METR AI Infrastructure Compromise: Fail-Open Authentication Leads to API Key Theft, SSH Persistence, and $600K in Unauthorized Usage

Anoymask

Posted on Sep 2 Edited on Sep 6

1. Basic Information

• Article Title: AI Model Evaluator METR Hit by Credential Theft, Probing
• Source: Dark Reading
• Publication Date: 2026-09-01
• Original Source: Dark Reading
• Related Information Source: METR Security Update
• Related Malware, Attack Groups, CVEs, Products: METR, AWS EC2, AI agent orchestration dashboard, Google Authentication, OAuth, public transcript viewer
• Severity: High

2. Executive Summary

METR disclosed two security incidents that occurred in March and May 2026. In March, an AI agent management dashboard hosted on a personal EC2 instance suffered from a fail-open authentication flaw, allowing an attacker to steal API keys, add an SSH key, and abuse approximately $60,000 worth of inference credits. In May, following continuous probing of public infrastructure, a public SQL mechanism was found to expose unreleased evaluation data; however, there is no evidence that attackers exploited this vulnerability or accessed non-public data.

3. Attack Flow

March 2026: API Key Theft and SSH Persistence

1. A METR researcher deployed a dashboard to run AI agents on a personal AWS EC2 instance. The instance was exposed to the internet and was intended to be protected by Google Authentication.
2. However, an application heavily built using AI code generation (so-called vibe coding) contained a fail-open vulnerability. When an authentication issue occurred, the app silently disabled Google Authentication instead of denying access. As a result, the dashboard remained accessible from the internet without authentication for several days.
3. METR assesses that attackers may have used Certificate Transparency (CT) logs to discover newly published AI-related sites and found this dashboard. CT logs publicly record newly issued HTTPS certificates and target domains, providing clues for attackers searching for newly launched services.
4. Attackers directly operated AI agents from the exposed dashboard and exposed the API keys of model providers.
5. Furthermore, the attackers added their own SSH key to the EC2 instance to maintain persistent access.
6. The stolen API keys were used for approximately three weeks, consuming about $60,000 worth of inference credits for public AI models. Because METR was provided these credits for free, this did not mean an actual charge of $60,000.

May 2026: Continuous Probing of Public Infrastructure

1. METR received intelligence indicating continuous attacks from potential actors seeking financial gain or access to advanced AI models.
2. Attackers heavily utilized AI agents to automate credential stuffing against authentication infrastructure, attempts to grant OAuth tokens, scanning for newly published services, and phishing employees.
3. Around the same time, a read-only SQL query function was unintentionally exposed in METR’s public transcript viewer. Although designed to reference only public data, combining it with another bug allowed access to unreleased evaluation data.
4. This database was primarily intended to handle data related to public models, but some sensitive model data was mistakenly included.
5. An independent security researcher discovered this vulnerability and reported it to METR, prompting METR to disable the API.
6. Although attackers also accessed this endpoint as part of extensive probing, there is no evidence that they discovered or exploited the vulnerability, or accessed non-public data.

March and May are separate incidents. Public information does not confirm that the attackers in both incidents are the same.

4. Attacker Positioning and Execution Location

• March Incident: Attackers accessed a public dashboard on a researcher’s personal EC2 instance from the internet. They then added an SSH key to secure persistent access to the EC2 instance and used the stolen API keys to access model provider APIs.
• May Incident: Attackers probed METR’s public services externally. There is no evidence of code execution within internal systems or successful access to non-public data.

5. Visibility for Victims and Administrators

March Incident

• The researcher exposed the EC2 instance expecting it to be protected by Google Authentication, but the fail-open flaw silently disabled authentication, making the exposed state difficult to notice from appearance alone.
• Because massive token consumption occurs during normal evaluation processing at METR, the increase in usage caused by unauthorized use blended into normal research activities.
• The internal usage dashboard at the time did not display requests that hit rate limits to all users, lacking clues indicating abnormal usage.
• Because credits were provided for free and there was no spending limit per key, early detection based on monetary amount did not function.

May Incident

• METR observed multiple types of probing and intrusion attempts, including credential stuffing against the auth infrastructure, OAuth token grant attempts, scanning for newly published services, and phishing.
• The vulnerability in the public SQL mechanism was revealed through responsible disclosure by another researcher. Attackers contacted the target endpoint, but successful exploitation of the vulnerability or access to non-public data was not confirmed.

6. Success and Failure Conditions

Conditions That Enabled Compromise in the March Incident

• The dashboard on the personal EC2 instance was reachable from the internet.
• The fail-open vulnerability disabled the intended Google Authentication.
• The EC2 instance contained API keys for METR’s public model account, and AI agents could access those values.
• Attackers made the agents display the API keys and added an SSH key.

