Listen to this Post
The vulnerability is a classic race condition within the Pterodactyl Panel’s resource creation logic (e.g., for databases, backups). When a user requests a new resource, the application first checks if the server’s configured resource limit has been reached. This check (SELECT COUNT() FROM resources WHERE server_id = X) occurs early in the request cycle without implementing a mutex lock or database transaction with sufficient isolation on the server’s resource count. A malicious actor can exploit this by sending a high-volume burst of concurrent `POST` requests to the creation endpoint (e.g., /api/client/servers/<uuid>/databases). Each request independently passes the initial limit check because they all read the same, not-yet-updated count from the database. Subsequently, each request proceeds to insert a new resource record (INSERT INTO resources ...), thereby exceeding the administrative quota. This lack of atomic “check-and-create” logic allows the limit to be bypassed entirely through concurrent execution.
Platform: Pterodactyl Panel
Version: < 1.11.6
Vulnerability : Race Condition
Severity: Critical
date: 2023-10-11
Prediction: 2023-11-01
What Undercode Say:
Concurrent request simulation
seq 1 50 | xargs -n1 -P50 -I {} curl -X POST -H "Authorization: Bearer $CLIENT_API_KEY" https://panel.host.example/api/client/servers/$SERVER_UUID/databases -d '{"database": "db_{}", "remote": "%"}'
Resource exhaustion check
curl -H "Authorization: Bearer $ADMIN_API_KEY" https://panel.host.example/api/application/servers/$SERVER_UUID | jq '.attributes.limits.database'
Example vulnerable code logic (simplified)
1. CHECK: current_count = Resource.where(server_id: server_id).count
2. IF current_count < server.limit
3. THEN Resource.create(server_id: server_id, ...) RACE WINDOW
How Exploit:
1. Acquire client API key.
2. Identify target server UUID.
3. Craft requests for resource creation (database/backup/port).
- Use tooling (e.g.,
httpx, custom script) to flood endpoint with concurrent requests. - Verify bypass by checking created resource count exceeds limit.
Protection from this CVE:
- Implement pessimistic locking (
SELECT FOR UPDATE) on the server record during the check-and-create transaction. - Use database-level unique constraints or atomic increment checks.
- Apply distributed rate-limiting per server at the proxy/application layer.
- Upgrade to patched version (e.g., v1.11.6+).
Impact:
- Resource Exhaustion (Node/Backup)
- Denial of Service
- Quota Bypass
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
