Avoidable Secrets Breaches

GitGuardian reported in August 2026 that it had found 4,576 unique n8n API tokens sitting in public GitHub commits, tied to more than 1,200 hostnames. When researchers tested them, 896 instances were reachable and 321 still accepted a leaked token. Because n8n wires together the systems it automates, one working token exposed workflow definitions and the credentials stored inside them, including OpenAI keys and database passwords, all through normal API calls with no vulnerability involved. The set also included hundreds of Model Context Protocol tokens, a handful still valid.

4,576 leaked tokens across more than 1,200 hostnames. Of 896 reachable instances, 321 still accepted a leaked token.

Valid n8n API tokens, and some MCP tokens, granting access to workflow definitions and the credentials stored in them, including OpenAI keys, database passwords, and deployment keys.

A single leaked automation token was a skeleton key to every system wired into that platform, reachable through standard API calls. Automation and agent platforms concentrate secrets, so their API tokens are high-value keys that belong out of git and on an aggressive rotation schedule.

Hugging Face disclosed in July 2026 that a malicious dataset uploaded to its platform exploited a vulnerability to run code on its servers. It attributed the activity to an external AI agent that carried out thousands of actions across short-lived sandboxes, using stolen and forged machine credentials to move deeper into internal systems. The intruder reached Kubernetes admin access and gained write access to a subset of internal source-code repositories. Hugging Face revoked and rotated the stolen credentials, fixed the vulnerability, and urged all users to rotate their access tokens.

Undisclosed. Hugging Face urged all users to rotate access tokens, and its investigation into customer and partner data was ongoing.

Internal service credentials and forged identity tokens, internal datasets, and write access to a subset of internal source-code repositories.

Users had to rotate their Hugging Face tokens and review account activity because stolen and forged machine credentials let the intruder move laterally into internal systems. Short-lived, tightly scoped machine identities and fast rotation are the main defense once an attacker is running thousands of actions inside your environment.

An extortion actor calling itself Icarus breached Klue, a competitive-intelligence vendor, in June 2026 by abusing an OAuth integration credential to steal the tokens customers used to connect Klue to their own systems. With those tokens the attacker reached connected SaaS platforms like Salesforce and Gong and pulled business data. Nearly 200 companies were named in the actor's claims, and Huntress, Recorded Future, Tanium, and Jamf confirmed they were affected. The stolen data was limited to CRM and business records; Huntress said no products, infrastructure, passwords, or payment data were touched.

Nearly 200 companies were named in the actor's claims. Huntress, Recorded Future, Tanium, and Jamf confirmed impact.

Business contact details, sales communications, pricing, and trial data pulled from customers' Salesforce and Gong systems using stolen OAuth tokens.

Customers had CRM data taken through an integration they had authorized, without their own logins ever being phished. OAuth tokens granted to third-party apps are standing keys to your data, so keep them least-privilege, short-lived, and revocable.

Attackers published a malicious version of the Nx Console extension, 18.95.0, to the VS Code Marketplace on May 18, 2026, using a stolen contributor token. The extension has millions of installs, and simply opening a workspace with the poisoned version silently harvested a developer's credentials. The payload swept up GitHub and npm tokens, AWS credentials, HashiCorp Vault and Kubernetes tokens, 1Password data, SSH keys, and the contents of .env files, and on macOS it installed a persistent backdoor. The malicious version was live only briefly, but developer machines that upgraded during the window had their full credential set exposed.

The extension had more than 2.2 million installs. Actual theft was limited to developers who upgraded during the short window and then opened a workspace.

GitHub and npm tokens, AWS credentials, HashiCorp Vault and Kubernetes tokens, 1Password data, SSH keys, and .env file contents from developer machines.

Opening a workspace was enough to exfiltrate a developer's entire credential set, and on macOS it left a persistent backdoor. Editor extensions are part of your supply-chain attack surface, so scope developer tokens tightly and treat local dev secrets as targets.

A GitGuardian researcher found a publicly accessible GitHub repository named Private-CISA holding roughly 844MB of production infrastructure secrets belonging to the U.S. cyber agency. It contained plaintext passwords, AWS credentials, Azure keys, GitHub personal access tokens, Artifactory tokens, and SAML certificates, some in files named things like Important AWS Tokens.txt. The repository had reportedly been exposed for about six months. After disclosure on May 14, 2026, CISA took it down within about a day, and said it had no indication the data was misused.

