Artículo · Seguridad
La semana negra de los servidores web: qué aprender de ella
En diez días de octubre de 2026 coincidieron tres problemas en las tres capas que sostienen casi cualquier sitio web: cinco fallos en Nginx, el servidor que recibe las visitas; PHP2Shell, en el lenguaje que ejecuta la mayoría de los sitios; y el caso eMudhra, en el sistema de certificados que hace funcionar el candado del navegador.
Ya escribimos sobre cada uno por separado. Este artículo es sobre lo que tienen en común, el papel que jugó la inteligencia artificial y las decisiones que un negocio puede tomar hoy para que la próxima semana así le pille preparado.
Diez días, tres capas
- 14 de octubre: Nginx
Las versiones 1.30.6 y 1.31.7 corrigen cinco fallos que, con ciertas configuraciones, pueden tumbar el servidor, ejecutar código o saltarse la verificación de certificados de cliente.
- 17 al 22 de octubre: eMudhra
Se descubre que ocho certificados intermedios de esta certificadora tenían claves privadas que se podían adivinar. Los navegadores los bloquean en tres días y la empresa abandona el negocio de certificados web.
- 20 al 23 de octubre: PHP2Shell
Se filtran dos fallos críticos en PHP antes de que exista la corrección. Gobiernos europeos desconectan sitios, Cloudflare registra millones de intentos de ataque y PHP publica parches de urgencia.
Lo que tienen en común
Ninguno de los tres es culpa del dueño del sitio. Nadie que haya contratado un sitio en WordPress eligió el fallo de PHP, y nadie que tenga un certificado HTTPS eligió a eMudhra como autoridad de confianza de su navegador. Son problemas de la infraestructura compartida sobre la que todos construimos.
Pero los tres tienen la misma solución práctica: alguien tiene que enterarse a tiempo, entender si le afecta y actualizar. Los sitios que salieron bien parados esa semana no eran los que tenían la mejor tecnología. Eran los que tenían a una persona responsable que respondió el mismo día.
El papel de la inteligencia artificial
Según la AFP, los fallos de PHP los reportaron en agosto, de forma independiente, la firma Calif y OpenAI. Diario Libre recoge que Calif usó un modelo de OpenAI para identificar uno de ellos. La misma nota de la AFP sitúa el caso en una ola de descubrimientos impulsada por modelos de IA cada vez más capaces, con la proyección de que 2026 podría duplicar el récord de vulnerabilidades del año anterior.
Esto tiene dos caras. La buena: fallos que llevaban catorce años escondidos en PHP se encuentran y se corrigen. La incómoda: si las herramientas para encontrar fallos son más accesibles, también lo son para quien quiere explotarlos, y el tiempo entre que se publica una corrección y aparecen los ataques se acorta. En PHP2Shell, los ataques empezaron antes que la corrección.
Para un negocio, la conclusión es sencilla: el ritmo de actualizaciones de seguridad no va a bajar. Va a subir.
Lo que funcionó
Vale la pena decir también lo que salió bien, porque es lo que hay que copiar.
La coordinación entre navegadores
Google bloqueó los certificados de eMudhra en Chrome en menos de dos horas desde el reporte, sin que nadie tuviera que actualizar el navegador. Apple, Mozilla y Microsoft lo hicieron en tres días.
La transparencia de certificados
Como Chrome exige que todo certificado esté en registros públicos, se pudo comprobar que nadie había emitido certificados falsos con las claves débiles antes del bloqueo.
Las actualizaciones automáticas
Los sitios en plataformas gestionadas, donde el proveedor actualiza PHP por ti, quedaron protegidos sin que su dueño hiciera nada.
Desconectar a tiempo
Apagar un sitio unas horas es incómodo. Los gobiernos que lo hicieron eligieron un problema pequeño y seguro en vez de uno grande e incierto.
Lo que falló
La filtración antes del parche
Los detalles de PHP2Shell circularon un día antes de que existiera la corrección. Nadie pudo actualizar antes de que empezaran los ataques.
Las versiones sin soporte
Miles de sitios corren en PHP 7.4, 8.0 u 8.1, para los que no hubo versión corregida oficial.
El software que no es un navegador
Los navegadores se protegieron solos de eMudhra. Los servidores, contenedores y aplicaciones que traen su propia lista de certificados no, y muchos siguen sin actualizar.
Los servidores sin dueño
El servidor que configuró un técnico que ya no trabaja con la empresa, el sistema interno que «funciona y no se toca». En esa semana, nadie sabía a quién llamar.
Cinco decisiones para la próxima vez
Ten un responsable con nombre
Una persona o empresa que reciba los avisos de seguridad de lo que usas y a la que puedas llamar un martes por la noche. Si hoy no sabes quién es, esa es la primera tarea.
Haz un inventario de una página
Qué sitios y sistemas tienes, dónde están alojados, en qué tecnología y versión, y quién los mantiene. Con eso, ante el próximo aviso sabes en cinco minutos si te afecta.
Prefiere lo que se actualiza solo
Hosting gestionado, renovación automática de certificados, plataformas donde el proveedor aplica los parches. Pagas un poco más y duermes mejor.
Sal de las versiones sin soporte
No esperes al próximo fallo. Migrar con calma cuesta menos que migrar de urgencia.
Ten respaldos que hayas probado
Un respaldo que nunca intentaste restaurar no es un respaldo. Si mañana tienes que volver a empezar, es lo único que te salva.
Una nota sobre nosotros
Nosotros desarrollamos con Next.js y Node.js, no con PHP, así que PHP2Shell no afectó a los sitios que hemos entregado. Pero Node.js sí necesitó actualizarse por el caso eMudhra, y React, la base de lo que usamos, tuvo su propio fallo crítico en diciembre de 2025. Ninguna tecnología te libra de esto. Lo que te libra es que alguien esté pendiente.
Fuentes consultadas
AFP vía Ensegundos, 21 de octubre
Descubrimiento de los fallos de PHP, papel de la IA y sitios desconectados en Europa.
Diario Libre, 22 de octubre
Cifras de ataques reportadas por Cloudflare y uso de un modelo de OpenAI por parte de Calif.
Google Security Blog y Help Net Security
Respuesta de los navegadores al caso eMudhra.
The Hacker News y Sevydevy
Detalle de los cinco fallos de Nginx.
Preguntas frecuentes
- ¿Fue un ataque coordinado?
- No. Son tres problemas independientes que coincidieron en el tiempo. Lo que los une es que afectan a la infraestructura común de internet, no a un sitio o empresa concretos.
- ¿Mi negocio necesita un equipo de seguridad?
- Un negocio pequeño no necesita un equipo propio. Necesita saber quién mantiene cada cosa y que esa persona o empresa responda a tiempo. Para muchos, eso es un contrato de mantenimiento o un hosting gestionado.
- ¿Cada cuánto debería revisar mis sistemas?
- Las actualizaciones de seguridad deberían aplicarse en días, no en meses. Una revisión general de versiones y respaldos cada trimestre es un buen mínimo para un negocio pequeño.
Seguir leyendo
¿Quieres el inventario de una página hecho?
Te ayudamos a listar qué sistemas tienes, en qué están hechos y quién los mantiene. Es el primer paso y el que más gente se salta.
Escribir por WhatsApp