# Abusing internal API to achieve IDOR in New Relic

IDOR in New Relic's internal_api v1 endpoint let any authenticated user read incidents, events, settings and messages from any other account by enumerating sequential account numbers.

- Payout: $1,000
- Severity: high
- Program: New Relic
- Found by: Jon Bottarini (@jon_bottarini)
- Disclosed: 2018-01-02
- Write-up quality: 6/10
- Original: https://www.jonbottarini.com/2018/01/02/abusing-internal-api-to-achieve-idor-in-new-relic/
- Library page: https://bugbountylibrary.com/r/blog%3Ajonbottarini-com-2018-01-02-abusing-internal-api-to-achieve-idor-in-new-relic
- Tags: area:web domain:api domain:web impact:data-leak kind:bounty platform:blog sev:high technique:js-analysis technique:recon vuln:access-control vuln:idor

**Target:** Internal REST API endpoint /internal_api/1/accounts/{ACCOUNT NUMBER}/incidents on alerts.newrelic.com
**Root cause:** The internal API GET endpoint did not verify that the account number in the request path matched the authenticated user's own account number, so any authenticated user could request arbitrary account IDs.
**Steps:**
1. Authenticate to alerts.newrelic.com with a standard user account.
2. Send `GET https://alerts.newrelic.com/internal_api/1/accounts/{ACCOUNT NUMBER}/incidents` with your session.
3. Replace {ACCOUNT NUMBER} with another account's number (sequential, +1 per new account) and observe the response.
4. Enumerate account numbers (e.g. Burp Intruder incrementing by one) to harvest data across accounts.
**How found:** Author was already familiar with New Relic's setup, tested the public REST API for IDOR by swapping application_id between victim/attacker accounts (dead end), then noticed references to an /internal_api/ endpoint in .js files. The bug was missed for a long time because there are two subdomains (infrastructure/alerts) and multiple internal_api versions; only v1 on alerts.newrelic.com was vulnerable.
**Exploitation:** With a valid session, the attacker iterates the account number in the internal_api v1 path and reads each account's incidents, events, messages, violations, policy summaries, infrastructure events/filters and account settings. Sequential account IDs make full enumeration trivial.
**Insight:** When a public API is hardened against IDOR, pivot to internal APIs referenced in JS bundles; check every subdomain and every API version separately, since fixes and vulns often differ per version.

## Proof of concept (copied exactly from the original report)

**IDOR request to internal_api incidents endpoint**

```
https://alerts.newrelic.com/internal_api/1/accounts/{ACCOUNT NUMBER}/incidents
```