¿Podían IAM, IGA o PAM mitigar las vulnerabilidades críticas de PHP?

El 21 de octubre de 2026 el proyecto PHP publicó un aviso titulado "Critical remote code execution vulnerabilities, update now". Las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades que pueden permitir ejecución remota de código sin autenticación, y el proyecto considera en riesgo a todas las instalaciones que atienden peticiones web.

Después del aviso, un cliente nos hizo una pregunta concreta: ¿desde la gestión de accesos (IAM), el gobierno de identidades (IGA) o los accesos privilegiados (PAM) podíamos hacer algo para mitigarlas?

La falla está en el runtime de PHP y se corrige actualizando; ningún control de identidad cambia eso. En nuestro caso usamos PHP-FPM y actualizamos nuestros servidores en cuanto se publicaron las versiones corregidas. Además pusimos session.upload_progress.enabled=0, que el propio aviso recomienda mantener aunque ya se haya parchado. FPM escucha en un socket Unix, así que la evasión de la ACL por IPv6 de septiembre (CVE-2026-91768) no nos afectaba. Y nuestros paneles internos ya estaban detrás de SSO desde antes del aviso, fuera del alcance de cualquiera en internet.

Pero la pregunta del cliente tiene otra parte que vale la pena contestar: quién puede llegar a un servidor vulnerable y qué puede hacer una vez dentro. Eso depende en buena medida de decisiones de identidad y acceso.

Qué corrigen las versiones de octubre

Las dos vulnerabilidades, que medios y firmas de seguridad han bautizado como php2shell, tienen que ver con la forma en que PHP limpia el estado de una petición, pero son fallas distintas.

CVE-2026-109618, RCE vía corrupción por falta de memoria (GHSA-w8hw-w9fx-j79w). Cuando se agota la memoria, PHP usa longjmp() para abortar la petición y puede dejar datos a medio inicializar, que el apagado posterior trata como válidos. Tiene CVSS 4.0 de 9.2.

CVE-2026-109619, RCE vía estado global obsoleto (GHSA-6wmf-4rv5-p3rp). Un worker persistente puede conservar referencias a memoria que liberó una petición anterior, ya sea por un error fatal o por una advertencia emitida durante la limpieza. Algunas operaciones, como los diagnósticos de directivas INI y session.upload_progress, leen ese estado antes de que la siguiente petición lo reinicie. También tiene CVSS 4.0 de 9.2 y requiere que las dos peticiones caigan en el mismo worker: tener más workers baja la probabilidad de cada intento, pero no elimina la condición.

Lo confirmado varía según el modo en que corre PHP:

Modo	CVE-2026-109618	CVE-2026-109619
Apache mod_php	RCE confirmada, antes de que se ejecute código de la aplicación	RCE confirmada
PHP-FPM	Susceptible según el análisis del código; no hay exploit completo demostrado	RCE confirmada vía `session.upload_progress`, con una operación adecuada de la aplicación; la vía INI aplica solo si el frontend envía `PHP_VALUE` o `PHP_ADMIN_VALUE`
FrankenPHP	Probablemente susceptible	No se estableció la vía INI con la configuración por defecto, lo que no lo hace inmune
LiteSpeed (LSAPI)	Explotación dependiente de la aplicación, probable pero no validada	Candidato condicional

Cada rama tiene su versión corregida: 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Las versiones anteriores de cada rama siguen expuestas. PHP 8.1 y anteriores ya no reciben soporte, aunque por la severidad el equipo de seguridad publicó backports mínimos en código fuente para 7.4, 8.0 y 8.1, y algunos distribuidores tienen los suyos. PHP 8.2 llega a fin de vida el 31 de diciembre de 2026. Varias firmas de seguridad ya reportan exploits públicos e intentos de explotación.

El aviso llegó un mes después de otra ronda de seguridad. El 24 de septiembre, las versiones 8.5.11, 8.4.26, 8.3.35 y 8.2.34 corrigieron, entre otros, CVE-2026-91768 (en PHP-FPM, la ACL listen.allowed_clients comparaba solo 12 de los 16 bytes de una dirección IPv6), CVE-2026-91766 (el wrapper HTTP reenviaba cabeceras de credenciales al seguir redirecciones hacia otro origen) y CVE-2026-91765 (una recursión sin límite en el servidor SOAP que permite a un atacante sin autenticar tumbar el proceso). Los dos primeros son problemas de control de acceso y los retomamos más abajo.

Por qué el inicio de sesión no protege frente a estos CVE

