Vulnerabilidades críticas de PHP: a quién afectan, qué podría ocurrir y cómo parchear con seguridad

Ilustración de TechiesJournal sobre la idea del artículo. Las dos pilas ejecutan una aplicación actualizada. Solo la capa de PHP de la derecha tiene la corrección, así que solo ella detiene la solicitud.

Dos vulnerabilidades de seguridad críticas en PHP han expuesto sitios web y aplicaciones a una posible ejecución remota de código y a la divulgación de datos sensibles. Investigadores de seguridad han demostrado su explotación y se han observado ataques activos. Esto es lo que las organizaciones deben entender antes de actualizar sus sistemas.

Una aplicación parcheada puede seguir ejecutándose sobre un entorno de ejecución vulnerable

Imagina que tu organización tiene un sitio web para clientes creado con WordPress. Sus plugins están actualizados, los controles de acceso están activados y el equipo de desarrollo corrige con regularidad las debilidades de seguridad de la aplicación. Aun así, el sitio web podría seguir expuesto a un ataque que eluda estas precauciones.

Puede que el problema ni siquiera esté en WordPress. Puede estar en PHP, el software que ejecuta la aplicación y procesa las solicitudes web entrantes.

El 21 de octubre de 2026, el proyecto PHP anunció actualizaciones de seguridad de emergencia para dos vulnerabilidades críticas. Muestran por qué la seguridad de las aplicaciones debe ir más allá del código de la aplicación. Las vulnerabilidades, conocidas en conjunto como PHP2Shell, pueden permitir la ejecución remota de código sin autenticación, lo que significa que un atacante que no ha iniciado sesión puede ejecutar código en el servidor desde internet, o la exposición de información sensible de la memoria del proceso de PHP.

Los dos fallos críticos están en el propio PHP

Las vulnerabilidades se identifican como:

• CVE-2026-109618: Un problema de corrupción de memoria relacionado con la forma en que PHP gestiona los errores de falta de memoria.
• CVE-2026-109619: Un problema por el que el estado interno de una solicitud anterior puede seguir siendo accesible después de que se haya liberado su memoria.

Ambas están calificadas como críticas, con una puntuación CVSS 4.0 de 9.2 sobre 10 (CVSS es la escala estándar de gravedad de las vulnerabilidades) en el aviso previo del equipo de seguridad de PHP.

En el funcionamiento normal, PHP asigna memoria mientras procesa una solicitud y la libera cuando ya no la necesita. Estas vulnerabilidades afectan a situaciones en las que PHP puede intentar usar datos internos que no se han inicializado de forma segura o que ya no pertenecen a memoria válida. En determinadas condiciones, solicitudes web construidas específicamente pueden activar estas debilidades.

Un atacante que logre explotarlas podría ejecutar código con los privilegios del proceso de trabajo (worker) de PHP, acceder a memoria sensible del proceso o interrumpir la aplicación. Son vulnerabilidades del propio PHP, así que una aplicación puede verse afectada aunque su propio código fuente no contenga ningún defecto de seguridad equivalente.

Varios equipos de investigación encontraron los fallos y los mantenedores de PHP los corrigieron

El descubrimiento fue fruto de varios trabajos de investigación de seguridad, unos independientes y otros en colaboración. Wiz Research identifica públicamente a Sagi Tzadik, Shir Tamari, Nir Ohfeld y Tomer Schwartz entre sus investigadores. Su cronología de divulgación publicada indica que su equipo descubrió la primera vulnerabilidad el 19 de agosto de 2026, verificó la ejecución remota de código contra Drupal y WordPress en los días siguientes y comunicó los hallazgos a los mantenedores de PHP el 24 de agosto.

Calif identificó de forma independiente un fallo crítico de PHP en el marco de la iniciativa de seguridad Patch the Planet de OpenAI, usando GPT-5.6 Sol. El informe de divulgación coordinada de OpenAI también atribuye a Wiz el descubrimiento y la notificación independientes de ambas vulnerabilidades. En la divulgación participaron además investigadores y proveedores de seguridad, entre ellos Cloudflare y Quarkslab, y el sitio web de investigación de PHP2Shell reconoce el trabajo de Amy Burnett, de OpenAI, y de Ryan A., de Calif. Fueron los mantenedores de PHP quienes dirigieron las correcciones de seguridad y la publicación de las versiones.

