CVE-2026-26198: When MIN() Forgot to Ask Whether the Column Was Real

---

Ormar's aggregate helpers turn a user-supplied string into raw SQL via sqlalchemy.text(). sum() and avg() accidentally got a guard rail; min() and max() drove straight off the cliff, letting an attacker smuggle a whole subquery in where a column name belongs.

The advisory in plain English

Ormar is an async mini-ORM for Python (the kind of thing you bolt onto FastAPI so you never have to hand-write SQL). Like most ORMs it offers convenience aggregates: await Model.objects.min("price"), max, sum, avg. You pass a column name as a string, it returns a scalar.

The defect (CVE-2026-26198, CVSS 7.5 — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, a confidentiality-only read primitive — fixed in 0.23.0) is that the "column name" is never checked against the model's actual columns before being spliced into SQL. The string is wrapped in sqlalchemy.text() — SQLAlchemy's explicit "I, the developer, vouch that this is safe literal SQL" escape hatch — and dropped inside a MIN(...)/MAX(...) call. If the string isn't a column name but a correlated subquery, the database happily evaluates it. Because the subquery can name any table, an unauthenticated caller who reaches a min()/max() endpoint can read the entire database — one scalar at a time, via repeated correlated-subquery queries — not just the model that was queried.

I cloned the repo at the patched HEAD and walked back to the fix commit a03bae1 and its parent ef95d32 to read the vulnerable code as it shipped.

The flawed function

Every aggregate funnels through one private method. Here it is pre-fix — ormar/queryset/queryset.py @ ef95d32, L699-L709:

async def _query_aggr_function(self, func_name: str, columns: List) -> Any:
    func = getattr(sqlalchemy.func, func_name)
    select_actions = [
        SelectAction(select_str=column, model_cls=self.model) for column in columns
    ]
    if func_name in ["sum", "avg"]:
        if any(not x.is_numeric for x in select_actions):
            raise QueryDefinitionError(
                "You can use sum and svg only with" "numeric types of columns"
            )
    select_columns = [x.apply_func(func, use_label=True) for x in select_actions]

Read the if carefully. The only validation is gated on func_name in ["sum", "avg"]. When you call min() or max(), that branch is skipped entirely, and select_actions flow straight into apply_func with zero checks. The columns list is whatever the caller passed.

Where does the string become SQL? In the SelectAction. The sink is ormar/queryset/actions/select_action.py @ ef95d32, L41-L43:

def get_text_clause(self) -> sqlalchemy.sql.expression.TextClause:
    alias = f"{self.table_prefix}_" if self.table_prefix else ""
    return sqlalchemy.text(f"{alias}{self.field_name}")

That f"{alias}{self.field_name}" is the entire bug in one line. self.field_name is derived directly from the caller's string (select_str.split("__")[-1], set at select_action.py @ ef95d32, L31), and it is interpolated into sqlalchemy.text() with no quoting, no identifier validation, no allow-list. text() produces a literal SQL fragment; apply_func then wraps it as MIN(<that fragment>). Whatever you put in the column slot becomes part of the executed statement. This is a textbook SQL injection sink — the f-string-into-text() pattern is precisely what SQLAlchemy's own docs warn against.

Why the check was insufficient

The interesting part isn't that a check was missing — it's that a partial check existed and lulled everyone into thinking the surface was covered. Look at what is_numeric actually does, at select_action.py @ ef95d32, L34-L39:

@property
def is_numeric(self) -> bool:
    return self.get_target_field_type() in [int, float, decimal.Decimal]

def get_target_field_type(self) -> Any:
    return self.target_model.ormar_config.model_fields[self.field_name].__type__

get_target_field_type indexes ormar_config.model_fields[self.field_name]. For an injected string that isn't a real column, that dictionary lookup raises KeyError — so sum() and avg() blow up before reaching the sink. It's not a deliberate security check; it's an incidental crash. But a crash that happens to abort the query is, functionally, a guard rail. sum/avg were protected by accident.

min and max never call is_numeric, so they never touch model_fields, so the non-existent "column" is never looked up — and the only thing standing between user input and the database is text(), which by design trusts its argument. Two methods accidentally safe, two methods wide open, all four sharing the same sink. That asymmetry is the smell that should have prompted a unified validation layer years earlier.

