Blog

Over a recent months, I audited a slice of the WordPress plugin ecosystem with one goal: find real vulnerabilities hidden in ordinary, widely installed software – Automated.

I am not going to name the plugins here. The interesting part is not the branding. The interesting part is the pattern.

Across the run, I reviewed:

• 402 software targets
• 417 completed audits
• 748 candidate findings
• 37,924 known vulnerability records used for duplicate comparison
• 0 duplicate matches in the local matching set

The Numbers

Out of 748 findings, the severity distribution looked like this:

At first glance, most findings were not immediately critical. That is normal. Real vulnerability research is mostly filtering: removing noise, rejecting dead ends, and separating “bad-looking code” from “exploitable security boundary.”

But the meaningful slice was still large:

• 98 medium-or-higher findings
• 29 high-severity findings
• 416 findings reachable by unauthenticated or low-privileged users

That last number matters. A bug behind administrator access is often still a bug, but it usually does not cross a meaningful security boundary. A bug reachable by a visitor, subscriber, contributor, or customer changes the equation completely.

The Most Common Bug Classes

The strongest repeated themes were:

The pattern is familiar but still important: most real bugs were not exotic. They came from small trust mistakes.

A value was sanitized for display but later used in SQL.
A nonce was treated like authorization.
A user ID comparison accidentally allowed guest-owned objects.
A shortcode or renderer preserved attacker-controlled structure.
A public endpoint reused logic originally written for trusted users.

The interesting bugs were rarely one dramatic mistake. They were chains.

The Attacker Model Matters

The findings broke down by attacker role like this:

This is where vulnerability triage becomes more than pattern matching.

An SQL injection reachable only by an administrator may be technically real but practically ineligible in many bounty programs. The same primitive reachable by a customer, subscriber, or unauthenticated visitor becomes a serious issue.

Likewise, a stored XSS that requires an administrator to inject the payload is usually weak. A stored XSS that an anonymous visitor can persist into a page later viewed by an administrator is a completely different story.

The bug class is only half the report. The other half is: who can reach it?

What Kept Showing Up

The most common root causes were surprisingly consistent.

1. Sanitization confused with security

Functions that clean text for display or remove tags are often mistaken for SQL escaping, authorization, or URL validation. They are not interchangeable.

This showed up repeatedly in places where input passed through a “sanitize” function and was later concatenated into a query, rendered into HTML, or used as an object identifier.

2. Nonces treated as permissions

A nonce can prove that a request came from a page or session that received it. It does not prove that the user is allowed to perform the action.

Several findings followed the same pattern:

nonce valid
→ no capability check
→ sensitive action performed

That is not authorization. It is just CSRF protection.

3. Public features exposing private assumptions

Many plugins expose frontend AJAX routes for convenience: chat, forms, dashboards, uploads, galleries, submissions, donations, listings.

The danger appears when those routes reuse backend assumptions. A function that was safe when called by an administrator may become unsafe when exposed to a visitor with a public nonce.

4. Renderers trusting stored structure

Stored XSS often appeared where plugins preserved structured mini-languages: shortcodes, pseudo-markup, attachment tags, URL auto-linking, templates, labels, or backend-provided display values.

The payload was not always a raw <script> tag. More often, it was a quote, attribute, URL scheme, shortcode property, or rendered link.

Why Validation Is The Hard Part

Static analysis can identify promising paths, but runtime validation decides whether a finding survives.

Some candidates looked strong until the browser refused to execute a javascript: URL because the renderer forced target="_blank" with noopener. Some SQL injection candidates depended on whether the queried table had rows. Some guest-user issues depended on whether an add-on or site-specific filter enabled the public workflow.

That is the part automated reports often miss.

A good finding is not:

input reaches sink

A good finding is:

attacker-controlled input crosses a security boundary and produces a real security impact

That difference is where most of the work happens.

The Takeaway

The WordPress plugin ecosystem is huge, fragmented, and full of code paths that only activate under specific settings. That makes it easy to dismiss findings as “configuration-dependent,” but many real-world vulnerabilities live exactly there.

Shortcodes change access models.
Frontend dashboards expose authenticated logic to weaker roles.
Guest posting turns user ID 0 into an ownership problem.
Public nonces create a false sense of safety.
Convenience renderers turn stored text into active content.

In this sprint, the most valuable findings were not the loudest ones. They were the ones where a small trust assumption quietly collapsed.

That is the work: follow the value, identify the boundary, prove the impact, and be honest about the conditions.

No plugin names needed. The patterns are the story.