php2shell: ¿Nos afecta?

php2shell pone la ejecución remota de código en PHP en el centro de la respuesta de seguridad de hoy. Dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, se hicieron públicas el 21 de octubre de 2026. Para los equipos responsables de aplicaciones PHP desplegadas, el reto inmediato es convertir la noticia en decisiones: ¿dónde nos afecta, qué podemos confirmar y qué debe cambiar?

Un identificador CVE no responde esas preguntas. Tampoco una lista de repositorios que mencionan PHP. El software relevante ya está desplegado, a veces detrás de varias capas de infraestructura, y la evidencia necesaria para evaluarlo está repartida entre avisos, información del entorno de ejecución, configuración y registros de despliegue.

Construí CVE Central para conectar esas piezas. Su agente de investigación inspecciona despliegues configurados, reúne evidencia del entorno y de los avisos, confirma hallazgos de versiones afectadas y produce un plan de acción manual. php2shell ofrece un caso concreto para explicar cómo funciona: desde identificar el PHP que atiende las peticiones hasta proponer un parche que cubra ambas CVE.

Qué cambia con php2shell

El nombre php2shell agrupa dos vulnerabilidades de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas pueden permitir la ejecución remota de código. La guía del NCSC de Países Bajos reúne información sobre las dos.

CVE-2026-109618 afecta el manejo de errores por falta de memoria. Una inicialización interrumpida puede dejar memoria inválida que después procesa la limpieza de la petición. El aviso de PHP describe una vía en Apache mod_php que ocurre antes de ejecutar código de la aplicación. Las validaciones de la aplicación no bastan para cubrirla. Véase el aviso de PHP.

CVE-2026-109619 afecta el estado que persiste entre peticiones. Un proceso puede conservar referencias a memoria de una petición anterior; una operación posterior puede usarla después de su liberación. Las operaciones y la configuración determinan las condiciones relevantes. Véase el aviso de PHP.

Ambos avisos identifican correcciones en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Son límites de parche para cada rama. Si PHP procede de un paquete de una distribución, también hay que consultar su aviso de seguridad y comprobar si incorporó la corrección mediante un backport. Comparar únicamente el número de versión oficial puede ser insuficiente para evaluar ese paquete.

La alerta se convierte en un hallazgo local

La primera tarea es identificar dónde se ejecuta PHP. Un archivo de dependencias o una nota de despliegue puede describir la versión prevista. La respuesta necesita evidencia del servicio desplegado.

CVE Central parte de un destino configurado explícitamente y con acceso autorizado. Su adaptador actual de PHP inspecciona el contenedor activo, consulta la versión a través del servidor web y reúne la interfaz y la configuración. Las observaciones de despliegue y red ayudan a ubicar el servicio y señalar preguntas pendientes sobre exposición. Los despliegues basados en paquetes también requieren evidencia de los parches del proveedor; la evaluación actual de versiones oficiales no demuestra esa cobertura.

Contrastar observaciones importa. El binario de PHP en la terminal puede ser distinto del que atiende el sitio. La referencia de una imagen puede no coincidir con el proceso activo. Si las observaciones se contradicen, el agente debe conservar esa discrepancia e investigarla antes de emitir una conclusión firme.

El agente contrasta la referencia de la imagen PHP/Apache con la versión informada a través del servidor web. Así obtiene un entorno concreto para compararlo con los avisos. Una dependencia declarada no demuestra qué atiende las peticiones en este momento.

La detección debe producir un inventario de entornos observados vinculados con servicios desplegados, con evidencia y marcas de tiempo. Lo que el agente no pudo inspeccionar debe quedar explícitamente pendiente. Un inventario incompleto no puede convertirse en una afirmación de que las demás aplicaciones están a salvo.

Un servicio que funciona puede necesitar un parche urgente

Diseñé la evaluación alrededor de una distinción operativa: confirmar una versión afectada es distinto de confirmar una explotación o un compromiso. CVE Central establece el hallazgo de versión; las demás preguntas requieren evidencia adicional.

CVE Central consulta los registros CNA de PHP y conserva sus direcciones de origen y horas de consulta. La comparación de versiones se ejecuta en código, a partir del entorno oficial observado y los intervalos de los avisos que admite. Si una distribución incorpora correcciones mediante backports, el estado de seguridad del paquete debe formar parte de la comparación. La evidencia ausente o contradictoria debe producir un hallazgo pendiente y una solicitud concreta de seguimiento.

