php2shell: qué es y cómo corregir el PHP ahora

El 21 de octubre de 2026 el proyecto PHP publicó correcciones de emergencia para dos fallas críticas de ejecución remota de código sin autenticación. Esas fallas se rastrean como CVE-2026-109618 y CVE-2026-109619 y se conocen de forma amplia como php2shell. El riesgo no depende de un plugin frágil ni de un tema mal escrito. El php2shell vive en el runtime que procesa la solicitud HTTP. Eso cambia la prioridad de respuesta para quien opera un sitio, una API o un servicio de hospedaje.

Si usted mantiene WordPress, Laravel, Drupal, un panel o un contenedor con imagen oficial de PHP, el primer paso es inventariar la versión que atiende el tráfico. Lo mismo vale si la aplicación corre detrás de PHP-FPM o de Apache con mod_php. Esta guía asume el lado de defensa y operación. Explica lo que confirman las fuentes abiertas sobre php2shell, dónde divergen, cómo medir exposición, cómo corregir y qué reducir mientras el parche aún no entra.

El texto no enseña explotación. Sirve para decidir qué hacer mañana en el inventario, en el pipeline y en la ventana de mantenimiento. Cada recomendación incluye riesgos y límites.

Qué es el php2shell y por qué importa ahora#

El php2shell es el nombre informal del conjunto formado por CVE-2026-109618 y CVE-2026-109619. Son dos vulnerabilidades de memoria en el núcleo de PHP. En las condiciones adecuadas, un atacante sin inicio de sesión puede ejecutar código con los privilegios del worker web.

El aviso de seguridad en el archive de php.net describe la primera como corrupción ligada al tratamiento de falta de memoria. La segunda aparece como reutilización de estado global envejecido entre solicitudes en el mismo worker. La PHP Foundation refuerza, el mismo día, que ambas tocan gestión de memoria y tratamiento de error. Esos caminos son casi inevitables en toda solicitud.

La nota oficial y las alertas de gobierno que la repiten atribuyen CVSS v4.0 9.2 a cada CVE. Antes del anuncio completo circuló la idea de una nota 10.0. Trate 9.2 como la referencia publicada por el proyecto y por los organismos que citan el parecer del CNA. Trate la nota inflada como rumor hasta que exista un registro oficial que la sustente.

El impacto práctico es amplio porque el ataque apunta al intérprete, no a la lógica de su aplicación. En Apache con mod_php, el equipo de PHP y la Foundation relatan explotación demostrada. En ese escenario, la solicitud dispara el camino vulnerable antes de cualquier código de la aplicación. En PHP-FPM, el RCE también fue confirmado por caminos a nivel de aplicación. Las descripciones técnicas también hablan de divulgación de memoria sensible del proceso. Eso puede exponer secretos de otras solicitudes en el mismo worker.

En la práctica, lo que veo con más frecuencia es un equipo que trata el php2shell como un error del CMS. El problema suele estar en el binario de PHP bajo ese CMS. Quien tarda en separar runtime de aplicación pierde la ventana en la que el parche aún es barato.

Cómo leer las fuentes sobre explotación del php2shell#

Sobre explotación real del php2shell, las fuentes no hablan el mismo idioma. La alerta de la CISA del 21 de octubre de 2026 afirma que, en el momento de la publicación, la agencia no había observado explotación. En cambio, sensores comerciales y reportajes del mismo día describen tráfico de ataque e intentos tras una filtración previa de detalles.

La lectura responsable es esta. Los intentos existen según varios sensores. Un compromiso exitoso a gran escala no es un hecho uniforme y confirmado por todas las autoridades en el mismo instante. El riesgo operativo del php2shell, sin embargo, no espera consenso.

Quién está afectado por las fallas de PHP#

Según el aviso oficial, toda instalación de PHP que sirve solicitudes web está en riesgo frente al php2shell. Eso incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo se considera más alto en mod_php, porque allí existe demostración de un disparador sin autenticación antes del código de la aplicación. Eso cubre buena parte de internet clásica de hospedaje compartido y muchos stacks heredados.

