CVE-2026-54553: Validation Bypass in starlette-admin REST API via Unvalidated Sort and Filter Fields

The starlette-admin framework provides an administrative interface for Starlette and FastAPI applications. Within this framework, developers configure a ModelView instance mapped to database engines like SQLAlchemy, MongoEngine, Beanie, or Odmantic. The administrative panel exposes a REST API used to fetch, sort, and search list records dynamically.

To restrict data access, the framework allows administrators to define which columns are sortable, searchable, or excluded from the user interface. However, in versions prior to 0.16.1, the backend API failed to enforce these restrictions on incoming requests. This omission created an API validation bypass vector that exposes the underlying database fields directly to client manipulation.

An authenticated user with access to the list endpoint can bypass frontend controls by issuing direct HTTP GET requests with custom query parameters. By specifying fields designed to be hidden or non-sortable, attackers can bypass security rules. The impact of this flaw includes sensitive information exposure and service disruption via uncaught backend database exceptions.

The root cause of this vulnerability lies in the input validation logic within the central REST list controller. The endpoint _render_api located in starlette_admin/base.py processes list requests. It extracts order_by and where parameters from the query string and forwards them directly to the underlying model's finder methods without validating them against the view configuration.

The database adapter layers receive the raw client input and attempt to translate it directly into query structures. If a query contains a hidden column, such as a password hash or an internal flag, the adapter executes the sorting operation without verifying if the field is declared as sortable. This allows an unauthorized user to alter the result list order based on confidential properties.

Furthermore, the system does not validate that incoming keys are legitimate database fields. When a client submits special Python dunder attributes or non-existent fields, the database driver fails to resolve the properties. This failure generates uncaught exceptions within the request execution loop, leading to immediate HTTP 500 responses.

In vulnerable versions, the _render_api function reads query parameters directly and delegates them to the datastore without any verification:

# Vulnerable path in starlette-admin (pre-0.16.1)
async def _render_api(self, request: Request) -> Response:
    identity = request.path_params.get("identity")
    model = self._find_model_from_identity(identity)
    
    # Reading query parameters directly from client input
    skip = int(request.query_params.get("skip", 0))
    limit = int(request.query_params.get("limit", 100))
    order_by = request.query_params.getlist("order_by")
    where = request.query_params.get("where")
    
    # Vulnerable database query call with unvalidated arguments
    items = await model.find_all(
        request=request,
        skip=skip,
        limit=limit,
        where=where,
        order_by=order_by
    )

The patched version introduces recursive schema checking. This logic processes input structures and rejects keys that are not explicitly permitted in the current ModelView configuration. The following snippet illustrates the validation logic introduced in starlette_admin/views.py:

# Patched implementation helper methods
def _validate_order_by(self, request: Request, order_by: List[str]) -> Optional[str]:
    # Extract fields permitted on the list view
    list_field_names = {f.name for f in self._all_fields if not f.exclude_from_list}
    sortable: Set[str] = set(self.sortable_fields or [])
    
    for clause in order_by:
        parts = clause.split(maxsplit=1)
        if len(parts) < 2:
            return f"Invalid order_by clause: '{clause}'"
        field_name = parts[0]
        # Enforce that fields must be in the view and marked as sortable
        if field_name not in list_field_names or field_name not in sortable:
            return f"Unknown field or field is not sortable in order_by: '{field_name}'"
    return None

To exploit this vulnerability, an authenticated user identifies a target model view and intercepts the API communication. The attacker then constructs specific HTTP requests designed to trigger unauthorized sorting or filtering.

For a blind sorting attack, the attacker sorts a user table by a hidden field such as password_hash. By observing the order in which user records are returned across multiple requests, the attacker can systematically extract the hash values. For example, sorting the list alphabetically allows the attacker to isolate user accounts and infer character values iteratively.

To induce a Denial of Service state, the attacker targets the database driver's exception handling mechanisms. Submitting an HTTP GET request with a query payload referencing the __class__ dunder attribute causes the backend parser to crash. This uncaught exception triggers an unhandled traceback, resulting in an HTTP 500 error and resource exhaustion.

The impact of this vulnerability is classified as Medium, with a CVSS score of 5.4. While the vulnerability requires the attacker to be authenticated, the barriers to exploitation are minimal. This issue directly affects the confidentiality and availability of the system's data and processes.

From a confidentiality perspective, the exposure of internal-only columns is highly problematic. Attackers can leverage the blind sorting technique to reconstruct critical tokens, system hashes, and sensitive personal information. This data leakage bypasses standard row-level and column-level administrative security configurations.

From an availability perspective, the lack of exception handling allows attackers to target database adapter layers directly. By executing invalid database operations, an attacker can crash the application worker processes. Repeated execution of these payloads can cause sustained application downtime.

To remediate this vulnerability, administrators must update starlette-admin to version 0.16.1 or later. The patch implements strong parameter validation and rejects any input containing unauthorized query directives.

If updating the package is not immediately possible, temporary mitigation measures can be applied. Teams can deploy Web Application Firewall (WAF) rules to detect and drop suspicious API queries. Rules should target patterns matching specific Python dunder structures like __class__ or unauthorized sorting directions in REST parameters.

Additionally, developers can override the standard query parameter parsing logic by implementing a custom middleware. This middleware can inspect incoming administrative REST calls and strip out any unexpected sorting or filtering parameters before they are processed by the Starlette-Admin view routers.