GHSA-9ggv-8w38-r7pm
MEDIUMTypeORM: SQL Injection in UpdateQueryBuilder/SoftDeleteQueryBuilder orderBy (MySQL/MariaDB)
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
typeormnpmDescription
Impact
Blind SQL injection vulnerability in UpdateQueryBuilder and SoftDeleteQueryBuilder affecting MySQL and MariaDB users.
UpdateQueryBuilder and SoftDeleteQueryBuilder (including their addOrderBy variants) do not validate the order parameter against an allowlist of permitted values (ASC/DESC). The caller-supplied value is stored verbatim and concatenated directly into the generated SQL string without quoting or parameterization. SelectQueryBuilder.orderBy performs this validation correctly; the affected builders do not.
If any code path passes user-controlled input to orderBy/addOrderBy on an update or soft-delete query, an attacker can inject arbitrary SQL via the sort direction — even when the column name itself is hardcoded.
Demonstrated impact includes:
- Data exfiltration via time-based blind extraction (e.g. using
SLEEP()to infer secret values bit by bit) - Row targeting manipulation in queries using
LIMITpatterns - Denial of service via
SLEEP()-based query exhaustion
CVSS 3.1: 8.6 (High) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Affected files (relative to commit 73fda419):
src/query-builder/UpdateQueryBuilder.ts: lines 383–419 and 718–744src/query-builder/SoftDeleteQueryBuilder.ts: lines 352–388 and 520–546
The vulnerability was introduced in commit 03799bd2 (v0.1.12) and is present through the latest release (v0.3.28).
Patches
A fix has been released in 0.3.29 (1b66c44) and 1.0.0 (93eec63).
Workarounds
Applications can manually validate the order argument before passing it to orderBy or addOrderBy on update or soft-delete query builders:
const direction = userInput.toUpperCase();
if (direction !== 'ASC' && direction !== 'DESC') {
throw new Error('Invalid sort direction');
}
qb.orderBy(column, direction as 'ASC' | 'DESC');
Do not pass user-controlled values to orderBy/addOrderBy on UpdateQueryBuilder or SoftDeleteQueryBuilder without this validation.
References
- Introduced in commit 03799bd2 (v0.1.12)
- Confirmed present in v0.3.28 (commit 73fda419)
- See
SelectQueryBuilder.orderByfor the correct validation pattern this fix should mirror
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | typeorm | ≥ 0.1.12&&< 0.3.29 | 0.3.29 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for typeorm. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update typeorm to 0.3.29 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9ggv-8w38-r7pm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9ggv-8w38-r7pm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9ggv-8w38-r7pm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9ggv-8w38-r7pm in your dependencies?
O3 detects GHSA-9ggv-8w38-r7pm across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.