El ecosistema del desarrollo web ha vivido una de sus semanas más preocupantes en materia de seguridad. El pasado 21 de octubre, el equipo de PHP publicó cuatro actualizaciones urgentes para corregir dos vulnerabilidades críticas que podrían permitir a un atacante ejecutar código de forma remota en servidores vulnerables, incluso sin disponer de usuario ni contraseña.

La gravedad de estos fallos, identificados como CVE-2026-109618 y CVE-2026-109619, ha provocado una respuesta inmediata por parte de desarrolladores, administradores de sistemas, empresas de alojamiento y organismos de ciberseguridad internacionales.

Ambas vulnerabilidades han recibido una puntuación de 9,2 sobre 10 en la escala CVSS 4.0, situándose en la categoría de gravedad crítica.

Pero ¿qué ha ocurrido exactamente? ¿Por qué estos fallos representan una amenaza tan importante? ¿Están en peligro las páginas desarrolladas con WordPress, PrestaShop o Laravel? Y, sobre todo, ¿qué debemos hacer para proteger nuestros proyectos?

Vamos a analizarlo.

¿Qué ha pasado con PHP en octubre de 2026?

Todo comenzó el martes 20 de octubre, cuando el equipo de seguridad de PHP publicó un aviso poco habitual: al día siguiente llegarían actualizaciones extraordinarias destinadas a solucionar dos problemas de seguridad especialmente graves.

El anuncio adelantaba que ambas vulnerabilidades tenían una puntuación CVSS de 9,2 y recomendaba preparar los sistemas para actualizar cuanto antes.

El miércoles 21 de octubre se publicaron los parches correspondientes a cuatro ramas del lenguaje:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Estas versiones incorporan las correcciones necesarias para resolver los dos fallos identificados.

El problema es que no estamos hablando de vulnerabilidades en una plantilla, un plugin o una aplicación concreta.

Estamos hablando de vulnerabilidades en el propio núcleo de PHP, el lenguaje que ejecuta una parte fundamental de las páginas y aplicaciones web de Internet.

Esto significa que incluso un proyecto bien programado, con sus dependencias actualizadas y sin errores conocidos en su código, puede estar expuesto si el servidor utiliza una versión vulnerable de PHP.

La situación llevó al equipo de respuesta a incidentes de ciberseguridad de la Unión Europea, CERT-EU, a emitir una alerta específica y recomendar la actualización inmediata de los sistemas afectados.

Las dos vulnerabilidades que han encendido todas las alarmas

Aunque ambas pueden llegar a permitir ejecución remota de código, sus causas técnicas son diferentes.

CVE-2026-109618: corrupción de memoria cuando PHP se queda sin recursos

La primera vulnerabilidad está relacionada con la forma en que PHP gestiona determinadas situaciones en las que se agota la memoria disponible para una operación.

Normalmente, cuando un proceso alcanza el límite de memoria establecido, PHP interrumpe su ejecución para evitar problemas mayores.

Sin embargo, los investigadores identificaron escenarios en los que esa interrupción puede producirse mientras determinadas estructuras internas todavía no han terminado de inicializarse.

Cuando PHP intenta limpiar los recursos utilizados por una petición, puede acabar trabajando con información de memoria que no se encuentra en un estado válido.

En determinadas circunstancias, un atacante podría aprovechar esta situación para provocar corrupción de memoria y conseguir ejecutar código no autorizado.

Lo especialmente preocupante es que se ha demostrado una vía de explotación remota sin autenticación mediante Apache con mod_php, incluso antes de que se ejecute el código de la aplicación.

Es decir, el problema puede producirse en una fase anterior a la intervención de WordPress, PrestaShop o cualquier otro software desarrollado sobre PHP.

CVE-2026-109619: reutilización de memoria que ya debería haberse liberado

La segunda vulnerabilidad está relacionada con la gestión de información interna entre diferentes peticiones.

PHP utiliza estructuras de memoria para mantener determinados datos necesarios durante la ejecución.

El problema aparece cuando parte de esa información continúa siendo accesible después de que la memoria asociada haya sido liberada.

Si una petición posterior reutiliza el mismo proceso de trabajo, podría acceder a referencias que ya no deberían existir.

Esta clase de error se conoce como use-after-free y puede tener consecuencias importantes para la seguridad.

Dependiendo de la configuración y del comportamiento de la aplicación, un atacante podría manipular las condiciones necesarias para aprovecharlo.

En este caso, se ha demostrado la posibilidad de ejecución remota de código sin autenticación tanto en entornos Apache con mod_php como en PHP-FPM.

Lo importante es entender que estos problemas no dependen necesariamente de que el desarrollador haya cometido un error en su aplicación: afectan al funcionamiento interno del intérprete de PHP.