Las herramientas de IA desempeñaron un papel documentado en la investigación. Wiz afirma haber usado Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol. Las pruebas respaldan que se hable de investigación de seguridad asistida por IA, no que se sugiera que un sistema de IA autónomo descubrió, validó y reparó por sí solo todas las vulnerabilidades.

La secuencia también ilustra por qué importa la divulgación coordinada. Los investigadores necesitaban tiempo para trabajar con los mantenedores y los proveedores de seguridad antes de publicar detalles técnicos que los atacantes podrían llegar a aprovechar.

Los sistemas afectados ejecutan un entorno de ejecución de PHP sin parchear

PHP se usa en una parte considerable de la web. Entre el software habitual basado en PHP están WordPress, Drupal, Joomla, Moodle, MediaWiki, Nextcloud y las aplicaciones creadas con Laravel o Symfony. Eso no significa que todas las instalaciones de esos productos sean vulnerables. La pregunta relevante es si el sistema desplegado usa un entorno de ejecución de PHP afectado y si se ha instalado una corrección de seguridad aplicable.

Wiz Research demostró la ejecución remota de código en entornos controlados con WordPress, Drupal y Joomla. Estas demostraciones establecen una explotabilidad creíble en despliegues representativos, pero no prueban que las organizaciones responsables de esos productos sufrieran una vulneración.

El anuncio de seguridad de PHP enumera como entornos de servicio web afectados Apache mod_php (PHP ejecutándose dentro del servidor web Apache), PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera que el riesgo es mayor con mod_php, porque la vía de ataque puede activarse antes de que se ejecute cualquier código de la aplicación. Las vulnerabilidades también pueden afectar a aplicaciones empresariales a medida, sistemas alojados en la nube, imágenes de contenedor y productos que incluyen PHP internamente.

Versiones de PHP parcheadas

La primera versión upstream corregida de cada rama

Rama de PHP	Primera versión upstream corregida
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 y anteriores	Sin versión de seguridad upstream regular, así que revisa los backports del proveedor o migra

La tabla recoge la primera versión corregida de cada rama, según el anuncio de PHP y la alerta del Canadian Cyber Centre. Las versiones anteriores también contienen código afectado. Wiz afirma que todas las versiones de PHP publicadas en la última década están afectadas por al menos uno de los fallos, y Cloudflare describe el problema como uno que afecta a los servidores web que ejecutan PHP 5.4 o posterior.

Algunas distribuciones de Linux y proveedores de soporte a largo plazo pueden incorporar las correcciones necesarias mediante backports sin cambiar el número de versión upstream visible de PHP. Por eso, los administradores deben confirmar el estado del parche con su proveedor de software en lugar de fiarse por completo de php -v. Para PHP 7.4, 8.0 y 8.1, el equipo de seguridad de PHP también proporcionó backports mínimos del código fuente para quienes compilan desde el código fuente o no tienen acceso a un proveedor de soporte a largo plazo. Según el anuncio de PHP, PHP 8.2 llega al fin de su vida útil upstream el 31 de diciembre de 2026, así que las organizaciones que actualicen esa rama también deberían planificar la migración a una versión con soporte.

Los atacantes ya sondeaban PHP2Shell antes de que salieran los parches

Hay pruebas documentadas de intentos activos, incluida actividad anterior a la divulgación pública de las vulnerabilidades. Amazon Threat Intelligence informó de que detectó un intento de explotación de PHP2Shell contra su infraestructura de honeypots MadPot el 17 de octubre de 2026, cuatro días antes de la divulgación pública. El 21 de octubre, AWS observó más intentos con cargas útiles (payloads) e infraestructura distintas, y afirmó que PHP2Shell se estaba explotando ampliamente en entornos reales. AWS también señaló que el análisis técnico seguía en curso y que no estaba claro si alguno de los intentos habría tenido éxito contra sistemas reales.

Cloudflare también informó de tráfico de ataque dirigido a sus clientes durante el periodo de divulgación. Describió cómo los atacantes cambiaban sus payloads para intentar eludir las protecciones que acababa de desplegar. Son hallazgos importantes porque muestran que la amenaza no se limita a una prueba de concepto de laboratorio.

