What happened
Five critical vulnerabilities have been disclosed across widely used WordPress plugins and themes, creating attack paths ranging from authentication bypass and administrator account takeover to arbitrary file writing and remote code execution. The affected products are WPMU DEV Dashboard, the Avada theme with Fusion Builder, TranslatePress, Pods, and GiveWP.
The vulnerabilities were disclosed separately by Wordfence and Patchstack and brought together in an August 29, 2026 report by The Hacker News. Four of the five vulnerabilities carry CVSS 3.1 scores of 9.8. The GiveWP vulnerability, CVE-2026-82222, received the maximum 10.0 rating from Patchstack.
What makes this group especially important for website owners is that none of the attack paths requires an attacker to begin with a normal WordPress administrator account. Depending on the affected product and configuration, an unauthenticated attacker may be able to bypass authentication, recover an administrator password-reset link, invoke privileged administrative functionality, write executable PHP files, or ultimately run commands on the underlying server.
The five vulnerabilities are:
CVE-2026-76581 WPMU DEV Dashboard Authentication bypass
CVE-2026-18431 Avada + Fusion Builder Arbitrary file write / RCE
CVE-2026-19632 TranslatePress Administrator account takeover
CVE-2026-19598 Pods Privilege escalation
CVE-2026-82222 GiveWP PHP object injection / RCEThese are separate vulnerabilities with different prerequisites. Running WordPress alone does not make a site vulnerable, and some flaws require particular plugin settings or combinations of components. Administrators should therefore inventory their actual WordPress stack rather than treating the disclosures as one universal WordPress vulnerability.
CVE-2026-76581: WPMU DEV Dashboard authentication bypass
CVE-2026-76581 affects WPMU DEV Dashboard versions through 5.0.1 and has a CVSS score of 9.8. The vulnerability exists in the Hub Single Sign-On flow used to authenticate users from WPMU DEV's Hub into connected WordPress websites.
The issue results from inconsistent construction of the cryptographic data used during two stages of the SSO process. Values included when one step creates an HMAC do not correspond unambiguously with the values checked during the following step. Under vulnerable conditions, an attacker can manipulate those values and reuse a valid cryptographic result in a way that causes WordPress to create an authenticated session.
The attack is only relevant to sites connected to WPMU DEV where Hub SSO is enabled and mapped to an administrator account. Successful exploitation can provide WordPress administrator access without knowing the administrator's password.
Administrator access can itself represent complete application compromise. Depending on WordPress configuration and hosting restrictions, an administrator may be able to install plugins, modify site content, create additional accounts, access private information, or introduce server-side code.
WPMU DEV released version 5.0.2 on August 24, 2026 to address the vulnerability. Sites that cannot update immediately should disable Hub SSO until the corrected version can be installed.
CVE-2026-18431: Avada and Fusion Builder remote code execution
CVE-2026-18431 affects the Avada WordPress theme through version 7.16 when Fusion Builder is installed and active through version 3.16. The vulnerability has a CVSS score of 9.8 and can allow an unauthenticated attacker to write attacker-controlled files to the WordPress server.
This is not a single simple file upload bug. Wordfence described the issue as a multi-stage vulnerability chain involving several authorization and input-validation weaknesses across Avada and Fusion Builder. When the necessary conditions are present, the chain can ultimately allow an attacker to create a PHP file containing attacker-controlled content.
If that PHP file is placed somewhere accessible to the web server and PHP execution is permitted, requesting it can execute the attacker's code:
Unauthenticated request
|
v
Multiple Avada / Fusion Builder weaknesses
|
v
Attacker-controlled file written
|
v
PHP file becomes web accessible
|
v
Remote code executionSuccessful exploitation requires Avada and Fusion Builder to be installed and active together, along with particular administrator-authored content required by the vulnerable chain. Because Avada normally operates alongside Fusion Builder, administrators using the theme should confirm the version of both components rather than checking only the theme.
The vulnerability is addressed in Avada 7.16.1 and Fusion Builder 3.16.1. Both should be updated together.
CVE-2026-19632: TranslatePress administrator account takeover
CVE-2026-19632 is a critical information disclosure vulnerability affecting TranslatePress versions through 3.3.1. TranslatePress is used to build multilingual WordPress websites and has more than 400,000 active installations according to Wordfence.
The vulnerability is unusual because it involves the handling of WordPress password-reset emails. TranslatePress can process translatable strings from outgoing email content. Under specific conditions, the administrator's password-reset URL can be saved into a secondary-language translation dictionary.
That reset URL contains security-sensitive information, including the password-reset key and account parameters. An unauthenticated attacker able to retrieve the stored translation entry can obtain the reset link, set a new password for the administrator account, and then log in to WordPress as that administrator.
Exploitation requires automatic string saving to be enabled and the targeted administrator's WordPress profile locale to use a published secondary language. Automatic string saving was identified by Wordfence as the default configuration when it disclosed the issue.
TranslatePress version 3.3.2 contains the fix. Administrators should update rather than relying solely on configuration changes because multilingual settings may change later and other administrators may use different profile locales.
CVE-2026-19598: Pods privilege escalation
CVE-2026-19598 affects Pods, a WordPress framework used to create custom content types and fields. The vulnerability carries a CVSS score of 9.8 and affects versions through 3.3.9, as well as older maintained release branches.
The flaw occurs in the pods_admin AJAX router. Administrative operations pass through checks intended to validate the requested method, verify a nonce, confirm that the requester is authenticated, and determine whether the user has sufficient capabilities. Under the vulnerable code path, failures can be routed through an error-handling function that records the error but does not reliably terminate execution.
That difference is critical. Security checks are effective only if a failed check prevents the privileged action from continuing. If processing continues after authorization fails, the application may execute functionality that should have been restricted to privileged users.
According to the published vulnerability information, an unauthenticated attacker can abuse the flaw to invoke administrative functionality, overwrite another user's password, or elevate privileges to Administrator. Either outcome can lead to complete WordPress site takeover.
For sites on the 3.3 branch, the security fix is available in Pods 3.3.9.1. Patched releases were also produced for older supported branches, including 3.2.8.3, 3.1.4.2, 3.0.10.4, 2.9.19.4, and 2.8.23.4. Administrators should normally move to the newest supported release rather than remaining on an older branch unless compatibility requirements make that necessary.
CVE-2026-82222: GiveWP remote code execution
CVE-2026-82222 is the highest-rated issue in this group. Patchstack assigned the GiveWP vulnerability a CVSS score of 10.0. GiveWP is a donation and fundraising platform for WordPress used by charities, nonprofits, campaigns, and other organizations that accept payments online.
The vulnerability affects GiveWP through version 4.16.7.1 and combines several weaknesses into a PHP object injection chain that can ultimately result in arbitrary operating-system command execution.
The underlying problem involves code intended to safely process serialized PHP data. The defensive helper prevents normal object construction during one stage but does not fully neutralize the attacker-controlled serialized object. The data can survive storage and later reach another unserialization operation where the protection is no longer present.
GiveWP also ships classes that can form a usable PHP gadget chain. In PHP object injection attacks, a gadget chain allows attacker-controlled object properties to trigger existing methods in application libraries. When the right classes and methods are available, object injection can move from data manipulation to execution of dangerous functions.
Patchstack found that the vulnerability could be exploited without the attacker starting with a legitimate WordPress account. GiveWP's surrounding registration and donation workflow provided the components necessary to progress through the attack chain under affected configurations.
A site with at least one published donation form and an active payment gateway may meet the relevant conditions. Exact reachability varies between affected GiveWP versions, particularly in the later 4.16.6 through 4.16.7.1 releases, but those versions remained vulnerable rather than fully corrected.
GiveWP version 4.16.7.2 contains the fix. Patchstack notes that the developer addressed the chain at several points rather than attempting to correct only one vulnerable function.
Why it matters for website owners
These five disclosures show how different WordPress components can reach the same end result through very different weaknesses. One flaw breaks an SSO authentication boundary, another writes files to disk, one exposes password-reset secrets, another allows authorization failures to continue, and the final vulnerability abuses PHP serialization.
The practical consequences converge around two outcomes: administrator control of WordPress or execution of code on the server.
An attacker with administrator access can alter content, create users, change site settings, install malicious plugins, redirect visitors, tamper with ecommerce or donation pages, or plant persistent malicious code. Direct remote code execution goes further because the attacker operates through the PHP process and may access configuration files, database credentials, API secrets, filesystem data, or other applications sharing the hosting account.
WordPress sites are also frequently connected to external services such as payment processors, CRM platforms, marketing systems, email providers, analytics tools, cloud storage, and APIs. A website compromise can therefore expose credentials whose usefulness extends beyond WordPress itself.
The conditional nature of several vulnerabilities is also important. A basic version scanner may tell an administrator that vulnerable software is present, but determining exploitability may require checking SSO configuration, language settings, published forms, active payment gateways, installed companion plugins, and site content.
What to check on your site
- Inventory all WordPress installations. Include production, staging, development, archived sites, marketing microsites, and old domains that remain reachable.
- Check WPMU DEV Dashboard. Versions through 5.0.1 are affected. Update to 5.0.2 or later and review whether Hub SSO is enabled and mapped to an administrator.
- Check Avada and Fusion Builder together. Avada through 7.16 combined with Fusion Builder through 3.16 is affected. Update to Avada 7.16.1 and Fusion Builder 3.16.1 or later.
- Check TranslatePress. Versions through 3.3.1 are affected. Update to 3.3.2 or later. Review automatic string saving and administrator profile locales.
- Check Pods. Sites running the 3.3 branch should use at least 3.3.9.1. Older maintained branches have separate security releases.
- Check GiveWP. Versions through 4.16.7.1 are affected. Update to 4.16.7.2 or later.
- Review administrator accounts. Investigate unknown users, unexpected password changes, recently created administrators, and unexplained privilege changes.
- Inspect recently modified PHP files. This is particularly important on Avada sites because the vulnerability can lead directly to attacker-controlled file creation.
- Review access and authentication logs. Look for unusual SSO activity, unexplained administrator sessions, abnormal AJAX requests, suspicious account recovery activity, and unexpected donation or form submissions.
- Remove unused components. Themes and plugins that are no longer required should not remain installed indefinitely.
Recommended response
The primary remediation is to update each affected component to a corrected release. Administrators managing multiple WordPress sites should prioritize internet-facing installations and systems holding customer, donor, employee, or payment-related information.
Where a vulnerable product cannot immediately be updated, temporarily disabling the affected plugin or functionality may be appropriate. For example, disabling Hub SSO can reduce exposure to CVE-2026-76581 while WPMU DEV Dashboard is being updated. This should be treated as temporary containment rather than a substitute for patching.
Administrators should also consider whether a vulnerable version was exposed long enough for compromise to have occurred. Installing a patch prevents future exploitation of the corrected weakness but does not remove administrator accounts, PHP backdoors, malicious plugins, altered configuration, or other persistence created before the update.
For high-value sites, compare WordPress core, theme, and plugin files against trusted versions, review administrator accounts, check filesystem modification times, and rotate credentials if evidence indicates that an attacker obtained server-side code execution.
Using Vulnify for WordPress review
The Stack Checker can help identify publicly detectable WordPress components and provide an external view of the technology exposed by a website. This is useful when reviewing multiple properties and determining which sites require deeper plugin and theme inventory checks.
External detection should be combined with direct access to the WordPress administration area or hosting environment. Several vulnerabilities in this group depend on internal configuration that cannot reliably be determined from the public website alone. Vulnify should therefore be used to support the assessment process rather than as proof that a site is or is not exploitable through a specific CVE.
For broader remediation guidance, the Security Hardening Checklist covers plugin management, administrative access, updates, exposed functionality, and practical controls for reducing WordPress attack surface. Organizations processing personal information can also review Article 32 for Web Teams: Technical Measures Explained when assessing controls around websites handling personal data.
Related reading
Conclusion
The August 2026 disclosures involving WPMU DEV Dashboard, Avada, TranslatePress, Pods, and GiveWP demonstrate how serious WordPress compromises can originate far outside WordPress core. Plugins and themes routinely participate in authentication, file handling, account management, payments, database operations, and server-side processing, which makes vulnerabilities in those components capable of crossing major security boundaries.
CVE-2026-76581, CVE-2026-18431, CVE-2026-19632, and CVE-2026-19598 each carry CVSS scores of 9.8. Patchstack rates CVE-2026-82222 in GiveWP at 10.0. Although their technical causes differ, every issue can ultimately lead to severe control over an affected WordPress environment.
Website owners should verify installed versions, update vulnerable components, check the configuration-specific prerequisites relevant to each flaw, and investigate signs of previous compromise where appropriate. Maintaining a current inventory of WordPress themes and plugins remains essential because simply knowing that WordPress core is updated does not address vulnerabilities introduced by the wider application stack.