EN PT-BR
← Voltar ao feed
high

OWASP ModSecurity publishes advisories and PoC for RFC 2231 filename* WAF bypass (CVE-2026-104269) and XML parser flaw (CVE-2026-73857)

1 fonte(s) · 1 atualização(ões) · publicado 09/11/2026 00:07 · coletado há 2 horas

The OWASP ModSecurity project has published full advisories for two flaws fixed in libmodsecurity 3.0.17, released on 29 September 2026, one of them with a working proof-of-concept request. CVE-2026-104269 (CVSS 8.6, GHSA-5pww-8rfg-9crf) lets an attacker hide a dangerous upload file name in the RFC 2231 filename* parameter that ModSecurity's multipart parser ignored, so that OWASP CRS upload rules see only a harmless decoy while the application saves the real file — the advisory states the WAF protection is "entirely bypassed" and warns of "RCE if in webroot". CVE-2026-73857 (CVSS 7.5, GHSA-jx3r-phvx-2jmj) is an uninitialized pointer dereference in the XML-into-ARGS code that a single crafted request can turn into a restricted write-what-where primitive, with impact ranging from denial of service to memory disclosure and execution-flow redirection. No exploitation in the wild has been reported for either flaw. The project's own advisory digest shows that the multipart bypass also affects the Apache module mod_security2 up to 2.9.14, fixed in 2.9.15 — a detail the article omits (modsecurity.org).

Entenda a falha

A vulnerabilidade

Two flaws in OWASP ModSecurity, both fixed in libmodsecurity 3.0.17 (29 September 2026). CVE-2026-104269 (CVSS 8.6) is a WAF bypass in the multipart parser: it ignores the RFC 2231 filename* parameter, so an attacker who sends an upload request can show the OWASP CRS upload rules a harmless decoy name while the backend saves the real file. This affects libmodsecurity 3.0.0 through 3.0.16, and mod_security2 up to 2.9.14 (fixed in 2.9.15) according to the project's advisory digest. The advisory warns of RCE if the file lands in the webroot. CVE-2026-73857 (CVSS 7.5) is an uninitialized pointer dereference in the XML-into-ARGS code. A single crafted request gives a restricted write-what-where primitive, with impact from denial of service to memory disclosure and execution-flow redirection. It affects only libmodsecurity 3.0.15 and 3.0.16, and only when SecParseXmlIntoArgs is On or OnlyArgs (off by default).

Como funciona

For CVE-2026-104269, a multipart upload part carries a Content-Disposition header that may hold a file name twice: plain filename and an encoded filename*. ModSecurity's parser reads only the plain one. A part with only filename* gets no file name at all and just logs a warning. Rules that use MULTIPART_FILENAME, FILES or a raw-header regex (CRS 920120, 922100, 922110) therefore see nothing or the decoy. The request then reaches the application, and backends in Go, Python, Node.js and Java prefer the decoded filename* value and save that file. PHP is not affected. For CVE-2026-73857, with XML-into-ARGS parsing enabled, a request body is parsed by a SAX parser. In the end-element callback the code dereferences a pointer that was never initialized and writes a constant value to the address it holds.

Por que é vulnerável

CVE-2026-104269 comes from the multipart parser not implementing RFC 2231, so the WAF and the backend disagree on which file name a part carries. The fix decodes filename*, makes MULTIPART_FILENAME hold the filename* value when both are present, and adds MULTIPART_FILENAME_CHARSET and MULTIPART_FILENAME_LANGUAGE. CVE-2026-73857 is a missing initialization of a pointer that is later dereferenced. In mod_security2 the XML state is zeroed with apr_pcalloc(), so the pointer was already NULL there, but it received the same guard as defence in depth.

Onde está

The XML flaw is in XMLNodes::parsing_ctx_arg, used in the XML-into-ARGS SAX end-element callback; the multipart flaw is in ModSecurity's multipart parser. Both fixes shipped in pull request #3647 (V3/master3017) in github.com/owasp-modsecurity/ModSecurity.