There's a second lesson buried in the split logic. field_name is parts[-1] after splitting on __ (ormar's relation-traversal separator). So the injected payload simply needs to live in the final segment of the string. The "column name" abstraction was leaky: the framework treated the string as structured (relation path + field) but never validated that the field at the end of the path was a field the model actually owns.

What the fix changed

The patch is small and correct. From git show a03bae1 -- ormar/queryset/queryset.py, the added lines (ormar/queryset/queryset.py @ a03bae1):

if any(x.field_name not in x.target_model.ormar_config.model_fields for x in select_actions):
    raise QueryDefinitionError(
        "You can use aggregate functions only on "
        "existing columns of the target model"
    )

This runs unconditionally — outside the sum/avg branch — so it covers min, max, sum, and avg uniformly. Every SelectAction's resolved field_name must be a key in the target model's ormar_config.model_fields. An injected subquery isn't a declared field, so it's rejected with a clean QueryDefinitionError instead of reaching text(). The release notes flagged this as a breaking change and bumped the minor version to 0.23.0 — appropriate, since anyone relying on passing computed expressions to min()/max() (you shouldn't have been) will now get an error.

The fix is allow-list validation at the boundary: don't try to detect bad input, enumerate the good input. Bind parameters protect value positions but not identifier positions — you cannot parameterize a column name — so allow-listing the known columns is the most robust fix; the alternative is to route the name through a safe identifier construct (quoted_name/column()) instead of text(). The set of valid columns is known statically from the model. Checking membership is cheap and total.

What the scanners said (and didn't)

I tried to get an off-the-shelf scanner to flag the sink, partly to see whether a CI gate would have caught this. The results are a cautionary tale about trusting tools.

Bandit (bandit -r ormar/queryset/actions/select_action.py -f json) reported SEVERITY.HIGH: 0, zero results. Bandit's SQL rule (B608) keys on string-formatting into SELECT/INSERT-shaped literals; it does not model sqlalchemy.text() as a sink, so the f-string here was invisible to it.

Semgrep couldn't reach its registry (p/python → proxy 403), so I wrote a local rule. Then it got weird. pattern: self.field_name correctly returned 4 findings — semgrep was parsing the file fine. But pattern: sqlalchemy.text(...) returned 0 findings, and so did sqlalchemy.text($X) and a bare text(...). I tried sqlalchemy.text(f"...{...}...") — still 0. To isolate the cause I matched the f-string node on its own:

pattern: f"...{self.field_name}..."   →  2 findings (L43, L45)

(L43 is the get_text_clause line shown above; the L45 hit is a second self.field_name f-string elsewhere in the file, outside the snippet.) So the f-string is matchable, and self.field_name is matchable, but the OSS engine (semgrep 1.165.0) failed to match the call sqlalchemy.text(<f-string>) — an f-string-as-call-argument quirk in this version. The takeaway: both default scanners missed a 7.5 because the dangerous data crossed through text(), a sink neither tool modeled by default. The hole was a one-liner; the tooling that "should" have caught it didn't. Read the diff yourself; don't outsource your judgment to a green checkmark.

The lesson

Three of them, really. First: text() (and every "trust me" raw-SQL primitive) is a sink — anything reaching it must already be validated, and "the value came from a column-name parameter" is not validation. Second: validate by allow-list at the trust boundary, not by hoping a downstream KeyError saves you; incidental safety on sum/avg is exactly why the real hole in min/max survived. Third: when two siblings of a four-method family behave differently around untrusted input, that inconsistency is the vulnerability report — go read the other two.

References

• Fix commit: https://github.com/collerek/ormar/commit/a03bae14fe01358d3eaf7e319fcd5db2e4956b16
• Release 0.23.0: https://github.com/collerek/ormar/releases/tag/0.23.0
• Advisory GHSA-xxh2-68g9-8jqr: https://github.com/collerek/ormar/security/advisories/GHSA-xxh2-68g9-8jqr
• Vulnerable sink: https://github.com/collerek/ormar/blob/ef95d32/ormar/queryset/actions/select_action.py#L41-L43
• is_numeric partial guard: https://github.com/collerek/ormar/blob/ef95d32/ormar/queryset/actions/select_action.py#L34-L39
• Pre-fix aggregate dispatch: https://github.com/collerek/ormar/blob/ef95d32/ormar/queryset/queryset.py#L699-L709
• Patched validation: https://github.com/collerek/ormar/blob/a03bae14fe01358d3eaf7e319fcd5db2e4956b16/ormar/queryset/queryset.py