@idsulik can you create a dedicated PR for the e2e flaky test fix please? I need to merge this one

@idsulik can you create a dedicated PR for the e2e flaky test fix please? I need to merge this one

Yes, working on it, can't find why it fails on GitHub while locally it works stably

Great work guys, can i assign it as a cve ?

@0pepsi No, please, you should have followed the recommendations in our security policy
to avoid disclosing the vulnerability before a fix was available.

I’m currently checking with our internal security team to determine the best process to follow.
We’ll get back to you shortly.

Sounds good, mb i thought the whole thing was over (: (👍

@0pepsi because this vulnerability was disclosed publicly, via a github issue, we had to urgently patch and release a new version, and bypass the proper workflow via a private Github Security Advisory and a CVE publication. Hence, no CVE will be issued for this.

Our security policy asks that researchers disclose secuity issues privately via [email protected] and follow a responsible disclosure policy which allows us to privately review a submission within 72 hours, and work on a patch before it is disclosed publicly (we ask for up to 90 days of keeping an issue confidential to allow us to properly patch depending on complexity).

We will now proceed to delete this issue. Please reach out directly to [email protected] with any follow-up questions or additional findings.

Thank you

Hence, no CVE will be issued for this.

So you aren't going to tell the world about the vulnerability because you didn't like the way it was disclosed?

We've taken a closer look at this issue and appreciated the feedback from community members. While our earlier statement about the CVE disclosure process was inaccurate, we want to clarify that, after further analysis, this is not a vulnerability in Docker Compose and does not warrant a CVE ID. We apologize for the confusion and are sharing the following technical details to provide more context.

Understanding the Reported Behavior
In order to trigger this specific issue and load a chosen file from the host via the git loader a potential attacker would need to manipulate the -f argument of the Compose command line. Using the Docker Compose CLI requires the same permissions as running any arbitrary workload on Docker Compose and also requires that the chosen file is accessible by the user, therefore there would be no confidentiality, integrity or availability impact. Other places where the git loader can be used are the "include" top level element or "extends" attribute in compose files but those also allow to specify any file the user has access to and setting them requires write access to the Compose file.

Considering a hypothetical scenario in which a third party application allows untrusted and unsanitized input to be injected into a part of the -f CLI option or in a part of an include or extends field of an otherwise trusted Compose file, that would be a vulnerability of the hypothetical third party application. That said, this PR fixes an actual bug which is the fact that the git loader used to accept an invalid input.