GHSA-7g7c-qhf3-x59p
propel/propel1 SQL injection possible with limit() on MySQL
GHSA-7g7c-qhf3-x59p is a critical vulnerability (CVSS 9.8) in propel/propel1, published May 20, 2024. No source lists public exploit code. Fixed in propel/propel1 1.7.2.
- Severity
- 9.8 CriticalCVSS 3.1, GitHub Advisories
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
1.7.2propel/propel1 +1 more
Description
The limit() query method is susceptible to catastrophic SQL injection with MySQL.
For example, given a model User for a table users:
UserQuery::create()->limit('1;DROP TABLE users')->find();
This will drop the users table!
The cause appears to be a lack of integer casting of the limit input in either Criteria::setLimit() or in DBMySQL::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers.
This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection.
This affects all versions of Propel: 1.x, 2.x, and 3.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Affected packages
| Package | Affected | Fixed |
|---|---|---|
propel/propel1Packagist | 1 to 1.7.1 | 1.7.2 |
propel/propel1Packagist | 1 up to 1.7.2, plus listed versions 1.6.21.6.31.6.41.6.51.6.6 Show 5 moreShow less1.6.71.6.81.6.91.7.01.7.1 | 1.7.2 |
What each source reports
GitHub Advisories Score used
propel/propel1 SQL injection possible with limit() on MySQL
The limit() query method is susceptible to catastrophic SQL injection with MySQL.
For example, given a model User for a table users:
UserQuery::create()->limit('1;DROP TABLE users')->find();
This will drop the users table!
The cause appears to be a lack of integer casting of the limit input in either Criteria::setLimit() or in DBMySQL::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers.
This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection.
This affects all versions of Propel: 1.x, 2.x, and 3.
- Record
GHSA-7g7c-qhf3-x59p- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
OSV
propel/propel1 SQL injection possible with limit() on MySQL
The limit() query method is susceptible to catastrophic SQL injection with MySQL.
For example, given a model User for a table users:
UserQuery::create()->limit('1;DROP TABLE users')->find();
This will drop the users table!
The cause appears to be a lack of integer casting of the limit input in either Criteria::setLimit() or in DBMySQL::applyLimit(). The code comments there seem to imply that casting was avoided due to overflow issues with 32-bit integers.
This is surprising behavior since one of the primary purposes of an ORM is to prevent basic SQL injection.
This affects all versions of Propel: 1.x, 2.x, and 3.
- Record
GHSA-7g7c-qhf3-x59p- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
References
github.com/propelorm/Propel/issues/1052