Los informes difieren en cuanto a los plazos. La alerta del Canadian Cyber Centre del 21 de octubre decía que en ese momento no se había identificado ninguna explotación activa, aunque eso podía cambiar rápidamente, mientras que AWS y Cloudflare informaron de tráfico de ataque. Sigue habiendo una diferencia entre detectar un intento de explotación y confirmar que los sistemas de producción de una organización sufrieron una vulneración. En el momento de esta revisión de fuentes, los informes públicos examinados no establecían una lista verificada de organizaciones concretas vulneradas con éxito a través de estas vulnerabilidades. La conclusión adecuada es que se han observado ataques activos, mientras que el número y la identidad de las organizaciones vulneradas con éxito siguen sin estar claros. Las organizaciones no deberían tomar la ausencia de una lista publicada de víctimas como prueba de que sus sistemas están a salvo.

Una explotación con éxito podría llegar mucho más allá del servidor web

Las consecuencias dependen de la configuración vulnerable, la vía de ataque y los privilegios de que disponga el proceso de PHP. Una explotación con éxito puede tener varias consecuencias.

Ejecución de código no autorizada. Un atacante podría ejecutar comandos como la cuenta que ejecuta PHP. Según los permisos de esa cuenta, esto podría permitir modificar archivos del sitio web, instalar código malicioso o acceder a sistemas conectados.

Divulgación de memoria sensible. La memoria del proceso de PHP puede contener tokens de autenticación, contraseñas, claves de API o información de otras solicitudes. Algunas vías de ataque pueden exponer memoria sin lograr antes una ejecución remota de código general.

Interrupción del sitio web. La corrupción de memoria o su agotamiento deliberado pueden hacer que fallen los workers, interrumpir el procesamiento o reducir la disponibilidad del servicio.

Exposición de datos y nuevas vulneraciones. Si un atacante obtiene acceso a credenciales de bases de datos, secretos de la aplicación o integraciones con privilegios, las consecuencias pueden extenderse más allá del servidor web original.

Son resultados posibles, no una prueba de que todas las instalaciones afectadas los hayan sufrido. El daño real depende de la configuración, los permisos, el acceso de red y de que la explotación tenga éxito.

La fuente correcta del parche depende de cómo se instaló PHP

Para las instalaciones de PHP gestionadas directamente, las versiones oficiales y la información de instalación están disponibles en la página de descargas de PHP, el registro de cambios de PHP 8 y, para Windows, windows.php.net. En los servidores Linux, los administradores normalmente deberían obtener las actualizaciones de seguridad a través de la distribución de su sistema operativo o del proveedor de paquetes de PHP de confianza que ya mantiene la instalación.

En los sistemas en contenedores, los equipos deberían seleccionar una imagen base actualizada, oficial o con soporte del proveedor, reconstruir la imagen de la aplicación y desplegar el entorno de ejecución corregido. En el alojamiento gestionado, el alojamiento compartido o los entornos SaaS, puede que sea el proveedor quien controle la actualización, así que los clientes deberían obtener confirmación de que el entorno de ejecución de PHP afectado se ha parcheado.

No descargues binarios de parches no oficiales solo porque afirmen resolver PHP2Shell. Verifica el origen, la información de la versión y la integridad del paquete.

Una actualización segura empieza por un inventario

El proceso de remediación debería empezar con un inventario, no con un cambio inmediato y sin verificar en producción. Primero, identifica dónde se ejecuta PHP, incluidos los sitios web públicos, las API, las aplicaciones internas, los contenedores de aplicaciones, las máquinas virtuales, los paneles de alojamiento web y los appliances de terceros. Después, determina la versión de PHP instalada, el proveedor que la suministra y si incluye la corrección de seguridad necesaria.

Prioriza los sistemas expuestos a internet. El equipo de seguridad de PHP enumera ajustes que reducen la exposición a vías de ataque concretas, pero advierte de que no hacen segura una instalación y de que solo una actualización es una solución completa. Instalar un entorno de ejecución corregido es, por tanto, el remedio necesario. Antes de modificar sistemas de producción, conserva las configuraciones necesarias, haz copias de seguridad verificadas y registra el estado actual del despliegue.

Aplica los paquetes actualizados o despliega nuevas imágenes de contenedor mediante el proceso de gestión adecuado. Reinicia o sustituye los procesos worker de PHP para que el código corregido se esté ejecutando realmente. Por último, verifica la versión de PHP o el estado del parche del proveedor desde el entorno operativo, confirma que la aplicación funciona e investiga los registros (logs) pertinentes en busca de indicios de explotación.