¿Por qué son tan peligrosas estas vulnerabilidades?

Para comprender la gravedad de la situación hay que detenerse en un concepto: RCE, o ejecución remota de código.

Una vulnerabilidad RCE permite que un atacante consiga ejecutar instrucciones en un sistema desde el exterior.

En función de los permisos del proceso comprometido, la configuración del servidor y las protecciones existentes, las consecuencias pueden incluir:

• Acceso no autorizado a archivos y configuraciones del servidor.
• Lectura o modificación de información sensible.
• Compromiso de credenciales de conexión a bases de datos.
• Alteración de contenidos o funcionalidades de una página web.
• Instalación de código malicioso o puertas traseras.
• Interrupción del servicio y pérdida de disponibilidad.
• Utilización del servidor comprometido como punto de partida para nuevos ataques.

En una tienda online, por ejemplo, un incidente de estas características podría comprometer información comercial, datos de clientes o la integridad del proceso de compra.

En una web corporativa, podría afectar a formularios, información privada o comunicaciones con servicios externos.

Eso no significa que todos los servidores vulnerables vayan a sufrir un ataque ni que todas las configuraciones sean explotables de la misma manera.

Sin embargo, el riesgo potencial es suficientemente elevado como para justificar una actuación inmediata.

Una puntuación de 9,2 sobre 10

El sistema CVSS permite clasificar vulnerabilidades de acuerdo con determinadas características técnicas y su impacto potencial.

En este caso, ambos fallos han recibido una puntuación de 9,2 sobre 10 bajo CVSS 4.0.

La combinación de ejecución remota, ausencia de necesidad de autenticación en los escenarios demostrados y posible impacto sobre la confidencialidad, integridad y disponibilidad del sistema explica la elevada gravedad asignada.

No estamos ante un simple error que pueda mostrar información incorrecta o provocar un fallo visual. Estamos ante problemas capaces de comprometer la seguridad de un servidor.

¿Qué versiones de PHP están afectadas y cuáles son seguras?

El equipo de PHP ha publicado actualizaciones para las ramas que mantienen soporte de seguridad.

Las versiones anteriores a las indicadas dentro de cada rama están afectadas por los fallos publicados.

Existe además una situación especialmente delicada: las instalaciones que utilizan PHP 8.1 o versiones anteriores.

Estas ramas ya no reciben actualizaciones ordinarias de seguridad por parte del proyecto PHP.

Aunque algunos proveedores de sistemas operativos y soporte extendido pueden proporcionar correcciones adaptadas, mantener versiones antiguas sin mantenimiento supone un riesgo considerable.

Por la gravedad del incidente, el equipo de PHP también ha facilitado adaptaciones mínimas del código de corrección para PHP 7.4, 8.0 y 8.1, destinadas especialmente a quienes mantienen compilaciones propias o carecen de un proveedor de soporte extendido.

No obstante, disponer de una corrección excepcional no convierte una versión obsoleta en una opción recomendable a largo plazo.

La mejor estrategia consiste en utilizar una rama de PHP con soporte activo y mantenerla actualizada.

Conviene recordar, además, que una distribución Linux puede incorporar correcciones de seguridad sin modificar necesariamente el número principal de versión mostrado por el sistema. En estos casos es importante comprobar el estado de los paquetes y los avisos del proveedor.

WordPress, PrestaShop, Laravel y otras plataformas: ¿están en peligro?

Esta es una de las preguntas más importantes para propietarios de páginas web, tiendas online y agencias digitales.

PHP es la tecnología sobre la que funcionan numerosos gestores de contenidos, plataformas de comercio electrónico y frameworks.

Entre ellos encontramos WordPress, PrestaShop, Drupal, Magento Open Source, Laravel y Symfony.

El hecho de utilizar cualquiera de estas tecnologías no significa automáticamente que una web haya sido comprometida.

Lo que determina la exposición es, principalmente, la versión real de PHP utilizada por el servidor, las correcciones instaladas y las condiciones técnicas del entorno.

WordPress: actualizar los plugins no es suficiente

En WordPress solemos prestar especial atención a las actualizaciones del núcleo, los plugins y las plantillas.

Sin embargo, PHP es una tecnología independiente que se ejecuta en el servidor.

Podemos tener WordPress completamente actualizado y continuar utilizando una versión vulnerable de PHP.

Esto significa que actualizar WordPress no sustituye a la instalación de los parches del intérprete.

Es necesario revisar también la versión de PHP configurada en el alojamiento y confirmar con el proveedor que incorpora las correcciones de seguridad correspondientes.

PrestaShop: especial atención a las tiendas con versiones antiguas

En el caso de PrestaShop, la situación merece una atención especial.