Roughly 844MB of one agency's production infrastructure secrets were public for a reported six months.

Plaintext passwords, AWS credentials, Azure registry keys, GitHub personal access tokens, Artifactory tokens, SAML certificates, and Kubernetes and Terraform configs.

Anyone who found the repo had a map and the keys to production infrastructure. Hardcoded, long-lived secrets committed to a repo are a breach waiting to happen, and private by name is not access control; secrets belong in a managed store, never in source.

Vercel disclosed in April 2026 that attackers had compromised Context.ai, a third-party AI tool one of its employees used, and abused its Google Workspace OAuth access to take over that employee's account. From there they pivoted into Vercel's internal systems and reached the environment variables of a limited subset of customers. Vercel characterized the exposed variables as non-sensitive and said its published npm packages were not affected. The company framed the incident around OAuth sprawl and the risk of broadly scoped grants to shadow AI tools.

Undisclosed. Vercel described a limited subset of customers plus a small number of additional accounts.

Environment variables belonging to a limited subset of customers, which Vercel characterized as non-sensitive. Its npm packages were not affected.

The entry point was a single broadly scoped OAuth grant to a third-party AI tool, which became a path into internal systems and a customer secret store. Environment-variable secrets need short lifetimes, and OAuth grants to outside tools need tight scoping and review.

Attackers pushed two backdoored versions of LiteLLM, 1.82.7 and 1.82.8, to PyPI on March 24, 2026. LiteLLM sits in front of many AI stacks as a gateway and pulls in millions of downloads a day, so a tainted release could reach a lot of pipelines fast. The malicious code ran a credential stealer against CI/CD environments, sweeping up cloud credentials, SSH keys, Kubernetes tokens, .env files, and the AI provider API keys the gateway exists to route. The packages were pulled quickly, but stolen credentials keep working until they are rotated, and a large trove of the harvested secrets later surfaced publicly.

Undisclosed and not independently confirmed. Reporting cited around 2,500 exposed organizations, and BleepingComputer's sources put the number of credential exfiltrations near 500,000.

Cloud credentials (AWS, GCP, Azure), SSH keys, Kubernetes tokens, CI/CD secrets, .env contents, and AI provider API keys pulled from build environments.

Any team that installed a poisoned version had live secrets swept out of its pipelines, and some of those credentials still worked months later. A single compromised upstream package can turn a trusted AI dependency into an exfiltration tool, so pin and verify dependency versions and rotate pipeline and gateway secrets after any supply-chain event.

CarGurus confirmed a cybersecurity incident involving unauthorized access to an internal company database. According to the company, the breach exposed limited dealership contact and internal business data, highlighting the risks of credential compromise and weak access workflows. The incident follows broader reporting tying the attack to social engineering and credential-focused intrusion methods used by the ShinyHunters group. CarGurus said the event was contained, services remained operational, and affected parties were directly notified where sensitive information may have been involved.

Undisclosed

Internal company database, employee authentication workflows

Attackers reportedly gained access through social engineering techniques targeting employee authentication workflows. Centralized access controls, phishing-resistant authentication, and tighter credential management help reduce the blast radius when employee accounts are compromised.

Wiz found that Moltbook, a social network for AI agents, had left its Supabase database open through a hardcoded API key in client-side JavaScript with no row-level security behind it. Anyone could read and write the production database. The exposure included about 1.5 million agent API tokens, more than 35,000 user emails, and roughly 4,060 private messages, some of which held users' own OpenAI keys, adding up to around 4.75 million records. The issue was reported on January 31, 2026 and patched within a day.

More than 35,000 user emails and roughly 1.5 million agent accounts owned by about 17,000 people, around 4.75 million records in total.

About 1.5 million agent API tokens, more than 35,000 user emails, and roughly 4,060 private messages, some containing third-party OpenAI API keys.

Anyone who looked could impersonate any agent, read private messages, and lift the third-party keys inside them, with full write access on top. Never ship a privileged API key in client-side JavaScript, and never treat a database as private without row-level access controls.

Security researchers uncovered over 175,000 publicly exposed Ollama AI servers across ~130 countries, many misconfigured without authentication despite running local LLM infrastructure. Nearly half allow tool-calling, expanding the attack surface, and are now being actively exploited for abuse like resource hijacking and LLMjacking.

The compromise stems from misconfiguration of AI servers.

No specific personal or proprietary data was reported as directly exfiltrated.