Como foi descoberta

The project credits the CVE-2026-104269 report to 0xkalawy, ZeyadZonkorany and Mohamed Gouda (B0YK4), with the fix contributed by Hiroaki Nakamura, Felipe Zipitria and Ervin Hegedüs. Tobias Klein reported CVE-2026-73857 on 3 July 2026. The fixes shipped in libmodsecurity 3.0.17 on 29 September 2026, and the project later published the full advisories (GHSA-5pww-8rfg-9crf and GHSA-jx3r-phvx-2jmj). No exploitation in the wild has been reported for either flaw.

PoC pública

The advisory for CVE-2026-104269 includes a complete proof-of-concept upload request and a table of what each layer sees, showing the decoy name reaching the WAF while the backend takes the real one. It is a working demonstration of the bypass on RFC-compliant backends (Go, Python, Node.js, Java). The XML advisory (CVE-2026-73857) describes the bug but ships no exploit. Since the PoC is public, upgrade to 3.0.17 soon, even though no in-the-wild exploitation is reported.

Explicação gerada por IA a partir da matéria e dos artigos, em 09/11/2026 01:17.

Detalhes técnicos

CVE-2026-104269: Content-Disposition headers may carry a file name twice, as plain filename and as an RFC 2231 encoded filename*; RFC-compliant parsers prefer filename*. ModSecurity's multipart parser did not implement RFC 2231: it recognised filename only, and a part carrying filename* alone populated no file name at all, logging a warning instead, so rules using MULTIPART_FILENAME, FILES or a raw-header regex — including CRS 920120, 922100 and 922110 — saw nothing or the decoy. Backends in Go, Python, Node.js and Java act on the filename* value; PHP is not affected. The project credits the report to 0xkalawy, ZeyadZonkorany and Mohamed Gouda (B0YK4), with the fix contributed by Hiroaki Nakamura, Felipe Zipitria and Ervin Hegedüs (modsecurity.org).

CVE-2026-73857: reported by Tobias Klein on 3 July 2026, the bug is a dereference of the uninitialized pointer XMLNodes::parsing_ctx_arg in the XML-into-ARGS SAX end-element callback, resulting in a write of a constant value to an attacker-controlled address. It affects libmodsecurity 3.0.15 and 3.0.16 only and is reachable only when SecParseXmlIntoArgs is set to On or OnlyArgs, which is off by default; mod_security2 zeroes its XML state with apr_pcalloc() so the pointer was already NULL there, but received the same guard as defence in depth (modsecurity.org). This default-off prerequisite materially limits real-world exposure.

Detalhes da correção

The 3.0.17 release was merged through pull request #3647 ("V3/master3017"), opened by maintainer Ervin Hegedüs (airween) and merged into v3/master with 58 commits; it bundles the RFC 2231 filename* handling, the new multipart variables for duplicate part headers and extended filename charset and language, improved remote-rules download host verification and the XML argument parsing fix (github.com/owasp-modsecurity/ModSecurity). Behaviour changes to review before upgrading: a part carrying only filename* now populates MULTIPART_FILENAME, and when both parameters are present that variable holds the filename* value (modsecurity.org).

Remediação

Upgrade libmodsecurity to 3.0.17 and, for Apache deployments, mod_security2 to 2.9.15. 3.0.17 decodes filename* and adds the MULTIPART_FILENAME_CHARSET and MULTIPART_FILENAME_LANGUAGE variables. Where upgrading is not yet possible, keep SecParseXmlIntoArgs set to Off to remove the XML attack surface; there is no equivalent configuration mitigation for the filename bypass. Validate file extensions in the application itself and not only at the WAF. Release 3.0.17 also fixes six further ModSecurity issues, including a response body inspection bypass, so the upgrade closes considerably more than these two flaws.

Linha do tempo

  1. securityonline.info ↗ · pub. 09/11/2026 00:07 · coletado 09/11 01:00 primeiro registro

    OWASP ModSecurity publishes advisories and PoC for RFC 2231 filename* WAF bypass (CVE-2026-104269) and XML parser flaw (CVE-2026-73857)

    ler a análise desta fonte

    The OWASP ModSecurity project has published full advisories for two flaws fixed in libmodsecurity 3.0.17, released on 29 September 2026, one of them with a working proof-of-concept request. CVE-2026-104269 (CVSS 8.6, GHSA-5pww-8rfg-9crf) lets an attacker hide a dangerous upload file name in the RFC 2231 filename* parameter that ModSecurity's multipart parser ignored, so that OWASP CRS upload rules see only a harmless decoy while the application saves the real file — the advisory states the WAF protection is "entirely bypassed" and warns of "RCE if in webroot". CVE-2026-73857 (CVSS 7.5, GHSA-jx3r-phvx-2jmj) is an uninitialized pointer dereference in the XML-into-ARGS code that a single crafted request can turn into a restricted write-what-where primitive, with impact ranging from denial of service to memory disclosure and execution-flow redirection. No exploitation in the wild has been reported for either flaw. The project's own advisory digest shows that the multipart bypass also affects the Apache module mod_security2 up to 2.9.14, fixed in 2.9.15 — a detail the article omits (modsecurity.org).

    Technical Details

    CVE-2026-104269: Content-Disposition headers may carry a file name twice, as plain filename and as an RFC 2231 encoded filename*; RFC-compliant parsers prefer filename*. ModSecurity's multipart parser did not implement RFC 2231: it recognised filename only, and a part carrying filename* alone populated no file name at all, logging a warning instead, so rules using MULTIPART_FILENAME, FILES or a raw-header regex — including CRS 920120, 922100 and 922110 — saw nothing or the decoy. Backends in Go, Python, Node.js and Java act on the filename* value; PHP is not affected. The project credits the report to 0xkalawy, ZeyadZonkorany and Mohamed Gouda (B0YK4), with the fix contributed by Hiroaki Nakamura, Felipe Zipitria and Ervin Hegedüs (modsecurity.org).

    CVE-2026-73857: reported by Tobias Klein on 3 July 2026, the bug is a dereference of the uninitialized pointer XMLNodes::parsing_ctx_arg in the XML-into-ARGS SAX end-element callback, resulting in a write of a constant value to an attacker-controlled address. It affects libmodsecurity 3.0.15 and 3.0.16 only and is reachable only when SecParseXmlIntoArgs is set to On or OnlyArgs, which is off by default; mod_security2 zeroes its XML state with apr_pcalloc() so the pointer was already NULL there, but received the same guard as defence in depth (modsecurity.org). This default-off prerequisite materially limits real-world exposure.

    Fix Details

    The 3.0.17 release was merged through pull request #3647 ("V3/master3017"), opened by maintainer Ervin Hegedüs (airween) and merged into v3/master with 58 commits; it bundles the RFC 2231 filename* handling, the new multipart variables for duplicate part headers and extended filename charset and language, improved remote-rules download host verification and the XML argument parsing fix (github.com/owasp-modsecurity/ModSecurity). Behaviour changes to review before upgrading: a part carrying only filename* now populates MULTIPART_FILENAME, and when both parameters are present that variable holds the filename* value (modsecurity.org).

    Remediation

    Upgrade libmodsecurity to 3.0.17 and, for Apache deployments, mod_security2 to 2.9.15. 3.0.17 decodes filename* and adds the MULTIPART_FILENAME_CHARSET and MULTIPART_FILENAME_LANGUAGE variables. Where upgrading is not yet possible, keep SecParseXmlIntoArgs set to Off to remove the XML attack surface; there is no equivalent configuration mitigation for the filename bypass. Validate file extensions in the application itself and not only at the WAF. Release 3.0.17 also fixes six further ModSecurity issues, including a response body inspection bypass, so the upgrade closes considerably more than these two flaws.