Resumen ejecutivo
El Silverfort Un equipo de investigación ha descubierto que la forma en que Anthropic almacena las credenciales de la interfaz de línea de comandos de Claude Code en macOS facilita que cualquier proceso que se ejecute con los permisos del usuario robe las credenciales de su cuenta de Anthropic y, por extensión, las de cualquier servidor MCP conectado. Una simple lectura silenciosa devuelve todo el conjunto de credenciales, que un atacante puede reproducir desde otra máquina para hacerse pasar por el usuario.
El Llavero de macOS cuenta con un mecanismo de almacenamiento seguro que requiere que el usuario vuelva a introducir su contraseña o confirmación biométrica antes de compartir una clave secreta con un proceso solicitante. Claude Desktop lo utiliza correctamente. Si otro proceso intenta acceder a la credencial almacenada, macOS solicita al usuario que se vuelva a autenticar. Claude Code CLI no lo hace. Está implementado de forma que cualquier proceso en modo usuario puede obtener la credencial sin necesidad de volver a autenticarse, y profundizaremos en este tema en este blog.
Técnicamente, esto no es una vulnerabilidad, sino un fallo de diseño en la implementación, una debilidad de seguridad: las credenciales que deberían requerir una nueva autenticación no la requieren. Para explotarlo, no se necesita una técnica sofisticada más allá de la estándar "ejecutar código como el usuario", un requisito mucho menor que la escalada de privilegios. El fallo de diseño afecta a cualquier usuario de macOS que ejecute la CLI de Claude Code (no a los usuarios de escritorio ni a los de la CLI de Windows/Linux, ya que estos dependen del almacenamiento basado en archivos, donde las heurísticas antivirus/EDR existentes ya deberían detectar cualquier manipulación).
El resultado final: si un código malicioso se ejecuta bajo la cuenta de un usuario, puede leer silenciosamente las credenciales de Claude, sin escalada de privilegios, sin solicitud de contraseña, sin alerta, y moverse lateralmente accediendo a los servidores MCP. En macOS, Keychain es el mejor método en comparación con el almacenamiento basado en archivos, pero como Claude Code CLI omite el paso de reautenticación, esa ventaja desaparece, y ninguna heurística antivirus existente monitorea esto como lo hacen las heurísticas de acceso a archivos en otras plataformas. Si un endpoint es comprometido, un atacante obtiene acceso a la cuenta de Anthropic del usuario y a cualquier servidor MCP conectado, y puede influir en todo lo que controlan esos servidores, el código fuente de la empresa en GitHub, su base de conocimientos en Atlassian u otros conectores MCP sensibles.
Silverfort El 25 de junio se informó de este hallazgo a Anthropic a través de HackerOne, siguiendo su práctica de divulgación responsable. Anthropic respondió rápidamente y, tras consultar con su equipo, confirmaron que están haciendo un seguimiento de un endurecimiento del control de acceso del elemento Keychain como una mejora de seguridad y creen que es "un cambio de defensa en profundidad... que vale la pena realizar". Anthropic no puso objeciones. Silverfort publicar la investigación.
Guía para defensores
Hasta que se solucione este problema, las organizaciones que utilicen Claude Code CLI en macOS deberían crear una alerta cada vez que se utilice el mismo token en diferentes máquinas. Más allá de la detección y respuesta tradicionales, las organizaciones deberían considerar una plataforma de seguridad de identidad que pueda controlar el uso de credenciales estáticas o temporales, e indicar cuándo se utiliza el mismo token desde dos máquinas diferentes, un fuerte indicador del uso de credenciales robadas. Los equipos de seguridad deben supervisar el acceso anómalo o inesperado a los procesos que accedan a la entrada del llavero utilizada por la CLI de Claude Code. Los patrones de acceso inusuales a este almacén de credenciales son un indicador importante de una posible vulneración y deben considerarse un motivo para iniciar una investigación.
Fondo
Los agentes de codificación de IA ahora poseen credenciales reales. Para realizar su trabajo, inician sesión y mantienen un token en la máquina, y el Claude Code CLI Claude no es una excepción. Al ejecutarlo, inicia sesión con un paquete OAuth: un token de acceso temporal y un token de actualización permanente. El token de actualización es lo que debería preocuparte. Se puede intercambiar por nuevos tokens de acceso hasta que alguien lo revoque, por lo que no se trata de una sesión temporal. Es un acceso permanente a la cuenta desde un ordenador portátil.
La ubicación del paquete OAuth depende del sistema operativo. En dos de las tres plataformas (Linux y Windows), se trata de un archivo simple en el disco. En macOS, se guarda en el llavero del sistema operativo, lo cual es lógico, pero con una particularidad: por defecto, el elemento está bloqueado al programa que lo creó, y en este caso, la seguridad es una herramienta que cualquier proceso puede ejecutar. Por lo tanto, el bloqueo existe, pero nunca se ejecuta, y cualquier proceso bajo tu cuenta obtiene los tokens sin que el usuario tenga que introducir su contraseña.
Seguiremos las credenciales CLI de Claude Code en las tres plataformas, analizaremos detenidamente el defecto de macOS, cubriremos un truco de bajo impacto para reutilizar un paquete robado y terminaremos con la pregunta que toda empresa se hará: ¿no es cierto que el nuevo... Puerta de enlace de aplicaciones Claude ¿Hacer esto irrelevante? La respuesta corta es no.
Los secretos en un archivo suenan peor, pero es el que puedes ver
En Linux y Windows, las credenciales se almacenan en un archivo JSON de texto plano, sin la intervención del almacén de claves del sistema operativo. Si bien esto puede parecer una medida menos segura, un archivo de credenciales en disco es un problema que los expertos en seguridad ya saben cómo manejar. Es un objetivo clásico, y las herramientas de protección de endpoints, como los antivirus y las EDR, pueden detectar procesos que acceden a un archivo con tokens. Existe un lugar conocido donde implementar un control y un mecanismo de alerta concreto. En macOS, esta medida de seguridad desaparece, como veremos.
La documentación de la CLI de Claude Code indica dónde se encuentra el archivo:
“En Linux, las credenciales se almacenan en
~/.claude/.credentials.jsoncon el modo de archivo 0600.”“En Windows, las credenciales se almacenan en
%USERPROFILE%\.claude\.credentials.jsony heredar los controles de acceso del directorio de su perfil de usuario, que restringe el acceso al archivo a su cuenta de usuario de forma predeterminada.”
Un pequeño inconveniente: CLAUDE_CONFIG_DIR Este archivo se mueve a otro lugar, por lo que las reglas de detección que codifican la ruta literal no detectarán esas instalaciones.
Dentro de ese archivo se encuentra todo lo que vale la pena guardar: un token de acceso OAuth (sk-ant-oat…), el token de actualización de larga duración (sk-ant-ort…), una marca de tiempo de expiración y los ámbitos del token. El mismo almacén también guarda los tokens OAuth del servidor MCP y los secretos de los complementos que hayas conectado. El token de actualización es el importante, ya que una sola lectura del mismo otorga acceso permanente a la cuenta. En Linux y Windows, aquí tienes algunas sugerencias sobre qué tener en cuenta:
- Monitoreo de la integridad de los archivos. Tratar
~/.claude/.credentials.json(Y elCLAUDE_CONFIG_DIRvariante) como objeto sensible. La alerta que desea es una lectura o apertura por cualquier proceso que no sea el binario claude. En Linux puede hacer esto con un reloj auditd (auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_creds) o telemetría abierta eBPF. En Windows, utilice la auditoría de acceso a objetos (ID de evento 4663) con una SACL o la telemetría de lectura de archivos EDR. - Desviación de permisos. El archivo de Linux debería permanecer en
0600Si se vuelve legible para el grupo o para todo el mundo, eso ya es una señal de alerta. - Firmas de contenido. Trate los prefijos sk-ant-oat (acceso) y sk-ant-ort (actualización) como indicadores de credenciales para DLP y AV. Márquelos en archivos fuera del directorio de configuración, en archivos comprimidos, en el portapapeles y en el tráfico saliente. Una coincidencia con el prefijo refresh-token es la más grave.
- El problema de la identidad. La mejor señal no está en el punto final. Un token que aparece primero en un host y luego en otro es un claro indicador de robo. Esté atento a la aparición de la misma sesión OAuth desde un nuevo dispositivo, ubicación o IP poco después de una lectura local. Detectar este tipo de reutilización entre hosts es la función de una plataforma de detección de amenazas de identidad.
Conserva el archivo complementario, ~/.claude.json, también en tu radar. No es la tienda secreta, pero contiene la identidad de la cuenta (oauthAccount,userID), que es la otra mitad de una sesión de trabajo. Hablaremos más sobre eso en la siguiente sección.
El candado que no cierra: En macOS, el Llavero es una buena idea, pero debe implementarse correctamente.
macOS rompe ese patrón con la CLI que guarda sus credenciales en el Llavero en lugar de en un .credentials.json archivo. La documentación es explícita:
“En macOS, las credenciales se almacenan en el llavero cifrado de macOS.”
Este es el instinto correcto. Un almacenamiento cifrado y protegido por el sistema operativo siempre supera a un archivo plano. Pero la seguridad de un elemento del llavero depende de la lista de control de acceso (ACL) asociada, y es aquí donde este elemento en particular falla.
Claude Code CLI crea su elemento Keychain desembolsando /usr/bin/security add-generic-passwordy no pasa ningún argumento de control de acceso: ni -T para confiar en una aplicación específica, ni -A para permitir cualquier aplicación. Por lo tanto, el elemento hereda la lista de control de acceso (ACL) predeterminada del llavero. La página man security(1) de macOS explica qué hace esa configuración predeterminada:
“Por defecto, se confía en que la aplicación que crea un elemento acceda a sus datos sin previo aviso. Puede eliminar este acceso por defecto especificando explícitamente una ruta de acceso vacía para la aplicación: -T “”.
En esta ruta de código se encuentra la aplicación que crea el elemento. /usr/bin/security mismo. Por lo tanto, el lector de confianza registrado en el artículo es /usr/bin/security, sentado en el apple-tool: partición que macOS reserva para las herramientas firmadas por Apple. Ese valor predeterminado es el problema. /usr/bin/security es una herramienta de línea de comandos de propósito general, firmada por Apple, y cualquier proceso que se ejecute bajo su cuenta puede llamarla sin privilegios especiales. Una ACL cuyo único lector de confianza es el security La herramienta es satisfecha por cualquier proceso que ejecute el security herramienta, es decir, cualquier proceso en la máquina. La ACL está diseñada para controlar qué programa puede leer el secreto. En la práctica, no controla nada, ya que cualquier programa puede leerlo solicitando a un binario estándar que realice la lectura.
El resultado es una lectura silenciosa de una sola línea:
security find-generic-password -s "Claude Code-credentials" -a "$USER" -w
Sin Touch ID, sin solicitud de contraseña, sin elevación de privilegios. Se devuelve el JSON completo de las credenciales: el token de acceso, el token de actualización de larga duración y cualquier secreto de MCP o complemento que comparta el elemento.
Anthropic ya lo hace bien con Claude Desktop, así que ¿por qué no con Claude Code CLI?
La prueba más clara de que se trata de una decisión de implementación y no de una limitación de macOS es que Anthropic ya lo hace correctamente en Claude Desktop. Claude Desktop se ejecuta en el mismo sistema operativo, para el mismo usuario y protege el mismo tipo de información confidencial. Lo hace con Electron safeStorage, y vale la pena explicar su diseño, ya que no es el mismo que el de la interfaz de línea de comandos (CLI). safeStorage guarda una clave de cifrado en el llavero y almacena los tokens reales como texto cifrado en un archivo en el disco. La documentación de Electron describe cómo se protege esa clave:
“Las claves de cifrado de tu aplicación se almacenan en Acceso a Llaveros de forma que impide que otras aplicaciones las carguen sin la autorización del usuario.”
El elemento Keychain que contiene esa clave solo enumera la aplicación Claude firmada en su ACL, y su partición está anclada al equipo de desarrolladores de Anthropic, por lo que una lectura de seguridad desde cualquier De lo contrario, se le pedirá la contraseña de inicio de sesión.El texto cifrado en el disco es inútil sin la clave, y la clave no se obtiene sin esa solicitud.
Ambos diseños parecen similares, pero se comportan de forma muy diferente. La interfaz de línea de comandos (CLI) almacena los tokens en el llavero con una lista de control de acceso (ACL) que permite que cualquier proceso los lea. Claude Desktop, en cambio, almacena solo una clave en el llavero, la vincula a su propia firma y guarda los tokens cifrados en un archivo que, por sí solo, resulta inútil. Mismo sistema operativo, mismo usuario, mismo tipo de secreto: uno puede ser leído silenciosamente por cualquier proceso, mientras que el otro requiere la aprobación del usuario. La diferencia radica en cómo se crea el elemento del llavero y qué protege.
Causa principal: La CLI entrega la creación de elementos a /usr/bin/security En lugar de usar la API nativa de Keychain Services para vincular el elemento a la firma de código del binario de Claude, que es el patrón que ya incluye Claude Desktop, la herramienta de seguridad no puede vincular un elemento al programa que lo llamó. Solo la API nativa puede hacerlo. En términos de vulnerabilidad, esto corresponde a CWE-732 (asignación incorrecta de permisos para un recurso crítico) y CWE-522 (credenciales insuficientemente protegidas).
Reconstruir la sesión sin modificar ningún archivo de configuración.
Leer el token es solo la mitad de la suplantación de identidad. Para actuar como la víctima, la CLI de Claude Code también necesita saber quién ha iniciado sesión, que normalmente reside en el oauthAccount bloque interior ~/.claude.jsonLo lógico sería robar también ese archivo. Sin embargo, existe una forma más limpia que deja muchas menos huellas, y vale la pena analizarla, ya que la explicación obvia de por qué funciona es errónea.
La receta, en la máquina del atacante:
1. Exporta el token de acceso robado y ejecuta claude una vez:
export ANTHROPIC_API_KEY=<access-token>
claude
2. Salir y luego unset ANTHROPIC_API_KEY.
3. Coloca el paquete robado completo en tu propio llavero:
security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'
4.Ejecutar claude De nuevo. Ahora has iniciado sesión como la víctima.
Aquí viene la parte contraintuitiva. La variable de entorno no es lo que te inicia sesión. Un robo sk-ant-oat… El valor colocado en ANTHROPIC_API_KEY se envía como encabezado X-Api-Key, según la documentación de prioridad de autenticación de la CLI de Claude Code. Ese encabezado es incorrecto, y además es un tipo de token incorrecto, ya que un token de acceso OAuth no es una clave de API de consola. No autentica las llamadas al modelo en absoluto.
¿Para qué sirve la exportación? El orden de las operaciones es clave. La primera ejecución, con el token de acceso robado exportado, es el paso que consigue que la identidad de la cuenta de la víctima se escriba en ~/.claude.json, para que el atacante nunca tenga que copiar ese archivo. A continuación, se desactiva la variable y se coloca el paquete completo, incluido el token de actualización, en el llavero. La documentación describe unset ANTHROPIC_API_KEY como la forma de “recurrir a tu suscripción”, y la ejecución final hace precisamente eso: se autentica con el paquete Keychain como credencial de suscripción, cuyo token de actualización de larga duración sigue generando nuevos tokens de acceso. Esa credencial es la entrada de menor prioridad en la lista y también la más duradera.
¿Por qué debería importarles a los defensores? Porque la clave de este método es su mínima huella digital. Una lectura silenciosa del llavero equivale a la captura de varios archivos, y al copiar menos archivos en la máquina de origen, hay menos indicadores para la detección de exfiltración. En macOS, ni siquiera se puede esperar a que se genere un archivo, porque no existe tal archivo. La lectura se realiza dentro de un proceso, por lo que es ahí donde hay que vigilar.
Toda la cadena, de principio a fin.
Al unir ambas partes, el ataque es rápido. En el lado de la víctima, todo funciona como un usuario normal, sin avisos ni privilegios; en el lado del atacante, simplemente se repite la operación.
Aquí se muestra ese mismo flujo como prueba de concepto, ejecutándose de principio a fin:
¿No solucionará esto la puerta de enlace de aplicaciones de Claude?
Respuesta corta: no. Implementamos la puerta de enlace, configuramos nuestro propio código Claude para que la utilizara y ejecutamos el mismo método de robo. Y funcionó.
Es importante ser preciso sobre qué es la puerta de enlace, ya que su función es más específica de lo que sugiere su nombre. No se trata de una capa de seguridad que envuelve la configuración habitual de Claude. Es una herramienta de enrutamiento, una forma de dirigir Claude Code a un punto final de modelo específico que la organización utiliza o elige, en una ubicación distinta a la ruta predeterminada de Anthropic: en las instalaciones, Microsoft Foundry, Amazon Bedrock, Google Cloud o un punto final de Anthropic propio. Los motivos que observamos fueron los habituales: residencia de datos y normas de cumplimiento, un proveedor de nube preferido o una implementación local. Si este no es el caso de su organización, la puerta de enlace nunca formó parte de su configuración, y el elemento Keychain se expone exactamente como se describe en el resto de esta publicación.
Es justo preguntarse qué ventajas ofrece la puerta de enlace, porque no son insignificantes. Los desarrolladores inician sesión con SSO corporativo, las sesiones duran aproximadamente una hora y la revocación se realiza a través del IdP, por lo que una vez que una organización desactiva a un usuario, su acceso a la puerta de enlace se pierde dentro de la misma sesión. La clave de origen, la clave API de Claude o la credencial en la nube, no se almacena en el portátil. Eso es lo que quiere decir el anuncio con:
“Ningún secreto duradero se guarda en las máquinas de los desarrolladores.”
Vale la pena leer esa línea tal y como dice, porque se refiere a la clave de origen, no al robo. Lo que aún permanece en el Llavero bajo la puerta de enlace es una credencial de actualización. Puede que esté configurada para que solo la puerta de enlace la acepte, pero ahí radica el problema: un atacante que la obtenga y se conecte a la puerta de enlace como el usuario puede seguir creando nuevas sesiones mientras esa cuenta permanezca habilitada. La sesión de una hora nunca limita al ladrón. Lo único que lo detiene es que la organización lo detecte y deshabilite al usuario, y una lectura silenciosa del Llavero no provoca que eso suceda. La promesa de "sin secretos duraderos" se convierte silenciosamente en acceso permanente para quien lea el elemento.
Así que configuramos una puerta de enlace, conectamos a Claude a ella y repetimos el ataque de la sección anterior. La lectura del llavero no cambió. El mismo script de Python de una sola línea extrajo la credencial sin ninguna solicitud, y la copiamos a una segunda máquina.
Esta vez ni siquiera necesitamos el arranque adicional de la sección anterior, ni un segundo archivo de la víctima. La dirección de la puerta de enlace ya está dentro de la credencial que robamos. El valor almacenado en el llavero de credenciales de Claude Code contiene más que los tokens. También registra la puerta de enlace en la que la víctima inició sesión, por lo que una lectura silenciosa nos proporciona tanto las claves como la dirección de la puerta que abren.
Eso significa que no hay nada adicional que extraer del disco de la víctima. Creamos la configuración en la propia máquina del atacante, en:
/Biblioteca/Soporte de aplicaciones/ClaudeCode/managed-settings.json
y apuntarlo a la URL de la puerta de enlace que acabamos de leer de la credencial robada:
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}
Escribir ese archivo no supone ningún obstáculo. Anthropic define la configuración gestionada como un control del lado del cliente, no como una barrera de seguridad, por lo que un atacante puede crear la suya propia. A continuación, cargamos la credencial robada e iniciamos Claude Code. No hay ningún paso adicional para recrear la identidad de la víctima. La credencial contiene el token, este se autentica en la puerta de enlace y esta ejecuta la sesión como la víctima, con sus permisos de acceso.
La puerta de enlace supone un obstáculo que un atacante puramente remoto no podría superar. Claude Code no se comunica con una puerta de enlace a través de una dirección pública:
En /login, Claude Code requiere que el nombre de host o la dirección IP de la puerta de enlace se resuelva únicamente a direcciones privadas: RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 o loopback para desarrollo local. Para una puerta de enlace que usted aloje, se rechaza cualquier dirección pública.
Así pues, la credencial robada solo funciona desde algún lugar que pueda acceder a la puerta de enlace privada. Esto parece una barrera infranqueable hasta que se recuerda el modelo de amenazas. Partimos de la base de que el atacante se ejecuta como el usuario en el equipo de la víctima, que, para empezar, se encuentra dentro de esa red. Acceder a una dirección privada desde ahí es la parte fácil. Se trata de una fricción, no de una barrera.
Aquí está la evaluación honesta. La puerta de enlace es útil por otras razones. Mantiene la clave de origen fuera del portátil y proporciona a la organización un interruptor de seguridad centralizado a través del IdP, aunque esto solo funciona una vez que alguien detecta el robo. Lo que no hace es solucionar la vulnerabilidad que se describe en esta publicación. La credencial sigue apareciendo en el mismo elemento del llavero, que sigue siendo legible por cualquier proceso sin necesidad de aviso, y una credencial de actualización robada continúa funcionando contra la puerta de enlace hasta que se desactiva la cuenta.
La comprobación de la red es un desvío, no una parada. Y para la gran mayoría de los usuarios, que nunca interactúan con la puerta de enlace, nada cambia.
¿Qué debe hacer un defensor de inmediato?
- macOS: hasta que la ACL del elemento esté vinculada a la firma de Claude, su punto de detección es el proceso, no un archivo. La señal es una llamada a /usr/bin/security find-generic-password cuya cadena de servicio es Claude Code-credentials y que lleva -w para imprimir el secreto. Genere alertas a través de la ejecución de procesos o la telemetría de Endpoint Security, y use el linaje del proceso para eliminar los falsos positivos: las lecturas legítimas se remontan al binario de Claude, así que establezca primero la línea base de esas, mientras que las sospechosas provienen de una línea de shell, un editor o host de extensión, o un script de instalación de dependencias. Monitoree también add-generic-password para el mismo servicio, porque así es como se planta un paquete robado en una segunda máquina. Trate estas alertas como un control compensatorio.
- Linux y Windows: supervisión de la integridad de archivos y DLP en .credentials.json, alertas de desviación de permisos y firmas de contenido en los prefijos sk-ant-oat y sk-ant-ort.
- En todas partes: correlacione las lecturas del almacén de credenciales con el tráfico saliente inesperado y supervise el plano de identidad para detectar la reutilización del mismo token en diferentes hosts. Rote ante cualquier sospecha. Una sola lectura entrega un token de actualización de larga duración, por lo que un evento de lectura creíble requiere cerrar sesión y volver a iniciarla, además de la rotación de la clave de consola, no solo la limpieza del punto final.
- La solución definitiva la tiene Anthropic, y es de bajo riesgo: crear el elemento Keychain de la CLI mediante la API nativa, vinculado a la firma de código del binario de Claude. Este es el patrón que ya se incluye en Claude Desktop.
La buena noticia es que la parte más difícil ya está resuelta en el código fuente de Anthropic. La interfaz de línea de comandos no necesita un nuevo modelo de seguridad; necesita el que ya está funcionando en segundo plano.
Cronograma de divulgación
25 de junio, 3:46 UTC. El investigador presenta el informe con los pasos para reproducir el problema, el impacto y tres capturas de pantalla.
25 de junio, 4:05 UTC. Anthropic lo cierra como informativo tan solo 19 minutos después, descartándolo fuera del alcance bajo "Almacenamiento local de credenciales, configuración y registros de Claude Code", y afirma que los procesos del mismo usuario son totalmente confiables, por lo que las ACL de Keychain por proceso no agregan ningún límite significativo.
2 de julio, 11:12 UTC. El investigador solicita una reevaluación humana, argumenta que el cierre se asignó a la exclusión incorrecta (se trata de una configuración errónea de la ACL del llavero, no del almacenamiento local, y el escritorio lo gestiona correctamente en el mismo sistema operativo), adjunta el vídeo de la prueba de concepto y anuncia la elaboración de un informe defensivo con la oferta de coordinar la divulgación.
2 de julio, 11:14 UTC. Anthropic reconoce la solicitud de reevaluación y afirma que la revisará internamente, confirma que no hay inconveniente en que el debate público esté abierto, ya que el informe es un caso cerrado, y solicita ver un borrador con antelación.
22 julio. El investigador comparte el borrador final del blog para su revisión previa a la publicación, tal como lo solicitó Anthropic, y señala que ahora incluye un análisis sobre si la puerta de enlace de las aplicaciones Claude mitiga o no la vulnerabilidad.
24 julio. Anthropic finaliza su revisión, no reporta problemas de hecho ni solicita correcciones, y autoriza la publicación del informe. Su clasificación permanece sin cambios: añade que ahora está haciendo un seguimiento del endurecimiento del control de acceso del elemento Keychain como una mejora de seguridad integral que vale la pena implementar, aunque no lo considera una vulnerabilidad según su modelo de amenazas.