También entran en el inventario productos que embuten PHP sin que usted lo note. Paneles, appliances, imágenes Docker antiguas y entornos gestionados cuentan. El NCSC de Suiza y la CISA piden inventario más allá del sitio visible. El hospedaje gestionado puede parecer fuera de su mano, pero la cuenta sigue siendo suya hasta que el proveedor confirme el paquete corregido.

En Linux, el NCSC suizo alerta además que una major version igual no prueba ausencia de parche. El backport puede mantener el número aparente y cambiar el contenido del paquete. El error que más cuesta caro aquí es inventariar solo el WordPress de la vitrina. Quien olvida el segundo PHP del panel interno, del cron web o del contenedor de staging expuesto deja la puerta abierta. El atacante no respeta el organigrama del equipo.

Qué versiones cierran el php2shell y dónde hay divergencia#

Las versiones corregidas publicadas el 21 de octubre de 2026 son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las líneas anteriores a esas, dentro de cada rama soportada, entran como afectadas en los advisories GHSA de php-src. El proyecto PHP deja claro que 8.1 y versiones más antiguas ya no reciben actualizaciones oficiales de la línea principal. Las distribuciones y los proveedores LTS pueden publicar backport. Para quien compila desde el código fuente sin LTS, el equipo de seguridad publicó backports mínimos de fuente para 7.4, 8.0 y 8.1.

Hay una divergencia importante sobre el alcance histórico. Informes de investigadores y de Cloudflare afirman impacto desde PHP 5.4, es decir, una década o más de releases. El aviso oficial de php.net, en la forma leída en esta sesión, no usa esa frase como confirmación única. Se centra en las líneas con parche publicado, en el fin de vida de 8.1 y en los backports.

En un texto editorial responsable, diga que Cloudflare y los grupos de investigación citados en la divulgación afirman alcance desde 5.4. Lo que el vendor confirma de forma operativa es otra cosa. Hay que actualizar a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, u obtener un paquete backporteado del proveedor. Esa es la respuesta operativa al php2shell.

Cómo saber si su PHP está vulnerable#

Usted descubre exposición al php2shell cruzando tres datos. Necesita la versión del runtime que atiende HTTP, el origen del paquete y el SAPI en uso. Ejecutar php -v en el shell ayuda, pero no basta si el sitio usa otro binario vía FPM o módulo de Apache. Confirme la versión reportada por la propia aplicación en un entorno controlado. Use phpinfo() solo en red administrativa. Revise también el paquete de la distribución y la etiqueta de la imagen del contenedor.

Orden práctico sugerido.

1. Liste hosts y servicios que responden contenido dinámico en PHP, públicos e internos.
2. Identifique el SAPI, si es mod_php, PHP-FPM, cgi, FrankenPHP o LiteSpeed, porque la prioridad del parche sube con mod_php expuesto.
3. Anote la versión exacta y el paquete. En Debian y Ubuntu, el número del paquete y el changelog de seguridad importan tanto como el PHP_VERSION. En RHEL y clones, el advisory del vendor manda.
4. En contenedor, lea la imagen en ejecución y la fecha del build. Una imagen php:8.4 tirada semanas atrás puede seguir por debajo de PHP 8.4.27.
5. En hospedaje gestionado, pida confirmación escrita de la versión corregida o del ticket de seguridad. Mientras no haya confirmación, trátelo como vulnerable al php2shell.
6. Si está en 8.1 o inferior sin backport del vendor, considérselo vulnerable y sin camino oficial del proyecto PHP, salvo el backport mínimo de fuente o la migración.

Si la versión es menor que 8.5.12 en la línea 8.5, menor que 8.4.27 en la 8.4, menor que 8.3.36 en la 8.3 o menor que 8.2.35 en la 8.2, y no hay evidencia de backport, usted está en la zona de corrección inmediata. Para 8.1 y anteriores, la pregunta deja de ser qué parche de php.net aplica. Pasa a ser qué paquete del vendor o qué fecha de migración.

Mucha gente confía solo en el php -v del SSH y casi siempre está equivocada, porque el worker del sitio puede ser otro archivo. Confirme el binario del pool FPM o del módulo Apache antes de marcar el ítem de php2shell como resuelto.

Cómo aplicar la corrección PHP RCE con versiones oficiales#