Un paquete actualizado en el disco no basta si el servicio en ejecución sigue usando el proceso de PHP antiguo.

Las actualizaciones dentro de la misma rama conllevan el menor riesgo de compatibilidad

Para una aplicación que ya usa una rama de PHP con soporte, aplicar la versión de parche corregida dentro de esa misma rama supondrá por lo general menos riesgo de compatibilidad que pasar de inmediato a una versión mayor o menor más reciente de PHP. Menos riesgo no significa riesgo cero. Las versiones de seguridad incluyen cambios en el comportamiento interno del entorno de ejecución de PHP, y los registros de cambios de las versiones pueden incluir otras correcciones de errores. Las aplicaciones que dependen de extensiones concretas, funcionalidades heredadas o comportamientos poco habituales del entorno de ejecución pueden requerir pruebas.

Los administradores deberían revisar varias áreas antes de dar por buena la actualización.

Funcionalidad de la aplicación. Verifica el inicio de sesión, la autenticación, las transacciones de negocio importantes, los endpoints de API, las subidas de archivos, las tareas en segundo plano y las interacciones con la base de datos.

Extensiones de PHP. Confirma que extensiones como los controladores de bases de datos, los módulos de caché, las bibliotecas de procesamiento de imágenes y los módulos binarios de terceros siguen disponibles y son compatibles.

Sesiones y procesamiento de solicitudes. Como las vulnerabilidades implican estado relacionado con las solicitudes, prueba el comportamiento de las sesiones, las subidas de archivos y la gestión de solicitudes en las aplicaciones que dependen mucho de ellos.

Contenedores e infraestructura. Confirma que las imágenes reconstruidas incluyen la versión de PHP corregida y que los servicios desplegados usan realmente esas imágenes.

Rendimiento y estabilidad. Vigila los errores de la aplicación, las caídas de los workers de PHP, el uso de memoria, la latencia y la disponibilidad del servicio después del despliegue.

Los cambios en producción deberían seguir un procedimiento de despliegue o mantenimiento controlado, con monitorización y un plan de recuperación. Si la aplicación falla después de actualizar, volver a un entorno de ejecución afectado y exponerlo públicamente no es una solución permanente segura. En su lugar, el equipo debería resolver el problema de compatibilidad, usar un paquete con soporte corregido por el proveedor o aislar el sistema mientras continúa la remediación.

Ninguna prueba creíble de las fuentes revisadas establece que estas versiones de seguridad de PHP en concreto causen en general fallos de aplicaciones o una degradación sustancial del rendimiento en los despliegues existentes. Cualquier afirmación sobre una regresión concreta debería respaldarse con notas de la versión, pruebas reproducibles o un incidente documentado por el proveedor.

Un parche cierra el agujero, pero no elimina una vulneración ya existente

Una actualización de seguridad cierra la vía de la vulnerabilidad afectada. No elimina automáticamente los archivos maliciosos, ni deshace los cambios no autorizados, ni revoca las credenciales robadas, ni demuestra que la actividad anterior fuera inofensiva. Como se observaron intentos de explotación antes de la divulgación pública, las organizaciones con sistemas expuestos previamente deberían revisar sus pruebas de seguridad. AWS aconseja empezar estas investigaciones, como mínimo, desde el 17 de octubre, no desde la fecha de divulgación. El artículo relacionado de TechiesJournal «Con parches» no significa «limpio» (en inglés) trata el problema de la recuperación con más detalle.

Los equipos de seguridad pueden investigar errores de memoria de PHP inusuales, salidas anómalas de workers, procesos hijo inesperados, archivos de la aplicación modificados, conexiones salientes sospechosas y solicitudes HTTP inusuales. Una alerta o una solicitud sospechosa no son, por sí solas, prueba de una vulneración, así que los hallazgos deben investigarse en contexto y correlacionarse con otras pruebas disponibles.

Cuando se ha confirmado una vulneración o hay sospechas razonables de ella, la respuesta puede requerir aislamiento, conservación de pruebas, rotación de credenciales, reconstrucción de los sistemas afectados y una investigación del incidente.

Las reglas de firewall y CDN reducen la exposición, pero no sustituyen al parche

