GHSA-2gh4-jmwq-rr8w

Описание

Summary

piccolo_admin uses a helper called superuser_validators to gate access to the user and session tables for non-superusers. The helper rejects PUT, PATCH, DELETE, and POST, but does not reject GET.

The sessions table stores live session tokens in plaintext, and the token column is not marked secret=True, so it is included in every GET response. Any non-superuser admin can therefore list every other user's live session token with one request, replay the token as their own Cookie: id=…, impersonate that user (including the superuser), and then permanently self-promote by writing superuser = true on their own row.

The chain is reachable on a realistic, documented configuration: a deployer adds the Sessions (and User) tables to create_admin([...]) so superusers have a UI to monitor and revoke sessions.

Affected component

• File: piccolo_admin/endpoints.py
• Function: superuser_validators (around line 419)

The method check is a deny-list instead of an allow-list; GET is absent. Compounding the issue, SessionsBase.token in piccolo_api/session_auth/tables.py is a Varchar without secret=True, so the default exclude_secrets=True in PiccoloCRUD does not strip it.

Preconditions

1. Network reachability to the admin.
2. Valid credentials for a non-superuser admin (admin=True, superuser=False — the default role created by BaseUser.create_user(admin=True)).
3. The deployment includes the Sessions table (and typically the User table) in create_admin([...]) — the documented pattern for "active sessions" management UIs.

Steps to reproduce

1. Log in as the non-superuser admin (john / john123). Open the Piccolo User table and confirm john's SUPERUSER column is ✗. (See Screenshot 1.)

   

2. Attempt the target write directly. Send the following request:

   PATCH /api/tables/piccolo_user/2/ HTTP/1.1 Host: target:8001 Content-Type: application/json Cookie: id=<john's session>; csrftoken=<token> X-CSRFToken: <token> {"superuser": true}

   The server returns:

   HTTP/1.1 405 {"detail":"Only superusers can perform these actions."}

   The same response is shown both in the dashboard banner (Screenshot 2) and in Burp Repeater (Screenshot 3). This establishes the privilege boundary that the bug will break.

   

3. Leak the credential. As the same john user, request:

   GET /api/tables/sessions/ HTTP/1.1 Host: target:8001 Cookie: id=<john's session>; csrftoken=<token>

   Response: 200 OK containing every active session in plaintext, e.g.

   {"rows":[ {"token":"jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE","user_id":1, ...}, {"token":"...","user_id":2, ...}, ... ]}

   Copy the token value of any row whose user_id matches the superuser. That string IS the live session cookie of that user. (Screenshot 4.)

   

4. Replay the step-2 PATCH with the stolen cookie. Send the exact same request as step 2, changing only the Cookie: id= value to the stolen token:

   PATCH /api/tables/piccolo_user/2/ HTTP/1.1 Host: target:8001 Content-Type: application/json Cookie: id=jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE; csrftoken=<token> X-CSRFToken: <token> {"superuser": true}

   Response: 200 OK, body shows "superuser": true for john. (Screenshot 5.)

   

5. Verify persistence. Log in fresh as john / john123 (no stolen cookie). John is now a superuser. The stolen cookie is no longer needed — the elevation is permanent on john's own row.

Impact

Full superuser takeover of the admin from any non-superuser admin account. The promoted attacker can:

• read/write/delete any row in any table the admin exposes;
• revoke any other session, locking out other admins;
• change any user's password;
• export data (including via the bulk CSV download forms);
• plant payloads (e.g. CSV-formula injections) that fire when higher-trust operators open exports.

Persistence is automatic — once the attacker writes superuser=true on their own row in step 4, the stolen cookie can be discarded.

Suggested fix

Primary (single-line): make superuser_validators reject all requests from non-superusers — there is no legitimate non-superuser use case for the user or session tables in this context:

Defence in depth: in piccolo_api/session_auth/tables.py, mark SessionsBase.token with secret=True. The existing exclude_secrets=True default on PiccoloCRUD then strips the field from every response, closing the leak even if the validator is later misconfigured by a downstream consumer.

Severity

CVSS 3.1: 8.8 HIGH — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Reasoning:

• AV:N — accessible over the network.
• AC:L — single GET; no race or timing dependency.
• PR:L — requires non-superuser admin credentials (the default admin role).
• UI:N — no victim interaction needed.
• S:U — scope kept Unchanged to be conservative; some auditors may prefer S:C (which yields 9.9 Critical) because crossing from admin to superuser breaks an explicit, named privilege gate.
• C:H / I:H / A:H — full read, full write, full availability impact on the admin's data and on other users' sessions.

Weaknesses

• CWE-269 Improper Privilege Management (primary)
• CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
• CWE-863 Incorrect Authorization

Notes for the maintainer

• The vulnerability is reachable on any version where superuser_validators uses a method deny-list and SessionsBase.token is not secret=True. I tested against piccolo_admin 1.13.0 + piccolo_api 1.9.0.
• The shipped admin_demo does not expose the Sessions table, so the bug is not reproducible against the demo as-shipped. The PoC harness used a minimal create_admin([..., TableConfig(User), TableConfig(Sessions)], auth_table=User, session_table=Sessions) configuration, which mirrors the documented "Sessions admin view" pattern.
• I'm happy to coordinate disclosure timing and validate any candidate patch.