WordPress Vulnerability Roundup: July 2026 Access Control
By WP Vanguard Team
July 2026 added 1,108 new WordPress vulnerabilities to our database, against 235 in June under the prior reporting methodology. That jump is real disclosure volume plus broader advisory aggregation landing in the same month, not a clean 5x spike, so treat the raw totals as a trend indicator rather than an apples-to-apples comparison. What is comparable is the shape of the month: Missing Authorization and Cross-Site Scripting together account for over half of everything disclosed in July. Most of this month's plugin failures came from code that never asked who was calling, not code that failed to clean up what was sent.
This WordPress vulnerability roundup for July 2026 covers the numbers, the ten criticals worth knowing by name, and the access-control pattern tying them together. It follows last month's report, WordPress Vulnerability Roundup: June 2026, where the defining story was a wave of PHP object injection bugs sharing code across a family of CRM plugins. July's story is different, and the difference tells you something about where plugin authors keep losing the thread.
The methodology shift matters enough to say plainly. Our June figures came from an earlier reporting pass that counted 235 disclosures across 206 plugins and 9 themes. July's 1,108 draws from a wider sweep of the same public advisory sources, still overwhelmingly Wordfence, so more of the month's real output is visible in the count. Some of the jump is genuinely more bugs shipping in July; some of it is us seeing more of what was always there. Both things can be true, and neither one changes what the class breakdown says about where the bugs cluster.
The Numbers This Month
| Severity | Count |
|---|---|
| Critical (9.0+) | 60 |
| High (7.0-8.9) | 295 |
| Medium (4.0-6.9) | 751 |
| Low | 1 |
| Unknown | 1 |
| Total | 1,108 |
The affected software splits across 1,067 vulnerabilities in 737 distinct plugin slugs, 39 vulnerabilities in 33 theme slugs, and 2 in WordPress core. Patch status: 939 patched, 169 unpatched at time of writing, an 84.7% patch rate. That's a healthier ratio than June's 76%, even with triple the volume, though 169 unpatched issues is still a large unaddressed tail sitting on live sites.
Sixty criticals in a single month deserves a beat of its own. Every one of the ten we spotlight below scores CVSS 9.8 and needs no authentication at all, which means the attacker doesn't need a stolen password or a phished session, just a reachable endpoint.
Vulnerability Classes: What Broke and Why
These counts are by classification, not a partition of the total. A single advisory frequently carries two labels, an unauthenticated file upload that's also arbitrary file write, for instance, so don't expect the column to sum to 1,108.
| Vulnerability Type | Count |
|---|---|
| Cross-Site Scripting | 343 |
| Missing Authorization | 255 |
| SQL Injection | 119 |
| Information Exposure | 56 |
| Privilege Escalation | 46 |
| Cross-Site Request Forgery | 37 |
| Local File Inclusion | 28 |
| Arbitrary File Upload | 26 |
| Server-Side Request Forgery | 22 |
| Arbitrary File Deletion | 20 |
| Arbitrary File Read | 18 |
| Remote Code Execution | 17 |
| PHP Object Injection | 17 |
| Authentication Bypass | 17 |
| Path Traversal | 11 |
| Account Takeover | 9 |
Cross-Site Scripting leads at 343, but Missing Authorization at 255 is the number that reframes the month. Add them together and you're at 598 of 1,108 disclosures, well over half, carrying a label that maps to a single root cause: a plugin trusts the caller instead of checking them.
How Missing Authorization Breaks
Missing Authorization is a specific, recurring pattern in WordPress plugin code, not a catch-all. A REST route or AJAX handler runs, does its job, and returns data or performs a write, but the function never calls current_user_can() or checks the requesting user's role before doing it. The endpoint might still verify a nonce. That's the trap: a nonce proves the request came from a legitimate page load, not that the user is allowed to do what they're asking for.
We wrote about this exact confusion in what WordPress nonces actually protect. A nonce is a CSRF token. It stops a forged request from a different site tricking a logged-in admin's browser into firing an action. It says nothing about whether the logged-in user making the request, subscriber, contributor, or anonymous visitor hitting a public REST route, should be allowed to fire it at all. Plugins that check the nonce and stop there ship an endpoint anyone can call.
July's 255 Missing Authorization disclosures are mostly this shape: a settings-update handler, an export function, or a REST endpoint for reading private data that any authenticated (or in the worst cases, unauthenticated) request can reach. Cross-Site Scripting, this month's biggest single category at 343, is a different mechanism, unsanitized output reflected or stored, but it fails for a related reason: the plugin trusts input or context it shouldn't. Between the two, July's dominant failure mode is trust placed in the wrong place, either in who's calling or in what they sent.
Picture the actual code path on a typical Missing Authorization advisory. A plugin registers a REST route with register_rest_route() and sets permission_callback to __return_true, a pattern that's fine for a genuinely public endpoint like a contact form submission, but gets copy-pasted onto routes that shouldn't be public at all: a settings importer, a user-list export, a coupon generator. The developer tested it while logged in as an admin, watched it work, and shipped it without ever testing what an anonymous request or a subscriber-level account could reach. Nothing throws an error. The endpoint just does what it was built to do, for whoever asks.
Critical Spotlight: Ten CVSS 9.8 Bugs
All ten of July's most severe disclosures require zero authentication and score CVSS 9.8. We verified each against public advisory data before including it here.
- CVE-2026-5524, Divi Form Builder <= 5.1.8: unauthenticated arbitrary file upload to remote code execution via the
acceptFileTypesparameter, letting an attacker push a PHP payload past extension checks. Fixed in 5.1.9. - CVE-2026-15158, Blocksy Companion <= 2.1.46: arbitrary file upload via
blc-review-images[]. Fixed in 2.1.47. - CVE-2026-14345, WPFunnels <= 3.12.7: unauthenticated RCE via the
postDataparameter, written unsanitized into a PHP-includeable log file. Fixed in 3.12.8. - CVE-2026-14894, Super Forms <= 6.3.313: arbitrary file upload via the
dataparameter. Fixed in 6.3.314. - CVE-2026-12761, miniOrange Social Login and Register <= 7.7.0: authentication bypass to full admin takeover. Fixed in 7.8.0.
- CVE-2026-14245, miniOrange OTP Login <= 5.5.1: authentication bypass via
username_b. Fixed in 5.5.2. - CVE-2026-15013, SAML Single Sign On <= 5.4.3: authentication bypass via SAMLResponse signature algorithm confusion, forging assertions against a mismatched key type. Fixed in 5.4.4.
- CVE-2026-13001, Podlove Podcast Publisher <= 4.5.1: unauthenticated arbitrary file upload. Fixed in 4.5.2.
- CVE-2026-57692, Private Content <= 9.9.2: unauthenticated privilege escalation. Fixed in 9.10.0.
- CVE-2026-9701, Eventer <= 4.4.4: insecure password reset flow leading to privilege escalation. Fixed in 4.4.5.
Three of these, the miniOrange Social Login and Register bug, the miniOrange OTP Login bug, and the SAML Single Sign On bug, all trace back to one vendor. That's a single company shipping three separate unauthenticated auth-bypass criticals in identity and login plugins in the same 30 days. If you run any miniOrange login, SSO, or OTP plugin, that's not a coincidence you can shrug off. Check every miniOrange product on your sites, not just the one in this list you happen to recognize.
Why Access Control Is July's Story
June's defining pattern was PHP object injection sharing a codebase across a family of rebadged CRM plugins, a supply-chain problem where one flaw multiplied into a dozen advisories. July's pattern is more diffuse but arguably more consequential: it's not one vendor's shared engine, it's an industry-wide habit. Missing Authorization at 255 disclosures spans hundreds of unrelated plugins built by different teams, in different frameworks, for different purposes, all making the same mistake independently.
That's harder to fix with a single patch and harder to defend against with a single rule. It means every REST route and AJAX handler a plugin registers needs its own capability check, and that checking a nonce is table stakes, not the whole job. A site running twenty plugins is trusting twenty separate implementations of "does this user get to do this," and July shows that a meaningful share of them get it wrong.
It also explains why the five unauthenticated file-upload criticals in the spotlight list above aren't really a separate category from the Missing Authorization count. Divi Form Builder, Blocksy Companion, WPFunnels, Super Forms, and Podlove Podcast Publisher each expose an upload handler that never confirms the requester should be allowed to upload anything at all. The file-type validation gets the headline because it's the part that turns into remote code execution, but the access-control gap underneath it is the same one running through the 255 count. Fix the permission check first and the file-type bug becomes far less reachable, even before a byte of the extension-filtering code changes.
If you want the general playbook for how these individual flaws chain into a full compromise, from the first unauthenticated request to a persistent backdoor, we cover that mechanism in how WordPress sites get hacked.
What to Do Now
Start with the ten criticals above if you recognize any of the plugin names, especially the miniOrange family. For everything else on your sites:
- Update Divi Form Builder, Blocksy Companion, WPFunnels, Super Forms, and Podlove Podcast Publisher immediately if installed. All five are unauthenticated file-upload or RCE paths, the most dangerous class on this list, and the fix is a single version bump.
- Audit every miniOrange plugin, not just one. If you have Social Login and Register, OTP Login, or SAML Single Sign On, confirm the installed version against the fixed builds above (7.8.0, 5.5.2, 5.4.4 respectively) and check your user list for admin accounts you don't recognize.
- If you run Private Content or Eventer, check for unexpected role changes on existing accounts, both bugs escalate privilege on accounts that already exist rather than creating new ones, which makes the indicator subtler than a new rogue admin.
- Check file-upload directories on any site that ran a vulnerable version of the five upload-related plugins before patching. Look in the plugin's own upload path (for Divi Form Builder, that's
/wp-content/uploads/de_fb_uploads/) for files with double extensions or PHP variants like.phtmlor.pharthat don't belong. - For the rest of your plugin inventory, run through the WordPress security checklist once, then keep your update cadence tight. With 169 disclosures from July still unpatched, waiting on a vendor fix isn't a plan by itself.
References
Related reading
Check Your WordPress Site Security
Free scan, no login required. Find vulnerabilities before attackers do.
Scan Your Site FreeGet weekly WordPress security tips
Vulnerability alerts, plugin updates, and security guides. No spam. Unsubscribe any time.