Live Helper Chat CVE-2026-44633

Exploitation requires valid REST API credentials with the lhchat/use permission role assigned to the attacker or compromised account. The vulnerable deployment must implement department-based access controls with multiple departments configured, as the authorization bypass only matters when departments exist to separate data access. The REST API chat update endpoint must be network-accessible to the attacker's position, which is default for most deployments but may be restricted by firewall rules or authentication proxies in hardened environments. For the XSS component, operator users must actively view manipulated chats in the dashboard interface for JavaScript execution to occur. Default installations of Live Helper Chat 4.84v with REST API enabled and department features active meet all exploitation prerequisites without requiring non-standard configurations.

Real-world risk is moderate-to-high for organizations using Live Helper Chat's departmental access controls. CVSS 8.1 (High) reflects network-accessible exploitation with low complexity requiring only low-privileged authentication (PR:L), producing high confidentiality and integrity impact. The attack chain requires a valid REST API credential with lhchat/use permission, which in multi-tenant or departmentalized deployments represents a realistic insider threat or compromised low-privilege account scenario. EPSS probability unavailable but the combination of authorization bypass plus stored XSS affecting privileged users (operators/admins) represents significant business risk. No CISA KEV listing or public exploit code identified, suggesting exploitation remains theoretical or limited. However, the GitHub Security Advisory publication means technical details are publicly available to potential attackers. Priority should be elevated if the application uses department-based access controls or has externally-facing REST API access, as these configurations maximize the attack surface. Organizations not using departmental restrictions or REST API features face reduced risk.

An attacker with a compromised low-privilege REST API account holding lhchat/use permission targets chats in departments they cannot normally access. They issue authenticated API requests to the chat update endpoint, modifying the chat hash field to match another department's chat and changing the status to make it accessible through visitor/widget paths that bypass department authorization. The attacker retrieves confidential customer conversations through these public-facing paths. To establish persistence and escalate privileges, they set the operation_admin field to malicious JavaScript payloads. When legitimate support operators view the manipulated chat in their dashboard, the injected code executes in their browser session, potentially stealing operator credentials or performing administrative actions under their authority.