WordPress Vulnerability Report — July 1 – July 8, 2026

What the July 1 – July 8 numbers actually tell us

The headline figure from WPSentry is straightforward: 103 vulnerabilities disclosed in eight days, aggregated from the NIST National Vulnerability Database, Wordfence Intelligence, and WPSentry's own scanning database, deduplicated by CVE ID, and rated on the CVSS v3.x scale. For context, the same outlet counted 142 disclosures in the June 26 – July 3 window (8 critical, 37 high severity, 2 patched, 140 unpatched) and 81 in May 17 – May 24 (8 critical, 20 high severity, 2 patched, 79 unpatched). The pattern is consistent — a steady stream of unpatched issues, with only a handful fixed at the time of disclosure. WPSentry also notes that the report is generated automatically and may not capture every vulnerability, so the real number is likely higher.

This is the part that should concern us as site owners: the volume is high, the patching rate is low, and most of the risk sits in third-party code rather than WordPress core itself.

Why outdated plugins and PHP keep showing up in the same headlines

Two companion stories from the same week reinforce the same lesson. Hosted.com published a piece on the security risks of outdated WordPress plugins, and gbhackers.com reports that over 70% of public WordPress sites are running outdated PHP versions, leaving them exposed to known attack paths. Meanwhile, SiteGround's "AI in WordPress: 2026 Findings for Small Businesses" found that 41% of small businesses cannot get usable results from WordPress 7.0's AI tools — a reminder that as the platform layers in more automation, the fundamentals of maintenance, updates, and hosting hygiene still decide whether a site is safe to run.

Together, these reports point to the same root cause: sites accumulate technical debt in plugins, themes, and server runtime, and that debt is exactly what vulnerability scanners find first.

Let us configure your response in three steps

Firstly, open your dashboard and head to Plugins → Installed Plugins. Sort by "Update available" and review every entry before clicking update. For plugins you no longer use, deactivate and delete them rather than leaving dormant code in place. However, if a plugin is mission-critical and the latest version is a major bump, test the update on a staging site first — consequently, you will catch conflicts before they hit production.

Secondly, let us check the PHP version your host is actually serving. In your WordPress admin, go to Tools → Site Health → Info, and look at the Server panel. If the PHP version is below the current minimum your plugins require, or if your host is still on PHP 7.x or 8.0, contact your hosting provider or switch your site's runtime version in the hosting control panel. A modern PHP release is one of the highest-leverage security upgrades you can make, and the gbhackers.com finding suggests most of us have not done it yet.

Thirdly, turn on auto-updates selectively. Go to Plugins, click "Enable auto-updates" on trusted, actively maintained plugins, and leave the rest on manual review. In the block editor, you can also set a maintenance-mode page in Settings → Reading while you audit, and you can schedule a weekly fifteen-minute window to review the WPSentry vulnerability roundup and cross-check it against your installed plugins. We will keep this loop short and predictable rather than reactive.

What to watch this month

The two patched-versus-unpatched counts from late June (2 out of 142) and mid-May (2 out of 81) suggest that disclosure outpaces fixes by a wide margin, so do not wait for a CVE to match a plugin you are running — subscribe to your critical plugin authors' changelogs and to a weekly vulnerability digest. Track whether your host supports the latest PHP branch, whether your staging workflow is actually being used, and whether the AI tools in WordPress 7.0 are saving you time or adding configuration overhead. Those three checks, done weekly, will close most of the gap that this week's 103 disclosures just opened.