72 horas de vulnerabilidades: qué parchear, qué rotar y qué certificados cambiar

Entre el lunes 19 y el jueves 22 de octubre de 2026 se publicaron ocho incidentes que afectan a infraestructura muy común: dos fallos críticos en PHP, una release de seguridad de Node.js con diez CVE, un RCE sin autenticación en GitLab con CVSS 10.0, una brecha en las variables de entorno de Railway, una versión maliciosa de LiteLLM en PyPI y Docker Hub, el aviso de PingCAP sobre TiDB Cloud, la revocación de 404.607 certificados de GoDaddy y la desconfianza en ocho CA intermedias de eMudhra.

Leídos como titulares son ocho noticias. Para quien mantiene servidores son tres tareas: actualizar, rotar secretos y revisar certificados. Este post los ordena así, con las versiones corregidas y los comandos para comprobarlo.

Resumen: quién tiene que hacer qué

1. Actualizar runtimes y servidores

PHP: php2shell

Un post en Hacker News filtró el 20 de octubre los identificadores de dos fallos críticos de PHP antes del fin del embargo, y el proyecto adelantó la publicación al 21 de octubre a las 14:00 UTC. CVE-2026-109618 es una corrupción de memoria cuando PHP se queda sin memoria a mitad de procesar la petición; CVE-2026-109619 es un use-after-free entre peticiones del mismo worker. Las dos se explotan sin autenticación, afectan a todas las instalaciones que sirven PHP por web y son peores con mod_php, donde Rapid7 indica que se explotan antes de que corra el código de la aplicación. Wiz demostró RCE contra WordPress, Drupal y Joomla. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; si usas los paquetes de tu distribución Linux, mira el aviso de tu proveedor, que en muchos casos parcheó antes. Si no puedes actualizar hoy, la mitigación oficial temporal es session.upload_progress.enabled=0 en php.ini o en el pool de FPM (no vale ini_set ni .user.ini) y reiniciar todos los workers. Si prefieres delegar la actualización: parche de seguridad PHP.

Node.js: Brotli y hostnames TLS

El 21 de octubre Node.js publicó diez CVE para las ramas 26.x, 24.x y 22.x. Las cuatro altas:

• CVE-2026-111497: escritura fuera de límites en el descompresor Brotli, con posibilidad de RCE. Express 5 y fetch() descomprimen Brotli de forma automática, así que basta con que tu servidor reciba o tu código descargue una respuesta comprimida manipulada.
• CVE-2026-106069 y CVE-2026-105483: la comprobación del hostname de un certificado TLS se puede saltar. Un cliente Node podría aceptar un certificado válido emitido para otro dominio.
• CVE-2026-105482: dns.resolve trunca los nombres que contienen un carácter NUL.

Versiones corregidas: v26.12.1, v24.22.1 y v22.23.4. Node 20 y 25 están fuera de soporte y no reciben parche: si sigues en ellas, la actualización es de rama mayor. No hay explotación reportada. Si sigues en 20 o 25 y prefieres no hacer el salto tú, mira parche de seguridad Node.js.

node --version
# en Docker, la imagen base es la que manda:
docker run --rm tu-imagen node --version

NGINX: un año con mucho trabajo

NGINX acumula en 2026 varias tandas de avisos. En mayo salió CVE-2026-42945, “NGINX Rift”: la plataforma de IA de DepthFirst lo encontró en unas seis horas, y el fallo venía de la versión 0.6.27, publicada en 2008. nginx.org lo califica de gravedad media; la Cloud Security Alliance y Help Net Security lo dan como crítico (9.2), y VulnCheck vio intentos de explotación desde el 16 de mayo. Se corrigió en 1.31.0 y 1.30.1.

La tanda de octubre trae cinco CVE más: CVE-2026-15176, 93479, 95101 (request smuggling en HTTP/3), 97629 (falsificación de sesión TLS que salta la verificación del certificado de cliente) y 97205. Se corrigen en 1.31.7+ y 1.30.6+. Mientras actualizas, nginx.org propone evitar $request_filename y alias (15176) y usar capturas con nombre en lugar de capturas sin nombre en las location con regex (93479). La actualización y la revisión de esa configuración las cubre parche de seguridad NGINX.

