[GHSA-p436-gjf2-799p] Docker CLI Plugins: Uncontrolled Search Path Element Leads to Local Privilege Escalation on Windows

[levpachmanov]

Updates

• Affected products

Comments
As shown by the references, the vulnerability affects github.com/docker/cli and has been fixed there. Docker Compose simply uses this library as a dependency and should not be flagged on its own.

[helixplant]

Hi,
Those packages were intentionally included in the original advisory which is why they are listed as affected here. I’m looping in @thaJeztah on this matter for more insight on if github.com/docker/compose/v2 and github.com/docker/compose/v5 should be receiving separate alerts.

[thaJeztah]

Yeah, compose was impacted through that dependency, so probably fine to exclude it; not sure what common practice is for this?

[helixplant]

@thaJeztah it depends on how the dependencies are structured. If a user can upgrade the vulnerable dependency on github.com/docker/cli without changing the version of github.com/docker/compose/v2 or github.com/docker/compose/v5 they use, there's no need to have github.com/docker/compose/v2 and github.com/docker/compose/v5 listed as vulnerable products. If a vulnerable version of github.com/docker/cli is hard coded into github.com/docker/compose/v2 and github.com/docker/compose/v5, they should stay listed as affected products.

[levpachmanov]

As I understand it, the common practice is to mark the library that is actually vulnerable. If it is in use, an SCA scanner will flag the artifact as vulnerable.
Otherwise, the advisory would need to include every indirect dependency that relies on this library.

[schneidergithub]

I have seen advisories include downstream dependencies, in my opinion it's useful info. Maybe the best middle ground is to keep it listed, but update the advisory that compose is affected through the bundled/pinned CLI dependency, rather than being the original source of the bug. I am not a GO expert, but my understanding is the compose module is immutable and it would make sense to keep it in the advisory.

[levpachmanov]

@schneidergithub - I see where you’re coming from, but I don’t agree that keeping it listed is the right approach.

Including downstream dependencies in this way can be misleading. It implies that the compose module itself is inherently affected, when in practice users have flexibility - they can swap the module for a custom fork or pull it in as part of their dependency tree with a different version of the CLI. So the relationship isn’t as fixed as the advisory might suggest.

Because of that, attributing the issue to compose (even with clarification about the bundled/pinned CLI) risks overstating its role and potentially confusing users about where the vulnerability actually originates.