This, as well as CVE-2024-36610 (GHSA-cg28-v4wq-whv5) also need back-porting to Symfony 5.4.

Those CVE have not been declared by the Symfony team. Apparently, someone reported CVEs for things that were considered regular bugfixes.

Actually, the change in security-http was considered to be a feature.

Either they are security issues and should be backported to 6.x and 5.x, or they are not security issues. In which case the advistories should be withdrawn, as well as the roave/security-advisories entries.

We determined this as 'security hardening', which we always consider features per our maintenance policy.

Unfortunately, everyone can submit CVEs to MITRE without communicating this with the Symfony team. We're currently looking for ways to withdraw this incorrect CVE, but this isn't something we have any more control over.

the advistories should be withdrawn

We cannot withdraw what we haven't issued, can we?

@derrabus indeed, we cannot. We would have to manage to convince MITRE to reject those CVEs. And this is not easy.
For instance, curl went as far as becoming a CNA themselves to be able to avoid bogus CVEs (by being the sole CNA allowed to issue CVEs for curl). See some of the articles in the security category of badger's blog if you don't know that story yet.

Can we instead convince Composer to ignore those bogus CVEs? Might we easier after all.

cc @naderman @Seldaek

@derrabus You can configure an ignore locally:

        "audit": {
            "abandoned": "report",
            "ignore": {
                "GHSA-7q22-x757-cmgc": "Bogus",
                "GHSA-cg28-v4wq-whv5": "Bogus"
            }
        }

@bobvandevijver Yes, but if I configure that locally, it won't help anyone but myself.

FWIW looking through the gists on the account linked in the CVE there is a reference to an invalid vulnerability report in curl: https://curl.se/docs/CVE-2023-52071.html

See also Daniel Stenberg's take on these bogus reports.

the advistories should be withdrawn

We cannot withdraw what we haven't issued, can we?

Symfony can al least work with roave/security-advisories to get the entries reverted for the bogus CVE's so that we can use the security-advisories package for real security issues.

We've just updated the DB to ignore those in packagist.org so composer audit is green again.

Thank you Jordi!!

Any hints about how/who created these bogus entries? Something is very wrong here, that's a supply chain attack vector.

Both advisories reference gists created by the same person who seems to be blogging about security https://1047524396.github.io

References
[...]
https://gist.github.com/1047524396/24e93f2905850235e42ad7db6e878bd5
https://github.com/symfony/symfony/blob/v7.0.3/src/Symfony/Component/VarDumper/Cloner/Stub.php#L53

@1047524396 Are you the one who created these advisories? 👀

@nicolas-grekas you should read the post by the curl maintainer @fritzmg linked above: https://daniel.haxx.se/blog/2024/02/21/disputed-not-rejected/ - it's indeed a problem of the CVE system.

We've just updated the DB to ignore those in packagist.org so composer audit is green again.

Thank you !

Is there something to do to ignore this also with roave/security-advisories ?

@jeckel see Roave/SecurityAdvisoriesBuilder#756

It would be nice to have a blog post about this that would inform a bit more widely, because at first I didn't understand why if there is CVE, it doesn't apply to the 5.x branch. I had a hard time putting together that it was created by bypassing the security team.

CVE ignored by Packagist (composer audit)
Advisory ignored by roave/security-advisories
Advisory withdrawn by GitHub
Revocation of CVE by mitre.org in progress

We can close this issue.