PHP2Shell (CVE-2026-109618 y CVE-2026-109619): qué significa para las webs en WordPress y HubSpot
El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas, conocidas juntas como PHP2Shell. PHP mueve una gran parte de la web, incluidos WordPress, Drupal, Joomla y Magento, así que esto afecta a casi cualquiera que tenga una web.
Este artículo explica qué son los dos fallos y quién tiene que actuar. También explica por qué las webs en plataformas gestionadas de forma centralizada, como HubSpot CMS y Vercel, no tienen nada que parchear, y por qué veremos más noticias así a medida que la IA cambia la forma de encontrar fallos.
Respuesta corta: si tu web funciona con PHP que gestionas tú o tu agencia, actualiza PHP ya a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o pregunta a tu proveedor de hosting si ya lo ha hecho. Si tu web está en HubSpot CMS, o en Vercel con uno de sus runtimes oficiales, no ejecuta PHP que gestiones tú y no tienes nada que parchear.
¿Qué son CVE-2026-109618 y CVE-2026-109619?
Ambos son fallos del propio PHP, no de un plugin ni de un tema. Según el aviso de seguridad de PHP, cualquiera de los dos puede permitir que un atacante sin autenticar ejecute código en el servidor web mediante peticiones HTTP manipuladas.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Tipo | Corrupción de memoria tras un error de memoria agotada | Uso de un estado obsoleto tras liberar la memoria |
| Qué ocurre | Si PHP se queda sin memoria mientras los datos de la petición solo están a medio preparar, la limpieza puede tratar datos no válidos como válidos | El estado interno de una petición puede sobrevivir, y la siguiente petición en el mismo worker puede usarlo |
| Gravedad | Crítica, puntuación CVSS 4.0 de 9,2 | Crítica, puntuación CVSS 4.0 de 9,2 |
| Corregido en | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Algunos medios citaron una puntuación de 10,0 antes de la publicación. Esa cifra no vino de PHP; el equipo de seguridad de PHP califica ambos fallos con 9,2.
Quién está en riesgo: según PHP, toda instalación que atienda peticiones web, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que el riesgo es mayor con mod_php.
Versiones antiguas: el código afectado se remonta a PHP 5.4. PHP 8.1 y anteriores ya no reciben versiones oficiales del proyecto PHP. El equipo de seguridad de PHP publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones Linux y proveedores de soporte a largo plazo publican sus propias correcciones.
¿Se está explotando? Los informes no coinciden. Según Tenable, Amazon detectó un intento en un honeypot cuatro días antes de la publicación, y desde entonces empresas de seguridad informan de ataques. Otros dicen que el código de exploit público no funciona contra una instalación por defecto. En cualquier caso, el consejo del propio PHP es claro: actualizar es la única solución completa.
Quién tiene que hacer algo
Tienes que actuar si tu web funciona con PHP que alguien gestiona específicamente para ti:
- tu propio servidor, VPS o máquina en la nube con PHP instalado
- un panel de hosting como Plesk o cPanel en el que eliges la versión de PHP
- una imagen de Docker con una versión fija de PHP
- una web en WordPress, Drupal, Joomla, Magento u otra web PHP en cualquiera de los entornos anteriores
Qué hacer:
- Comprueba tu versión de PHP. Tu panel de hosting la muestra, o pregúntale a tu proveedor.
- Actualiza a una versión corregida: 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete parcheado de tu proveedor.
- Reinicia todos los workers de PHP después de actualizar, para que no siga funcionando ningún proceso antiguo.
- Con PHP 8.1 o anterior, pasa a una versión con soporte o consigue una corrección adaptada de tu distribución o de tu proveedor de soporte.
- Si no puedes actualizar enseguida, aplica los ajustes provisionales del aviso de PHP. PHP deja claro que reducen la exposición, pero no hacen segura una instalación.
Con un hosting gestionado, buena parte de esto se hace por ti: muchos proveedores parchean PHP una sola vez para todas las webs de sus servidores. Si no estás seguro, pregúntale a tu proveedor.
Por qué las webs en HubSpot CMS y Vercel no están expuestas
PHP2Shell es un fallo de PHP. Una web que no ejecuta PHP no puede estar expuesta a él.
HubSpot CMS: una web en HubSpot no ejecuta PHP que gestiones tú. Las páginas se renderizan con HubL, el lenguaje de plantillas propio de HubSpot, en los servidores de HubSpot, y las funciones serverless se escriben en JavaScript y se ejecutan en Node.js. No hay ninguna versión de PHP que revisar ni nada que actualizar.
Vercel: los runtimes oficiales de Vercel son Node.js, Bun, Python, Rust, Go, Ruby, Wasm y Edge, además de un runtime de contenedores para código propio. PHP no es uno de ellos. Una web Next.js, React o estática en Vercel no ejecuta PHP. Si has desplegado PHP allí por tu cuenta, con un contenedor o un runtime de la comunidad, lo actualizas como en cualquier otro servidor.
La misma lógica vale para otras plataformas gestionadas que no ejecutan PHP por ti. Lo que importa no es la marca, sino quién gestiona el software que hay debajo de tu web y si ese software incluye PHP.
Fallos así pueden aparecer en cualquier parte
Sería fácil convertir PHP2Shell en una historia sobre una tecnología mala. Pero esa no es la lección. PHP es maduro, muy usado y lo mantiene un equipo de seguridad capaz, que publicó correcciones para cuatro ramas de versiones, más correcciones en código fuente para las antiguas, en una única publicación coordinada.
Todo código grande tiene fallos así: servidores web, runtimes de JavaScript, bases de datos, navegadores y sistemas operativos también. Estos dos pasaron desapercibidos durante más de una década. La pregunta no es si una plataforma tendrá alguna vez una vulnerabilidad crítica, sino lo rápido que la corrección llega a cada web que la necesita.
En la era de la IA veremos más
Lo nuevo de PHP2Shell es cómo se encontró. Según The Hacker News, investigadores de Wiz, Calif y OpenAI encontraron y comunicaron los fallos. Los modelos de IA ayudaron a convertir fallos antiguos en exploits funcionales, de modo que un solo investigador hizo en una semana lo que a un equipo le habría llevado meses.
Eso tiene dos caras. Los defensores pueden encontrar y corregir fallos antiguos mucho más rápido, y eso beneficia a todos. Pero las mismas herramientas están al alcance de los atacantes, y el tiempo entre una corrección y el primer ataque es cada vez más corto.
Así que cuenta con más avisos como este, para todas las tecnologías, no solo PHP. Cada vez menos gente preguntará si hay fallos y más preguntará lo rápido que una corrección llega a su web.
Por qué ayudan las plataformas gestionadas de forma centralizada
Aquí es donde brillan las plataformas gestionadas de forma centralizada. Compara las dos formas en que puede llegar una corrección:
- Instancias propias: cada servidor, cuenta de hosting y contenedor tiene su propia versión de PHP. Alguien tiene que revisarla, actualizarla y reiniciarla en cada caso: el propietario, la agencia o el proveedor de hosting. La mayoría se parchea en pocos días. Algunas quedan olvidadas durante meses.
- Plataformas gestionadas de forma centralizada: el proveedor gestiona un solo entorno para todos sus clientes. Cuando hace falta una corrección, la aplica una vez y todas las webs de la plataforma la tienen. Los clientes no tienen que revisar versiones, planificar mantenimientos ni acordarse de un viejo servidor de pruebas.
Eso vale para HubSpot CMS y Vercel, y también para un buen hosting gestionado de WordPress, que parchea PHP para todos sus clientes a la vez. El CMS importa menos que quién asume el trabajo de parchear y a cuántos sitios distintos tiene que llegar una corrección.
Para un equipo de marketing, ese cambio vale mucho. El tiempo que se iría en días de parches de emergencia se dedica a la web.
Qué significa si estás planificando un relanzamiento
Si PHP2Shell te ha tenido revisando servidores esta semana, vale la pena preguntarse cuánto mantenimiento de parches debería necesitar tu web.
- Pasar a HubSpot CMS: nuestro asistente de migración escanea tu web actual, sea WordPress, Drupal, Joomla, TYPO3 u otro CMS, y la reconstruye como tema nativo de HubSpot. Lee cómo funciona una migración a HubSpot en tres pasos.
- Seguir en WordPress: transjt también crea temas nativos de WordPress sin page builder, a partir de Figma o de un proyecto hecho con IA. Menos piezas facilitan las actualizaciones, y un hosting gestionado mantiene PHP al día por ti.
- Crear algo nuevo: tanto si tu diseño viene de Figma como de un builder de IA, transjt lo convierte en un tema sobre una plataforma gestionada de forma centralizada.
Elijas lo que elijas, actualiza PHP hoy allí donde lo gestiones tú.
Preguntas frecuentes
PHP2Shell es el nombre de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, corregidas el 21 de octubre de 2026. Cualquiera de las dos puede permitir que un atacante sin autenticar ejecute código en un servidor web con una versión de PHP sin parchear.
PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores no reciben versión oficial; pasa a una versión con soporte o usa una corrección adaptada de tu distribución o de tu proveedor de soporte.
Los fallos están en PHP, no en WordPress, pero WordPress funciona con PHP. Una web en WordPress está expuesta si su servidor ejecuta una versión de PHP sin parchear. Actualizar PHP, o confirmar que tu proveedor de hosting lo ha hecho, lo soluciona.
Una web en HubSpot CMS no ejecuta PHP que gestiones tú: las páginas se renderizan con HubL, el lenguaje propio de HubSpot, y las funciones serverless se ejecutan en Node.js. No hay ninguna versión de PHP que tengas que actualizar.
Los runtimes oficiales de Vercel no incluyen PHP, así que una web Next.js, React o estática allí no ejecuta PHP. Solo si despliegas PHP por tu cuenta, por ejemplo en un contenedor, tienes que actualizarlo.
Solo en parte. PHP indica ajustes provisionales que reducen la exposición a vías de ataque conocidas, pero dice que no hacen segura una instalación. Actualizar es la única solución completa.
Muy probablemente. Las herramientas de IA ayudan a los investigadores a encontrar y explotar fallos antiguos mucho más rápido, en todas las tecnologías. Lo que mejor protege una web es lo rápido que le llegan las correcciones, y ahí es donde ayudan las plataformas gestionadas de forma centralizada.