CVE-2023-0992

What it actually does

This is a stored cross-site scripting flaw in which an unauthenticated remote attacker can place attacker-controlled JavaScript into a field derived from the HTTP User-Agent header. If the application stores that value and later renders it in an administrative, audit, analytics, security, or log-viewing page without proper output encoding, the script executes in the browser context of the user viewing that page. Successful exploitation can allow actions in the victim user's session, such as reading page-accessible data, abusing anti-CSRF tokens, modifying application settings, initiating privileged workflow actions, or pivoting to further account compromise depending on the privileges of the viewer.

Why it matters to the business

Public-facing sites using vulnerable versions can be poisoned by simple unauthenticated web requests, creating risk that administrators or operators trigger malicious browser code while reviewing logs or security events. The main operational impact is compromise of trusted application sessions, unauthorized configuration changes, defacement or content manipulation, and potential follow-on account takeover. Although this issue is not listed in CISA KEV and is not marked as ransomware-related, the EPSS score is very high, indicating a materially elevated likelihood of exploitation or scanning activity; because it has been public for years, unpatched instances should be treated as internet-exposed legacy risk.

How an attack unfolds

An attacker first identifies an exposed application or plugin version that records visitor metadata, including the User-Agent header, and displays it back to privileged users. The attacker then sends one or more HTTP requests with a crafted User-Agent containing JavaScript or HTML event-handler payloads. The vulnerable application stores that header value in logs, audit trails, security dashboards, request history, or similar pages. When an administrator or other privileged user later opens the affected page, the browser interprets the stored value as executable script rather than text. The script then runs with the victim user's authenticated browser context and can perform same-origin actions, harvest page-accessible tokens or nonces, alter settings, create malicious content, or stage additional payloads. Attackers commonly make the initial request look like routine scanning traffic to avoid drawing attention until a privileged user views the poisoned record.

How to fix it

Upgrade to a fixed release or fixed source revision. For deployments tracking shirasagi/shirasagi from Git, update to commit 3d8d9fe28c22aa21fd32dd96aeefbc4957567605 or a later commit containing the fix. For deployments matching the Shield Security plugin vulnerability description, update beyond vulnerable versions up to and including 17.0.17 to the vendor-fixed release. If immediate upgrade is not possible, apply compensating controls: sanitize and HTML-encode all displayed request headers, especially User-Agent; block or normalize suspicious User-Agent values at the edge; restrict access to administrative log and security-event pages; enforce strong Content Security Policy where compatible; and ensure session cookies are marked HttpOnly, Secure, and SameSite to reduce exploit impact. Do not rely only on input filtering, because log and dashboard rendering must safely encode untrusted stored values at output time.

How to confirm the fix worked

Confirm the installed package, plugin, or source revision is newer than the vulnerable version range and, where applicable, includes commit 3d8d9fe28c22aa21fd32dd96aeefbc4957567605. Review dependency lockfiles, plugin inventory, container images, and deployed source to ensure all runtime instances are updated, not only the repository. In a non-production or controlled test environment, send a request with a harmless User-Agent such as XSS-VALIDATION-TEST-<script>alert(1)</script> and verify that any log, audit, or administrative page displays the payload as inert escaped text rather than executable markup. Inspect rendered HTML and browser developer tools to confirm characters such as <, >, quotes, and event-handler attributes are encoded. Verify edge rules or WAF controls log and optionally block suspicious User-Agent values without disrupting legitimate clients.

Typical attack path

1. Identify a public web endpoint running a vulnerable version of the affected application or plugin.
2. Send an unauthenticated HTTP request with a malicious payload embedded in the User-Agent header.
3. Cause the application to store the malicious User-Agent value in a log, audit, security, analytics, or administrative view.
4. Wait for an administrator, moderator, or operator to open the affected page.
5. Execute JavaScript in the victim's authenticated browser session.
6. Use the victim's privileges to read sensitive page data, perform unauthorized application actions, change configuration, inject additional content, or establish persistence through application-level changes.

How to detect it

To determine whether exploitation was already attempted or successful, review logs that preserve raw HTTP request headers and administrative page access. Useful sources include web server access logs, reverse proxy logs, CDN logs, WAF events, application request logs, plugin or security-event logs, audit dashboards, and administrative activity logs. Search for User-Agent values containing HTML tags, script tags, JavaScript URI schemes, encoded angle brackets, event-handler attributes, suspicious external callbacks, or strings associated with token theft such as document.cookie, localStorage, fetch, XMLHttpRequest, eval, or atob. Correlate suspicious User-Agent entries with subsequent access to log, audit, security, or admin pages by privileged users; then review actions performed by those users immediately afterward. Indicators of successful exploitation may include unexplained administrator actions, new privileged accounts, changed site settings, unexpected redirects, new plugins/extensions, modified theme or template files, altered content, unusual outbound browser requests to attacker-controlled domains, or repeated poisoned User-Agent entries designed to trigger when logs are viewed. Because stored XSS payloads may be URL-encoded, HTML entity-encoded, mixed-case, or split across attributes, include decoded and normalized log searches in addition to raw string matching.

• User-Agent: <script
• User-Agent: </script>
• User-Agent: %3Cscript
• User-Agent: %3C%2Fscript%3E
• User-Agent: javascript:
• User-Agent: onerror=
• User-Agent: onload=
• User-Agent: onmouseover=
• User-Agent: onclick=
• User-Agent: document.cookie
• User-Agent: localStorage
• User-Agent: sessionStorage
• User-Agent: XMLHttpRequest
• User-Agent: fetch(
• User-Agent: eval(
• User-Agent: atob(
• User-Agent: new Image(
• User-Agent: String.fromCharCode
• User-Agent: <img
• User-Agent: <svg
• User-Agent: <iframe
• User-Agent: srcdoc=
• User-Agent: data:text/html
• XSS-VALIDATION-TEST

What your security team should do

• Prioritize patching internet-facing deployments because exploitation requires only an unauthenticated HTTP request and the EPSS score is very high.
• Inventory all affected application/plugin deployments, including source-based Git deployments, containers, and managed hosting instances.
• Upgrade shirasagi/shirasagi Git deployments to commit 3d8d9fe28c22aa21fd32dd96aeefbc4957567605 or later, and upgrade any Shield Security plugin deployments beyond version 17.0.17.
• Search historical web, application, reverse-proxy, CDN, WAF, and security-plugin logs for suspicious User-Agent payloads indicative of stored XSS attempts.
• Review administrative users' recent activity after any suspicious User-Agent entries, especially configuration changes, new users, new plugins/extensions, content edits, redirect changes, or unfamiliar scheduled tasks.
• Temporarily restrict administrative dashboard and log-view access to trusted networks or require additional authentication while patching.
• Deploy or tune WAF/edge detections for script tags, JavaScript URI handlers, and HTML event-handler attributes in User-Agent headers.
• After remediation, run a controlled validation test to confirm malicious-looking User-Agent values are escaped in all log and audit views.