CVE-2026-44680
Received Received - Intake
SQL Injection in MikroORM

Publication date: 2026-05-26

Last updated on: 2026-05-26

Assigner: GitHub, Inc.

Description
MikroORM is a TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Prior to @mikro-orm/knex 6.6.14 and @mikro-orm/sql 7.0.14, 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. This vulnerability is fixed in @mikro-orm/knex 6.6.14 and @mikro-orm/sql 7.0.14.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-26
Last Modified
2026-05-26
Generated
2026-05-26
AI Q&A
2026-05-26
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
mikro-orm knex to 6.6.14 (inc)
mikro-orm sql to 7.0.14 (inc)
mikro-orm knex to 6.6.14 (exc)
mikro-orm sql to 7.0.14 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-89 The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-44680 is a SQL injection vulnerability in MikroORM, a TypeScript ORM for Node.js. The issue arises because MikroORM's identifier-quoting helper functions and JSON-path emitters did not properly escape characters that delimit SQL identifiers or string literals. This improper escaping allows an attacker to break out of the quoted context when attacker-controlled strings are passed to public ORM APIs expecting identifiers or JSON-property filters, enabling arbitrary SQL injection.

The vulnerability affects multiple MikroORM APIs, including multi-tenant schema options, JSON-property filters in queries, and dynamic keys in query builders. It impacts all SQL dialects supported by MikroORM due to unescaped delimiter characters.

The issue was fixed by properly escaping JSON property filter keys and SQL identifiers, ensuring special characters are handled correctly and wrapped with dialect-specific escaping functions.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-44680 is a SQL injection vulnerability in MikroORM that allows attackers to inject arbitrary SQL by breaking out of quoted contexts in SQL identifiers or JSON-path keys. This can lead to unauthorized data access, data modification, or denial-of-service conditions.

Such unauthorized access or modification of data can impact compliance with data protection regulations and standards like GDPR and HIPAA, which require safeguarding sensitive data against unauthorized access and ensuring data integrity.

Therefore, if exploited, this vulnerability could result in violations of these regulations due to potential data breaches or unauthorized data manipulation.

Mitigations include upgrading to patched versions of MikroORM or applying strict validation of inputs before passing them to MikroORM APIs.


How can this vulnerability impact me? :

This vulnerability can allow an attacker to inject arbitrary SQL commands into MikroORM queries by exploiting improper escaping of identifiers and JSON-path keys. This can lead to unauthorized data access, data modification, or denial-of-service conditions.

  • Data leaks through unauthorized SQL queries.
  • Unauthorized modification of database contents.
  • Potential denial-of-service attacks by executing malicious SQL.

The vulnerability has a high CVSS score of 7.6, with low attack complexity and requiring low privileges, making it a significant risk if unpatched.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability arises from improper escaping of characters in SQL identifiers and JSON-path keys in MikroORM versions prior to @mikro-orm/knex 6.6.14 and @mikro-orm/sql 7.0.14. Detection involves identifying usage of vulnerable MikroORM package versions and inspecting application code for usage of public ORM APIs that accept identifiers or JSON-property filters with user-controlled input.

There are no specific network or system commands provided in the resources to detect exploitation attempts or presence of this vulnerability.

Recommended detection steps include:

  • Check the installed versions of @mikro-orm/knex and @mikro-orm/sql packages to see if they are older than 6.6.14 and 7.0.14 respectively.
  • Review application code for usage of MikroORM APIs that accept identifiers or JSON property filters, especially where user input might be passed directly.
  • Monitor logs or database query logs for suspicious or malformed SQL queries that could indicate injection attempts.

What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade the affected MikroORM packages to fixed versions: @mikro-orm/knex version 6.6.14 or later, and @mikro-orm/sql version 7.0.14 or later.

If immediate upgrade is not possible, temporary mitigations include:

  • Strictly validate and sanitize schema names, entity property keys, and JSON sub-keys before passing them to MikroORM APIs to prevent attacker-controlled input from reaching vulnerable code paths.
  • Avoid passing untrusted or user-controlled strings directly to ORM APIs that expect identifiers or JSON property filters.

Additionally, the vulnerability does not affect documented escape-hatch APIs like raw() or qb.raw(), which require manual sanitization, so consider using these with caution.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart