php2shell en PHP: dos fallas de ejecución remota sin autenticar y las cuatro versiones que las cierran

Si tenés un sitio propio, lo primero es un número. Las versiones de PHP que corrigen estas dos fallas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Todo lo anterior dentro de cada rama está afectado.

Las dos fallas se conocen en conjunto como php2shell, y según el aviso de CISA alcanzan a todas las instalaciones de PHP que atienden pedidos web. Las dos permiten ejecución remota de código sin autenticarse: sin usuario, sin clave y sin que nadie haga clic en nada.

Y si corrés PHP 8.1 o anterior, que ya no tiene soporte, la recomendación de CISA no es "actualizá cuando puedas". Es, textual, bajar los sistemas basados en PHP hasta poder parchearlos o actualizarlos. Es la indicación más fuerte que vi en un aviso de este año, y conviene leerla dos veces si tu hosting todavía sirve una rama vieja.

Las cuatro ramas de PHP, y qué versión corrige en cada una

Las dos fallas comparten exactamente el mismo rango afectado y las mismas versiones corregidas, así que acá no hay que hacer la cuenta de dos parches: una sola actualización cierra las dos.

Vale ubicar el caso: el intérprete de PHP en sí mismo —no un framework, no una librería— entró al catálogo de fallas explotadas de CISA en 2022 por CVE-2012-1823 y en 2024 por CVE-2024-4577. Con estas dos, van tres episodios en poco más de 4 años, y es la primera vez que entran dos fallas del intérprete el mismo día.

Un detalle que conviene decir con precisión: los avisos del proyecto listan solamente las ramas 8.2, 8.3, 8.4 y 8.5. No mencionan la 8.1 ni anteriores, y eso no significa que estén a salvo: significa que ya no reciben parches. Por eso la indicación de CISA para esas ramas es distinta en naturaleza, no en grado.

Qué son las dos fallas, y por qué Apache con mod_php es el peor caso

Las dos son problemas de memoria que sobrevive a lo que debería limpiarla, y las dos terminan en ejecución de código. El mecanismo, en los términos del propio proyecto:

CVE-2026-109618, "RCE via OOM corruption". PHP usa longjmp() para salir del contexto cuando se queda sin memoria y abortar el pedido. Algunos contextos no contemplan ese escenario y dejan la memoria del pedido sin inicializar antes de hacer una asignación. El procedimiento de limpieza posterior puede leer esa memoria o tomar decisiones con ella. El aviso dice que varias estrategias de agotamiento de memoria disparan la condición de forma consistente.

CVE-2026-109619, "RCE via stale global state". PHP tiene estado global que apunta temporalmente a la memoria del pedido. En algunos escenarios ese estado no se reinicia bien, o se vuelve a llenar después de haberse reiniciado, y queda apuntando a memoria ya liberada. Pedidos posteriores pueden leer ese estado rancio antes de que esté inicializado. El aviso lo resume así: "una disposición del montículo cuidadosamente construida puede producir ejecución remota de código completa".

La diferencia entre formas de servir PHP es la parte más útil del aviso, y explica por qué el titular es tan fuerte. Para la falla del agotamiento de memoria, el proyecto dice que validó un exploit remoto completo sobre HTTP contra mod_php, y además con los límites por defecto de entrada y de memoria y una configuración prefork normal. O sea: sin configuración rara, sin nada subido de tono.

El motivo técnico que da es concreto: mod_php invoca el procedimiento de cierre del pedido de forma incondicional, incluso cuando el arranque del pedido falló. FPM, en cambio, mata al hijo cuando el arranque falla, y ahí el aviso aclara que el análisis del código lo señala como susceptible pero que no se demostró un exploit completo para ese caso.

Para la segunda falla el reparto cambia: el caso del ciclo de vida de sesión se validó contra mod_php y contra FPM, y FPM queda expuesto de forma condicional cuando un frontend le manda parámetros PHP_VALUE o PHP_ADMIN_VALUE.

Dónde NVD y PHP no coinciden al puntuar CVE-2026-109618

Acá hay algo que vale la pena mirar, justo después de la medición de ayer sobre quién calcula los puntajes: estas dos fichas sí tienen puntaje propio de NVD, y no coincide con el del proyecto.

Para CVE-2026-109618, el proyecto PHP publica 9,2 en CVSS 4.0 con un vector que dice complejidad alta y requisitos de ataque presentes. NVD publica 9,8 en CVSS 3.1 con complejidad baja. Para CVE-2026-109619 las dos fuentes coinciden en que la complejidad es alta, y los números son 9,2 y 8,1.

Las dos escalas no definen igual la complejidad, y la 4.0 tiene una métrica aparte para los requisitos, así que no es una contradicción entre números comparables. Pero para quien prioriza con el número, la consecuencia es clara: el 9,8 no incorpora la condicionalidad que el propio proyecto considera parte del problema. Si tu criterio es "9,8 se atiende hoy", está bien; si es "9,2 con complejidad alta espera", el aviso del proyecto no te está diciendo que esperes.

