Vulnerabilidades críticas en PHP: versiones afectadas y cómo proteger tu web

Dos vulnerabilidades críticas en PHP, CVE-2026-109618 y CVE-2026-109619, pueden permitir a un atacante sin autenticación ejecutar código con los permisos del proceso web. El equipo de PHP publicó los avisos técnicos el 21 de octubre de 2026 y ya existen actualizaciones correctoras. Si tu empresa utiliza PHP, la prioridad es comprobar la versión y los parches del servidor que atiende las peticiones web.

Esta noticia recoge la información verificada a 22 de octubre de 2026. No todas las webs con PHP son automáticamente vulnerables ni una versión afectada demuestra que haya ocurrido un ataque. La exposición depende también de la configuración, la aplicación y las correcciones que haya incorporado el proveedor.

Qué ha pasado con las vulnerabilidades de PHP

Los fallos se encuentran en el núcleo de PHP, el entorno que ejecuta numerosas aplicaciones web, y no en un plugin o un framework concreto. Ambos avisos tienen una severidad crítica, con puntuación CVSS v4.0 de 9,2 sobre 10.

El impacto posible es la ejecución remota de código, conocida como RCE: un atacante podría conseguir que el servidor ejecutara instrucciones con los privilegios del proceso web. Esos permisos determinan qué archivos, credenciales o servicios resultarían accesibles; no debe confundirse esta posibilidad con obtener automáticamente acceso de administrador al sistema completo.

La recomendación central del equipo de PHP es instalar una versión que contenga las correcciones. Las medidas parciales de configuración no sustituyen a los parches. Para una empresa, conviene tratarlo como una revisión prioritaria de infraestructura, aunque la web siga funcionando con normalidad.

CVE-2026-109618: corrupción de memoria al agotarse la memoria

Este fallo afecta a determinadas rutas de procesamiento cuando una asignación de memoria falla y parte del estado de la petición todavía no está correctamente inicializado. Al finalizar la solicitud, PHP puede utilizar ese estado inválido y provocar corrupción de memoria.

El equipo de PHP ha validado ejecución remota sin autenticación en Apache con mod_php, incluso antes de que se ejecute el código de la aplicación. El análisis también considera susceptible a PHP-FPM, aunque el aviso no demuestra un exploit completo para esa ruta concreta. Esta diferencia importa: no todos los entornos tienen una demostración de explotación equivalente.

CVE-2026-109619: estado interno obsoleto entre peticiones

La segunda vulnerabilidad se relaciona con referencias a memoria de una petición anterior que permanecen en un proceso trabajador. Si una petición posterior utiliza ese estado antes de reinicializarlo, puede producirse un uso de memoria ya liberada y, en determinadas condiciones, ejecución de código.

El aviso describe rutas confirmadas en mod_php y PHP-FPM, con condiciones específicas de configuración o comportamiento de la aplicación. Que una web no muestre errores al visitante no permite descartar el problema: ocultar los mensajes de error no equivale a corregir la vulnerabilidad.

Versiones de PHP afectadas y actualizaciones de seguridad

Estas son las versiones correctoras publicadas para las ramas mantenidas según los avisos consultados. Cada comparación se aplica dentro de su propia rama, no entre todas las versiones de PHP.

Si ya hay una versión posterior disponible, comprueba que incluya ambas correcciones y que sea compatible con tu aplicación. La tabla identifica los parches de esta alerta; no garantiza que una versión quede libre de cualquier otro problema de seguridad presente o futuro.

Atención a los paquetes del proveedor: algunas distribuciones Linux y servicios de soporte incorporan parches retroportados sin cambiar el número principal que muestra PHP. Antes de decidir que una instalación es vulnerable, verifica el paquete completo, su revisión y el aviso de seguridad del proveedor. Tampoco basta con que el panel del hosting diga simplemente «PHP 8».

Qué hacer si utilizas PHP 7.4, 8.0 u 8.1

Estas ramas ya no reciben actualizaciones regulares del proyecto PHP. Se han facilitado parches de código fuente para estas vulnerabilidades, pero disponer de un parche no significa que tu hosting lo haya aplicado ni que la rama vuelva a tener soporte regular.

