CVE-2026-26198 affects Ormar, an async mini ORM for Python, in versions 0.9.9 through 0.22.0. The vulnerability arises in aggregate query construction where user-supplied column names are passed directly into sqlalchemy.text() without validation or sanitization. Specifically, the QuerySet.min() and QuerySet.max() methods accept arbitrary string input for the column parameter and embed that input as raw SQL inside the aggregate function call. Unlike sum() and avg(), which perform a partial is_numeric field validation check, min() and max() omit this validation entirely. This allows attacker-controlled SQL expressions, including subqueries, to be injected into aggregate queries.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Model.objects.min() or Model.objects.max(), whether directly or indirectly through API parameters, reporting features, or GraphQL field selection. Implement a strict application-side allowlist that maps user selections to known-safe model fields only. Reject unexpected input and SQL metacharacters such as spaces, parentheses, quotes, or operators as defense in depth. Where possible, disable or restrict endpoints that expose dynamic aggregation behavior, and add monitoring or WAF detections for suspicious aggregate-query payloads.Patch, then assume compromise.
min() and max() aggregation paths.1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (2 hidden).
This repository is a self-contained proof-of-concept and analysis package for CVE-2026-26198, a SQL injection vulnerability affecting Ormar ORM versions 0.9.9 through 0.22.0. It is not part of a larger exploit framework. The code demonstrates how unvalidated user input passed to min() and max() aggregate methods can be embedded directly into SQL, allowing attackers to inject subqueries and read data from unrelated tables. Repository structure: README.md provides the vulnerability overview, impact, affected versions, and usage instructions. vulnerable_app.py recreates the vulnerable pattern with a simplified QuerySet implementation and builds a demo SQLite database containing products and sensitive users data. exploit_demo.py is the main PoC entry point; it creates a temporary database, invokes the vulnerable max() method with crafted SQL payloads, and prints leaked emails, password hashes, and user-role data. patched_app.py contains the remediation logic using identifier validation plus a whitelist of known model fields. test_vulnerability.py is a comprehensive pytest suite that proves exploitation works in the vulnerable implementation and that the patch blocks subquery, UNION, semicolon, comment, and malformed-column payloads. root_cause.md explains the original Ormar code path, including the unsafe flow into sqlalchemy.text(). Main exploit capability: unauthorized database disclosure via SQL injection in aggregate column parameters. The PoC does not provide code execution or persistence; it focuses on data exfiltration. Demonstrated payloads extract all user emails, the admin password hash, and a concatenated dump of usernames and roles from the users table while querying the products table. The README also describes a realistic web exposure pattern through an endpoint like GET /products/stats?aggregate=max&field=price, where attacker-controlled field input could reach the vulnerable ORM method. The exploit is best classified as a POC: it is functional and clearly demonstrates impact, but it is a local demo against SQLite rather than a weaponized remote exploit. The attack vector is fundamentally network-reachable in real applications if a web API forwards untrusted aggregate field names into Ormar's min()/max() methods without validation.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
11 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.