Café y paciencia: la semana en que se rompió media internet (y cómo parchear cada cosa)

Si esta semana abriste Twitter, tu correo o el panel de tu servidor y sentiste que todo estaba en llamas al mismo tiempo, no fue tu imaginación. En cuestión de días cayeron una vulnerabilidad crítica en PHP, un RCE en Node.js, dos CVSS 10.0 seguidos en GitLab, una librería de IA comprometida en PyPI, una brecha de secretos en Railway, datos de clientes expuestos en TiDB Cloud, ocho llaves de una autoridad certificadora que resultaron ser casi públicas y más de 400,000 certificados revocados de golpe en GoDaddy. La imagen que encabeza este artículo lo resume mejor que cualquier comunicado: café en mano, sonrisa puesta y a apagar fuegos uno por uno.

Pero ojo: este no es un artículo para mirar el incendio. Es una guía de extintores. Por cada incidente te decimos qué pasó, si te toca preocuparte y, lo más importante, qué hacer ahora mismo, con los enlaces a los parches y la documentación oficial. Sirve el café y vamos por partes.

El resumen visual de la semana: todo arde, pero seguimos online. Café y paciencia.

El parte de daños en 30 segundos

• PHP (PHP2Shell): RCE crítico sin autenticación. Actualiza a 8.4.27 / 8.3.36 / 8.2.35 / 8.5.12.
• Node.js: RCE en el decodificador Brotli. Actualiza a 22.23.4 / 24.22.1 / 26.12.1.
• GitLab: dos CVSS 10.0 en nueve días. Si es autohospedado, actualiza otra vez, sí, otra vez.
• LiteLLM 1.107.0: versión maliciosa en PyPI y Docker. Si la instalaste el 21 de octubre, rota todas tus credenciales.
• Railway: acceso no autorizado a variables de entorno. Rota secretos y credenciales de bases de datos.
• PingCAP / TiDB Cloud: datos de clientes copiados. Reemplaza tus API keys de gestión y ojo con el phishing.
• eMudhra: 8 llaves de CA recuperables por cualquiera. Revisa si tus certificados cuelgan de emSign antes del 27 de octubre.
• GoDaddy: 404,607 certificados revocados. Instala y verifica el certificado de reemplazo.

PHP2Shell: el fuego que llegó primero

La semana de locos empezó con PHP2Shell (CVE-2026-109618 y CVE-2026-109619, CVSS 9.2): una corrupción de memoria en el núcleo de PHP que permite ejecutar código en el servidor sin contraseña y antes de que tu aplicación procese la petición. Afecta a PHP desde la versión 5.4 y el exploit se filtró públicamente, así que no hay tiempo que perder.

Qué hacer

• Actualiza PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según tu rama. Las distribuciones (Debian, Ubuntu, Red Hat) a veces aplican el arreglo sin cambiar el número de versión: revisa el changelog del paquete, no solo php -v.
• Si sigues en PHP 8.1 o anterior, esas ramas ya no reciben parches: o subes con backports (cPanel, CloudLinux, TuxCare) o ese servidor no debería estar en internet.
• Mitigación temporal mientras actualizas: bloquear peticiones multipart/form-data en el borde (CDN/WAF) y desactivar session.upload_progress.enabled.

Publicamos la guía completa, con detección, mitigación en Docker y Nixpacks y todas las fuentes: PHP2Shell: la vulnerabilidad crítica de PHP que permite tomar tu servidor sin contraseña.

Node.js: la bomba Brotli

El 21 de octubre Node.js publicó versiones de seguridad para sus tres ramas (10 vulnerabilidades en total, cuatro de severidad alta). La protagonista es CVE-2026-111497, una escritura fuera de límites en el decodificador Brotli que Node trae integrado: si tu aplicación descomprime datos Brotli que controla un atacante —un cuerpo de petición, la respuesta de un fetch() a un servidor comprometido, o datos pasados a node:zlib— el resultado puede ser ejecución remota de código. La misma actualización corrige dos formas de saltarse la verificación de hostname en certificados TLS y un bug de truncamiento en dns.resolve, así que conviene instalarla aunque nunca hayas tocado Brotli.

Qué hacer

