Procesando…
Web y ciberseguridad
Dos fallos críticos afectan al propio motor PHP. Aquí explicamos sus mecanismos, las versiones vulnerables, los sistemas expuestos y los pasos que debes seguir para corregir y comprobar tus aplicaciones.
El 21 de octubre de 2026, el equipo de seguridad de PHP publicó cuatro versiones correctivas para dos vulnerabilidades críticas del motor: CVE-2026-109618 y CVE-2026-109619, también conocidas como PHP2Shell. En determinadas configuraciones, podrían permitir que un atacante no autenticado ejecute código en un servidor web.
El problema va más allá de un CMS, un framework o un proveedor de alojamiento: afecta al motor PHP del lado del servidor. Tanto si ejecuta WordPress, Drupal, PrestaShop, Laravel, Symfony o una aplicación desarrollada a medida, cualquier sitio que utilice una versión vulnerable debe evaluarse y corregirse. El nivel real de exposición dependerá después de la configuración, los procesos PHP y los accesos de red.
9,2/10 (CVSS v4.0) para cada vulnerabilidad. Las versiones corregidas de PHP publicadas el 21 de octubre de 2026 son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. No existe una solución provisional completa: solo la aplicación de una corrección adecuada cubre todas las vías de explotación conocidas.
El 20 de octubre, el equipo de PHP anunció una publicación urgente de seguridad. El 21 de octubre, publicó las correcciones y dio a conocer los detalles técnicos. CERT-FR y CERT-EU recomiendan una remediación inmediata, e incluso aislar los servicios expuestos a Internet cuando no sea posible aplicar una corrección rápidamente.
Las dos vulnerabilidades pertenecen a la categoría RCE (Remote Code Execution, o ejecución remota de código). A diferencia de un error que afecta a una extensión concreta de WordPress o a una página de una aplicación, estas vulnerabilidades se encuentran dentro del runtime de PHP, que interviene en el procesamiento de solicitudes HTTP, formularios, memoria y estado de los procesos.
«Sin autenticación» no significa «compromiso automático». El ataque no requiere necesariamente una cuenta de usuario, pero su viabilidad varía según el modo de ejecución y la configuración. La gravedad reside en el potencial de acceder al sistema antes de que los controles habituales de la aplicación puedan actuar.
Los defectos tienen algo en común: se utilizan datos internos cuando su estado en memoria ya no es fiable. Sin embargo, explotan dos mecanismos distintos.
Cuando se alcanza un límite de memoria (out-of-memory u OOM), PHP utilizaba una salida abrupta basada en longjmp(). Si la interrupción se produce durante la inicialización de estructuras vinculadas a una solicitud, el proceso de limpieza posterior puede interpretar datos incompletos como si fueran válidos. Esta corrupción puede abrir la puerta a la ejecución de código.
Algunos estados globales (errores, sesiones, extensiones u objetos) pueden conservar una referencia a una zona de memoria que ya se ha liberado. Si el mismo proceso PHP atiende después otra solicitud antes de reinicializar ese estado, puede reutilizar la referencia obsoleta. Se trata de un defecto de tipo use-after-free.
En el primer fallo, el procesamiento de ciertas solicitudes multipart, como las que se utilizan para formularios y archivos enviados al servidor, puede provocar una presión inesperada sobre la memoria. En el segundo, un error fatal o ciertos diagnósticos pueden dejar un estado que se utilizará en una solicitud posterior. Los avisos técnicos de PHP detallan estas categorías de escenarios, aunque no siempre es necesario que haya un formulario vulnerable en el código de la aplicación.
Para Apache con mod_php, el equipo de PHP considera que el riesgo es especialmente elevado: una demostración muestra que una solicitud no autenticada puede alcanzar la vía vulnerable antes de que se ejecute el código de la aplicación. PHP-FPM tampoco está fuera de peligro: el procesamiento de errores y las vías de explotación son distintos, pero PHP también lo incluye entre los entornos afectados.
Una explotación satisfactoria puede permitir actuar con los privilegios del proceso PHP: leer archivos a los que tenga acceso el servicio, obtener secretos de la aplicación, comprometer una base de datos si se dispone de sus credenciales, modificar contenido o interrumpir el servicio. El alcance de las consecuencias depende de los permisos, el aislamiento y la arquitectura del servidor.
El ámbito afectado no se limita a los sitios que muestran visiblemente «PHP». Una aplicación puede utilizar PHP detrás de un proxy, una CDN, un contenedor o una plataforma gestionada. CERT-EU cita las principales interfaces web que ejecutan PHP: mod_php, PHP-FPM, php-cgi, FrankenPHP y LiteSpeed.
| Entorno | Qué comprobar |
|---|---|
| WordPress, Drupal, PrestaShop, Magento | El runtime PHP real del servidor, independientemente de la versión del CMS |
| Symfony, Laravel, aplicación PHP personalizada | El runtime de las instancias web, las API, los workers y los despliegues afectados |
| Apache + mod_php | Actualización prioritaria: la vía crítica puede activarse antes de que se ejecute el código de la aplicación |
| Nginx + PHP-FPM, php-cgi, LiteSpeed, FrankenPHP | Versión del runtime que realmente cargan los procesos del servicio |
| Docker, Kubernetes, imágenes CI/CD | Imagen base, contenedores efectivamente redesplegados y réplicas que aún estén activas |
| Alojamiento compartido o plataforma gestionada | Versión corregida o parche retroportado confirmado por el operador |
Importante: actualizar WordPress, una extensión o una dependencia de Composer no corrige el motor PHP. A la inversa, un sitio con código de aplicación bien escrito puede seguir expuesto si su intérprete no ha recibido la corrección.
CERT-FR considera afectadas las ramas antiguas y todas las versiones anteriores a las siguientes versiones corregidas:
| Rama | Versiones que deben corregirse | Versión correctiva de PHP |
|---|---|---|
| PHP 8.5 | 8.5.0 a 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.0 a 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.0 a 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.0 a 8.2.34 | 8.2.35 |
| PHP 8.1 y anteriores | Ramas sin soporte oficial | Hay que comprobar si el proveedor ofrece una migración o un parche retroportado |
El proyecto PHP ya no publica versiones oficiales para PHP 8.1 ni para las ramas anteriores. No obstante, algunos proveedores de Linux y servicios de soporte de larga duración ofrecen parches retroportados, sin cambiar de versión mayor o menor. Por tanto, un número de versión antiguo no demuestra por sí solo que falte la corrección: hay que consultar los boletines de la distribución y el estado del paquete instalado.
PHP también ha proporcionado retroportaciones mínimas de código fuente para las ramas 7.4, 8.0 y 8.1; esto no significa que vuelvan a contar con soporte estándar. PHP 8.2 llega al final de su ciclo de vida el 31 de diciembre de 2026: lo ideal es acompañar la corrección inmediata con un plan de migración.
Un problema habitual es comprobar la versión de PHP equivocada. En una misma máquina, la versión que se ejecuta en el terminal puede diferir de la que utilizan Apache, PHP-FPM, un contenedor o un subdominio. Por tanto, la verificación debe centrarse en el servicio web que está realmente en producción.
Inventariar los dominios, las API, los pools de PHP-FPM, las versiones de los paquetes, las imágenes de contenedor y las tareas en segundo plano. Comprobar las versiones efectivas mediante la administración de la plataforma, los comandos del sistema o una comprobación temporal protegida desde la aplicación.
Comparar la información con el aviso de PHP o el boletín del proveedor. Tras aplicar la corrección, comprobar que se hayan reiniciado los servicios o desplegado los nuevos contenedores. Confirmar que ningún worker antiguo siga recibiendo tráfico.
Algunos comandos de diagnóstico, que deben adaptarse al sistema:
php -v
php --iniphp -v y php --ini describen el entorno CLI, no necesariamente el que procesa las solicitudes HTTP. Para PHP-FPM, comprueba el binario del pool correspondiente, sus archivos de configuración y el servicio que se está ejecutando. En Docker o Kubernetes, comprueba tanto la imagen reconstruida como los contenedores o pods activos. No dejes nunca una página phpinfo() accesible públicamente para realizar esta comprobación.
mod_php y las aplicaciones que contengan datos sensibles.Si existen indicios sólidos de compromiso, una actualización no elimina necesariamente un acceso malicioso ya obtenido. En ese caso, hay que aislar el sistema afectado, preservar los registros, examinar los archivos y secretos expuestos y aplicar un procedimiento de respuesta a incidentes adecuado.
PHP insiste en este punto: ninguna medida provisional ofrece una protección completa. CERT-EU recomienda considerar el aislamiento temporal de los servicios públicos cuya corrección no pueda aplicarse y verificarse.
Las reglas de WAF, la limitación de solicitudes multipart o la desactivación de ciertas funciones pueden reducir la exposición a escenarios documentados, pero no eliminan las dos vulnerabilidades. Además, algunas protecciones pueden bloquear formularios o cargas legítimas de archivos: evalúa sus consecuencias antes de implementarlas.
A modo de ejemplo, CERT-FR menciona desactivar el seguimiento del progreso de las cargas de sesión mediante session.upload_progress.enabled=Off y, según el caso, filtrar el tráfico multipart. El proyecto PHP también cita ajustes de memory_limit para limitar algunas vías del primer fallo. Estas medidas son parciales y, en ocasiones, difíciles de aplicar de forma segura: debe decidirlas el administrador responsable, verificarse en todos los procesos y retirarse o reevaluarse después de instalar las correcciones.
No concluyas que no hay riesgo simplemente porque haya un WAF activo, un escáner externo no detecte nada o los errores de PHP no aparezcan en el navegador. Ninguno de estos indicios demuestra que se haya corregido la memoria del runtime.
No necesariamente. WordPress y sus extensiones son componentes distintos del motor PHP. Hay que actualizar cada uno de estos niveles y, en particular, comprobar la versión de PHP que realmente utiliza el sitio.
La vía de explotación demostrada con mod_php resulta especialmente preocupante, pero PHP también incluye PHP-FPM entre los entornos que deben corregirse. El nivel de riesgo varía según la arquitectura; no debe confundirse «menos directamente demostrado» con «no vulnerable».
El operador suele gestionar el motor PHP, pero las responsabilidades dependen del contrato y del servicio contratado. Pide confirmación de que se haya aplicado la corrección, consulta los avisos de mantenimiento y realiza pruebas funcionales en tu sitio.
No, si PHP está incluido en las imágenes de la aplicación. Hay que reconstruirlas a partir de una imagen base corregida, redesplegar todas las réplicas y comprobar que no quede ninguna instancia antigua en producción.
El 21 de octubre, CERT-EU indicó que circulaban públicamente pruebas de concepto, lo que aumenta la probabilidad de ataques. Esto no permite afirmar que un sitio concreto haya sido comprometido. Para los servicios expuestos, la prioridad sigue siendo aplicar rápidamente la corrección y vigilar los registros.
Es un paso, no una prueba definitiva. Hay que comprobar que se utiliza la fuente de paquetes adecuada, que se han actualizado todas las instancias, que los procesos se han reiniciado correctamente y que la aplicación funciona después del despliegue.
PHP2Shell recuerda una realidad que suele pasarse por alto: la seguridad de un sitio no depende únicamente de la calidad del código de la aplicación, de las extensiones instaladas o del framework. También depende del motor que ejecuta ese código, de la gestión de su memoria y de la disciplina con que se actualizan los entornos de producción.
La estrategia adecuada es concreta: inventariar, corregir, redesplegar, verificar y supervisar. Las organizaciones que no puedan aplicar rápidamente las correcciones deben decidir expresamente si mantienen sus servicios expuestos a Internet.
Artículo basado en los boletines públicos del 21 de octubre de 2026. Los mantenedores y proveedores de las distribuciones pueden ampliar las instrucciones de remediación.
WEB Y CIBERSEGURIDAD
La auditoría del código, las dependencias y las rutas sensibles convierte una alerta técnica en un plan de acción controlado.
Introduce al menos 2 caracteres para iniciar la búsqueda.