php2shell (CVE-2026-109618 y CVE-2026-109619): qué hacer hoy con tu PHP

El 21 de octubre de 2026 el equipo de seguridad de PHP publicó una tanda de versiones fuera de calendario —8.5.12, 8.4.27, 8.3.36 y 8.2.35— para corregir dos vulnerabilidades críticas que permiten ejecución remota de código sin autenticación. Se las conoce como php2shell, llevan los identificadores CVE-2026-109618 y CVE-2026-109619, y ambas están puntuadas con 9,2 sobre 10 en CVSS v4.0.

No son fallos de WordPress, ni de PrestaShop, ni de un plugin. Están en el intérprete de PHP, por debajo de tu aplicación: el código vulnerable se ejecuta antes de que tu web llegue a arrancar. Eso significa que actualizar el CMS, los plugins o los módulos no te protege, que tener la web detrás de un login tampoco, y que la responsabilidad recae en quien administra el servidor o el hosting.

Si tu empresa ha recibido estos días un aviso de su proveedor de ciberseguridad o de su empresa de mantenimiento, el aviso es legítimo y el contenido habitual de esas comunicaciones es correcto. En este artículo te contamos lo que hemos podido verificar en fuentes primarias —el aviso oficial de PHP, la alerta de CERT-EU y los análisis técnicos de Rapid7, Tenable, Unit 42, Huntress, Datadog y Wiz—, qué significa cada una de las dos vulnerabilidades, cómo saber en 10 minutos si estás afectado, un plan de actuación por horas, qué mitigaciones sirven de verdad y cuáles se están difundiendo con más optimismo del que merecen, y qué revisar si tu servidor ha estado expuesto sin parchear. Al final hay una lista de preguntas concretas para trasladar a tu hosting o a tu proveedor, porque en la mayoría de los casos la actualización no la vas a aplicar tú.

1. Qué ha pasado exactamente: cronología de un parche de emergencia

Este caso no ha seguido el guion normal de una divulgación coordinada. La secuencia, reconstruida a partir del aviso de PHP y de los análisis de Huntress, Tenable y SecurityWeek, es la siguiente:

• 20 de octubre. Aparece en Hacker News una publicación que adelanta la existencia de dos vulnerabilidades críticas de PHP pendientes de divulgación. Se retira, pero las capturas ya circulan por redes. La empresa de investigación watchTowr confirma la fuga: el embargo era para el día siguiente.
• 20 de octubre. El equipo de seguridad de PHP publica un preaviso y adelanta la liberación un día, fijándola para el 21 a las 14:00 UTC. CERT-EU publica la alerta 2026-018.
• 21 de octubre. Salen las cuatro versiones corregidas y el aviso oficial. Esa misma tarde se publican los análisis técnicos de Calif.io y Wiz.
• Antes de todo eso. El dato más incómodo lo aportó Amazon Threat Intelligence: su red de honeypots MadPot registró un intento de explotación el 17 de octubre, cuatro días antes de la divulgación pública. No está claro cómo obtuvo el atacante la información.

La consecuencia práctica de esa fuga es que el margen habitual entre «hay parche» y «hay exploit funcionando» se ha comprimido muchísimo. Cuando una vulnerabilidad se filtra antes del parche, los equipos de defensa pierden la ventaja de llegar primero.

1.1 Por qué el nombre php2shell

El apodo lo pusieron los investigadores y describe bien el impacto: de una petición HTTP a una shell en el servidor. Sigue la estela de otros casos bautizados así —el año pasado tratamos aquí uno equivalente en el ecosistema WordPress, la vulnerabilidad crítica wp2shell y cómo responder—, y como entonces, el nombre pegadizo ayuda a que el aviso llegue a dirección, pero no sustituye a entender el mecanismo.

2. Las dos vulnerabilidades, explicadas sin humo

Ambas son fallos de gestión de memoria en el núcleo de PHP, y las dos comparten un patrón: PHP aborta el procesamiento de una petición de forma abrupta mediante longjmp(), y ese salto deja estructuras internas en un estado inconsistente que luego se trata como si fuera válido.

2.1 CVE-2026-109618 — corrupción de memoria en el manejo de OOM

Cuando una petición agota el memory_limit, PHP la interrumpe. El problema es que esa interrupción puede ocurrir mientras los datos internos de la petición están solo parcialmente inicializados —por ejemplo, durante el parseo de un formulario multipart con subida de ficheros—. La rutina de limpieza posterior procesa esos datos como válidos y libera memoria que nunca se inicializó y que todavía puede contener datos controlados por el atacante procedentes de asignaciones anteriores.

