En abril de 2026, investigadores de Manifold Security demostraron que Claude 4.7 aprueba código malicioso si el commit está firmado con el nombre de alguien de confianza. La falsificación de identidad Git con Claude requiere exactamente dos comandos: git config user.name y git config user.email. Sin credenciales robadas, sin exploits complejos.
En 30 segundos
- Manifold Security falsificó la identidad de un investigador reconocido en Git y Claude 4.7 aprobó automáticamente código malicioso sin validación adicional.
- El ataque usa dos comandos básicos de Git config — sin credenciales, sin exploits, sin herramientas especiales.
- Commits sin firmar criptográficamente son declaraciones de buena fe, no verificaciones. Claude confió en metadatos sin contraste criptográfico.
- GitHub permite requerir commits firmados con GPG/SSH en ramas protegidas. La mayoría de los equipos no lo tiene configurado.
- Anthropic usa internamente validación de hash para proteger su propio Claude Code, pero esa protección no llega a los clientes por defecto.
Claude 4 es una familia de modelos de lenguaje grande desarrollada por Anthropic para generación de texto, programación, análisis y razonamiento. Incluye versiones como Claude 4.6 y Claude 4.7, lanzadas a partir de 2024.
Claude falsificación identidad Git es el nombre que está circulando en los foros de seguridad para describir este vector de ataque. La definición técnica es precisa: Git permite a cualquier usuario declarar cualquier nombre y email en sus commits locales sin verificación del sistema. Cuando una herramienta de IA usa esos metadatos como señal de confianza para decidir si aprobar o rechazar código, la cadena de revisión queda completamente expuesta.
El ataque de Manifold Security: cómo engañaron a Claude
Ponele que tu equipo configuró Claude para revisar PRs automáticamente. Y que, razonablemente, le dijiste que los commits de ciertos investigadores senior pasan sin fricción extra. Manifold Security tomó exactamente esa configuración y la convirtió en un problema.
El experimento, documentado por The Register en abril de 2026, usó dos comandos:
git config user.name "Nombre De Investigador Conocido"git config user.email "[email protected]"
Con eso, cualquier commit que hicieran aparecía firmado por esa persona. Sin tokens robados. Sin acceso a cuentas. La cita literal de Manifold es brutalmente clara: “No credentials, no exploitation, no complex tools.”
El resultado: Claude 4.7 aprobó el código malicioso incluido en el commit. Activó los comandos de fusión configurados para ese flujo. El código entró al repositorio.
¿Y qué tenía de especial el código en cuestión? Era deliberadamente dañino. El punto no era si Claude podía detectar código malicioso en abstracto, sino si la identidad del autor podía anular esa capacidad de detección. Sí podía.Por qué Claude confió en metadatos falsos
Acá viene la parte que más me molesta del asunto. No es un bug en el sentido clásico. Es un problema de diseño. Sobre eso hablamos en los límites de Sonnet 4.6.
Cuando configurás un workflow de revisión con Claude, podés incluir instrucciones del tipo “si el autor es X, aplicá reglas de aprobación relajadas” o “los commits de los arquitectos senior van directo a main con aprobación automática”. Esas reglas tienen sentido en un sistema donde la identidad está verificada. En Git sin firmas criptográficas, la identidad es lo que el autor dice ser.
Claude ejecuta comandos de aprobación y fusión basándose en lo que lee en los metadatos del commit. No tiene acceso a ningún mecanismo externo de verificación de identidad. Los guardrails están en el modelo, entrenados para detectar código peligroso, pero esos guardrails pueden ser cortocircuitados por instrucciones del sistema que le dicen “confía en este autor”.
El problema es que los guardrails en el modelo son una capa. Las reglas de confianza que el operador configura son otra capa. Y cuando las dos entran en conflicto, las reglas del operador ganan. Eso no es un fallo de Claude: es exactamente cómo está diseñado. El fallo es que el sistema asume que el operador tiene identidades verificadas, y rara vez es así.
La diferencia entre commits sin firmar y firmados
Un commit de Git sin firma es una declaración. Decís quién sos y nadie lo verifica. Es como firmar una carta a mano: podés poner cualquier nombre.
Un commit firmado con GPG o SSH es distinto. Tiene verificación criptográfica: solo alguien con la clave privada correspondiente puede producir esa firma. GitHub marca estos commits con un badge verde “Verified”. Si alguien falsifica el nombre pero no tiene la clave, la firma no matchea y el sistema lo detecta.
| Tipo de commit | Verifica identidad | Configurable en GitHub | Adoptado por la industria |
|---|---|---|---|
| Sin firma (default) | No | N/A | Mayoría de repos |
| Firmado con GPG | Sí (clave privada) | Sí, branch protection rules | Minoría, principalmente FOSS crítico |
| Firmado con SSH | Sí (clave privada) | Sí, desde 2022 | Creciendo lentamente |
| Gitmoji / convención | No | No aplica | No es seguridad |
GitHub permite requerir commits firmados en ramas protegidas desde hace años. La configuración está en Settings > Branches > Branch protection rules > “Require signed commits”. Tarda cinco minutos en activar. La mayoría de los equipos no lo hizo. Ya lo cubrimos antes en cómo se comportan otros modelos.
Cómo este ataque afecta los flujos de revisión con IA
El problema escala cuando pensás en cuántos repositorios open source usan workflows automatizados con IA para revisar PRs. Proyectos con miles de contribuyentes externos, donde la revisión humana de cada cambio es imposible y la IA toma decisiones de primera línea.
En ese contexto, falsificar la identidad de un maintainer conocido no requiere comprometer su cuenta. Alcanza con saber su nombre y email, datos que están en el historial público de cualquier repo.
Esto no es independiente de otros problemas de seguridad en Claude Code. El CVE-2025-55284 documentó una vulnerabilidad de inyección DNS en Claude Code que permitía redirigir solicitudes a servidores arbitrarios. Son vectores distintos, pero apuntan al mismo patrón: herramientas de IA con acceso a sistemas críticos y superficies de ataque que los equipos de seguridad todavía están mapeando.
Los flujos de revisión automatizados dependen de una premisa que este ataque invalida: que los metadatos de Git reflejan identidades reales. Si esa premisa cae, toda la lógica de “confiar en este autor” se vuelve un vector de entrada.
Las contradicciones de Anthropic: lo que usan adentro vs lo que dan afuera
Acá viene la parte más interesante, y la que más incomoda.
El source leak de Claude Code de marzo de 2026 expuso parte del código interno de Anthropic. Entre los detalles que circularon estaba la declaración de Boris Cherny, uno de los desarrolladores principales: “100% de mis contribuciones recientes fueron hechas por Claude Code”. Anthropic usa su propia herramienta para desarrollar Claude Code (sí, es recursivo).
Lo que también salió a la luz es que el sistema interno incluye validación de hash con el parámetro cch=00000 para prevenir ciertos tipos de spoofing en los flujos internos. Tienen capas de protección que sus propios equipos de ingeniería usan.
Esa protección no está disponible para los clientes por defecto. No está documentada de forma prominente en la documentación de seguridad de Claude Code. Los equipos que usan Claude Code para revisión de PRs tienen que armar sus propias salvaguardas.
No digo que sea mala fe. Puede ser simplemente que los sistemas internos evolucionaron con capas de seguridad que todavía no están productizadas para el público. Pero la ironía queda: Anthropic se protege con verificaciones adicionales mientras sus clientes usan una versión con menos controles.
Protecciones concretas que podés implementar hoy
Basta de panorama. ¿Qué hacés si usás Claude Code o cualquier workflow de IA para revisión de código? Relacionado: validación de datos críticos.
Requerir commits firmados en ramas críticas
Configurar firma GPG global:
git config --global commit.gpgsign truegit config --global user.signingkey TU_KEY_ID
Si usás GitHub, activá “Require signed commits” en las branch protection rules de main y cualquier rama de release. Los PRs de autores sin firma verificada no van a poder mergear.
Auditar las instrucciones de confianza en tus workflows IA
Revisá qué le dijiste a Claude sobre a quién confiar. Si tenés reglas del tipo “los commits de [persona] van directo a aprobación”, esas reglas asumen identidad verificada. Sin commits firmados, son agujeros.
Cambiá la lógica: en vez de confiar por nombre, confiá por verificación criptográfica. Si el commit tiene firma verificada de la clave GPG del autor, procede. Si no, revisión manual sin importar el nombre.
No delegues la decisión de merge a la IA sin segunda capa
Claude puede revisar, sugerir, marcar problemas. La decisión de fusionar, especialmente en ramas protegidas, debería requerir una acción humana o una verificación técnica adicional (firma válida, check de CI, aprobación de reviewer humano). El flujo “Claude aprueba y mergea solo” es cómodo pero deja la puerta abierta.
Qué está confirmado y qué no
| Afirmación | Estado |
|---|---|
| Manifold Security demostró el ataque con Claude 4.7 | Confirmado — The Register, abril 2026 |
| El ataque requiere solo dos comandos git config | Confirmado por Manifold (“no credentials, no exploitation”) |
| Anthropic usa validación de hash interna no disponible para clientes | Confirmado por source leak de marzo 2026 |
| Claude Code tiene parche oficial para este vector | No confirmado — no hay anuncio oficial de fix a la fecha |
| Otros modelos (GPT-4o, Gemini) son vulnerables al mismo vector | No confirmado — no hay prueba equivalente publicada |
| CVE-2025-55284 (inyección DNS en Claude Code) está parchado | Pendiente — seguir el advisory oficial |
Errores comunes al configurar revisión de código con IA
Error 1: asumir que Claude “sabe” quién está commiteando. Claude lee lo que dice el commit. Si el commit dice que el autor es alguien de confianza, Claude lo toma por válido. No tiene acceso a GitHub’s authentication layer, no verifica sesiones, no compara con llaves SSH del usuario. El modelo no tiene esa capacidad estructuralmente.
Error 2: activar workflows de auto-merge para “ahorrar tiempo” sin revisar qué condiciones los activan. Muchos equipos configuran auto-merge si Claude aprueba, sin especificar que esa aprobación requiere identidad verificada. La corrección: agregar la condición de firma criptográfica válida al checklist de merge, no solo la aprobación del modelo. Tema relacionado: problemas similares en ChatGPT.
Error 3: tratar los commits firmados como opción avanzada para proyectos críticos. Cualquier proyecto con revisión automatizada por IA debería requerir firmas. No es configuración para proyectos de alta seguridad: es el mínimo necesario para que la lógica de confianza por autor tenga algún sentido.
Preguntas Frecuentes
¿Cómo pueden falsificar la identidad de un autor en Git?
Git almacena nombre y email del autor como texto plano en cada commit. Cualquier usuario puede configurar esos valores con git config user.name y git config user.email antes de hacer un commit. Sin firma criptográfica, nadie verifica que esos datos correspondan a la persona real. El sistema funcionó así desde el inicio de Git porque fue diseñado para entornos de confianza entre developers conocidos.
¿Es seguro usar Claude para revisar código automáticamente?
Depende de cómo lo configurés. Si el workflow incluye reglas de confianza basadas en identidad de autor sin verificación criptográfica, el sistema es vulnerable al ataque de Manifold Security. Con commits firmados obligatorios y sin reglas de bypass por nombre, Claude puede revisar código de forma razonablemente segura. La herramienta no es inherentemente insegura, pero la configuración típica lo hace vulnerable.
¿Qué diferencia hay entre commits firmados y sin firmar?
Un commit sin firmar declara nombre y email pero no los verifica. Un commit firmado con GPG o SSH incluye una firma criptográfica que solo puede producir quien tiene la clave privada correspondiente. GitHub verifica esas firmas contra las claves públicas registradas en la cuenta del usuario y marca los commits verificados con un badge “Verified”. Si alguien falsifica el nombre pero no tiene la clave, la firma no coincide y el sistema lo detecta.
¿Cómo proteger un repositorio de commits con identidad falsa?
Tres pasos concretos: primero, requerir commits firmados en ramas protegidas desde Settings > Branches en GitHub. Segundo, configurar firma GPG o SSH para todos los miembros del equipo con git config --global commit.gpgsign true. Tercero, eliminar reglas de confianza por nombre en los workflows de IA, y reemplazarlas por confianza condicionada a firma verificada. Si un commit no tiene firma válida, revisión manual sin excepciones.
¿Qué es el gaslighting de IA en revisión de código?
El término viene del artículo original que nombraba este ataque: Claude aprobó código malicioso con tanta confianza que el investigador dudó de su propio juicio sobre si el código era peligroso. En sentido técnico, describe un modelo que da respuestas incorrectas con alta confianza aparente, basándose en datos falsos que el sistema no cuestionó. En este caso, Claude “vio” un commit de alguien de confianza y actuó en consecuencia, ignorando el contenido real del código.
Conclusión
Lo que demostró Manifold Security no es que Claude esté roto. Es que los flujos de revisión automatizados tienen una premisa silenciosa: que los metadatos de Git son confiables. No lo son, y nunca lo fueron. La diferencia es que antes esa premisa solo afectaba a revisores humanos distraídos. Ahora afecta a sistemas que toman decisiones de merge sin intervención humana.
La corrección técnica existe y es accesible: commits firmados, branch protection rules, revisión de las reglas de confianza en los workflows. Lo que requiere es que los equipos entiendan que configurar Claude para revisión de código no es solo una decisión de producto, es una decisión de seguridad con consecuencias concretas.
Anthropic protege sus propios sistemas con capas adicionales que no están en el tier estándar del cliente. Ese gap vale la pena tenerlo en cuenta al diseñar cualquier pipeline de CI/CD con IA en el medio.
Fuentes
- The Register — Git identity spoof fools Claude into approving malicious code (abril 2026)
- Noah News — Anthropic’s Claude AI review system fooled by spoofed Git identities
- Alex Kim — Claude Code source leak analysis (marzo 2026)
- Anthropic — Claude Code Security Documentation
- Kaspersky LATAM — Riesgos del vibe coding y herramientas IA en desarrollo