Muchas tiendas online siguen ejecutándose sobre versiones antiguas del CMS y configuraciones de PHP condicionadas por módulos, personalizaciones o integraciones que llevan años funcionando.

Esto puede dificultar una actualización inmediata.

Cambiar la versión de PHP sin realizar comprobaciones previas puede provocar incompatibilidades con determinados módulos o desarrollos personalizados.

Pero mantener una instalación vulnerable tampoco es una alternativa aceptable.

Lo recomendable es disponer de una copia de seguridad, comprobar los requisitos de compatibilidad, preparar un entorno de pruebas y coordinar la actualización del servidor con las correcciones necesarias en la aplicación.

Cuando el proyecto utiliza una versión de PHP que ya no recibe mantenimiento, debería plantearse una estrategia de modernización.

Laravel, Symfony y los desarrollos personalizados

Los proyectos basados en frameworks modernos tampoco quedan automáticamente protegidos.

Aunque un framework incorpore buenas prácticas de seguridad, estas vulnerabilidades afectan a una capa inferior: el propio entorno de ejecución.

Por tanto, una aplicación Laravel correctamente desarrollada puede estar expuesta si funciona sobre una versión afectada de PHP.

Lo mismo sucede con aplicaciones empresariales, herramientas internas, API y plataformas programadas a medida.

La seguridad debe abordarse en todas las capas, desde el sistema operativo y el servidor web hasta el código de la aplicación y sus dependencias.

¿Qué ocurre si mi web está alojada en un hosting compartido?

En un servidor propio o un VPS administrado, el responsable técnico dispone normalmente de mayor control sobre la instalación y las actualizaciones de PHP.

En un alojamiento compartido, parte de esa responsabilidad corresponde al proveedor de hosting.

Esto no significa que el propietario de la web pueda despreocuparse.

Es importante comprobar qué versión se está ejecutando realmente y si el proveedor ha distribuido los parches.

Algunos alojamientos permiten seleccionar la versión de PHP desde su panel de administración. Otros aplican actualizaciones de seguridad directamente a sus paquetes.

En cualquier caso, conviene solicitar una confirmación específica.

No basta con saber que utilizamos PHP 8.4, por ejemplo. Debemos comprobar que el entorno dispone de la corrección equivalente a PHP 8.4.27 o de un paquete mantenido por el proveedor que incluya esos arreglos.

¿Se están produciendo ataques reales?

La publicación de los parches también ha supuesto la divulgación de información técnica sobre los fallos.

CERT-EU advirtió el 21 de octubre de que ya comenzaban a circular pruebas de concepto, conocidas como PoC.

Estas pruebas permiten demostrar que una vulnerabilidad puede explotarse bajo determinadas condiciones.

Su publicación facilita el trabajo de investigadores y profesionales de seguridad, pero también puede proporcionar información útil a posibles atacantes.

La existencia de pruebas de concepto y la actividad de investigación incrementan la urgencia de actualizar, especialmente en servidores accesibles desde Internet.

No obstante, es importante diferenciar tres conceptos: que exista una vulnerabilidad, que se haya demostrado su explotación y que se haya confirmado un ataque real contra un sistema concreto.

Una instalación vulnerable no debe considerarse comprometida automáticamente.

Aun así, los responsables de sistemas expuestos deberían revisar los registros y señales de actividad anómala, especialmente si han permanecido sin actualizar.

¿Qué hacer para proteger una página web?

La respuesta principal es clara: actualizar PHP a una versión corregida cuanto antes.

No obstante, una actualización debe realizarse con un procedimiento técnico adecuado para reducir los riesgos operativos y comprobar que realmente ha solucionado el problema.

1. Identificar la versión real de PHP

El primer paso consiste en comprobar la versión que utiliza la web.

En muchos hostings puede consultarse desde el panel de control.

En WordPress también es posible obtener esta información desde la sección de salud del sitio.

Si se dispone de acceso al servidor, se pueden utilizar herramientas de administración para consultar las versiones instaladas.

Es importante comprobar la versión utilizada por las peticiones web, porque puede ser diferente de la configurada para ejecutar comandos desde la terminal.

2. Realizar una copia de seguridad

Antes de aplicar cambios en un entorno de producción conviene disponer de una copia actualizada de los archivos, la base de datos y las configuraciones relevantes.

Si el alojamiento permite generar instantáneas del servidor, también pueden resultar útiles.

La copia debe ser recuperable y, preferiblemente, haberse verificado previamente.

3. Aplicar los parches publicados

Una vez identificada la rama de PHP, debe instalarse la versión corregida correspondiente.

En servidores Linux administrados, lo habitual es utilizar los paquetes de seguridad distribuidos por el proveedor del sistema.

En alojamientos compartidos, será necesario utilizar el panel de control o coordinar la intervención con el soporte técnico.