Lo relevante para un responsable de sistemas:

• El disparador es una petición multipart manipulada, y puede agotar memoria aunque su tamaño parezca estar dentro de los límites configurados.
• Funciona con la configuración por defecto de límites de entrada y memoria, según el propio aviso.
• En Apache con mod_php la limpieza se ejecuta incluso cuando falla el arranque de la petición, lo que habilita el ataque demostrado antes de que corra una sola línea de tu aplicación.
• En PHP-FPM, el worker termina cuando falla el arranque, lo que corta esa secuencia concreta; el análisis del código apunta a que FPM sigue siendo susceptible tras un arranque correcto, pero el aviso no reporta un exploit completo para FPM en este CVE.
• El camino de código vulnerable más antiguo identificado se remonta a PHP 5.4.0. No es un fallo introducido hace dos versiones.

2.2 CVE-2026-109619 — estado global obsoleto (use-after-free entre peticiones)

Esta es, conceptualmente, más desagradable. Estado interno que pertenece a una petición sobrevive después de que su memoria haya sido liberada. Una petición posterior, atendida por el mismo worker reutilizado, puede usar ese puntero obsoleto antes de que la inicialización normal lo resetee. Los errores fatales —agotamiento de memoria, timeouts de ejecución— son precisamente lo que interrumpe la limpieza del estado.

Hay dos caminos confirmados:

• mod_php en PHP 8.5: RCE a través de la función de backtrace en errores fatales, cuando fatal_error_backtraces está activo (y lo está por defecto).
• mod_php y FPM, ciclo de sesión: el session upload progress —habilitado por defecto— actúa como consumidor temprano de estado obsoleto de sesión o del decodificador. Y para llegar ahí no hace falta que tu aplicación llame a session_start().

El aviso de PHP confirma además la divulgación de memoria como impacto: sin llegar a ejecutar código, un atacante puede leer memoria del proceso que contenga contraseñas de base de datos, tokens de API o claves. Wiz demostró ese camino por separado del RCE. Por eso la recomendación de rotar credenciales no es paranoia: es la respuesta proporcionada a una exposición de memoria.

2.3 Por qué 9,2 y no 10

Circularon identificadores con un 10.0 que la PHP Foundation desmintió. La puntuación oficial es 9,2 en CVSS v4.0 para las dos, con vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Los dos componentes que bajan la nota son AC:H (complejidad de ataque alta) y AT:P (requiere condiciones concretas): la fiabilidad del exploit depende del build de PHP, las extensiones cargadas, el comportamiento del frontend y la disposición de memoria. Eso no es un consuelo. Significa que no todo intento funcionará en todos los servidores, no que tu servidor esté a salvo.

3. A quién afecta: versiones, ramas y SAPI

El aviso oficial es explícito: están en riesgo todas las instalaciones de PHP que sirvan peticiones web, incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo se considera más alto en mod_php, por el motivo que ya hemos visto: ahí el ataque puede desencadenarse antes de que tu aplicación arranque.

3.1 Tabla de versiones

Rama	Estado	Qué hacer
8.5.x anterior a 8.5.12	Vulnerable	Actualizar a 8.5.12
8.4.x anterior a 8.4.27	Vulnerable	Actualizar a 8.4.27
8.3.x anterior a 8.3.36	Vulnerable	Actualizar a 8.3.36
8.2.x anterior a 8.2.35	Vulnerable	Actualizar a 8.2.35
8.1.x, 8.0.x, 7.4.x	Vulnerable, sin release oficial	Paquete del proveedor/distro, o backport mínimo de código fuente
7.3.x y anteriores	Vulnerable, fin de vida	Sin corrección del proyecto: migrar

Dos matices que generan confusión y que conviene tener claros antes de llamar al proveedor:

Las distribuciones recibieron los parches por adelantado. Debian, Ubuntu, Red Hat y los proveedores con soporte extendido incorporan la corrección a sus propios paquetes sin cambiar necesariamente el número de versión menor que se muestra. Si tu php -v devuelve, digamos, 8.2.28 con un sufijo de la distribución, eso no significa automáticamente que estés vulnerable: significa que tienes que comprobar el changelog del paquete y pedir confirmación expresa de que ambos CVE están corregidos. Es el punto donde más se equivocan los inventarios automáticos.

