El 21 de octubre de 2026 se hicieron públicas dos vulnerabilidades críticas en PHP que podían permitir a un atacante ejecutar código en un servidor web sin necesidad de autenticarse. El Instituto Nacional de Ciberseguridad (INCIBE) calificó la alerta con el máximo nivel de gravedad, 5 sobre 5, y una puntuación de 9,2 sobre 10 en el sistema CVSS 4.0. Además, se habían comunicado ataques antes de que estuvieran disponibles las actualizaciones de seguridad.
El problema no afectaba únicamente a instalaciones antiguas ni a páginas web desactualizadas. Una web con WordPress, PrestaShop o cualquier otra aplicación completamente al día podía seguir siendo vulnerable si la versión de PHP utilizada por su servidor no incorporaba las correcciones necesarias.
La gravedad de estos fallos obligó al equipo de desarrollo de PHP a publicar actualizaciones extraordinarias y recomendar su instalación inmediata. La situación resulta especialmente delicada para las páginas que funcionan sobre versiones antiguas, ya que algunas han dejado de recibir mantenimiento oficial y requieren soluciones específicas para corregir las vulnerabilidades.
Qué ha ocurrido con PHP en octubre de 2026
PHP es uno de los lenguajes de programación más utilizados en el desarrollo de páginas web y aplicaciones dinámicas. Plataformas como WordPress y PrestaShop dependen de él para ejecutar buena parte de sus funcionalidades, desde mostrar contenidos hasta gestionar usuarios, procesar formularios o completar pedidos en una tienda online.
Las vulnerabilidades identificadas, CVE-2026-109618 y CVE-2026-109619, afectan al funcionamiento interno del intérprete PHP y están relacionadas con errores en la gestión de memoria. Aunque ambas pueden permitir la ejecución remota de código, su origen técnico es diferente:
- CVE-2026-109618: afecta al tratamiento de situaciones de agotamiento de memoria. En determinadas circunstancias, PHP puede interrumpir una operación cuando algunas estructuras internas todavía no se han inicializado correctamente, provocando errores durante su posterior liberación.
- CVE-2026-109619: está relacionada con la conservación de información interna entre solicitudes. Determinadas referencias pueden permanecer accesibles después de que la memoria a la que apuntaban haya sido liberada, generando una situación potencialmente aprovechable por un atacante.
Estos fallos son especialmente graves porque afectan al propio intérprete encargado de ejecutar las instrucciones PHP. No dependen necesariamente de un error de programación en la página web ni de que un usuario tenga acceso a su panel de administración.
El equipo oficial de PHP confirmó que las vulnerabilidades podían afectar a diferentes configuraciones utilizadas para procesar solicitudes web, entre ellas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Según el aviso oficial publicado por PHP, el riesgo era especialmente elevado en determinadas configuraciones de Apache con mod_php, donde se había demostrado una vía de explotación capaz de activarse antes de que comenzara a ejecutarse el código de la aplicación.
Por qué estas vulnerabilidades de PHP eran tan peligrosas
Cuando un visitante accede a una página dinámica, el servidor recibe una solicitud y PHP ejecuta las instrucciones necesarias para generar la respuesta. Durante este proceso se realizan operaciones internas que utilizan memoria para almacenar información temporal y gestionar las tareas solicitadas.
Los fallos descubiertos permitían que, bajo determinadas condiciones, estos mecanismos funcionaran incorrectamente. Un atacante que consiguiera aprovecharlos podría llegar a ejecutar instrucciones no autorizadas con los permisos del proceso PHP afectado, sin conocer las contraseñas de WordPress, PrestaShop o del panel de administración.
Las consecuencias de una explotación satisfactoria dependerían de la configuración del servidor, los permisos disponibles y las medidas de aislamiento existentes. Entre los riesgos potenciales se encuentran:
- Acceso a información confidencial: exposición de archivos, configuraciones o datos a los que tenga acceso el proceso comprometido.
- Modificación de archivos: alteración del código de una página web o incorporación de instrucciones maliciosas.
- Compromiso de aplicaciones: posibilidad de manipular funcionalidades o aprovechar los permisos del servicio para realizar operaciones no autorizadas.
- Persistencia del atacante: instalación de mecanismos que permitan conservar el acceso al entorno comprometido, si los permisos disponibles lo permiten.
No significa que todas las páginas que utilizaban una versión vulnerable hayan sufrido estos ataques. Sin embargo, la posibilidad de ejecutar código sin autenticación elevaba considerablemente el riesgo, especialmente en servidores accesibles públicamente.
Por qué actualizar WordPress o PrestaShop no solucionaba el problema
Las vulnerabilidades no se encontraban en WordPress ni en PrestaShop, sino en PHP, una tecnología sobre la que funcionan ambas plataformas.
Por tanto, una tienda online podía tener sus módulos actualizados, utilizar un certificado SSL válido y funcionar correctamente, pero continuar expuesta si su servidor ejecutaba una versión vulnerable de PHP.
Actualizar una aplicación no significa que el entorno en el que se ejecuta también esté actualizado. Una página web depende de diferentes componentes, como el servidor HTTP, PHP, la base de datos y el sistema operativo, que necesitan recibir sus propias correcciones de seguridad.
En este caso, la solución requería actuar sobre PHP. Los cortafuegos, las reglas de seguridad y los mecanismos de protección adicionales podían reducir determinados escenarios de ataque, pero no corregían los errores presentes en el intérprete.
Qué versiones de PHP están afectadas y cuáles incorporan las correcciones
El equipo de desarrollo de PHP publicó el 21 de octubre de 2026 cuatro versiones de seguridad destinadas a corregir las vulnerabilidades CVE-2026-109618 y CVE-2026-109619.
Las instalaciones que utilizan versiones anteriores dentro de estas ramas deben actualizarse a la versión indicada o a una posterior que incorpore las mismas correcciones.
La situación es diferente para PHP 7.4, 8.0 y 8.1, ramas que ya no reciben actualizaciones regulares del proyecto oficial. Ante la gravedad de este incidente, el equipo de PHP también facilitó parches de código fuente para que proveedores y administradores pudieran corregir los fallos en determinados entornos antiguos.
Esto no significa que esas versiones hayan recuperado su mantenimiento oficial. Una instalación de PHP 7.4 puede incorporar los parches de ambas vulnerabilidades y continuar expuesta a otros problemas de seguridad propios de una tecnología obsoleta.
También hay que considerar que PHP 8.2 finalizará su soporte oficial el 31 de diciembre de 2026. Aunque dispone de una versión corregida para este incidente, es recomendable planificar su actualización hacia una rama con un periodo de mantenimiento más amplio.
En servidores Linux existe otra particularidad importante: algunos distribuidores incorporan correcciones de seguridad mediante parches retroportados, sin modificar la numeración principal de PHP. Por eso, no siempre es suficiente con consultar el número de versión; también puede ser necesario revisar las actualizaciones y los registros de cambios del proveedor.
Qué medidas de seguridad deben implementarse para proteger una web
Ante las vulnerabilidades descubiertas, la medida imprescindible es actualizar PHP o instalar paquetes que incorporen las correcciones correspondientes. El equipo oficial de desarrollo ha advertido de que no existen mitigaciones completas capaces de sustituir esta actualización.
No obstante, la seguridad de una página web requiere otras medidas complementarias para limitar la exposición del servidor, controlar posibles comportamientos anómalos y facilitar su recuperación ante una incidencia.
Actualizar PHP y verificar que las correcciones están instaladas
El primer paso consiste en identificar qué versión de PHP utiliza realmente la página web. Esta información puede consultarse desde determinados paneles de alojamiento o solicitarse al proveedor responsable de su administración.
Una vez identificada la versión, hay que comprobar si se han instalado las actualizaciones publicadas el 21 de octubre o si el proveedor ha incorporado los parches correspondientes mediante otro mecanismo.
En un alojamiento compartido, conviene solicitar confirmación expresa de que CVE-2026-109618 y CVE-2026-109619 están corregidas, especialmente cuando la numeración de PHP no coincide con las versiones oficiales publicadas.
También debe verificarse que la página web utiliza realmente el intérprete actualizado. Algunos servidores disponen de varias versiones de PHP instaladas simultáneamente, por lo que actualizar una de ellas no implica necesariamente que todas las aplicaciones estén protegidas.
Revisar la configuración de seguridad del servidor
La configuración del servidor puede influir en las consecuencias de una vulnerabilidad. Limitar los permisos de los procesos, restringir el acceso a archivos sensibles y mantener separadas las aplicaciones contribuye a reducir el alcance de una posible intrusión.
Para este incidente, el equipo de PHP publicó medidas temporales destinadas a dificultar determinadas vías de explotación mientras se realizaban las actualizaciones. Entre ellas se encontraban ajustes relacionados con la gestión de memoria, el procesamiento de solicitudes y algunas funcionalidades vinculadas a la subida de archivos.
Estas modificaciones requieren una evaluación técnica porque pueden afectar al funcionamiento de las aplicaciones. Además, no ofrecen una protección completa y no deben considerarse una alternativa permanente a la instalación de los parches.
También resulta recomendable revisar los permisos de escritura, evitar privilegios innecesarios y mantener mecanismos de aislamiento adecuados cuando varias páginas comparten un mismo servidor.
Implementar un firewall de aplicaciones web y sistemas de monitorización
Un firewall de aplicaciones web (WAF) puede ayudar a detectar y bloquear determinadas solicitudes maliciosas antes de que lleguen a la aplicación. Las restricciones de acceso, la limitación de peticiones y los sistemas de detección de comportamientos anómalos también contribuyen a mejorar la protección del entorno.
Sin embargo, ninguna de estas herramientas garantiza que todos los intentos de explotación sean detectados, especialmente cuando las vulnerabilidades afectan a componentes internos como PHP.
Por eso, la monitorización debe contemplar la revisión de registros de seguridad, modificaciones inesperadas de archivos, comportamientos anómalos y accesos no autorizados.
También es importante disponer de copias de seguridad periódicas, almacenadas de forma independiente y con procedimientos de restauración comprobados. Aunque no evitan una explotación, pueden resultar esenciales para recuperar una página web que haya sufrido alteraciones o pérdida de información.
Mantener actualizados todos los componentes de la web
Corregir las vulnerabilidades de PHP no elimina otros posibles problemas de seguridad. WordPress, PrestaShop, sus plugins, módulos y temas pueden contener fallos independientes que también requieren actualizaciones.
Lo mismo ocurre con el sistema operativo, las bases de datos, el servidor web y las bibliotecas utilizadas por la aplicación.
El mantenimiento debe contemplar estos componentes y prestar especial atención a aquellos que han finalizado su periodo de soporte. También es recomendable eliminar extensiones innecesarias, sustituir complementos abandonados y verificar las compatibilidades antes de introducir actualizaciones importantes.
En las tiendas online, las comprobaciones posteriores deben incluir procesos de compra, pasarelas de pago, integraciones y gestión de usuarios. En las páginas corporativas conviene revisar especialmente los formularios, las áreas privadas y los servicios externos conectados.
Qué ocurre si tu web utiliza una versión de PHP sin soporte
Muchas páginas web continúan utilizando versiones antiguas porque fueron desarrolladas hace años o dependen de módulos y funcionalidades que no son compatibles con las versiones actuales.
Que sigan funcionando no significa que sean seguras. Una versión de PHP sin mantenimiento oficial puede continuar ejecutando una aplicación correctamente mientras acumula vulnerabilidades para las que ya no se publican actualizaciones regulares.
Ante una situación de este tipo, existen alternativas que deben valorarse según las características de cada proyecto.
Algunos proveedores especializados ofrecen mantenimiento extendido y parches retroportados para determinadas versiones antiguas. Esto puede proporcionar una solución temporal, siempre que exista una garantía verificable de que las vulnerabilidades están corregidas y de que el servicio continuará recibiendo actualizaciones.
La alternativa recomendable a largo plazo es migrar hacia una versión de PHP mantenida. Sin embargo, este proceso puede requerir actualizar previamente el CMS, sustituir módulos incompatibles o adaptar desarrollos personalizados.
Por ello, una migración debe planificarse y probarse antes de aplicarse en producción, especialmente cuando afecta a una tienda online o a una aplicación que interviene directamente en la actividad de una empresa.
También es necesario comprobar el estado del sistema operativo del servidor. Mantener PHP actualizado sobre una distribución que ya no recibe correcciones de seguridad puede dejar otros componentes expuestos, aunque el intérprete haya sido parcheado.
Cómo saber si tu página web está protegida frente a estas vulnerabilidades
No siempre es posible identificar desde el exterior qué versión de PHP utiliza una página web. Muchos servidores ocultan correctamente esta información, por lo que las herramientas públicas de detección de tecnologías pueden ofrecer resultados incompletos.
La comprobación más fiable debe realizarse desde el alojamiento o mediante el proveedor responsable de su mantenimiento.
Para verificar el estado de una página web frente a las vulnerabilidades publicadas el 21 de octubre, es necesario confirmar tres aspectos: la versión de PHP realmente utilizada, la incorporación de los parches de seguridad y el estado de soporte de la tecnología instalada.
Si la página utiliza un alojamiento compartido, el proveedor debería poder confirmar qué actualizaciones se han aplicado. En servidores VPS o dedicados, esta revisión corresponde al responsable técnico de la infraestructura.
También conviene comprobar que no existan otras aplicaciones alojadas en el mismo entorno que continúen utilizando versiones vulnerables.
Si la instalación estuvo expuesta antes de recibir las correcciones, actualizar PHP permite solucionar los fallos conocidos, pero no demuestra por sí solo que no haya existido una intrusión anterior. Esta distinción es especialmente importante cuando se ha detectado alguna actividad sospechosa.
¿Qué hacer si sospechas que tu servidor PHP ha sido comprometido?
La explotación de una vulnerabilidad crítica no siempre provoca errores visibles. Una página puede continuar funcionando con normalidad incluso después de que un atacante haya conseguido ejecutar instrucciones no autorizadas.
Algunos indicios que pueden justificar una investigación son la aparición de archivos desconocidos, modificaciones inesperadas del código, nuevos usuarios administrativos, cambios de configuración no autorizados o actividad anómala en los registros del servidor. También pueden observarse comportamientos extraños, redirecciones que no deberían existir o comunicaciones inesperadas con servicios externos.
Estas señales no demuestran por sí solas que las vulnerabilidades de PHP hayan sido explotadas, ya que pueden tener otras causas. Del mismo modo, su ausencia tampoco permite descartar una intrusión.
Cuando existen sospechas razonables, es recomendable solicitar una revisión especializada que permita analizar los registros disponibles, comprobar la integridad de la aplicación y determinar si se han producido accesos no autorizados. Antes de realizar cambios que puedan alterar las evidencias, debe valorarse cómo conservar la información necesaria para investigar lo sucedido.
Si se confirma un compromiso, la respuesta puede requerir contener el acceso del atacante, eliminar los mecanismos de persistencia, revisar credenciales y restaurar componentes afectados desde copias de seguridad verificadas. También será necesario corregir la vulnerabilidad que permitió la intrusión y comprobar que el entorno puede volver a funcionar de forma segura.
Cuando la investigación determine que se han visto afectados datos personales, deberán evaluarse además las obligaciones legales aplicables en materia de protección de datos.
Las actualizaciones publicadas el 21 de octubre de 2026 permiten corregir los dos fallos críticos identificados, pero instalar los parches no elimina automáticamente las modificaciones que un atacante pudiera haber realizado antes de la actualización. Por eso, cuando existen indicios de compromiso, resulta tan importante investigar el estado del servidor como aplicar las correcciones de seguridad.
La información técnica y las recomendaciones oficiales sobre estas vulnerabilidades pueden consultarse en el aviso de seguridad de INCIBE y en el comunicado de seguridad del proyecto PHP.