https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-08T23:22:42.713972+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/euvd-2026-321468 EUVD-2026-321468 2026-10-08T23:22:43.037629+00:00 EUVD-2026-321468 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44680 fkie_cve-2026-44680 2026-10-08T23:22:43.037667+00:00

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.

 https://cve.radiocsirt.org/vuln/ghsa-cfw5-68c4-ffqp GHSA-cfw5-68c4-ffqp — MikroORM has SQL injection via runtime-controlled identifiers and JSON-path keys 2026-10-08T23:22:43.037706+00:00

Affected: npm: @mikro-orm/sql, npm: @mikro-orm/knex

## 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 `schema` option** — `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.where` JSON-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.select` keys** — keys containing `.` or `::` bypassed the structured-where metadata validator in `CriteriaNode`, then flowed through the same broken `quoteIdentifier`. Apps that forwarded raw filter keys from…