GHSA-65v8-q222-64xx: compose-lint: `fix --apply` can delete a line the user did not select, including a security setting
compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.9.0 until 0.18.0, compose-lint's YAML parser recognizes lone carriage returns and Unicode line separators U+0085, U+2028, and U+2029 as line breaks while fix position conversion counts only newline characters. A pull request can place one of these separators in a quoted value so fix --apply shifts each later edit and deletes the line after the selected target, including an unselected network or other security setting. The resulting Compose file can remain valid, post-edit checks can pass, and the command can report a successful fix even though the dry-run diff was the only place showing the extra deletion. This issue is fixed in version 0.18.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
compose-lintto a version that resolves this vulnerability.Fixed in 0.18.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users of compose-lint versions 0.9.0 through versions before 0.18.0 are affected when they run fix --apply on a Compose file containing a lone carriage return or Unicode U+0085, U+2028, or U+2029 in a quoted value before the intended edit.
What does an attacker need to do to trigger the unintended deletion?
An attacker needs to get a crafted Compose-file change, such as through a pull request, reviewed and then have a user run fix --apply. The crafted separator must appear in a quoted value so later edit positions are shifted.
How can teams detect whether a fix changed more than intended?
Review the dry-run diff before applying fixes, because it is the only stated place where the extra deletion is shown. Do not rely solely on a successful command result or post-edit checks, since the resulting Compose file can remain valid and those checks can pass.
What should be done if updating is not immediately possible?
Avoid applying fixes automatically to untrusted or newly submitted Compose files, and manually inspect the dry-run diff before using fix --apply. Pay particular attention to quoted values containing lone carriage returns or Unicode U+0085, U+2028, or U+2029 separators.
Which version fixes the issue?
The issue is fixed in compose-lint version 0.18.0.