La vulnerabilidad crítica en PHP se ha traducido en millones de ciberataques en pocas horas. El aviso de INCIBE-CERT afecta a equipos de QNAP, Synology, Mitel, y Palo Alto Networks, y varias administraciones españolas han elegido la respuesta más contundente: apagar el acceso público a sus servicios.
El Servicio Andaluz de Empleo y al menos un ayuntamiento han cortado de forma temporal sus portales. No es una reacción desproporcionada. Cuando el agujero está en la capa que sostiene la web, no queda margen para la cirugía fina: o se cierra la puerta o se reza.
Son dos vulnerabilidades en el intérprete de PHP, el lenguaje sobre el que corre buena parte del software corporativo e institucional. EL PAÍS lo ha resumido como un fallo en el corazón del 70% de las webs, una proporción que encaja con el peso real de gestores de contenido como WordPress, Drupal y Joomla en la pyme española.
En el aviso de INCIBE-CERT, el equipo de respuesta a incidentes del organismo público dependiente de la Secretaría de Estado de Digitalización e Inteligencia Artificial, aparece una relación de fabricantes afectados que no tiene nada de casual: QNAP y Synology concentran buena parte del almacenamiento en red de la media empresa, Mitel domina la telefonía IP de oficina y Palo Alto Networks los cortafuegos perimetrales de medio tejido corporativo.
La paradoja es incómoda. El cortafuegos, el aparato que muchas empresas compraron para sentirse protegidas, figura en la lista de producto vulnerable. Y el parche no depende solo del departamento de sistemas: exige que el fabricante publique firmware y que alguien lo aplique en cada máquina, incluidas las que llevan años funcionando sin contrato de mantenimiento.
Un fallo en una capa invisible tumba la web de un ayuntamiento en una mañana; la factura de no saber qué corre en casa llega después.
Qué hay detrás de los dos fallos que afectan a QNAP, Synology, Mitel y Palo Alto
PHP no es un producto de nicho. Es el motor de la mayoría de los gestores de contenido con los que se construyen webs corporativas, tiendas pequeñas y portales institucionales, y su código lo mantiene una comunidad de voluntarios junto a una fundación sin ánimo de lucro. Esa estructura abarata el software para todos y, al mismo tiempo, reparte de forma desigual la capacidad de reaccionar cuando aparece un agujero. El proyecto PHP publica sus notas de versión y sus avisos de seguridad, pero no puede obligar a nadie a instalarlos.
La novedad de este episodio está en el origen del hallazgo. Según EL PAÍS, fue un sistema de inteligencia artificial el que localizó el fallo; según El Confidencial, un ingeniero voluntario frenó lo que podía haber sido un desastre mayor. Esa combinación cambia la economía de la seguridad. Encontrar vulnerabilidades deja de ser un trabajo artesanal y pasa a ser una tarea industrial, replicable y barata.
Tiene dos lecturas. La buena es que los parches llegan antes y con mejor diagnóstico. La mala es que la ventana entre el descubrimiento y la explotación se mide ya en horas. Los millones de intentos de ataque registrados en una sola jornada son la prueba más simple de ese cambio de escala.
Del Servicio Andaluz de Empleo a los ayuntamientos: el apagón como parche
Apagar el portal es la decisión más honesta y la más impopular. El SAE y los consistorios que han suspendido servicios han preferido cortar antes que arriesgar, una lógica que cualquier responsable de sistemas comparte y que ningún ciudadano que se queda sin cita previa celebra. En los casos conocidos, la interrupción se ha medido en horas y no en días.
El coste no es solo reputacional. Cada hora de servicio caído en una administración genera colas que reaparecen al día siguiente y personal atendiendo por teléfono lo que antes resolvía un formulario. En el sector privado la factura se llama ventas perdidas, y para una pyme una web caída un viernes por la tarde puede decidir el cierre del mes.
Los fabricantes afrontan ahora la parte lenta del problema: publicar firmware y convencer a sus clientes de que lo apliquen. Palo Alto Networks mantiene sus avisos técnicos en un portal de seguridad propio. El problema es la cola de cualquier lista de parches: los equipos que ya no reciben soporte oficial no aparecen en ningún boletín.
Ahí está el punto ciego de toda la cadena. El aparato comprado en 2018, con PHP embebido en su interfaz de administración, sigue conectado porque nadie lo ha apagado y nadie sabe que existe. Cosas que pasan cuando el inventario se hace a ojo.
Concentración, firmware y la factura de no saber qué corre en casa
Este episodio dice menos del código abierto que de la gestión que hacemos de él. Que una base de código mantenida en buena parte por voluntarios sostenga el 70% de las webs del planeta no es un escándalo; es una realidad que lleva dos décadas funcionando razonablemente bien. Lo que falla es el otro lado de la cadena: empresas que han digitalizado su negocio sin inventario de lo que corre en sus servidores, administraciones que descubren su dependencia el día en que el proveedor publica el aviso, y máquinas con firmware de hace ocho años a las que nadie ha vuelto a mirar.
Tomo partido: la inversión en seguridad se ha concentrado en la capa visible, la del cortafuegos y el antivirus del portátil, mientras la capa que de verdad sostiene el servicio sigue sin documentar. La lista de activos es el documento de seguridad más aburrido y el más rentable que puede tener una compañía. Sin ella, cada alerta llega como una sorpresa y cada sorpresa se paga con un apagón.
Hay una contradicción que conviene nombrar sin adornos. El mismo mercado que exige disponibilidad total acepta como normal que el software crítico se actualice cuando alguien encuentra un hueco en la agenda. Eso no lo arregla un comunicado ni una campaña de concienciación: lo arregla un calendario de mantenimiento con fecha y con responsable.
El hito que conviene vigilar no es el número de ataques, sino la fecha en que QNAP, Synology y Mitel completen el firmware corregido para toda su base instalada, incluidos los modelos descatalogados. Si esa lista tarda más de lo razonable, la próxima vez el apagón no será una decisión prudente. Será la única salida disponible, y para entonces la conversación ya no será sobre PHP.