En entornos con contenedores también hay que comprobar las imágenes utilizadas y desplegar nuevamente los servicios afectados.

4. Verificar el funcionamiento de la aplicación

Después de actualizar es necesario revisar las funcionalidades principales de la web.

En una tienda online, por ejemplo, deberíamos comprobar el catálogo, las fichas de producto, el carrito, el proceso de compra, los métodos de pago y las integraciones externas.

En una web corporativa es recomendable revisar formularios, autenticación, panel de administración y funcionalidades personalizadas.

También deben comprobarse los registros de errores del servidor y de PHP.

5. Confirmar que la actualización se ha aplicado correctamente

No es suficiente con iniciar una actualización y darla por finalizada.

Hay que comprobar que el servicio web está utilizando realmente el entorno corregido.

En instalaciones con PHP-FPM, servidores con varios pools o infraestructuras con diferentes nodos, es especialmente importante verificar todos los procesos y servicios afectados.

Los procesos antiguos deben reemplazarse mediante el reinicio o redespliegue correspondiente para que utilicen el código actualizado.

6. Revisar los registros de seguridad

La actualización corrige la vulnerabilidad, pero no permite determinar por sí sola si un atacante ha aprovechado el fallo antes de instalar los parches.

Por eso resulta conveniente revisar accesos sospechosos, errores anómalos, modificaciones inesperadas de archivos y actividad inusual en los procesos del servidor.

Si existen indicios de compromiso, será necesario realizar un análisis de seguridad más profundo y aplicar un procedimiento de respuesta a incidentes.

¿Existen soluciones temporales si no puedo actualizar?

El propio equipo de PHP ha publicado algunas recomendaciones destinadas a reducir la exposición mientras se prepara una actualización.

Estas medidas afectan a configuraciones específicas, como los límites de memoria, el procesamiento de peticiones y determinadas funcionalidades relacionadas con sesiones y carga de archivos.

Sin embargo, hay un detalle fundamental: ninguna de estas medidas constituye una solución completa que sustituya a los parches.

Además, modificar parámetros relacionados con la memoria y el procesamiento de peticiones sin evaluar el entorno puede provocar problemas de disponibilidad o funcionamiento.

Por ese motivo, los cambios temporales deberían ser estudiados por personal técnico con conocimiento de la infraestructura.

Cuando no sea posible corregir una instalación vulnerable de forma inmediata, CERT-EU recomienda considerar el aislamiento de las aplicaciones accesibles desde Internet hasta que se pueda aplicar y verificar la actualización.

La inteligencia artificial y su papel en la investigación de vulnerabilidades

Otro aspecto interesante de este incidente es el papel que ha desempeñado la inteligencia artificial en la investigación de seguridad.

Diversas informaciones publicadas durante estos días relacionan el descubrimiento y análisis de las vulnerabilidades con el uso de herramientas avanzadas de IA.

El desarrollo de estos sistemas está transformando la forma en que se analizan grandes bases de código, se identifican comportamientos inesperados y se investigan posibles fallos de seguridad.

Tareas que anteriormente requerían extensas revisiones manuales pueden beneficiarse ahora de procesos de análisis asistidos.

Sin embargo, esta evolución presenta una doble vertiente.

Por un lado, la inteligencia artificial puede ayudar a descubrir y corregir problemas antes de que sean utilizados maliciosamente.

Por otro, también puede facilitar que determinados actores analicen vulnerabilidades conocidas y desarrollen nuevas técnicas de ataque.

Esto hace todavía más importante la capacidad de respuesta de los equipos responsables del mantenimiento de infraestructuras.

La inteligencia artificial no sustituye a los especialistas en ciberseguridad, pero sí está modificando sus herramientas y sus métodos de trabajo.

Una lección importante: la seguridad no termina en el código de nuestra web

Este incidente vuelve a poner sobre la mesa una realidad que a menudo se pasa por alto.

La seguridad de una página web no depende exclusivamente del CMS, de las contraseñas o de los plugins que tengamos instalados.

También depende del sistema operativo, del servidor web, del intérprete PHP, de las bases de datos, de las bibliotecas utilizadas y de los servicios externos con los que se comunica nuestra aplicación.

Podemos dedicar mucho esfuerzo a desarrollar una web optimizada, rápida, accesible y visualmente atractiva.

Pero si la infraestructura que la ejecuta no recibe mantenimiento, todos esos esfuerzos pueden quedar comprometidos.

Por eso resulta fundamental contar con una estrategia de mantenimiento que contemple revisiones periódicas, actualizaciones, copias de seguridad, monitorización y planes de recuperación.

Y, especialmente, conviene abandonar la idea de que una página web está terminada el día que se publica.

Una web es un sistema vivo que necesita mantenimiento continuo.