• Actualiza a Node.js 22.23.4 (LTS), 24.22.1 (LTS) o 26.12.1, según tu rama.
• Revisa también lo que no parece "un servidor": aplicaciones Electron y cualquier herramienta que empaquete su propio Node.
• Si sigues en Node 18 o 20, esas líneas están fuera de soporte y no recibirán el parche: toca migrar.
• Detalle con doble premio: esta actualización también retira de la lista de confianza de Node los certificados intermedios comprometidos de eMudhra, de los que hablamos más abajo.

Fuentes y detalle técnico: análisis del security release de octubre y, si hospedas con CloudLinux, su guía de paquetes alt-nodejs.

Manual de procedimiento de esta semana: extintor en una mano, café en la otra.

GitLab: el que parchó el 12, que parquee otra vez el 21

GitLab se llevó el récord de la semana: dos vulnerabilidades CVSS 10.0 en nueve días, ambas en su motor de expresiones regulares y reportadas por el mismo investigador (joaxcar, vía HackerOne). La primera, CVE-2026-97229 (12 de octubre), permitía ejecutar código sin autenticación mediante una expresión regular maliciosa en la configuración CI/CD; Censys contó cerca de 26,000 instancias expuestas y ya circula un exploit público. La segunda, CVE-2026-110264 (21 de octubre), es un desbordamiento de entero en el motor Onigmo al compilar expresiones regulares (se dispara, entre otras vías, al renderizar archivos .org) y afecta a todas las instalaciones autohospedadas desde GitLab 7.0, del año 2014.

Qué hacer

• Si usas GitLab.com o GitLab Dedicated actualizado, ya estás cubierto: el problema es solo de instalaciones self-managed (CE y EE).
• Actualiza a la versión corregida de tu línea: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13 (para todo lo anterior a 19.0). Si parchaste el 12 de octubre, esas versiones quedan por debajo de las nuevas: hay que actualizar otra vez.
• No existe workaround oficial: la actualización es la única protección. Planifica ventana de mantenimiento: algunas versiones incluyen migraciones de base de datos.
• Para cazar actividad sospechosa, GitLab publicó dos detecciones para instancias autohospedadas: "Onigmo native worker crash" y "Org mode render error burst".

Fuentes: BleepingComputer y la guía práctica de actualización.

LiteLLM 1.107.0: el invitado que entró por la puerta principal

El golpe más feo de la semana para quienes trabajan con IA. El 21 de octubre, atacantes publicaron una versión maliciosa de LiteLLM (1.107.0) en PyPI y en las imágenes oficiales de Docker, usando tokens OAuth de GitHub CLI robados a tres ingenieros del proyecto y un repositorio gemelo con un guion de diferencia en el nombre (Berri-AI en vez de BerriAI). La versión estuvo disponible unas dos horas e instalaba un ladrón de credenciales que se ejecuta cada vez que arranca Python, más una puerta trasera. Es el segundo compromiso de LiteLLM en 2026; el de marzo afectó a las versiones 1.82.7 y 1.82.8.

Qué hacer

• Revisa si instalaste o desplegaste litellm==1.107.0 el 21 de octubre (en PyPI entre 11:39 y 13:23 UTC), o imágenes Docker con tags v1.107.0, latest, main-latest o main-stable de ese día.
• Desinstalar no basta: el malware deja cook.pth, cook.py y un sitecustomize.py en site-packages que sobreviven a la desinstalación. Bórralos, detén el proceso cargador y reconstruye el entorno o la imagen desde cero.
• Fija la versión buena: litellm==1.106.2 (o cualquier versión anterior al 21 de octubre), y las imágenes por digest, no por tag flotante.
• Y lo serio: rota todas las credenciales a las que ese equipo o contenedor tuviera acceso —nube (AWS, GCP, Azure), Kubernetes, SSH, Git y, por supuesto, las llaves de los proveedores de IA—. Ya se observó uso posterior de credenciales AWS robadas.

Fuentes: Datadog Security Labs y el runbook de respuesta con indicadores de compromiso de Kodem.

Railway: cuando el botín son tus variables de entorno

