GHSA-9GGV-8W38-R7PM
Vulnerability from github – Published: 2026-06-19 19:18 – Updated: 2026-06-19 19:18Impact
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 LIMIT patterns
- 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–744
- src/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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.28"
},
"package": {
"ecosystem": "npm",
"name": "typeorm"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.12"
},
{
"fixed": "0.3.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-89"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T19:18:49Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nBlind SQL injection vulnerability in `UpdateQueryBuilder` and `SoftDeleteQueryBuilder` affecting MySQL and MariaDB users.\n\n`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.\n\nIf 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 \u2014 even when the column name itself is hardcoded.\n\nDemonstrated impact includes:\n- **Data exfiltration** via time-based blind extraction (e.g. using `SLEEP()` to infer secret values bit by bit)\n- **Row targeting manipulation** in queries using `LIMIT` patterns\n- **Denial of service** via `SLEEP()`-based query exhaustion\n\nCVSS 3.1: **8.6 (High)** \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L`\n\nAffected files (relative to commit `73fda419`):\n- `src/query-builder/UpdateQueryBuilder.ts`: lines 383\u2013419 and 718\u2013744\n- `src/query-builder/SoftDeleteQueryBuilder.ts`: lines 352\u2013388 and 520\u2013546\n\nThe vulnerability was introduced in commit `03799bd2` (v0.1.12) and is present through the latest release (v0.3.28).\n\n### Patches\n\nA fix has been released in 0.3.29 (1b66c44) and 1.0.0 (93eec63).\n\n### Workarounds\n\nApplications can manually validate the `order` argument before passing it to `orderBy` or `addOrderBy` on update or soft-delete query builders:\n\n```ts\nconst direction = userInput.toUpperCase();\nif (direction !== \u0027ASC\u0027 \u0026\u0026 direction !== \u0027DESC\u0027) {\n throw new Error(\u0027Invalid sort direction\u0027);\n}\nqb.orderBy(column, direction as \u0027ASC\u0027 | \u0027DESC\u0027);\n```\n\nDo not pass user-controlled values to `orderBy`/`addOrderBy` on `UpdateQueryBuilder` or `SoftDeleteQueryBuilder` without this validation.\n\n### References\n\n- Introduced in commit 03799bd2 (v0.1.12)\n- Confirmed present in v0.3.28 (commit 73fda419)\n- See `SelectQueryBuilder.orderBy` for the correct validation pattern this fix should mirror",
"id": "GHSA-9ggv-8w38-r7pm",
"modified": "2026-06-19T19:18:49Z",
"published": "2026-06-19T19:18:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/typeorm/typeorm/security/advisories/GHSA-9ggv-8w38-r7pm"
},
{
"type": "WEB",
"url": "https://github.com/typeorm/typeorm/commit/1b66c44d0410bdc56a0dcefb46be41867ec0fffc"
},
{
"type": "WEB",
"url": "https://github.com/typeorm/typeorm/commit/93eec630630b219b162ba4e0c072afa851697cff"
},
{
"type": "PACKAGE",
"url": "https://github.com/typeorm/typeorm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "TypeORM: SQL Injection in UpdateQueryBuilder/SoftDeleteQueryBuilder orderBy (MySQL/MariaDB)"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.