Dos vulnerabilidades críticas en PHP encienden las alarmas por el riesgo para millones de sitios web

Los fallos, identificados con los códigos CVE-2026-109618 y CVE-2026-109619 y conocidos conjuntamente como PHP2Shell, fueron divulgados el 21 de octubre de 2026, cuando el equipo responsable del lenguaje anunció la disponibilidad de actualizaciones para corregirlos - Foto: lmonk72

Los fallos, identificados con los códigos CVE-2026-109618 y CVE-2026-109619 y conocidos conjuntamente como PHP2Shell, fueron divulgados el 21 de octubre de 2026, cuando el equipo responsable del lenguaje anunció la disponibilidad de actualizaciones para corregirlos - Foto: lmonk72

Dos vulnerabilidades críticas en PHP, uno de los lenguajes de programación más utilizados para desarrollar sitios web y aplicaciones, encendieron las alertas de la comunidad internacional de ciberseguridad por la posibilidad de que atacantes ejecuten código malicioso en servidores expuestos a internet.

Los fallos, identificados con los códigos CVE-2026-109618 y CVE-2026-109619 y conocidos conjuntamente como PHP2Shell, fueron divulgados el 21 de octubre de 2026, cuando el equipo responsable del lenguaje anunció la disponibilidad de actualizaciones para corregirlos.

La gravedad del hallazgo radica en que las vulnerabilidades pueden permitir la ejecución remota de código sin que el atacante tenga que autenticarse. En determinadas condiciones, esto podría facilitar el control de un servidor y abrir el camino para acceder a información sensible, alterar archivos o comprometer aplicaciones alojadas en él.

El descubrimiento también puso de relieve un problema que afecta al mantenimiento de las infraestructuras digitales: algunos errores pueden permanecer durante años en componentes fundamentales del software antes de ser identificados. En este caso, los investigadores señalaron que los problemas estaban relacionados con código que llevaba más de una década presente en PHP.

La primera vulnerabilidad, CVE-2026-109618, está asociada con el manejo de errores que se producen cuando PHP agota la memoria disponible. En determinadas circunstancias, la interrupción de una operación puede dejar estructuras internas de una petición parcialmente inicializadas, que posteriormente son procesadas de manera insegura durante las tareas de limpieza.

La segunda falla, CVE-2026-109619, está relacionada con el uso de referencias a memoria que ya fue liberada. Cuando determinados estados internos conservan esos vínculos, una petición posterior puede interactuar con información que ya no debería estar disponible, lo que genera condiciones que pueden aprovecharse para comprometer la ejecución del proceso.

Ambas vulnerabilidades recibieron una puntuación de 9,2 sobre 10 en el sistema CVSS 4.0, una clasificación que corresponde a una gravedad crítica. Los análisis técnicos advierten que la explotación exitosa puede tener consecuencias que van más allá de la interrupción de un servicio y comprometer la seguridad del servidor afectado.

El alcance potencial de la amenaza está relacionado con la presencia de PHP en una parte considerable de internet. El lenguaje se utiliza para desarrollar páginas dinámicas, gestionar formularios, procesar transacciones y conectar aplicaciones con bases de datos, además de servir como plataforma para numerosos sistemas de administración de contenidos.

Entre los productos que utilizan PHP se encuentran WordPress, Drupal y Joomla, ampliamente empleados para publicar contenidos, administrar portales institucionales y mantener sitios corporativos. Sin embargo, la existencia de una aplicación basada en alguna de estas plataformas no significa por sí sola que haya sido comprometida: la exposición depende, entre otros factores, de la versión de PHP y de la configuración del servidor.

Las estimaciones sobre la presencia de PHP en la web ayudan a dimensionar la superficie potencial de riesgo, pero no permiten establecer cuántos sitios están realmente expuestos a estas vulnerabilidades. Tampoco existe una equivalencia entre el número de páginas que utilizan el lenguaje y la cantidad de sistemas que han sufrido una intrusión.

Los fallos afectan a diferentes modalidades de ejecución de PHP, entre ellas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP señaló que uno de los escenarios de mayor riesgo se presenta en instalaciones con mod_php, donde se demostró que una petición no autenticada podía desencadenar el ataque antes de que se ejecutara el código de la aplicación.

La disponibilidad de información técnica sobre las vulnerabilidades constituye otro factor de preocupación. Después de la publicación de los parches, investigadores y equipos de seguridad pueden estudiar los cambios introducidos para comprender los errores y comprobar si sus sistemas están protegidos, pero ese mismo conocimiento también puede facilitar el trabajo de actores maliciosos.

