Static API key abuse

How it works

An API key is a static secret string that authenticates a caller, service, or automation to an API. It works on the first try, needs no library or protocol negotiation, and requires nothing beyond copying a value into a header or config file, which is exactly why it persists across the industry despite being the weakest common credential type. A static key does not expire on its own, does not rotate automatically, and does not distinguish between the workflow it was issued to and any other holder of the same string. Whoever presents it is treated as the identity it represents, indefinitely, until someone manually revokes it.

GitGuardian's August 2026 research on n8n illustrates the abuse path end to end. Researchers found 4,576 unique n8n API tokens exposed in public GitHub commits across 1,255 hostnames, and of 896 reachable instances they tested, 321 accepted at least one leaked token, about 36 percent. With a working token, an attacker had read access to workflow definitions, stored credentials, and data tables, and could invoke a stored credential such as a connected service's key without ever needing to see its value, by building a workflow that used the credential to call an endpoint of the attacker's choosing.

Why it works

The control assumption that fails is that possession of the key string is equivalent to authorization to use it. Nothing about a static API key ties it to a specific caller, location, or time window; it is a bearer credential in the same sense a session cookie is, and whoever holds the string is the authenticated party with no further check. A second assumption that fails is that read-only access implies limited blast radius. An automation platform's API is not a passive data store, it is a workflow engine, so read access to it is really access to trigger any action the platform's connected credentials can perform, which is broader than the API surface suggests on its face.

How to detect it

• API usage from an IP range, geography, or client that has never been associated with the key's issuing workflow, with no corresponding change to the workflow's actual deployment.
• A key that has been dormant for a normal operating pattern suddenly generating a burst of calls to endpoints it has never called before.
• Automation platform activity invoking a stored credential to reach an external destination outside the set the workflow was built to call.

Be honest about the limits: legitimate automation traffic is bursty, comes from cloud provider IP ranges that rotate and get reused by many tenants, and often calls new endpoints as workflows are updated by their actual owners. A single anomalous call is not proof of key theft, and this needs a behavioral baseline for the specific workflow rather than a static allowlist to be useful.

How to stop it

• Replace static API keys with short-lived, workload-issued credentials wherever the platform supports it, so a leaked value has a limited window of usefulness rather than none.
• Keep API keys out of repositories and config files entirely, using a vault with runtime injection instead of a value pasted into source.
• Scope every key to the minimum set of actions and resources it needs, so a leaked key exposes less even before rotation.
• Rotate on a schedule you actually verify and rotate immediately on any suspected exposure, including every downstream credential a compromised orchestrator token could reach.
• Give every key an owner and an expiry, and put automation platform credentials into the same access review process used for human accounts. See non-human identity and workload identity.

Seen in the wild

• GitGuardian found 4,576 leaked n8n tokens, and a third of reachable instances accepted them

Sources

• MITRE ATT&CK T1078.004: Valid Accounts: Cloud Accounts
• API key, glossary