La distinción importa especialmente con php2shell. La configuración ayuda a interpretar las vías descritas en los avisos, pero recopilar ajustes no reproduce una explotación. Las pruebas habituales de la aplicación aportan una referencia para la actualización; aprobarlas no demuestra que PHP esté libre de la vulnerabilidad.

Del mismo modo, un puerto publicado por Docker no demuestra accesibilidad desde Internet. Eso exige evidencia adicional sobre rutas, firewalls, proxies y controles de acceso. Una versión afectada ya justifica preparar el parche; demostrar una explotación contra el servicio activo no tiene por qué convertirse en requisito previo.

Aquí importa especialmente la precisión del informe. «Versión afectada», «despliegue explotable» y «compromiso confirmado» llevan a decisiones distintas. Reducirlos a un solo indicador rojo elimina información necesaria para el operador.

Dos hallazgos llevan a un solo cambio propuesto

En un despliegue de PHP oficial de la rama 8.4 con una versión afectada, el límite de parche compartido permite atender ambas CVE con una actualización del entorno. La investigación de php2shell del agente produjo este cambio propuesto para el contenedor:

La edición es el centro del plan. El operador también necesita una forma de desplegarla y determinar si funcionó. CVE Central genera un procedimiento manual alrededor de esa edición, con preparación, sustitución del servicio, aceptación y recuperación. Al revisarlo, el operador necesita resolver cinco cuestiones prácticas:

1. Alcance y prioridad. Identificar el servicio afectado, su responsable, la evidencia y las preguntas pendientes sobre exposición. Si el parche debe esperar, evaluar medidas temporales con orientación oficial vigente y las condiciones del despliegue.
2. Preparación. Verificar el artefacto corregido, registrar su digest, conservar la configuración y preparar el respaldo y la recuperación de los datos.
3. Ejecución. Revisar el cambio exacto y sustituir el servicio en una ventana acordada, considerando interrupciones de peticiones y pérdida de sesiones.
4. Aceptación. Confirmar la versión corregida a través del servidor web, registrar el nuevo artefacto activo y repetir las pruebas funcionales de referencia.
5. Recuperación y cierre. Definir qué hacer si el servicio falla, reconocer que restaurar la versión afectada reabre el hallazgo y conservar la evidencia necesaria para cerrarlo.

La diferencia entre un plan escrito y una corrección terminada debe permanecer visible. Generar un procedimiento no actualiza un servicio. El hallazgo sigue abierto hasta que el despliegue y la verificación posterior demuestren que el entorno afectado fue sustituido.

De la divulgación de hoy a una respuesta verificada

CVE Central conecta tres trabajos que suelen pasar de una persona a otra: identificar entornos afectados en despliegues configurados, evaluar la evidencia y preparar el cambio. El modelo selecciona herramientas permitidas en cada fase; la comparación de versiones y la construcción del procedimiento se ejecutan en código. Los puntos de revisión separan recopilación, evaluación, planificación e informe para que el operador pueda inspeccionar la evidencia antes de continuar.

La página del agente y el informe técnico documentan el agente que construí y su alcance actual: destinos PHP configurados. El alcance importa: evaluar servicios seleccionados no demuestra que se haya revisado toda una organización. Ampliar la cobertura exige un inventario y acceso a los despliegues que se van a evaluar.

php2shell muestra por qué la respuesta a vulnerabilidades no puede terminar en la notificación. La divulgación es una noticia compartida; los servicios afectados, la procedencia de los paquetes, la exposición y las restricciones de recuperación son hechos locales. Construí CVE Central para reunir esa evidencia y preparar un plan que un operador pueda revisar y ejecutar. Produce la investigación y el procedimiento; no despliega el parche ni certifica que la corrección esté terminada.

El criterio de éxito es concreto: identificar el despliegue afectado, explicar la evidencia, especificar la corrección y verificar el entorno después del cambio. Hasta entonces, la organización tiene una alerta o un plan. Con esa evidencia, tiene una respuesta fundamentada a la pregunta que php2shell planteó hoy: ¿dónde nos afectaba y qué hicimos al respecto?