CVE-2026-94144 in drogon
Summary
by MITRE • 09/21/2026
A flaw has been found in drogonframework drogon up to 1.9.13. This affects the function makeCriteria in the library orm_lib/src/Criteria.cc of the component ORM. Executing a manipulation of the argument filter can lead to sql injection. The attack may be performed from remote. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified within the drogonframework, specifically affecting versions up through 1.9.13, represents a critical security flaw located within the Object-Relational Mapping (ORM) component of the framework. The root cause resides in the makeCriteria function found in the source file orm_lib/src/Criteria.cc. This particular function is responsible for constructing database query criteria based on user-supplied input or application logic parameters. In this instance, the implementation fails to adequately sanitize or validate the filter argument before it is incorporated into SQL statements. This lack of proper input validation allows an attacker to inject malicious SQL code directly into the query structure, bypassing intended logical constraints and potentially accessing, modifying, or deleting data that should remain protected by application-level permissions.
This flaw is classified as a classic SQL Injection vulnerability, which corresponds to CWE-89 in the Common Weakness Enumeration taxonomy. The severity of this issue is compounded by its remote exploitability, meaning an attacker does not need local access to the system but can instead leverage network connectivity to deliver malicious payloads. Since drogon is often deployed in web server environments handling HTTP requests, the filter argument likely originates from user-facing inputs such as query parameters, POST body data, or headers that are processed by the ORM layer. The fact that a public exploit has been published significantly elevates the risk profile of this vulnerability, as automated scanning tools and malicious actors can readily utilize these proof-of-concept codes to compromise vulnerable systems without requiring custom development effort.
The operational impact of exploiting this SQL injection is severe and multifaceted. Successful exploitation could lead to unauthorized access to sensitive database contents, including personally identifiable information, financial records, or proprietary business data. Beyond confidentiality breaches, attackers may manipulate existing records or insert new malicious entries, compromising data integrity. In more advanced attack scenarios involving stacked queries or specific database configurations, the vulnerability might even allow for command execution on the underlying host system, leading to a complete compromise of the server infrastructure. The lack of response from the vendor further exacerbates the situation, as users are left without official patches or guidance during an active threat landscape where exploits are already in circulation.
Mitigation strategies must be implemented immediately given the availability of public exploits and the absence of vendor updates. Applications using drogon versions up to 1.9.13 should prioritize upgrading to a patched version if one becomes available from alternative sources or community forks, as the official vendor has been unresponsive. In the interim, developers can implement defensive coding practices by ensuring that all inputs passed to the makeCriteria function are strictly validated against expected formats and types. Utilizing parameterized queries or prepared statements wherever possible within custom ORM extensions can also help mitigate direct injection risks. Additionally, deploying a Web Application Firewall with rules specifically tuned for SQL injection patterns may provide an additional layer of defense at the network perimeter. Continuous monitoring of application logs for anomalous database query structures is recommended to detect potential exploitation attempts in real-time.