Jan Lehnardt :couchdb: @janl@narrativ.es
Public

This is very funny because the opposite is true.

I’ve been an open source software vendor for 15+ years and what actually happens when you have a critical vulnerability disclosed to you, you fix it, try and find all other instances of it and put a structural safety net in place that the category of this error can be ruled out for the entire codebase and cannot happen again in future *before* the CVE is made public. Even with tiny volunteer teams.

Citing Log4j here, which was (and is) famously understaffed and underfunded, just tells you how badly resourced react is and they are trying to save their asses and blaming you for not realising that the first fix maybe wasn’t sufficient.

hails.org/@hailey/115703205121

A big highlighted “Note” section on the latest CVE announcement on the react.dev site reading: It’s common for critical CVEs to uncover follow‑up vulnerabilities. When a critical vulnerability is disclosed, researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed. This pattern shows up across the industry, not just in JavaScript. For example, after Log4Shell, additional CVEs (1, 2) were reported as the community probed the original fix. Additional disclosures can be frustrating, but they are generally a sign of a healthy response cycle.

Hailey (@hailey@hails.org)

Attached: 1 image check out the perception management going on in react’s latest cve disclosure

social.hails.org · hails.org

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://social.security.plumbing/users/freddy/statuses/115711405019882383 on your instance and quote it. (Note that quoting is not supported in Mastodon.)