Solicita al proveedor confirmación explícita de las correcciones. Si no puede ofrecer una versión corregida, valora una migración a una rama mantenida y compatible. Cuando existen dependencias antiguas, la modernización de una aplicación legacy debe planificarse con pruebas, no limitarse a cambiar una opción del panel.

Cómo saber si tu web utiliza una versión vulnerable de PHP

La comprobación debe centrarse en el entorno que recibe tráfico real. Un servidor puede tener varias versiones instaladas y asignar una distinta a cada dominio, aplicación o pool de PHP-FPM.

1. Identifica todas las aplicaciones expuestas: web corporativa, tienda online, API, panel de clientes, subdominios y servicios antiguos que sigan publicados.
2. Comprueba la versión web efectiva: revisa el panel del alojamiento y la configuración del servicio que atiende cada aplicación. Si no administras el servidor, pide la información al proveedor.
3. Confirma el paquete y sus parches: solicita la revisión exacta y la confirmación de que cubre los dos CVE.
4. Comprueba todos los nodos: si hay balanceadores, réplicas o varios servidores, actualizar solo uno deja parte del servicio pendiente.

El comando php -v resulta útil para conocer la versión del intérprete de consola, pero no demuestra por sí solo qué versión ejecuta la web. La consola y PHP-FPM pueden utilizar binarios distintos.

Evita publicar un archivo phpinfo() para comprobarlo: expone detalles de configuración que no deberían quedar accesibles. Utiliza información administrativa o una comprobación controlada por el equipo técnico.

¿No sabes qué PHP está ejecutando tu web? En 10Code te ayudamos a revisar el entorno, comprobar los parches y planificar la actualización. Contactar con 10Code para revisar la seguridad de PHP.

¿Afecta a WordPress, Laravel y otras aplicaciones PHP?

Puede afectar al entorno PHP que utilizan estas aplicaciones cuando ejecutan una versión sin corregir y se cumplen las condiciones de exposición. No significa que WordPress o Laravel sean el origen de estas dos vulnerabilidades.

Webs WordPress y tiendas online

Actualizar WordPress, el tema o los plugins no instala necesariamente un parche del intérprete PHP. Son capas diferentes. Comprueba por separado el mantenimiento del CMS y el del servidor.

En una tienda online, valida después los procesos críticos: acceso, carrito, pago, confirmación de pedidos y tareas programadas. El objetivo es corregir la exposición sin introducir fallos operativos por incompatibilidad.

Aplicaciones Laravel y APIs

Actualizar dependencias con Composer tampoco garantiza que el servicio PHP-FPM haya cambiado de versión. Revisa los requisitos del proyecto, extensiones, procesos web y trabajadores de larga duración.

Si necesitas ayuda con compatibilidad o despliegue, nuestro equipo de expertos en Laravel puede ayudarte a revisar la aplicación y su entorno. La actualización debe cubrir tanto la infraestructura que atiende HTTP como los procesos asociados que correspondan.

Desarrollos PHP a medida

Un software propio puede depender de extensiones o comportamientos antiguos. Antes de saltar de rama, identifica esas dependencias y prueba la aplicación. Cuando exista una actualización correctora compatible dentro de la rama actual, puede ser una vía más directa que una migración mayor, siempre que el proveedor mantenga esa rama y confirme los parches.

Cómo actualizar PHP con seguridad en una empresa

No hay una orden universal válida para todos los servidores. La actualización depende del sistema operativo, el proveedor, el modo de ejecución y las necesidades de la aplicación. El procedimiento debe incluir estas comprobaciones:

1. Confirmar exposición y preparar recuperación

Identifica versiones, configuración y aplicaciones afectadas. Verifica una copia de seguridad recuperable y documenta los componentes que vas a modificar. Una copia que nunca se ha probado no garantiza que puedas recuperar el servicio.

2. Elegir una versión corregida compatible

Comprueba requisitos de la aplicación, framework, extensiones y proveedor. Prioriza una versión con las dos correcciones. Si necesitas cambiar de rama, prepara las adaptaciones correspondientes en lugar de asumir compatibilidad automática.

3. Probar los recorridos críticos

Valida el cambio en un entorno de pruebas representativo: autenticación, formularios, cargas de archivos, sesiones, integraciones, cobros y procesos de negocio. Ajusta la profundidad de las pruebas al riesgo del sistema y a la urgencia de protegerlo.