¿A quién afecta php2shell?

A cualquier sitio o aplicación que corra PHP para atender pedidos web, y eso en la región es casi todo:

Si tenés un WordPress, un Magento, un Nextcloud o cualquier aplicación PHP, la falla no está en la aplicación sino en el intérprete que la ejecuta. No alcanza con tener los plugins al día. Es la diferencia con casos como la falla de WordPress explotada el mismo día o la del CODE Server de Nextcloud: acá el agujero está una capa más abajo.

Si estás en hosting compartido, la versión de PHP la decide en buena medida tu proveedor, aunque en el panel suela haber un selector. Qué queda de tu lado y qué del lado del hosting está desarrollado en qué cubre el hosting en materia de seguridad.

Si administrás sitios de clientes, el trabajo es de inventario, y CISA lo dice con una advertencia que conviene repetir: PHP "suele ser un componente de otro software y su prevalencia puede no ser directamente observable". O sea que hay PHP en lugares donde nadie lo anotó.

Si tenés una aplicación interna en PHP que no mira a internet, bajás varios escalones de urgencia, pero no a cero: la cadena arranca sin credenciales, así que cualquiera que llegue a la red llega al intérprete.

¿Quién puede ignorar el plazo del 29 de octubre?

El plazo del 29 de octubre —3 días desde el alta en el catálogo, o sea que faltan 2 días— obliga a las agencias federales civiles de Estados Unidos por la directiva que cita el catálogo. Si tenés una PyME en Latinoamérica, no te obliga.

Pero esta vez el plazo es lo menos interesante, por dos motivos. El primero es que la versión corregida salió el 21 de octubre, así que ya lleva 6 días disponible. El segundo es más incómodo y conviene decirlo con cuidado: ni los avisos del proyecto ni el texto de la alerta de CISA describen explotación observada en el mundo real. Los avisos describen pruebas de concepto validadas por quienes reportaron las fallas. Lo que sí hizo CISA fue sumarlas al catálogo de fallas explotadas el 26 de octubre, 5 días después de publicar su propia alerta, y estar en ese catálogo significa, por definición, explotación conocida. Dicho de otro modo: CISA está afirmando algo que su propio texto no detalla, y no voy a inventar la explicación.

Quien no corra PHP en ningún lado puede cerrar la página, con el asterisco del inventario: conviene estar seguro, no suponerlo.

¿Cómo sé qué versión de PHP corre mi sitio?

De la más rápida a la más confiable:

1. En el panel del hosting. Casi todos los paneles tienen un selector de versión de PHP que muestra la activa. Ojo: suele mostrar la rama, "8.3", y lo que necesitás es el número completo, porque la diferencia entre 8.3.35 y 8.3.36 es justamente esta falla.
2. Por línea de comandos, si tenés acceso: php -v. Devuelve la versión completa en la primera línea. Si usás FPM, la versión que importa es la del binario que atiende los pedidos, que puede no ser la misma que la del CLI.
3. Preguntándole al proveedor, y acá la pregunta tiene que ser precisa: no "¿están al día?" sino "¿en qué versión completa de PHP está mi sitio y cuándo pasa a 8.2.35, 8.3.36, 8.4.27 o 8.5.12?". Cómo se piden y se contestan esas cosas por escrito está en cómo responder un cuestionario de seguridad de un cliente.

Lo que no conviene es publicar la versión de PHP en una página de diagnóstico accesible desde internet para averiguarlo. Si existe una, ese es otro problema a resolver.

Y para detectar actividad, CISA da una señal concreta y buena: vigilar procesos de trabajo de PHP que lancen shells o descarguen herramientas. Un php-fpm que ejecuta sh, curl o wget es anómalo por lo que hace, no por su contenido. Mirar conducta y no firmas es la diferencia que explico en cuándo se justifica un EDR en una PyME y en la categoría de antivirus y EDR.

¿Qué hago si no puedo actualizar PHP ya mismo?

Primero, la frase que los dos avisos repiten de distinta forma: actualizar es la única mitigación completa. Para la falla del OOM dice que "actualizar a una versión de PHP que contenga el parche es la única mitigación completa"; para la del estado rancio, que "actualizar a una versión que contenga el parche completo de reinicio de estado es la única mitigación confiable". Todo lo que sigue es para ganar tiempo, no para quedarse.

