WordPress Plugin Security Roundup: August 2026

Every month we review the WordPress vulnerability disclosures from Patchstack, Wordfence Intelligence, and WPScan, then summarize the ones that matter most: high install counts, exploitable without privileges, or actively weaponized in the wild. After July's core-level emergency, August looked calm. It was not.

Three of this month's four headline flaws were patched in July. Their public write-ups landed in August. That gap — a fix shipped quietly in a routine plugin update, the details published two to five weeks later — is the story of the month. Every site that auto-updates plugins was protected before the news broke. Every site that batches updates for a monthly maintenance window spent that window exposed to a bug an attacker could read about in full.

August 2026 at a Glance

CVE	Plugin	CVSS	Type	Auth Required	Status
CVE-2026-32475	Elementor Pro	9.0 Critical	Arbitrary File Upload → RCE	None	Patched — update to 4.2.2
CVE-2026-15748	Forminator Forms	9.8 Critical	Arbitrary File Upload → RCE	None	Patched — update to 1.56.2
CVE-2026-28139	Ajax Search Lite	9.8 Critical	PHP Object Injection	None	Patched — update to 4.14.5
CVE-2026-15826	User Profile Builder	9.8 Critical	Authentication Bypass	None	Patched — update to 3.16.5

Every one of the four has a fix available today. Two of them are the same class of bug — a file-upload handler that validates one thing while it processes another — which is worth noting on its own. Form builders sit on more WordPress sites than almost any other category of plugin, so a repeatable upload-validation mistake in that category is a broad problem. We start with the one that runs on the largest install base.

CVE-2026-32475 — Elementor Pro (CVSS 9.0 Critical)

Affected versions: Elementor Pro 4.2.1 and below
Fixed in: 4.2.2 (released August 19, 2026)
Auth required to exploit: None — fully unauthenticated
Affected installs: Elementor Pro is the paid tier of a page builder whose free plugin reports more than 10 million active installs; the Pro install count is not published

This is the month's headline. An anonymous visitor uploads a PHP file through an ordinary contact form, then runs it on your server. No account, no cookie, no nonce. The only prerequisite is a published Elementor page carrying a Form widget with a File Upload field — a completely normal thing to have on a normal business site.

The root cause is a desynchronization between two loops in the Forms module. The validation loop and the file-processing loop treat empty file entries differently. Validation hits an empty entry, then exits outright with return; processing hits the same entry, then skips past it with continue. An attacker submits two file parts for the same form field, the first one empty. Validation bails out before it ever inspects the second part, so the .php extension blocklist never runs. Processing skips the empty part, then happily moves the malicious one into the public uploads directory.

The file lands in wp-content/uploads/elementor/forms/ under a uniqid()-derived name. That sounds like protection. It is not: Patchstack's write-up notes the name is recoverable by brute-forcing five hex digits of microsecond timing, and on sites with form autoresponders enabled the confirmation email hands the attacker the exact upload URL with no guessing at all.

The disclosure timeline is the uncomfortable part. Researcher Tin Pham (TF1T) reported the flaw on July 16, 2026. The vendor had a patch prepared on July 17 — one day later. That patch reached users on August 19. For thirty-four days a working fix sat in hand while every affected site stayed open. No in-the-wild exploitation was observed at the time of publication, which is the one piece of good news here, but full technical details are now public. Update to 4.2.2 today, then inspect wp-content/uploads/elementor/forms/ for any file that is not a document or an image. A .php file in that directory means you were reached.

CVE-2026-15748 — Forminator Forms (CVSS 9.8 Critical)

Affected versions: All versions up to and including 1.56.1
Fixed in: 1.56.2 (released July 31, 2026)
Auth required to exploit: None — fully unauthenticated
Install count: 600,000+ active installs, with roughly 300,000 still on a vulnerable version when the details went public

Same category of plugin, same category of mistake, higher score. Forminator's handle_file_upload function blocks dangerous file types with a blocklist that performs exact-key matching. Exact matching is the flaw: the check can be walked past with pipe-alternative MIME type keys that never match a blocklist entry, yet still resolve to an executable PHP file once written to disk.

A second weakness makes it worse. The public submission handler trusts the upload field configuration that arrives with the request, and that configuration can be forged through a Select field value. The attacker does not just sneak a file past the filter — they rewrite the rules the filter is applying. Exploitation needs a form that contains both a File Upload field and a Select field, which is an ordinary combination on a job application form, a support request form, or a quote request form.

The flaw was found by researcher daroo through the Wordfence Bug Bounty Program, earning a $2,048 award. WPMU DEV shipped 1.56.2 on July 31, 2026. Public analysis followed on August 18. In the eighteen days between those two dates about half the install base updated; the other half — roughly 300,000 sites — were still vulnerable when the write-up appeared. No confirmed in-the-wild exploitation had been reported at that point.