nginx -v

GitLab self-managed: CVSS 10.0

El 21 de octubre GitLab publicó CVE-2026-110264: un desbordamiento de entero al compilar una expresión regular manipulada permite a un usuario sin autenticar ejecutar código en el servidor. Afecta a CE y EE desde la versión 7.0, de 2014. GitLab.com y GitLab Dedicated ya están parcheados; las instalaciones propias hay que subirlas a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, según la rama. A 22 de octubre no se conoce explotación.

Nueve días antes, el 12 de octubre, GitLab ya había parcheado otro 10.0 (CVE-2026-97229, también con expresiones regulares en CI/CD) en 19.2.8, 19.3.5 y 19.4.2, y de ese hay PoC público. Si no aplicaste aquel, las versiones nuevas de esas ramas incluyen también esa corrección. Para que lo actualicemos nosotros: actualizar GitLab self-managed.

Por qué salen tantos fallos viejos

Dos de los fallos de esta lista vivían desde hace más de una década: el de GitLab desde 2014 y NGINX Rift desde 2008. En el caso de NGINX sabemos cómo se encontró: una herramienta de IA tardó unas seis horas. El FIRST (Forum of Incident Response and Security Teams) prevé cerrar 2026 cerca de 66.000 CVE, y atribuye parte de la subida a herramientas de IA que buscan fallos solas. La misma fuente avisa de que otra parte es contabilidad (bases de datos que catalogan más y registran fallos antiguos) y de que la proporción de CVE explotados se mantiene estable. Para un equipo pequeño eso significa que la lista de avisos que leer crece, aunque la de urgencias no lo haga al mismo ritmo, y que conviene tener un inventario de versiones para saber en un minuto si un aviso te afecta.

2. Rotar secretos, en orden

Tres incidentes de la lista exponen credenciales en lugar de código:

• Railway detectó el 21 de octubre actividad anómala en los sistemas que guardan las variables de entorno de sus clientes. Un tercero pudo acceder a variables cifradas y en algunos casos descifrarlas. Railway pausó todos los despliegues y pide rotar credenciales. No ha publicado cuántos clientes están afectados ni cómo entraron.
• LiteLLM 1.107.0, publicado el 21 de octubre en PyPI y Docker Hub, contiene un ladrón de credenciales y un cargador remoto que se activa al arrancar cualquier proceso Python del host, no solo LiteLLM. Los atacantes publicaron con tokens OAuth de GitHub CLI robados a tres ingenieros. El tag de GitHub no contiene el código malicioso, que solo está en los paquetes publicados. Es la segunda vez este año.
• PingCAP informa de que, entre el 9 de septiembre y el 7 de octubre, alguien usó credenciales robadas de una cuenta de servicio para entrar en sistemas internos y copiar datos y código fuente: metadatos de cuentas y proyectos, texto del editor SQL, registros de facturación y valores cifrados de API keys. No hay evidencia de impacto en los datos guardados en TiDB. El grupo FulcrumSec dice tener 10,6 TB; PingCAP no lo ha confirmado.

El orden importa, porque rotar una clave en un host que sigue comprometido solo le da al atacante la clave nueva.

1. Contener. Con LiteLLM 1.107.0, para el servicio y reconstruye el host o el contenedor desde una imagen limpia con la versión fijada a 1.106.2 (litellm==1.106.2 en requirements.txt, o el tag de imagen exacto, nunca latest). El cargador se ejecuta con cualquier proceso Python, así que limpiar solo el paquete no basta.
2. Hacer inventario. Lista lo que había en ese host o en esas variables: claves de proveedores de LLM, credenciales de la nube, contraseñas de base de datos, tokens de CI, webhooks, claves de pasarela de pago. En Railway, la lista son las variables de cada servicio y entorno.
3. Empezar por lo que más abre. Primero credenciales con permisos amplios (IAM o cuentas raíz de la nube, tokens de CI/CD y de GitHub, usuarios de base de datos), después las APIs de terceros.
4. Emitir, desplegar, revocar. Crea la credencial nueva, despliégala y revoca la vieja. Con los despliegues de Railway en pausa, revocar antes de poder actualizar la variable deja el servicio caído hasta que vuelvan; para claves de pago o de la nube, una caída corta cuesta menos que dejar viva una clave filtrada.
5. Mirar el uso de la clave vieja. Revisa los registros de acceso del proveedor (CloudTrail, el panel de la API, los logs de la base de datos) desde el día del incidente.

