Wordfence Report Tallies 102 WordPress Vulnerabilities in One Week

Wordfence’s latest weekly vulnerability report says 102 WordPress plugin and theme vulnerabilities were added to its intelligence database for the June 8 to June 14 reporting week, keeping patch triage near the top of the WordPress operations queue.

The Wordfence Intelligence weekly report, published June 18, 2026, says the additions covered 90 WordPress plugins and five themes. Wordfence counted 78 patched vulnerabilities and 24 still unpatched at publication time, with 68 researchers credited for the week’s disclosures.

For site owners and agencies, the useful signal is not only the headline count. The report shows how quickly the WordPress risk surface can shift across forms, directories, LMS tools, calendars, backup plugins, builders, maps, data tables, and WooCommerce add-ons. That makes plugin inventory and update verification an operational control, not a housekeeping task.

What changed in Wordfence’s June 8–14 report

Wordfence classified the week’s additions as 62 medium-severity, 36 high-severity, and four critical-severity vulnerabilities. The largest vulnerability class was cross-site scripting, with 35 entries, followed by 13 SQL injection issues and 12 sensitive-information exposure issues. Wordfence also counted CSRF, missing authorization, path traversal, deserialization, SSRF, privilege-management, and file-upload flaws.

The four critical entries included unauthenticated privilege escalation in Doctreat Core, Listdom, and LoginPress Pro, all with 9.8 CVSS ratings in the report. Wordfence also listed an unauthenticated arbitrary file upload issue in WordPress & WooCommerce Scraper Plugin, Import Data from Any WebSite through version 1.0.7, rated 9.8 and marked unpatched.

Why this matters for WordPress operators

Unpatched entries should drive exposure review

A patched vulnerability normally creates a straightforward next step: update, verify the new version, and confirm the old version is gone from production, staging, and abandoned client sites. An unpatched vulnerability is different. It should trigger a decision about disabling the plugin, removing public exposure, replacing the component, adding compensating controls, or isolating the site until a vendor fix is available.

That is especially important when the vulnerable component is unauthenticated, supports uploads, changes accounts, processes forms, or touches e-commerce workflows. Those are the paths that turn a plugin bug into a site-takeover or recovery problem.

The official WordPress guidance points to layered risk reduction

The WordPress hardening handbook describes security as risk reduction rather than perfect prevention, and reminds operators to keep WordPress software up to date while using trusted sources for plugins and themes. Its plugin security reporting guidance also warns against public disclosure before issues are handled, because premature publicity can increase compromise risk.

In practice, that means the right response to a weekly vulnerability batch is a repeatable process: inventory every installed plugin and theme, map versions to vulnerability intelligence, prioritize critical and high-severity unauthenticated paths, update where fixes exist, and record explicit risk decisions where fixes do not exist.

What to check now

WordPress administrators should review the Wordfence list against their own installed plugins and themes, prioritizing the critical entries and any unpatched software. Agencies and hosts should also check dormant sites, staging copies, and legacy campaign properties, because those often carry old plugins even after the main production site has been cleaned up.

The safest operating pattern is to treat each weekly report as a patch-cycle input: confirm affected assets, update or remove vulnerable components, verify that no old plugin directories remain writable on disk, and check logs for requests targeting newly disclosed unauthenticated actions, upload handlers, or SQL injection paths.