Update to 1.56.2 or later. Then review your live forms, check your upload directories for PHP files you did not put there, plus confirm that your host does not allow PHP execution inside upload paths. That last setting is the difference between an uploaded web shell being a file on disk or a shell on your server.

CVE-2026-28139 — Ajax Search Lite (CVSS 9.8 Critical)

Affected versions: All versions up to and including 4.14.4
Fixed in: 4.14.5
Auth required to exploit: None — fully unauthenticated
Install count: 20,000+ active installs

Published by Patchstack on August 4, 2026 and credited to researcher hhhai, this is an unauthenticated PHP object injection in a live-search plugin. Untrusted input reaches PHP's deserialization routine, which lets an attacker construct arbitrary PHP objects inside your application.

Object injection deserves a word of explanation, because its severity is genuinely conditional. The bug itself does not run code. It hands the attacker a set of PHP objects, and what those objects do depends on whether a usable "POP gadget chain" exists somewhere in your installed code — your theme, your other plugins, or a shared library. Where a suitable chain exists, the outcome runs from code execution to SQL injection to path traversal to denial of service. Where none exists, the same bug may do very little.

That conditionality is exactly why you should not treat it as a low-priority item. The gadget chain does not have to live in Ajax Search Lite. It can arrive next week in an unrelated plugin you install for an unrelated reason, at which point a dormant bug becomes a live one without anybody touching the vulnerable code. Update to 4.14.5. This is a small plugin with a small footprint, so the update is cheap.

CVE-2026-15826 — User Profile Builder (CVSS 9.8 Critical)

Affected versions: All versions up to and including 3.16.4
Fixed in: 3.16.5 (released July 16, 2026)
Auth required to exploit: None — fully unauthenticated
Install count: 40,000+ affected sites

Wordfence received this report on July 14, 2026, a patch shipped on July 16, then the public write-up appeared on August 17 — the same quiet-fix pattern as the two above.

The bug is a type confusion in the registration flow. When account creation fails, the plugin returns an error object. That value gets converted to an integer before the code checks whether an error occurred, and an error object cast to an integer becomes 1. The plugin reads 1 as a user ID, then completes its automatic-login step against user 1 — conventionally the original administrator account on a WordPress install. An attacker submits a registration that is guaranteed to fail, then gets logged in as an admin.

Exploitation is conditional on configuration: the site needs automatic login after registration enabled, plus an active account at user ID 1. Plenty of membership sites, client portals, and community sites meet both conditions without anybody having made a deliberate choice about either. Update to 3.16.5, then review your administrator account for sessions or changes you cannot account for. Because the plugin logs the attacker into a real existing account rather than creating a new one, a fraudulent admin login here leaves no new user in your user list to spot.

The Three-Step Response

Update the four plugins now. Elementor Pro to 4.2.2, Forminator Forms to 1.56.2, Ajax Search Lite to 4.14.5, User Profile Builder to 3.16.5. All four are unauthenticated flaws, all four have public technical details, all four have a patch waiting.
Audit the upload directories. Two of this month's bugs write attacker files to disk. Check wp-content/uploads/ — particularly uploads/elementor/forms/ — for any .php file or anything that is not the document or image type your forms accept. Then confirm your server blocks PHP execution inside upload paths.
Turn on plugin auto-updates, or shorten your patch window. Every flaw in this roundup was fixed before its details went public. The sites that were never at risk are the ones that updated automatically. If auto-updates are not viable for a business-critical site, then test plugin updates on a staging site weekly rather than monthly — the exposure window is measured in days, not maintenance cycles.

If you manage several WordPress sites, running this by hand for each one is slow. Patchstack and WPScan both offer free tiers that email you when a vulnerability is disclosed for a plugin on your connected sites. Our free Vortex Security Check plugin scans your installed plugins, themes, plus core against the same databases without your data ever leaving the site.

Looking Ahead

The lesson of August is that a patch you have not applied is not a patch. Nothing this month was a zero-day. Nothing required a heroic emergency response. Every single one of these four critical flaws was fixed by its vendor, shipped through the ordinary WordPress update system, then sat unapplied on tens or hundreds of thousands of sites until the write-up made it newsworthy. Elementor's thirty-four days between a working patch and its release is the outlier worth watching — that delay is a vendor decision a site owner cannot influence, which makes updating fast once the release does land the only lever you actually control.

The second lesson is narrower but practical: check your forms. Two of this month's four bugs were file-upload validation failures in form builders, both unauthenticated, both ending in remote code execution. If a form on your site accepts file uploads, that form is an anonymous write path into your server. It deserves the same scrutiny you would give a login page.

Keeping up with disclosure feeds every month is real work, and it is work most business owners should not be doing. Our managed WordPress hosting watches these feeds daily, applies the patches while the exposure window is still small, then verifies the fix held. We will publish the September 2026 roundup at the end of next month. Until then, the Patchstack database is updated daily, free to search.