GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

cve.new
Check your stack
GHSA-7vw7-qx38-37vrcritical9.8No CVE assigned

Propel2 SQL injection possible with limit() on MySQL

Impact

The limit() query method is susceptible to catastrophic SQL injection with MySQL.

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

propel/propel Packagist
Affected rangeRecorded fix
From 2.0.0-alpha1 before 2.0.0-alpha8Ecosystem versions2.0.0-alpha8

Version evidence: OSV · GHSA-7vw7-qx38-37vr

View original version evidence (7 explicit versions)

Original source 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 Propel\Runtime\ActiveQuery\Criteria::setLimit() or in Propel\Runtime\Adapter\Pdo\MysqlAdapter::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.

References