Las vulnerabilidades PHP2Shell han obligado a gobiernos y operadores digitales a retirar temporalmente servicios de internet y a desplegar parches de urgencia. El 21 de octubre de 2026, el proyecto PHP publicó cuatro versiones corregidas para dos fallos críticos que pueden permitir ejecutar código en servidores sin disponer de una cuenta válida. A 23 de octubre, la prioridad para cualquier empresa con una web es comprobar la versión real de PHP que ejecuta su alojamiento, no limitarse a actualizar WordPress.
Las incidencias afectan a una pieza básica de la infraestructura digital. PHP procesa solicitudes de muchas webs corporativas, comercios electrónicos y aplicaciones de gestión. Los problemas, identificados como CVE-2026-109618 y CVE-2026-109619, han recibido una puntuación de gravedad de 9,2 sobre 10 en CVSS 4.0. La advertencia procede del equipo de respuesta a incidentes de la Unión Europea (CERT-EU), que aconseja corregir inmediatamente los sistemas afectados o aislarlos temporalmente si no pueden parchearse.
Qué ocurrió entre el 20 y el 23 de octubre
El proyecto PHP avisó el día 20 de que preparaba una publicación extraordinaria de seguridad. El miércoles 21 llegaron las versiones corregidas. Para entonces circulaban detalles técnicos y pruebas de concepto, de modo que los administradores de servidores debían actuar con rapidez. El anuncio oficial de PHP 8.4.27 confirma que se trata de una actualización de seguridad, y la comunicación del equipo de PHP advierte de que no existe una mitigación completa que sustituya a la actualización.
La alerta tuvo consecuencias visibles. Según la cobertura internacional de Reuters, actualizada el 22 de octubre, administraciones de Países Bajos, Francia, Dinamarca y Finlandia desconectaron sitios y servicios de forma preventiva. Algunas organizaciones prefirieron interrumpir el acceso público durante las tareas de protección. Esa decisión no demuestra que sus sistemas hubieran sido comprometidos: una retirada preventiva es distinta de un ataque confirmado.
También se observaron intentos de explotación. Cloudflare informó de tráfico malicioso contra clientes y de nuevas reglas de su cortafuegos web, desplegadas antes de la divulgación pública. La existencia de intentos no permite afirmar que todas las webs vulnerables hayan sido atacadas con éxito, ni que cada caída de una página durante esos días se deba a PHP2Shell.
Las versiones de PHP que corrigen las vulnerabilidades
La medida verificable es instalar una versión que incluya los dos parches o confirmar con el proveedor un paquete equivalente corregido. Las ramas y versiones publicadas el 21 de octubre son las siguientes:
| Rama PHP | Primera versión corregida | Qué comprobar |
|---|---|---|
| PHP 8.5 | 8.5.12 | Versión instalada y servicios reiniciados |
| PHP 8.4 | 8.4.27 | Versión instalada y servicios reiniciados |
| PHP 8.3 | 8.3.36 | Versión instalada y servicios reiniciados |
| PHP 8.2 | 8.2.35 | Versión instalada y servicios reiniciados |
| PHP 8.1 y anteriores | Sin nueva versión ordinaria oficial | Migrar a rama mantenida o verificar un parche del proveedor |
La tabla reproduce las versiones enumeradas por CIRCL, el centro de respuesta a incidentes de Luxemburgo, y CERT-EU. En distribuciones Linux y servicios gestionados puede existir un parche de seguridad retroportado sin cambiar el número principal de versión. En ese caso, la empresa debe pedir al alojamiento una confirmación técnica específica sobre ambas CVE, en lugar de decidir únicamente por el número visible.
Por qué actualizar WordPress no basta
La vulnerabilidad reside en el intérprete PHP que utiliza el servidor. WordPress, Drupal, Joomla y otras aplicaciones dependen de él, pero no son necesariamente el origen del defecto. Una instalación puede tener la última versión de WordPress, todos sus complementos actualizados y continuar expuesta si el servicio PHP subyacente no ha recibido el parche. Es una diferencia decisiva para pequeñas empresas que delegan la infraestructura en un proveedor.
Los dos fallos tienen un origen relacionado con el manejo interno de memoria. En determinadas circunstancias, PHP puede utilizar información incompleta o referencias a memoria ya liberada al procesar peticiones. Un atacante podría aprovechar esa situación para ejecutar instrucciones con los permisos del proceso web. La gravedad concreta depende de la configuración y del escenario de explotación; no equivale automáticamente a control total de cada servidor expuesto.
El riesgo también cambia según el despliegue. CERT-EU destaca la demostración de explotación contra Apache con mod_php y señala que otros entornos, como PHP-FPM, también están en el perímetro de riesgo. Por ello no es prudente concluir que una web está protegida simplemente porque utiliza Nginx, un servicio gestionado o una configuración distinta de Apache.
Qué debe revisar hoy una empresa con página web
Primero, identificar al responsable del alojamiento. En un servidor propio, el equipo técnico debe comprobar paquetes y servicios realmente activos. En un hosting compartido o administrado, corresponde solicitar al proveedor que confirme por escrito la corrección de CVE-2026-109618 y CVE-2026-109619 en el entorno donde se ejecuta la web. El panel de WordPress no siempre refleja los detalles de los parches aplicados por la distribución.
Segundo, planificar la actualización y verificarla. Antes de cambiar de rama conviene disponer de copia de seguridad y comprobar compatibilidad con aplicaciones y extensiones. Una vez aplicado el parche, el responsable técnico debe verificar la versión efectiva de PHP, reiniciar los procesos necesarios y probar las funciones críticas: formularios, pagos, acceso de clientes, integraciones y administración.
Tercero, revisar la exposición anterior. Haber instalado el parche evita determinados ataques futuros, pero no descarta por sí mismo una intrusión previa. Si existen indicios de actividad sospechosa, hay que conservar registros, analizar accesos y valorar la rotación de credenciales comprometidas con personal especializado. No sería riguroso afirmar que cualquier web que estuvo sin actualizar ha sufrido un robo de datos.
Cuarto, no confundir un cortafuegos con la solución definitiva. Cloudflare ha desplegado reglas de protección, pero el propio proveedor pide actualizar PHP incluso cuando esas defensas están activas. Un cortafuegos reduce ciertas vías de ataque; no modifica el código vulnerable del servidor.
El impacto empresarial va más allá de una web caída
Para un comercio electrónico, una interrupción puede traducirse en pedidos no procesados, consultas de clientes sin respuesta y gastos de recuperación. Para una asesoría o una pyme industrial, la dependencia puede estar en una intranet, un formulario de presupuestos o una plataforma externa. La prioridad no es medir el impacto por el número de webs que usan PHP, sino identificar qué procesos de negocio quedarían interrumpidos o expuestos.
El episodio vuelve a poner de relieve la concentración tecnológica: un componente mantenido por una comunidad de desarrolladores sostiene servicios públicos y privados de todo el mundo. También evidencia el doble papel de la inteligencia artificial. Herramientas asistidas por IA ayudaron a descubrir fallos que llevaban años en el código, mientras los investigadores advierten de que pueden acelerar la búsqueda de nuevas vías de explotación.
La recomendación final es concreta: verificar hoy el estado del PHP del servidor y documentar la respuesta del proveedor. La alarma mundial está justificada por la gravedad técnica y la extensión potencial, pero no debe convertirse en una afirmación infundada de que todas las páginas están comprometidas. La diferencia entre vulnerabilidad, intento de ataque, intrusión confirmada y cierre preventivo debe mantenerse clara.
Fuentes y alcance de esta actualización
Información contrastada hasta la mañana del 23 de octubre de 2026 (hora peninsular española). Fuentes primarias: CERT-EU, proyecto PHP, CIRCL y Cloudflare. Contraste independiente: Reuters. Para entender otros riesgos de dependencia tecnológica, véase nuestro análisis sobre la caída de Google Cloud y los bancos europeos.
Imagen destacada: Caspar Camille Rubin / Unsplash (licencia Unsplash). Fotografía ilustrativa de código PHP, no captura del incidente.
