OWASP ModSecurity, el cortafuegos de aplicaciones web (WAF) de código abierto más extendido, tiene dos vulnerabilidades de gravedad alta en su rama 3. La primera, CVE-2026-73857, es un fallo de memoria en el procesador de XML que puede tumbar el servidor y, en el peor caso, abrir la puerta a ejecución remota de código; se corrige en libmodsecurity 3.0.17. La segunda, CVE-2026-104269, permite colar un archivo con nombre malicioso saltándose las reglas de subida de ficheros, y a día de hoy no tiene parche.
Las claves de los fallos de ModSecurity en 20 segundos
- CVE-2026-73857 (CVSS 7,5) afecta a libmodsecurity 3.0.15 y 3.0.16.
- Solo es explotable con SecParseXmlIntoArgs activado, que viene desactivado.
- CVE-2026-104269 (CVSS 8,6) afecta a toda la rama 3 y no tiene parche.
Algunos medios han informado de que ModSecurity ha «parcheado» dos fallos, pero los avisos oficiales del proyecto en GitHub cuentan otra cosa: solo uno tiene versión corregida. ModSecurity v2 no está afectado por el fallo de XML, y el aviso del segundo error se limita a la rama 3.
CVE-2026-73857: un puntero sin inicializar en el procesador XML
Lo descubrió el investigador Tobias Klein. Según el aviso GHSA-jx3r-phvx-2jmj, un atacante remoto y sin autenticar puede, con una sola petición HTTP manipulada, hacer que un proceso del servidor web que ejecuta ModSecurity use un puntero sin inicializar en la función que convierte el XML en argumentos. El resultado es una escritura de un valor fijo en una dirección que elige el atacante. El efecto va desde la denegación de servicio hasta la fuga de memoria o el desvío del flujo de ejecución, que podría acabar en ejecución remota de código.
El código vulnerable se introdujo en la versión 3.0.15, así que afecta a la 3.0.15, a la 3.0.16 y a la rama principal de desarrollo. Hay una condición importante: solo se puede alcanzar si la directiva SecParseXmlIntoArgs está en On u OnlyArgs, y por defecto está en Off. El aviso marca como versión corregida la 3.0.17, publicada el 29 de septiembre de 2026, aunque su texto todavía conserva una nota antigua según la cual el parche llegaría en la siguiente versión. Si no se puede actualizar, el remedio es mantener esa directiva desactivada.
CVE-2026-104269: el truco del filename*
El segundo fallo es más sutil y, por ahora, más preocupante, porque no tiene solución en ModSecurity. Lo encontraron los investigadores 0xkalawy y ZeyadZonkorany, con la coordinación de B0YK4. El analizador multipart de ModSecurity no implementa la RFC 2231, que permite enviar parámetros codificados con la sintaxis filename*=UTF-8''nombre. Los analizadores de la mayoría de lenguajes de servidor sí la implementan y, cuando una petición trae a la vez filename y filename*, dan prioridad al segundo.
Eso permite que un atacante envíe un archivo con filename="safe.jpg", que es lo que ve el WAF y pasa las reglas de extensiones de OWASP CRS, y a la vez filename*=UTF-8''shell.php, que es el nombre que usa la aplicación. Si esta guarda el archivo con ese nombre en una carpeta servida por la web, el resultado puede ser ejecución remota de código. El aviso GHSA-5pww-8rfg-9crf, con una puntuación de 8,6, enumera como afectados Go (net/http), Python con Flask/Werkzeug o FastAPI/Starlette, Node.js con busboy o @fastify/multipart y Java con Spring. Las aplicaciones PHP nativas no están afectadas, porque solo leen filename.
Mientras no haya parche, la recomendación razonable es no confiar solo en el WAF para validar subidas: que la aplicación ignore el nombre enviado por el cliente y genere el suyo, valide extensiones con una lista de permitidas y guarde los ficheros fuera del directorio público. También es posible añadir una regla propia que rechace las cabeceras con filename* si la aplicación no las necesita, probándola antes en modo solo detección.
Preguntas frecuentes
¿Qué versión de ModSecurity corrige CVE-2026-73857?
libmodsecurity 3.0.17. Afecta a la 3.0.15 y la 3.0.16, y solo si SecParseXmlIntoArgs está activado.
¿Hay parche para CVE-2026-104269?
No. El aviso oficial no recoge ninguna versión corregida, así que la protección depende de la aplicación y de reglas propias.
¿Están afectadas las webs en PHP?
No por el fallo de nombres de archivo, porque PHP solo lee el parámetro filename. Sí pueden estarlo por el fallo de XML si usan libmodsecurity 3.0.15 o 3.0.16 con SecParseXmlIntoArgs activado.
Fuentes:
