Vulnerabilidad PHP: qué hacer si tienes hosting compartido
DominicodeCada pocos meses alguien vuelve a decir que PHP está muerto. Y el 21 de octubre de 2026 medio internet estaba parcheando servidores a toda prisa.
Lo resumí en un tuit: "Para estar muerto, PHP tiene unos CVEs muy vivos".
Ese día el proyecto PHP publicó versiones de seguridad para dos fallos críticos que ya circulan con el nombre de PHP2Shell. Es una vulnerabilidad PHP crítica: ejecución remota de código sin autenticación, CVSS 9.2.
Y la pregunta que se está haciendo mucha gente que no administra servidores es otra: ¿tengo que hacer algo si tengo un hosting compartido?
En corto: PHP2Shell (CVE-2026-109618 y CVE-2026-109619) es una vulnerabilidad PHP de ejecución remota de código, corregida el 21 de octubre de 2026 en 8.5.12, 8.4.27, 8.3.36 y 8.2.35. En hosting compartido el parche lo aplica tu proveedor, pero a ti te toca comprobar tu versión, subir a 8.3 o 8.4 si sigues en 8.1 o anterior, y preguntar al soporte si ya está aplicado. Si tardó, rota contraseñas, claves API y salts.
¿Qué es PHP2Shell?
PHP2Shell es el nombre que se ha dado a dos vulnerabilidades de PHP (CVE-2026-109618 y CVE-2026-109619) que permiten ejecutar código en el servidor sin autenticación, con los permisos del usuario con el que corre el worker web.
Las dos tienen una puntuación CVSS v4.0 de 9.2. Según el aviso de seguridad de php.net, las SAPIs en riesgo son PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Es decir, prácticamente cualquier forma de servir PHP por HTTP.
La descubrieron Wiz Research, Calif y OpenAI, y los dos primeros cuentan que usaron modelos de IA en la investigación. Discrepan en el peso: Wiz atribuye a Gemini 4 Argon una contribución clave para encontrar el fallo, y Calif dice que no usó ningún harness especial ni modelos que no estuvieran al alcance de cualquiera.
Por qué esta vulnerabilidad PHP va de workers, no de tu código
Para entender el fallo hace falta una idea: un worker es un proceso de PHP que atiende una petición, limpia y atiende la siguiente. No arranca de cero cada vez. Esa reutilización funciona si la limpieza entre peticiones es perfecta. PHP2Shell son dos formas de romperla.
CVE-2026-109618, "RCE via OOM corruption". Cuando PHP se queda sin memoria durante el arranque de la petición, salta con longjmp() y deja la memoria a medio inicializar. El cierre de la petición procesa ese estado inválido.
El atacante fuerza ese OOM con peticiones multipart: formularios y subidas de archivos. En mod_php la RCE está validada por HTTP con los límites por defecto. En FPM no se ha demostrado un exploit completo, pero el análisis del código lo considera susceptible.
CVE-2026-109619, "RCE via stale global state". Parte del estado global de una petición (errores, sesión, extensiones) sobrevive después de liberar su memoria, y la siguiente petición en el mismo worker lo usa. Un use-after-free de manual. Los caminos confirmados son fatal_error_backtraces en PHP 8.5, session upload progress y las directivas INI por petición vía .htaccess/php_value en Apache.
Este segundo fallo también permite leer memoria del worker. Según Qualys, esa memoria puede contener contraseñas, tokens y API keys.
El detalle técnico está en los avisos públicos de GitHub: GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp. Drupal publicó además su propio PSA.
¿Se está explotando ya? Según Qualys, sí: Amazon Threat Intelligence y Cloudflare han reportado actividad, y Patchstack ha recibido informes de partners de hosting. No hay una PoC pública enlazada en los avisos.
Qué versión de PHP está corregida
La vulnerabilidad PHP está corregida en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 (y en 8.6.0 RC4), publicadas el 21 de octubre de 2026. Las ramas 8.1 y anteriores no tienen versión oficial.
| Rama de PHP | Versión corregida | Estado |
|---|---|---|
| 8.5 | 8.5.12 | Soportada |
| 8.4 | 8.4.27 | Soportada |
| 8.3 | 8.3.36 | Soportada |
| 8.2 | 8.2.35 | Soportada hasta el 31 de diciembre de 2026 |
| 8.1, 8.0, 7.4 y anteriores | Sin versión oficial | Sin soporte. Hay parches en código fuente para 7.4, 8.0 y 8.1 que el proveedor puede aplicar o no |
Fíjate en la última fila. Que tu sitio quede protegido en esas ramas depende de que tu proveedor decida aplicar los parches.
¿Tengo que hacer algo si tengo un hosting compartido?
Sí, pero no lo que crees: el parche de esta vulnerabilidad PHP lo aplica tu proveedor, no tú. Tú no puedes actualizar PHP en un hosting compartido, pero sí tienes cuatro tareas, y las cuatro dependen de ti.
1. Mira qué versión de PHP usa tu sitio en el panel
En cPanel está en "Select PHP Version" o en "MultiPHP Manager". En Plesk, en la configuración de PHP del dominio. Si no encuentras nada, sube un archivo temporal con <?php phpinfo();, ábrelo en el navegador, apunta la versión y bórralo en cuanto termines. Un phpinfo olvidado es un regalo para cualquiera que esté buscando.
2. Si es 8.1 o anterior, sube a 8.3 o 8.4
Nadie te garantiza el parche en una rama sin soporte. Sube a 8.3 o 8.4 desde el mismo panel. Si estás en 8.2, aprovecha también: le quedan dos meses de soporte.
Si usas WordPress, antes comprueba que tu tema y tus plugins aguantan la versión nueva. Haz copia de seguridad y prueba en staging si tu hosting lo ofrece.
Un tema abandonado puede romperse al cambiar de rama. Si te pasa, quizá sea el momento de mirar Ipsum, el nuevo tema por defecto de WordPress 7.2.
3. Pregunta al soporte si ya aplicó el parche
Aquí está la trampa: el número de versión puede engañar. Qualys avisa de que los parches backporteados pueden conservar un número de versión antiguo. Ver "8.3.30" en phpinfo no demuestra por sí solo que seas vulnerable.
La única forma de saberlo es preguntar. Este mensaje te sirve tal cual:
Hola. Mi sitio [dominio] usa PHP [versión]. ¿Habéis aplicado ya las
correcciones de CVE-2026-109618 y CVE-2026-109619 (PHP2Shell, 21/10/2026)?
¿Es la versión oficial (8.5.12, 8.4.27, 8.3.36 u 8.2.35) o un parche
backporteado? ¿En qué fecha se aplicó y se reiniciaron los procesos PHP?
Gracias.
La fecha importa para el paso siguiente.
4. Si tardó en parchear, cambia contraseñas, claves API y salts
Como el segundo fallo permite leer memoria del worker, cuenta con que lo que pasaba por ella pudo filtrarse. Si el parche no estaba aplicado el 21 o el 22 de octubre, cambia la contraseña de la base de datos y las claves API que use tu aplicación (pagos, email, servicios externos).
En WordPress, regenera además los salts de wp-config.php. Eso cierra todas las sesiones abiertas.
Si nunca has pensado dónde viven tus claves y cuánto tardarías en rotarlas, empieza por el post sobre cómo gestionar las API keys de un agente de IA. El problema es el mismo aunque no uses agentes.
Lo que no puedes hacer en compartido
La mitigación parcial de session.upload_progress.enabled=0 solo funciona en php.ini, en el pool de FPM o en la configuración del servidor que se aplica antes de parsear la petición. Hay que reiniciar los workers. ini_set() y .user.ini no sirven.
Tampoco ayuda ocultar errores con display_errors o con @. El fallo está en la gestión de memoria, no en lo que se muestra.
Quién parchea según tu tipo de alojamiento
Quién aplica el parche depende de quién controla el binario de PHP: en hosting compartido y gestionado, el proveedor; en VPS y contenedores, tú.
| Tipo de alojamiento | Quién parchea PHP | Qué haces tú | Riesgo o limitación |
|---|---|---|---|
| Hosting compartido | El proveedor | Ver versión, subir de rama si estás en 8.1 o menos, preguntar si ya está aplicado, rotar secretos si tardó | No controlas php.ini ni el reinicio de workers; dependes de lo que te diga el soporte |
| Hosting gestionado de WordPress | El proveedor | Confirmar con el soporte, revisar compatibilidad de plugins, rotar salts y claves si hubo retraso | El número de versión puede no reflejar el backport |
| VPS o servidor propio | Tú | Actualizar el paquete de PHP y reiniciar PHP-FPM o Apache; aplicar mitigaciones mientras tanto | Sin reinicio sigue corriendo el binario viejo |
| Contenedores / Docker | Tú | Reconstruir la imagen sobre una base parcheada y volver a desplegar | Una imagen fijada a una versión antigua sigue vulnerable aunque el host esté al día |
Si tienes VPS o servidor propio
Actualiza el paquete y reinicia PHP-FPM o Apache. No des por hecho que el gestor de paquetes lo reinicia: compruébalo con systemctl status. Hasta que reinicias, los workers siguen ejecutando el binario viejo.
Mientras llega la actualización, php.net propone mitigaciones parciales:
; php.ini o pool de FPM (luego reiniciar workers)
; CVE-2026-109618: quita el OOM controlable. Mejor como php_admin_value
; y con un límite de memoria de cgroup/contenedor que mate solo el worker
memory_limit = -1
; CVE-2026-109619
session.upload_progress.enabled = 0
; solo en PHP 8.5
fatal_error_backtraces = 0
; 8M si no aceptas subidas, 32M si las aceptas
post_max_size = 32M
; ejemplo: siempre por debajo de post_max_size
upload_max_filesize = 24M
No uses RLIMIT_AS ni RLIMIT_DATA como sustituto: php.net avisa de que provocan justo el fallo de memoria vulnerable.
En FPM, pm.max_requests = 1 si el rendimiento lo aguanta: cada worker muere tras una petición, así que CVE-2026-109619 casi no tiene estado que reutilizar. Contra CVE-2026-109618 no sirve, porque ese fallo ocurre dentro de una sola petición.
Si trabajas con especificaciones, esto debería estar escrito como requisito no funcional: "parche de seguridad crítico aplicado y verificado en menos de X horas". En el libro de Spec-Driven Development explico por qué los NFR de seguridad tienen que ser medibles.
Límites de las mitigaciones
Las mitigaciones parciales no te protegen del todo de la vulnerabilidad PHP. Desactivar session upload progress cierra un camino confirmado de CVE-2026-109619, pero no el de .htaccess/php_value, ni CVE-2026-109618. La única mitigación completa es actualizar.
Un WAF o un plugin de seguridad no sustituye al parche. Un plugin corre dentro de PHP, cuando el intérprete ya ha parseado la petición: llega tarde. Un WAF externo sí la ve antes, pero solo bloquea patrones conocidos, y según Qualys, Cloudflare ya ha observado intentos de evadir sus reglas.
Este post no puede decirte si tu proveedor está parcheado. Ni el número de versión ni una herramienta externa lo prueban si hubo backport. En el hilo de Hacker News sobre PHP2Shell alguien preguntó si había código fiable para validar que el parche estaba aplicado, y la respuesta fue que no había ni una fuente fiable del exploit. La confirmación tiene que venir del proveedor.
Rotar secretos no deshace lo que ya se haya filtrado. Corta el uso futuro de esas credenciales, pero si alguien ya las usó, tienes que revisar logs y accesos aparte.
Vulnerabilidad PHP en hosting compartido: la acción de hoy
PHP no está muerto. Está en todas partes, y por eso una vulnerabilidad PHP en su gestión de memoria obliga a medio internet a moverse el mismo día.
Si tienes un hosting compartido, la acción concreta de hoy es una: abre el panel, apunta la versión de PHP y manda el mensaje de arriba al soporte. Con la respuesta sabrás si te toca cambiar de rama, rotar secretos o nada más.
Si quieres comentar este tipo de incidentes con otros developers que construyen en producción, en Dominicode Labs tienes la comunidad, y en el canal de YouTube más contenido sobre construir y desplegar con criterio.
Preguntas frecuentes
¿Tengo que hacer algo si tengo un hosting compartido?
Sí, aunque el parche de PHP lo aplica tu proveedor, no tú. Mira qué versión usa tu sitio, sube a 8.3 o 8.4 si sigues en 8.1 o anterior y pregunta al soporte si ya aplicó la corrección. Si tardó, cambia contraseñas de BD, claves API y salts de WordPress.
¿Mi WordPress en hosting compartido es vulnerable a PHP2Shell?
Lo es si el PHP que usa tu sitio está por debajo de 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y tu proveedor no ha aplicado un parche backporteado. WordPress no es la causa: el fallo está en PHP, así que afecta a cualquier aplicación servida con PHP-FPM, mod_php, php-cgi, FrankenPHP o LiteSpeed.
¿Cómo sé si mi proveedor ya parcheó?
Preguntando. Qualys avisa de que los parches backporteados pueden conservar un número de versión antiguo, así que phpinfo no basta. Pide al soporte que confirme si aplicaron las correcciones de CVE-2026-109618 y CVE-2026-109619, en qué fecha, y si reiniciaron los procesos de PHP.
¿Sirve un plugin de seguridad o un WAF?
Ayuda a reducir ruido, pero no sustituye a la actualización. Esta vulnerabilidad PHP está en el intérprete, en el parseo de la petición y en la gestión de memoria entre peticiones, y la única mitigación completa según php.net es actualizar.
¿Qué pasa si sigo en PHP 7.4 u 8.1?
Esas ramas no reciben versiones oficiales. El equipo de PHP publicó parches en código fuente para 7.4, 8.0 y 8.1, pero aplicarlos depende de tu proveedor o de tu distribución. Lo sensato es subir a 8.3 o 8.4 tras comprobar la compatibilidad de tu aplicación. Ten en cuenta que 8.2 llega a fin de vida el 31 de diciembre de 2026.
¿Afecta a Laravel o Symfony?
Sí, en el mismo sentido que a WordPress: el problema no está en el framework sino en el PHP que lo ejecuta. Si tu aplicación Laravel o Symfony corre sobre una versión de PHP afectada, está expuesta hasta que actualices PHP y reinicies los workers.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.