El miércoles 21 de octubre de 2026, PHP, Node.js y GitLab publicaron actualizaciones de seguridad críticas, una versión envenenada de LiteLLM 1.107.0 estuvo unas dos horas en PyPI y Docker Hub, y Railway pidió a sus usuarios rotar todos los secretos que guardan en la plataforma. TechCrunch lo llamó ‘un día muy malo para la ciberseguridad’, y no encontré nada que conecte estos incidentes entre sí.
Cinco días después, este es el triaje que yo haría: una tabla ordenada por urgencia, un chequeo de solo lectura para cada punto y lo que cambia la semana para equipos que publican código. PHP2Shell y la rotación de secretos tienen cada uno su análisis a fondo; este post es el mapa.
1. Contexto: Qué Pasó Entre el 20 y el 26 de Octubre
No fue un único ataque. Fue una acumulación de divulgaciones independientes en las mismas 48 horas, sobre una semana que ya traía una autoridad de certificación rota y dos productos de acceso remoto explotados. Las horas van en UTC cuando la fuente las da.
Cronología (php.net, nodejs.org, docs.gitlab.com, LiteLLM, Railway)
Incidentes separados, no una sola campaña
El resumen de TechCrunch dice que los problemas del día no estaban relacionados, y su nota sobre Railway dice que ese ataque parece separado de PHP2Shell. No encontré ninguna fuente que vincule PHP, Node.js o GitLab con Railway o LiteLLM. El hilo que sí une varios incidentes es el botín: Railway dice que su atacante buscaba claves de API de proveedores de IA para destilación, OpenCode atribuyó a un ‘ataque de destilación’ su filtración de claves del 17 de octubre, y el payload de LiteLLM recolecta claves de proveedores de IA. El informe de LiteLLM no vincula su compromiso con esa campaña.
La consecuencia práctica: no hay un único arreglo. Parchear runtimes (PHP, Node.js, GitLab) y rotar credenciales (Railway, LiteLLM, OpenCode) son dos frentes distintos, muchas veces con responsables distintos. Empezá los dos hoy.
2. Tabla de Triaje: Qué Parchear Primero
Ordenada según lo que haría primero: arriba, la ejecución remota de código sin autenticación en servicios expuestos a internet y el robo de secretos confirmado; después, los fallos que necesitan una ruta de código concreta. ‘Hoy’ supone que la fila te aplica; si no, salteala.
| Incidente | Quién está expuesto | Versión corregida / acción | Urgencia |
|---|---|---|---|
| PHP2Shell: CVE-2026-109618, CVE-2026-109619 (CVSS v4.0 9.2) | Toda instalación de PHP que sirve peticiones web: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. PHP considera mod_php el caso de mayor riesgo. | 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. 8.1 o anterior: sin versión oficial; php.net publicó parches de código fuente y distros como Ubuntu sacaron backports, así que mirá la versión del paquete, no php -v. Poné session.upload_progress.enabled=0. | 🔴 Hoy |
| Compromiso de la cadena de suministro de LiteLLM 1.107.0 | Quien instaló litellm 1.107.0 o descargó v1.107.0, latest, main-latest o main-stable el 21 oct (PyPI 11:39–13:23 UTC, Docker Hub hasta las 14:20). | Tratá el host como comprometido: borrá cook.pth, cook.py y sitecustomize.py, reconstruí, fijá 1.106.2 y rotá todo lo que pudo alcanzar. | 🔴 Hoy |
| Brecha de variables de entorno en Railway | Todo cliente de Railway registrado antes del 21 oct; Railway les pide a todos que roten. | Rotá cada variable y credencial de registro privado, recreá RAILWAY_TOKEN / RAILWAY_API_TOKEN (Railway revocó todos sus tokens), revisá logs, redesplegá y reconectá GitHub. | 🔴 Hoy |
| GitLab: CVE-2026-110264 (CVSS 10) | CE y EE self-managed desde la 7.0. Los servidores parcheados el 12 oct siguen afectados. GitLab.com ya está parcheado. | 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13. | 🔴 Hoy si está expuesto a internet |
| BeyondTrust Remote Support: CVE-2026-102764 | Remote Support self-hosted 26.2.3 o anterior, explotado desde finales de agosto. El SaaS se parcheó el 8 oct. | Aplicá el parche BT26-05 y revisá los appliances accesibles desde internet como potencialmente comprometidos. | 🔴 Hoy si lo usás |
| Node.js: 4 altas, 3 medias, 3 bajas | Node 22, 24 y 26 por debajo de las versiones corregidas. Node 20 y anteriores están fuera de soporte y no reciben arreglo. | 22.23.4 / 24.22.1 / 26.12.1, y después reconstruí tus imágenes. | 🟠 48 h (hoy si descomprimís Brotli no confiable) |
| Plex2Shell (Plex Media Server) | Versiones anteriores a 1.43.3.10861; hay explotación reportada desde el 17 oct. | Actualizá a 1.43.3.10861 o posterior. | 🟠 48 h |
| Compromiso de CA intermedias de eMudhra | Clientes con almacén de confianza propio: builds antiguos de Node.js, certifi de Python, /usr/bin/curl de macOS. Los navegadores ya las bloquean. | Actualizá Node.js, certifi y los ca-certificates del sistema. | 🟡 Esta semana |
| Claves de OpenCode Console y TiDB Cloud | Claves de proveedores vinculadas en OpenCode Console (1,4 % de usuarios expuestos); claves de API de TiDB Cloud (se exportaron valores cifrados). | Rotá las claves de proveedores. Rotá también las claves de API de TiDB Cloud, aunque PingCAP todavía no lo pida. | 🟡 Esta semana |
La urgencia es mi criterio, no una puntuación del proveedor. Los paquetes de distribución (Debian, Ubuntu, RHEL, Amazon Linux) suelen aplicar backports sin cambiar el número de versión oficial, así que leé el aviso de tu distro antes de concluir que un servidor no está parcheado.
3. Los Cinco Incidentes Principales en Breve
Una tarjeta por incidente: qué dice la fuente primaria, qué sigue siendo incierto y dónde profundizar.
PHP2Shell: dos RCE sin autenticación en el propio PHP
CVE-2026-109618 · CVE-2026-109619 · CVSS v4.0 9.2 · php.net
El aviso de PHP describe dos fallos distintos que viven por debajo de tu framework. CVE-2026-109618 afecta a la petición que se queda sin memoria: la asignación fallida puede interrumpir PHP con los datos de esa petición a medio inicializar, y su propia limpieza confía después en ese estado inválido. CVE-2026-109619 es estado obsoleto: un error fatal, incluido el agotamiento de memoria o un timeout de ejecución, puede dejar estado global apuntando a memoria liberada, y una petición posterior en el mismo worker lo reutiliza. PHP señala mod_php como el escenario de mayor riesgo, con un exploit demostrado que se dispara antes de que corra cualquier código de la aplicación.
El hallazgo fue de varios equipos y asistido por IA: los advisories de GitHub dan crédito a cuatro reportantes, Wiz dice que usó modelos de IA y la prensa cuenta que los investigadores de Calif usaron un modelo de OpenAI. Wiz agrega que toda versión de PHP de la última década está afectada por al menos uno de los fallos. El 23 de octubre PHP añadió CVE-2026-115560, que las versiones del 21 de octubre no corrigen. Requiere una aplicación que cambie session.serialize_handler en tiempo de ejecución; php.net dice que las apps que nunca lo hacen pueden dejar activo el upload progress, pero yo pondría session.upload_progress.enabled=0 igual, porque también cierra vías de CVE-2026-109619.
Pasos de parcheo, mitigaciones y los ajustes de ini que no sirven: análisis a fondo de PHP2Shell →Node.js: RCE en Brotli, truncado de DNS y dos bypass de hostname TLS
4 altas · 3 medias · 3 bajas · nodejs.org
El fallo principal es CVE-2026-111497: una entrada Brotli malformada puede escribir más allá de un búfer de ocho bytes del decodificador incluido, y un atacante que controla datos que descomprimís con node:zlib puede provocar un cierre, una fuga de memoria o ejecución remota de código. CVE-2026-105482 hace que dns.resolve*() y dns.reverse() corten en silencio un hostname en un byte NUL, así que la comprobación de una allowlist y la consulta real pueden no coincidir. CVE-2026-106069 y CVE-2026-105483 hacen que tls.checkServerIdentity() acepte un certificado para la IP equivocada cuando el host se escribe como 0127.0.0.1 o con dígitos de ancho completo.
Las versiones también actualizan el almacén de CA incluido por el compromiso de eMudhra. La política de Node es tajante: las versiones fuera de soporte siempre están afectadas, así que Node 20 y anteriores siguen vulnerables. El mismo CVE de Brotli llegó a PHP en Windows a través de la descompresión automática de cURL, desactivada por defecto; PHP publicó reconstrucciones -1 de sus paquetes de Windows el 26 de octubre.
GitLab: un segundo fallo de regex con CVSS 10 en nueve días
CVE-2026-110264 · CVE-2026-97229 · docs.gitlab.com
El 12 de octubre GitLab corrigió CVE-2026-97229, una expresión regular manipulada en la configuración de CI/CD que podía permitir a un usuario no autenticado ejecutar código en el servidor. El 21 de octubre llegó CVE-2026-110264, un desbordamiento de enteros al compilar una regex manipulada, que afecta a todas las versiones CE y EE desde la 7.0. El propio rango afectado de GitLab (19.4 antes de 19.4.3) significa que un servidor que pasaste a 19.4.2 el 12 de octubre sigue expuesto.
El aviso no menciona explotación activa, GitLab.com ya está parcheado y la versión incluye migraciones de base de datos, así que las instancias de un solo nodo tendrán caída de servicio. Reservá la ventana hoy en lugar de descubrirlo a mitad de la actualización.
LiteLLM 1.107.0: una versión firmada construida desde un repo imitador
PyPI · Docker Hub · GHCR · LiteLLM, Datadog, Aikido
El análisis de causa raíz que LiteLLM publicó el 23 de octubre, y que corrige su primera actualización, dice que una master key de su Agent Platform quedó commiteada en un repo público el 27 de mayo y nunca se revocó. El 10 de octubre el atacante la usó y la API de la plataforma le devolvió el token OAuth de GitHub CLI de un owner de la organización en GitHub. Con ese token y los de dos maintainers, desactivó la protección de ramas y apuntó el workflow de release a Berri-AI/litellm, un fork a un guion de distancia de BerriAI/litellm; el workflow real construyó, firmó y publicó el resultado. El tag de código fuente oficial v1.107.0 está limpio, y los clientes enterprise con la versión privada no se vieron afectados.
Los wheels dejan cook.pth, cook.py y sitecustomize.py en site-packages, así que el payload corre en cada arranque de Python, aunque nada importe litellm. Aikido y Datadog describen un infostealer (credenciales de nube, SSH, navegador, CI y herramientas de IA, más las claves de proveedores que guarda el proxy) y un troyano que busca código nuevo cada hora. LiteLLM recomienda fijar 1.106.2; la 1.106.4 (25 de octubre) es la versión actual en PyPI.
Qué rotar después de LiteLLM y en qué orden: runbook de rotación de secretos →Railway: variables de entorno cifradas extraídas, algunas descifradas
Divulgación 21 oct · informe preliminar 22 oct · blog.railway.com
Railway dice que un atacante fue a por su infraestructura de build desde el 20 de octubre, extrajo variables de entorno cifradas y descifró un subconjunto con credenciales de CI comprometidas. Su informe preliminar fija la exposición en ‘como máximo el 1,85 % de todos los workspaces’, unos 100.000 workspaces según la propia Railway, y dice que no se accedió a cuentas de usuario. No descarta que se haya accedido a código fuente.
Railway cree que el atacante buscaba claves de API de proveedores de IA para destilación y dice que envió listas de claves a GitHub, GitLab, Anthropic, OpenAI, OpenRouter y Stripe para revocarlas. Lo que pide a cada cliente registrado antes del 21 de octubre: rotar las claves guardadas en Railway, renovar credenciales de registros, quitar el acceso de red público a las bases de datos, revisar los logs de auditoría de GitHub y de los registros, y redesplegar el último commit. Railway además revocó todos sus tokens de acceso y reinició sus instalaciones de la GitHub App, así que hay que recrear los tokens de CLI y CI (RAILWAY_TOKEN, RAILWAY_API_TOKEN).
Rotación paso a paso de variables, bases de datos y claves de proveedores en Railway →También esa semana, en una línea cada uno
- eMudhra: ocho certificados de CA intermedia usaban claves P-384 débiles, recuperables probando 256 valores. Mozilla y Chrome los bloquearon el 17 de octubre; eMudhra dice que no encontró evidencia de abuso (BleepingComputer).
- TiDB Cloud: PingCAP dice que credenciales robadas de una cuenta de servicio dieron a un atacante acceso a sistemas internos del 9 de septiembre al 7 de octubre, incluido código fuente y una tabla exportada con valores cifrados de claves de API. No reporta evidencia de impacto en los datos guardados en TiDB.
- Plex2Shell: cuatro fallos encadenados de Plex Media Server, corregidos en 1.43.3.10861 ya en agosto, explotados contra honeypots desde el 17 de octubre (BleepingComputer).
- BeyondTrust: zero-day de Remote Support CVE-2026-102764, explotado desde finales de agosto y atribuido por Mandiant a un presunto actor vinculado a China (BleepingComputer).
- OpenCode: el 17 de octubre OpenCode dijo, en X y por email, que se expusieron claves de proveedores guardadas del 1,4 % de los usuarios de la Console, todos con proveedores externos vinculados, y lo llamó un ataque de destilación. No encontré un post en el blog de OpenCode; esto se apoya en BleepingComputer.
4. Cinco Implicaciones para Equipos que Publican Código
Más allá de cada parche, estos son los cambios que tendría en cuenta para lo que queda de año.
La caza de bugs asistida por IA acorta la ventana de parcheo
PHP2Shell · Wiz, php.net, AWS
Varios equipos encontraron PHP2Shell con modelos de IA en el proceso, PHP avisó con un día de antelación y los honeypots de Amazon registraron un intento de explotación el 17 de octubre, cuatro días antes de la divulgación. La distancia entre aviso y ataque ahora se mide en horas, y a veces es negativa. Los runtimes expuestos a internet necesitan una vía de parcheo en el mismo día, no un ciclo mensual.
La procedencia firmada prueba el pipeline, no el origen
LiteLLM · página del incidente, Datadog
Los artefactos envenenados salieron del workflow de release real de LiteLLM y estaban firmados; Datadog señala que la procedencia registraba el fork malicioso como origen. La procedencia solo sirve si algo comprueba ese campo. Y la protección de ramas no aguantó porque un token de owner podía desactivarla.
Las claves de proveedores de IA son el botín
Railway · OpenCode · LiteLLM
Railway y OpenCode describen atacantes a la caza de claves de proveedores de IA, y el payload de LiteLLM lee las credenciales de proveedores que guarda el proxy. Cualquier plataforma que tenga tu clave de OpenAI o Anthropic forma parte de tu perímetro de facturación: claves por proyecto con límite de gasto convierten una filtración en un mal día, no en un mal mes.
Los runtimes fuera de soporte viven de parches ajenos
PHP 8.1 y anteriores · Node.js 20 y anteriores
PHP 8.1 y anteriores no reciben una versión oficial para PHP2Shell, solo parches de código fuente de php.net y backports de distros como el php8.1 de Ubuntu 22.04 (USN-8948-1) y, según fuentes secundarias, los paquetes de Surý. Node.js dice que las líneas fuera de soporte siempre están afectadas. El propio PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026. Si una imagen base o un servidor heredado sigue con esas versiones, las opciones son un backport del proveedor, actualizar o sacarlo de internet.
Un parche ya no significa estar parcheado
GitLab · PHP · Node.js
El arreglo de GitLab del 12 de octubre quedó superado nueve días después, PHP añadió un tercer CVE dos días después de su publicación y los paquetes de Windows de PHP se reconstruyeron otra vez el 26 de octubre. Volvé a comprobar versiones tras cada aviso de una serie, en lugar de marcar la casilla una sola vez.
5. Qué Hacer Esta Semana
Hoy es lunes 26 de octubre. Este es el orden en que yo trabajaría. Los comandos de abajo solo leen versiones y archivos: corrélos en cada host, imagen y runner de CI que tengas.
Chequeos de solo lectura para los incidentes principales
Los paquetes de distribución pueden esconder backports detrás de una versión antigua, así que tomá una discrepancia como ‘andá a leer el aviso de tu proveedor’, no como prueba. Los indicadores de LiteLLM salen de su página del incidente y de Datadog.
# PHP: revisá el binario que sirve tráfico web, no solo la CLI php -v php-fpm -v # Debian/Ubuntu: php-fpm8.3 -v (ajustá tu versión) php -i | grep -E '^(memory_limit|session.upload_progress.enabled) ' # php -i muestra la config de la CLI; los pools de FPM y Apache pueden sobrescribirla # corregidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35 dpkg -l | grep -E 'php[0-9.]+-(fpm|cgi|cli)|libapache2-mod-php' # Debian/Ubuntu: compará la versión del paquete con el aviso de tu distro # Node.js, en hosts y en cada imagen que construís node -p process.version grep -rn --include='Dockerfile*' 'FROM node:' . # corregidas: v22.23.4, v24.22.1, v26.12.1 # GitLab self-managed (paquete Linux): mirá 'GitLab information > Version' sudo gitlab-rake gitlab:env:info # corregidas: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 # LiteLLM: buscá los archivos ANTES de que arranque cualquier proceso Python find / \( -name 'cook.pth' -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null ls -la /tmp/.pc_once_* /tmp/remote_code_loader.lock 2>/dev/null docker images --digests | grep -i litellm # digest de índice comprometido: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e grep -rn --include='*.lock' --include='requirements*.txt' 'litellm' .
No dejes que Python arranque primero
La página del incidente de LiteLLM advierte que cualquier arranque de Python vuelve a ejecutar cook.pth y sitecustomize.py, pip incluido. Buscá con find, reconstruí el venv o la imagen desde cero con litellm==1.106.2 y solo entonces usá pip. Que no exista el marcador en /tmp no prueba nada, porque los contenedores y la limpieza de tmp lo borran. Algunas distribuciones Linux incluyen un sitecustomize.py legítimo; por eso busco cook.pth y el dist-info de la 1.107.0.
🔥 Hoy (lunes 26 de octubre)
- 1. Parcheá PHP en cada host expuesto a internet a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reiniciá todos los workers. Poné session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la config del servidor, no con ini_set() ni .user.ini.
- 2. Corré el chequeo de LiteLLM en laptops, runners de CI e imágenes. Si aparece algo: aislá el host, reconstruilo, fijá 1.106.2 y rotá desde una máquina limpia.
- 3. Si te registraste en Railway antes del 21 de octubre, rotá cada variable y credencial de registro guardada allí, recreá tus RAILWAY_TOKEN y RAILWAY_API_TOKEN, y después redesplegá el último commit y reconectá GitHub.
- 4. Actualizá GitLab si está expuesto a internet y cualquier appliance self-hosted de BeyondTrust Remote Support.
📅 Antes del miércoles
- Node.js: pasá a 22.23.4, 24.22.1 o 26.12.1, reconstruí cada imagen que fije un tag de node anterior y empezá el plan para salir de Node 20 y anteriores.
- Claves de proveedores de IA: rotá las claves vinculadas en OpenCode Console y revisá los paneles de uso de OpenAI, Anthropic y OpenRouter en busca de gasto que no reconozcas. Railway publicó una guía corta por proveedor.
- Equipos secundarios: actualizá Plex Media Server a 1.43.3.10861 o posterior. Es justo el tipo de máquina de home lab que termina en una VPN junto a laptops del trabajo.
- Almacenes de confianza: actualizá certifi, los ca-certificates del sistema y todo lo que traiga su propio bundle de CA, para que las intermedias de eMudhra dejen de ser de confianza.
📆 Antes del viernes: que el próximo salga más barato
- Inventario de runtimes: una lista con SAPI y versión de PHP, versión mayor de Node y versión de GitLab por servicio, para que el próximo aviso te lleve minutos y no un día de sesiones SSH.
- Dependencias fijadas y con demora: versiones exactas con hashes más una demora mínima desde la publicación. litellm 1.107.0 estuvo en PyPI menos de dos horas.
- Secretos de vida corta y con alcance limitado: claves de proveedores por proyecto con límite de gasto, OIDC hacia tu nube en lugar de claves estáticas en variables de entorno, y ningún token de owner permanente que pueda desactivar en silencio la protección de ramas.
- Calendario de fin de soporte: PHP 8.2 termina el 31 de diciembre de 2026. Agendá esa actualización ya, mientras todavía te acordás de esta semana.
6. Qué Está Confirmado y Qué No (Revisado el 26 de Octubre de 2026)
‘Confirmado’ significa una fuente primaria (aviso del proveedor o página del proyecto) o dos informes independientes. Todo lo demás va marcado como tal.
Versiones corregidas y versiones seguras
Las versiones de PHP, Node.js, GitLab y LiteLLM salen directamente de php.net, nodejs.org, docs.gitlab.com y la página del incidente de LiteLLM.
Alcance en Railway
Del propio informe preliminar de Railway: como máximo el 1,85 % de los workspaces potencialmente expuestos, un subconjunto de variables descifradas y la petición de rotar a todos los clientes registrados antes del 21 de octubre. El informe forense final sigue pendiente.
Explotación de PHP2Shell
Los intentos están confirmados: los honeypots MadPot de Amazon registraron uno el 17 de octubre, cuatro días antes de la divulgación, y más tras la aparición de pruebas de concepto el 21 de octubre; Cloudflare (citada por BleepingComputer) también vio ataques tempranos. El éxito no: Amazon dice que no está claro si algún intento habría funcionado, Sophos se retractó de un primer reporte de compromiso exitoso y el Centro Canadiense de Ciberseguridad dijo el 23 de octubre que no había identificado explotación activa.
Aviso de la NSA
TechCrunch informa que la NSA pidió a las organizaciones actualizar de inmediato o desconectar los sistemas hasta poder hacerlo. nsa.gov bloqueó mi consulta, así que esto se apoya en ese informe y en otra cobertura de prensa.
Ventanas de tiempo de LiteLLM
LiteLLM da PyPI de 11:39 a 13:23 UTC y Docker Hub hasta las 14:20; Datadog sitúa la cuarentena de PyPI a las 13:20 y la retirada de imágenes a las 13:53. Uso los datos de LiteLLM porque son los más amplios.
Acceso inicial en Railway (el de LiteLLM ya está explicado)
Railway no revela su vector de entrada y su informe forense final no había salido al 26 de octubre. El primer post de LiteLLM atribuía el robo a tokens sacados de los logs de un despliegue interno; su análisis de causa raíz del 23 de octubre lo reemplaza por la master key del Agent Platform filtrada y nunca revocada.
Lo que no pude confirmar
No probé ningún exploit. nsa.gov y la página del aviso de BeyondTrust rechazaron mi consulta, así que los detalles de BeyondTrust salen de BleepingComputer, igual que los de Plex2Shell, eMudhra y OpenCode. No encontré puntuación CVSS para CVE-2026-115560, y lo que cuenta la prensa sobre cómo Calif encontró los fallos es de segunda mano.
Regla de oro
Llevá dos colas en paralelo: parchear los runtimes en los hosts expuestos a internet y rotar secretos en cada plataforma que tocó tus claves. Ninguna sustituye a la otra.
Conclusión
El 21 de octubre no fue un ataque; fue una prueba de estrés de tu inventario. Los equipos que podían responder en una hora ‘qué SAPI de PHP, qué versión mayor de Node, qué GitLab, qué hosts instalaron litellm el miércoles, qué claves viven en Railway’ ya terminaron. El resto está armando esa lista esta semana.
Resolvé las filas rojas hoy, las naranjas antes del miércoles, y usá el viernes para que el próximo aviso salga más barato. El próximo ‘día muy malo’ no va a esperar a tu ciclo de parches, y con la caza de bugs asistida por IA probablemente llegue antes.
Esta semana en una pantalla
Parchear
- • PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
- • GitLab 19.5.1 o tu backport
- • Node 22.23.4 / 24.22.1 / 26.12.1
Rotar
- • Todo lo guardado en Railway
- • Hosts que corrieron litellm 1.107.0
- • Claves vinculadas en OpenCode
Endurecer
- • Inventario de runtimes por servicio
- • Deps fijadas + demora de release
- • Claves acotadas con límite de gasto
Fuentes
- PHP — Archivo de noticias 2026 (aviso del 21 oct, CVE-2026-115560 del 23 oct, reconstrucciones de Windows del 26 oct)
- PHP — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- PHP — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- AWS Security Blog — Amazon detecta explotación de PHP2Shell en MadPot antes de la divulgación
- Ubuntu — USN-8948-1: vulnerabilidades de PHP (incluye php8.1 en 22.04)
- Node.js — Actualizaciones de seguridad de octubre de 2026
- GitLab — Critical Patch Release 19.5.1, 19.4.3, 19.3.6 y backports (21 oct)
- GitLab — Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (12 oct)
- LiteLLM — Incidente de seguridad, 21 de octubre de 2026
- LiteLLM — Cadena de ataque y análisis de causa raíz (23 oct)
- Datadog Security Labs — LiteLLM comprometido en PyPI y Docker
- Aikido — LiteLLM comprometido: infostealer y RAT
- Railway — Security Disclosure: Wednesday October 21st
- Railway — Informe preliminar del incidente del 21 de octubre
- TechCrunch — The internet is having a very bad cybersecurity day
- TechCrunch — Railway pide a todos sus usuarios revocar claves tras un ciberataque
- Wiz — PHP2Shell: la IA descubre vulnerabilidades críticas de RCE
- BleepingComputer — PHP publica parches de emergencia para PHP2Shell
- Centro Canadiense de Ciberseguridad — AL26-026, vulnerabilidades críticas en PHP
- BleepingComputer — Mozilla, Google y Apple bloquean los certificados comprometidos de eMudhra
- PingCAP — Actualización de seguridad, octubre de 2026
