[ecjhdnc2025]

There is imprecision and conceptual forcing and there are sketchy constructs in this post that are annoying given its subject area. It is also shoehorning in other known vulnerability issues to pad out the article, when it is a pretty concise topic.

I am not sure how widespread this specific nonce problem is.

It definitely is a problem -- I am not disputing that.

(Just as it's a problem that people have tended to assume that is_admin() or admin-ajax implies that by the time your hook runs, there's already a valid administrator session, when there isn't. But this is covered in the documentation.)

But the concept here is actually pretty obscure to WP developers so I would imagine they tend to consult the documentation, where they will encounter this at the end of the process:

https://developer.wordpress.org/reference/functions/wp_verif...

Nonces should never be relied on for authentication or authorization, access control. Protect your functions using current_user_can(), always assume Nonces can be compromised.

--

As to the rest of the article, I wish it were written less lazily:

> Unfortunately, as history shows, most WordPress plugins, even popular ones, often contain security vulnerabilities.

Most of them often do?

Not so. Definitely some often do, and there are repeat offenders, and many have, but by volume most WordPress plugins are small and do pretty simple things.

> So far this year, 280 critical (CVSS score 9.0+) vulnerabilities have been found in WordPress and its plugins.

This is disingenuously phrased, to my mind: "WordPress and its plugins" suggests a single authorship and conflates WP with the plugins.

WordPress itself has had no 9+ vulnerabilities this year (or indeed since 2021).

https://www.cvedetails.com/vulnerability-list/vendor_id-2337...

(Not to mention that the post is talking about 280 9.0+ vulnerabilities in seventy thousand plugins, the long tail of which have maybe dozens of activations at most.)

> There are dozens of SQL queries in every WP plugin.

Overreach again. Sure, many (perhaps the majority) of plugins cause additional SQL queries through the posts and options APIs, but most plugins contain little to no custom SQL.

[fullspectrumdev]

> 280 9.0+ vulnerabilities in seventy thousand plugins, the long tail of which have maybe dozens of activations at most.

This actually is a great point. A few years ago when working on a code analysis tool, we mirrored every single WP plugin and let it chew on them for a while.

It used a mixture of static and dynamic analysis, and “kinda worked” to some extent.

It found more issues than we could reasonably handle, and a lot of them were in plugins with maybe two installs ever and that hadn’t been activated in years.

We ran out of beans before implementing a proper triage system that would score the findings based on popularity or “last updated” data.

I may revisit this sometime though, as my ideas on static and dynamic analysis have come a long way since then!

[nelse]

Agree regarding Wordpress part connected to vulnerabilities. Fixed.

[ecjhdnc2025]

That's great :-)