CVE-2026-26198 in ormar
Summary
by MITRE • 02/24/2026
Ormar is a async mini ORM for Python. In versions 0.9.9 through 0.22.0, when performing aggregate queries, Ormar ORM constructs SQL expressions by passing user-supplied column names directly into `sqlalchemy.text()` without any validation or sanitization. The `min()` and `max()` methods in the `QuerySet` class accept arbitrary string input as the column parameter. While `sum()` and `avg()` are partially protected by an `is_numeric` type check that rejects non-existent fields, `min()` and `max()` skip this validation entirely. As a result, an attacker-controlled string is embedded as raw SQL inside the aggregate function call. Any unauthorized user can exploit this vulnerability to read the entire database contents, including tables unrelated to the queried model, by injecting a subquery as the column parameter. Version 0.23.0 contains a patch.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 02/25/2026
The vulnerability described in CVE-2026-26198 represents a critical SQL injection flaw within the Ormar Python ORM library that affects versions 0.9.9 through 0.22.0. This security weakness stems from improper input validation and sanitization practices during the construction of aggregate SQL queries. The vulnerability specifically impacts the `min()` and `max()` methods within the `QuerySet` class, which accept arbitrary string parameters that are directly passed to `sqlalchemy.text()` without any form of validation or sanitization. The flaw creates a path for attackers to inject malicious SQL code through user-controlled inputs that are then executed as part of the aggregate function calls.
The technical implementation of this vulnerability demonstrates a classic case of unsafe SQL construction where the ORM fails to properly escape or validate user-supplied column names before incorporating them into SQL queries. While the `sum()` and `avg()` methods include a basic `is_numeric` type check that provides some protection against non-existent fields, the `min()` and `max()` methods completely bypass this validation mechanism. This inconsistency in security controls creates an exploitable gap where attackers can manipulate the column parameter to include malicious SQL subqueries. The vulnerability operates at the database abstraction layer, allowing an attacker to bypass normal access controls and potentially extract data from any table within the database, regardless of whether those tables relate to the model being queried.
The operational impact of this vulnerability is severe and far-reaching, as it allows any unauthorized user to execute arbitrary SQL commands against the database. An attacker can construct malicious column parameters that include subqueries capable of reading entire database contents, including sensitive information from unrelated tables. This type of attack falls under the category of SQL injection as defined by CWE-89 and can be mapped to ATT&CK technique T1071.004 for application layer protocol. The vulnerability essentially grants read access to the entire database schema and data without requiring elevated privileges or authentication. The patch implemented in version 0.23.0 addresses this by introducing proper input validation and sanitization for all aggregate methods, ensuring that column parameters are properly validated before being incorporated into SQL queries.
Organizations using affected versions of Ormar should immediately prioritize patching their systems to prevent potential data breaches and unauthorized access to sensitive database information. The vulnerability demonstrates the critical importance of input validation in database abstraction layers and highlights the risks associated with inconsistent security controls within software libraries. This flaw serves as a reminder of the necessity for comprehensive security testing and validation of all user-supplied inputs, particularly in contexts where SQL queries are constructed dynamically. The issue also underscores the importance of maintaining up-to-date security practices in ORM libraries, as the lack of proper validation in one method can create a complete bypass of database security controls.