A New Relic user API key lets whoever holds it act as the user who created it. It can query your account through the NerdGraph API, read entity and log data, and run changes that the user is allowed to make, such as editing dashboards, alert conditions and synthetic monitors. The key carries the permissions of its owner, so an administrator’s key is a far larger risk than a read-only one. Revoke the key first, then check what it was used to read or change.
Check your GitHub account for leaked secrets — free
- Provider
- New Relic
- Severity
- High
- Impact
- SaaS account access and billing
- Checked live by LeakWatch
- No
What a New Relic User API Key looks like
A New Relic user API key starts with NRAK-, followed by 27 letters and digits. The masked shape looks like this:
NRAK-…XXXX New Relic user API key (masked)
New Relic shows the full key only once, when it is created. Afterwards the interface displays only the first few characters, which is enough to find the key in the list but not to copy it. The NRAK- prefix is the same for every user key, so the value alone identifies its type. Its meaning comes from the context: the variable name or the line it appears on, such as NEW_RELIC_API_KEY or newrelic_user_key, usually makes clear what it is for.
Other New Relic keys look similar but do different jobs. License keys are used by agents to send data, and ingest keys are used to send events and metrics. They are not user keys, and each is revoked in its own place. Check which one leaked, because a user key can read and change far more than an ingest key.
How New Relic User API Keys get leaked
- Agent and exporter configuration. A
newrelic.yml, a Helm values file or a Docker environment file that holds the key next to the account settings, then gets committed. - Scripts that call NerdGraph. A script that sends a request to the NerdGraph endpoint with the key in a header or a variable, then gets shared in a repository or a gist.
- Terraform providers. A provider block with the key written in plain text, pushed with the rest of the infrastructure code.
- Debug output. A log line or a verbose flag that prints request headers, including the
API-Keyheader, from a failing call. - Shared dotfiles and snippets. A key pasted into a shell profile or a chat thread so that a colleague could run the same query.
What to do in the first hour
- Delete the exposed key first. Open the API keys page in New Relic and delete the user key that leaked. Deleting ends its access at once, so do it before cleaning the repository.
- Create a replacement for the script or tool that needs one. A user key is tied to a person, so consider a key owned by a service user with a role that fits the task, rather than an administrator’s account.
- Deploy the replacement to the system that used the old key, and run a simple query to confirm it still works.
- Check the account activity. Review the audit or activity records for the user who owned the key, for the period since the exposure. Look for changes to alert conditions, notification channels and dashboards that you did not make, and for queries from unfamiliar addresses. Changes to alerting are the most useful thing to check, because an attacker who wants to stay quiet will often change them first.
- Review what the key could read. Entity and log data can contain customer details, hostnames and internal URLs. Decide what the key could reach and whether any of it needs to be reported under your own policies.
- Rotate the other keys the same team uses. If the same file held a license key or an ingest key, rotate that too, since those are separate values and remain valid after the user key is gone.
- Clean the repository and look for other credentials stored alongside the key. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at New Relic
User API keys are listed on the API keys page of the New Relic One interface. Use the account or region that owns the key, since the EU and Japan regions have their own pages. Find the key in the list by its name, then open the menu on its row and choose Delete. The list shows only the first characters of each key, so match on those, and if several keys have similar names, check the creation date. A deleted key cannot be recovered, so make sure your replacement is in place before you delete the one in use.
How LeakWatch detects it
The rule is called New Relic User API Key. It needs two things: a New Relic context word, such as new-relic, newrelic or new_relic, within a short distance before the value, and the value itself, which starts with NRAK- followed by 27 letters or digits. Both parts are matched in any letter case. Because the context word is required, a bare NRAK- value with no nearby New Relic name is not reported, which keeps false alerts down but means a key pasted on its own can be missed. The severity is high. This type is not checked live: LeakWatch does not send any request to New Relic with the key it found, so you should delete the key yourself.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone change my alerts with this key?
Yes, if the user who owns the key has the rights to do so. Check the audit records for changes to alert conditions and notification channels, because those are the changes that hide an incident.
Is a read-only key safe to leave in place?
No. A read-only key can still expose logs, hostnames and customer data. It is also easy to upgrade it later by changing the user’s role, so delete the leaked key rather than trying to judge its risk.
Does deleting the user key affect my agents?
No. Agents send data with license keys, not user keys. Deleting the user key only stops whatever used it for queries and changes, such as scripts and provider configurations.