Showing results for 
Search instead for 
Did you mean: 

Log4j iRule mitigation as described in K59329043 - which encoding is the regex using ?


Hi Community,


just for my understanding - can someone please clarify which encoding is being used in the regex with F5 release under K59329043 in order to mitigate log4j CVEs exploits ?


I'm referring to this regex


when RULE_INIT {

# To switch to a much more aggressive regexp uncomment the first line and comment the second.

#    set static::log4j_regex {(?i)(\$|\\+(0?44|([u0]00|x)24))'?(\{|\\+(0?173|([u0]00|x)7b))'?}

    set static::log4j_regex {(?i)(\$|\\+(0?44|([u0]00|x)24))'?(\{|\\+(0?173|([u0]00|x)7b))'?\s*((j|b|\\+(0?1[5140]2|([u0]00|x)[64][a2]))|((\$|\\+(0?44|([u0]00|x)24))?'?(\{|\\+(0?173|([u0]00|x)7b))'?.+?'?(\}|\\+(0?175|([u0]00|x)7d))'?))}



I'm seeing some false positives in the payload of applications where the iRule is at the moment active; nevertheless when I attempt to regex the payload I cannot see any match - so I suspect I might be using the wrong encoding.


Thank you for your assistance


Hi ,


the regex will search for some possible variants and obfuscations of the well-known string that is used to exploit the log4shell vulnerability.

Paste the full string without the {} here:

You will get an awesome explanation with syntax highlighting.






Another great site for regex visualisation :


Copy paste the F5 regex without the {} and (?i).


Hi @Daniel Wolf​ ,


thank you for your quick reply. Well, I already actually tried to get my answer via


Here what somehow suprises me:


if I type in this string




which I extracted from a real attack / exploit attempt against one of our production servers:


info tmm[13241]: Rule /Linux/LOG4J-iRULE-BLOCK <HTTP_REQUEST>: log4j_rce_detection drop on URI: /${jndi:ldap:/}


I only get match on the first 3 characters:


0691T00000F8FwBQAV.pngIs it meant to be so ? or am I missing something here ?


Thank you for clarifying.


Best Regards

The idea here is that, when you encounter a string that starts with ${j the rest of the string is most likely going to be ndi:ldap:/}.


If you remember previous versions of this iRule, F5 was always offering two or three different regexes. More or less permissive. The more characters you inspect, the more permissive the iRule will be. You could also say you will have less false positive.

On the other hand - the more characters you inspect, the more CPU cycles are used. Matching regex is expensive on the CPU. So it's a trade-off between preciseness and performance.






thank you for clarifying the trade off idea behind.


What I'm still missing here is the encoding part used when performing the Regex comparison - as mentioned in the initial post, I'm seeing some false positives within the application payload. This forced me to manually add some whitelisting within the originally provided iRule.


I've attempted to dump the payload as collected by the "HTTP_REQUEST_DATA" event and have it checked against the reference regex (tcl based regex checking - using the f5 built-in tclsh interpreter for ex.) in order to better understand what is exactly matching the Regex - yet I'm seeing no matches.


So clearly I'm missing out on the encoding part.


Can you perhaps also advice on this ?


Thank you and Best Regards

Hi ,


looking only at this part (\$|\\+(0?44|([u0]00|x)24)) 

I can recognise the literal $.

The octal of $, which ist 44.

The hexadecimal of $, which is 24.

And some more characters in between.


And I would not claim that I am good at reading regex... Someone more savvy can for sure explain you in more details.






thank you for your feedback. So basically the regex is trying to match across multiple encodings at the same time - right ?


Best Regards

Yes, , that pretty much sums it up.


I imagine, to avoid false positives, the irule will need to parse a lot more than the first 3 characters. Even if there is an overhead