Por Canuto  

El equipo de PHP lanzó parches de emergencia para dos vulnerabilidades críticas que pueden permitir ejecutar código remoto sin autenticación. Las fallas afectan instalaciones que reciben peticiones web, y los administradores deben actualizar a las versiones corregidas o consultar de inmediato con su proveedor.
***

  • Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 podrían permitir ejecución remota de código mediante una petición no autenticada.
  • PHP corrigió los fallos en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35; mod_php enfrenta el mayor riesgo señalado.
  • El NCSC del Reino Unido recomienda considerar desconectar los sistemas que no puedan repararse de inmediato.

El equipo de desarrollo de PHP publicó actualizaciones de seguridad de emergencia para corregir dos vulnerabilidades críticas que podrían permitir a un atacante ejecutar código de forma remota en un servidor web, sin iniciar sesión. Identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas en conjunto como PHP2Shell, las fallas afectan instalaciones que atienden peticiones web. El aviso, divulgado el 21 de octubre de 2026, insta a actualizar sin demora.

Los parches están disponibles en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. La alerta publicada por Help Net Security también indica que el problema alcanza distintos modos de despliegue, como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed; las configuraciones que usan mod_php enfrentan el peligro más alto, según la información difundida.

Dos fallas con posibles consecuencias remotas

La primera vulnerabilidad, CVE-2026-109618, se relaciona con una condición de falta de memoria, conocida como OOM, que puede interrumpir el funcionamiento de PHP mientras ciertos datos internos de una petición todavía se inicializan. En esa situación, el proceso de limpieza puede tratar información inválida como si fuera correcta. La cadena de errores abre la posibilidad de que un atacante consiga ejecutar código en el servidor afectado.

La segunda falla, CVE-2026-109619, involucra el estado global que PHP mantiene durante el procesamiento de una petición. De acuerdo con la descripción técnica divulgada, ese estado puede persistir después de que se libere la memoria que lo respalda, y una petición posterior atendida por el mismo trabajador podría reutilizarlo antes de que la inicialización normal lo restablezca. El riesgo, por tanto, no depende únicamente de los datos de una petición aislada.

La noticia advierte que ya se demostró un exploit funcional capaz de activarse con una sola petición no autenticada. En las configuraciones señaladas, el ataque podría comenzar antes de que se ejecute el código propio de la aplicación; por eso, una revisión limitada a las funciones de una página o servicio no basta para descartar el riesgo. La prioridad es comprobar qué versión de PHP ejecuta cada servidor y aplicar la corrección correspondiente.

Los investigadores de Wiz describieron los hallazgos como algunos de los más graves encontrados en PHP y destacaron que los defectos subyacentes habían estado presentes durante décadas. Según su explicación, probar que podían explotarse exigió una secuencia excepcionalmente compleja, que estaba cerca de los límites prácticos para investigadores humanos. Añadieron que modelos de inteligencia artificial de vanguardia redujeron sustancialmente esa barrera y ayudaron a convertir un defecto antiguo en un exploit.

Actualización urgente y sistemas difíciles de mantener

La recomendación principal es instalar PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, según la rama que utilice cada organización. Las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron los parches antes del anuncio público, por lo que los administradores deben consultar sus repositorios y canales oficiales para encontrar los paquetes corregidos. Si la actualización no está disponible directamente, la fuente aconseja contactar al proveedor antes de asumir que el sistema ya está protegido.

PHP 8.1 y las versiones anteriores dejaron de recibir soporte del proyecto, aunque algunas distribuciones y proveedores LTS pueden ofrecer correcciones retroportadas. Quienes dependan de esas ramas deben confirmar con su proveedor si existe un parche o migrar a una versión soportada. El equipo de seguridad de PHP también publicó backports de código fuente mínimos para PHP 7.4, 8.0 y 8.1, destinados a quienes compilan desde el código fuente o no cuentan con un proveedor de soporte extendido.

La recomendación incluye una advertencia específica para quienes usan paquetes de rpms.remirepo.net, un repositorio mantenido por voluntarios. Según el aviso, ese repositorio no tendría actualizaciones disponibles ese día; por ello, se aconseja cambiar a paquetes de la distribución correspondiente o compilar PHP desde el código fuente para poder aplicar la corrección de inmediato. La medida no elimina la necesidad de verificar que el parche se haya instalado correctamente en todos los entornos que reciben tráfico web.

El Centro Nacional de Ciberseguridad del Reino Unido, conocido como NCSC, pidió a las organizaciones considerar desconectar cualquier sistema que no pueda repararse con rapidez. La recomendación subraya el dilema para operadores que mantienen infraestructura expuesta, pero no pueden desplegar de inmediato una versión corregida. El investigador de seguridad Kevin Beaumont advirtió que la situación podría generar numerosos incidentes y calificó el caso como una de las mayores vulnerabilidades de los últimos años.

El experto en informática forense Hal Pomeranz puso el foco en la duración potencial del problema: señaló que hay muchas instalaciones integradas que nunca recibirán parches y aplicaciones olvidadas o sin mantenimiento. Su advertencia apunta a que el riesgo no termina cuando los proveedores principales distribuyen una actualización, porque algunos sistemas pueden seguir funcionando con versiones antiguas y sin una ruta sencilla de actualización. Esa cola de equipos desatendidos podría prolongar la exposición.

Cloudflare informó que desplegó un conjunto inicial de reglas de firewall de aplicaciones web, o WAF, para los vectores de explotación conocidos. Dane Knecht, CTO de la compañía, dijo que esas reglas están disponibles para todos sus clientes, incluidos los que utilizan el nivel gratuito. La medida puede ofrecer una capa adicional de defensa para sitios que pasan por ese servicio, pero el aviso no la presenta como sustituto de actualizar PHP o de consultar al proveedor responsable del sistema.

Para los equipos de seguridad, el siguiente paso consiste en inventariar las instalaciones que procesan peticiones web, identificar su versión y confirmar el método con el que se desplegará el parche. También conviene priorizar los servidores con mod_php, revisar las ramas sin soporte y comprobar si los proveedores han publicado paquetes corregidos o backports. La urgencia deriva de que las fallas pueden ser activadas sin autenticación, mientras que la diversidad de instalaciones hace probable que no todos los sistemas se actualicen al mismo ritmo.

PHP2Shell reúne así dos problemas distintos de manejo de memoria y estado interno bajo una misma advertencia operativa: los servidores expuestos requieren una acción inmediata, no solo una evaluación posterior. Las versiones corregidas ya están identificadas, pero la protección efectiva depende de que cada administrador aplique el parche adecuado o, si eso no es posible, siga las indicaciones de su proveedor y valore desconectar el sistema. La fuente advierte que las instalaciones olvidadas podrían mantener vivo el riesgo durante mucho tiempo.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados