CVE-2021-41951

What it actually does

This is a reflected cross-site scripting flaw: user-controlled input supplied through the wordpress_user parameter to plugins/wordpress_sso/pages/index.php is reflected into an HTTP response without sufficient output encoding or sanitization. An unauthenticated attacker can craft a URL that causes JavaScript to execute in the victim's browser under the vulnerable application's origin. Because execution occurs in the trusted web origin, the script may read page content, interact with the application as the user, submit requests using the user's session, alter displayed content, or capture tokens and form data accessible to client-side code. The vulnerability requires user interaction but does not require attacker authentication. The provided affected-product metadata references swagger-api/swagger-ui with a fixed Git commit of 86e7f002c6dc55c935e18e82f9c5576dc48a7ff2, while the vulnerability description references ResourceSpace before 9.6 rev 18290; organizations should validate exposure against both the deployed application and dependency inventory where this record appears.

Why it matters to the business

Successful exploitation can allow attackers to abuse trusted application sessions, mislead users, steal data visible in the browser, perform unauthorized actions as victims, and damage trust in the affected web application. Although this is not a direct server compromise, the high EPSS score and weaponized exploit maturity indicate elevated likelihood of real-world exploitation, especially for internet-facing deployments or applications used by privileged staff. Operational consequences may include account takeover investigations, user notification, session invalidation, help-desk load, and emergency patching across applications that embed the affected component or plugin.

How an attack unfolds

An attacker identifies a vulnerable deployment exposing the affected page or component. They craft a URL containing malicious JavaScript in the wordpress_user parameter, using common encodings to evade basic filtering and to ensure the payload is reflected into the generated page. The attacker then delivers the link through phishing, chat, support tickets, documentation links, comments, or another channel likely to be opened by an authenticated user. When the victim visits the URL, the application returns a page that includes the attacker-controlled script. The browser executes the script in the security context of the vulnerable application, allowing the attacker to read accessible page data, issue same-origin requests with the victim's cookies, modify the interface, redirect the user, or exfiltrate tokens or sensitive values available to client-side JavaScript. If the victim has administrative privileges, the attacker may use the session to make configuration changes or create persistence through application-level settings, depending on what the application permits from the browser.

How to fix it

Upgrade or patch the affected software immediately. For ResourceSpace deployments matching the vulnerability description, upgrade to ResourceSpace 9.6 rev 18290 or later. For environments where this record is mapped to swagger-api/swagger-ui, update to a version containing commit 86e7f002c6dc55c935e18e82f9c5576dc48a7ff2 or a later trusted release that includes the fix. Remove duplicate or vendored vulnerable copies from application bundles, static asset directories, container images, and package lockfiles. If immediate patching is not possible, restrict access to the affected page, disable the affected WordPress SSO plugin or vulnerable integration, add server-side validation for wordpress_user, apply context-aware output encoding, and consider a temporary web application firewall rule blocking script-like input to the vulnerable parameter. Defense-in-depth measures should include a restrictive Content Security Policy that limits inline script execution, HttpOnly and SameSite session cookies where compatible, CSRF protections for state-changing actions, and forced session rotation after patching if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed version or source revision is at or beyond the fixed level: ResourceSpace 9.6 rev 18290 or later for the ResourceSpace path described, and commit 86e7f002c6dc55c935e18e82f9c5576dc48a7ff2 or a later fixed release for swagger-api/swagger-ui inventories where applicable. Search source code, containers, and web roots for plugins/wordpress_sso/pages/index.php and verify the wordpress_user parameter is safely handled with allow-list validation and context-appropriate output encoding. Perform a safe reflected-XSS validation using a harmless marker value such as xss_validation_marker rather than active script; the marker should not be reflected unsafely into HTML, JavaScript, or attribute contexts. Use a web security scanner or manual proxy testing to verify that encoded variants of angle brackets, event handlers, script tags, javascript: URLs, and SVG payloads are neutralized. Validate that deployed static assets and application images have been rebuilt, caches/CDNs purged, and no older vulnerable copies remain reachable.

Typical attack path

1. Discover an internet-accessible or user-accessible instance running the vulnerable page, plugin, or embedded component.
2. Confirm that input supplied to the wordpress_user parameter is reflected into the response without safe encoding.
3. Create a malicious URL containing a JavaScript payload in the wordpress_user parameter, often URL-encoded or HTML-encoded.
4. Deliver the crafted URL to a target user through phishing, messaging, documentation, comments, or another social-engineering path.
5. Wait for the victim to open the link while authenticated to the affected application.
6. Execute JavaScript in the victim's browser under the trusted application origin.
7. Use the victim's session to read accessible data, submit state-changing requests, capture tokens or form values, redirect the user, or perform privileged actions available to that user.
8. Exfiltrate collected data to attacker-controlled infrastructure or chain the browser compromise into further account or application abuse.

How to detect it

Review HTTP access logs, reverse-proxy logs, WAF events, CDN logs, application logs, and EDR/browser telemetry for requests to plugins/wordpress_sso/pages/index.php containing the wordpress_user parameter with script-like content, encoded HTML tags, JavaScript event handlers, javascript: URLs, SVG payloads, or references to external domains. Because reflected XSS often leaves little server-side evidence beyond the initial request, prioritize URL query-string logging and look for successful 200 responses followed by unusual same-session actions, privilege changes, configuration changes, new API tokens, unexpected file downloads, or suspicious redirects. Search for both raw and encoded payloads, including %3Cscript, %3Csvg, onerror=, onload=, eval(, document.cookie, localStorage, fetch(, XMLHttpRequest, and external callback domains. Investigate phishing reports or user complaints that include links to the vulnerable page. If browser telemetry is available, look for script execution, navigation, or network connections to untrusted domains immediately after visiting the affected application. Treat evidence of exploitation as potential account/session compromise and review activity for the affected user accounts during and after the request window.

• plugins/wordpress_sso/pages/index.php
• wordpress_user=
• %3Cscript
• <script
• %3C%2Fscript%3E
• </script>
• onerror=
• onload=
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• %3Csvg
• <svg
• document.cookie
• localStorage
• sessionStorage
• eval(
• fetch(
• XMLHttpRequest
• new Image(
• plugins/wordpress_sso/pages/index.php?wordpress_user=
• /plugins/wordpress_sso/pages/index.php?wordpress_user=
• 86e7f002c6dc55c935e18e82f9c5576dc48a7ff2

What your security team should do

• Prioritize remediation for internet-facing instances and applications used by administrators or support personnel because exploit maturity is weaponized and EPSS likelihood is high.
• Inventory deployments for both the described ResourceSpace WordPress SSO plugin path and any dependency records that map this vulnerability to swagger-api/swagger-ui; resolve the metadata discrepancy through software composition analysis and direct file/version checks.
• Patch to ResourceSpace 9.6 rev 18290 or later where applicable, or to a swagger-api/swagger-ui release containing commit 86e7f002c6dc55c935e18e82f9c5576dc48a7ff2 or later where applicable.
• Temporarily restrict access to the affected endpoint or disable the affected plugin/integration until patching is complete.
• Add WAF or reverse-proxy detections for script-like payloads in the wordpress_user parameter, but do not treat filtering as a substitute for patching.
• Review web access logs for historical requests to the affected path and parameter, including URL-encoded JavaScript payloads and external exfiltration URLs.
• If suspicious access is found, invalidate active sessions, review privileged account activity, and investigate browser-side account abuse or unauthorized configuration changes.
• Strengthen application-wide XSS resilience with Content Security Policy, secure cookie attributes, CSRF protections, and centralized output encoding practices.