Proveedores de seguridad como Cloudflare desplegaron protecciones frente a patrones de ataque conocidos de PHP2Shell. Cloudflare afirma que sus clientes del firewall de aplicaciones web (WAF), tanto gratuitos como de pago, estaban protegidos de forma predeterminada desde las 3:02 a. m. UTC del 21 de octubre, unas nueve horas antes de la divulgación pública. Estas protecciones pueden ayudar a reducir la exposición mientras las organizaciones instalan las actualizaciones necesarias.

Sin embargo, las reglas de un WAF no garantizan que se bloqueen todas las vías de explotación posibles. Los atacantes pueden modificar las solicitudes, descubrir técnicas alternativas o llegar a los sistemas por rutas que esquiven la capa de protección, y la propia Cloudflare observó a atacantes cambiando sus payloads. Por eso, las reglas de firewall deben tratarse como controles defensivos adicionales, no como sustitutos de la corrección del entorno de ejecución de PHP.

La lección va más allá de PHP

PHP2Shell ilustra un problema de seguridad que va más allá de PHP. Las aplicaciones modernas dependen de capas de software que los equipos de desarrollo quizá no mantengan directamente. Una aplicación puede seguir buenas prácticas de seguridad y, aun así, depender de un entorno de ejecución, un sistema operativo, una biblioteca o un componente de alojamiento vulnerables. Eso genera responsabilidades en los equipos de desarrollo, operaciones, infraestructura y seguridad.

Las organizaciones necesitan saber qué software se está ejecutando, de dónde procede, quién lo mantiene y con qué rapidez puede llegar a producción una actualización de seguridad verificada. En el caso de PHP2Shell, las prioridades inmediatas son identificar los sistemas afectados, instalar correcciones verificadas, confirmar que funciona el entorno de ejecución corregido e investigar una posible vulneración.

La lección más amplia es que proteger el código de la aplicación es esencial, pero no sustituye a proteger el software que lo ejecuta.

Para profundizar

Investigación revisada el 22 de octubre de 2026. La actividad de las amenazas, la disponibilidad de parches y las recomendaciones de los proveedores pueden cambiar rápidamente, así que consulta las fuentes primarias antes de actuar.

Fuentes de proveedores, gobiernos e investigación

• PHP Security Team, anuncio oficial de seguridad, 21 de octubre de 2026, la fuente de las correcciones de seguridad, los entornos de ejecución afectados y las recomendaciones oficiales de actualización.
• Canadian Centre for Cyber Security, AL26-026, 21 de octubre de 2026, evaluación del Gobierno de Canadá y medidas recomendadas.
• Wiz Research, investigación sobre PHP2Shell, 21 de octubre de 2026, historia del descubrimiento, investigación técnica y demostraciones controladas.
• OpenAI, divulgación coordinada de vulnerabilidades críticas, 21 de octubre de 2026, descubrimiento independiente, investigación asistida por IA y coordinación de la respuesta.
• PHP2Shell, recurso de investigación conjunto, créditos de la investigación, resumen técnico y alcance de las demostraciones.

Ataques observados y protecciones

• AWS Security Blog, primeros intentos de explotación, 21 de octubre de 2026, pruebas de los ataques observados, incluida actividad anterior a la divulgación.
• Cloudflare, mitigaciones de PHP2Shell, 21 de octubre de 2026, tráfico malicioso observado y despliegue de controles de protección.

Cómo obtener la corrección

• Descargas e instalación de PHP, recursos oficiales de descarga e instalación.
• Registro de cambios de PHP 8, cambios detallados de cada versión para revisar la compatibilidad y posibles regresiones.

Las organizaciones que evalúen una posible exposición deberían consultar los avisos actuales de los proveedores y sus propios procedimientos de respuesta a incidentes. Los informes públicos revisados no establecen que todas las instalaciones se hayan visto vulneradas.

Lecturas relacionadas en TechiesJournal

• «Con parches» no significa «limpio»: qué hacer tras corregir un dispositivo perimetral explotado (en inglés), TechiesJournal, octubre de 2026, por qué corregir una vulnerabilidad no elimina automáticamente una vulneración ya existente.
• Cuando una aplicación en la nube de confianza se convierte en una vía de ataque (en inglés), para otro caso en el que un componente de confianza, y no el propio código de los defensores, se convirtió en la vía de entrada.