# Improper authorization on `/api/as/v1/credentials/` allows any App Search user to access all API keys and escalate privileges

App Search's /api/as/v1/credentials/ endpoint returned all API keys to any authenticated user regardless of role, enabling privilege escalation to admin keys.

- Payout: hidden
- Severity: high
- Program: Elastic
- Found by: dee-see
- Disclosed: 2021-06-02
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1168528
- Library page: https://bugbountylibrary.com/r/h1%3A1168528
- Tags: area:web domain:api domain:web impact:data-leak impact:privesc kind:bounty platform:hackerone sev:high technique:source-review vuln:access-control vuln:auth-bypass vuln:privilege-escalation vuln:secrets-leak

**Target:** App Search REST API endpoint /api/as/v1/credentials/
**Root cause:** The credentials API endpoint lacked role-based authorization checks, unlike the UI page which correctly 404s for Analyst/Editor roles, so any authenticated user could list all API keys.
**Steps:**
1. Create a role mapping with attribute value `h1-repro` mapped to `Analyst` role with Limited Engine Access (no engines).
2. Create a user `hi-repro` in Kibana Stack Management.
3. Log in to App Search as `hi-repro`; `/as#/role-mappings/` returns 404 as expected.
4. Request `GET /api/as/v1/credentials/` and observe all API keys returned.
**How found:** Noticed the UI credentials page correctly 404s for Analyst/Editor roles, then hypothesized the underlying API endpoint might not enforce the same role check and tested it directly.
**Exploitation:** A low-privileged Analyst user queries `/api/as/v1/credentials/` to retrieve all API keys including the default Private API Key with read/write access to all engines; if a Private Admin Key exists, the attacker uses it to create or delete API keys.
**Escalation:** Use leaked Private Admin Key to mint new keys or delete existing ones, escalating to full administrative control over App Search engines.
**Insight:** When a UI page enforces a role check, test the backing API endpoint directly—front-end gating often diverges from server-side authorization on the same data.