El repositorio de Remi no tuvo paquetes el día del lanzamiento. El propio aviso de PHP recomienda a quien dependa de rpms.remirepo.net cambiar a paquetes de la distribución o compilar desde fuente para poder aplicar actualizaciones de inmediato. Si tu stack es CentOS/Rocky con Remi, revísalo.

3.2 Y el software de terceros que lleva PHP dentro

Aquí está el punto ciego clásico. No es solo tu web: paneles de hosting (cPanel, Plesk), NAS, appliances, imágenes de contenedor, entornos de staging que nadie mira, instaladores de aplicaciones empresariales que embarcan su propio binario de PHP. CERT-EU remite al repositorio de NCSC-NL para identificar productos afectados. Si has hecho alguna vez un ejercicio de auditoría de dependencias y supply chain, el inventario que generaste entonces es exactamente lo que necesitas hoy.

4. Qué se sabe de la explotación real (y qué no)

Conviene separar lo confirmado de lo alarmista, porque estos días circula de todo.

Lo que está confirmado:

• Hay exploit funcional. Los avisos describen un RCE desarrollado durante la investigación, contra mod_php y contra PHP-FPM por caminos distintos. Calif.io reporta RCE pre-autenticación contra versiones concretas de WordPress, Drupal, Joomla y Magento. Wiz demostró RCE no autenticado contra la imagen de contenedor oficial de WordPress más reciente.
• Hay intentos de explotación. Amazon registró el intento del 17 de octubre y más el día 21, con cargas que apuntan a varios actores distintos. Cloudflare habló de ataques tempranos emergiendo. watchTowr reprodujo ambos fallos y observa intentos contra los dos.
• La superficie es enorme. Cortex Xpanse, de Palo Alto, cifró en más de 22,6 millones las instancias expuestas potencialmente vulnerables.
• Ya ha habido reacciones de retirada. Unit 42 reporta que al menos una administración europea retiró su web de forma preventiva, y en Japón varias plataformas de hosting entraron en mantenimiento de emergencia.

Lo que no está confirmado (a fecha de publicación de este artículo): no hay compromisos confirmados públicamente atribuidos a php2shell, solo intentos; Huntress no había visto explotación en su base de clientes en su última actualización; y el exploit técnico completo no es público, aunque circula código que lo reclama. Tampoco están, por ahora, en el catálogo KEV de CISA —donde sí figuran otras vulnerabilidades de PHP con uso conocido en ransomware, como CVE-2024-4577 y CVE-2019-11043—.

La lectura correcta de ese cuadro no es «aún no ha pasado nada, hay tiempo». Es que la ventana entre intentos oportunistas y explotación masiva en una vulnerabilidad de esta superficie se mide en días, no en semanas. Sansec llegó a estimar que la explotación masiva podía empezar a los quince minutos de salir el parche.

5. Plan de actuación: las primeras horas

Si eres el responsable técnico, este es el orden que recomendamos. Si no lo eres, salta a la sección 9 y traslada esa lista a quien corresponda.

5.1 Inventario (30 minutos)

Enumera todo lo que ejecuta PHP de cara a internet o accesible desde la red interna: webs de producción, tiendas online, intranets, APIs, paneles, staging, contenedores, cron workers. Para cada uno necesitas tres datos: versión exacta, SAPI (mod_php, FPM, cgi, FrankenPHP, LiteSpeed) y quién administra el servidor.

En cada host:

# Versión del binario CLI (ojo: puede NO ser la que sirve la web)
php -v

# Versión y SAPI que realmente sirve las peticiones
php-fpm -v ; php-fpm8.3 -v
apachectl -M 2>/dev/null | grep -i php

# Paquetes instalados y si la corrección está en el changelog del paquete
dpkg -l | grep -i php        # Debian/Ubuntu
rpm -qa | grep -i php        # RHEL/Rocky/Alma
apt changelog php8.3-fpm | head -40

# Procesos PHP realmente en ejecución
ps aux | grep -E 'php-fpm|php-cgi|httpd|apache2' | head

El error más común es mirar php -v por SSH y dar el servidor por bueno. El CLI y el SAPI web son binarios distintos y pueden estar en versiones distintas. Lo que sirve tu web es lo que importa, y la forma fiable de verlo desde la propia aplicación es un phpinfo() temporal —que debes borrar inmediatamente después— o la cabecera que exponga tu servidor.