Conditions That Could Have Led to Data Breach in the May Incident

• The read-only SQL query function was reachable from the public transcript viewer.
• Exploiting the bug allowed access to unreleased evaluation data beyond the scope of normal public data.
• Some sensitive model data that should not have been included was present in the same database.
• However, there is no evidence that attackers discovered this exploitation method or acquired non-public data.

Risk Mitigation Measures

• Make public applications fail-closed, denying access if authentication anomalies occur.
• Do not bring organization API keys or internal data into personally owned cloud environments or devices.
• Conduct security reviews before deploying public applications.
• Reduce API key lifespans and privileges, and monitor usage, abnormal consumption, and spending.
• Separate environments for public services from internal infrastructure to prevent access to internal data resulting from public-side misconfigurations.

7. What Happens Upon Success

Impacts Confirmed in the March Incident

• Model provider API keys were stolen.
• Attackers’ SSH keys were added to the EC2 instance, enabling persistent access.
• Stolen API keys were used for about three weeks, consuming approximately $60,000 worth of public AI model inference credits.
• Investigations by METR and external security consultants confirmed no evidence that the compromise extended beyond this single API key.

Potential Impacts in the May Incident

• If the SQL mechanism bug had been exploited, unreleased evaluation data would have been accessible.
• The database mistakenly included some sensitive model data.
• However, no evidence was confirmed that attackers exploited this vulnerability or accessed non-public data.

8. Observable Logs

• Email: Phishing employees was attempted in the May incident. Inference: Email security logs or mailbox audit logs can reveal the sender, redirect URLs, recipients, and user interaction status.
• Proxy/SWG/DNS: Scanning of newly published services was observed in the May incident. Inference: Public service access logs or proxy logs can show communications probing multiple endpoints in a short time.
• Endpoint/EDR: Inference: If file auditing or EDR is enabled on EC2, changes to authorized_keys, unknown SSH sessions, and subsequent process execution can be identified.
• Identity/IdP: Credential stuffing and OAuth token grant attempts were observed in the May incident. IdP authentication logs and OAuth audit logs are the primary review targets.
• SaaS/Cloud: Model API usage per key, models, senders, and rate limit status are critical. At the time, METR’s internal usage dashboard did not display requests hitting rate limits to all users, and there were no spending limits per key.
• Network: Inference: If EC2 network logs are collected, external access after dashboard publication, SSH connections, and communications from unusual senders or during unusual timeframes can be reviewed chronologically.

9. Attack Success Determination

March Incident

• Initial Execution Confirmed: It is confirmed that attackers operated AI agents from the public dashboard, displayed API keys, and added an SSH key to the EC2 instance.
• Malware Execution or Successful Authentication Confirmed: No malware execution was reported, but persistent access via the added SSH key and continued use of stolen API keys were confirmed.
• Information Theft or Session Compromise Confirmed: Model provider API keys were stolen, and inference credits were fraudulently used with those keys for about three weeks.
• Unconfirmed Scope: METR and external security consultants found no evidence of compromise exceeding this single API key. Access to Category 3 and 4 sensitive data or credentials was also not confirmed.

May Incident

• Attack Attempts Observed (Success Unconfirmed): Scanning of public services, credential stuffing, OAuth token grant attempts, and phishing were confirmed.
• SQL Mechanism Exploitation Unconfirmed: Attackers contacted the target endpoint, but there is no evidence of discovering or exploiting the vulnerability, or accessing non-public data.

10. Investigation Playbook

• Trigger: Initiate based on sudden spikes in AI API usage, increased requests hitting unusual rate limits, public apps operating without authentication, or unexpected modifications to authorized_keys.
• Initial Review: Identify which apps were published and when, whether intended authentication was actually enforced, which API keys were deployed, and when the usage increase began.
• Endpoints: Stop and isolate the target EC2 instance, save an image, and preserve SSH logs, authorized_keys, AI agent operation history, and process/file modifications.
• Authentication & Cloud: Cross-reference Google Auth, OAuth, AWS, and model provider logs to build a chronological timeline of API keys, sessions, senders, and usage.
• Subsequent Actions: Check for other credentials or internal data placed in the same environment, researchers’ other personal clouds, secondary intrusions into public services, and phishing impacts.
• Containment: Stop public services and revoke/rotate related credentials. Preserve and rebuild compromised terminals and EC2 instances, and separate public environments from internal infrastructure.
• Judgment Classification: Evaluate the March “successful compromise” and May “probing/intrusion attempt and vulnerability exposure” separately. Observing probing does not equate to confirmed successful exploitation of SQL vulnerabilities or data breaches.

11. Defense and Detection Ideas

