Description

starlette-admin versions 0.16.1 through 0.17.1 fail to enforce the searchable_fields allowlist when configured as an empty list, allowing authenticated users to filter on non-searchable fields. Attackers can submit structured filter queries via the list API's where parameter to perform equality and comparison operations on excluded columns.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-12T02:16:23.580Z",
  "pubdate": "2026-09-12T02:16:23.580Z",
  "executiveSummary": "A security flaw exists in starlette-admin versions 0.16.1 through 0.17.1, involving improper input validation within the API's filtering mechanism.\nThe vulnerability occurs because the framework fails to enforce the searchable_fields allowlist when it is configured as an empty list.\nThis vulnerability allows an authenticated user to perform unauthorized search and filtering operations on database columns that were explicitly intended to be excluded from search functionality.\nBy submitting specifically crafted structured filter queries via the 'where' parameter in the list API, an attacker can perform equality and comparison operations on arbitrary, non-searchable columns.\nThe risk implication is unauthorized data access and potential reconnaissance, as an attacker can infer sensitive information by systematically querying fields that should be unreachable via the search API.\nExploitation requires the attacker to be authenticated to the application.",
  "technicalDetails": "The vulnerability resides in the request processing logic of the starlette-admin list API, specifically concerning how user-provided filter parameters are parsed and translated into backend database queries.\nWhen a developer configures a model view, they define 'searchable_fields' to restrict which database columns can be queried via the API. The intended security behavior is that if this list is defined as empty, no fields should be searchable.\nThe root cause is a logic failure in the validation layer where the framework incorrectly assumes that an empty list indicates no restriction, rather than an instruction to disable searching entirely, or fails to properly enforce the check when the configuration value evaluates to an empty list.\nAn authenticated attacker can exploit this by intercepting a request to the list API and appending a 'where' parameter, which contains a JSON-serialized object defining the field and operator to be used for the query.\nBecause the allowlist enforcement is bypassed, the backend application accepts the 'where' parameter and constructs a database query dynamically.\nThe attack flow is as follows: 1) The attacker identifies a target model endpoint in the starlette-admin interface. 2) The attacker crafts a payload targeting a sensitive or non-searchable field (e.g., hashed passwords, internal flags, or private metadata). 3) The payload is transmitted as part of the 'where' parameter in a GET request to the model's list endpoint. 4) The server processes the request, fails to check the field against the (empty) allowlist, and executes a database query (e.g., SELECT ... WHERE non_searchable_column = 'value'). 5) The response is returned to the attacker, potentially leaking information based on whether the record exists or through direct data disclosure.\nThis allows attackers to perform equality comparisons (=) and other supported comparison operations defined by the underlying database abstraction layer on columns that developers presumed to be secure.\nThe affected versions are starlette-admin 0.16.1 through 0.17.1. The impact is significant as it facilitates unauthorized data reconnaissance and potential information disclosure of sensitive database records that the administrator intended to keep shielded from the API search feature."
}