Las rutas de explotación que describen los avisos no pasan por el inicio de sesión de la aplicación. En mod_php todo ocurre antes de que empiece a ejecutarse el código de la aplicación; en FPM la ruta confirmada pasa por la aplicación, pero no exige que el atacante se haya autenticado. El formulario de login, el MFA de la aplicación, las políticas de contraseñas y las recertificaciones de roles que gestiona IGA quedan fuera del camino del exploit.

Para un sitio PHP público, como el portal corporativo, una tienda o un CMS, la respuesta es parchar y reiniciar todos los workers. Las medidas temporales que publicó el proyecto PHP para quien no pueda actualizar de inmediato están en la lista práctica, al final, con sus límites.

El papel de IAM en las aplicaciones que no deberían ser públicas

La mayoría de las organizaciones tiene más PHP del que cree: paneles de bases de datos, herramientas de monitoreo, wikis, consolas de proveedores. Muchas de esas aplicaciones están en internet protegidas solo por su propia pantalla de inicio de sesión, que contra estos CVE no sirve.

Un proxy consciente de identidad, que exige una sesión SSO válida antes de reenviar cualquier petición al servidor PHP, cambia quién puede llegar al worker vulnerable: ya no cualquiera en internet, sino usuarios autenticados con MFA. Funciona con dos condiciones. El proxy tiene que terminar la autenticación por sí mismo, porque si solo reenvía y deja que la aplicación valide la sesión, la petición ya llegó al runtime. Y la red tiene que impedir el acceso directo al servidor de origen. Lo que se gana es menos exposición mientras se actualiza, no un motivo para posponer la actualización. Además, una cuenta comprometida sigue pudiendo llegar.

Otros CVE de PHP dependen de que el atacante tenga acceso a una función protegida, por ejemplo una deserialización insegura en un módulo administrativo. Ahí SSO con MFA reduce las cuentas que un atacante puede usar, el mínimo privilegio limita lo que expone cada una, y la baja automática de cuentas huérfanas, que es trabajo de IGA, elimina credenciales olvidadas. Conviene verificar que la función esté de verdad detrás de la autenticación: el servidor SOAP de CVE-2026-91765 se podía atacar sin autenticar en cualquier endpoint SoapServer accesible.

Para las fallas locales, que requieren algún punto de apoyo en el servidor, el terreno es PAM: cuentas nominales en lugar de root compartido, sesiones grabadas y elevación por tiempo limitado. Ese punto de apoyo no tiene que ser una cuenta legítima; también puede venir de explotar una aplicación, de credenciales robadas o de un movimiento lateral.

Qué pasa cuando el atacante ya ejecuta código

Si la aplicación es pública y el parche llegó tarde, el atacante corre código con los privilegios del worker web, como dicen los avisos. Lo que pueda hacer a partir de ahí depende de decisiones tomadas antes del incidente:

Una cuenta de servicio por aplicación en PHP-FPM, sin escritura sobre su propio código ni acceso a otros pools. La separación solo funciona si los permisos la respaldan: pools con usuarios distintos que comparten directorios, archivos de configuración legibles o credenciales quedan casi igual de expuestos.
Credenciales de base de datos propias de la aplicación y con el mínimo privilegio, nunca root ni un usuario con acceso a todos los esquemas.
Secretos fuera del alcance del worker. Sacarlos del webroot evita que se descarguen por error, pero quien ejecuta código como www-data lee todo lo que www-data puede leer.
Inventario, dueño y rotación para las credenciales de servicio. Es gobierno de identidades no humanas, y es donde IGA y PAM aportan más en un incidente así. Tras una exposición hay que asumir que se leyó todo lo que el worker podía leer, y si rotarlo toma semanas porque nadie sabe dónde más se usa, el incidente dura semanas.
Detección de uso anómalo de credenciales de aplicación, como una cuenta de base de datos que consulta tablas que nunca tocó o un token de API usado desde otra dirección.

Los CVE de septiembre que tocan el control de acceso

En CVE-2026-91768, listen.allowed_clients es la lista de direcciones IP que pueden hablar FastCGI con un pool de PHP-FPM, y en IPv6 bastaba con coincidir en los primeros 96 bits para pasar. El aviso aclara que no afecta a sockets Unix, a despliegues solo IPv4 ni a quien tiene un firewall externo como frontera real. El problema de fondo es usar la dirección de red como autorización: cuando esa verificación falla, no queda otro control. Con FPM en un socket Unix o una regla de firewall acotada al servidor web concreto, el error de comparación no habría importado.

