CVE-2026-8438 – All-In-One Security – Stored XSS – POC

CVE-2026-8438 affects All-In-One Security (AIOS) – Security and Firewall and it is an unauthenticated stored cross site scripting vulnerability in the debug log workflow. When debug mode and the REST API restriction for non-logged in users are enabled, an attacker can place HTML or JavaScript in the REST request path. The decoded path is written into the debug log and later rendered without escaping in the AIOS Dashboard Debug logs page. A single request can therefore plant script that runs in an administrator browser session when the log view is opened, which can lead to nonce theft, privileged actions, and full site compromise.

CVE	CVE-2026-8438
Plugin Version	All-In-One Security (AIOS) – Security and Firewall <= 5.4.7
All Time	37 539 154
Active installations	1 000 000+
Publicly Published	June 5, 2026
Last Updated	June 6, 2026
Researcher	Dmitrii Ignatyev
PoC	Yes
Exploit	No
Reference	https://www.cve.org/CVERecord?id=CVE-2026-8438 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/all-in-one-wp-security-and-firewall/all-in-one-security-aios-547-unauthenticated-stored-cross-site-scripting-via-rest-api-request-path
Plugin Security Certification by CleanTalk
Logo of the plugin

Join the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.

Get Plugin Security Certificate

PSC by Cleantalk

Timeline

Discovery of the Vulnerability

The vulnerable surface is the REST request handling path that is used when AIOS blocks REST API access for non-logged in users. In the affected versions, the plugin builds the REST route from the decoded REQUEST_URI value and includes that value in a debug log message when debug mode is active. The missing security step is twofold. The request path is not reduced to safe text before storage, and the message column in the debug log list table is later returned without output escaping. This turns a blocked unauthenticated REST request into stored HTML inside the administrator debug log view.

The bug depends on two plugin options being enabled. The site must have aiowps_enable_debug enabled and aiowps_disallow_unauthorized_rest_requests enabled. Once both settings are active, the attacker does not need a WordPress account. A request to a crafted wp-json path is enough to place the payload into the debug log table. The execution is delayed until an administrator opens the AIOS Dashboard Debug logs page, which makes the issue stored XSS rather than a simple reflected request path issue.

Understanding of Stored XSS attacks

Stored XSS in WordPress is dangerous because the attacker only needs to place the payload once. The vulnerable application stores attacker supplied markup in the database and later serves it to a trusted user. In an admin page, that trusted user is often a site owner or administrator with active WordPress cookies and valid nonces in the browser. If the plugin renders stored log data as HTML instead of text, the browser treats the log entry as part of the page and executes event handlers or script capable markup in the administrator context.

Debug and audit log screens are especially sensitive because they often display raw request data, paths, headers, user agents, and error messages. These values must be escaped on output even when they were collected for internal diagnostics. Logging is not a sanitization boundary. A log viewer should treat every value as attacker controlled unless it was generated entirely by trusted server code.

Exploiting the Stored XSS Vulnerability

To exploit CVE-2026-8438, an unauthenticated attacker can send one crafted REST request after the required AIOS settings are enabled:

POC:

POC:
1. Go to http://138.124.55.33/wp-admin/admin.php?page=aiowpsec_settings and enable Debug mode.
2. Go to http://138.124.55.33/wp-admin/admin.php?page=aiowpsec_firewall&subtab=wp-rest-api and enable "Disallow REST requests".
3. Send this request:
curl 'http://138.124.55.33/index.php/wp-json/%3Cimg%20src=x%20onerror=alert(1892891428924)%3E/test'
4. Open http://138.124.55.33/wp-admin/admin.php?page=aiowpsec&tab=debug-logs to observe the stored XSS in the debug log view.

____

The request path contains a URL encoded image tag with an onerror handler. AIOS decodes the path while building the REST route value, logs it as part of the debug message, and later displays that message without escaping. When the administrator opens the debug log tab, the payload is parsed by the browser and JavaScript runs inside the admin session. The practical impact is not limited to a popup. A real attack can use the administrator context to read page nonces and send privileged WordPress requests allowed to that user.

Recommendations for Improved Security

Site owners should update All-In-One Security (AIOS) – Security and Firewall to version 5.4.8 or a newer patched version. The current wordpress.org release is 5.4.9, so updating to the latest available build is the safest operational choice. Until the update is applied, avoid enabling debug mode together with REST API blocking on production sites, and review AIOS debug logs after clearing any suspicious entries.

Developers should treat REST paths and log messages as untrusted data. The request URI should be sanitized before storage when it is used as a diagnostic value, and every debug log field should be escaped on output with the correct WordPress escaping function for the HTML context. For table list output, message fields should be rendered as text, not raw HTML. Security features that block requests still need safe logging because blocked traffic is often controlled by attackers.

By taking proactive measures to address Stored XSS like CVE-2026-8438, WordPress website owners can reduce the risk created by unsafe debug log rendering and protect administrator sessions from client side compromise. Stay vigilant, stay secure.

#WordPressSecurity #StoredXSS #WebsiteSafety #StayProtected #HighVulnerability

Use CleanTalk solutions to improve the security of your website