Si tu web usa PHP, actualiza ya: estas son las versiones que corrigen los dos fallos críticos

Dos vulnerabilidades críticas en PHP, uno de los lenguajes más utilizados para desarrollar páginas web, han provocado el cierre preventivo de numerosos portales públicos en Europa. Los fallos permiten a un atacante ejecutar código en un servidor sin necesidad de contraseña ni permisos, por lo que las autoridades de ciberseguridad han pedido actualizar los sistemas cuanto antes.

El equipo de PHP publicó el 21 de octubre varias actualizaciones para corregir los problemas. La alerta tiene un alcance considerable. Según W3Techs, PHP está presente en el 69,3% de los sitios web cuyo lenguaje de servidor se ha podido identificar.

Dos fallos críticos que permiten tomar el control de un servidor

Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas conjuntamente como PHP2Shell, tienen una gravedad de 9,2 sobre 10 en la escala CVSS v4.0, según los avisos del proyecto PHP. El INCIBE las considera críticas, según informó EFE.

Ambas están relacionadas con la gestión de la memoria del servidor, aunque funcionan de manera diferente:

• CVE-2026-109618: si el servidor se queda sin memoria mientras procesa una petición, PHP puede acabar utilizando datos internos que no se habían inicializado correctamente.
• CVE-2026-109619: permite que información interna de una petición permanezca en memoria después de haber sido liberada y pueda ser utilizada por otra petición posterior.

En determinadas circunstancias, una petición manipulada puede agotar la memoria del servidor incluso respetando sus límites configurados. La firma de ciberseguridad Wiz también advierte de que uno de los fallos permite acceder a información sensible almacenada en ella.

El mayor peligro es que el ataque puede producirse antes de que se ejecute el código de la propia página web. Según los avisos del proyecto PHP, los investigadores consiguieron ejecutar código sin autenticación en servidores Apache con mod_php, lo que significa que una web puede estar expuesta aunque su aplicación sea segura.

Por ahora, según Rapid7, los exploits públicos conocidos solo funcionan con determinadas combinaciones de sistema operativo, versión de PHP y servidor web, aunque varias empresas de seguridad ya han registrado intentos de explotación.

Qué versiones de PHP están afectadas y cómo actualizarlas

Los problemas afectan a las instalaciones de PHP que procesan peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Según el propio proyecto PHP, el riesgo es especialmente elevado cuando se utiliza mod_php.

Para corregir las vulnerabilidades, el equipo de PHP ha publicado las siguientes versiones:

Las versiones antiguas tampoco están a salvo. Los fallos alcanzan a casi todas las versiones desde PHP 5.4, aunque PHP 8.1 y las ramas anteriores ya no reciben actualizaciones oficiales. Para quienes compilan PHP desde el código fuente o no disponen de mantenimiento extendido, el equipo de seguridad ha publicado parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1.

Además, la rama PHP 8.2 ya solo recibe correcciones de seguridad y dejará de recibirlas el 31 de diciembre de 2026.

Es importante tener en cuenta que actualizar WordPress u otro gestor de contenidos no actualiza automáticamente PHP. Esa actualización depende del servidor, del proveedor de alojamiento o de la imagen del contenedor utilizada.

En algunas distribuciones Linux y servicios con mantenimiento extendido, las correcciones pueden estar disponibles sin que cambie el número principal de versión, ya que los proveedores han incorporado sus propios parches.

Qué hacer si tienes una página web que utiliza PHP

El INCIBE insiste en que la actualización es la única solución completa. Mientras se instala el parche, los administradores deben identificar los sistemas expuestos y adoptar medidas de protección.

• Actualizar PHP: instalar la versión corregida correspondiente y reiniciar Apache, PHP-FPM y los procesos PHP de larga duración.
• Aislar los servidores que no puedan actualizarse: desconectarlos de las redes públicas hasta que se haya aplicado la corrección, siguiendo las recomendaciones del INCIBE.
• Aplicar medidas temporales de mitigación: PHP propone configurar memory_limit=-1 (que desactiva el límite de memoria por petición y no sirve como solución a largo plazo), reducir post_max_size y desactivar session.upload_progress.enabled. En PHP 8.5 también recomienda fatal_error_backtraces=0. Estos ajustes deben realizarse a nivel de servidor, no mediante ini_set() en la aplicación, y requieren reiniciar los procesos. El proyecto advierte de que estas medidas no sustituyen la actualización.
• Revisar posibles intrusiones: instalar el parche no elimina el código malicioso que un atacante pudiera haber introducido anteriormente. Check Point aconseja comprobar si hay archivos PHP desconocidos, peticiones inusuales, interrupciones inexplicables, comandos ejecutados desde procesos del servidor o conexiones a direcciones externas sospechosas.

Se detectaron intentos de ataque antes de publicarse los parches

Los primeros intentos de explotación conocidos se remontan al 17 de octubre, cuatro días antes de la publicación de las actualizaciones.

Amazon detectó esa actividad en uno de sus sistemas señuelo. Las peticiones procedían de una red comercial de anonimización y la compañía considera que se trataba de un intento real de ataque, ya que las vulnerabilidades todavía no se habían divulgado públicamente.

El 21 de octubre, en torno a la publicación de los parches, empresas de ciberseguridad como Cloudflare y watchTowr también registraron intentos de explotación. watchTowr señaló que no había observado ataques que hubieran tenido éxito, aunque no esperaba que eso durara mucho.

