Headline
GHSA-wrh9-cjv3-2hpw: Sequelize vulnerable to SQL Injection via replacements
Impact
The SQL injection exploit is related to replacements. Here is such an example:
In the following query, some parameters are passed through replacements, and some are passed directly through the where option.
User.findAll({
where: or(
literal('soundex("firstName") = soundex(:firstName)'),
{ lastName: lastName },
),
replacements: { firstName },
})
This is a very legitimate use case, but this query was vulnerable to SQL injection due to how Sequelize processed the query: Sequelize built a first query using the where option, then passed it over to sequelize.query which parsed the resulting SQL to inject all :replacements.
If the user passed values such as
{
"firstName": "OR true; DROP TABLE users;",
"lastName": ":firstName"
}
Sequelize would first generate this query:
SELECT * FROM users WHERE soundex("firstName") = soundex(:firstName) OR "lastName" = ':firstName'
Then would inject replacements in it, which resulted in this:
SELECT * FROM users WHERE soundex("firstName") = soundex('OR true; DROP TABLE users;') OR "lastName" = ''OR true; DROP TABLE users;''
As you can see this resulted in arbitrary user-provided SQL being executed.
Patches
The issue was fixed in Sequelize 6.19.1
Workarounds
Do not use the replacements and the where option in the same query if you are not using Sequelize >= 6.19.1
References
See this thread for more information: https://github.com/sequelize/sequelize/issues/14519
Snyk: https://security.snyk.io/vuln/SNYK-JS-SEQUELIZE-2932027
- GitHub Advisory Database
- GitHub Reviewed
- CVE-2023-25813
Sequelize vulnerable to SQL Injection via replacements
Critical severity GitHub Reviewed Published Feb 22, 2023 in sequelize/sequelize • Updated Feb 22, 2023
Package
npm sequelize (npm)
Affected versions
< 6.19.1
Impact
The SQL injection exploit is related to replacements. Here is such an example:
In the following query, some parameters are passed through replacements, and some are passed directly through the where option.
User.findAll({ where: or( literal('soundex(“firstName”) = soundex(:firstName)'), { lastName: lastName }, ), replacements: { firstName }, })
This is a very legitimate use case, but this query was vulnerable to SQL injection due to how Sequelize processed the query: Sequelize built a first query using the where option, then passed it over to sequelize.query which parsed the resulting SQL to inject all :replacements.
If the user passed values such as
{ "firstName": "OR true; DROP TABLE users;", "lastName": “:firstName” }
Sequelize would first generate this query:
SELECT * FROM users WHERE soundex(“firstName”) = soundex(:firstName) OR “lastName” = ‘:firstName’
Then would inject replacements in it, which resulted in this:
SELECT * FROM users WHERE soundex(“firstName”) = soundex(‘OR true; DROP TABLE users;’) OR “lastName” = ‘’OR true; DROP TABLE users;’’
As you can see this resulted in arbitrary user-provided SQL being executed.
Patches
The issue was fixed in Sequelize 6.19.1
Workarounds
Do not use the replacements and the where option in the same query if you are not using Sequelize >= 6.19.1
References
See this thread for more information: sequelize/sequelize#14519
Snyk: https://security.snyk.io/vuln/SNYK-JS-SEQUELIZE-2932027
References
- GHSA-wrh9-cjv3-2hpw
- https://nvd.nist.gov/vuln/detail/CVE-2023-25813
- sequelize/sequelize#14519
- sequelize/sequelize@ccaa399
- https://github.com/sequelize/sequelize/releases/tag/v6.19.1
- https://security.snyk.io/vuln/SNYK-JS-SEQUELIZE-2932027
Published by the National Vulnerability Database
Feb 22, 2023
Published to the GitHub Advisory Database
Feb 22, 2023
Last updated
Feb 22, 2023
Related news
Sequelize is a Node.js ORM tool. In versions prior to 6.19.1 a SQL injection exploit exists related to replacements. Parameters which are passed through replacements are not properly escaped which can lead to arbitrary SQL injection depending on the specific queries in use. The issue has been fixed in Sequelize 6.19.1. Users are advised to upgrade. Users unable to upgrade should not use the `replacements` and the `where` option in the same query.