https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 15:44:54 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-368008 EUVD-2026-368008 https://cve.radiocsirt.org/vuln/euvd-2026-368008 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54529 <p>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&#39;s available fields and data. This issue is fixed in version 0.27.1.</p> <p>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&#39;s available fields and data. This issue is fixed in version 0.27.1.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54529 https://cve.radiocsirt.org/vuln/ghsa-ccg5-9c8w-xh6v <p><strong>Affected:</strong> PyPI: sqladmin</p> <p>## Summary</p> <p>`ModelView.sort_query()` uses the attacker-controlled `sortBy` list-view query parameter without checking it against the configured `column_sortable_list` allow-list. The value is resolved with `getattr(model, ...)` and fed into relationship joins and `order_by()`, so a request can sort by **any** column of the model — including ones hidden from `column_list` — and, via a dotted path, by columns of related models. Because row order then reflects the value of an unexposed column, this is an information-exposure **ordering oracle**.</p> <p>## Root cause</p> <p>`column_sortable_list` is consulted only in the list template to decide which header links to render; the server never enforces it, so removing a column from the UI does not prevent sorting by it.</p> <p>## Exploitation</p> <p>A single request leaks the relative ordering of an unexposed column; the `asc`↔`desc` reversal confirms rows are ordered by the secret&#39;s actual value. Pairing `sortBy` with searchable/filterable columns and pagination can narrow the oracle toward specific values, though value recovery is conditional on having a filterable target column.</p> <p><strong>Affected:</strong> PyPI: sqladmin</p> <p>## Summary</p> <p>`ModelView.sort_query()` uses the attacker-controlled `sortBy` list-view query parameter without checking it against the configured `column_sortable_list` allow-list. The value is resolved with `getattr(model, ...)` and fed into relationship joins and `order_by()`, so a request can sort by **any** column of the model — including ones hidden from `column_list` — and, via a dotted path, by columns of related models. Because row order then reflects the value of an unexposed column, this is an information-exposure **ordering oracle**.</p> <p>## Root cause</p> <p>`column_sortable_list` is consulted only in the list template to decide which header links to render; the server never enforces it, so removing a column from the UI does not prevent sorting by it.</p> <p>## Exploitation</p> <p>A single request leaks the relative ordering of an unexposed column; the `asc`↔`desc` reversal confirms rows are ordered by the secret&#39;s actual value. Pairing `sortBy` with searchable/filterable columns and pagination can narrow the oracle toward specific values, though value recovery is conditional on having a filterable target column.</p> https://cve.radiocsirt.org/vuln/ghsa-ccg5-9c8w-xh6v https://cve.radiocsirt.org/vuln/pysec-2026-3922 <p><strong>Affected:</strong> PyPI: sqladmin</p> <p>## Summary</p> <p>`ModelView.sort_query()` uses the attacker-controlled `sortBy` list-view query parameter without checking it against the configured `column_sortable_list` allow-list. The value is resolved with `getattr(model, ...)` and fed into relationship joins and `order_by()`, so a request can sort by **any** column of the model — including ones hidden from `column_list` — and, via a dotted path, by columns of related models. Because row order then reflects the value of an unexposed column, this is an information-exposure **ordering oracle**.</p> <p>## Root cause</p> <p>`column_sortable_list` is consulted only in the list template to decide which header links to render; the server never enforces it, so removing a column from the UI does not prevent sorting by it.</p> <p>## Exploitation</p> <p>A single request leaks the relative ordering of an unexposed column; the `asc`↔`desc` reversal confirms rows are ordered by the secret&#39;s actual value. Pairing `sortBy` with searchable/filterable columns and pagination can narrow the oracle toward specific values, though value recovery is conditional on having a filterable target column.</p> <p><strong>Affected:</strong> PyPI: sqladmin</p> <p>## Summary</p> <p>`ModelView.sort_query()` uses the attacker-controlled `sortBy` list-view query parameter without checking it against the configured `column_sortable_list` allow-list. The value is resolved with `getattr(model, ...)` and fed into relationship joins and `order_by()`, so a request can sort by **any** column of the model — including ones hidden from `column_list` — and, via a dotted path, by columns of related models. Because row order then reflects the value of an unexposed column, this is an information-exposure **ordering oracle**.</p> <p>## Root cause</p> <p>`column_sortable_list` is consulted only in the list template to decide which header links to render; the server never enforces it, so removing a column from the UI does not prevent sorting by it.</p> <p>## Exploitation</p> <p>A single request leaks the relative ordering of an unexposed column; the `asc`↔`desc` reversal confirms rows are ordered by the secret&#39;s actual value. Pairing `sortBy` with searchable/filterable columns and pagination can narrow the oracle toward specific values, though value recovery is conditional on having a filterable target column.</p> https://cve.radiocsirt.org/vuln/pysec-2026-3922