Cloudflare activó el 21 de octubre, varias horas antes de la divulgación pública (la compañía habla de unas nueve), reglas de protección en su cortafuegos web. Según la empresa, protegen por defecto a los clientes de todos los planes; en los de pago conviene confirmar que su conjunto de reglas gestionadas está en modo de bloqueo. Su director ejecutivo, Matthew Prince, explicó en X que la compañía detectó millones de intentos de explotación después de la divulgación.

Gobiernos europeos desconectan páginas web por precaución

La gravedad de las vulnerabilidades llevó a distintas administraciones europeas a suspender temporalmente servicios y páginas web mientras aplicaban las actualizaciones de seguridad.

En Bélgica, el Gobierno regional de Flandes ordenó retirar todas sus webs oficiales que utilizaban PHP. Su ministro-presidente, Matthias Diependaele, defendió la decisión señalando que la continuidad y la seguridad de los servicios digitales eran su prioridad.

También se registraron desconexiones en otros países:

• Países Bajos: se desconectaron el sistema de identidad digital DigiD, el portal gubernamental Overheid.nl, MijnOverheid y la web del Puerto de Rotterdam.
• Finlandia: el proveedor estatal de servicios informáticos Valtori suspendió servicios web del Gobierno.
• Alemania: el proveedor tecnológico federal ITZBund retiró temporalmente varios portales públicos.

La Agencia de Seguridad Nacional de Estados Unidos (NSA) también recomendó desconectar temporalmente los sistemas que no pudieran actualizarse de inmediato. En Europa, el NCSC británico y el CERT-EU pidieron identificar los servidores vulnerables e instalar los parches.

Estas desconexiones no significan necesariamente que los sistemas hayan sufrido un ciberataque. Como explicó Dimitrios Salampasis, de la Universidad Tecnológica de Swinburne, apagar una web puede ser una medida preventiva responsable para protegerla mientras se corrigen los fallos.

España también activa las alertas de ciberseguridad

En España, el Instituto Nacional de Ciberseguridad (INCIBE) emitió una alerta de importancia crítica, el máximo nivel de gravedad, ante la posibilidad de que atacantes remotos sin autenticar ejecuten código y tomen el control de servidores web.

El organismo recomienda actualizar cuanto antes y aislar de internet los sistemas vulnerables que no puedan recibir el parche. Por su parte, el Centro Criptológico Nacional (CCN) aconseja apagar los servicios expuestos que no sean imprescindibles.

Las advertencias se recogen en la alerta AL 11/26 del CCN-CERT, publicada el 21 de octubre, y en el aviso del INCIBE sobre PHP, actualizado ese mismo día.

Según Escudo Digital, en España no se produjo un apagón masivo de los portales ministeriales, aunque algunas universidades y administraciones locales realizaron tareas de mantenimiento preventivo. Según Expansión, también quedaron temporalmente inaccesibles determinadas aulas digitales basadas en Moodle.

La inteligencia artificial ayudó a descubrir las vulnerabilidades

La investigación de estos fallos también ha puesto de manifiesto el papel de la inteligencia artificial en el descubrimiento de vulnerabilidades de seguridad.

Según la Fundación PHP, Calif y OpenAI comunicaron por separado el problema de memoria el 11 de agosto. La fundación añade que OpenAI, Wiz y Trail of Bits también encontraron las mismas vulnerabilidades en sus propias auditorías de PHP.

Calif había encontrado el primer fallo durante una auditoría financiada por OpenAI a través de su programa Patch the Planet, utilizando el modelo GPT-5.6 Sol.

Según Expansión, demostrar que los errores podían aprovecharse requería una cadena de acciones muy compleja, y la IA permitió identificar y probar esos escenarios de ataque.

La Fundación PHP reconoce que el problema de memoria ya se había detectado en 2024, durante la primera auditoría externa de seguridad del lenguaje en años: un desarrollador del núcleo lo encontró mientras corregía otro fallo y se planteó un posible ataque, pero no se halló una vía concreta de explotación. El equipo de seguridad barajó varias correcciones alternativas, con costes distintos, y temía publicar una equivocada, por lo que el trabajo se detuvo y se retomó durante meses. La fundación califica este retraso de “fallo estructural” en su proceso de decisión y en sus recursos.

Desde el 1 de julio, la Fundación PHP ha publicado 15 CVE. Para analizar el código, el equipo ha utilizado herramientas de IA, primero Claude Mythos, de Anthropic, y después Daybreak, de OpenAI, para validar los informes recibidos.

Una filtración obligó a adelantar la publicación de los parches

La divulgación de las vulnerabilidades estaba prevista inicialmente para el 22 de octubre, pero una filtración el día 20 precipitó los acontecimientos y el equipo de PHP adelantó las actualizaciones al 21 de octubre.

Según la Fundación PHP, Calif publicó por error un vídeo que mostraba una prueba de concepto funcional. Aunque lo eliminó, ya habían comenzado a circular copias.

La situación se complicó cuando Chainguard publicó el 21 de octubre, a las 07:41 UTC, imágenes de contenedores que incluían las correcciones, más de seis horas antes del lanzamiento coordinado. Esto permitía a posibles atacantes examinar los cambios mientras otros usuarios seguían esperando los parches oficiales.

El consejero delegado de Chainguard, Dan Lorenc, explicó que decidió adelantar su publicación porque, según dijo, ya circulaban exploits, aunque no precisó qué proveedores los habían detectado. También pidió disculpas por la presión adicional que la decisión provocó sobre los responsables de PHP.