Al menos 8,600 servidores en México cargan hoy una versión de PHP que nunca recibirá una corrección. Entre ellos hay sistemas de la SEP, la Secretaría de Gobernación y gobiernos estatales. Y el problema es que acaba de aparecer la falla que los pone a todos en la mira.
La semana pasada, dos fallas en PHP —la tecnología con la que funcionan 7 de cada 10 sitios web del mundo— obligaron a una respuesta de emergencia global. La Agencia de Seguridad Nacional de Estados Unidos (NSA) llamó a parchar de inmediato o desconectar los servidores. En Países Bajos, ministerios, hospitales y medios apagaron sus páginas por precaución.
La falla no está en cada página, sino en la base sobre la que están construidas: el código. En México, esa base lleva años sin mantenimiento. “En los próximos días vienen ataques sumamente fuertes, y que serán exitosos, contra las organizaciones que no hayan actualizado sus sistemas”, advierte Víctor Ruiz, fundador de la firma de ciberseguridad SILIKN, consultado por MILENIO. “Será caótico, te lo puedo asegurar”.
Qué es PHP y qué falló
PHP es un lenguaje de programación con el que se construyen páginas web. Con él funcionan WordPress, tiendas en línea y muchos portales de gobierno. Según W3Techs, lo usa el 70.2% de los sitios cuyo lenguaje se conoce.
Las fallas, registradas como CVE-2026-109618 y CVE-2026-109619 y apodadas PHP2Shell, están en el propio PHP, no en una página en particular. Por eso un sitio bien mantenido sigue expuesto si el PHP que corre debajo no se actualiza.
La falla se activa con algo tan común como subir un archivo a una página. Un atacante envía un archivo diseñado para que PHP agote su memoria y, en ese instante, queda un hueco por el que se asoma información que aún no se había borrado. No hace falta usuario, contraseña ni ningún formulario especial: basta con que el servidor acepte recibir archivos, que es la forma en que viene configurado de fábrica.
“Es una vulnerabilidad muy curiosa: sólo se necesita que el servidor acepte peticiones y subir archivos”, explica Nicolás Azuara, especialista en ciberseguridad consultado por MILENIO. En una segunda petición hecha en el momento justo, el servidor devuelve hasta 67 kilobytes de esa memoria sin limpiar, que pueden contener contraseñas, claves de acceso y certificados. El equipo de PHP calificó ambas fallas con 9.2 de 10 en gravedad.
Qué pasa en México
Aunque no hay una cifra oficial de cuántos sistemas mexicanos están en riesgo. Para este texto se consultó Shodan, un buscador que registra los equipos conectados a internet y la versión de software que cada uno declara. El conteo es del 22 de octubre de 2026 y cuenta servicios expuestos, no sitios: un mismo equipo puede aparecer varias veces.
De los 39,661 servicios con PHP detectados en el país, al menos 8,600 usan una versión sin parche posible: cerca de uno de cada cinco. Y es un mínimo, porque muchos servidores ni siquiera revelan su versión.
El grueso del problema se concentra en las versiones más viejas. Hay 2,880 servicios con PHP 7.2 y 3,222 con la 8.1, dos ramas que ya no reciben soporte, además de cientos más repartidos en las versiones 5, 7.0, 7.1, 7.3, 7.4 y 8.0. Otros 5,731 corren PHP 8.2: esa sí tiene corrección, pero sigue vulnerable mientras su dueño no la instale.
Como contexto, Colombia hizo un ejercicio parecido: su equipo de respuesta, Colcert, contó 8,699 servicios con PHP expuestos. En México no se tiene registro de una alerta equivalente de la autoridad.
El gobierno, con software de hace 20 años
Al filtrar solo dominios gob.mx, aparecieron 550 servicios de gobierno con PHP. De una muestra de 20 revisados uno por uno, 19 usaban versiones vulnerables y solo uno estaba actualizado.
Entre los casos documentados, dos destacan por su antigüedad. Un sistema de la Secretaría de Educación Pública corre con PHP 4.3, de 2004, y uno de la Secretaría de Gobernación con PHP 5.2, de 2007. Ambas versiones llevan más de 15 años sin recibir actualizaciones de seguridad de ningún tipo.
También aparece un patrón revelador. La Secretaría de Relaciones Exteriores tenía un servidor ya actualizado a la versión corregida, mientras otros de la misma dependencia seguían en versiones sin parche. Es decir, conocían la falla y la atendieron a medias.
Las universidades, el blanco más grande
La institución con más servicios PHP del país no es una dependencia de gobierno: es la UNAM, con 820. Entre todas las universidades públicas de la lista suman más de 1,800. Guardan datos de cientos de miles de estudiantes y trabajadores, y en la revisión aparecen con versiones sin parche como la 7.0 y la 8.1.
Cinco días de octubre
La falla debía revelarse el jueves 22 con el parche listo, como marca la práctica de seguridad. No ocurrió así: los detalles se filtraron antes y los atacantes llegaron primero.
Amazon registró el primer intento de ataque el 17 de octubre, cuatro días antes de que la falla fuera pública. El 20 se filtraron los detalles y el equipo de PHP tuvo que adelantar el parche. Esa madrugada, una herramienta de ataque funcional apareció en un foro de internet de forma anónima.
La mañana del 21, en Países Bajos, el propio centro nacional de ciberseguridad, portales de gobierno y medios apagaron sus sitios por precaución. A las 8:00 de la mañana, hora del centro de México, PHP publicó la corrección de emergencia. Horas después, la NSA y la CISA pidieron parchar o desconectar los sistemas de inmediato.
Por qué “Octubre Negro”
El nombre no es oficial. Usuarios en redes lo empezaron a usar para agrupar una racha de incidentes de este mes, no solo PHP2Shell.
En la misma semana, LiteLLM, una herramienta para conectar aplicaciones con inteligencia artificial, distribuyó una versión alterada que robaba contraseñas. La plataforma Zeabur confirmó el robo de datos de 321,810 cuentas y anunció su cierre. Railway, otro servicio de alojamiento, reportó accesos indebidos a claves de sus clientes.
No hay pruebas de que estos casos estén coordinados. Lo que los une es el blanco: la infraestructura invisible sobre la que funcionan miles de servicios.
Por qué es tan grave
Quien aprovecha la falla puede tomar el control del servidor: instalar programas, borrar información o usarlo para entrar a otros sistemas de la misma red. La NSA advirtió que los atacantes podrían robar datos sensibles o interrumpir servicios.
Hay un segundo riesgo menos visible. La falla también permite leer la memoria del servidor, donde se guardan contraseñas, claves de acceso y certificados. Actualizar cierra la puerta, pero no recupera lo que ya pudo salir.
El tercer problema son las versiones viejas. PHP solo corrigió las versiones 8.2 a 8.5; las anteriores ya no reciben soporte. A nivel mundial, unos 884,000 servidores anuncian una de esas versiones sin soporte: el 59% de los que muestran cuál usan.
El matiz: no todo servidor cae igual
Explotar la falla no es trivial. La firma Sansec concluyó el 22 de octubre que un ataque masivo es menos probable de lo previsto: requiere conocer bien el servidor y que se cumplan ciertas condiciones. Hoy las pruebas de ataque que circulan funcionan sobre todo contra servidores Apache con PHP 8, el tipo más común.
Eso no quita la urgencia. Basta con que un atacante elija bien su blanco, y los sistemas olvidados son los más fáciles de elegir.
Azuara apunta un dato tranquilizador: muchas de las herramientas de ataque que se comparten en internet son falsas o traen trampas para engañar a quien las use. Pero advierte cuál es el verdadero problema: “afecta casi todas las versiones de PHP y, lamentablemente, muchos sistemas se encuentran muy desactualizados”. Ahí es donde México queda expuesto.
Qué sigue
Ruiz anticipa dos oleadas. En las primeras horas, ataques automáticos que rastrean internet en busca de servidores vulnerables; después, en las siguientes semanas, campañas más dirigidas contra las organizaciones rezagadas. El botín posible va del robo de bases de datos y la alteración de páginas hasta la instalación de accesos ocultos para entrar cuando quieran.
Para el sector público, su diagnóstico es duro: “vulnerabilidades como PHP2Shell no distinguen recursos presupuestales”, de modo que tanto una secretaría estatal como un pequeño ayuntamiento quedan igual de expuestos. Advierte además que la falta de monitoreo juega en contra: “la ausencia de alertas no descarta una intrusión”, y obliga a revisar los registros hacia atrás, no solo a actualizar.
El parche ya existe, pero publicarlo no termina el problema. Cada institución tiene que instalarlo en todos sus servidores y, si estuvo expuesta, cambiar sus contraseñas y claves, porque la falla pudo exponerlas antes de la actualización.
Para el usuario común no hay nada que hacer en su teléfono o computadora: la falla vive en los servidores, no en los dispositivos. La responsabilidad es de quien opera cada sitio.
El riesgo de fondo no es esta falla en particular, sino lo que revela: buena parte de la infraestructura pública mexicana corre sobre software que nadie actualiza. PHP2Shell tiene corrección; la próxima falla llegará a los mismos servidores olvidados.