4. Desplegar y renovar los procesos

Aplica el paquete o la versión corregida mediante el procedimiento de tu infraestructura. Reinicia o renueva los procesos pertinentes y verifica que todas las instancias web usan ya el entorno actualizado. Que el paquete esté instalado no demuestra que los trabajadores antiguos hayan dejado de ejecutarse.

5. Verificar el servicio y revisar indicios

Comprueba la versión efectiva, los parches, los errores y la salud de los procesos. Si encuentras actividad sospechosa, trata el caso como un posible incidente: actualizar evita nuevas explotaciones del fallo corregido, pero no elimina por sí solo una intrusión previa.

El plan de recuperación también debe tener en cuenta la seguridad. Volver a una imagen vulnerable puede reabrir la exposición; si no hay alternativa segura, el equipo técnico debe valorar restricciones de acceso o aislamiento mientras resuelve el problema.

Qué hacer si no puedes actualizar PHP inmediatamente

Escala la situación al proveedor o al responsable técnico y evalúa cómo reducir la exposición de los sistemas afectados. Los avisos describen mitigaciones parciales, pero advierten de que no existe una configuración genérica que sustituya todas las correcciones.

No copies ajustes de memoria, sesiones o límites del servidor sin analizar sus consecuencias. Algunos cambios pueden aumentar el consumo de recursos o no cubrir otras rutas vulnerables. Un firewall, un antivirus o un plugin de seguridad tampoco permiten dar por resuelto un fallo del núcleo de PHP.

Si el sistema expuesto no puede corregirse, valora con el equipo técnico limitar su acceso o aislarlo temporalmente. La decisión debe equilibrar continuidad operativa y riesgo, con un plan concreto para instalar los parches.

Preguntas frecuentes sobre las vulnerabilidades de PHP

¿Todas las webs con PHP son vulnerables?

No. Hay que verificar versión, parches del proveedor y condiciones de ejecución. Incluso una instalación vulnerable no debe describirse como comprometida sin evidencias de un ataque.

¿Qué versiones corrigen CVE-2026-109618 y CVE-2026-109619?

Los avisos indican PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12 en sus respectivas ramas. Revisa también versiones posteriores y paquetes con correcciones retroportadas confirmadas por el proveedor.

¿Basta con actualizar WordPress o Laravel?

No. Actualizar el código de la aplicación y actualizar el intérprete PHP son operaciones distintas. Debes comprobar que el entorno web contiene los parches.

¿Un certificado HTTPS protege frente a estos fallos?

No. HTTPS protege el transporte de información entre cliente y servidor, pero no corrige las vulnerabilidades del proceso PHP que atiende las solicitudes.

¿Cómo puedo comprobarlo si no tengo acceso al servidor?

Pide al hosting la versión efectiva para tu dominio, la revisión del paquete y la confirmación de que incluye ambos parches. Si la respuesta no es clara, solicita una revisión técnica antes de dar el caso por cerrado.

¿Actualizar PHP repara una web que ya ha sido atacada?

No necesariamente. Si hay indicios de compromiso, además de actualizar hace falta investigar el alcance, revisar persistencia y credenciales, y recuperar el sistema desde un estado fiable.

Revisa y actualiza PHP con ayuda de 10Code

Si tu empresa no tiene claro qué versión utiliza, depende de una aplicación antigua o necesita coordinar la actualización con su actividad, podemos ayudarte a revisar el entorno y planificar el cambio. No necesitas conocer el CVE para empezar: indícanos qué aplicación utilizas y qué información te ha facilitado tu proveedor.

Contactar con 10Code para revisar y actualizar PHP. Cuéntanos tu caso desde el formulario de contacto y valoraremos cómo ayudarte.

Fuentes técnicas y fecha de revisión

Información revisada el 22 de octubre de 2026. Los detalles y recomendaciones pueden evolucionar; consulta los avisos originales antes de intervenir en un servidor.

• Aviso del equipo PHP: RCE via OOM corruption, GHSA-w8hw-w9fx-j79w.
• Aviso del equipo PHP: RCE via stale global state, GHSA-6wmf-4rv5-p3rp.
• Comunicados oficiales de PHP de 2026.
• Historial oficial de cambios de PHP 8.