REDAXO CMS EUVD-2026-85332

Requires an authenticated REDAXO backend user (PR:L) with access to any page rendering a rex_list list that supports sorting; the attacker manipulates the 'sort' HTTP request parameter to name a column that was never registered via setColumnSortable(), causing getSortColumn()/prepareQuery() to place an unauthorized (but escaped) identifier into the ORDER BY clause. Exploitation is limited by the need for valid backend credentials and by the confidentiality-only, inference-based nature of the leak (error-based enumeration and ordering oracle rather than direct data dump). Only versions of redaxo/core prior to 5.21.2 are affected; the 5.21.2 fix validates the requested column with hasColumnOption(..., REX_LIST_OPT_SORT) before accepting it.

This is a low-to-moderate severity, authenticated information-disclosure issue, not an urgent priority. The vendor CVSS of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) is internally consistent with the description: exploitation requires an authenticated REDAXO backend user (PR:L) but no user interaction, and impact is limited to confidentiality (C:L) via error-based column enumeration and ordering by unselected sensitive fields such as rex_user.password - a slow inference/oracle technique, not bulk data theft. No EPSS score, no CISA KEV listing, and no public POC are present in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis.' There is no SSVC data supplied. The main signals - moderate CVSS, required backend authentication, indirect confidentiality-only impact, and absence of exploitation evidence - all point the same direction: a real but bounded weakness worth patching in routine cycles rather than emergency response. The source-code diff confirms the root cause and fix, raising confidence in the technical accuracy of the report.

An attacker who already holds a low-privileged REDAXO backend account browses a list view and tampers with the 'sort' request parameter, supplying a column name that was never registered as sortable (e.g. a field from a joined table or rex_user.password). Because getSortColumn() did not validate the parameter against setColumnSortable(), the value is escaped and injected into the ORDER BY clause, letting the attacker use database errors and ordering behavior to enumerate hidden columns and infer sensitive values. No public exploit code is identified, but the technique is straightforward given the confirmed source diff.