Seguridad de la caché: envenenamiento, CREEP y aislamiento por rama

Una caché compartida es, antes que una optimización, una frontera de confianza. En cuanto varias máquinas y varios contribuidores escriben y leen del mismo almacén, la propiedad que la hacía maravillosa —que cualquiera que produzca el mismo contenido calcula la misma clave y puede pedir por ella— se convierte en su talón de Aquiles: si cualquiera que calcule esa clave puede también escribir bajo ella, entonces cualquiera puede dictar lo que recibirán todos los demás. Este nivel mira la caché desde la óptica del atacante, estudia el envenenamiento como clase de vulnerabilidad, y analiza el caso que en 2025 puso el tema en el mapa: CREEP.

El envenenamiento de caché

El envenenamiento explota una suposición que casi ningún sistema de build hace explícita: que un hit es de fiar. Cuando la caché encuentra una entrada bajo la clave que calculaste, te entrega su contenido sin volver a verificarlo —ese es justo el ahorro que buscas—. Pero esa confianza tiene una cara oscura: si un atacante consigue colocar un artefacto malicioso bajo una clave legítima, todo consumidor que calcule esa clave recibirá el veneno con la misma naturalidad con la que habría recibido el resultado correcto, y sin sospechar nada, porque el hash cuadra.

Nótese dónde está la vulnerabilidad: no en la lectura, sino en la escritura. El direccionamiento por contenido garantiza que la clave describe fielmente las entradas, pero no dice nada sobre quién tuvo derecho a poblar esa clave. Un hash es una huella del contenido; no es una firma de su autor ni una prueba de su procedencia. Si el almacén no distingue entre un artefacto producido en un contexto de confianza y otro producido por un contribuidor cualquiera, la clave se convierte en un buzón abierto: el primero que escriba en él decide lo que leerá todo el mundo.

Y el problema se agrava justo por la virtud que hace útil la caché: la ausencia de reverificación. Un hit es rápido precisamente porque no vuelve a comprobar nada —confía en que lo guardado bajo esa clave es correcto y lo entrega—. Esa confianza es el motor del rendimiento y, a la vez, la puerta del ataque: cuanto más ciega es la lectura a la procedencia del dato, más barato es el hit y más devastador el envenenamiento. No se puede pedir a la lectura que sea a la vez instantánea y desconfiada; por eso la defensa tiene que vivir en otro sitio.

CVE-2025-36852: CREEP

En junio de 2025, una investigación divulgada por Nx describió y bautizó esta clase de fallo en cachés de build remotas: CREEP, siglas de Cache Race-condition Exploit Enables Poisoning, registrada como CVE-2025-36852 con una severidad crítica de 9.4. Su hallazgo incómodo: en muchas configuraciones, cualquier desarrollador con permiso para abrir un pull request podía inyectar código en los artefactos de producción.

El mecanismo encadena tres hechos que, por separado, parecen inofensivos. Primero, la caché remota se comparte entre contextos de confianza distinta: los pull requests —a menudo desde forks de colaboradores externos— y las ramas protegidas como main escriben y leen del mismo almacén. Segundo, la clave es un hash del contenido y no codifica la rama ni el nivel de confianza: un PR que parte del mismo estado de fuentes que main calcula exactamente la misma clave. Tercero, rige el principio de “el primero en cachear gana”: quien suba primero un artefacto para un estado dado de las fuentes fija la versión que se servirá en todas partes donde ese estado reaparezca, producción incluida.

flowchart TD
PR[PR de un fork no confiable] --> Hh[Calcula el hash que main usara]
Hh --> Up[Sube primero un artefacto envenenado]
Up --> Store[Cache remota compartida sin aislamiento]
Main[Rama protegida main] --> Same[Calcula el mismo hash]
Same --> Store
Store --> Hit[Cache hit: descarga el artefacto del atacante]
Hit --> Deploy[Despliega codigo envenenado]
style Deploy fill:#f38ba8,color:#11111b
style Store fill:#f9e2af,color:#11111b

El ataque, entonces, no necesita romper nada: usa el sistema tal como está diseñado. Un contribuidor malicioso abre un PR, precalcula el hash que la rama protegida usará para su build, produce un artefacto envenenado —un dist con una puerta trasera— y lo sube a la caché compartida bajo esa clave, ganando la carrera. Cuando main construye ese mismo estado de fuentes, calcula la clave idéntica, obtiene un hit y descarga el artefacto del atacante en lugar de generar el suyo. Lo que se despliega a producción es código que nadie revisó ni aprobó.

