Question/Advice on iRule Remediating the Telerik (Unsafe Reflection Vulnerability (CVE-2025-3600)

HI Maxim_Taskov​    We have this really cool AI iRules assistant   F5 AI Assistant Expands with iRules Code Generation for BIG-IP Programmability | F5  that can help write and analyze irules... I put your irule in and here is what came back...  

 

1. Objective
   • This iRule targets requests for “Telerik.Web.UI.WebResource.axd” and applies three security controls.
   • It first allows only specific POST uploads (type=rau or rcu).
   • It then blocks any GET with a Content-Type header.
   • Finally, it blocks requests containing “prtype=” in the decoded query or cookie, or any non-GET not already allowed.
2. Execution Flow
   • Event: when HTTP_REQUEST (docs: valid event for HTTP::path, HTTP::query, HTTP::method, etc.)
   1. Retrieve the request path via HTTP::path, lowercase it (string tolower).
   2. If the lowercase path matches *telerik.web.ui.webresource.axd, proceed; else do nothing.
   3. Normalize the method: set method [string toupper [HTTP::method]].
   4. Read raw query: set raw_q [HTTP::query]; decode if non-empty (URI::decode), else set dec_q "".
   5. If a “Cookie” header exists (HTTP::header exists "Cookie"), read and decode it into dec_cookie; else dec_cookie is empty.
   6. Rule 1 (ALLOW):
      – If method == "POST" and dec_q matches ^type=(rau|rcu)$ (case-insensitive), then return (stop this event).
   7. Rule 2 (BLOCK):
      – If method == "GET" and a non-empty “Content-Type” header exists, then respond with 403 “Request blocked 2”, disable the event, and return.
   8. Rule 3 (BLOCK):
      – If dec_q or dec_cookie contains prtype= (case-insensitive) OR method != "GET", then respond with 403 “Request blocked 3”, disable the event, and return.
   9. If none of the above rules fired, the request is allowed to proceed.
3. Potential Logic Concerns
   • The calls to event disable omit the required event name (e.g., event HTTP_REQUEST disable), so they will not actually disable further evaluations as intended. (high confidence)

Overall, the iRule correctly sequences allow-then-block checks for the targeted resource, but the malformed event disable commands mean blocked requests may still trigger later events.

 

So it seems there may be an issue with the event disable.  

Looks like the request  matches a blocking condition, the iRule issues HTTP::respond 403 to reject it, followed by event disable and return.

Event disable disables the HTTP_REQUEST event for the entire current TCP connection. This is a global effect on the connection, not just the current HTTP request.

Have you considered using "reject" which will send a TCP RST, closing the connection immediately.  

 

this part of the code you can try 

if { [regexp -nocase {prtype=} $dec_q]
             || [regexp -nocase {prtype=} $dec_cookie]
             || $method ne "GET" } {
            HTTP::respond 403 content {Request blocked 3}
            reject  ;# Close connection to prevent reuse
            return
        }