GHSA-9ggv-8w38-r7pm

What it actually does

TypeORM versions before 0.3.29 contain a SQL injection flaw in the MySQL/MariaDB query generation path for UpdateQueryBuilder and SoftDeleteQueryBuilder when orderBy is used. If an application passes attacker-controlled column names, sort expressions, or sort directions into orderBy for update or soft-delete operations, TypeORM may place that input into the generated SQL without sufficient identifier validation. The attacker’s input is interpreted by the database as SQL rather than data. Exploitation is generally constrained to the ORDER BY context, but can still enable blind/time-based data extraction, query manipulation, database errors, denial of service through expensive expressions, or broader modification of data depending on query structure, database privileges, and MySQL/MariaDB driver settings such as whether stacked statements are allowed.

Why it matters to the business

Applications using affected TypeORM versions with MySQL or MariaDB may be vulnerable if they expose user-controlled sorting or ordering fields in update or soft-delete workflows. A successful attack could corrupt or improperly modify records, expose sensitive database contents through blind SQL injection techniques, disrupt application availability, or undermine trust in data integrity. The issue is not currently listed in CISA KEV, has no known mature public exploitation in the provided intelligence, and has a moderate CVSS score, but it affects a widely used npm ORM and should be addressed promptly, especially in internet-facing applications and services that map API parameters directly into query builder orderBy calls.

How an attack unfolds

An attacker first identifies an application endpoint that performs an update or soft-delete operation through TypeORM against MySQL or MariaDB and accepts a user-controllable sort/order parameter. The attacker supplies a crafted value intended to escape the expected column or direction syntax inside the generated ORDER BY clause. TypeORM builds the SQL query using the unsafe orderBy value, and the database evaluates the injected SQL fragment. The attacker then iterates payloads to confirm injection through syntax errors, timing differences such as sleep-based probes, or observable changes in affected records. If exploitable, the attacker may use blind SQL injection methods to infer database values, alter which rows are updated or soft-deleted where query structure permits, trigger expensive database operations for denial of service, or attempt stacked statements if the MySQL/MariaDB driver and connection configuration allow multiple statements.

How to fix it

Upgrade TypeORM to version 0.3.29 or later. For npm-based projects, update package manifests and lockfiles, then rebuild and redeploy all affected services. If immediate upgrade is not possible, prevent untrusted input from reaching UpdateQueryBuilder.orderBy or SoftDeleteQueryBuilder.orderBy. Use strict allowlists that map external sort keys to known safe database column identifiers, allow only explicit directions such as ASC or DESC, and reject free-form SQL expressions. Do not rely on parameter binding for SQL identifiers; parameters protect values, not column names or raw SQL fragments. Disable MySQL/MariaDB multiple statements unless there is a strong business requirement. Ensure application database users have only the minimum privileges required, so exploitation cannot perform broad schema changes or unauthorized reads. Add application-level validation and tests for update and soft-delete code paths that accept ordering controls.

How to confirm the fix worked

Confirm deployed applications use TypeORM 0.3.29 or later by checking package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, container images, build artifacts, and runtime dependency output such as npm ls typeorm. Verify that no vulnerable dependency remains in transitive or bundled application artifacts. Review code for UpdateQueryBuilder or soft-delete flows that call orderBy with request-derived values, including aliases such as sort, order, field, column, direction, and orderBy. Test affected endpoints with benign invalid sort values and confirm they are rejected before query execution. Enable SQL logging in a safe test environment and verify generated MySQL/MariaDB UPDATE or soft-delete statements do not contain raw external input in ORDER BY clauses. Run SCA tooling after remediation and confirm the advisory is cleared.

Typical attack path

1. Identify a web/API endpoint backed by TypeORM that performs update or soft-delete operations.
2. Determine whether the endpoint accepts a sort, order, orderBy, column, field, or direction parameter.
3. Submit malformed ORDER BY values and observe SQL errors, response differences, timing changes, or unexpected update/delete behavior.
4. Confirm database execution using MySQL/MariaDB-specific syntax or time-delay probes in the ORDER BY context.
5. Use blind SQL injection techniques to infer database information or manipulate query behavior within the limits of the generated statement.
6. If database driver settings permit stacked statements, attempt to execute additional SQL statements.
7. Leverage exposed data, corrupted records, or application disruption for further compromise or operational impact.

How to detect it

Look for evidence of attempted SQL injection against endpoints that perform update or soft-delete operations and accept ordering or sorting parameters. Useful sources include application access logs, API gateway logs, WAF events, application error logs, ORM/query logs, MySQL/MariaDB general logs, slow query logs, audit logs, and database error logs. Focus on requests containing sort/order/orderBy/field/column/direction parameters with SQL metacharacters, comments, MySQL functions, time-delay functions, subqueries, or stacked-statement separators. In database logs, review UPDATE statements and soft-delete-style UPDATE statements that include unexpected ORDER BY expressions rather than known column names. Investigate SQL syntax errors, unknown column errors, delayed queries, repeated probing of ordering parameters, and bursts of update or soft-delete operations affecting unusual row counts. If query logging was not enabled historically, correlate suspicious HTTP requests with application errors, database latency spikes, and unexpected data modification events.

• sort=
• order=
• orderBy=
• field=
• column=
• direction=
• SLEEP(
• BENCHMARK(
• IF(
• CASE WHEN
• EXTRACTVALUE(
• UPDATEXML(
• INFORMATION_SCHEMA
• --
• /*
• #
• ;
• ORDER BY SLEEP
• ORDER BY BENCHMARK
• ER_PARSE_ERROR
• ER_BAD_FIELD_ERROR
• You have an error in your SQL syntax
• Unknown column

What your security team should do

• Upgrade all applications using TypeORM with MySQL or MariaDB to TypeORM 0.3.29 or later as the primary remediation.
• Prioritize internet-facing APIs, administrative interfaces, and services that expose sorting or ordering options for update or soft-delete operations.
• Perform code review for QueryBuilder.update, createQueryBuilder().update, softDelete, restore, and orderBy combinations where order values may originate from HTTP parameters, GraphQL arguments, message payloads, or job inputs.
• Add centralized allowlist helpers for sortable fields and directions so application code never passes raw user input into orderBy.
• Check MySQL/MariaDB connection configuration and disable multipleStatements unless explicitly required.
• Review database account privileges for affected applications and remove unnecessary schema, administrative, file, or cross-database privileges.
• Enable or increase logging for suspicious SQL errors, time-delay functions, and anomalous update/soft-delete activity during the investigation window.
• Because the issue is 52 days past publication, verify that older container images, serverless bundles, and long-lived deployments were not missed by dependency updates.