Description

SQLAdmin is a flexible Admin interface for SQLAlchemy models. Prior to 0.27.1, ModelView.sort_query in sqladmin/models.py accepts the attacker-controlled sortBy list-view query parameter without enforcing the configured column_sortable_list server-side allow-list in self._sort_fields. The value is resolved with getattr and passed to relationship joins and order_by, allowing requests to sort by columns hidden from column_list and by related-model columns through dotted paths. The resulting row order forms an information-exposure oracle for unexposed values, and reversing ascending and descending order confirms their relative ordering. Pairing sortBy with searchable or filterable columns and pagination can narrow the oracle toward specific values, but exact recovery depends on the application's available fields and data. This issue is fixed in version 0.27.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-14T16:17:12.050Z",
  "pubdate": "2026-09-14T16:17:12.050Z",
  "executiveSummary": "SQLAdmin versions prior to 0.27.1 contain an improper input validation vulnerability within the ModelView.sort_query function. The vulnerability arises from the application's failure to enforce the column_sortable_list allow-list when processing the sortBy query parameter provided by users.\nThis flaw allows an attacker to manipulate sorting operations to target columns that were intentionally hidden from the UI via column_list or to perform sorting based on related-model columns using dotted path notation.\nThe primary impact is a side-channel information exposure vulnerability. By observing how the application orders result sets based on arbitrary columns, an attacker can construct an information-exposure oracle. This allows for the inference of data values that are otherwise unexposed to the user. Exploitation is facilitated by pairing this sorting mechanism with pagination, filtering, or searching capabilities, enabling an attacker to incrementally reconstruct or verify sensitive data points. The risk is significant for applications handling sensitive or private model data, as it provides a non-intrusive method for data exfiltration without requiring direct read access to restricted attributes.",
  "technicalDetails": "The vulnerability is located in sqladmin/models.py within the ModelView.sort_query method. The root cause is a deficiency in input sanitization and allow-list enforcement. Specifically, the method accepts user-controlled input from the sortBy query parameter and processes it without validating the input against the configured self._sort_fields attribute, which is intended to define the set of permitted sortable columns.\nIn the vulnerable implementation, the provided sortBy string is passed to getattr, which resolves the attribute on the SQLAlchemy model. Because this process ignores the server-side allow-list, it permits the application to resolve arbitrary class attributes. This effectively bypasses intended UI restrictions, allowing an attacker to sort the returned result set by any model attribute or, through the use of dotted path syntax, by columns located in related models.\nThe exploitation flow typically follows these steps: 1. An attacker identifies an endpoint managed by SQLAdmin that accepts a sortBy query parameter. 2. The attacker submits a crafted request, setting sortBy to a sensitive column name or a related model path that is not exposed in the standard view. 3. The server executes the order_by clause using this unvalidated input. 4. By observing the order of the returned records, the attacker confirms the relative ordering of values in the target column. 5. Through iterative requests—often combined with pagination and filter/search parameters—the attacker performs a systematic analysis of the data set.\nThis behavior functions as an information-exposure oracle. Even if the content of the hidden column is not directly returned in the response body, the row ordering provides sufficient context to verify the presence or relative value of data within that column. For instance, by observing whether a record appears at the top or bottom of a list during ascending or descending sorts, an attacker can confirm sensitive values such as booleans, timestamps, or discrete categorical data. The vulnerability allows for the retrieval of metadata and relationships that the application administrator intended to keep private, significantly expanding the attack surface beyond what is exposed by default UI configurations."
}