El 21 de octubre se publicaron dos vulnerabilidades críticas en PHP, identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas popularmente como PHP2Shell. Ambas podían permitir a un atacante ejecutar código en un servidor sin necesidad de credenciales.
En nsign, en menos de 24 horas, toda la superficie de ataque identificada estaba cerrada. Te explicamos qué ha pasado, qué hicimos y por qué este caso nos deja una reflexión importante sobre la seguridad en la era de la inteligencia artificial.
¿Qué es PHP2Shell?
El nombre se lee «PHP to shell»: de PHP a la shell, la consola desde la que se controla un servidor. Y resume bien el riesgo: aprovechar un fallo en PHP para acabar dando órdenes directamente al sistema, como si el atacante estuviera sentado frente a él.
El nombre sigue la tradición de Log4Shell, la vulnerabilidad que sacudió internet en 2021.
Si quieres la explicación técnica completa, puedes consultarla en php2shell.com.
Nuestra respuesta, paso a paso
Cuando se publicaron las vulnerabilidades, el equipo de Tecnología de nsign actuó en tres frentes:
- Análisis del impacto. Revisamos nuestro código y nuestra infraestructura para identificar con precisión la superficie de ataque.
- Parcheo. Aplicamos la versión corregida de PHP en nuestra plataforma en cuanto la imagen oficial estuvo disponible.
- Contención. Allí donde el parche no podía aplicarse de inmediato, cerramos los accesos afectados.
Resultado: en menos de 24 horas, toda la superficie de ataque identificada estaba cerrada.
La reflexión: un fallo antiguo, una amenaza nueva
Hay un dato que nos hace pensar: este fallo llevaba más de diez años en el código de PHP. No es nuevo.
Lo nuevo es que la inteligencia artificial ya encuentra vulnerabilidades como esta a una velocidad nunca vista. Y esa capacidad está al alcance tanto de quienes defienden como de quienes atacan.
Reaccionar rápido es necesario, pero no suficiente
Por eso, la velocidad de respuesta es solo una parte de la ecuación. Para proteger de verdad una plataforma hace falta:
- Apoyarse en la IA para detectar y priorizar los riesgos antes.
- Diseñar con arquitectura segura, para que un fallo puntual no se convierta en una puerta abierta.
- Gestionar la infraestructura con rigor: parcheo continuo y procesos probados.
Seguridad avalada por el ENS
En nsign ya trabajábamos así, y hoy lo avala nuestra certificación en el Esquema Nacional de Seguridad (ENS), categoría Media.
Porque la seguridad no es un proyecto con fecha de fin. Es una práctica diaria.
Gracias a todo el equipo de Tecnología por la rapidez y el rigor de estos días.
Mira el vídeo
Teresa Rojas, Chief Technology & Product Officer de nsign, lo explica en un minuto:
Puedes mirar el vídeo de LinkedIn