Si tus servicios guardan las credenciales en un gestor de secretos y no en variables escritas a mano, el paso 4 es mucho más corto. Es una de las cosas que revisamos en los proyectos de cloud y DevOps y al diseñar APIs que dependen de claves de terceros. Si prefieres que la rotación la hagamos nosotros, mira rotación de secretos y API keys expuestas.

3. Certificados: GoDaddy y eMudhra

GoDaddy revocó el 21 de octubre 404.607 certificados TLS de sus jerarquías GoDaddy y Starfield porque los OID de política y la URI del CPS de esos certificados no coincidían con su CPS publicado (Mozilla Bug 2082703). Nadie robó claves; el problema es que una web con uno de esos certificados puede dejar de cargar si no instala el de reemplazo.

eMudhra, una CA india, generó en abril de 2025 ocho certificados de CA intermedia TLS con claves débiles por un fallo en su ceremonia de generación, y esas claves se recuperaron a partir de los certificados públicos. Chrome los bloqueó, Apple el 19 de octubre y Microsoft el 20; Go y Node.js publicaron una desconfianza explícita (la release de Node del 21 de octubre ya rechaza esas cadenas). No hay ataques confirmados contra usuarios.

Para saber quién emitió tu certificado y cuándo caduca:

echo | openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -serial

• Si el issuer contiene GoDaddy o Starfield, entra en tu cuenta de GoDaddy, comprueba si ese certificado tiene un reemplazo emitido e instálalo en todos los servidores, balanceadores y CDN donde esté el antiguo.
• Si tu web cuelga de una de las intermedias de eMudhra, Chrome, Safari y Windows ya no la aceptan y tienes que pedir un certificado a otra CA. Para ver la cadena entera, intermedias incluidas, busca eMudhra en las líneas i: (emisor) de esta salida:

echo | openssl s_client -connect tudominio.com:443 -servername tudominio.com -showcerts 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

• El caso que más se escapa es el de salida: un servicio tuyo en Node o Go que llama a una API firmada por esas intermedias empezará a fallar con un error TLS después de actualizar. Si tras el parche de Node aparecen errores de certificado en llamadas salientes, revisa con el mismo comando el dominio al que llamas.

Si no quieres hacerlo tú

En Soamee hacemos este trabajo para los proyectos que mantenemos: inventario de versiones de PHP, Node, NGINX y GitLab; mitigación inmediata donde todavía no se puede actualizar; actualización y verificación; revisión de indicios de compromiso; rotación de secretos en el orden de arriba y cambio de certificados. Nadie puede dejar un servidor invulnerable, así que no lo prometemos. Lo que te dejamos es un registro de qué versión tienes, qué se ha cambiado y qué queda pendiente.

Si tienes servidores o despliegues y no sabes si alguno de estos ocho avisos te afecta, cuéntanoslo en una consultoría gratuita o escríbenos desde contacto.

Fuentes

• PHP: php.net · Rapid7 · Huntress · NCSC
• Node.js: October 2026 Security Releases
• NGINX: nginx security advisories · CSA Research Note sobre CVE-2026-42945 · Help Net Security, 18-may-2026
• GitLab: Critical Patch Release 19.5.1 · The Hacker News sobre CVE-2026-97229
• Railway: The CyberSec Guru
• LiteLLM: Wiz
• PingCAP: Security update, octubre 2026
• GoDaddy: CyberPress
• eMudhra: The Hacker News
• Previsión de CVE en 2026: Help Net Security, 15-jun-2026