5.2 Actualizar (el mismo día)

Es la única solución completa. El propio aviso de las releases lo dice sin matices: no hay mitigaciones completas, actualizar es la única opción segura. En la práctica:

1. Copia de seguridad antes de tocar nada: base de datos y ficheros. Si tu estrategia de respaldo no está clara, este es el momento de descubrirlo, no después.
2. Actualiza desde el paquete de tu distribución siempre que exista. Es la vía con menos fricción y la que ya trae el parche.
3. Comprobación de compatibilidad: dentro de la misma rama (8.3.35 → 8.3.36) el riesgo de rotura es mínimo, porque son releases de parche. Si la actualización implica salto de rama —porque estás en 8.1, por ejemplo—, ahí sí hay trabajo de compatibilidad, y conviene planificarlo con la guía de migración a PHP 8.4 y 8.5 en la mano. Pero no uses la migración pendiente como excusa para no mitigar hoy.
4. Reinicia todos los workers. Esto es imprescindible y se olvida con frecuencia: un systemctl reload no siempre recicla procesos antiguos, y un worker viejo sigue ejecutando el binario vulnerable en memoria.

systemctl restart php8.3-fpm     # FPM
systemctl restart apache2        # mod_php
# verificar que no quedan procesos antiguos
ps -eo pid,lstart,cmd | grep php-fpm

5.3 Verificar (10 minutos)

Después de actualizar: confirma la versión que sirve la web (no la del CLI), comprueba que el sitio funciona —portada, login, checkout, formularios con subida de ficheros, que es justo el camino del CVE de OOM— y revisa el log de errores por si la actualización ha destapado avisos de deprecación.

6. Mitigaciones temporales: lo que sirve y lo que no

Si no puedes actualizar hoy —porque dependes de un proveedor, porque tienes una ventana de cambios cerrada o porque estás en una rama sin release—, el aviso oficial recoge una serie de medidas que reducen la exposición a caminos de ataque concretos pero no hacen segura la instalación. Esa distinción es importante: no son un parche, son un torniquete.

6.1 Para el CVE de OOM (CVE-2026-109618)

; aplicar en php.ini, pool de FPM o configuración del servidor,
; nunca en el código de la aplicación
memory_limit = -1
post_max_size = 8M          ; 32M si necesitas subida de ficheros
upload_max_filesize = 8M    ; siempre por debajo de post_max_size

Y en FPM, de forma que la aplicación no pueda sobrescribirlo:

php_admin_value[memory_limit] = -1

La lógica del memory_limit = -1 es contraintuitiva pero correcta: si no hay límite, no se dispara el fallo de asignación que inicia la cadena. Con dos advertencias del propio aviso: una asignación puede fallar igualmente si la máquina se queda sin memoria real, y no se debe sustituir por RLIMIT_AS ni RLIMIT_DATA, porque precisamente provocan el fallo de asignación vulnerable. Los límites de contenedor o cgroup son una alternativa incompleta y, mal configurados, pueden matar el proceso maestro y con él todos los workers.

Complementariamente, limitar en el frontend —Nginx, Apache o el proxy— el tamaño del cuerpo decodificado, el número de campos y de partes multipart, las cabeceras por parte y la profundidad de anidamiento, incluidas las peticiones sin Content-Length utilizable. Si tu aplicación no usa multipart, bloquéalo directamente. Nuestra guía de optimización de Nginx en servidor dedicado cubre dónde se tocan esos límites; aquí el objetivo no es rendimiento sino recortar superficie.

6.2 Para el CVE de estado obsoleto (CVE-2026-109619)

session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; solo PHP 8.5

Con un reinicio de todos los workers después. Y con una precaución que no se repite lo suficiente: aplicarlo en php.ini, en el pool de FPM o en la configuración del servidor, nunca con ini_set() ni con un .user.ini de FPM, porque esos se evalúan demasiado tarde, cuando el parseo de la petición ya ha ocurrido.

Aquí hay una discrepancia honesta entre fuentes que merece la pena señalar. El aviso oficial de PHP lista session.upload_progress.enabled=0 como mitigación del camino de sesión confirmado. El equipo de Datadog Security Labs, en cambio, advierte explícitamente de que desactivarlo no protege, a pesar de los consejos que circulan en ese sentido. Las dos cosas pueden ser ciertas a la vez: cierra el camino confirmado, no cierra la clase de vulnerabilidad. Nuestra recomendación: aplícalo si no puedes parchear, pero no lo registres como «mitigado» en tu registro de riesgos. Sigue siendo un servidor vulnerable.

