CVE Alert: CVE-2025-12028 – indieweb – IndieAuth

CVE-2025-12028

HIGHNo exploitation known

The IndieAuth plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 4.5.4. This is due to missing nonce verification on the `login_form_indieauth()` function and the authorization endpoint at wp-login.php?action=indieauth. This makes it possible for unauthenticated attackers to force authenticated users to approve OAuth authorization requests for attacker-controlled applications via a forged request granted they can trick a user into performing an action such as clicking on a link or visiting a malicious page while logged in. The attacker can then exchange the stolen authorization code for an access token, effectively taking over the victim’s account with the granted scopes (create, update, delete).

CVSS v3.1 (8.8)
Vendor
indieweb
Product
IndieAuth
Versions
* lte 4.5.4
CWE
CWE-352, CWE-352 Cross-Site Request Forgery (CSRF)
Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Published
2025-10-24T08:23:58.518Z
Updated
2025-10-24T08:23:58.518Z

AI Summary Analysis

Risk verdict

High risk of account takeover via CSRF in IndieAuth up to 4.5.4; exploitation is feasible with user interaction, patch urgently where the plugin is installed (no KEV/EPSS indicators provided).

Why this matters

Unauthenticated attackers can force a logged-in user to approve OAuth authorisations for attacker-controlled apps, enabling token exchange for broad access (create, update, delete). On WordPress sites using IndieAuth, this can compromise user accounts and extend to data and workflow disruption across connected services.

Most likely attack path

An attacker crafts a forged request to trigger the auth flow (login_form_indieauth or wp-login.php?action=indieauth) while a valid user is logged in. With no nonce verification, the user’s consent is coerced, allowing an authorization code to be issued and exchanged for an access token. The attacker then acts within the user’s authorised scope; the CVSS metrics imply network access with low complexity and high-impact consequences if a token is obtained.

Who is most exposed

Sites using the IndieAuth plugin on WordPress, especially where multiple users have author or admin roles or where OAuth-integrated apps are common. Shared hosting or multi-site WordPress deployments are particularly at risk if the plugin is active.

Detection ideas

  • Unusual OAuth authorization grants to unknown client apps from authenticated sessions.
  • Tokens issued with high-privilege scopes without normal user consent patterns.
  • Redirect patterns or login attempts to wp-login.php?action=indieauth from unexpected origins.
  • Username/session activity spikes around login/auth endpoints.
  • Logs showing missing nonce checks on IndieAuth endpoints.

Mitigation and prioritisation

  • Patch to 4.5.4 or later; ensure nonce verification on login_form_indieauth and the authorization endpoint.
  • If patching now isn’t possible, disable IndieAuth or restrict OAuth client registrations; enforce stricter CSRF protections and SameSite cookies.
  • Monitor OAuth token issuance and revoke suspicious tokens; require MFA for admin accounts.
  • Plan a staging test before production rollout; notify stakeholders of potential account-takeover risk.
  • Treat as priority of concern and shorten change windows where exposure is detected, even though explicit KEV/EPSS flags aren’t present.

Support Our Work

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

AI APIs OSINT driven New features