Attack Vectors

WP-WebAuthn (slug: wp-webauthn) versions 1.3.4 and earlier are affected by an Unauthenticated Stored Cross-Site Scripting (XSS) vulnerability (severity: Medium, CVSS 6.1; vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) tracked as CVE-2025-13910.

An external attacker can send crafted input to the plugin’s wwa_auth AJAX endpoint without logging in. The malicious content can be stored in the plugin’s logs and will execute later when a user (often an administrator, security staff, or IT) opens the plugin’s log page.

This exposure specifically depends on configuration: the scripts execute when the logging option is enabled in WP-WebAuthn settings and when someone views the log interface (the “UI:R” element of the CVSS vector).

Security Weakness

The underlying issue is insufficient input sanitization and output escaping of user-supplied attributes that are recorded by the plugin and later rendered in the log page. Because the log page displays stored content, the attack becomes stored XSS rather than a one-time reflected event.

Stored XSS is particularly risky for business systems because it can be designed to trigger only when privileged users open routine pages (like logs), potentially turning routine operational activity into an infection point.

At the time of writing, there is no known patch available. Organizations should plan mitigations based on risk tolerance, including considering whether continued use of WP-WebAuthn is acceptable in its current state.

Technical or Business Impacts

If exploited, this issue can expose an organization to credential theft, session hijacking, and unauthorized administrative actions performed in the victim’s browser context when they view the WP-WebAuthn logs. While the CVSS score rates availability impact as none, the business impact can still be significant if an attacker gains access to marketing pages, customer-facing content, forms, or site settings through a compromised admin session.

For marketing directors and executives, the practical risks include brand damage (site defacement or malicious redirects), lead loss (tampered forms or tracking scripts), privacy/compliance exposure (unauthorized access to admin panels that manage customer data), and incident response costs (forensics, legal review, notifications, and downtime during remediation).

Recommended mitigations (given no known patch): disable WP-WebAuthn logging if it is not essential; restrict access to WordPress admin areas by IP/VPN where feasible; implement monitoring to alert on suspicious admin activity; and strongly consider uninstalling the affected plugin and replacing it with an alternative that meets your security and compliance requirements.

Similar Attacks

Stored XSS has been used in real-world incidents to spread quickly and compromise accounts when users view infected content:

MySpace “Samy” worm (2005) — stored XSS that propagated across user profiles
TweetDeck XSS incident (2014) — malicious scripts posted automatically through affected accounts
Documented examples of XSS impacts — overview of real cases and outcomes