Vulnerabilidad PHP CVE-2026-109618: parche urgente mientras los paneles corren
La vulnerabilidad PHP CVE-2026-109618 y CVE-2026-109619 puntúan CVSS 9.2. Qué hicieron RunCloud, Prostack y Cloudflare, y cómo parchear.
bufferSobre el autor12 min de lectura
PHP publicó esta noche versiones de emergencia para dos fallos críticos apodados php2shell. Si alojas WordPress, un blog, un front de IA u otra app PHP en un panel VPS, la vulnerabilidad PHP CVE-2026-109618 y la CVE-2026-109619 son las que debes parchear antes de dormir. El equipo de seguridad de PHP las puntúa con CVSS v4.0 9.2 —no 10.0, pese a ese número que circuló hoy—. No hay mitigación completa por configuración. Actualizar PHP es la única opción segura.
Este artículo resume qué pasó esta noche en hora de Pekín (UTC+8), qué dicen los avisos oficiales, cómo se movieron paneles como RunCloud y Prostack, y cómo revisar tu propio servidor. Las horas son de Pekín salvo que se indique UTC.
Qué pasó esta noche
El 20 de octubre se filtraron detalles en redes y Hacker News antes de la divulgación prevista para el 22. La cuenta de la PHP Foundation anunció una versión crítica el 21 a las 14:00 UTC (22:00 en Pekín), ambos fallos con CVSS v4.0 9.2. Proveedores y WAF se movieron antes.
A las 11:02 de Pekín (03:02 UTC), Cloudflare activó reglas WAF por defecto en todos los planes, incluido el gratuito —unas nueve horas antes de la divulgación—. A las 15:43, el CTO Dane Knecht escribió en X que los sitios detrás de Cloudflare ya tenían reglas para vectores conocidos, que “we are seeing early attacks emerging” y que era solo un STOPGAP (publicación).
Hacia las 16:00, RunCloud desactivó session.upload_progress en todos los servidores y publicó un aviso en la comunidad a las 16:58 (08:58 UTC). A las 23:00 esa página solo muestra “We are in maintenance mode due to PHP Update”; el texto del aviso de RunCloud proviene de una caché de buscador: la página no está disponible y no hay copia en Wayback Machine.
Los clientes de paneles gestionados también suelen recibir avisos en el panel o por correo. Si usas RunCloud, mira el panel y el correo del proveedor para el estado de tu stack; no esperes a que vuelva la comunidad.
Hacia las 21:35–21:40, php.net publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35, antes de las 22:00. Prostack actualizó después (15:30 hora UK, ~22:30 Pekín): todos los servidores Cito estaban parcheados. Por eso varios paneles parecían “caídos” esta noche.
Qué son las dos CVE
Ambos fallos están en el runtime de PHP. Actualizar WordPress, un tema o un plugin no sirve. Según el aviso de php.net y los avisos de GitHub GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp:
- CVE-2026-109618 — RCE por corrupción en OOM. Si PHP se queda sin memoria a mitad de armar una petición, puede dejar datos a medias; la limpieza los trata como válidos. Disparadores confirmados incluyen subidas multipart elaboradas dentro de los límites habituales. Mayor riesgo en Apache
mod_php; FPM sigue considerándose susceptible. - CVE-2026-109619 — RCE por estado global obsoleto. El estado de una petición puede sobrevivir tras liberar su memoria. Una petición posterior en el mismo worker puede usarlo. Rutas confirmadas: progreso de subida de sesión (activo por defecto; no hace falta
session_start()) y, en PHP 8.5, backtraces de errores fatales.
Impacto según los avisos: ejecución remota de código sin autenticación con privilegios del worker web. NVD ya recibió ambos registros (CVE-2026-109618); el estado sigue en “Received”. A las 01:15 hora de Pekín del 22 de octubre, ninguna CVE está en KEV: el catálogo más reciente de CISA sigue siendo el del 21 de octubre a las 14:04 UTC (catálogo KEV).
Versiones afectadas y corregidas
Actualiza dentro de tu rama major.minor; no hace falta saltar a 8.5. Si instalas PHP por paquetes de distro, mira el aviso del proveedor por la versión del paquete: Ubuntu y similares suelen mantener el número upstream y cambiar la revisión del paquete.
| Rama | Afectada | Versión corregida | Soporte oficial |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | hasta 31 dic 2029 |
| 8.4 | < 8.4.27 | 8.4.27 | hasta 31 dic 2028 |
| 8.3 | < 8.3.36 | 8.3.36 | hasta 31 dic 2027 |
| 8.2 | < 8.2.35 | 8.2.35 | hasta 31 dic 2026 |
| 8.1 / 8.0 / 7.4 | afectada | sin versión oficial; solo backports mínimos de código | EOL |
| 7.3 y anteriores / 5.x | tratada como afectada por investigadores y CERT-FR | solo backports del proveedor, si existen | EOL |
Fuentes: GHSA, php.net. Los datos estructurados de NVD listan 8.2–8.5; la frase “desde PHP 5.4” viene de investigadores y CERT-FR, no de la lista estructurada del CNA.
La IA encontró un fallo que afecta a casi toda la web
Para quien sigue la IA, este es el ángulo fuerte. Según el artículo “Patch the Planet” de OpenAI y la publicación de @OpenAI a las 22:04 Pekín, los modelos de OpenAI ayudaron a investigadores de esa iniciativa a hallar fallos críticos en PHP. El socio Calif usó GPT-5.6 Sol; Wiz descubrió e informó ambos de forma independiente. OpenAI dice que dedicó unos dos meses a coordinar mantenedores, investigadores y proveedores (incluidos Cloudflare y Wiz) porque el cambio en el motor era complejo, y que contactó con socios del gobierno de EE. UU. (Super Intelligence Force de la Casa Blanca, ONCD, CISA) y socios internacionales.
El presidente de OpenAI, Greg Brockman, publicó a las 22:58 Pekín el artículo de X “Towards securing the internet” (publicación), calificando php2shell como uno de los bugs de código abierto más graves de los últimos tiempos y señalando que la fecha original era el 22 de octubre hasta que la filtración adelantó el lanzamiento. En números: W3Techs (21 oct 2026) indica que PHP lo usan el 69,3% de los sitios cuya lengua del servidor se conoce —unos tres cuartos de ese conjunto—. Entre sitios con PHP, cerca del 35% sigue en PHP 7 o 5 (27,0% + 7,7%), sin arreglo oficial esta noche.
Un dato que encaja con “OpenAI avisó a la Casa Blanca”: el sitio público whitehouse.gov es WordPress (el HTML de la portada tiene más de 200 referencias a wp-content) y sus cabeceras coinciden con WordPress VIP. Automattic se encarga del parcheo. No afirmamos si estaba vulnerable o parcheado esta noche; solo que corre sobre WordPress/PHP en un host gestionado.
Avisos gubernamentales, incluido Japón
A las 20:55:59 de Pekín, la cuenta oficial en X de la primera ministra de Japón @takaichi_sanae pidió comprobar si los sitios públicos usan PHP, prepararse para el parche a las 23:00 hora de Japón y considerar apagar temporalmente el sitio si no se puede parchear rápido. La bio de la cuenta indica que parte de las publicaciones durante el mandato las hace el personal de prensa, así que aquí se habla de “publicación de la cuenta oficial”, no de quién tecleó. Métricas al leerlas vía API de X (~23:05 Pekín): unas 20,7M de vistas, 52,4K reposts y 170,7K likes.
El texto sigue de cerca dos avisos de la oficina nacional de ciberseguridad de Japón @cyber_forecast —a las 12:01 y a las 20:44—. Que un canal oficial de un jefe de gobierno amplifique el mismo día una alerta técnica es poco habitual; el contenido técnico es el de la NCO.
Qué hizo cada plataforma
Desactivar session.upload_progress solo corta una ruta confirmada de CVE-2026-109619. No hace nada contra CVE-2026-109618. El aviso de PHP es claro: no hay mitigaciones completas.
| Plataforma | Mitigación esta noche | Quién recibe parche | Ramas antiguas |
|---|---|---|---|
| RunCloud | Desactiva session.upload_progress; plantillas NGINX opcionales | Auto en 8.2+ cuando lleguen builds (Native/Docker/LSAPI pending en la última caché) | Sin builds parcheados para 8.1 y anteriores — pasar a 8.2+ |
| Prostack | Mantiene upload_progress apagado; despliega parches | Cito: todos parcheados; backports 5.6–8.4 | Ruta cPanel: backports desde 7.4; por debajo hay que actualizar |
| cPanel | EasyApache 4 25.91 | ea-php74 a ea-php85 | Hasta 7.4 |
| Plesk Linux | Paquetes PHP 8.2–8.5 | 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 | 7.4–8.1 y Windows: aún en desarrollo |
| Laravel | Cloud y Vapor automáticos; Forge manual | Apps en PHP 8 | Apagar el servidor si no se puede actualizar (según Laravel) |
| Cloudflare (WAF) | Reglas gestionadas + detección de transacción completa | Todos los planes, incluido Free | Stopgap — hay que parchear PHP |
Notas de distro esta noche: Debian publicó DSA-6574-1 para php8.4 en Trixie. El tracker de Ubuntu marca las CVE como Critical; no cites USN-8936-1 (19 oct), que es otro fallo. Red Hat lo sigue en Bugzilla 2556842; no verificamos un RHSA formal a la hora de cierre. PHP indicó que el repo Remi no actualizaría hoy.
Cómo comprobar y parchear tu servidor
- Mira la versión real:
php -vy unphpinfo()temporal (CLI y FPM a menudo difieren). Objetivo: ≥ 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 en tu rama. - Revisa el progreso de subida:
php -i | grep session.upload_progress.enabledy confirma en el SAPI web. Ponsession.upload_progress.enabled = Offen php.ini ophp_admin_flag[session.upload_progress.enabled] = offen el pool FPM. Reinicia workers.ini_set()y.user.inillegan tarde. - Solo en PHP 8.5: también
fatal_error_backtraces=0hasta parchear. - Actualiza:
apt update && apt upgrade,dnf upgrade 'php*', EasyApache / Plesk, o el rebuild del panel. Luego reinicia Apache (mod_php), PHP-FPM y workers largos (Octane, colas). - WordPress: subidas, plugins/temas y muchos formularios usan multipart. No bloquees multipart en todo el sitio sin una lista blanca cuidadosa.
- Si sigues en 8.1 o anterior sin backport: migra esta noche o apaga el sitio hasta poder —como aconsejan la NCO de Japón y varios hosts.
# ejemplos — ajusta nombres de paquete
php -v
php -i | grep session.upload_progress.enabled
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.2-fpm
ps aux | grep php-fpmEl verificador oficial de OpenAI, y qué significa UNKNOWN
A las 00:35 hora de Pekín del 22 de octubre, OpenAI publicó una herramienta oficial para autocomprobar PHP2Shell. No envía peticiones de ataque: solo lee la versión de PHP que tu sitio ya expone en las cabeceras HTTP de respuesta (X-Powered-By y Server) o, con --local, lo que dice php -v en la máquina donde la ejecutas. Solo necesita Node.js; no hay paquetes que instalar.
GitHubopenai/php2shell-checker
Para un sitio: node phpcheck.js "https://example.com". En el propio servidor: node phpcheck.js --local. La respuesta es una de tres: OK, VULNERABLE o UNKNOWN.
Ojo: la mayoría de hostings compartidos y paneles ocultan la cabecera con la versión de PHP, así que en muchos sitios verás simplemente UNKNOWN. Eso no significa que estés a salvo; el propio README lo dice. Entra en tu panel o ejecuta php -v y actualiza dentro de tu rama a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Incluso un OK es solo una comparación de números de versión, no una prueba de que el parche esté aplicado.
Panel gestionado frente a autogestión
Esta noche es una prueba A/B limpia. En un panel que recompila PHP solo, miras el panel y evitas reactivar session.upload_progress en un .user.ini. En un VPS propio eres el ingeniero de release: inventarias cada binario PHP, aplicas el paquete del proveedor, reinicias workers y demuestras la versión en ejecución. El ángulo de IA no es que “la IA hace fácil el hosting”; es que la IA halló un bug de clase catorce años en el lenguaje bajo tu stack, y duerme mejor quien ya tenía un pipeline de parches.
Estado de explotación — lo que sí se puede decir
- Situación a las 01:15 hora de Pekín del 22 de octubre. Ya hay código de prueba de concepto (PoC) público: varios repositorios con PoC para CVE-2026-109618/109619 están abiertos en GitHub y circulan por X. No los hemos probado y no los enlazamos.
- Proveedores de seguridad ven a atacantes probando ese código público. Vega Threat Research dijo a las 23:01 hora de Pekín del 21 de octubre que está viendo intentos de explotación reales con el PoC público. watchTowr contó a SecurityWeek que sus sensores registraron los primeros intentos reales más o menos cuando salieron los parches, y que ninguno había tenido éxito. Cloudflare también reporta tráfico de ataque y cargas mutantes (blog, Knecht).
- Sigue sin haber ningún compromiso confirmado: hablamos de escaneos e intentos de explotación. No hemos encontrado ningún informe confirmado de un sitio que haya sido vulnerado de verdad por estos fallos.
- Siguen fuera de CISA KEV a las 01:15 hora de Pekín (catálogo más reciente: 21 de octubre, 14:04 UTC; catálogo KEV).
Preguntas frecuentes
¿Basta con apagar session.upload_progress?
No. Solo corta una ruta confirmada de CVE-2026-109619. No hace nada contra CVE-2026-109618. PHP dice que no hay mitigaciones completas.
¿Cloudflare me protege?
Si el tráfico pasa por Cloudflare y el Managed Ruleset está en modo bloqueo, tienes un stopgap por defecto desde las 11:02 de Pekín. Aun así hay que parchear PHP.
Estoy en PHP 8.1. ¿Estoy bien?
No según php.net. Solo hosts con backport (p. ej. Prostack Cito hasta 5.6, o cPanel desde 7.4) te cubren. Si no, pasa a 8.2+ o quédate offline.
¿Actualizar plugins de WordPress ayuda?
No. El fallo está en el runtime de PHP. Los plugins no sustituyen una actualización de PHP.
¿Por qué algunos hablan de CVSS 10.0?
Textos secundarios tempranos usaron 10.0. El equipo de PHP, GHSA y NVD usan CVSS v4.0 9.2 con complejidad High y requisitos Present.
¿OpenAI fue vulnerado?
No hay evidencia pública de eso. El rol público de OpenAI aquí es descubridor y coordinador vía Patch the Planet, no el de un SaaS afectado.
Fuentes
- Aviso php.net · GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp
- Blog WAF de Cloudflare · Dane Knecht
- OpenAI Patch the Planet · @OpenAI · Greg Brockman
- Aviso RunCloud (caché; en mantenimiento) · Prostack · cPanel · Plesk
- @takaichi_sanae · @cyber_forecast · W3Techs · CISA KEV · watchTowr · Vega Threat Research en X · SecurityWeek · BleepingComputer
Relacionado en este sitio: guía de errores de Claude Code y cómo revisar un Mac que se calienta por un minero — problemas distintos, mismo hábito de verificar antes de reiniciar a ciegas.