PHP ha publicado parches de urgencia para dos fallos críticos que permiten ejecutar código sin autenticación. Explicamos qué ocurre y cómo actuar.
Qué ha pasado
La comunidad de PHP ha lanzado actualizaciones fuera de calendario para corregir dos fallos, identificados como CVE-2026-109618 y CVE-2026-109619. Ambos alcanzan 9,2 sobre 10 en CVSS v4.0, la escala estándar con la que se puntúa la gravedad de una vulnerabilidad. Según el resumen de Hispasec, ya circulan intentos de explotación y se han visto ajustes de carga maliciosa pensados para esquivar reglas de WAF (los cortafuegos de aplicaciones web).
Lo inquietante es que la exposición no depende de cómo esté escrita tu web. No hace falta una aplicación compleja ni un endpoint especial: si el servidor ejecuta una rama afectada del motor, puede ser atacable incluso con páginas triviales. Por eso conviene pensar en cómo se despliega PHP, más que en qué código corre encima.
Cómo funcionan los dos fallos
El primero describe una cadena de errores que termina en corrupción de memoria por falta de memoria disponible y puede acabar en ejecución de código con los permisos del proceso web. El segundo se debe a un estado global obsoleto, con las consecuencias típicas de un use-after-free: el programa sigue usando una zona de memoria que ya había liberado. Eso puede traducirse en divulgación de memoria y, en ciertos escenarios, en ejecución de código con los privilegios del worker.
La divulgación de memoria añade una segunda capa de riesgo: un atacante podría leer lo que el proceso tenga en RAM, como contraseñas, tokens, claves de API o certificados, según las peticiones concurrentes y el comportamiento del servidor. La superficie incluye PHP-FPM, php-cgi, FrankenPHP, LiteSpeed y, de forma destacada, Apache con mod_php, donde se ha demostrado un vector que puede activarse antes de que se ejecute el código de la aplicación.
Qué hacer ahora
Lo primero es actualizar a una versión corregida y reiniciar Apache, PHP-FPM y cualquier worker persistente, porque instalar el paquete no basta si el proceso sigue cargando el runtime antiguo. Si dependes de una distribución Linux o de un proveedor con soporte extendido, revisa el changelog: algunos mantenedores aplican el parche sin reflejarlo en el número de versión. Tienes más contexto en The Hacker News y en BleepingComputer.
- Si no puedes actualizar ya, para CVE-2026-109618: fija memory_limit=-1 de modo que la aplicación no lo sobrescriba, mantén post_max_size bajo y limita el tamaño de las peticiones en el servidor o el proxy. Evita RLIMIT_AS y RLIMIT_DATA como sustitutos, porque pueden activar rutas vulnerables.
- Para CVE-2026-109619: desactiva session.upload_progress.enabled y reinicia todos los workers. En PHP 8.5, otra contención parcial es desactivar fatal_error_backtraces y reiniciar procesos.
- Vigila señales compatibles con explotación: peticiones multipart anómalas seguidas de errores de límite de memoria, oleadas de HTTP 500, cookies PHPSESSID inusualmente grandes o reinicios inexplicables de workers.
Estas medidas son contención, no solución. Además, tras parchear la corrección introduce un límite duro de memoria: alcanzarlo puede terminar procesos y saltarse manejadores de apagado, así que conviene observar cambios de comportamiento. Y recordemos que PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto, de modo que modernizar versiones es una cuestión de seguridad, no solo de mantenimiento.
Artículos relacionados de LaRebelión
PHP prepara dos parches de emergencia para fallos críticos de ejecución remota
FortiBleed sigue activa: el FBI alerta sobre 86.644 credenciales Fortinet robadas
Citrix parchea un zero-day de NetScaler explotado que tumba despliegues SAML- GitHub comprometido por la extensión maliciosa Nx Console de VS Code
- Cinco servidores MCP corrigieron fallos SSRF con el mismo patrón
- TeaOnHer: fallos de API que exponían carnés y qué pasó después
Fuente original: unaaldia.hispasec.com
Elaborado con apoyo de IA y revisado por la redacción
Comentarios
Publicar un comentario