PHP publicó el 21 de octubre parches de emergencia para PHP2Shell, dos fallos críticos (CVSS 9.2) que permiten a un atacante sin cuenta ejecutar código en un servidor web. Afectan a webs en PHP como WordPress o PrestaShop, aunque su código sea seguro. Actualiza hoy a 8.5.12, 8.4.27, 8.3.36 u 8.2.35: ya hay intentos de explotación.
Lo esencial
- Los fallos son CVE-2026-109618 y CVE-2026-109619, ambos con CVSS v4.0 de 9.2. El primero corrompe la memoria cuando esta se agota al analizar entradas conforme a RFC 1867. El segundo corrompe el estado global tras un error fatal.
- Versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Son vulnerables las inferiores en cada rama.
- Afectan a casi todas las versiones de PHP desde la 5.4. INCIBE-CERT indica que todas podrían estar afectadas y que las pruebas se hicieron solo en las versiones 5 a 8.
- watchTowr informó de «intentos de explotación activa» de ambos fallos a las 14:19 UTC del 21 de octubre, según SecurityWeek. En ese momento no había ninguna intrusión confirmada y ninguno estaba en el catálogo KEV de CISA.
- El CCN-CERT emitió la alerta AL 11/26, de nivel crítico. INCIBE-CERT le asigna importancia 5 (crítica).
¿Me afecta si mi web usa WordPress, PrestaShop o un desarrollo a medida?
Sí, si corre sobre PHP. El fallo está en el lenguaje, no en tu aplicación. Quedan expuestos los sitios aunque su propio código sea seguro: WordPress, WooCommerce, PrestaShop, Magento, Laravel y los desarrollos a medida. Y no solo la web. También el CRM, el portal de clientes o la intranet, si usan PHP.
El mayor riesgo está en servidores Apache con mod_php. Según The Hacker News, ahí basta una sola petición sin autenticar para activar el ataque, antes de que se ejecute código de la aplicación. En PHP-FPM, el segundo fallo también llegó a ejecutar código, pero esa vía depende de una operación dentro de la aplicación en ejecución.
Hay un riesgo añadido: los fallos permiten leer memoria del proceso, que puede contener credenciales y claves de API.
¿Qué pasa si mi servidor usa una versión antigua de PHP?
Es el caso más delicado. INCIBE-CERT anunció antes del lanzamiento parches retrocompatibles para las ramas 7.4, 8.0 y 8.1. Pero la tabla de versiones corregidas de The Hacker News solo recoge de la 8.2 a la 8.5. Confirma en el aviso oficial de PHP si tu rama tiene parche. Si tienes un servidor heredado en una rama sin corrección, da por hecho que está expuesto.
¿Basta con tener Cloudflare o un WAF?
No. Los detalles se filtraron un día antes de la divulgación prevista para el 22 de octubre. Cloudflare activó reglas de protección por defecto antes del parche, pero reconoce que son solo una medida provisional. Te dan horas, no sustituyen a la actualización.
Qué hacer hoy
- Pregunta a tu proveedor de hosting o a tu informático qué versión de PHP ejecutan tus servidores y si ya han aplicado 8.5.12, 8.4.27, 8.3.36 u 8.2.35. En hosting compartido o gestionado, exige la confirmación por escrito.
- Haz la lista: web, tienda online, CRM, portal de clientes, intranet. Todo lo que use PHP entra.
- Si no puedes actualizar aún, aplica las mitigaciones temporales. Para CVE-2026-109618:
memory_limit=-1y límites apost_max_sizey al tamaño de las peticiones en el servidor web o proxy. Para CVE-2026-109619:session.upload_progress.enabled=0y reinicia todos los workers. Ninguna mitiga el fallo por completo. - Apaga los servicios expuestos que no sean indispensables, como recomienda el CCN-CERT. Activa el WAF o las reglas de Cloudflare si las tienes.
- Tras actualizar, revisa los registros de acceso desde el 17 de octubre en busca de peticiones anómalas. Si hay indicios de compromiso, rota las claves de API y las credenciales de las aplicaciones expuestas.
Qué significa para una pyme
Este aviso va por delante de los demás de la semana. Muchos fallos críticos afectan a un producto que quizá no usas. Este afecta al componente base de buena parte de las webs de pymes españolas, y lo más probable es que no sepas qué versión de PHP tienes.
Que el parche exista no significa que esté aplicado. En hosting compartido dependes de tu proveedor. En un servidor propio o un VPS, de quien lo mantenga. Si hoy nadie puede decirte la versión exacta que corre en cada servidor, ese es el problema de fondo, más allá de PHP2Shell.
El punto débil real son los sistemas heredados: la web antigua que nadie toca, la intranet que sigue en una rama vieja. Las mitigaciones y el WAF compran tiempo. La decisión de verdad es migrar, aislar o apagar. Si necesitas ayuda para hacer ese inventario y priorizar, puedes verlo con nuestro equipo de ciberseguridad.
Preguntas frecuentes
¿Hay ataques confirmados?
Hay intentos de explotación activa detectados por watchTowr el 21 de octubre. A fecha de esa actualización, ninguna fuente había confirmado una intrusión concreta.
Si mi código es seguro, ¿sigo en riesgo?
Sí. El fallo está en PHP, no en tu aplicación.
¿Qué versión debo tener?
8.5.12, 8.4.27, 8.3.36 u 8.2.35, según tu rama. Para ramas anteriores, confirma en el aviso oficial de PHP si hay parche.
Fuentes
- CCN-CERT – Alerta CCN-CERT AL 11/26: actualización inmediata de vulnerabilidad crítica en PHP
- INCIBE-CERT – Múltiples vulnerabilidades en PHP
- The Hacker News – PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge
- SecurityWeek – PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors
