# Read-only application can publish/delete fleets

Fleet API endpoints /fleets/v1/create and /fleets/v1/delete lacked OAuth scope checks, letting read-only third-party apps publish and delete fleets.

- Payout: hidden
- Severity: medium
- Program: X / xAI
- Found by: ryotak
- Disclosed: 2021-01-04
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/1032468
- Library page: https://bugbountylibrary.com/r/h1%3A1032468
- Tags: area:mobile domain:api domain:mobile kind:bounty platform:hackerone sev:medium tech:oauth tech:rest technique:reverse-engineering technique:source-review vuln:access-control vuln:auth-bypass vuln:privilege-escalation

**Target:** Twitter Fleet REST API (api.twitter.com /fleets/v1/*)
**Root cause:** The new Fleet endpoints did not enforce the application's write permission, unlike standard v1.1 endpoints which reject read-only apps before processing.
**Steps:**
1. Install twurl and authenticate with an OAuth app granted only read permission.
2. Send `twurl /fleets/v1/create -X POST --header 'Content-Type: application/json' -d '{"text":"Hey yo"}'`.
3. Observe a fleet is created despite read-only scope; same for `/fleets/v1/delete`.
**How found:** Researcher decompiled the updated Twitter for Android APK (apktool/dex2jar/CFR), grepped for 'fleet' to find /fleets/v1/user_fleets, enumerated sibling endpoints, then while validating API docs noticed a fleet was created with a read-only app and compared against /1.1/statuses/update.json which correctly errors 'Read-only application cannot POST.'
**Exploitation:** Any third-party app with read-only tokens could POST to /fleets/v1/create to publish fleets or /fleets/v1/delete to remove them, bypassing the write-permission gate that standard endpoints enforce.
**Insight:** When a vendor ships a new feature, decompile the client to enumerate its endpoints and test each against a low-privilege token; new endpoints often skip the centralized scope-check middleware that older endpoints inherit.