Exposed AI hosts can be hijacked for spam, malware, or cryptocurrency mining at the owner’s expense. Tool-enabled endpoints further expand the attack surface by allowing command execution and access to external systems, while unsecured hosts risk being used for harmful activity, creating potential legal and reputational fallout.

A threat actor tracked by Google as UNC6395 used OAuth tokens stolen from the Salesloft Drift integration to reach the Salesforce instances of hundreds of organizations and pull data at scale. The attacker then combed the stolen records for more secrets, specifically AWS access keys, Snowflake tokens, and passwords, to enable further compromise, and deleted its query jobs to cover its tracks. Salesloft, Salesforce, and Google revoked all active Drift tokens, and a follow-up disclosure widened the scope to Drift Email tokens tied to Google Workspace. Confirmed victims included security vendors such as Cloudflare, Palo Alto Networks, and Zscaler.

Google's initial assessment referenced more than 700 potentially affected organizations. Confirmed victims included Cloudflare, Palo Alto Networks, and Zscaler.

Salesforce records including accounts, contacts, cases, and opportunities, reached with stolen OAuth access and refresh tokens.

Organizations that never touched the attacker still lost sensitive CRM and support data because one trusted integration's tokens were stolen, and the attacker mined that data for still more secrets. OAuth tokens are standing credentials that skip MFA, so third-party app tokens need least-privilege scoping, monitoring, and fast revocation.

An attacker submitted a pull request to the open-source repository behind Amazon's Q Developer extension for VS Code and gained enough repository access to commit a malicious prompt. The prompt, bundled into version 1.84.0 and published to the marketplace, instructed the AI agent to wipe local files and delete AWS resources through the CLI. The code reached an extension with more than 964,000 installs but failed to run because of a formatting error, and AWS confirmed no customer resources were affected. AWS revoked the exposed credentials, pulled the code, and shipped a clean version about a week later.

Undisclosed. The affected extension had been installed more than 964,000 times.

No data was exfiltrated. An attacker used repository access to inject a destructive prompt into a widely distributed AI coding extension.

Had the payload executed, it could have deleted developers' local files and torn down AWS resources, but the formatting error meant no environments were harmed. AI coding assistants run with real privileges, so the repository tokens and credentials behind them need least-privilege scoping and tight review.

A security researcher flagged that an xAI employee had committed a private x.ai API key to a public GitHub repository. GitGuardian's scanners caught the key and alerted the employee in early March 2025, but it stayed valid until xAI's security team was told at the end of April, roughly two months later. During that window the key granted access to at least 60 private and unreleased large language models, including development versions of Grok reportedly tuned on internal SpaceX, Tesla, and X data. No misuse was confirmed, but a single hardcoded credential sat live long after a scanner had already found it.

Undisclosed. One employee's key granted access to at least 60 private and fine-tuned language models.

A private x.ai API key that unlocked internal and unreleased large language models, some reportedly tuned on SpaceX, Tesla, and X data.

No customer data breach was confirmed, but the key gave two months of standing access to proprietary models that could have been copied, abused, or probed. Detection is only half the job; a leaked key has to be revoked the moment it is found, which is what scanning paired with fast rotation is for.

A supply chain attack compromised the GitHub Actions tool 'tj-actions/changed-files', redirecting version tags to malicious code. Organizations have been advised to immediately rotate credentials as a precautionary measure.

23,000 organizations

Credentials such as AWS access keys, GitHub Personal Access Tokens (PATs), npm tokens, and private RSA keys.

Potential unauthorized access to their sensitive data.

Wiz Research found a DeepSeek ClickHouse database sitting on the open internet with no authentication in front of it. It held more than a million log lines, including plaintext chat history, API keys, and backend service details, and the open HTTP interface let anyone run arbitrary SQL against it. DeepSeek locked it down after Wiz reported the exposure, but for a window the keys and conversations were readable by anyone who found the port. Shipping an AI product quickly does not remove the basics: a database holding secrets should never be reachable without authentication.

Undisclosed. The exposed log stream alone held more than a million entries.

A publicly reachable ClickHouse database with no authentication, exposing plaintext chat history, API keys, and backend operational metadata.

Anyone who located the open ports could read live user conversations and pull the API keys stored alongside them, and could have escalated to broader control of DeepSeek's systems. Keeping credentials out of logs and behind authenticated, access-controlled storage is what stops a single misconfiguration from turning into full exposure.

