El nombre que los investigadores han dado a dos vulnerabilidades críticas en PHP, identificadas como CVE-2026-109618 y CVE-2026-109619. PHP les asigna una puntuación CVSS v4.0 de 9.2 a cada una. Los detalles se filtraron antes de que hubiera parche.

¿Cuándo salió el parche?

El 21 de octubre de 2026 a las 14:00 UTC (16:00 en la España peninsular), tal y como estaba anunciado. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 — exactamente las que se esperaban.

¿Qué versiones de PHP están afectadas?

Según el aviso oficial, todas las instalaciones que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Se corrigen las ramas 8.2 a 8.5. Para 8.1 y anteriores, ya sin soporte, PHP ha publicado backports mínimos de código fuente para 7.4, 8.0 y 8.1, y las distribuciones y vendors LTS pueden ofrecer paquetes backportados.

¿Se está explotando ya?

Sí. Amazon Threat Intelligence ha observado intentos de explotación el 17 de octubre, cuatro días antes de la divulgación pública y tres antes de la propia filtración. Los fallos no figuran aún en el catálogo KEV de CISA, pero la ventana pre-parche ya estaba abierta.

¿Hay alguna mitigación?

Junto al parche, PHP ha publicado mitigaciones temporales oficiales: deshabilitar session.upload_progress, reiniciar los workers de forma regular y revisar la guía de memory_limit, post_max_size y fatal_error_backtraces. La medida preventiva que DMNTR aplicó el día del embargo resultó ir en la línea correcta. Ninguna de ellas sustituye a la actualización.

¿Y si uso PHP 8.1 o anterior?

Esas ramas están fuera de soporte y no reciben el parche oficial. PHP ha publicado backports mínimos de código fuente para 7.4, 8.0 y 8.1. Si no puedes actualizar, aísla esos servidores detrás de una VPN o un WAF y dales prioridad en el inventario.

php2shell: dos fallos críticos en PHP y un parche que sale hoy

“Two CRITICAL, unpatched PHP flaws (CVSS 9.2 each)”, avisaba The Hacker News en X esta madrugada. Los fallos son reales: el propio equipo de seguridad de PHP ha anunciado una versión que corrige dos vulnerabilidades críticas para hoy, 21 de octubre, a las 14:00 UTC (16:00 en la España peninsular). Lo inusual es que los detalles se filtraron antes del parche.

Actualización (22 de octubre, post-parche): el parche salió el 21 de octubre como estaba previsto. PHP publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35 — exactamente las versiones que se esperaban —, confirmó ambos fallos como ejecución remota de código sin autenticación con todos los SAPI que sirven web en riesgo (mod_php, el peor escenario), y publicó mitigaciones temporales oficiales. El dato que faltaba en esta crónica: Amazon Threat Intelligence detectó intentos de explotación el 17 de octubre, antes incluso de la filtración del día 20. El seguimiento completo — mitigaciones oficiales, detección y el repo del NCSC de Países Bajos con inventario SPDX de software con PHP embebido — está en php2shell: dos RCE críticas en PHP y el repo del NCSC para frenarlas. Este artículo queda como crónica de la mañana del embargo: se mantiene como estaba, salvo esta caja y sus preguntas frecuentes, actualizadas.

Qué se sabe

Dos fallos con CVSS v4.0 de 9.2 cada uno, según el aviso de PHP. Los identificadores que circulan son CVE-2026-109618 y CVE-2026-109619. El aviso oficial no los nombra todavía y en NVD aún no aparecen.
El nombre “php2shell” lo pusieron los investigadores, no PHP. Se habla de posible ejecución remota de código.
Hubo filtración. Según Huntress, los detalles salieron el 20 de octubre, antes de la divulgación coordinada, e incluso se publicó un vídeo corto de explotación que después se retiró.
Es reproducible. La firma watchTowr dice en su FAQ que ha reproducido CVE-2026-109618.
Sin explotación conocida, por ahora. Ni Huntress ni watchTowr la han visto, y los fallos no figuran en el catálogo KEV de CISA.

Qué no se sabe

Qué parte de PHP está afectada. No hay confirmación de si es el motor, PHP-FPM o CGI, ni de si hace falta una configuración concreta o autenticación. Algunos resúmenes dicen “sin autenticación”; ninguna fuente primaria lo respalda aún.

Desde qué versión. La filtración habla de “PHP 5 en adelante”. watchTowr subraya que eso no está confirmado.

Cuántos servidores hay en riesgo. Según The Hacker News, el 20 de octubre Shodan mostraba unos 884.000 servidores que anunciaban PHP 8.1 o anterior, el 59% de los 1,5 millones que indicaban versión. Son banners, no sistemas vulnerables confirmados.

Las versiones corregidas. Alpine y el investigador Kevin Beaumont esperan 8.5.12, 8.4.27, 8.3.36 y 8.2.35, pero PHP no las ha confirmado. A la hora de escribir, las últimas en php.net siguen siendo 8.5.11, 8.4.26, 8.3.35 y 8.2.34, del 24 de septiembre.

Qué hacer antes de las 14:00 UTC

Las recomendaciones de Huntress, ordenadas por lo que te afectan:

Haz inventario. Todo lo que lleve PHP: servidores web, paneles como cPanel o Plesk, appliances y programas de Windows que incluyen su propio php-cgi.exe.
Prioriza lo expuesto a Internet. Es lo primero que hay que actualizar cuando salga el parche.
Aísla las versiones sin soporte. PHP 8.1 y anteriores no recibirán corrección: solo se parchean las ramas 8.2 a 8.5. Ponlas detrás de una VPN o un WAF.
Vigila los procesos. Un worker de PHP que lanza una shell o descarga archivos es una señal de alarma.

Si usas hosting compartido, la actualización depende de tu proveedor: pregunta cuándo la aplicará.

Una mitigación no oficial

PHP no ha publicado ninguna mitigación. Aun así, el proveedor español DMNTR Network Solutions explica que ya la ha aplicado en todos los servidores que opera: desactivar el progreso de subida de ficheros de PHP (session.upload_progress).

Si administras tu propio servidor, la configuración que comparten es un archivo php.d/99-no-upload-progress.ini con:

session.upload_progress.enabled = Off

Y, en cada pool de PHP-FPM, esta línea para que ningún dominio la reactive:

php_admin_flag[session.upload_progress.enabled] = off

Después, reinicia PHP-FPM. El efecto visible, según DMNTR, es que puede dejar de verse la barra de progreso al subir archivos.

Tómalo como lo que es: una medida preventiva de un proveedor, no del equipo de PHP. Ninguna fuente oficial ha confirmado que los fallos estén en esa función, así que no sustituye al parche. Si la aplicas, actualiza igualmente en cuanto salgan las versiones corregidas.

Ojo con el ruido

Hay webs de baja calidad amplificando la noticia con datos que no aparecen en ninguna fuente primaria, como una puntuación de 10.0 (la oficial es 9.2) o una supuesta corrupción de memoria al procesar HTTP. Mientras PHP no publique el aviso completo, trata esos detalles como especulación.

Si gestionas servidores, la guía OWASP de 137 cheat sheets es buen punto de partida para endurecer tus aplicaciones. Este artículo quedó actualizado tras la salida del parche: ver la caja de actualización al principio.

El contexto

El mismo miércoles, Node.js también ha soltado su parche: 10 CVEs corregidas en las tres ramas activas, con un RCE en el decodificador Brotli y dos saltos de la verificación de hostname en TLS. Día de php -v y de node -v.