WordPress vulnerability news, written for people managing many sites
Most vulnerability feeds tell you a disclosure happened. If you run forty client sites, the useful question is whether you are affected, how badly, and what to do before lunch.
Free during early access. No credit card required.
A disclosure feed is not an action list
Public vulnerability feeds are comprehensive and largely unusable at portfolio scale. They report every disclosure affecting every WordPress component, ranked by severity score, with no knowledge of what you actually run.
Reading one as an agency means manually cross-referencing each disclosure against a plugin inventory you probably do not have in a single place. In practice almost nobody does this, which is why the gap between a patch being published and applied is measured in weeks rather than hours across most portfolios.
The severity score is also the wrong ranking. A critical vulnerability in a plugin you do not run is irrelevant. A medium one in a plugin installed on eleven client sites, three of which take payments, is your morning.
What matters more than severity score
- Whether you run the affected component at all
- How many client sites are affected
- Whether any of those sites take payments or hold personal data
- Whether exploitation requires authentication
- Whether a patch exists yet
- How long the exposure window has already been open
What each entry tells you
Every disclosure summarised in the same structure, so it can be read in under a minute.
What it is
The component, the affected version range, the vulnerability class and whether exploitation requires authentication. Version ranges matter more than the headline, because being on 4.2.1 when 4.2.0 is affected is the difference between an incident and a non-event.
Who is exposed
The realistic exposure profile: whether it is remotely exploitable, whether a public proof of concept exists, and what an attacker gains. Stated without dramatisation, because accurate descriptions are alarming enough.
What to do
The specific action and its urgency. Usually update to a named version. Occasionally the answer is to disable the component until a patch ships, and we say so when that is genuinely the right call.
How to check your portfolio
How to find out whether you run the affected component across every site you manage, in one query rather than forty logins.
What is tracked
Plugin and theme disclosures
Continuous matching of published vulnerability data against live inventories rather than periodic scans.
WordPress core releases
Security releases flagged separately from feature releases, because they warrant different urgency.
PHP security releases
End-of-life versions and security patches, which agencies frequently discover only when a host forces an upgrade.
WooCommerce and payment paths
Disclosures affecting checkout and payment extensions, prioritised because the consequence is direct revenue loss.
Exposure windows
How long each issue has been open on your sites, which is the number that actually measures your risk.
Client-ready summaries
Each entry written so it can go into a client report without translation.
The metric worth tracking
Almost every WordPress compromise an agency deals with involves a component with a published vulnerability and an available patch. The attack was not sophisticated; the patching was slow. That is uncomfortable and it is also good news, because it makes this an operational problem rather than a technical one.
The single most useful security measure an agency can track is therefore the time between a patch being published and it being applied across every affected site. Not scans completed, not updates run. How long your clients stayed exposed to a problem that had a fix available.
Measuring it honestly the first time is usually uncomfortable. It is also the number that improves fastest, because the barrier is almost never technical. What usually prevents fast patching is fear of breaking something, which is entirely rational if a previous update caused an incident, and which is why update safety and security are the same problem rather than separate ones.
Signals your patch cycle is too slow
- Security updates wait for the monthly maintenance window
- You cannot say how long a known issue has been open
- Patching is delayed because an earlier update broke something
- You learn about disclosures from the news, not your tooling
- Nobody owns the decision to break the schedule for an urgent patch
Related
Questions about vulnerability news
Continuously as disclosures are published, with the highest-consequence items summarised for agencies. Detection inside WPCentrify is continuous rather than on a scan schedule, so if a disclosure affects a component in your inventory you are notified within minutes.
They do different jobs. A firewall and malware scanner protect an individual site at runtime. This is the portfolio layer above: knowing what you run everywhere, what is vulnerable, and how quickly it gets patched. Both are worth having.
The entry says so explicitly and describes mitigation instead, which usually means disabling the component or restricting access to the affected path until a fix ships. We do not recommend waiting quietly.
That is the point of matching against a live inventory. Alerts fire for components you actually run, ranked by how many of your sites are affected and what those sites do, rather than for every disclosure in the ecosystem.
Find out if you are affected in seconds
Continuous inventory matching across every connected site, ranked by real exposure, with safe patching so speed does not mean risk.
Free during early access. No credit card required.