Research by CloudSEK found more than 30,000 public Postman workspaces leaking sensitive data. Developers had hardcoded secrets directly into public API collections and environments, including access and refresh tokens, third-party API keys, credentials, and session secrets. The exposure spanned major services, with thousands of leaked instances each for GitHub, Slack, and Salesforce. This was not one company being breached; it was systemic, self-inflicted exposure caused by workspaces left public and secrets left in the clear.

More than 30,000 public workspaces, belonging to organizations across healthcare, finance, SaaS, and consumer sectors.

Hardcoded access and refresh tokens, third-party API keys, credentials, and session secrets embedded in public API collections.

Any live key could let an attacker impersonate an app, drain a paid API account, or pivot into a connected system, often without the owning team realizing a testing tool had become the leak. API testing platforms are a real secrets-sprawl surface, so keep workspaces private, use environment variables and a vault instead of hardcoding, and scan public collections for keys.

In late 2024, a Chinese state-sponsored hacking group (APT) carried out a supply-chain attack by exploiting a stolen API key from BeyondTrust’s Remote Support service. BeyondTrust is a vendor that provides remote tech support tools to organizations, including the U.S. Treasury Department. On December 8, 2024, BeyondTrust notified the Treasury that attackers had obtained an API key used to secure its cloud-based remote support portal for Treasury Department employees. With this key, the threat actor was able to bypass security controls in the support service, effectively gaining remote access to certain Treasury user workstations and the data on them.

Treasury Department employees affected

Unclassified documents maintained by Treasury Departmental Offices users. Sensitive law enforcement information. Materials related to investigations conducted by the Committee on Foreign Investment in the U.S.

For the U.S. Treasury, the incident was a serious security breach: attackers remotely accessed employee computers, which could undermine trust in IT support channels and potentially expose sensitive information.

An attacker accessed the Internet Archive's Zendesk support system using a stolen API token and sent messages warning that data had been exposed. The token was reachable because an exposed GitLab configuration file on a development server had held authentication credentials since at least December 2022. The token had access to more than 800,000 support tickets going back to 2018, some containing identity documents that users had uploaded to request page removals. The organization had reportedly not rotated the exposed credentials despite earlier warnings, and this was its third security incident that month.

Undisclosed. The stolen token had access to more than 800,000 support tickets dating back to 2018.

Support tickets including personal identity documents, reached through an API token exposed in a GitLab configuration file.

Anyone who had ever emailed support, including people who submitted ID to request page removals, risked exposure of their messages and documents. A leaked credential is only half the failure; leaving it unrotated after being warned is what turned a known risk into a breach.

Slack, the workplace messaging platform, experienced a security incident over the 2022 holiday period when a limited number of employee tokens were stolen and misused to access the company’s externally hosted GitHub code repositories. On December 27, 2022, a threat actor used these leaked credentials to download some private Slack source code. Fortunately, no customer data or Slack’s primary codebase was accessed, and the breach did not stem from a vulnerability in Slack itself. Slack quickly invalidated the compromised tokens and rotated other secrets as a precaution.

NA

Private Slack source code.

No direct impact on customers or end-user data.

An attacker used an exposed GitHub authentication token to reach the New York Times' repositories and download internal data. The Times confirmed a credential to a third-party code platform had been inadvertently made available, and said there was no sign of access to its own internal systems. In June 2024 the archive surfaced publicly, around 273GB across roughly 5,000 repositories, including source code and internal tooling. A note posted with the leak said the exposed token was how the data was taken.

Undisclosed. No reader or subscriber accounts were reported compromised.

Roughly 273GB of internal data across about 5,000 repositories, including source code and IT documentation, reached through an exposed GitHub token.

The damage landed on internal intellectual property and tooling rather than reader accounts, though leaked infrastructure code and any embedded secrets create follow-on risk. A single over-privileged, long-lived repo token can expose an entire codebase, so source-platform tokens should be scoped tightly, kept short, and watched.

Hugging Face detected unauthorized access to its Spaces platform and disclosed that a subset of Spaces secrets, meaning the authentication tokens and API keys developers store for their hosted AI apps, could have been accessed. The company revoked affected tokens, emailed impacted users, and pushed everyone toward fine-grained access tokens. In response it rolled out a key management service for Spaces secrets, removed org-wide tokens to improve traceability, and improved detection of leaked credentials. The remediation reads like a secrets-hygiene checklist because the stolen assets were the credentials themselves.

