Mastodawn

There are levels to this thing…

Cory Dransfeldt

Feb 9

@zachleat do you add or multiply for sites that use both?

@cory both are bad

Cory Dransfeldt

Feb 9

@zachleat I’m terrified of both

Taylor “Tigt” Hunt Feb 10

@cory @zachleat Doesn’t Gutenberg put React in WP by default?

@tigt @zachleat 😰

@zachleat have you considered that Wordpress uses react in the editor?

@cbirdsong one-two punch!

Hm… I’m skeptical Feb 9

@zachleat wordpress is always marketing sites, right? No sensitive data?

@jorge who is saying that 😅

Timo Tijhof Feb 10

(Serious reply to funny post...)

"WordPress" here is more akin to npm or Node.js. Most CVEs are about generic PHP code added to a WordPress site via plugin.

React, Node, and front-end JS aren't bound by GPL, so the commercial ecosystem isn't as open.

CVEs in third-party scripts on a site with React or Node.js tend to be referred by name or vendor, not "React plugin", "npm package", or "Node.js module".

But anything on a WP site (front, back, and admin) is a "WordPress plugin".

Timo Tijhof Feb 10

The equivalent for a React site would need to include:

* unrelated third-party frontend scripts (equiv of WP theme and frontend plugins; eg WordPress plugins that just bundle and load an existing lightbox script, or analytics. Their CVEs all propagate.)

* server-side npm deps (equiv of WP backend feature plugins; such as general monitoring/profiling).

* dev dependencies used for the site's build steps (ie equiv of WP admin plugins; such as optimising thumbnails)

Zach Leatherman Feb 10

@krinkle 7,813 results for JavaScript 😅

https://www.cve.org/CVERecord?id=CVE-2025-3573

Should be a lot more! They don't organise frontend and npm vuln that way. This doesn't even mention JavaScript:

The search relies on descriptions for which standard terms are "an ongoing area of research" 🧐

https://www.cve.org/ResourcesSupport/FAQs#pc_cve_list_basicssearch_cve

Eco diff is quite distorted.

CVE dedupes npm such that A using outdated B isn't its own vul, despite requiring a separate upstream fix, and npm pkgs often having deep and wide dep trees (1000+ is common), and npm installing multiple versions, thus end-users don't update just once. You wait to apply each.

WP pgks are global so a thing only updates once (like Linux). Most have 0 deps, some 1. The deps that exist commit to pubic API forever stable, so direct upgrade is not constrained.

The craziest is that WordPress has unattended upgrades by default. So updates apply to a running server, like Debian/Ubuntu.

How often do we see a clean
npm-audit on a large end-user Node app, even an actively maintained one? I don't remember the last time.

It's gotten better with dependabot and lock bypasses, but that's limited to GitHub. And still requires waiting for intermediary maintainers to work through semver breaks and then to release it. I've waited years for some.

Anyway, peace ☮️ we're good.

Zach Leatherman Feb 11

@krinkle Yeah, I understand that there is plenty of nuance there but I do appreciate your replies! (and I bet you could aggregate those thoughts into an excellent blog post!)