Brechas de Railway y LiteLLM: Runbook Práctico para Rotar Secretos

Cronología, octubre de 2026 (UTC; informes de los proveedores)

Railway: listá cada secreto que guardás ahí

Railway CLI 5.x (5.71.0 mientras escribo; railway variables sigue funcionando como alias de railway variable). Imprimí nombres, nunca valores, por servicio y entorno. La CLI no devuelve las variables selladas, así que revisalas en el dashboard. Exportá antes los logs de auditoría de GitHub y de tus registros: la guía de GitHub de Railway dice que lo hagas antes de revocar nada.

# Solo nombres, por servicio y entorno: los valores nunca llegan a tu terminal
railway login
railway link        # elegí proyecto, entorno y servicio
railway variable list --service api --environment production --kv | cut -d= -f1

# La CLI no devuelve las variables selladas: listalas desde el dashboard
# Antes de revocar nada, exportá:
#   Org de GitHub: Settings > Logs > Audit log (JSON o CSV)
#   Registros (Docker Hub, GHCR): historial de tokens de acceso y pushes

LiteLLM: encontrá la 1.107.0 sin arrancar Python

Correlo en laptops, servidores, runners de CI propios e imágenes. Los bloques 1–3 solo leen archivos; el bloque 4 arranca Python, así que dejalo para hosts que ya salieron limpios. Los nombres de archivo, rutas, el marcador de entorno y los hashes de los wheels salen del issue de GitHub, el post del incidente de LiteLLM, Aikido y Datadog.

# 1. Lockfiles y requirements
grep -rn 'litellm==1.107.0' --include='*.txt' --include='*.in' --include='*.toml' .
grep -rn -A2 'name = "litellm"' --include='uv.lock' --include='poetry.lock' . | grep '1\.107\.0'
# Prefijos SHA-256 de los siete wheels maliciosos
grep -rnE '7598727f209d|0aaf7ba346d4|462d0c9f67ca|668169d35b87|1bbce8caa94f|c2e32d0ce254|12d4ccc5c6f8' .