6.3 Lo que NO te protege

• Actualizar WordPress, PrestaShop, los plugins o los módulos. El fallo está en el intérprete, por debajo. Es el malentendido más extendido de esta semana.
• El login de tu aplicación. PHP procesa la petición maliciosa antes de que tu código decida si el usuario está autenticado. La autenticación a nivel de aplicación no puede bloquear el ataque.
• Ocultar los errores. Jugar con error_reporting, display_errors, log_errors o el operador de silencio no impide el acceso al estado obsoleto. Y al revés: que no haya entradas en el log no demuestra que la instalación esté a salvo.
• Un WAF, por sí solo. Cloudflare desplegó reglas iniciales para los vectores conocidos, disponibles incluso en plan gratuito, y las describe como un remiendo temporal. Solo sirven si tu origen acepta tráfico exclusivamente desde el CDN; si tu IP de origen es alcanzable directamente, no protegen nada. Imunify360 y otros han publicado reglas que bloquean la forma del exploit público, lo que ayuda en hosting compartido, pero bloquear una forma conocida no es corregir el fallo.
• Plugins o snippets «de corrección» de terceros. Están apareciendo y no están verificados. Pueden romperte el sitio sin aportar protección.

Si no puedes actualizar y el servicio es crítico, la medida que el aviso de CERT-EU plantea es más contundente y más honesta que cualquier torniquete: aislar el sistema de internet o retirar temporalmente el acceso público hasta que la corrección esté aplicada y verificada. Es exactamente lo que hicieron algunas administraciones europeas.

7. Cómo verificar que estás parcheado de verdad

Tres comprobaciones que separan «me han dicho que está actualizado» de «está actualizado»:

1. La versión del SAPI web, no la del CLI. Ya lo hemos dicho, lo repetimos porque es el fallo número uno.
2. El changelog del paquete, no el número de versión. Si tu proveedor mantiene paquetes propios, pide confirmación expresa y por escrito de que ambos CVE están corregidos en la build que tienes instalada. «Estamos en la última versión del repositorio» no es una respuesta.
3. Los procesos reiniciados. Comprueba la hora de arranque de los workers (ps -eo pid,lstart,cmd): si es anterior a la actualización, el binario parcheado está en disco pero no en memoria.

Y una comprobación funcional después: formularios con subida de ficheros, checkout, importadores. Son los flujos que usan multipart y los primeros donde se notaría un cambio de límites mal calibrado.

8. Si has estado expuesto: cómo buscar indicios de compromiso

Si un servicio ha estado accesible desde internet sin parchear después del 17 de octubre —la fecha desde la que Amazon recomienda empezar a investigar—, la actualización no cierra el caso. Hay que descartar que ya hayan entrado.

8.1 Qué buscar

La explotación, según la guía de detección de Huntress, se manifestaría como procesos hijo sospechosos lanzados por los procesos de PHP (php-fpm, php-cgi, httpd, apache2):

• Shells: sh, bash, cmd.exe, powershell.exe.
• Intérpretes: python, perl.
• Herramientas de descarga o red: curl, wget, nc, certutil.exe.
• Patrones de shell inversa: /dev/tcp/, fsockopen, mkfifo.
• Reconocimiento desde el servidor web: whoami, id, uname -a, ipconfig.

Además, en el sistema de ficheros y la configuración: ficheros nuevos o modificados en el document root, webshells, tareas de cron o tareas programadas que no reconozcas, usuarios nuevos, claves SSH añadidas, plugins o módulos que nadie instaló.

Y en los logs del servidor web, los patrones que Patchstack señala como sospechosos: peticiones multipart inusuales seguidas de errores de límite de memoria o de una racha de HTTP 500, cookies PHPSESSID anormalmente grandes o malformadas, y reinicios de workers de PHP sin explicación.

Dos advertencias importantes. La primera: una explotación exitosa no necesariamente hace caer el worker, así que la detección basada en crashes se le puede escapar. La segunda: los logs de aplicación van a mostrar poco, porque el fallo actúa por debajo de la capa de aplicación. La ausencia de evidencia aquí vale poco.

8.2 Qué hacer si encuentras algo

