CVE-2026-55485 in Piccolo Admin
Summary
by MITRE • 08/28/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in Piccolo Admin prior to version 1.14.0 represents a critical authentication bypass and privilege escalation flaw rooted in improper access control mechanisms and sensitive data exposure within the application's session management architecture. The core issue stems from an asymmetry in how HTTP methods are handled by the admin interface endpoints versus how user credentials are stored and exposed through the API layer. Specifically, while the piccolo_admin/endpoints.py module correctly implements superuser_validators to restrict write operations such as PUT, PATCH, DELETE, and POST for non-superusers, it fails to apply equivalent restrictions to read operations like GET requests targeting configured user and session tables. This oversight allows any authenticated administrator with standard privileges to query sensitive database records that should be restricted based on their role level.
The technical flaw is further exacerbated by the implementation in piccolo_api/session_auth/tables.py, where the SessionsBase.token column is not marked as secret or protected from serialization. In typical web application security models, session tokens are considered highly sensitive credentials because they serve as proof of identity for an active user session. By exposing this token field directly through API endpoints without adequate masking or access controls, the system inadvertently provides a mechanism for credential theft. When combined with the unrestricted GET requests to the sessions table, this creates a direct path for attackers to harvest valid authentication tokens from other users within the same deployment environment.
The operational impact of this vulnerability is severe, enabling non-superuser administrators to perform session hijacking and privilege escalation attacks against superusers. An attacker can exploit the exposed API by issuing GET requests to /api/tables/sessions/, retrieving live session tokens associated with active superuser sessions. By extracting these tokens, the attacker can then replay them as Cookie id values in subsequent HTTP requests. This allows the attacker to impersonate a legitimate superuser without needing valid credentials for that account. Once authenticated as a superuser through token replay, the attacker gains full administrative control over the application. The most dangerous aspect of this exploit is the ability to permanently modify the attacker's own user record by setting the superuser flag to true. This effectively grants persistent elevated privileges, allowing continued access even if the original stolen session expires or is invalidated.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-522 Insufficiently Protected Credentials from the Common Weakness Enumeration standards. The failure to restrict read access based on user role constitutes a classic authorization bypass, while the exposure of plaintext session tokens violates fundamental principles of credential protection. From an ATT&CK perspective, this behavior maps to T1078 Valid Accounts and specifically T1528 Steal Application Access Token, as well as T1098 Account Manipulation due to the modification of user attributes to escalate privileges. The attack chain demonstrates how a combination of information disclosure and improper access control can lead to complete system compromise in administrative interfaces.
Mitigation for this vulnerability requires immediate updates to Piccolo Admin version 1.14.0 or later, where these issues have been addressed by developers. For organizations unable to upgrade immediately, temporary mitigations should include restricting API endpoint permissions at the network or reverse proxy level to prevent non-superusers from accessing session-related endpoints. Additionally, implementing strict role-based access control checks on all GET requests targeting sensitive tables is essential. Developers must ensure that any field containing secrets, such as tokens or passwords, is explicitly marked as secret in database models and excluded from API responses unless absolutely necessary for specific operational functions. Regular security audits of admin interfaces should also verify that read operations are subject to the same privilege checks as write operations to prevent similar access control bypasses in future versions.