Back to blog
WordPressCVERCE

WordPress: Five Critical Flaws Including WPMU DEV Dashboard, Avada, and GiveWP (CVSS 9.8 to 10)

Published on 2026-08-306 min readCleanIssue

> TL;DR: Wordfence and Patchstack detailed five critical flaws in the WordPress ecosystem on August 29, 2026: an authentication bypass in WPMU DEV Dashboard when Hub SSO is enabled (CVE-2026-76581, CVSS 9.8), arbitrary file write in the Avada theme via Fusion Builder (CVE-2026-18431, 9.8), exposure of raw admin password-reset URLs in TranslatePress (CVE-2026-19632, 9.8), unauthenticated escalation to administrator in Pods (CVE-2026-19598, 9.8), and remote code execution in GiveWP through PHP object injection (CVE-2026-82222, CVSS 10). All of them lead, to varying degrees, to complete site takeover.

The five flaws and their activation conditions

Each flaw has precise prerequisites — knowing them determines whether your site is exposed:

  • WPMU DEV Dashboard (CVE-2026-76581, ≤ 5.0.1): the bypass only applies when the site is connected to WPMU DEV with Hub Single Sign-On enabled and mapped to an administrator account. In that configuration, an unauthenticated attacker gains admin access and takes over the site.
  • Avada (CVE-2026-18431, ≤ 7.16): unauthenticated arbitrary file write when the Fusion Builder plugin (≤ 3.16) is installed and active. Write a PHP file, execute it: RCE and full compromise.
  • TranslatePress (CVE-2026-19632, ≤ 3.3.1): the plugin exposes the raw administrator password-reset URL — plaintext reset key included — but only when automatic string saving is enabled and the target admin's profile locale is set to a published secondary language. Two rare conditions in theory, realistic on multilingual sites.
  • Pods (CVE-2026-19598, ≤ 3.3.9): unauthenticated escalation to administrator, or outright overwrite of any user's password, including the site owner's.
  • GiveWP (CVE-2026-82222, ≤ 4.16.7.1): CVSS 10. An attacker can execute arbitrary commands on a site with at least one published donation form and one active payment gateway — the default configuration of any functioning fundraising site.
  • GiveWP: PHP deserialization ending in RCE

    The GiveWP case deserves attention because its mechanism is a classic that returns every year in the PHP ecosystem. Patchstack's analysis describes a three-ingredient chain: a "safe unserialize" helper that does not actually strip serialized objects, a donation flow feeding that helper attacker-controlled data, and a gadget chain in code GiveWP ships in production. When the three align, PHP object injection becomes command execution.

    The root causes are generic and reach far beyond this plugin: trusting a serialization sanitizer that does not clean objects, unserializing data read back from the database as if it were trusted, and shipping development-only libraries into production where they provide ready-made gadget chains.

    Why this matters to you

    WordPress sites at SaaS companies are rarely the product itself — they are the marketing site, the blog, the careers pages, and documentation spaces. But they often share the main domain, integrations (application forms, double opt-in, CRM webhooks), and sometimes shared accounts. A compromised WordPress admin on the root domain is a credible pivot toward the product: script injection on pages your users browse, form submission capture, transactional email spoofing. For an HR team running a recruiting site on WordPress with GiveWP or TranslatePress, this list should trigger an immediate version check.

    What to do

  • Update all five components if present: WPMU DEV Dashboard, Avada (+ Fusion Builder), TranslatePress, Pods, GiveWP — fixed versions are published; updating is the only treatment.
  • Audit administrator accounts: unknown users, recently changed roles, password resets you did not request (the TranslatePress tell).
  • Hunt for unexpected PHP files in upload directories and theme file modifications — the typical traces of Avada and GiveWP exploitation.
  • Rotate shared secrets: email API keys, webhook tokens, database credentials if configuration sharing exists.
  • The broader lesson: "specific conditions" protect less than you think

    Four of these five flaws have activation conditions (SSO enabled, secondary locale, published form). Across a fleet of sites, those conditions always match a few real instances — precisely the ones using the feature most. Protection-by-configuration-rarity is not a strategy: it is a delay of a few weeks between your site and the first scanner that tries the right combination. Fast updates of active plugins, even on "secondary" sites, remain one of the best security ROIs on the web.

    Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.

    Sources

    Related services

    If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.

    Need an external review of your HR SaaS?

    Share your product, stack, and client context. We will come back with the right review scope.

    Discuss your audit