Preserva los logs antes de tocar nada —son tu única traza—, trata el servidor como potencialmente comprometido y rota todas las credenciales que la aplicación tenga en memoria o en configuración: contraseñas de base de datos, claves de API, tokens de pasarelas de pago, credenciales SMTP, claves de almacenamiento, las salts de WordPress. Recuerda que la divulgación de memoria está confirmada como impacto: las credenciales pueden haberse filtrado sin que exista ni una sola webshell en disco.

Si el incidente afecta a datos personales o a un servicio esencial, los plazos de notificación entran en juego. Nuestra guía sobre la Directiva NIS2 y sus obligaciones de notificación detalla los tiempos, y el artículo sobre cómo funciona el ransomware y cómo protegerse cubre la mecánica de contención que aplica igual aquí: una RCE no autenticada es, con frecuencia, el primer eslabón de un despliegue de ransomware días después.

9. Qué pedirle exactamente a tu hosting o a tu proveedor

Si no administras el servidor, tu trabajo hoy es hacer las preguntas correctas y guardar las respuestas. Estas cinco, literalmente:

1. ¿Qué versión y SAPI de PHP sirve cada uno de nuestros sitios y aplicaciones, incluidos los entornos de pruebas?
2. ¿Está aplicada la corrección de CVE-2026-109618 y CVE-2026-109619 en esa build concreta? Si mantenéis paquetes propios en los que el número de versión no cambia, confirmádnoslo por escrito con referencia al changelog.
3. ¿Se han reiniciado todos los workers de PHP después de aplicar la corrección, y a qué hora?
4. Si algún entorno sigue sin parchear: ¿qué mitigaciones temporales hay activas, y cuál es la fecha comprometida de actualización?
5. ¿Hay evidencia de intentos de explotación en los logs desde el 17 de octubre, y se conservan esos logs?

Dos notas de criterio. Una: «tenemos un WAF» no responde a ninguna de las cinco. Dos: si la respuesta a la primera pregunta tarda días en llegar, el problema que tienes no es php2shell, es que nadie tiene el inventario. Eso se arregla con un contrato de mantenimiento que lo incluya, y es el motivo por el que insistimos tanto en que el mantenimiento no es un gasto opcional.

10. El caso incómodo: PHP 8.1 y anteriores

Si estás en 8.1, 8.0 o 7.4, no hay release oficial. Tienes tres caminos, en orden de preferencia:

1. Paquete de tu distribución o de tu proveedor de LTS. Recibieron los parches por adelantado. Es la opción limpia.
2. Backport mínimo de código fuente. Dada la gravedad, el equipo de seguridad de PHP publicó backports mínimos para 7.4, 8.0 y 8.1 en ramas específicas de php-src, para quien compila desde fuente o no tiene proveedor de LTS. Es una solución de emergencia, no un plan.
3. Migrar a una rama con soporte. Es lo que había que hacer de todas formas, y este episodio es el argumento que te faltaba para presupuestarlo.

En 7.3 y anteriores no hay corrección del proyecto, punto. Y conviene anotar una fecha: PHP 8.2 llega a fin de vida el 31 de diciembre de 2026 y no recibirá más correcciones de seguridad después. Si tu plan de contingencia de hoy es «actualizo a 8.2.35 y respiro», ese respiro dura dos meses. Lo razonable es aprovechar la ventana de cambios que vas a abrir ahora para saltar a 8.3 o 8.4.

11. La lección de fondo: esto volverá a pasar

php2shell no es un fallo exótico. Es un fallo de gestión de memoria en una ruta de código que, en su versión más antigua, lleva en el intérprete desde PHP 5.4. Lo que ha cambiado no es PHP: es que alguien ha mirado con suficiente atención, y que la divulgación se filtró antes de tiempo.

Para una empresa que depende de su web o de su tienda, la pregunta útil no es «¿cómo evito la próxima vulnerabilidad de PHP?» —no se puede—, sino «¿cuánto tardo en saber si me afecta y en aplicar el parche?». Esa es una métrica operativa, y se mejora con cosas aburridas:

• Inventario vivo de versiones y SAPI por entorno, no un Excel de hace dos años.
• Ventana de parcheo definida y ensayada, con una vía exprés para críticas que no dependa de pedir permiso a tres personas.
• Entorno de staging que se parezca a producción, para que validar un parche sea cuestión de horas.
• No acumular deuda de versiones. Estar en una rama con soporte convierte una emergencia en un apt upgrade; estar en 7.4 la convierte en un proyecto.
• Respaldos verificados y un plan de rotación de credenciales que alguien haya probado alguna vez.

