PHP2Shell: la pregunta que tuvo que responder toda empresa en octubre de 2026
El 20 de octubre de 2026, el proyecto PHP avisó a los administradores de que al día siguiente publicaría correcciones urgentes para dos vulnerabilidades críticas. Los detalles se habían filtrado antes de la divulgación prevista. Los fallos, CVE-2026-109618 y CVE-2026-109619, bautizados enseguida como PHP2Shell, permiten a un atacante sin autenticar ejecutar código en remoto en un servidor con PHP. El 21 de octubre el proyecto PHP publicó las correcciones para sus versiones con soporte.
Para cualquier empresa con PHP en algún rincón de su infraestructura, la primera pregunta no fue técnica. Fue: ¿dónde tenemos PHP y en qué versiones? La web corporativa en un hosting gestionado, un portal de clientes antiguo, una herramienta interna que alguien montó hace años, un WordPress en un subdominio olvidado. Las empresas que ya analizaban sus sistemas de forma continua pudieron responder en la misma jornada. Las que dependían de un pentest anual tuvieron que empezar por hacer inventario, con los detalles del ataque ya publicados.
Esa diferencia es la mejor forma de explicar por qué el análisis de vulnerabilidades y el pentest no son intercambiables. Uno te dice de forma continua qué debilidades conocidas hay en todo lo que usas. El otro te dice, en un momento concreto, qué podría hacer de verdad un atacante con experiencia. Un programa de seguridad que solo tiene uno de los dos ve la mitad del cuadro.
Qué hace un análisis de vulnerabilidades
Un escáner de vulnerabilidades es una herramienta automática que revisa los sistemas y compara lo que encuentra con bases de datos de vulnerabilidades conocidas. Identifica software y versiones, puertos y servicios abiertos, parches pendientes, configuraciones débiles y certificados caducados, y asigna a cada hallazgo un nivel de gravedad. Puede cubrir el perímetro externo (todo lo accesible desde internet), redes y servidores internos, configuraciones cloud e imágenes de contenedores.
Su valor está en la amplitud y la repetición. Un escáner puede revisar todos los activos que conoce cada día o cada semana, y señalar un problema nuevo en cuanto se publica una vulnerabilidad y se relaciona con un sistema. Es lo que convierte "esta mañana se ha anunciado un fallo crítico en PHP" en "estos cuatro servidores están afectados" sin que nadie lo haga a mano.
Análisis autenticado y no autenticado
Un análisis no autenticado mira los sistemas desde fuera, como lo haría un atacante en la red, sin iniciar sesión. Ve los servicios expuestos y a menudo deduce versiones por las respuestas que recibe, pero no ve lo que hay instalado dentro. Un análisis autenticado entra con credenciales y revisa directamente paquetes instalados, ficheros de configuración y niveles de parcheo.
El análisis autenticado es mucho más fiable para parches y configuración, y es justo lo que importa en un caso como PHP2Shell. Muchas distribuciones de Linux aplican las correcciones de seguridad a sus propios paquetes de PHP sin cambiar el número de versión original, de modo que un escáner que solo lee la versión desde fuera puede dar por vulnerable un servidor ya corregido, o al revés. Revisar el estado real del paquete evita ese error.
Límites: falsos positivos, sin explotación, sin encadenar
El escáner informa de lo que coincide con una firma, no de lo que es realmente explotable. Eso genera falsos positivos, hallazgos que parecen graves pero que en ese contexto no se pueden explotar, y a veces falsos negativos, problemas reales que el escáner no ve. Alguien tiene que revisar y priorizar los resultados, o el informe se convierte en una lista larga que nadie atiende.
Y, sobre todo, un escáner no piensa como un atacante. No va a ver que una fuga de información de gravedad media en un sistema, sumada a una política de contraseñas débil en otro y a una cuenta de servicio con demasiados privilegios en un tercero, abre un camino hasta la base de datos de clientes. Encadenar debilidades en una ruta de ataque es justo lo que un análisis no hace.
Qué hace un pentest
Un pentest, o prueba de penetración, es un ataque controlado que realizan especialistas, con autorización de la organización, sobre un alcance definido. El especialista usa herramientas, incluidos escáneres, pero el núcleo del trabajo es manual: entender cómo funciona la aplicación o la red, buscar debilidades que las herramientas no ven, intentar explotarlas y avanzar desde un primer acceso hacia algo que importe.
El resultado es una prueba de impacto. Un buen informe de pentest no se limita a listar vulnerabilidades: muestra el camino que siguió el atacante, a qué pudo acceder y qué gravedad tiene eso para el negocio. Por eso convence a la dirección y sirve para priorizar: "un atacante podría llegar a los datos de clientes desde la página pública de acceso" es una conversación muy distinta de "47 hallazgos de gravedad media".
Alcance, reglas de actuación y tipos de prueba
Todo pentest empieza con un alcance (qué sistemas, aplicaciones, redes o entornos entran) y unas reglas de actuación (cuándo se prueba, qué técnicas se permiten, a quién avisar si algo falla). Los tipos más habituales son la prueba externa desde internet, la prueba interna que simula a un atacante que ya está dentro, la prueba de aplicaciones web y APIs, la revisión de configuración cloud y los ejercicios de ingeniería social.
Las pruebas también varían según la información que recibe el especialista. En una prueba de caja negra parte solo del objetivo; en una de caja gris recibe algo de información o una cuenta de usuario; en una de caja blanca dispone de documentación y a veces del código fuente. La caja gris es habitual en aplicaciones porque dedica el tiempo limitado a lo que más importa, no al descubrimiento.
Límites: es una foto fija y depende del alcance
Un pentest es una foto fija. Refleja los sistemas tal como estaban durante la prueba. Un despliegue a la semana siguiente, un cambio de configuración o una vulnerabilidad recién publicada como PHP2Shell no aparecen en el informe del trimestre pasado.
Además, vale lo que valga su alcance. Una prueba exhaustiva de la aplicación principal no dice nada del subdominio olvidado que quedó fuera. Por eso el pentest funciona mejor sobre un análisis continuo y un inventario actualizado: el análisis mantiene la foto al día y encuentra lo expuesto, y el pentest profundiza donde el riesgo es mayor.
Con qué frecuencia hace falta cada uno
El análisis de vulnerabilidades debería ser continuo o casi. El perímetro externo, que es lo primero que ve un atacante, suele analizarse al menos cada semana y a menudo a diario, con revisiones inmediatas cuando se anuncia una vulnerabilidad crítica. Los análisis internos y autenticados suelen ser semanales o mensuales, según lo rápido que cambie el entorno.
El pentest es periódico. Un pentest anual del perímetro externo y de las aplicaciones clave es una referencia habitual, con pruebas adicionales tras cambios relevantes: un producto nuevo, una versión importante, una migración a otro entorno cloud o una adquisición. Clientes y organismos a veces fijan sus propios requisitos, y algunos cuestionarios de seguridad preguntan expresamente por la fecha y el alcance del último pentest.
Qué piden la ISO 27001 y el ENS
Ni la ISO 27001 ni el ENS dicen "haz un pentest al año". Ambos exigen conocer las vulnerabilidades técnicas y tratarlas, y dejan la elección de métodos al análisis de riesgos de cada organización. En la práctica, el auditor busca pruebas de que las vulnerabilidades se detectan con regularidad, se evalúan, se corrigen y se verifican.
El control 8.8 de la ISO 27001
El control 8.8 del Anexo A de la ISO 27001:2022, gestión de las vulnerabilidades técnicas, es la referencia más directa. En resumen, espera que la organización obtenga información sobre las vulnerabilidades técnicas de los sistemas que usa, evalúe su exposición y adopte las medidas adecuadas. El control 8.29 añade las pruebas de seguridad durante el desarrollo y la aceptación.
Un auditor que revise el 8.8 suele pedir informes de análisis de un periodo, pruebas de cómo se priorizaron los hallazgos, registros de corrección con fechas y evidencias de que los problemas críticos se resolvieron en los plazos que la propia organización se había fijado. Los informes de pentest y su seguimiento son una evidencia de apoyo sólida, sobre todo para aplicaciones expuestas a internet.
El ENS: qué exige el RD 311/2022
El Real Decreto 311/2022 recoge estas obligaciones de forma explícita. El artículo 10.2 establece que la evaluación permanente del estado de la seguridad de los activos debe permitir detectar vulnerabilidades e identificar deficiencias de configuración, y el artículo 21.2 exige evaluación y monitorización permanentes para ajustar los sistemas a las vulnerabilidades identificadas y a las actualizaciones que les afecten.
En el Anexo II, estos principios se concretan en medidas como op.exp.4 (mantenimiento y actualizaciones de seguridad), op.mon.3 (vigilancia) y mp.sw.2 (aceptación y puesta en servicio de aplicaciones). Las tres aplican desde la categoría BÁSICA, con refuerzos adicionales en MEDIA y ALTA. Las guías CCN-STIC del Centro Criptológico Nacional detallan cómo implantarlas y auditarlas. Para las empresas que prestan servicios al sector público, los avisos de vulnerabilidades del CCN-CERT y de INCIBE-CERT son además una fuente útil para saber cuándo hay que revisar los sistemas con urgencia.
Qué pasa después de los hallazgos
Encontrar vulnerabilidades es la parte fácil. El valor del análisis y del pentest depende por completo de lo que viene después: que los hallazgos se prioricen con criterio, los corrija quien debe y se compruebe que están corregidos. Los auditores y los atacantes miran precisamente esa parte.
Priorizar por riesgo real, no solo por CVSS
La puntuación CVSS mide la gravedad técnica de una vulnerabilidad en general. No sabe si el sistema afectado está expuesto a internet, si guarda datos de clientes, si circula un exploit o si un control compensatorio bloquea el ataque. Una puntuación crítica en un servidor de pruebas aislado puede importar menos que una media en la página de acceso de producción.
Priorizar bien combina gravedad y contexto: exposición, valor del activo, si la vulnerabilidad se está explotando activamente y a qué podría llegar un atacante desde ahí. Así decide un equipo con tiempo limitado qué corrige esta semana y qué puede esperar a la próxima ventana de mantenimiento.
Corrección y nueva comprobación
Cada hallazgo necesita un responsable, una fecha objetivo y un registro de lo que se hizo. "Corregido" debería significar comprobado: un nuevo análisis que confirme que la vulnerabilidad ha desaparecido, o una nueva prueba del especialista en los hallazgos que exigieron explotación manual. Sin ese paso, el registro muestra intenciones, no resultados.
La nueva comprobación importa sobre todo en los hallazgos de pentest, porque la corrección de un fallo de aplicación suele ser parcial. El desarrollador corrige la entrada concreta que usó el especialista y la misma debilidad sigue accesible por otro camino. La mayoría de proveedores de pentest incluyen una nueva prueba de los hallazgos originales; conviene asegurarse de que se hace.
PHP2Shell paso a paso: detectar, parchear, reiniciar, comprobar
PHP2Shell es un buen ejemplo práctico porque cada paso de una respuesta sólida dependía del análisis continuo y ninguno esperaba a un pentest. El primer paso era detectar: identificar todos los sistemas con PHP, sus versiones y si eran accesibles desde internet. Según las indicaciones del proyecto PHP recogidas por Kaspersky, estaban en riesgo las instalaciones sin parchear que procesan peticiones web en configuraciones habituales, como PHP-FPM, Apache con mod_php y php-cgi.
El segundo paso era parchear. Las versiones corregidas fueron 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Los sistemas con PHP 8.1 o anterior, que ya no reciben actualizaciones del proyecto PHP, no tenían parche que aplicar: la única solución real era actualizar a una versión con soporte, lo que lleva más tiempo y exigía una mitigación temporal mientras tanto. Las primeras indicaciones publicadas por el SANS Internet Storm Center describían la desactivación de session.upload_progress.enabled como mitigación parcial mientras se desplegaban los parches.
El tercer y el cuarto paso son los que se saltan. Instalar un paquete nuevo no sustituye los procesos de PHP que ya están en marcha: hay que reiniciar PHP-FPM o el servidor web para que se cargue el código corregido, y confirmar después la versión. Luego, un nuevo análisis, a ser posible autenticado, confirma que cada sistema ya no es vulnerable. Esa es la evidencia que pedirá el auditor y la garantía que querrá el cliente.
La plataforma de Qalea analiza de forma continua la superficie de ataque externa y los sistemas internos, señala las vulnerabilidades explotables y las prioriza por riesgo real, con un plan de corrección para cada una. El equipo de Qalea añade pentesting donde hace falta profundidad y sigue cada hallazgo hasta confirmar que está corregido. El artículo sobre la superficie de ataque externa explica cómo se descubren los activos expuestos, qué evalúa una auditoría de certificación explica cómo se revisan estas evidencias, y la página de superficie de ataque y pentesting reúne el resto de la serie.
