La vulnerabilidad PHP que los mantenedores han puntuado con 9,2 sobre 10 ha activado el protocolo de emergencia en el lenguaje que sostiene buena parte del negocio digital europeo. Dos parches anunciados con apenas horas de margen son la única barrera entre millones de sitios web y un exploit que ya tiene nombre propio: PHP2Shell.
Claves de la operación
- Dos fallos con nota 9,2 sobre 10. El equipo del proyecto fijó la publicación de ambos parches para algo más de doce horas después del aviso, con la advertencia expresa de adelantarla si aparecían detalles públicos o indicios de explotación.
- El coste recae en el alojamiento, no en el lenguaje. Quien paga la actualización son los proveedores de hosting, las agencias y los equipos internos que mantienen producción sin ventanas de mantenimiento.
- España entra por la vía del proveedor. Miles de pymes y administraciones locales dependen de un puñado de empresas de alojamiento y de gestores de contenido que heredan el riesgo sin tener equipo de seguridad propio.
El aviso llegó el lunes. Los mantenedores de el sitio oficial del proyecto comunicaron la publicación de dos parches, ambos con severidad 9,2 —a dos décimas del máximo—, y lo hicieron con una instrucción poco habitual en el ciclo de un lenguaje de código abierto: prepararse ya para actualizar en cuanto la versión estuviera disponible. La nota incluía una cláusula que mide bien la tensión del momento: el equipo se reserva adelantar la publicación si hay filtración o explotación activa.
La cifra que circula estos días en el sector —hasta un 70% de los sitios web potencialmente afectados— no es una licencia retórica. PHP sigue siendo la capa sobre la que se apoyan WordPress, Drupal, la mayoría de los gestores de contenido y las aplicaciones heredadas que ninguna empresa toca porque funcionan. La superficie de ataque no la define el lenguaje, sino la cantidad de instalaciones que llevan años sin actualizarse.
Un 9,2 no se corrige con una ventana de mantenimiento
La escala de severidad mide impacto y facilidad de explotación, no urgencia comercial. Un 9,2 implica que un atacante puede comprometer el servicio sin credenciales y con un esfuerzo bajo. Traducido a operación: no hay margen para el calendario trimestral de parches.
Ahí aparece la brecha entre el código abierto y quien lo explota comercialmente. El proyecto PHP lo sostienen voluntarios y una estructura de gobernanza que lleva años discutiendo cómo financiar su propio trabajo de seguridad, mientras las empresas que facturan millones sobre ese código rara vez contribuyen al ritmo que exige un fallo crítico. Es el mismo patrón de Log4j y de OpenSSL, y el mismo susto recorriendo la cadena de suministro del software.
Un fallo de severidad 9,2 no se corrige en el repositorio: se corrige en cada servidor que nadie recuerda que sigue encendido.
La parte incómoda es la de después. Actualizar PHP rompe compatibilidades, deja atrás funciones obsoletas y extensiones que los clientes siguen invocando. Cada salto de versión es una negociación entre seguridad y disponibilidad, y la decisión suele tomarla quien no tiene el inventario actualizado. Actualizar es fácil. Convencer, no.
El alojamiento asume una factura que no vendió
Los grandes proveedores de alojamiento compartido son el eslabón que absorbe el golpe. Su producto es la comodidad, no la administración de sistemas, y sus clientes no van a leer un aviso de seguridad. Por eso la actualización se ejecuta por defecto en la rama activa y se avisa a quien sigue en versiones antiguas, una política razonable que deja un porcentaje residual expuesto durante semanas.
En España el riesgo viaja por esa misma vía. Miles de pymes, despachos y administraciones locales contratan alojamiento en proveedores nacionales o revenden servicios de un tercero, y muchas no tienen equipo técnico propio. Para ellas la recomendación estándar —actualizar, revisar registros y, comprobar integridad— llega con el problema de siempre: nadie sabe qué versión corre su web hasta que la web se cae. Los avisos de INCIBE para empresas son el primer sitio donde mirar cuando no hay proveedor que llame.
El nombre PHP2Shell, que circuló antes de que existiera parche, también dice algo del mercado. Bautizar un fallo antes de tener la corrección es una señal de presión: acelera la respuesta de los administradores y, a la vez, sirve de recordatorio público a quien busque dónde golpear. La comunidad de seguridad lleva años discutiendo si ese doble filo sale a cuenta.
La gobernanza del código abierto, ante su enésimo examen
Ya hemos visto este guion. Log4j en 2021 y la vulnerabilidad Heartbleed de OpenSSL en 2014 dejaron la misma conclusión: el software que sostiene la infraestructura global se mantiene con recursos de proyecto pequeño y acaba casi siempre en en las mismas manos cuando toca pagar la remediación. En España ese negocio aterriza en las áreas de ciberseguridad de Indra y de Telefónica Tech, que facturan auditoría, inventario y migración mientras el lenguaje que lo hace posible sigue pidiendo donaciones.
Conviene señalar la contradicción de fondo. Nadie mide cuántos parches críticos se aplican de verdad: el sector mide la publicación, no la adopción. Un 9,2 corregido en el repositorio y sin instalar en producción es exactamente igual de peligroso que antes, con el agravante de que la conversación pública ya ha pasado a otra cosa. Ese desfase es el que explotan los grupos de ransomware semanas después, cuando el foco mediático se ha apagado. En esta redacción lo seguimos viendo cada trimestre.
El hito que conviene vigilar no es la publicación del parche, sino lo que llegue después: si el proyecto confirma explotación activa o si algún CERT europeo publica avisos de compromiso en instalaciones concretas. Ahí se sabrá si PHP2Shell fue un aviso a tiempo o la enésima lección aprendida a base de incidentes.
La entrada Una vulnerabilidad PHP de severidad 9,2: dos parches de emergencia ante un exploit que amenaza al 70% de las webs aparece primero en Moncloa.