La única remediación completa del php2shell, en palabras del propio proyecto PHP y repetida por CISA, el NCSC del Reino Unido y CERT europeos, es actualizar el runtime. El objetivo oficial del 21 de octubre de 2026 es claro.

El orden de prioridad que la mayoría de las operaciones debería seguir coloca primero los servicios internet-facing con mod_php. Después van los internet-facing con PHP-FPM. Luego entran los sistemas internos con datos sensibles. Al final queda el resto del inventario. Después de instalar el paquete, reinicie Apache, PHP-FPM o el equivalente. Confirme la versión en el proceso que realmente atiende. Un contenedor exige rebuild y redeploy de la imagen, no solo restart de la etiqueta antigua.

El advisory GHSA de la CVE-2026-109618 deja explícito que solo el release con el parche es mitigación completa. Actualizar PHP 8.5.12 o la línea equivalente que su proyecto soporte cierra la corrección PHP RCE de forma completa solo cuando el proceso vivo ya corre ese binario.

Remirepo, líneas muertas y compromiso previo#

Si usted depende de rpms.remirepo.net, el aviso de php.net en esta fecha pidió migración a paquetes de la distribución o build a partir del código fuente. Ese repositorio voluntario no tendría updates el mismo día. Quien está en 7.4, 8.0 u 8.1 sin LTS necesita decidir entre backport mínimo de fuente, paquete del vendor o salto a una línea soportada. Ninguna de esas opciones es gratis en regresión. Pruebe la aplicación, en especial extensiones nativas y pecl.

La corrección del runtime no limpia un compromiso previo. Si hay indicios de shell, descarga extraña desde el worker o alteración de archivos, abra el playbook de respuesta a incidentes. Trátelo como incidente, no como solo un parche. Un programa de gestión de vulnerabilidades ayuda a no repetir la misma sorpresa en la próxima CVE del runtime.

Quien deja el parche del php2shell para el sprint que viene suele descubrir que la regresión del upgrade era menor que el costo de aislar el sitio a mitad de la jornada. Programe la ventana corta y mida después.

Qué hacer mientras aún no puede actualizar#

Mientras el parche del php2shell no entra, reduzca superficie. Acepte que ninguna mitigación parcial vuelve segura la instalación. El NCSC del Reino Unido pidió preparación para una actualización inmediata. Si la remediación no es viable, pidió considerar sacar el sistema del aire hasta mitigar de verdad. La CISA repite la lógica de offline para quien no actualiza y aún usa 8.1 o anterior sin corrección.

Mitigaciones parciales descritas para CVE-2026-109618 y CVE-2026-109619#

Medidas transitorias descritas por el aviso de php.net y por el advisory GHSA para la CVE-2026-109618 incluyen forzar memory_limit=-1 de modo administrativo. Eso puede hacerse con php_admin_value en el pool FPM o en Apache, de forma que la aplicación no reinserte un límite finito. También recomiendan post_max_size bajo, 8M sin upload o 32M cuando el upload sea necesario, con upload_max_filesize por debajo de ese techo. Piden límites en el proxy para tamaño decodificado, campos, partes multipart y profundidad, incluso cuando no haya un Content-Length útil. Un límite de cgroup o contenedor puede servir de frontera de disponibilidad si mata solo el worker afectado. No use RLIMIT_AS ni RLIMIT_DATA en su lugar, porque eso puede provocar la falla de asignación en el camino vulnerable.

Para la CVE-2026-109619, el aviso pide session.upload_progress.enabled=0 en una configuración aplicada antes del parse de la solicitud, con restart de todos los workers. No dependa de ini_set() ni de .user.ini. En PHP 8.5, también fatal_error_backtraces=0 con restart. Elimine ajustes inválidos o deprecados que emiten diagnóstico demasiado pronto. Ocultar el error con display_errors no resuelve el php2shell.

El WAF ayuda como capa extra. Cloudflare reportó protecciones WAF implantadas antes de la divulgación pública y pidió el parche de todos modos. CISA y el NCSC suizo dicen lo mismo. El WAF solo no basta. Restringir acceso por VPN o allowlist, apagar internet en sistemas que no la necesitan y aislar uploads son controles de contención, no cura.

