Toyota 2023: An API Key Sat in a Public GitHub Repo for Five Years

In October 2023, Toyota Motor Corporation disclosed that a credential committed to a public GitHub repository in 2017 had remained there, undetected, for approximately five years. The exposed API key provided access to Toyota Connected’s vehicle data environment — a platform used by the company’s connected car services in Japan. The data accessible through the key included real-time and historical vehicle location information for roughly 215,000 customers.

No sophisticated attack was required. The key was in the repository the entire time. An external security researcher found it using publicly available tooling and reported it responsibly to Toyota.

What was exposed and how

Toyota Connected is the subsidiary that manages the telematics and connected services platform underpinning Toyota’s in-vehicle connectivity features. A developer working on a related project committed source code to a public repository that included a hardcoded API key — likely introduced as a convenience during development or testing, with the intent to replace it before the code went public. That replacement never happened.

The API key granted access to the Connected Services data environment, which held vehicle identification numbers (VINs), vehicle location data, and associated customer identifiers. With the key and knowledge of the API’s endpoint structure — both of which were visible in the repository — an attacker could query current and historical location data for any of the 215,000 affected vehicles.

Toyota’s disclosure stated that no evidence of malicious access was found during the investigation. But absence of evidence is not evidence of absence: without comprehensive API access logging reviewed against the exposed key, Toyota could not rule out that the key had been discovered and used quietly by other parties during the five-year window.

Why it went undetected for five years

The root cause is the absence of secret scanning at every point where it could have intervened.

At commit time, there was no pre-commit hook running a scanner like truffleHog or gitleaks against staged changes. A pre-commit check would have flagged the API key pattern before it was written to git history.

At push time, GitHub’s push protection feature — which blocks pushes containing secrets matching known patterns — was either not configured for the repository or not yet widely deployed at the time of the original commit. Push protection has since been expanded significantly and is now enabled by default on public repositories, but repositories predating its rollout may not have received retroactive scanning of existing history.

In the CI pipeline, there was no secret scanning step. Tools like truffleHog, detect-secrets, or GitHub Advanced Security’s secret scanning can be run as a pipeline stage and will fail the build if secrets are detected anywhere in the repository tree — including in prior commits.

At the API layer, access logs for the Connected Services API were apparently not reviewed for anomalous usage patterns associated with the exposed credential. A key that had been in a public repository for years and was actively queried by unexpected IP ranges would represent an anomalous access pattern — but only if access logs were being monitored.

The safe pattern: secrets never touch source control

The correct architecture removes the possibility of accidental secret exposure by ensuring credentials are never present in code at any stage.

Use AWS Secrets Manager for all credentials. Store API keys, database passwords, and service tokens in Secrets Manager. In application code, reference the secret by its ARN or name — never its value. At runtime, the application calls secretsmanager:GetSecretValue using the IAM role attached to its compute resource. The secret value is injected into memory and never written to disk, logs, or environment variable dumps.

Inject via IAM, not environment variables set at deploy time. A common pattern is to set API_KEY=xxxxx as an environment variable in a CI/CD deployment step. This moves the secret out of source code but still exposes it in CI logs, deployment manifests, and container environment dumps. The correct approach is for the application itself to fetch the secret at startup using its IAM role — no human or pipeline process needs to handle the plaintext value.

Enforce with pre-commit hooks. Add truffleHog or gitleaks to your repository’s pre-commit configuration. Both tools maintain regularly updated pattern libraries covering hundreds of known secret formats — API keys, tokens, private keys, and connection strings across all major cloud providers and SaaS platforms. A blocked commit is a low-friction intervention; a breach disclosure is not.

Enable GitHub push protection. For all repositories — public and private — enable push protection at the organization level. This adds a server-side check that blocks pushes containing detected secrets and requires an explicit bypass with a documented reason. It is the last line of defense when pre-commit hooks are absent or bypassed.

Rotate on any doubt. If a secret may have been exposed — through a public commit, a leaked CI log, or a misconfigured environment dump — rotate it immediately. In Secrets Manager, rotation can be automated and is picked up by all consumers without a code deployment. The cost of rotating an unexposed key is zero. The cost of not rotating an exposed one is potentially five years of silent access.

Takeaway

Toyota’s incident is a reminder that long-dwell exposure is the norm, not the exception, when secrets reach public repositories. The median time between a credential being committed to a public repo and its first unauthorized use has been measured in minutes by academic researchers — but detection and response lag far behind. Scanning at commit time, at push time, and in CI pipelines eliminates the exposure window entirely. Not scanning means trusting that no one will ever look — and five years of evidence suggests that trust is misplaced.