Undisclosed. A subset of Spaces secrets could have been accessed.

Authentication tokens and API keys that developers stored so their hosted AI apps could reach other services.

Exposed tokens could let an attacker impersonate users, reach private models and datasets, or push malicious changes, so affected users had to rotate everything the tokens protected. Fine-grained, short-lived, rotatable tokens limit how much a single stolen credential can reach.

Through 2024 a financially motivated group tracked as UNC5537 broke into a string of Snowflake customer accounts using logins that infostealer malware had swiped from employees, some of them years earlier. Mandiant found the abused accounts shared three gaps: no multi-factor authentication, credentials that were never rotated, and no network allow-listing. The platform itself was not breached; the accounts were. Roughly 165 organizations were flagged as potentially exposed, and victims including Ticketmaster, AT&T, and Santander were later extorted or had data leaked.

Around 165 organizations were notified as potentially exposed. Downstream victims included Ticketmaster, AT&T, and Santander.

Customer data held in Snowflake cloud instances, including personal, contact, and transaction records, exfiltrated with valid stolen logins.

Hundreds of millions of people had personal and transactional data exposed and monetized through extortion, feeding downstream fraud and phishing. A password stolen from a laptop years ago should not still open a data warehouse, which is why MFA, rotation, and allow-listing matter on every account.

CISA issued an advisory urging every Sisense customer to reset any credential or secret they had ever shared with the analytics vendor, an unusually broad warning that signaled real supply-chain risk. Reporting by Krebs on Security traced the breach to a Sisense-hosted GitLab repository that held credentials to the company's Amazon S3 storage. From there, attackers reportedly pulled terabytes of data, including millions of access tokens, email passwords, and SSL certificates. Because Sisense plugs into its customers' own data systems, the exposed secrets reached well beyond Sisense itself.

Undisclosed. Sisense serves more than a thousand customers across finance, healthcare, telecom, and other sectors.

Reportedly millions of access tokens, email passwords, and SSL certificates, reached through hardcoded credentials in a Git repository.

Any credential a customer had shared with Sisense had to be treated as compromised and rotated, from Active Directory and Git to SSO secrets, database logins, and API keys. Secrets that cross a vendor boundary need an inventory, short lifetimes, and a fast way to revoke them.

Dropbox disclosed that its electronic signature subsidiary, Dropbox Sign (formerly HelloSign), was breached in April 2024. Attackers compromised a service account in the Dropbox Sign production environment, which is a non-human account used for automated backend tasks. Using this account’s credentials, the intruders gained admin-level access to Dropbox Sign’s production systems, including its customer database. As a result, they were able to access a variety of user data and secrets. Specifically, the attackers retrieved Dropbox Sign customer account information, including authentication data such as API keys, OAuth access tokens, and MFA setup info.

All Dropbox Sign (formerly HelloSign) customers

Customer information like email addresses, usernames, phone numbers (in some cases), hashed passwords, and important authentication details like API keys and OAuth tokens were accessed.

Users were required to take multiple security actions. Dropbox invalidated all exposed passwords and session tokens, forcing password resets for affected accounts. They also restricted the functionality of exposed API keys and OAuth tokens until customers could rotate them.

A third-party breach exposed API keys used by OpenSea, a major NFT marketplace. The breach highlighted the cyber risks posed by external service providers and the importance of securing API keys.

Unknown.

API keys with various permissions, potentially affecting account management and authentication processes.

The exposure of API keys could lead to unauthorized transactions and account manipulations. OpenSea initiated a rotation of API keys and urged users to secure their accounts.

The Russian state-sponsored group Midnight Blizzard, also tracked as APT29, ran a slow password-spray attack against a legacy test account that had no multi-factor authentication. From there it abused a legacy OAuth application with high permissions, created more malicious OAuth apps, and granted itself access to read corporate mailboxes. A later update revealed the attacker used information from those emails to reach source-code repositories, and accessed secrets that customers had shared with Microsoft over email. Microsoft found no evidence its customer-facing production systems were compromised.

Undisclosed. Microsoft described access to a very small percentage of corporate email accounts, including senior leadership.

Corporate email and attached documents, some source-code repositories, and credentials that customers had shared with Microsoft in email.

Customers whose secrets were sitting in emails to Microsoft support faced exposure of those very credentials and had to rotate them. Enforce MFA on every account including legacy and test ones, retire dormant accounts and over-privileged OAuth apps, and keep plaintext secrets out of email and ticketing systems.