La divulgación subrayó dos cosas incómodas. La primera es el alcance: la configuración vulnerable —caché remota compartida entre PRs y ramas protegidas, sin partición por nivel de confianza— era el montaje por defecto o el más cómodo en incontables organizaciones, de modo que el fallo no era una rareza de laboratorio sino el estado natural de miles de pipelines. La segunda es que la carrera no exige un atacante sofisticado: como rige el “primero en cachear gana”, incluso un fork bienintencionado cuyo CI corriera antes que la rama protegida podía, sin malicia alguna, fijar el artefacto que producción reutilizaría. La severidad 9.4 no es alarmismo: refleja que el ataque es de bajo esfuerzo, no requiere privilegios especiales y desemboca en ejecución de código en producción.

El aislamiento por rama

La defensa no puede estar en la lectura —un hit tiene que ser rápido y no revalidar—, así que tiene que estar en la escritura y en la topología del almacén. La respuesta estructural es el aislamiento por rama (branch-scoped): particionar el espacio de claves según el nivel de confianza, de modo que un artefacto producido en un contexto no confiable jamás pueda ser leído por uno confiable bajo la misma clave.

En concreto, el aislamiento branch-scoped que Nx Cloud implementa como respuesta a CREEP separa los ámbitos: las corridas de PRs no confiables pueden leer de la caché compartida para acelerar —eso no entraña riesgo— pero sus escrituras quedan confinadas a un ámbito aislado, atado a esa rama o a ese contexto no confiable, del que las ramas protegidas nunca leen. Dicho de otro modo: un fork puede beneficiarse de lo que produjo la confianza, pero no puede inyectar nada en lo que la confianza consumirá. Se rompe la premisa segunda del ataque —que la clave no distinga contextos— añadiendo el contexto de confianza a la partición del almacén, aunque no al hash de contenido.

Qué comprobar en tu proveedor de caché

El aislamiento por rama no es una casilla que se marca y se olvida; conviene verificar que tu proveedor lo aplica de verdad y en la dirección correcta. Cuatro preguntas concretas separan una configuración segura de una expuesta:

• ¿Las corridas de PRs desde forks escriben en un ámbito distinto del que leen las ramas protegidas, o comparten espacio de claves?
• ¿Puede una rama protegida acabar leyendo un artefacto que produjo un contexto no confiable, aunque sea por una ruta indirecta?
• ¿La partición por confianza es el comportamiento por defecto, o hay que activarla explícitamente en la configuración?
• ¿Los tokens de escritura a la caché tienen alcance por contexto, de modo que un token de PR no pueda escribir donde escribe la rama protegida?

Si alguna respuesta te deja dudando, asume lo peor y trata tu caché remota como envenenable hasta demostrar lo contrario. La comodidad por defecto de “todos comparten todo” es exactamente la trampa que CREEP explotó a escala.

La lección de diseño trasciende a la herramienta concreta. Toda caché compartida entre partes de confianza distinta necesita responder, explícitamente, a la pregunta de quién puede escribir qué y quién puede leer de dónde. Si esa respuesta se deja implícita —“todos comparten todo porque el hash ya garantiza que el contenido cuadra”—, el direccionamiento por contenido, que resolvía el problema de la reutilización, deja abierto de par en par el problema de la procedencia.

Más allá de CREEP: la superficie de ataque

CREEP es el ejemplar más nítido de una familia más amplia. En cuanto una caché se comparte, hereda todas las vías por las que un contenido no confiable puede acabar en un lugar confiable, y el aislamiento por rama cierra la puerta principal pero no todas las ventanas. Conviene tener el mapa completo, porque cada vector se defiende de una manera distinta.

• Secretos en logs o artefactos cacheados. Si una tarea imprime un token o lo escribe en un archivo declarado como output, ese secreto queda congelado bajo una clave y se reproduce en cada hit, potencialmente en un almacén compartido. La caché convierte una fuga puntual en una fuga persistente y distribuida.
• Plugin o herramienta de build comprometido. Un plugin malicioso puede escribir archivos arbitrarios en el artefacto que luego se cachea y se distribuye al equipo entero con la bendición implícita del hash.
• Dependencia interna envenenada río arriba. Si el build de una librería interna produce salida maliciosa, su artefacto cacheado se reutiliza aguas abajo sin que nadie vuelva a mirarlo, propagándose por el grafo.
• La caché como canal de exfiltración. Un almacén compartido con permisos laxos de lectura y escritura puede servir para sacar datos entre contextos que jamás debieron comunicarse.