Si quieres el marco completo, lo desarrollamos en ciberseguridad en servidores con poco presupuesto y, para el lado de la aplicación, en el OWASP Top 10 y cómo prevenir las vulnerabilidades web más críticas. Para quien administre su propio stack, la configuración de referencia está en optimización de PHP-FPM: php.ini y www.conf, que es donde van a vivir varios de los parámetros de esta semana.

Preguntas frecuentes

¿Me afecta si mi web es un WordPress en hosting compartido?

El fallo está en el PHP del servidor, así que la exposición depende de tu hosting, no de tu WordPress. Lo que te toca es preguntar —las cinco preguntas de la sección 9— y actualizar la versión de PHP desde el panel si tu proveedor ya ofrece una corregida. Muchos hostings compartidos han aplicado reglas de WAF a nivel de plataforma mientras completan el despliegue.

He actualizado WordPress y todos los plugins. ¿Ya está?

No. Es el malentendido más frecuente de esta semana. Actualizar el CMS no cambia la versión del intérprete de PHP que ejecuta el servidor.

¿Basta con desactivar session.upload_progress?

No. Cierra uno de los caminos confirmados, y el aviso oficial lo recomienda como medida temporal, pero investigadores de Datadog advierten de que no protege frente a la clase de vulnerabilidad. Trátalo como un torniquete mientras organizas la actualización.

Mi php -v muestra una versión que no está en la lista de corregidas. ¿Estoy vulnerable?

No necesariamente: las distribuciones integran el parche en sus propios paquetes sin cambiar el número de versión visible. Comprueba el changelog del paquete y pide confirmación expresa a tu proveedor. Y recuerda que php -v es el CLI, no necesariamente el SAPI que sirve tu web.

¿Cómo sé si ya me han atacado?

Busca procesos hijo anómalos lanzados por PHP, ficheros nuevos en el document root, cron o usuarios desconocidos, y en los logs del servidor peticiones multipart raras seguidas de errores de memoria o rachas de 500. Ten en cuenta que una explotación exitosa puede no dejar un crash, así que la ausencia de señales no es una garantía.

¿Hay que rotar contraseñas y claves?

Si el servicio ha estado expuesto sin parchear, sí: la divulgación de memoria está confirmada como impacto, y eso incluye credenciales de base de datos, tokens y claves de API que el proceso tuviera cargadas.

¿Y si no puedo parchear hasta la semana que viene?

Aplica las mitigaciones de la sección 6, pero valora en serio la recomendación de CERT-EU: retirar el acceso público al servicio afectado hasta tener el parche aplicado y verificado. Para un servicio crítico expuesto, unas horas de indisponibilidad planificada cuestan menos que un incidente.

¿El aviso que me ha mandado mi proveedor de ciberseguridad es fiable?

Los avisos que estamos viendo circular estos días son correctos en lo esencial: los dos CVE existen, la puntuación de 9,2 es la oficial, las cuatro versiones corregidas son las que indican y es cierto que para 7.4, 8.0 y 8.1 solo hay backports mínimos. Si tienes dudas, contrasta siempre con el aviso oficial de PHP y con la alerta de CERT-EU 2026-018.

Conclusión

php2shell reúne todos los ingredientes de una emergencia operativa real: ejecución remota de código sin autenticación, superficie de ataque enorme —más de 22 millones de instancias expuestas—, una fuga que comprimió los plazos, intentos de explotación documentados antes incluso del parche, y una frase del propio equipo de PHP que no deja margen a la interpretación: no hay mitigaciones completas, actualizar es la única opción segura.

La buena noticia es que la acción es sencilla y está bien definida: localiza cada instalación de PHP, averigua la versión y el SAPI que de verdad sirven tus peticiones, actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 —o al paquete corregido de tu proveedor—, reinicia todos los workers, verifica, y si el servicio estuvo expuesto sin parchear desde el 17 de octubre, busca indicios y rota credenciales. Lo que no es sencillo, y es donde se decide el resultado, es tener el inventario a mano para poder hacer todo eso hoy en lugar de la semana que viene.

Si necesitas ayuda para coordinar la revisión con tu hosting, para verificar que el parche está realmente activo o para descartar un compromiso en un servidor que ha estado expuesto, escríbenos. Y si lo que descubres estos días es que nadie sabía qué versiones de PHP tenías corriendo, hablemos de eso también: es el problema de fondo, y tiene solución.