CVE-2026-91766 afecta a aplicaciones que llaman a una API con file_get_contents() o fopen() y pasan credenciales en las cabeceras Authorization o Cookie. Al seguir una redirección hacia otro dominio, otro puerto o de HTTPS a HTTP, PHP reenviaba esas cabeceras sin cambios, y quien controlara el destino recibía el token o la cookie. Los tokens de corta duración emitidos por un proveedor de identidad acortan el tiempo en que una credencial filtrada sirve, aunque no impiden que se use de inmediato; por eso conviene combinarlos con audiencia y permisos restringidos, control de redirecciones, revocación donde exista y, donde proceda, tokens vinculados al cliente.

Lista práctica

Infraestructura, para hoy

Inventariar toda instalación de PHP que atienda peticiones web, incluidas las que "nadie usa".
Actualizar cada rama a su versión corregida (8.2.35, 8.3.36, 8.4.27 u 8.5.12), o al paquete del distribuidor que incorpore los parches, verificado y no asumido, y reiniciar todos los workers.
Verificar en producción la versión que realmente carga cada SAPI y que los workers antiguos dejaron de atender peticiones.
Si el parche no puede aplicarse hoy, usar solo las mitigaciones parciales que el aviso describe para cada CVE, documentar la exposición residual y planear la salida de 8.1 y anteriores:
- CVE-2026-109618: memory_limit=-1 impuesto de forma que ningún pool, directorio o aplicación restablezca un límite finito, y límites de tamaño y complejidad de las peticiones en el frontend.
- CVE-2026-109619: session.upload_progress.enabled=0 y, en 8.5, fatal_error_backtraces=0.
- Aplicarlas en php.ini, el pool de FPM o la configuración del servidor, no con ini_set() ni .user.ini, y evaluar su efecto antes de cambiar la configuración.
Deshabilitar session.upload_progress si no se usa, incluso después de parchar, como recomienda el propio aviso.

Identidad y acceso

Clasificar cada aplicación PHP: ¿debe ser pública, o solo la usan personas identificables? Las segundas van detrás de un proxy consciente de identidad con SSO y MFA, sin acceso directo al origen.
Una cuenta de servicio por aplicación para PHP-FPM, sin privilegios cruzados.
Credenciales de base de datos y de API con mínimo privilegio, inventariadas, con dueño y rotación.
Secretos fuera del alcance innecesario del worker; tokens de corta duración y acotados en lugar de contraseñas estáticas donde sea viable.
Acceso administrativo a servidores vía PAM: cuentas nominales, sesiones grabadas, sin root compartido.
Alertas sobre uso anómalo de las credenciales de la aplicación, no solo de las personas.
Reemplazar las ACL por dirección IP como único control por sockets Unix o reglas acotadas al origen real.

Nuestra opinión

Con el uso de la IA, avisos como este son inevitables: la IA acelera tanto el descubrimiento de fallas, con análisis de código y fuzzing asistidos, como la construcción de exploits a partir de un parche publicado. En este caso, varias firmas reportaron exploits públicos a los pocos días del aviso. No vemos forma de evitar que aparezcan; lo que está en nuestras manos es minimizar los riesgos y reducir sus efectos, y eso depende sobre todo de tener procedimientos automatizados: prácticas DevOps, infraestructura como código, despliegue de configuraciones y escaneos.

En este caso se ve con claridad. Con la configuración versionada, aplicar session.upload_progress.enabled=0 en todos los pools es un cambio y un despliegue, no una revisión servidor por servidor. Con escaneos periódicos, el inventario incluye las instalaciones que nadie recuerda. Y con la deuda técnica gestionada, con un calendario de fin de vida para cada versión de PHP, no quedan servidores en 8.1 o anteriores, que ya no reciben versiones oficiales y dependen de backports o de su distribuidor para salir de un aviso así.

En Clear Intelligence revisamos con frecuencia arquitecturas donde cualquiera puede llegar a un servidor como este y la cuenta del worker puede leerlo prácticamente todo. Reducir ambas cosas no evita el siguiente CVE, pero cambia lo que un atacante puede hacer con él.

Fuentes

Servicios relacionados

Health Check IAM — Identifique qué aplicaciones internas están expuestas sin control de identidad y qué cuentas de servicio tienen más privilegios de los que necesitan.
Integraciones — Ponga sus aplicaciones internas detrás de SSO y MFA mediante un proxy consciente de identidad integrado con su plataforma IAM.
Managed Support — Operación continua con inventario de credenciales, rotación y detección de uso anómalo.