El costo oculto de estas mitigaciones es la rotura de upload, formulario grande y progreso de sesión. Mida el efecto en staging. Si el negocio no aguanta el efecto colateral y el parche se atrasa, la alternativa honesta del NCSC permanece. Saque del aire lo que no puede corregirse frente al php2shell.

Quien aplica solo la regla de WAF y marca el ticket como cerrado cambia riesgo técnico por riesgo de falsa seguridad. Use las mitigaciones para comprar horas, no semanas.

Hardening que reduce el radio de explosión después del parche#

Después de actualizar contra el php2shell, endurezca el entorno. La próxima falla de worker no debería convertirse en un dominio entero comprometido. El aislamiento por pool FPM por sitio, un usuario Linux distinto, un filesystem de código lo más de solo lectura posible y secretos fuera del document root siguen válidos. Los límites de cuerpo en el proxy y en PHP reducen la presión de memoria incluso después del parche.

El CERT-EU y la CISA piden monitoreo de reinicios anormales de worker, picos de multipart y procesos hijos inesperados de PHP. Incluyen workers que disparan shell o descarga. La observabilidad no sustituye el parche, pero evita descubrir el incidente solo por el defacement. Encamine logs de acceso, error del FPM y audit del host a la misma traza usada en el análisis de logs en respuesta a incidentes.

Si sospecha acceso previo, la caza de persistencia entra como etapa propia. Actualizar PHP no elimina un webshell ya grabado. Hay un límite claro. El hardening reduce radio y acelera la respuesta. No anula una CVE crítica en el runtime mientras la versión vulnerable al php2shell aún atiende internet.

En la operación del día a día, lo que separa un parche aplicado de un entorno bajo control es confirmar el proceso vivo y el comportamiento después del restart, no solo el paquete en dpkg. Sin esa verificación, el inventario miente con elegancia.

Checklist para desarrolladores frente al php2shell#

Use esta lista para cerrar exposición al php2shell en build, CI y producción sin confundir CLI con SAPI web.

1. Descubra qué versión de PHP usa de verdad cada entorno de build, CI, staging y producción en el SAPI web, no solo en el CLI.
2. Actualice imágenes base, Dockerfile y lock de runtime a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según la línea que el proyecto soporte.
3. Ejecute la suite de pruebas y un smoke de upload, sesión y formulario multipart, porque las mitigaciones transitorias y los cambios de límite rompen flujos legítimos.
4. Elimine la dependencia de session.upload_progress si aún existe en la UX, ya que el camino fue citado en las mitigaciones de la CVE-2026-109619.
5. Trate el fatal error y el timeout alcanzables por entrada del usuario como deuda de seguridad, no solo de UX, porque el aviso vincula estado residual a errores fatales mal limpiados.
6. No publique exploit, PoC funcional ni payload. El papel del equipo de producto es cerrar exposición y documentar la versión corregida en el runbook del servicio.
7. Pida al equipo de plataforma confirmación del paquete en hospedaje gestionado antes de marcar la historia del php2shell como lista.

El desarrollador que solo sube la imagen local y olvida el worker de producción deja el riesgo exactamente donde el atacante mira primero. Cierre el ciclo con evidencia de la versión en el proceso remoto.

Checklist para operaciones y hospedaje#

Ops debe tratar el php2shell como incidente de runtime, no como ticket de plugin.

1. Inventarie todo PHP que atiende HTTP, incluidos appliance, panel, contenedor y SaaS autogestionado.
2. Priorice internet-facing y mod_php, después FPM público, y luego el resto.
3. Aplique el paquete del vendor o el release oficial, reinicie workers y valide la versión en el proceso activo.
4. Si no puede parchear de inmediato, evalúe offline según NCSC y CISA, aplique mitigaciones parciales del aviso de php.net y mantenga el WAF actualizado sin tratar eso como cierre.
5. Monitoree workers que disparan shell, curl o descarga, crashes en serie y uploads multipart anómalos.
6. Exija al proveedor de hospedaje la versión corregida por escrito y la fecha de aplicación.
7. Después del parche, revise indicadores de compromiso previo antes de declarar victoria frente al php2shell.

Ops que cierra el llamado con el paquete instalado sin validar el binario del pool suele reabrir el mismo llamado con otro nombre. La evidencia es la versión del proceso que responde en el puerto 443.