También el 21 de octubre, Railway reveló que un tercero no autorizado accedió a los sistemas donde guarda las variables de entorno de sus clientes y que, en algunos casos, obtuvo su contenido descifrado. La plataforma pausó los despliegues, invalidó las sesiones OAuth, las credenciales de buckets y, ya el 22 de octubre, todos los tokens de su API. Railway cree que el incidente forma parte de una oleada de ataques contra plataformas cuyo objetivo son las llaves de proveedores de IA (OpenCode confirmó el 17 de octubre un incidente del mismo patrón con llaves guardadas en su consola). La lección es incómoda: hoy una API key de IA es una tarjeta de crédito para cómputo, y los atacantes lo saben.

Qué hacer

• Rota todas las variables de entorno guardadas en Railway: API keys, credenciales de registros privados y secretos de terceros.
• Rota también las credenciales de tus bases de datos (PostgreSQL, MongoDB, Redis, MySQL) y crea tokens de API nuevos, porque los anteriores fueron invalidados.
• Revisa el consumo y los registros en los servicios conectados: OpenAI, Anthropic, Stripe, GitHub, AWS, GCP. Un pico de uso de IA que no reconozcas es la señal de alarma.

Fuentes: análisis de GitGuardian y la cronología con la guía oficial de rotación.

PingCAP / TiDB Cloud: un mes dentro de la casa

PingCAP publicó el 19 de octubre su informe de incidente: entre el 9 de septiembre y el 7 de octubre, un atacante con credenciales de cuentas de servicio robadas accedió a sistemas internos, copió datos de clientes —nombres, correos, datos de organizaciones y proyectos, texto del editor SQL, información comercial y de facturación— y código fuente. También se exportó una tabla con valores cifrados de API keys de TiDB Cloud; la empresa indica que no hay evidencia de que se hayan descifrado ni usado, ni de que los datos almacenados dentro de las bases de datos TiDB hayan sido afectados. Las cifras millonarias que circulan por ahí (un grupo afirma haber robado 10.6 TB) no están verificadas.

Qué hacer

• Si eres cliente de TiDB Cloud, sigue la guía oficial: reemplaza tus API keys de gestión activas (crea las nuevas, verifica que tus aplicaciones funcionan y revoca las viejas; si sospechas mal uso, revoca primero y avisa a security@pingcap.com).
• Extrema la cautela con el phishing dirigido: el atacante tiene nombres, correos y datos de facturación, material perfecto para correos falsos muy convincentes. Verifica cualquier petición inesperada por un canal conocido.

Fuentes oficiales: informe del incidente y acciones recomendadas para clientes.

eMudhra: la llave privada que era el número 4

Y ahora, el momento "no puede ser" de la semana. El 17 de octubre, un investigador reportó que las llaves privadas de ocho certificados intermedios de CA de eMudhra (seis para TLS y dos para firma de código) podían recuperarse por cualquiera: el proceso de generación fue tan débil que las llaves P-384 resultaron ser enteros menores que 256. Una de ellas, literalmente, el número 4. Con una llave así, un atacante puede emitir certificados válidos para cualquier sitio. Chrome, Firefox, Apple y Microsoft bloquearon los intermedios entre el 17 y el 19 de octubre, y Chrome además retirará la raíz emSign ECC Root CA – G3 el 27 de octubre.

Qué hacer

• Si tus certificados fueron emitidos por eMudhra/emSign o cuelgan de la raíz emSign ECC Root CA – G3, reemplázalos antes del 27 de octubre o tus visitantes empezarán a ver errores.
• Los navegadores ya están protegidos, pero los clientes que no son navegador (APIs, contenedores, pipelines, dispositivos) dependen de su propio almacén de confianza: actualízalo. Node.js ya lo hizo en su release del 21, y Go 1.27.3 / 1.26.10 también bloquean estas llaves.
• Hasta el momento no se ha confirmado abuso ni certificados fraudulentos en los registros de transparencia, pero las llaves llevaban unos 17 meses siendo recuperables: la prudencia manda actuar igual.

Fuentes: Computerworld y la guía de verificación y corrección.

GoDaddy: 404,607 certificados revocados (y no, no fue un hackeo)

El último fuego ni siquiera fue un ataque. GoDaddy descubrió que cientos de miles de certificados (suyos y de su marca Starfield) se habían emitido sin cumplir los perfiles de su propia política de certificación, y la normativa le obligaba a revocarlos: 404,607 certificados revocados el 21 de octubre. Para rematar, la empresa no llegó a tiempo a su primera fecha límite de revocación, sumando un segundo incumplimiento. Sin llaves robadas ni cifrado roto: solo papeleo… con consecuencias muy reales para quien no actuó.

Qué hacer

• Si tu sitio usa un certificado GoDaddy o Starfield y recibiste el aviso, instala el certificado de reemplazo cuanto antes.
• Y verifícalo en producción: recibir el certificado nuevo no significa que tu servidor lo esté usando. Comprueba la cadena y la fecha desde fuera (el navegador o un verificador SSL) antes de dar el tema por cerrado.
• Si tus visitantes ven advertencias de seguridad, casi seguro es esto: certificado revocado sin reemplazar.

Fuente: Cyber Security News.

El kit oficial de la semana: café, extintor, checklist y llaves nuevas.

Tips de supervivencia para la próxima semana de incendios

Porque habrá próxima, estos hábitos separan el susto de la catástrofe:

1. Inventario o muerte: no puedes parchear lo que no sabes que tienes. Mantén una lista viva de versiones de runtimes, plataformas y servicios por proyecto.
2. Suscríbete a los avisos de seguridad de tus proveedores críticos (Node, PHP, tu plataforma de despliegue, tu CA). Esta semana, enterarse 48 horas tarde era la diferencia entre parchear y rotar credenciales.
3. Ventana de parcheo corta para críticos: un CVSS 10.0 sin autenticación se mide en horas, no en el próximo sprint.
4. Ante la duda, rota el secreto: rotar una llave es barato; descubrir dentro de un mes que la usaron, no.
5. Una llave de IA por aplicación, con límite de gasto: es la lección de Railway y LiteLLM. Las llaves de IA son el botín favorito del momento; trátalas como tarjetas con tope.
6. Fija versiones y usa lockfiles: nada de latest flotante en producción; en Docker, fija por digest. El ataque de LiteLLM entró por los canales normales de actualización.
7. Nada en versiones sin soporte: PHP 8.1 y Node 18/20 no recibieron ningún parche esta semana. Lo "gratis" sale carísimo.
8. Verifica, no asumas: versión instalada, certificado servido y parche aplicado se comprueban en producción, no en el correo de confirmación.
9. Tokens con el mínimo alcance y 2FA en las cuentas de release: el ataque a LiteLLM empezó con tokens robados de ingenieros. Lo que un token puede hacer, un atacante también.

Para cerrar: café, paciencia y parches

Semanas como esta no son una señal de que la tecnología se rompió: son el recordatorio de que mantener software es un trabajo continuo, y de que la diferencia entre un susto y un desastre suele ser tener a alguien pendiente de los avisos, con un plan y con la calma de ejecutarlo en orden. Si tu empresa no tiene ese alguien, en ARCADIG HUB ofrecemos mantenimiento y auditoría de seguridad para aplicaciones y servidores: revisamos versiones, aplicamos parches críticos y rotamos lo que haya que rotar antes de que el fuego te encuentre a ti. Estima tu proyecto o escríbenos, y que la próxima semana de incendios te agarre con el café listo y todo parcheado.

Fuentes

• PHP2Shell — guía completa de ARCADIG HUB y las notas de versión de PHP enlazadas en ella.
• Node.js — Security Online y CloudLinux.
• GitLab — BleepingComputer, The Hacker News y Rescana.
• LiteLLM — Datadog Security Labs, The Hacker News y Kodem.
• Railway — GitGuardian y Pandromeda.
• PingCAP — informe oficial y acciones para clientes.
• eMudhra — Computerworld y SOCRadar.
• GoDaddy — Cyber Security News y Cyber Updates 365.

Imagen principal: ilustración aportada por el autor. Imágenes interiores generadas con IA para ARCADIG HUB. Información verificada el 22 de octubre de 2026; los incidentes de Railway, LiteLLM y PingCAP siguen bajo investigación y pueden aparecer datos nuevos.