• Single Events: Candidate events include agent operations executed from public AI apps without authenticated sessions, unknown keys added to authorized_keys, or sudden changes in API key senders.
• Chronological Correlation: Correlate the sequence of deploying a newly published app -> unauthenticated operations -> agent-based API key disclosure -> SSH key addition -> surge in model API usage.
• Hunting: Inventory public AI apps including personal/test environments, organization API keys deployed there, and usage, senders, and rate limit status per key.
• Log Gaps: Without visibility into requests hitting rate limits, key-specific senders, and AI agent operation history, heavy usage blends into normal evaluation processing. Usage alerts must be established even for free credits.
• Priority Mitigations: Prioritize security reviews for public apps, fail-closed authentication, short-lived and least-privilege API keys, usage alerts, restrictions on bringing organizational credentials into personal environments, and separation of public and internal environments.

12. Facts / Inference / Hypothesis

Facts

• In March 2026, an AI agent dashboard deployed to a personal EC2 instance by a METR researcher suffered from a fail-open vulnerability, silently disabling Google Authentication and exposing it to the internet for several days.
• Attackers made the AI agent display model provider API keys and added an SSH key to the EC2 instance. The stolen API keys were used for about three weeks, consuming approximately $60,000 worth of public AI model inference credits.
• At METR, heavy token consumption looked like normal evaluation processing, requests hitting rate limits were not displayed to all users on the internal dashboard, and free credits lacked spending limits, delaying the discovery of abnormal usage.
• METR assesses that attackers may have used Certificate Transparency (CT) logs to discover newly published AI-related sites and found the public dashboard. CT logs publicly record newly issued HTTPS certificates and target domains.
• In May 2026, attackers used AI agents to automate credential stuffing, OAuth token grant attempts, public service scanning, and phishing.
• Around the same time, a read-only SQL query function was exposed in the public transcript viewer, allowing access to unreleased evaluation data if the bug was exploited. Some sensitive model data was also mistakenly included in the same database.
• Attackers contacted this endpoint, but no evidence was confirmed that they discovered or exploited the vulnerability, or accessed non-public data.

Inference

• Because AI research and evaluation environments generate heavy inference processing as normal operations, it is necessary to combine total usage with API keys, users, senders, models, and rate limit status to detect behaviors deviating from normal usage trends.

Hypothesis

No additional hypotheses. Unconfirmed items are documented in “Unknowns and Additional Investigation.”

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (High): In the March incident, the fail-open vulnerability of an internet-exposed dashboard was exploited to allow unauthenticated operations. For the May SQL mechanism, exploitation by attackers was not confirmed.
• T1098.004 Account Manipulation: SSH Authorized Keys (High): Attackers added an SSH key to the EC2 instance to secure persistent access.
• T1110.004 Brute Force: Credential Stuffing (High): In the May incident, credential stuffing against the authentication infrastructure by attackers was confirmed. However, successful authentication was not confirmed.

14. Unknowns and Additional Investigation

• Whether the attackers in the March and May incidents are the same, and the attribution of the attackers.
• Details of the model providers, API key senders, and used models abused in the March incident.
• Specific privileges and operation paths that allowed attackers to add an SSH key to the EC2 instance.
• Specific implementation details of the SQL mechanism and bugs exposed in the May incident.
• Although METR confirmed no evidence indicating access to Category 3 and 4 data, public information alone does not clarify the full scope and retention status of log collection.

15. Impact on SOCs and Organizations

The key takeaway from this incident is that traditional fundamental controls—such as authentication settings, credential management, public environment separation, and anomaly detection—remain just as critical in AI research and development environments as novel AI-specific attacks.

In particular, because massive usage of AI APIs can easily mimic legitimate evaluation and development work, relying solely on total token counts or billing amounts may cause anomalies to be overlooked. It is important to baseline normal usage volumes, senders, users, models, and rate limit statuses per API key to detect unusual usage patterns.

Additionally, treating prototyping apps or researchers’ personal clouds as temporary test environments with exceptions creates entry points to organizational API keys and internal data. Pre-deployment reviews, fail-closed authentication, short-lived and least-privilege credentials, and the separation of public and internal environments must be applied to test environments as well.

16. Summary by Role

• For SOCs: Monitor AI API abuse by combining total volume with API keys, users, senders, models, and rate limit status. Correlating these with new public AI app deployments, authentication anomalies, and authorized_keys changes helps identify unauthorized usage following API key theft earlier.
• For Administrators: Enforce policies prohibiting the introduction of organizational API keys and internal data into personal clouds or prototyping environments, and implement pre-deployment reviews, fail-closed authentication, short-lived and least-privilege API keys, usage/spending alerts, and environment separation.
• For Users: Before exposing prototyping AI apps externally, verify that authentication is actually enforced, confirm that no organizational API keys or internal data remain, and undergo necessary reviews.