CVE-2026-55485: 
Python Schwachstellenanalyse und -minderung

CVE-2026-55485 is a privilege escalation vulnerability in Piccolo Admin, a Python-based admin interface and CMS built on the Piccolo ORM framework. The flaw allows any non-superuser administrator to obtain live session tokens for all other users — including superusers — via an unrestricted GET request, then replay those tokens to permanently escalate their own account to superuser status. All versions of piccolo_admin prior to 1.14.0 are affected when the Sessions and User tables are exposed via create_admin(). It was disclosed on August 28, 2026, and carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory).

The root cause is a combination of CWE-863 (Incorrect Authorization), CWE-200 (Exposure of Sensitive Information), and CWE-269 (Improper Privilege Management). In piccolo_admin/endpoints.py, the superuser_validators function uses a deny-list approach, blocking only PUT, PATCH, DELETE, and POST requests from non-superusers while leaving GET requests unrestricted. Compounding this, SessionsBase.token in piccolo_api/session_auth/tables.py is defined as a plain Varchar without secret=True, so the PiccoloCRUD layer's exclude_secrets=True default does not strip it from GET responses — meaning live session tokens are returned in plaintext to any authenticated non-superuser admin. Exploitation requires only valid non-superuser admin credentials and network access to the admin interface in a deployment where the Sessions table is added to create_admin() (GitHub Advisory, piccolo_api PR #331).

Successful exploitation grants an attacker full superuser control over the Piccolo Admin instance. Once elevated, the attacker can read, write, or delete any row in any table exposed by the admin; revoke other users' sessions to lock them out; change any user's password; and export sensitive data via bulk CSV downloads. Critically, the privilege escalation is persistent — once the attacker writes superuser=true to their own row, the stolen session token is no longer needed, and the elevation survives token rotation (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. However, the attack requires only low privileges (a non-superuser admin account), no user interaction, and a single HTTP GET request, making it trivially exploitable in affected configurations. The vulnerability is only reachable in deployments that explicitly add the Sessions table to create_admin(), which is a documented but optional configuration pattern.

1. Authenticate as non-superuser admin: Log in to the Piccolo Admin interface with a valid account that has admin=True but superuser=False (the default role created by BaseUser.create_user(admin=True)), obtaining a session cookie (Cookie: id=<attacker_token>).
2. Confirm privilege boundary: Attempt a PATCH request to /api/tables/piccolo_user/<target_id>/ with {"superuser": true} to confirm the 405 error response: {"detail": "Only superusers can perform these actions."}.
3. Leak session tokens: Send a GET request to /api/tables/sessions/ using the attacker's own session cookie. The server returns a 200 OK response containing all active sessions in plaintext, including the token field for each user.
4. Identify superuser token: From the response JSON, locate the row where user_id corresponds to the superuser account and copy its token value.
5. Replay stolen token: Resend the PATCH request from step 2, replacing the Cookie: id= value with the stolen superuser token: PATCH /api/tables/piccolo_user/<attacker_id>/ ... Cookie: id=<stolen_superuser_token> with body {"superuser": true}.
6. Verify persistent escalation: Log out and log back in using the attacker's own credentials. The attacker's account now has superuser=true permanently — no stolen token is required for subsequent actions (GitHub Advisory).

• Network/Logs: Unexpected GET requests to /api/tables/sessions/ from non-superuser admin accounts, particularly if followed shortly by PATCH requests to /api/tables/piccolo_user/<id>/ with {"superuser": true} in the body.
• Logs: Admin access logs showing a PATCH request to the user table that returns HTTP 200 with "superuser": true, preceded by a GET to the sessions endpoint from the same or a different session cookie.
• Database: Unexpected changes to the superuser column in the piccolo_user table for accounts that were not previously superusers; audit any rows where superuser was recently set to true.
• Session Activity: A session cookie appearing in requests for two different user accounts (the attacker's account and the impersonated superuser's account) within a short time window, indicating session token replay (GitHub Advisory).

Upgrade piccolo_admin to version 1.14.0 and piccolo_api to version 1.10.0, which fix both root causes: superuser_validators now rejects all requests (not just write methods) from non-superusers, and SessionsBase.token is marked secret=True so it is stripped from all GET responses by PiccoloCRUD (piccolo_admin 1.14.0 release, piccolo_api PR #331). As an immediate workaround for deployments that cannot upgrade, remove the Sessions and User tables from create_admin() to eliminate the attack surface. Additionally, rotate all active session tokens and audit the piccolo_user table for any unauthorized superuser=true changes (GitHub Advisory).