Someone has created bogus CVE reports for Symfony (CVE-2024-36611 and CVE-2024-36610).
You might experience warnings from `composer audit` or other tools about these bogus CVEs when using Symfony components <7.1.
These MUST BE IGNORED, the reports are NOT security issues.
We're trying to find out how we can solve this. If someone has experience with this, please let us know!
Fortunately, the biggest advisory databases in PHP have responded quickly and the bogus Symfony security advisories are withdrawn from Packagist, Roave and GitHub.
Hopefully this has mitigated the impact for all projects.
Thanks to everyone involved!
@wouterj in the longer term, probably having Symfony (and/or the PHP-src project) become its own ' CVE Numbering Authority' (I'd guess with the PHP Foundation?), like Curl did - https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/ and also the Linux Kernel project. Though the kernel appears to be flooding the ecosystem with everything, so no one knows what's serious anymore
There's also the issues of the split between PHP-core, large frameworks, and all the little libraries that have CVEs written up for them.
@heiglandreas @alister @wouterj in my German jurisdiction it is a proper nicht eingetragener Verein :)
However not sure why that is relevant for relationship with CVE/MITRE, who accepted the construct. And inside the PHP project Rasmus et al. delegate as needed.
Might be relevant when trying to sue, but that's a different mine field in itself.
@johannes It might not be relevant for CVE/MITRE per se. But the rather loose "organisation" of the PHP group makes it rather hard to actually get hold of someone responsible. And letting Rasmus delegate everything does not really scale
Having an entity that people actually can get hold of and that has a more formal structure makes it easier to get hold of. Not in a legal sense but in a plain "Whom can I talk to" sense.
But that'S just my 0.02 €
@heiglandreas @alister @wouterj I won't argue about that, as I am mostly out for 10+ years and thus can't judge.
In the years before I never struggled due to formal organisation, but simple limited amount of people involved. Limited knowledge over systems and stuff, limited amount of people having time to scan spam trap security@ etc. while people who showed up were empowered quickly (when not demotivated by some diva fights on internals, to which I maybe contributed too much)
Anyways, that ..
@heiglandreas @alister @wouterj .. that CVS CNE thing goes to security@, and I assume (while never being actively involved, just receiving the mails) anybody there could impersonate the Group and ask for more authority over more projects.
However security@ in current structure, I guess, won't be able to properly handle it on bigger scale.
@hleithner @alister thanks for the suggestion! We've started investigating this path to prevent this from happening in the future.
@wouterj Mautic became a CNA for this reason, there's a bit of training involved and processes to follow but it's minimal really, and perfectly manageable if you've got an existing security team.
@rcheesley thank you for the suggestion! We've started investigating this path today.
Aside: I'm a bit sad that OSS projects have to go through lengths like this to protect their users.
@wouterj yeah indeed, happy to chat if it's any help, we signed up a few years back now.