Comment by john_strinlai
14 hours ago
if you received the information about the RCEs without the information about the embargo, then you did not break the embargo. someone else up the chain did.
this whole saga will be analyzed and we'll all come out better for it at the end.
> if you received the information about the RCEs without the information about the embargo, then you did not break the embargo.
Doesn't responsible disclosure also apply? If I become aware of a vulnerability that doesn't seem to be widely known shouldn't I first attempt to report the issue responsibly?
In this case it appears the OP did know about the embargo "A reliable source has indicated an announcement is scheduled". I think that with security disclosures it is assumed they are not supposed to be publicized before the announcement, but if he hadn't known about the announcement and only heard about the RCEs, then publicly announcing their existence doesn't seem OK either.
Just FYI, "responsible disclosure" is a term that many people (like me) dislike because it carries judgment about the merits of public disclosure that are not at all obvious.
This term came from an era where companies or projects were disrespectful and dismissive towards security researchers. Those orgs were generally bad risk practitioners, and they coined the term "responsible disclosure" to mean "you send us the info and we'll do whatever we want with it, for however long we want, etc".
Many security people (like me) prefer the term "coordinated disclosure" as a way to indicate a practice where both discoverer and patcher participate in a good faith, communicative, and timely process to get things fixed for the community.
The difference can be summed up like this: if I report vulnerability X to company Y, and company Y sits on it for 3 years, that is not responsible. It is more "responsible" (especially today) to report it to the public, so they can protect themselves in a non-official-patch way, because the likelihood of bad guys knowing about it and exploiting it are approaching near-certainty.
These terms are obviously not super scientific, but I try to point out the history whenever it comes up.
That approach to disclosure is about discovering vulnerabilities. Talking about something with a published CVE isn't really comparable.
I don't understand your point. A published CVE is already public and thus there's nothing really to disclose?
1 reply →
> Doesn't responsible disclosure also apply? If I become aware of a vulnerability that doesn't seem to be widely known shouldn't I first attempt to report the issue responsibly?
Did they assume the information came from upstream php? I think if i got a new version of php that i thought was coming from official sources, i would assume there is nothing to responsibly disclose.
Doesn't the embargo end when the CVE is published? I thought that's the whole point in CVE allocate != CVE publish.
It's not a press embargo in the sense that the whole package of information becomes public once the embargo expires. There will be a published record on the cve.org, but often those who initiated the embargo insist that key details related to the vulnerability remain private even after the existence of the vulnerability and its remediation have been published.
Consider this example:
https://www.cve.org/CVERecord?id=CVE-2026-113119
At this time, the corresponding Chromium bug tracker entry is still private:
https://issues.chromium.org/issues/557075191
(I just picked this one at random, I haven't checked if the information is publicly available from another source.)
No, a CVE being assigned or allocated can happen well in advance. It's just requesting an identifier and it can be reserved very early.
For example: https://www.cve.org/CVERecord?id=CVE-2026-50000
I think that's what they're saying.
Assigning the CVE happens much earlier than actually publishing, but it's the latter that ends the embargo.
No, CVEs can be allocated before a vulnerability has even been found!
Not sure that contradicts the claim. Publishing the CVE is what makes it public.
1 reply →
[flagged]
By now I've seen at least 5 different people or companies blamed for leaks or releasing fixes early.
If anyone is at fault here, I'm looking at the PHP maintainers.
The embargo apparently held for like two months, during which they have not managed to release patches.
AFAIK it's pretty much to allow the security cabal of companies that get the early access to fix their stuff first before the dirty public can be granted privilege of fixing the bugs.
1 reply →
> If anyone is at fault here, I'm looking at the PHP maintainers.
There's a reason the moniker PHP was "pretty horrible programming".
And well, things haven't changed in that regard.
If you're seriously asking whether or not it's possible that someone was overconfident and thoughtless rather than malicious and calculating... yeah I find that very easy to believe. Process safety exists because as individuals and as groups we suck at this.
It’s even an HN community guideline ironically, assume good faith.
I hope this is bait because that's not how it works.
Okay, my bad. I didn't know he was not participating in the embargo.
This is exactly how it works. People who are part of the embargo are responsible for making sure that anyone they share information with -- which should usually be nobody! -- are aware of and abide by the embargo.
you cannot be subject to an embargo of which you had no knowledge and took no participation in.
the embargo was already broken when pete received the information.
So if I read the post here and told someone, would I be breaking the embargo?
No, you didn't. I misread.
This is not a situation where "Ignorantia juris non excusat" applies.
I'm trying to follow but how could one possibly know information (the embargo) that has not been shared?
For the law, you can say that the law has been published and is at least available for review.
1 reply →
Yes, it is.