CVE-2026-44680 is a high-severity (CVSS 7.6) SQL Injection vulnerability in @mikro-orm/sql. 1 public exploit reference exists, so weaponization risk is real. A fix is available for @mikro-orm/sql — see the affected versions and patch details below.
MikroORM: SQL injection via runtime-controlled identifiers and JSON-path keys
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44680.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-44680 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@mikro-orm/sqlnpm@mikro-orm/knexnpmDescription
Summary
MikroORM's identifier-quoting helper (Platform.quoteIdentifier and the postgres/mssql overrides) and its JSON-path emitters (Platform.getSearchJsonPropertyKey, quoteJsonKey) did not properly escape characters that delimit the SQL identifier or string-literal context they emit into. When application code passes attacker-influenced strings to public ORM APIs that expect an identifier or a JSON-property filter, an attacker can break out of the quoted context and inject arbitrary SQL.
Affected APIs
The vulnerability is reachable when application code passes an attacker-influenced string to any of the following documented APIs:
- Multi-tenant
schemaoption —em.fork({ schema }),qb.withSchema(name),wrap(entity).setSchema(name),em.create(Cls, data, { schema }). The schema name is concatenated into the SQL identifier and never had its dialect quote character escaped. em.find/qb.whereJSON-property filters —em.find(Entity, { jsonCol: { [userKey]: value } }). The user-supplied JSON sub-keys cannot be validated against any metadata (JSON columns are schemaless by design), and were spliced into the SQL string literal of the JSON path expression without escaping.qb.where/qb.orderBy/qb.groupBy/qb.having/qb.selectkeys — keys containing.or::bypassed the structured-where metadata validator inCriteriaNode, then flowed through the same brokenquoteIdentifier. Apps that forwarded raw filter keys from request input were already broken on authorization grounds (e.g.{ isAdmin: true }); the SQL injection here is a defence-in-depth failure on top of that.
The vulnerability does not affect documented escape-hatch APIs (raw(), the sql tagged template, qb.raw(), em.raw()) — those are documented as accepting raw SQL and are the application's responsibility to sanitize.
Impact
- Confidentiality — read from any table/schema the database user has access to (cross-tenant data leak in multi-tenant deployments).
- Integrity — on dialects supporting multi-statement queries (MSSQL, MySQL with multi-statement enabled), execute additional arbitrary SQL statements (data modification, in-database privilege escalation).
- Availability — DROP/TRUNCATE via injected statements where the database user has the privilege.
Affected dialects
All SQL dialects supported by MikroORM. The identifier-quoting bug exists in every dialect's quoteIdentifier (the dialect's own quote character — backtick, double quote, or right bracket — was not doubled when embedded in the identifier). The JSON-path bug exists in all dialects' getSearchJsonPropertyKey/quoteJsonKey.
MongoDB driver is not affected (no SQL).
Patches
- v7: upgrade to 7.0.14 or later.
- v6: upgrade to 6.6.14 or later.
Patches:
- Identifier quoting: #7653 (master) / #7654 (6.x)
- JSON-path keys: #7656 (master) / #7657 (6.x)
Workarounds
If users cannot upgrade immediately:
- For multi-tenant apps using
em.fork({ schema })/wrap().setSchema()/qb.withSchema(): validate the schema name against a strict allowlist (e.g.^[A-Za-z_][\w$]*$) before passing it to MikroORM. - For applications that pass
where/orderByfilters from request input: validate every key against the entity's known properties before constructing the filter; do not pass keys containing.or::from user input. - For applications that allow filtering on JSON columns from request input: validate every JSON sub-key against an allowlist (or against
^[a-zA-Z_][\w]*$) before passing it toem.find.
Credits
Reported and patched by Martin Adámek (project maintainer) during an internal security review.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @mikro-orm/sql | all versions | 7.0.14npm install @mikro-orm/sql@7.0.14 |
| 📦npm | @mikro-orm/knex | all versions | 6.6.14npm install @mikro-orm/knex@6.6.14 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
MikroORM 7.0.13 - SQL Injection
by cardosource · May 29, 2026
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @mikro-orm/sql, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @mikro-orm/sql to 7.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44680 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44680 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44680. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44680 in your dependencies?
O3 Security finds CVE-2026-44680 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.