El equipo de seguridad de PHP publicará hoy, miércoles 21/10/2026, a las 14:00 UTC (16:00 en la España peninsular), una actualización que corrige dos vulnerabilidades críticas, ambas con una puntuación de 9,2 sobre 10 en CVSS v4.0. El aviso llegó el 20/10/2026, unas horas después de que la existencia de los fallos se filtrara en Internet antes de que hubiera parche. PHP es el lenguaje sobre el que funcionan WordPress, WooCommerce, Magento, Drupal y buena parte de las webs y tiendas online del mundo.
Las claves de las vulnerabilidades críticas de PHP en 30 segundos
- PHP corrige hoy a las 16:00 (hora peninsular) dos fallos con CVSS 9,2.
- Las versiones afectadas y los detalles técnicos se conocerán con la publicación.
- Varios investigadores hablan de ejecución remota de código y de un fallo ligado a la función de progreso de subidas.
- Solo las ramas 8.2, 8.3, 8.4 y 8.5 reciben correcciones de seguridad.
- A primera hora de hoy no había constancia pública de ataques reales confirmados.
Lo habitual en estos casos es que los fallos se mantengan en secreto (bajo embargo) hasta que la corrección está lista. Esta vez la noticia salió antes: la primera mención pública fue una publicación en Hacker News, después retirada, cuyas capturas circularon por X y Mastodon. Horas más tarde, PHP adelantó el aviso oficial y fijó la fecha de publicación.
Lo que ha confirmado PHP
El anuncio oficial, publicado en php.net y en el foro de la PHP Foundation, es escueto. Confirma que son dos vulnerabilidades críticas, que ambas tienen una puntuación de 9,2 en CVSS v4.0 y que la actualización saldrá el 21/10/2026 a las 14:00 UTC. El equipo de seguridad anima a todos los usuarios a prepararse «ahora» para actualizar en cuanto esté disponible, y se reserva el derecho a publicar antes si se hacen públicos los detalles de alguno de los fallos o si aparecen pruebas de explotación activa.
PHP no ha dicho qué versiones están afectadas, en qué componente está el fallo ni cómo se aprovecha. Todo eso se publicará junto con la actualización. Tampoco ha citado identificadores CVE: los que circulan, CVE-2026-109618 y CVE-2026-109619, proceden de la filtración y de los investigadores que la han comentado, y aún no tienen descripción oficial.
Hay un matiz importante para muchas empresas. PHP solo mantiene con parches de seguridad las ramas 8.2, 8.3, 8.4 y 8.5. Las versiones 8.1, 8.0, 7.x y 5.x ya no reciben correcciones, así que, si estos fallos también les afectan, no habrá arreglo oficial para ellas. En el sector se repite la misma realidad: buena parte de las webs no actualiza a tiempo, como reflejaba el dato de que el 86 % de las instalaciones de WordPress analizadas no estaba al día.
Lo que dicen los investigadores, sin confirmar por PHP
La empresa de investigación watchTowr ha confirmado públicamente que las vulnerabilidades son reales, aunque aclara que no las descubrió, y ha pedido que se tomen «en serio» y se apliquen los parches en cuanto estén disponibles. Varios investigadores las describen como ejecución remota de código: un atacante podría ejecutar órdenes en el servidor desde Internet sin tener acceso previo.
Sansec, especializada en seguridad de tiendas online, sostiene que afectan a todos los servidores web con PHP 5.4 o posterior, incluidas tiendas Magento, y que hay que corregirlas en la infraestructura, es decir, actualizando PHP en el servidor; no se pueden resolver desde el código de la aplicación. El caso ha recibido el nombre de «PHP2Shell». Para las tiendas, el precedente es claro: con SessionReaper en Magento, los ataques empezaron muy poco después de conocerse el fallo.
La japonesa GMO Flatt Security cree, tras su propia investigación, que el problema estaría en la función de seguimiento del progreso de las subidas de archivos de las sesiones de PHP (Session Upload Progress), que viene activada por defecto. Como medida temporal propone desactivarla con session.upload_progress.enabled=0 en el archivo php.ini, aunque advierte de que no puede asegurar que eso detenga el ataque por completo y de que su análisis se ha publicado con prisa y puede contener errores. Según Flatt, el ataque se ha reproducido con mod_php, php-fpm, WordPress, Laravel y Symfony, como ejemplos y no como lista cerrada.
No hay acuerdo en varios puntos. Sobre las versiones, la filtración original hablaba de «todas desde PHP 5» y Sansec, de PHP 5.4 o posterior. Sobre la gravedad, en la filtración se habló de 10 sobre 10, mientras que la cifra oficial de PHP es 9,2. Y sobre la medida temporal, otros investigadores apuntan a que uno de los dos fallos estaría en el procesamiento de los formularios con archivos adjuntos, que no se evitaría desactivando el progreso de subidas.
Qué hacer antes y después de las 16:00
El CERT-EU, el equipo de respuesta a incidentes de las instituciones europeas, publicó el 21/10/2026 un aviso en el que recomienda identificar las aplicaciones basadas en PHP y prepararse para parchear en cuanto haya versiones corregidas. Si no es posible hacerlo de inmediato, sugiere valorar aislar de la red pública las aplicaciones expuestas a Internet hasta poder aplicar la corrección.
Con lo que se sabe, los pasos razonables son:
- Inventariar todos los servidores, contenedores e imágenes que usan PHP y anotar su versión.
- Confirmar quién aplicará la actualización: en alojamientos gestionados o compartidos, preguntar al proveedor cuándo la desplegará.
- Reservar una ventana de mantenimiento poco después de las 16:00 y tener preparadas pruebas básicas de la web o la tienda.
- Probar en un entorno de pruebas la desactivación de
session.upload_progress.enabledcomo medida provisional, sabiendo que no garantiza protección total. - Planificar la migración a PHP 8.2 o superior de los sistemas con versiones sin soporte.
- Revisar los registros del servidor para poder investigar si se detecta actividad sospechosa.
A primera hora de hoy, ni PHP ni las empresas que han analizado el caso habían informado de ataques reales, aunque circula un vídeo de demostración sin verificar y varios investigadores esperan intentos de explotación poco después de que se publique la corrección, cuando los atacantes puedan comparar el código parcheado con el anterior.
Cómo mitigar el riesgo con Cloudflare
Cloudflare publicó el 21/10/2026 una actualización de emergencia de su Cloudflare Managed Ruleset, el conjunto de reglas gestionadas de su cortafuegos de aplicaciones web (WAF), con cuatro reglas nuevas llamadas «Generic Rules – Anomalous Execution» (de la 1 a la 4) para detectar patrones de peticiones anómalos. La 1 y la 3 bloquean por defecto; la 2 y la 4 solo registran. La compañía no vincula estas reglas a las vulnerabilidades de PHP ni explica qué detectan, así que no hay confirmación de que cubran este caso, pero quien tenga sus webs detrás de Cloudflare puede reforzar la protección mientras actualiza:
- Comprobar que el Cloudflare Managed Ruleset está activado: en el panel, en Security > Settings, filtrar por «Web application exploits» y activar «Cloudflare managed ruleset». Solo está disponible en los planes Pro, Business y Enterprise; el plan gratuito incluye el Free Managed Ruleset, que la nota de Cloudflare no menciona.
- Revisar las cuatro reglas «Anomalous Execution» desde Security rules, en la regla del conjunto gestionado, con la opción «Browse rules», y valorar pasar a bloqueo las dos que solo registran, después de comprobar en los eventos de seguridad que no provocan falsos positivos.
- Vigilar los eventos de seguridad para ver si estas reglas saltan sobre las webs PHP.
- Asegurarse de que el servidor de origen solo acepta tráfico de las IP de Cloudflare, porque el WAF no protege las peticiones que llegan directamente al servidor.
Como el resto de medidas temporales, no sustituye a la actualización de PHP.
Preguntas frecuentes
¿Cuándo publica PHP la actualización de seguridad?
El miércoles 21/10/2026 a las 14:00 UTC, las 16:00 en la España peninsular. PHP puede adelantarla si se publican los detalles o se detectan ataques.
¿Qué versiones de PHP están afectadas?
PHP no lo ha dicho todavía; lo publicará con la actualización. Investigadores como Sansec hablan de PHP 5.4 o posterior, pero no está confirmado oficialmente.
¿Habrá parche para PHP 7 o PHP 8.1?
PHP solo da soporte de seguridad a las ramas 8.2, 8.3, 8.4 y 8.5. Las versiones anteriores no reciben correcciones, así que la recomendación es migrar a una rama soportada.
¿Sirve desactivar session.upload_progress?
Flatt Security lo propone como medida temporal, pero reconoce que no puede asegurar que proteja del todo, y otros investigadores creen que no cubre uno de los dos fallos. No sustituye a la actualización.
Fuentes:
- PHP: Upcoming Critical PHP Security Release
- PHP Foundation: [ANNOUNCE] Upcoming Critical PHP Security Release
- CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
- GMO Flatt Security: PHPの重大な脆弱性「php2shell」の概要と対応指針
- Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619
- Cloudflare: WAF Release 2026-10-21, Emergency, Cloudflare Managed Ruleset
- Threat Landscape: PHP Core RCEs leak early
