La agencia estadounidense confirma ataques que permiten ejecutar código a distancia sin autenticación. Más de 32 millones de servicios PHP podrían seguir expuestos, mientras las empresas afrontan una carrera para instalar los parches.
Dos vulnerabilidades críticas han pasado de ser un problema técnico a una amenaza de seguridad confirmada. La Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) ha confirmado la explotación activa de dos fallos de PHP, un lenguaje utilizado en buena parte de las páginas web del mundo.
El riesgo es especialmente grave porque los atacantes pueden aprovechar los errores para ejecutar código de forma remota sin necesidad de autenticarse en los sistemas afectados. La alerta llega después de que investigadores detectaran ataques contra sistemas señuelo diseñados para registrar la actividad de los ciberdelincuentes.
Las vulnerabilidades, identificadas como CVE-2026-109618 y CVE-2026-109619, tienen una puntuación de 9,2 sobre 10 en el sistema CVSS. Aunque ya existen versiones corregidas, millones de servicios podrían continuar utilizando software vulnerable.
CISA confirma ataques contra las vulnerabilidades PHP2Shell
CISA incorporó el lunes 26 de octubre de 2026 las dos vulnerabilidades al catálogo de Vulnerabilidades Explotadas Conocidas, conocido como KEV. Esta lista recoge fallos para los que existe evidencia de explotación real y sirve como referencia para priorizar las tareas de ciberseguridad.
La inclusión en el catálogo no significa que todos los sistemas vulnerables hayan sido atacados ni que exista una intrusión generalizada. Sí indica que el riesgo ha dejado de ser una posibilidad teórica: hay evidencias de que los fallos están siendo utilizados para ejecutar ataques.
Las dos vulnerabilidades afectan a PHP y permiten la ejecución remota de código sin autenticación en las implementaciones vulnerables. Esta capacidad puede abrir la puerta a que un atacante ejecute instrucciones en el servidor sin disponer previamente de una cuenta legítima.
El impacto concreto dependerá de la configuración del sistema, los permisos del proceso PHP, las medidas de aislamiento y los servicios que se ejecuten en el servidor. Sin embargo, la combinación de explotación activa y ejecución remota justifica una respuesta prioritaria por parte de los administradores.
Qué son las vulnerabilidades CVE-2026-109618 y CVE-2026-109619
Los dos fallos identificados como PHP2Shell tienen mecanismos diferentes, aunque comparten una consecuencia de alto riesgo: pueden facilitar la ejecución remota de código en sistemas afectados.
- CVE-2026-109618: vulnerabilidad relacionada con una corrupción de memoria por falta de memoria, según la descripción facilitada.
- CVE-2026-109619: fallo asociado a un estado obsoleto de una solicitud interna, también capaz de facilitar la ejecución remota de código sin autenticación.
Ambas reciben una puntuación de 9,2 sobre 10 en CVSS, una escala utilizada para evaluar la gravedad de las vulnerabilidades informáticas. La puntuación no mide por sí sola cuántos sistemas han sido comprometidos, pero sí ayuda a determinar la prioridad de las correcciones.
La ejecución remota de código es una de las capacidades más peligrosas en el ámbito de la seguridad informática. Si un atacante consigue aprovecharla, puede ejecutar instrucciones en el sistema afectado con los permisos disponibles para el proceso vulnerable. En función de esos permisos y de las defensas existentes, el incidente podría derivar en acceso no autorizado a datos, alteración de archivos o nuevas acciones contra la infraestructura.
La ausencia de autenticación previa agrava el escenario, ya que elimina la necesidad de superar primero un proceso normal de inicio de sesión. Eso no significa que cualquier servidor pueda ser comprometido automáticamente: la explotación depende de que la instalación y las condiciones técnicas sean compatibles con el fallo.
Un investigador detectó ejecución de código en sistemas señuelo
La confirmación de la explotación llegó después de que Adel Karimi, responsable de detección y respuesta en Perplexity, comunicara el 24 de octubre de 2026 la detección de casos de ejecución remota de código contra sistemas honeypot.
Un honeypot es un sistema señuelo diseñado para atraer o registrar actividad maliciosa. Su finalidad es ayudar a los investigadores a observar las técnicas empleadas por los atacantes sin exponer necesariamente un sistema de producción real.
Según Karimi, la evidencia observada iba más allá de un fallo seguido de actividad sospechosa. El investigador afirmó haber detectado ejecución remota de código acompañada de una divulgación de memoria aprovechable.
La actividad registrada incluía un volcado de cookies decodificado de aproximadamente 800 KiB. Karimi también señaló que una dirección de función derivada de ese volcado, utilizando desplazamientos del exploit público, aparecía en la carga útil de ejecución posterior.
Estos elementos apuntan a una cadena de explotación técnicamente relevante, pero el propio investigador introdujo una limitación importante: las pruebas se obtuvieron en una configuración de mod_php con un solo trabajador, elegida expresamente por ser favorable para el ataque.
Por tanto, los resultados no demuestran que el exploit funcione con la misma fiabilidad en todas las configuraciones, versiones compiladas de PHP o aplicaciones. La advertencia evita extrapolar una prueba concreta a toda la infraestructura mundial que utiliza el lenguaje.
Más de 32 millones de servicios PHP podrían seguir expuestos
PHP, acrónimo de PHP: Hypertext Preprocessor, es un lenguaje de programación ejecutado en el servidor y utilizado para generar páginas web dinámicas y gestionar buena parte de la lógica de numerosas aplicaciones.
La información facilitada atribuye a PHP una presencia cercana al 70 % de los sitios web de internet. Además, las estimaciones de Censys citadas en el texto original apuntan a que más de 32,51 millones de servicios PHP todavía podrían utilizar versiones afectadas.
Esta cifra debe interpretarse con cautela. No equivale a 32,51 millones de servidores confirmados como vulnerables y accesibles desde internet, ni demuestra que todos sean explotables mediante las mismas técnicas. Para determinar la exposición real es necesario conocer las versiones instaladas, las configuraciones, los componentes utilizados y si se han aplicado las correcciones correspondientes.
Aun así, la magnitud potencial de la infraestructura afectada explica la preocupación de los equipos de seguridad. PHP está presente en sistemas empresariales, gestores de contenidos, aplicaciones web y servicios que pueden permanecer activos durante años sin recibir una revisión adecuada.
En entornos corporativos, el problema no se limita a actualizar una versión del lenguaje. Los administradores deben comprobar también las dependencias, las extensiones instaladas, las imágenes de contenedores, los servidores secundarios y los sistemas que no reciben mantenimiento habitual.
Una actualización disponible no protege por sí sola a una organización: la corrección debe instalarse en todos los sistemas afectados y verificarse después.
Las versiones de PHP que corrigen los fallos
Las vulnerabilidades PHP2Shell se corrigieron en las siguientes versiones, publicadas el 21 de octubre de 2026, según la información proporcionada:
| Rama de PHP | Versión 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 |
Los responsables técnicos deben comprobar qué versión está instalada en cada entorno y actualizarla a una versión corregida compatible con su aplicación. También deben revisar si el proveedor de su sistema operativo o plataforma distribuye paquetes propios con las correcciones incorporadas.
En el caso de las agencias federales estadounidenses, la alerta de CISA establece el 29 de octubre de 2026 como fecha límite para aplicar las medidas necesarias. Ese plazo corresponde a las obligaciones señaladas para las agencias federales de Estados Unidos y no debe interpretarse automáticamente como una fecha legal equivalente para todas las empresas españolas o europeas.
Las organizaciones privadas deben atender a sus obligaciones regulatorias, las instrucciones de sus proveedores y sus propios procedimientos de gestión de vulnerabilidades. Ante una vulnerabilidad con explotación confirmada, dejar la actualización para una ventana de mantenimiento lejana puede aumentar innecesariamente el riesgo.
Las empresas tecnológicas también han activado sus alertas
La gravedad de los fallos ha provocado advertencias de fabricantes, proveedores de software y organismos de seguridad. La relación recogida en la información original incluye compañías y proyectos de sectores muy distintos, desde infraestructura de red hasta gestores de contenidos y dispositivos conectados.
Entre los nombres citados figuran Broadcom, Citrix, Dell, F5, IBM, Huawei, Ivanti, NETGEAR, QNAP, Salesforce, Schneider Electric, Siemens, SonicWall, Splunk, Synology, Veeam y WordPress, además de proyectos como Drupal y Craft CMS.
La presencia de una empresa en esa lista no implica necesariamente que todos sus productos sean vulnerables ni que se haya confirmado una intrusión en sus sistemas. Puede significar que ha emitido una advertencia, que alguno de sus productos incorpora componentes afectados o que sus clientes deben comprobar configuraciones concretas.
Esta distinción es importante para evitar alarmas imprecisas. Los equipos informáticos deben consultar los avisos específicos de cada fabricante, identificar las versiones afectadas y seguir las instrucciones de mitigación correspondientes.
Una segunda alerta: la vulnerabilidad de Brotli conocida como Broccoli2Shell
La alerta sobre PHP2Shell coincide con otra actualización de seguridad relacionada con Brotli, una biblioteca de compresión utilizada en diferentes entornos de software.
El 26 de octubre de 2026, la Fundación PHP publicó versiones para Windows que incluyen correcciones para CVE-2026-111497, una vulnerabilidad de escritura fuera de límites en la biblioteca decodificadora Brotli. Según la información facilitada, este fallo también podría permitir una escalada de privilegios o la ejecución remota de código sin autenticación en determinadas condiciones.
El problema se conoce también por los nombres Broccoli2Shell, HTTP2Shell y Node2Shell. La información original señala como afectadas las versiones de Brotli 1.0.3 a 1.0.9, además de 1.1.0 y 1.2.0. Las versiones corregidas indicadas son 1.0.10, 1.1.1 y 1.2.1.
La vulnerabilidad no se limita a un único lenguaje o producto. Brotli se integra en diferentes proyectos y plataformas, por lo que la corrección puede requerir actualizaciones en componentes que utilizan la biblioteca C original.
Entre los proyectos mencionados figuran Node.js, Bun, Envoy Proxy, Istio, .NET y Python. Cada uno puede integrar Brotli de forma diferente, por lo que los administradores deben consultar las alertas específicas de los proyectos que utilicen.
Qué deben revisar los usuarios de PHP en Windows
La Fundación PHP advierte de que, en las compilaciones de PHP para Windows, se puede acceder al decodificador vulnerable a través de la extensión cURL cuando está habilitada la descompresión automática de respuestas HTTP.
Según la información facilitada, esta función está desactivada por defecto en cURL, aunque determinadas aplicaciones y bibliotecas cliente HTTP pueden activarla.
Esto significa que no todas las instalaciones de PHP para Windows presentan necesariamente la misma exposición. El riesgo depende de la versión instalada, los componentes utilizados y la configuración de la aplicación.
Los administradores deben comprobar si sus aplicaciones habilitan esa funcionalidad, actualizar los paquetes afectados y revisar las recomendaciones oficiales de PHP y de los proyectos que incorporan Brotli.
Qué deben hacer ahora los administradores de sistemas
Ante la explotación activa de PHP2Shell y la alerta adicional sobre Brotli, los responsables de seguridad deben priorizar una revisión ordenada de los sistemas.
Las medidas más relevantes son:
- Inventariar las instalaciones de PHP y localizar las versiones potencialmente afectadas.
- Aplicar las versiones corregidas —8.5.12, 8.4.27, 8.3.36 o 8.2.35, según la rama— o los paquetes equivalentes publicados por el proveedor.
- Comprobar las dependencias y extensiones, incluidas cURL y las bibliotecas que integren Brotli.
- Revisar los registros del servidor para identificar actividad anómala, errores inesperados o indicios de ejecución de código no autorizada.
- Verificar las actualizaciones en contenedores y sistemas secundarios, evitando que queden versiones antiguas fuera del inventario principal.
- Consultar las alertas de CISA y de los fabricantes para conocer las condiciones de explotación y las mitigaciones específicas.
- Investigar cualquier indicio de compromiso y no limitarse a instalar el parche si existen señales de que el sistema pudo ser atacado.
La aplicación de una actualización corrige la vulnerabilidad conocida, pero no garantiza que un equipo previamente comprometido haya quedado limpio. Si aparecen indicios de intrusión, la organización debe evaluar el alcance del incidente, preservar los registros relevantes y seguir su procedimiento de respuesta.
Una advertencia para empresas españolas y servicios digitales
Aunque la confirmación de CISA procede de Estados Unidos, la alerta afecta a un ecosistema tecnológico internacional. Las empresas españolas que utilicen PHP en servidores propios, plataformas alojadas o aplicaciones de terceros deben comprobar su exposición con independencia de dónde se haya detectado inicialmente la actividad maliciosa.
La dependencia de servicios digitales convierte las vulnerabilidades de los componentes más extendidos en un problema que puede propagarse por cadenas de proveedores. Una empresa puede no administrar directamente un servidor PHP y, aun así, depender de una aplicación web, un proveedor de alojamiento o una plataforma que sí lo utilice.
Por eso, la respuesta no debería limitarse a los departamentos técnicos. Las organizaciones deben conocer qué servicios dependen de los componentes afectados, qué proveedores los mantienen y qué plazos existen para aplicar las correcciones.
La urgencia también exige precisión. No hay base en la información facilitada para afirmar que todos los servicios PHP están comprometidos, ni para atribuir estos ataques a un grupo concreto de ciberdelincuentes. Lo que sí está confirmado, según la alerta descrita, es que existen casos de explotación activa y que los fallos cuentan con versiones corregidas.
PHP2Shell: una vulnerabilidad crítica que exige actuar sin alarmismo
La confirmación de CISA cambia la prioridad de las dos vulnerabilidades PHP2Shell. Ya no se trata únicamente de prevenir un posible ataque futuro: hay evidencias de explotación y una capacidad técnica especialmente sensible, la ejecución remota de código sin autenticación.
La disponibilidad de parches reduce el riesgo para quienes actualicen correctamente, pero la cantidad de servicios potencialmente afectados y la diversidad de configuraciones complican la respuesta. La vulnerabilidad adicional de Brotli obliga, además, a revisar componentes y dependencias que pueden pasar desapercibidos en un inventario convencional.
La conclusión para administradores y empresas es clara: identificar, actualizar y verificar. Retrasar las correcciones puede dejar una ventana de exposición innecesaria; aplicar parches sin comprobar el estado real de los sistemas tampoco basta.
La prioridad debe ser actuar sobre las instalaciones afectadas, contrastar las alertas de cada proveedor y revisar cualquier señal de intrusión. En ciberseguridad, la diferencia entre una vulnerabilidad conocida y un incidente grave puede depender de la rapidez con la que una organización detecta el problema y aplica las medidas adecuadas.
Chollones
Chollones
Chollones