Description

Piccolo Admin is an admin interface and content management system for Python, built on top of Piccolo. Prior to 1.14.0, piccolo_admin/endpoints.py uses superuser_validators to block PUT, PATCH, DELETE, and POST requests by non-superusers but permits GET requests to configured user and session tables, while piccolo_api/session_auth/tables.py exposes SessionsBase.token because the token column is not secret. In deployments that add the Sessions and User tables to create_admin, a non-superuser administrator can call GET /api/tables/sessions/, obtain another user's live session token, replay it as the Cookie id value to impersonate a superuser, and permanently set superuser to true on the attacker's own row. This issue is fixed in version 1.14.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T20:18:27.657Z",
  "pubdate": "2026-08-28T20:18:27.657Z",
  "executiveSummary": "Piccolo Admin versions prior to 1.14.0 contain a critical broken access control vulnerability originating from the improper exposure of sensitive session data within the admin interface.\nThe vulnerability allows a non-superuser administrator to retrieve live session tokens belonging to other users, including superusers, by querying the underlying database tables via the administrative API.\nThis flaw stems from overly permissive read access (GET requests) allowed for user and session tables, combined with the failure to treat the 'token' field in the 'SessionsBase' table as a protected, secret attribute.\nBy extracting a legitimate superuser session token, an attacker can perform a session hijacking attack by injecting the stolen token into their own session cookies.\nThe impact is complete system compromise, as the attacker gains superuser privileges and the ability to escalate their own account permissions permanently within the database.\nExploitation requires administrative access to the Piccolo Admin panel, but does not require superuser privileges, making it a high-risk escalation path for malicious or compromised lower-privileged administrative accounts.",
  "technicalDetails": "The vulnerability resides within 'piccolo_admin/endpoints.py' and 'piccolo_api/session_auth/tables.py'. In affected versions, the 'superuser_validators' implemented in the admin endpoints correctly restrict state-changing HTTP verbs such as PUT, PATCH, DELETE, and POST to superuser roles. However, these validators do not sufficiently restrict GET requests for administrative tables, specifically those associated with user management and session tracking.\nThe root cause is a dual failure: the exposure of the 'token' column within the 'SessionsBase' table definition in 'piccolo_api/session_auth/tables.py', and the lack of restrictive validation logic for GET requests in 'piccolo_admin/endpoints.py' when the admin interface is configured to include the Sessions and User tables.\nThe attack flow proceeds as follows: First, an authenticated, non-superuser administrator accesses the administrative dashboard. Second, the attacker leverages the improperly secured '/api/tables/sessions/' endpoint to perform a GET request. Third, because the API does not filter the 'token' field, the response body includes the raw session tokens for all active users in the system.\nOnce the superuser's session token is acquired, the attacker performs a session hijacking attack by modifying their local browser's cookie storage, replacing their own 'id' cookie value with the stolen superuser token. Upon refreshing the dashboard, the application authenticates the attacker as the superuser.\nPost-exploitation, the attacker possesses the full authorization scope of the hijacked account. Because the attacker now has superuser privileges within the admin panel, they can navigate to their own user record and manipulate the underlying database rows to permanently set their 'superuser' flag to 'true', ensuring persistence even after the stolen session token expires or is revoked.\nThe exposure of the token column as a non-secret attribute in the 'SessionsBase' model effectively bypasses the integrity of the session authentication mechanism. This vulnerability demonstrates the risks of exposing raw session identifiers through automated CRUD API endpoints without implementing field-level security or custom serialization logic for sensitive database columns."
}