GHSA-cfw5-68c4-ffqp is a high-severity (CVSS 7.6) vulnerability in @mikro-orm/sql. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-cfw5-68c4-ffqp is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
MikroORM has SQL injection via runtime-controlled identifiers and JSON-path keys
Real-World Exposure
@mikro-orm/sql📦@mikro-orm/knexReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
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.14 |
| 📦npm | @mikro-orm/knex | all versions | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-cfw5-68c4-ffqp 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 pinpoints whether GHSA-cfw5-68c4-ffqp is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-cfw5-68c4-ffqp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-cfw5-68c4-ffqp in your dependencies?
O3 detects GHSA-cfw5-68c4-ffqp across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.