GHSA-vgf9-9mxx-hq54: Path Traversal
Impact A path traversal vulnerability in the revision command allowed a crafted migration name supplied via the -m argument to escape the intended migrations directory.
Under specific conditions, an attacker could cause the tool to create a .sql file in an arbitrary location writable by the user executing the command.
This issue is only exploitable if an attacker can influence the migration name passed to the revision command, such as through an insecure automation or CI/CD pipeline that forwards untrusted input.
Patches The vulnerability has been fixed in version 1.0.3 by validating and sanitizing the migration name to prevent directory traversal.
Users should upgrade to version 1.0.3 or later.
Workarounds Do not pass untrusted input to the revision -m argument.
If upgrading is not immediately possible, ensure that only trusted users or automation can invoke the revision command and that migration names are validated before being passed to the tool.
References - Fix commit: https://github.com/QueueForge/ClickMigrate/commit/6b1f2c0202630a82252b3331aa57e64327e112b6
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/ClickMigrateto a version that resolves this vulnerability.Fixed in 1.0.3 - Upgrade
Upgrade
QueueForge/ClickMigrateto a version that resolves this vulnerability.Fixed in 1.0.3 - Compensating control
Do not pass untrusted input to the revision -m argument; restrict invocation of the revision command to trusted users or automation, and validate migration names before passing them to the tool.
Event History
Frequently Asked Questions
Who is realistically exposed to exploitation?
Exposure requires an attacker to influence the migration name supplied to the revision command's -m argument. This can occur in insecure automation or CI/CD pipelines that forward untrusted input to the command.
What can an attacker do if they exploit this issue?
A crafted migration name can traverse outside the intended migrations directory and cause creation of a .sql file in an arbitrary location writable by the user running the command. The issue does not provide the ability to write where that executing user lacks permission.
Are normal local uses affected by default?
The issue is only exploitable when untrusted input can reach revision -m. Environments where trusted users supply migration names directly are not exposed through that input path.
What should be done if an upgrade cannot happen immediately?
Do not pass untrusted input to revision -m. Restrict invocation of the revision command to trusted users or automation, and validate migration names before passing them to the tool.
Which version contains the fix?
The vulnerability is fixed in version 1.0.3. Upgrade to version 1.0.3 or later.