Preguntas frecuentes sobre php2shell#

Antes de decidir el orden del parche conviene aclarar las dudas que más se repiten en soporte y en equipos de producto. Mezclar CMS con runtime, WAF con remediación completa o versión de CLI con SAPI web suele atrasar la corrección PHP RCE días enteros. Esa confusión deja exposición abierta en el servicio que realmente atiende el tráfico público frente al php2shell.

¿El php2shell es una falla de WordPress o de PHP?#

Es una falla del runtime PHP. WordPress, Drupal, Joomla y otros entran porque corren sobre ese runtime. Una aplicación bien escrita no inmuniza si la versión de PHP es vulnerable, porque CVE-2026-109618 y CVE-2026-109619 tocan caminos del intérprete que la solicitud puede alcanzar antes o al margen de la lógica de su CMS. Inventariar el core y los plugins ayuda, pero no sustituye confirmar el binario que atiende HTTP.

¿Actualizar el CMS resuelve sin actualizar PHP?#

No. Usted necesita la versión corregida del intérprete o un backport equivalente del proveedor. Actualizar solo plugins y el core del CMS no cierra CVE-2026-109618 ni CVE-2026-109619, aunque mejore otras superficies. Si el hospedaje gestiona el runtime, pida evidencia escrita del paquete y de la fecha de aplicación antes de marcar el riesgo del php2shell como cerrado en el tablero del equipo.

¿Un WAF solo me protege del php2shell?#

No de forma completa. Cloudflare, CISA y el NCSC suizo tratan el WAF como capa temporal. El aviso de PHP afirma que solo la actualización es solución completa. Mantenga el WAF encendido y priorice el parche, porque una regla puede fallar ante una variante y, además, no limpia un compromiso que ya haya ocurrido antes de su activación. Use el WAF para ganar horas mientras programa la ventana de actualización.

¿PHP 7.4 u 8.1 tienen corrección oficial de php.net?#

El proyecto no mantiene releases oficiales de esas líneas. Hay mención a backports mínimos de fuente para 7.4, 8.0 y 8.1, y a una posible corrección vía distribución LTS. Sin uno de esos caminos, la salida es migrar a una línea soportada ya corregida. Puede actualizar PHP 8.5.12 o la mínima corregida de la rama que su aplicación pueda sostener tras pruebas. Evalúe regresión de extensiones nativas antes del salto.

¿Cómo sé si mi hospedaje ya aplicó el parche del php2shell?#

Pida la versión exacta de PHP en el SAPI web y la referencia del paquete o del advisory del proveedor. Si la respuesta es vaga, trátelo como no corregido hasta que exista evidencia. Un número de major version en el panel de control puede ocultar un backport ausente o un worker distinto del que el panel reporta. Confirme también la fecha de reinicio de los procesos que atienden el puerto público.

¿Necesito sacar el sitio del aire por el php2shell?#

Solo si usted no puede aplicar el parche en un plazo corto y la exposición a internet es inaceptable en su riesgo. Es exactamente el escenario en el que NCSC y CISA piden considerar offline. Haga la evaluación con el dueño del servicio y con seguridad, no a oscuras. Documente qué datos sensibles quedan expuestos mientras el runtime vulnerable sigue respondiendo.

Conclusión#

El php2shell, en el sentido operativo del día 21 de octubre de 2026, es un evento de runtime. Quien opera PHP necesita tratar inventario, parche y validación del proceso vivo como una sola cadena. La mayoría de los equipos debería actualizar ahora a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete backporteado del vendor. Empiece por lo que está en internet y en especial por mod_php.

La respuesta cambia cuando usted está atrapado en una línea muerta sin LTS, cuando el proveedor embute PHP sin transparencia o cuando ya hay indicios de compromiso. En esos casos el orden pasa a ser contención, evidencia y solo después el retorno. El primer paso concreto frente al php2shell es listar cada SAPI y cada versión que atiende HTTP hoy. Marque fecha y responsable del parche.

Este material tiene fin informativo y educativo sobre el php2shell y las CVE-2026-109618 y CVE-2026-109619. No reemplaza el criterio de su proveedor de hospedaje, de su equipo de seguridad ni de un profesional a cargo del entorno concreto.