{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/mikroorm/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["@mikro-orm/sql (\u003c= 7.0.13)","@mikro-orm/knex (\u003c= 6.6.13)"],"_cs_severities":["high"],"_cs_tags":["sql-injection","orm","mikroorm"],"_cs_type":"advisory","_cs_vendors":["MikroORM"],"content_html":"\u003cp\u003eMikroORM\u0026rsquo;s identifier-quoting helper (\u003ccode\u003ePlatform.quoteIdentifier\u003c/code\u003e and the postgres/mssql overrides) and its JSON-path emitters (\u003ccode\u003ePlatform.getSearchJsonPropertyKey\u003c/code\u003e, \u003ccode\u003equoteJsonKey\u003c/code\u003e) did not properly escape characters that delimit the SQL identifier or string-literal context they emit into. This allows for SQL injection vulnerabilities. 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 affects all SQL dialects supported by MikroORM, specifically versions 7.0.13 and earlier of \u003ccode\u003e@mikro-orm/sql\u003c/code\u003e and versions 6.6.13 and earlier of \u003ccode\u003e@mikro-orm/knex\u003c/code\u003e. The MongoDB driver is not affected.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an application using a vulnerable version of MikroORM.\u003c/li\u003e\n\u003cli\u003eThe attacker finds an API endpoint that passes user-controlled strings to a vulnerable MikroORM API, such as \u003ccode\u003eem.fork({ schema })\u003c/code\u003e or \u003ccode\u003eem.find(Entity, { jsonCol: { [userKey]: value } })\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious input string containing SQL injection payloads.\u003c/li\u003e\n\u003cli\u003eThis malicious string is passed to MikroORM\u0026rsquo;s \u003ccode\u003equoteIdentifier\u003c/code\u003e or \u003ccode\u003egetSearchJsonPropertyKey\u003c/code\u003e/\u003ccode\u003equoteJsonKey\u003c/code\u003e functions without proper escaping.\u003c/li\u003e\n\u003cli\u003eThe unescaped string is concatenated into a SQL query.\u003c/li\u003e\n\u003cli\u003eThe application executes the crafted SQL query against the database.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to data, modifies data, or elevates privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or performs other malicious actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability could allow an attacker to read from any table/schema the database user has access to, leading to cross-tenant data leaks in multi-tenant deployments. On dialects supporting multi-statement queries (MSSQL, MySQL with multi-statement enabled), attackers can execute additional arbitrary SQL statements, potentially leading to data modification and in-database privilege escalation. Availability could also be impacted through DROP/TRUNCATE statements if the database user has the necessary privileges.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade MikroORM to version 7.0.14 or later for v7, and 6.6.14 or later for v6, to patch the vulnerability (refer to Patches section in the content).\u003c/li\u003e\n\u003cli\u003eFor multi-tenant apps using \u003ccode\u003eem.fork({ schema })\u003c/code\u003e / \u003ccode\u003ewrap().setSchema()\u003c/code\u003e / \u003ccode\u003eqb.withSchema()\u003c/code\u003e, validate the schema name against a strict allowlist (e.g. \u003ccode\u003e^[A-Za-z_][\\w$]*$\u003c/code\u003e) before passing it to MikroORM (refer to Workarounds section in the content).\u003c/li\u003e\n\u003cli\u003eFor applications that pass \u003ccode\u003ewhere\u003c/code\u003e / \u003ccode\u003eorderBy\u003c/code\u003e filters from request input, validate every key against the entity\u0026rsquo;s known properties before constructing the filter; do not pass keys containing \u003ccode\u003e.\u003c/code\u003e or \u003ccode\u003e::\u003c/code\u003e from user input (refer to Workarounds section in the content).\u003c/li\u003e\n\u003cli\u003eFor applications that allow filtering on JSON columns from request input, validate every JSON sub-key against an allowlist (or against \u003ccode\u003e^[a-zA-Z_][\\w]*$\u003c/code\u003e) before passing it to \u003ccode\u003eem.find\u003c/code\u003e (refer to Workarounds section in the content).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-08T19:17:45Z","date_published":"2026-05-08T19:17:45Z","id":"/briefs/2024-01-mikroorm-sqli/","summary":"MikroORM is vulnerable to SQL injection due to improper escaping in identifier-quoting and JSON-path emitters, enabling attackers to inject arbitrary SQL via manipulated strings passed to public ORM APIs, potentially leading to data leaks, modification, and privilege escalation.","title":"MikroORM SQL Injection Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-mikroorm-sqli/"}],"language":"en","title":"CraftedSignal Threat Feed — Mikroorm","version":"https://jsonfeed.org/version/1.1"}