# User with limited access to Index configuration can rename the Index

After an admin downgraded a user's index permissions, the old API key still allowed a replayed `move` operation to rename the index, bypassing the revoked ACL.

- Payout: $200
- Severity: medium
- Program: Algolia
- Credited: bugs3ra
- Disclosed: 2016-06-01
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/99969
- Library page: https://bugbountylibrary.com/r/h1%3A99969
- Tags: domain:api impact:integrity kind:bounty platform:hackerone sev:medium technique:recon vuln:access-control vuln:auth-bypass vuln:privilege-escalation

**Target:** Index operation endpoint (/1/indexes/<index>/operation)
**Root cause:** Permission downgrade did not propagate to already-issued API keys; the key retained its prior ACL, so a replayed request with the old key still authorized the operation.
**Steps:**
1. Invite user, grant full access, log in as invited user, create an index.
2. As admin, remove the user's 'configure index' permission.
3. Observe config options disappear in the UI for the invited user.
4. Replay `POST /1/indexes/<index>/operation?x-algolia-api-key=<old key>&x-algolia-application-id=<app>` with body `{"operation":"move","destination":"new name"}`.
5. Reload: index is renamed despite revoked permission.
**How found:** Researcher noticed UI hid configuration options after downgrade, hypothesized the backend ACL wasn't updated, and replayed the captured request with the old key to confirm.
**Exploitation:** Attacker with a previously-issued full-access API key keeps using it after the admin downgrades their role; replaying the move operation renames the index, and the same stale key likely permits delete/add object operations.
**Insight:** When testing role/permission changes, capture requests before downgrade and replay them after — UI hiding controls is not enforcement; check whether API keys/credentials are re-scoped or invalidated on permission change.