El Centro de Respuesta a Incidentes de Seguridad Informática de la Unión Europea, CERT-EU, recomendó a las organizaciones instalar las actualizaciones de inmediato. El organismo también aconsejó aislar temporalmente de las redes públicas las aplicaciones expuestas cuando no sea posible corregirlas y verificar que la solución se haya aplicado.

El proyecto PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que incorporan las correcciones para los dos fallos. Los desarrolladores recomendaron actualizar cuanto antes las instalaciones correspondientes a esas ramas.

La situación es más compleja para quienes todavía utilizan PHP 8.1 o versiones anteriores, que ya no reciben mantenimiento de seguridad del proyecto principal. En esos casos, es necesario comprobar si el proveedor del sistema operativo o del alojamiento web ha distribuido parches específicos y, cuando corresponda, planificar la migración a una versión con soporte.

Los administradores también deben tener presente que la versión de PHP instalada en un servidor puede ser diferente de la que utiliza una aplicación concreta. En entornos de alojamiento compartido o con varios sitios web, es posible que existan distintas versiones ejecutándose simultáneamente, por lo que actualizar un único componente no garantiza que toda la infraestructura haya quedado protegida.

La amenaza también involucra a proveedores de alojamiento, empresas que administran servidores para terceros y organizaciones que dependen de plataformas contratadas. En esos casos, los responsables de los sitios deben solicitar confirmación de la versión utilizada, las actualizaciones aplicadas y las medidas adoptadas para verificar que no queden servicios vulnerables expuestos.

Además de instalar los parches, los equipos técnicos deben revisar los registros de acceso, los archivos modificados y los procesos que se ejecutan en los servidores. Si existen indicios de actividad sospechosa, será necesario investigar si se produjo una intrusión, determinar su alcance y comprobar que no se hayan instalado mecanismos para mantener el acceso después de corregir la vulnerabilidad.

La actualización del software es la principal medida de protección. El propio equipo de PHP advirtió que no existen mitigaciones completas que sustituyan la instalación de las versiones corregidas. Por ello, desactivar temporalmente determinadas funciones o aplicar restricciones de acceso puede reducir algunos escenarios de exposición, pero no debe considerarse una solución definitiva.

El caso también evidencia las dificultades que enfrentan las organizaciones para mantener infraestructuras que llevan años en funcionamiento. Los sitios antiguos pueden depender de versiones específicas de PHP, complementos que ya no reciben mantenimiento o aplicaciones desarrolladas a medida, lo que retrasa las actualizaciones y aumenta los costos de migración.

En el ámbito de la administración pública, los medios de comunicación, las universidades y las empresas privadas, este tipo de vulnerabilidades plantea la necesidad de contar con inventarios actualizados de los activos digitales. Sin esa información, los responsables de seguridad pueden desconocer qué servicios utilizan versiones vulnerables o dependen de proveedores que todavía no han aplicado las correcciones.

El hallazgo también destacó el papel de la inteligencia artificial en la investigación de seguridad informática. Los reportes publicados atribuyeron a herramientas de IA una función en la identificación de uno de los fallos, mientras otros investigadores realizaron análisis independientes y colaboraron en el proceso de divulgación coordinada con los responsables de PHP.

Estas herramientas pueden ayudar a examinar grandes cantidades de código, identificar patrones problemáticos y acelerar la detección de errores complejos. Sin embargo, la capacidad de analizar vulnerabilidades también puede ser utilizada para desarrollar técnicas de explotación, lo que refuerza la importancia de coordinar las divulgaciones y distribuir las correcciones con rapidez.

Hasta el momento, los reportes sobre intentos de explotación y la circulación de pruebas de concepto justifican una respuesta urgente de los administradores, pero no permiten afirmar que todos los sitios que utilizan PHP estén comprometidos. Para establecer el número de víctimas se requieren evidencias de incidentes confirmados y evaluaciones específicas de cada infraestructura.

La principal lección de PHP2Shell es que la antigüedad de un componente no garantiza su estabilidad ni su seguridad. Un error que permanece durante años puede convertirse en una amenaza de gran alcance cuando se descubre una forma de explotarlo, especialmente si afecta a una tecnología ampliamente utilizada y existen servidores que continúan funcionando sin las actualizaciones necesarias.

Por ahora, la prioridad para las organizaciones es identificar las instalaciones afectadas, aplicar las correcciones correspondientes y verificar que los servicios estén protegidos. La rapidez de esa respuesta será determinante para reducir las posibilidades de que dos errores internos del lenguaje se conviertan en una puerta de entrada a sistemas, datos y servicios digitales.

Etiquetado: