MikroORM SQL Injection via Duck-Type Object Marker Detection

Vulnerability Description

MikroORM versions up to 6.6.9 (v6 branch) and 7.0.5 (v7 branch) are vulnerable to SQL injection due to improper detection of internal ORM marker properties. The vulnerability stems from duck-typing logic that checks for specific property names to identify ORM-internal objects. An attacker can create specially crafted objects containing these marker properties, causing the ORM to misclassify untrusted input as internal ORM data and pass it directly into SQL query construction without sanitization.

Root Cause & Impact

The root cause is the use of property name matching (string-based detection) rather than cryptographic or symbol-based verification to distinguish legitimate ORM objects from user-provided data. When untrusted objects reach ORM write methods—such as wrap().assign(), em.create(), em.nativeUpdate(), or em.nativeInsert()—the ORM's duck-type checks fail to reject malicious input. This can result in arbitrary SQL injection, enabling data exfiltration, modification, deletion, or authentication bypass depending on database permissions and query context.

Detection Guidance

Application-Level Monitoring:

• Log all calls to em.nativeUpdate(), em.nativeInsert(), and direct assign() operations with user input
• Monitor for objects with suspicious property names matching known ORM internal markers (e.g., properties like __orm, __ref, or similar framework-specific indicators)
• Track TypeScript/JavaScript runtime type mismatches: instances of plain objects being passed where typed entities are expected

Query Analysis:

• Inspect SQL logs for multi-statement executions or UNION-based patterns originating from ORM execution paths
• Alert on SQL syntax anomalies in parameterized queries that should have strict structure
• Correlation rule: trigger on assign() or nativeUpdate() calls followed by unexpected SQL syntax in query logs

Mitigation & Patching

Immediate Actions:

1. Upgrade: Apply patches to MikroORM >6.6.9 and >7.0.5, which replace duck-typed property checks with Symbol-based markers that cannot be forged by user input
2. Input Validation: Enforce strict schema validation and type checking before any data reaches ORM write methods. Use Zod, Joi, or class-validator to validate input shape and types
3. Least Privilege: Ensure database credentials used by the application have minimal required permissions (no DROP, CREATE, or multi-statement execution if unnecessary)

Configuration Changes:

• Disable nativeUpdate() and nativeInsert() if dynamic queries aren't required; use typed ORM APIs exclusively
• Implement middleware to sanitize and validate all incoming request data before ORM interaction

Risk Assessment

Likelihood of Exploitation: High in vulnerable codebases that accept JSON payloads or form data and directly pass unsanitized objects to ORM methods. Lower risk for applications with strict input validation layers.

Threat Actor Interest: This vulnerability is attractive to attackers targeting web applications with inadequate input validation. The barrier to exploitation is moderate—requires identifying a code path where user objects bypass validation—but impact is severe.

In-the-Wild Prevalence: Likely moderate; Node.js/Nest.js applications using MikroORM for data persistence are common targets, particularly smaller teams or rapid-development projects that may skip robust input validation.