1. Si estás en 8.1 o anterior, considerá bajar el servicio. Es lo que recomienda CISA para versiones sin soporte, y no hay parche que aplicar.
2. Desactivá session.upload_progress.enabled si no lo usás, y reiniciá todos los trabajadores. El aviso dice que viene habilitado por defecto y sugiere desactivarlo incluso después de parchear si la función no hace falta.
3. Si estás en PHP 8.5 y no podés actualizar, poné fatal_error_backtraces=0 y reiniciá todos los trabajadores: el caso confirmado más fuerte de la segunda falla depende de esa opción.
4. Apretá los límites de entrada: un post_max_size conservador, un max_input_nesting_level reducido, y límites a variables de entrada, partes de multipart, encabezados y subidas. Si tu aplicación no usa multipart, el aviso sugiere bloquearlo directamente en el frontend.
5. Un WAF puede dar algo de protección hasta que parchees, según CISA. Algo, no todo.
6. Lo que NO sirve, y es importante porque es tentador: el aviso advierte contra usar RLIMIT_AS y RLIMIT_DATA. Y aclara que fijar memory_limit=-1 de forma administrativa no es una mitigación completa, aunque lo menciona como opción para sistemas que no pueden actualizar.

El encuadre más amplio de qué pedirle a la infraestructura de una PyME está en la guía de ciberseguridad para PyMEs de LATAM, y el caso de una tienda con PHP por debajo, en la falla de Magento y Adobe Commerce.

Una aclaración sobre las fuentes. Lo que sí pude leer: los dos avisos del proyecto php-src, GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp, publicados el 21 de octubre de 2026, de donde salen los rangos afectados, las versiones corregidas, los vectores CVSS del proyecto, el reparto por forma de servir PHP, las precondiciones, las mitigaciones y las advertencias sobre lo que no sirve; la alerta de CISA del 21 de octubre, revisada por última vez el 26, de donde salen el nombre php2shell, el alcance declarado, la recomendación para versiones sin soporte y la señal de detección; las fichas de la API de NVD de las dos CVE, de donde salen los puntajes primarios de NVD y su contraste con los del proyecto; y el feed JSON del catálogo KEV, de donde salen el alta del 26 de octubre y el plazo del 29. Lo que no voy a enlazar: el análisis técnico público que referencia NVD ni el repositorio que enlaza la alerta de CISA. El mecanismo y la detección están arriba; el paso a paso no, y en este caso menos que nunca, porque el parche recién salió. Lo que no se puede afirmar: que haya explotación observada en el mundo real, porque ninguna de las dos fuentes primarias la describe, aunque el alta en el catálogo de CISA implique explotación conocida.

Preguntas frecuentes sobre php2shell en PHP

¿Qué versión de PHP tengo que tener?

8.2.35, 8.3.36, 8.4.27 o 8.5.12, según la rama en la que estés. Las dos fallas comparten el mismo rango afectado y las mismas versiones corregidas, así que una sola actualización cierra las dos. Lo importante es comparar el número completo y no la rama: entre 8.3.35 y 8.3.36 está justamente esta falla.

Estoy en PHP 8.1, que ya no tiene soporte. ¿Qué hago?

Los avisos del proyecto no listan la 8.1 ni anteriores, porque esas ramas ya no reciben parches, y la recomendación de CISA para ese caso es más fuerte que "actualizá pronto": dice bajar los sistemas basados en PHP hasta poder parchearlos o actualizarlos. En la práctica, el camino es pasar a una rama con soporte. Si eso lleva trabajo de compatibilidad, el aviso te está diciendo que ese trabajo es más urgente que el resto.

Uso PHP-FPM y no mod_php. ¿Estoy mejor?

Para una de las dos fallas, sí, y el aviso lo dice con cuidado: en la falla del agotamiento de memoria, FPM aparece como susceptible por el análisis del código pero no se demostró un exploit completo para ese caso, mientras que contra mod_php se validó uno completo sobre HTTP con configuración por defecto. Para la otra falla, la del estado rancio, el camino del progreso de subida de sesión se validó contra FPM además de mod_php. O sea: estar en FPM reduce el riesgo en un caso y no en el otro. No es una razón para no actualizar.

¿Alcanza con tener WordPress y los plugins al día?

No, porque la falla no está en WordPress ni en los plugins sino en el intérprete de PHP que los ejecuta. Es una capa más abajo de lo que actualiza el panel de WordPress. Si estás en hosting compartido, la versión de PHP suele elegirse en el panel del proveedor, y eso es lo que hay que mirar. Un WAF puede ayudar un poco mientras tanto, según CISA, pero no reemplaza la actualización.

¿Está siendo explotada de verdad?

Con los documentos en la mano, lo honesto es decir que no se puede afirmar. CISA sumó las dos CVE a su catálogo de fallas explotadas el 26 de octubre, y estar en ese catálogo significa explotación conocida. Pero ni los avisos del proyecto PHP ni el texto de la alerta de CISA describen explotación observada en el mundo real: lo que describen son pruebas de concepto validadas por quienes reportaron las fallas, una de ellas un exploit remoto completo contra Apache con mod_php. Para decidir qué hacer, la diferencia no cambia nada: la versión corregida existe desde el 21 de octubre, hace 6 días.