MikroORM CVE-2026-44680

Exploitation requires authenticated access (CVSS PR:L - low-privilege authenticated user account) to application endpoints that pass user-controlled input to one of three vulnerable MikroORM API categories. First category: multi-tenant schema operations (em.fork with schema parameter, qb.withSchema, wrap(entity).setSchema, em.create with schema option) where the schema name originates from request input, session data, or other attacker-influenced sources-this is the highest-risk path in schema-per-tenant multi-tenant architectures. Second category: query builder or EntityManager find operations where filter keys (where/orderBy/groupBy/having/select parameter keys) or JSON property filters (JSONB column sub-keys in where clauses) are constructed from request parameters without validation against entity metadata-applications that pass req.query or req.body keys directly to em.find/qb.where are vulnerable. Third category: applications must use SQL dialects (all supported MikroORM SQL dialects are affected) rather than MongoDB driver. Maximum impact (multi-statement execution for data modification/deletion) additionally requires MSSQL dialect or MySQL/MariaDB with CLIENT_MULTI_STATEMENTS connection flag enabled (non-default for MySQL). Exploitation is limited by: database user privileges (attacker cannot escalate beyond ORM database connection user's grants), single-statement restriction on PostgreSQL/SQLite/default MySQL (limits to UNION-based data exfiltration without modification/deletion), and application architecture (apps using strict input validation, allowlists for schema names, or metadata-validated filter keys are not vulnerable despite using affected MikroORM versions). No special platform, non-default configuration, or user interaction required beyond authenticated API access-remote unauthenticated exploitation is NOT possible as all affected APIs are behind application authentication layers per typical ORM usage patterns.

Real-world risk is substantial for multi-tenant Node.js applications using MikroORM with user-controllable schema selection or JSON column filtering. CVSS 7.6 (HIGH) reflects network-accessible attack vector with low complexity but requires authenticated access (PR:L). The EPSS and KEV data are not provided, but the absence of CISA KEV listing suggests no confirmed widespread exploitation. However, the attack surface is broad: multi-tenant schema switching (em.fork with user-supplied schema), JSON property filters from request parameters, and query builder keys all flow through the vulnerable code paths. Impact is severe in multi-statement-capable dialects (MSSQL, MySQL with CLIENT_MULTI_STATEMENTS)-attackers gain full SQL execution within database user privileges, enabling cross-tenant data theft, privilege escalation, or data destruction via DROP/TRUNCATE. PostgreSQL and SQLite limit impact to single-statement injection but still permit confidentiality breaches via UNION-based extraction. The defense-in-depth failure is notable: applications already violating least-privilege principles by passing unsanitized request keys to query builders now face SQL injection on top of authorization bypass. Mitigation priority depends on deployment model-multi-tenant SaaS platforms using schema-per-tenant isolation should treat this as CRITICAL and patch immediately. Single-tenant or properly input-validated deployments face lower immediate risk but should still prioritize patching as this is a fundamental ORM security boundary violation.

An authenticated user in a multi-tenant SaaS application built with MikroORM submits a crafted API request containing a malicious schema name payload such as 'tenant_123" OR 1=1--' to an endpoint that calls em.fork({ schema: userInput }). The unescaped double-quote character breaks out of the PostgreSQL quoted identifier context, and the injected OR 1=1 clause bypasses tenant isolation in the generated WHERE clause, leaking data from all tenants. In a MySQL deployment with CLIENT_MULTI_STATEMENTS enabled, an attacker injects 'tenant"]; DROP TABLE users; --' which executes as a second statement, destroying the users table. Similarly, JSON property filtering via em.find(Entity, { settings: { [userKey]: value } }) with userKey='admin\'); DELETE FROM audit_log WHERE (\'' injects into the JSON path string literal, executing destructive queries on MSSQL. The low attack complexity (AC:L) and lack of required user interaction (UI:N) enable automated exploitation against any authenticated API endpoint accepting schema names or filter parameters from request input.