CVE-2024-45642: IBM Security QRadar EDR XSS Vulnerability

CVE-2024-45642 Overview

IBM Security ReaQta 3.12 contains a stored cross-site scripting (XSS) vulnerability in its Web UI. A privileged user can embed arbitrary JavaScript that executes within the browsers of other users interacting with the affected interface. The injected script runs inside a trusted session context, allowing attackers to alter application behavior and potentially exfiltrate credentials or session data. The vulnerability is tracked as CWE-942 related weakness in the product's input handling. IBM has published a security advisory addressing the issue in the QRadar EDR product line, which succeeded the ReaQta branding.

Critical Impact
Authenticated attackers with privileged access can inject persistent JavaScript into the ReaQta Web UI, exposing credentials and session data of other users within a trusted browser context.

Affected Products

IBM Security ReaQta 3.12
IBM Security QRadar EDR (successor product)
Deployments running the affected Web UI on Linux hosts

Discovery Timeline

2024-11-14 - CVE-2024-45642 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-45642

Vulnerability Analysis

The flaw is a cross-site scripting (XSS) vulnerability located in the IBM Security ReaQta 3.12 Web UI. An authenticated user with elevated privileges can submit input containing JavaScript that the application stores or renders without adequate output encoding. When another user views the affected UI component, the injected script executes inside the victim's browser under the origin of the ReaQta console.

Because the endpoint detection and response (EDR) console handles sensitive operational data, execution inside a trusted session can be leveraged to read tokens, hijack in-flight requests, or manipulate UI actions on behalf of the victim. The attack does not require exploitation of memory corruption or authentication bypass, only the ability to store attacker-controlled content that the UI later renders.

Root Cause

The root cause is improper neutralization of input during Web UI rendering, classified under CWE-942 (Permissive Cross-domain Policy) as noted in the NVD entry. The application accepts JavaScript payloads from a privileged user and reflects them into the interface without stripping or encoding active script content. Trust placed in privileged users allowed the input path to bypass strict sanitization that would normally be applied to untrusted input.

Attack Vector

Exploitation requires network access to the ReaQta Web UI and valid credentials for a privileged account. The attacker submits a payload containing JavaScript through a field or configuration element rendered in the console. When a second operator opens the affected view, the browser executes the payload. The attacker can then read session cookies, capture keystrokes within the page, submit requests as the victim, or redirect the user to attacker-controlled infrastructure. No user interaction beyond normal use of the console is required by the victim.

Refer to the IBM Support Advisory for full technical scope and affected component details.

Detection Methods for CVE-2024-45642

Indicators of Compromise

Unexpected <script> tags, javascript: URIs, or HTML event handlers stored in ReaQta configuration fields, comments, or labels.
Anomalous outbound requests from operator browsers to unfamiliar domains while the ReaQta console is open.
Session tokens or API keys appearing in web server access logs for endpoints not typically involved in credential handling.
Privileged user accounts modifying UI-rendered fields at unusual times or from unusual source addresses.

Detection Strategies

Inspect ReaQta application and audit logs for changes made by privileged accounts to fields that render in the Web UI.
Deploy Content Security Policy (CSP) violation reporting on the console to surface inline script execution attempts.
Review browser telemetry from operator workstations for scripts loading from domains outside the ReaQta origin.
Correlate privileged user activity with subsequent authentication anomalies for other operators using the same console.

Monitoring Recommendations

Enable and centralize ReaQta administrative audit logs for changes to user-editable UI fields.
Monitor operator browser sessions for unexpected redirects, credential prompts, or JavaScript errors originating from the console.
Alert on new or modified privileged accounts within the EDR platform.
Track access patterns to the IBM Support Advisory referenced endpoints for policy compliance.

How to Mitigate CVE-2024-45642

Immediate Actions Required

Apply the fix documented in the IBM Support Advisory for IBM Security ReaQta and QRadar EDR.
Audit all privileged accounts on the ReaQta console and remove unused or excessive privileges.
Rotate credentials and session tokens for administrators who may have accessed a compromised UI view.
Review recent changes to user-editable UI fields for stored payloads and remove any suspicious content.

Patch Information

IBM has released a fix through its support portal. Administrators should consult the IBM Support Advisory for the exact fixed version and upgrade instructions applicable to their deployment of Security ReaQta or QRadar EDR. Upgrading to the vendor-supplied fixed release is the definitive remediation.

Workarounds

Restrict privileged console access to a minimal set of trusted administrators until the patch is applied.
Require multi-factor authentication for all accounts with edit rights on the ReaQta Web UI.
Access the console from dedicated administrative workstations with restricted browsing to reduce lateral impact of session hijack.
Enforce a strict Content Security Policy at any reverse proxy fronting the ReaQta Web UI to block inline script execution.

bash

# Example nginx reverse proxy header to restrict inline script execution
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;