CVE-2025-60542: SQL Injection
Summary
SQL Injection vulnerability in TypeORM before 0.3.26 via crafted request to repository.save or repository.update due to the sqlstring call using stringifyObjects default to false.
Details
Vulnerable Code:
js const { username, city, name} = req.body; const updateData = { username, city, name, id:userId }; // Developer aims to only allow above three fields to be updated const result = await userRepo.save(updateData);
Intended Payload (non-malicious):
username=myusername&city=Riga&name=Javad
OR
{username:\"myusername\",phone:12345,name:\"Javad\"}
SQL query produced:
sql UPDATE user SET username = 'myusername', city = 'Riga', name = 'Javad' WHERE id IN (1);
Malicious Payload:
username=myusername&city[name]=Riga&city[role]=admin
OR
{username:\"myusername\",city:{name:\"Javad\",role:\"admin\"}}
SQL query produced with Injected Column:
sql UPDATE user SET username = 'myusername', city = name = 'Javad', role = 'admin' WHERE id IN (1);
Above query is valid as city = name = Javad is a boolean expression resulting in city = 1 (false). “role” column is injected and updated.
Underlying issue was due to TypeORM using mysql2 without specifying a value for the stringifyObjects option. In both mysql and mysql2 this option defaults to false. This option is then passed into SQLString library as false. This results in sqlstring parsing objects in a strange way using objectToValues.
Affected Software
Event History
Frequently Asked Questions
Which applications are exposed?
Applications using TypeORM versions before 0.3.26 are exposed when attacker-controlled request data is passed to repository.save or repository.update. The affected input includes fields that can be supplied as nested objects rather than expected scalar values.
Does exploitation require authentication or user interaction?
The CVSS vector indicates no privileges and no user interaction are required. In practice, an attacker must be able to send a crafted request to an application endpoint that forwards the relevant input to repository.save or repository.update.
Are default settings affected?
Yes. The issue is attributed to the sqlstring call with stringifyObjects using its default value of false, so applications relying on that default behavior are affected.
What should be done if the application is vulnerable?
Update TypeORM to version 0.3.26 or later. Until updating, ensure request fields passed to repository.save or repository.update are validated as expected scalar types and do not accept nested object values.
How can I identify potentially affected code paths?
Check for TypeORM versions earlier than 0.3.26 and find uses of repository.save or repository.update that receive data derived from HTTP request bodies. Pay particular attention to fields expected to be strings that can be submitted using nested request parameters or JSON objects.