Attackers used one access token and three service-account credentials that had been stolen in Okta's October 2023 support breach and that Cloudflare had not rotated. Starting in mid-November, they reached Cloudflare's self-hosted Atlassian environment, established persistent access around Thanksgiving, and browsed Confluence, Jira, and Bitbucket, viewing some source code before being evicted. Cloudflare rotated more than 5,000 production credentials, triaged nearly 4,900 systems, and reimaged its Atlassian servers. The company said no customer data or systems were affected.

Cloudflare itself. No customer data, systems, or network configuration were affected.

Internal Atlassian tools (Confluence, Jira, Bitbucket) and a limited amount of source code, reached with one access token and three service-account credentials.

No customers were harmed, but the intrusion succeeded only because credentials leaked in an upstream vendor breach were never rotated. Credentials exposed anywhere in the supply chain should be treated as compromised and rotated right away.

Identity provider Okta revealed that a threat actor gained unauthorized access to its customer support case management system by exploiting leaked credentials for a support service account. An Okta employee had inadvertently saved the support account’s username and password in their personal Google Chrome profile, which was likely compromised, exposing the credentials. Between late September and October 17, 2023, the attacker used these credentials to access files from support tickets of 134 Okta customers. Some of these files included HTTP Archive (HAR) logs containing session cookies/session tokens.

134 customers

The hacker used stolen session tokens to hijack five customers’ active Okta sessions, impersonating those users in their own Okta orgs.

For the five affected customer organizations, the attacker’s use of session tokens could have led to unauthorized access to those organizations’ Okta tenant data. Okta worked with those customers to revoke compromised sessions and cookies. Beyond those cases, other customers whose support files were accessed were advised to review what was in those uploads (e.g., scrub HAR logs) and to monitor for any misuse.

Researchers from Wiz discovered that Microsoft’s AI research team had accidentally exposed an overly-permissive Azure Shared Access Signature (SAS) token in a GitHub repository. This single leaked storage access key granted full control over an entire Azure Storage account, exposing 38 TB of private data that Microsoft did not intend to share. The trove included a disk backup of two employees’ workstations containing sensitive secrets, private keys, passwords, and over 30,000 internal Microsoft Teams messages from 359 Microsoft employees. The leak was an internal exposure (not a result of an outside attack) caused by a misconfigured token that allowed access beyond the specific AI training data it was meant to share. Microsoft was alerted to the issue on June 22, 2023, and promptly revoked the SAS token to secure the data.

Limited / Internal exposure

38 TB of private data that Microsoft did not intend to share.

NA

CircleCI, a popular CI/CD platform, suffered a major breach caused by an infostealer malware on an engineer’s laptop. The malware stole a 2FA-backed SSO session cookie, allowing the attacker to impersonate the employee and access CircleCI’s internal production systems. Using this access, the hacker generated new tokens and exfiltrated sensitive data from some of CircleCI’s databases, including customers’ environment variables, API keys, and tokens. Although the stolen data was encrypted at rest, the attacker even grabbed encryption keys from memory to decrypt the stolen secrets. CircleCI disclosed the incident on January 4, 2023, urging all customers to rotate any secrets stored in the platform.

Undisclosed / Potentially All

Customers’ security was at risk because the stolen API keys and tokens could be used to access those customers’ systems.

CircleCI required users to rotate all secrets (SSH keys, API tokens, OAuth tokens, etc.) that were in CircleCI. "Fewer than 5” customers reported unauthorized access to their systems as a result of the stolen tokens.

Toyota disclosed that part of its T-Connect website source code had been posted to a public GitHub repository by a subcontractor, where it stayed accessible for nearly five years. The source code contained a hardcoded access key to a data server holding customer records. Up to 296,019 customers may have had their email addresses and management numbers exposed. Toyota restricted the repository and rotated the key in September 2022, and said it could not confirm or rule out that anyone else had accessed the data.

Up to 296,019 T-Connect customers registered between December 2017 and September 2022.

Customer email addresses and management numbers, exposed through a hardcoded server access key committed to public source code.

Affected drivers faced a higher risk of phishing and targeted spam, and Toyota could not say for certain whether anyone had used the exposed key. Secrets embedded in code can sit public for years unnoticed, which is why credentials belong in a managed store and repositories need continuous scanning.