Attack Chain

1. The attacker authenticates as a standard, non-superuser administrator (e.g., admin=True, superuser=False).
2. The attacker identifies that the Sessions table is exposed in the admin dashboard.
3. The attacker issues a GET request to /api/tables/sessions/ to retrieve the entire contents of the sessions table.
4. The server returns a 200 OK response containing plaintext session tokens for all active users, including superusers.
5. The attacker extracts a superuser's session token from the JSON response.
6. The attacker uses the stolen superuser token in a new session cookie (Cookie: id=...) to authenticate requests to the admin API.
7. The attacker sends a PATCH request to /api/tables/piccolo_user/<attacker_id>/ with the payload {"superuser": true}.
8. The server processes the request as the superuser, successfully promoting the attacker's account to superuser status.

Impact

Successful exploitation results in full administrative takeover. An attacker can access all tables, modify user credentials, revoke existing sessions, and potentially plant payloads in exported data. The elevation is permanent, as the attacker effectively modifies the database record associated with their account.

Recommendation

• Upgrade piccolo_admin and associated piccolo_api components immediately; identify the specific patched version from the vendor and apply it.
• Apply the recommended fix to superuser_validators by implementing an allow-list or a more restrictive if not request.user.user.superuser: raise HTTPException pattern to block all unauthorized access.
• Apply the defense-in-depth fix by setting secret=True on SessionsBase.token in piccolo_api/session_auth/tables.py to prevent plaintext leakage.
• Monitor web logs for GET requests to /api/tables/sessions/ originated by users without superuser status.