# 2. Entornos instalados, solo sistema de archivos
find / -type d -name 'litellm-1.107.0.dist-info' 2>/dev/null
find / -path '*-packages*' \( -name cook.pth -o -name cook.py -o -name sitecustomize.py \) 2>/dev/null
ls -la /tmp/.pc_once_* /tmp/remote_code_loader.lock 2>/dev/null
sudo grep -l PRIVCOLLECT_ACTIVE /proc/*/environ 2>/dev/null   # Linux: payload corriendo ahora
# PowerShell: Get-ChildItem C:\ -Recurse -Filter cook.pth -ErrorAction SilentlyContinue

# 3. Imágenes: el digest del índice malicioso, y mirar dentro sin ejecutar
docker images --digests | grep -iE 'litellm|1bbcb1443bc9'
cid=$(docker create <IMAGE_ID>)   # ID local de la imagen, no el tag: los tags se reapuntaron
docker export "$cid" | tar -tf - | grep -E 'cook\.pth|litellm-1\.107\.0\.dist-info'
docker rm "$cid"
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[*].imageID}{"\n"}{end}' | grep -i litellm

# 4. Solo en hosts que pasaron 1-3 (estos arrancan Python)
pip show litellm | head -n 2
uv pip list | grep -i litellm

Railway: solapamiento de dos claves desde la CLI

Es el patrón sin downtime que documenta Railway. Dale al servicio un healthcheck que use de verdad la credencial, así un valor malo hace fallar el deploy nuevo mientras el viejo sigue sirviendo. Pasar la clave por stdin la mantiene fuera del historial de tu shell.

# 1. Creá la clave nueva en el proveedor. La vieja sigue funcionando.
# 2. Dejala lista sin reiniciar (railway link eligió el entorno)
read -rs NEW_KEY
printf '%s' "$NEW_KEY" | railway variable set OPENAI_API_KEY --stdin \
  --service api --skip-deploys
# 3. Repetí con cada variable que cambie y desplegalas juntas
railway redeploy --service api
# 4. Comprobá que el deploy nuevo está sano y las llamadas funcionan
railway logs --service api --since 10m
# 5. Recién ahora revocá la clave vieja en el proveedor

# ¿Varios servicios? Guardá la clave una vez como variable compartida y referenciala:
#   OPENAI_API_KEY=${{ shared.OPENAI_API_KEY }}

Nube, GitHub y SSH desde la línea de comandos

Mismo orden que la lista de arriba. Los marcadores en mayúsculas los completás vos.

# AWS: clave nueva, desactivá la vieja y borrala tras un día tranquilo
aws iam create-access-key --user-name APP_USER
aws iam update-access-key --user-name APP_USER --access-key-id OLD_KEY_ID --status Inactive
aws iam delete-access-key --user-name APP_USER --access-key-id OLD_KEY_ID
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=OLD_KEY_ID \
  --start-time 2026-10-14T00:00:00Z   # por región: repetí con --region

# Claves de service accounts de GCP
gcloud iam service-accounts keys create new-key.json --iam-account=SA_EMAIL
gcloud iam service-accounts keys delete OLD_KEY_ID --iam-account=SA_EMAIL

# CLI de GitHub: logout es solo local
gh auth status                       # cuentas, hosts y scopes del token aquí
gh auth logout --hostname github.com --user YOUR_USER
#   después github.com/settings/applications > GitHub CLI > Revoke
gh auth login                        # token nuevo, desde una máquina limpia

# SSH: clave nueva, registrala y eliminá la vieja en todas partes
ssh-keygen -t ed25519 -C "laptop-2026-10" -f ~/.ssh/id_ed25519_2026_10
gh ssh-key add ~/.ssh/id_ed25519_2026_10.pub --title "laptop 2026-10"
gh ssh-key list
gh ssh-key delete OLD_SSH_KEY_ID

Fijá con hashes, y entendé lo que no hacen

Los hashes garantizan que el archivo que instalás es el que fijaste en el lockfile. No impiden que fijés un release nuevo malicioso: si hubieras regenerado el lock durante esas dos horas, el hash habría sido el del ladrón. Para eso está el cooldown.

# requirements.in: litellm[proxy]==1.106.4
uv pip compile requirements.in --generate-hashes -o requirements.txt
pip install --require-hashes -r requirements.txt

# Proyectos uv: uv.lock ya guarda hashes; que CI falle si se desvía
uv sync --locked

Cooldowns de dependencias: un ataque de dos horas contra una espera de siete días

litellm 1.107.0 estuvo en PyPI menos de dos horas; los releases de marzo estuvieron publicados entre 40 minutos y tres horas, según la fuente. Una antigüedad mínima de un día habría saltado ambos. Revisá antes la versión de tu herramienta: uv 0.9.17+ para duraciones relativas, pip 26.1+ para duraciones en días (26.0 acepta timestamps), pnpm 10.16+ y npm con min-release-age (11.10+, según la cobertura del release). Dejá una vía de escape para parches de seguridad urgentes.

# uv >= 0.9.17: pyproject.toml
[tool.uv]
exclude-newer = "7 days"

# pip >= 26.1: ISO 8601, solo días
pip install --uploaded-prior-to P7D -r requirements.txt

# pnpm >= 10.16 (pnpm 11 usa 1440 por defecto): pnpm-workspace.yaml, minutos
minimumReleaseAge: 10080

# npm: .npmrc, días
min-release-age=7

# Renovate: renovate.json
{ "minimumReleaseAge": "7 days" }

# Dependabot: .github/dependabot.yml, dentro de cada entrada de updates
    cooldown:
      default-days: 7

Docker: digest, no tag

Cuatro tags, latest y main-stable incluidos, apuntaron a la imagen maliciosa durante hasta dos horas y media. Un digest no se puede reapuntar. Verificá las firmas con la clave nueva de LiteLLM (commit e82a3c6, en uso desde el 24 de octubre); la clave vieja 0112e53 falla con los releases nuevos. Una advertencia de Datadog: los artefactos maliciosos traían procedencia de build que nombraba como origen el fork de nombre parecido, así que si revisás la procedencia, mirá qué repositorio indica.

# Resolvé el tag una vez, verificalo y fijá el digest
docker buildx imagetools inspect ghcr.io/berriai/litellm:v1.106.4   # imprime Digest: sha256:...
cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
  ghcr.io/berriai/litellm:v1.106.4

# Dockerfile o compose: el tag para humanos, el digest para la máquina
FROM ghcr.io/berriai/litellm:v1.106.4@sha256:<DIGEST_QUE_VERIFICASTE>