CVE-2026-26198: Collerek Ormar SQLI Vulnerability

CVE-2026-26198 Overview

Ormar is an async mini ORM for Python designed for use with FastAPI and Pydantic. A SQL injection vulnerability exists in versions 0.9.9 through 0.22.0 where the min() and max() aggregate query methods accept arbitrary string input as the column parameter without validation or sanitization. The user-supplied column names are passed directly into sqlalchemy.text(), allowing attackers to inject malicious SQL expressions into aggregate function calls.

Critical Impact

Unauthorized users 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.

Affected Products

• Collerek Ormar versions 0.9.9 through 0.22.0
• Python applications using Ormar ORM with exposed aggregate query functionality
• FastAPI applications utilizing Ormar's QuerySet.min() and QuerySet.max() methods

Discovery Timeline

• 2026-02-24 - CVE CVE-2026-26198 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-26198

Vulnerability Analysis

This SQL injection vulnerability (CWE-89) stems from improper input validation in Ormar's aggregate query functionality. When performing aggregate queries using min() and max() methods in the QuerySet class, the ORM constructs SQL expressions by passing user-supplied column names directly into SQLAlchemy's text() function without any validation or sanitization.

While the sum() and avg() methods implement partial protection through an is_numeric type check that rejects non-existent fields, the min() and max() methods completely skip this validation. This inconsistency creates a dangerous attack surface where an attacker-controlled string is embedded as raw SQL inside the aggregate function call, enabling full database exfiltration through subquery injection.

Root Cause

The root cause is the absence of column name validation in the min() and max() aggregate methods. Unlike sum() and avg(), which verify that the specified column exists and is numeric, these methods accept arbitrary string input and pass it directly to sqlalchemy.text(). This allows attackers to break out of the intended SQL context and inject arbitrary SQL expressions, including subqueries that can access any table in the database.

Attack Vector

The attack vector is network-accessible, requiring no authentication. An attacker can exploit this vulnerability by sending a crafted request to an endpoint that utilizes Ormar's min() or max() aggregate methods. By providing a malicious column parameter containing a SQL subquery, the attacker can extract sensitive data from any table in the database. The attack is particularly dangerous in FastAPI applications where user input may flow directly into ORM aggregate queries.

# Security patch in ormar/queryset/queryset.py - fix vulnerability by column filtering (#1557)
# Source: https://github.com/collerek/ormar/commit/a03bae14fe01358d3eaf7e319fcd5db2e4956b16

         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"
+                    "You can use sum and svg only with numeric types of columns"
                 )
+        if any(x.field_name not in x.target_model.model_fields for x in select_actions):
+            raise QueryDefinitionError(
+                "You can use aggregate functions only on "
+                "existing columns of the target model"
+            )
         select_columns = [x.apply_func(func, use_label=True) for x in select_actions]
         expr = self.build_select_expression().alias(f"subquery_for_{func_name}")
         expr = sqlalchemy.select(*select_columns).select_from(expr)  # type: ignore

Detection Methods for CVE-2026-26198

Indicators of Compromise

• Unusual aggregate query patterns in application logs containing SQL syntax characters such as parentheses, semicolons, or SELECT keywords in column parameters
• Database query logs showing subqueries nested within MIN() or MAX() aggregate functions
• Error messages indicating SQL syntax errors from malformed injection attempts
• Unexpected database table access patterns showing queries to tables not normally accessed by the application

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect SQL injection patterns in API request parameters targeting aggregate endpoints
• Monitor application logs for aggregate query calls with suspicious column parameter values containing SQL keywords or special characters
• Deploy database activity monitoring to detect anomalous query patterns accessing tables outside normal application scope
• Use SentinelOne Singularity to detect and alert on SQL injection attack patterns at the endpoint level

Monitoring Recommendations

• Enable detailed logging for all Ormar QuerySet aggregate method invocations, capturing the column parameters passed to min(), max(), sum(), and avg() methods
• Configure database audit logging to track all aggregate function executions and identify suspicious patterns
• Implement runtime application self-protection (RASP) to detect and block SQL injection attempts in real-time

How to Mitigate CVE-2026-26198

Immediate Actions Required

• Upgrade Ormar to version 0.23.0 or later immediately to receive the security patch
• Audit all application code for usage of QuerySet.min() and QuerySet.max() methods with user-controlled input
• Implement input validation at the application layer to whitelist allowed column names before passing to ORM methods
• Review database access logs for signs of exploitation attempts

Patch Information

The vulnerability has been patched in Ormar version 0.23.0. The fix adds validation to ensure that the field name provided to aggregate functions exists in the target model's defined fields before constructing the SQL expression. The patch is available in commit a03bae14fe01358d3eaf7e319fcd5db2e4956b16. For detailed information, see the GitHub Security Advisory GHSA-xxh2-68g9-8jqr and GitHub Release 0.23.0.

Workarounds

• If immediate upgrade is not possible, implement a whitelist of allowed column names at the application layer before passing user input to aggregate methods
• Create wrapper functions around min() and max() that validate column names against the model's defined fields
• Use prepared statements or parameterized queries when constructing aggregate queries manually

# Example: Application-level column validation workaround
ALLOWED_COLUMNS = {"id", "price", "quantity", "created_at"}

async def safe_min(queryset, column_name: str):
    """Validates column name before calling min() aggregate."""
    if column_name not in ALLOWED_COLUMNS:
        raise ValueError(f"Invalid column name: {column_name}")
    return await queryset.min(column_name)