CVE-2026-22674: Hashgraph Guardian Stored XSS via Branding Configuration

Technical summary

The vulnerability exists in Guardian's branding service, which fails to properly sanitize user input before assigning the companyName value to the innerHTML property. The unsanitized assignment permits stored XSS injection via the branding configuration API endpoint. An attacker holding the STANDARD_REGISTRY role can craft a malicious payload in the companyName field that persists in the application state. On each authenticated user's page load, the injected script executes in their browser context with the privileges of their session. The vulnerability was remediated in commit ba8c566.

Business impact

This vulnerability enables persistent compromise of user sessions within Guardian deployments. An insider or compromised standard registry account can inject malicious scripts that affect all users in the system. Potential impacts include credential harvesting, unauthorized transaction initiation, data exfiltration, and erosion of user trust. Organizations running Guardian should treat this as a privilege-escalation and session-hijacking risk, particularly in multi-user environments where registry operators have administrative access.

Affected systems

Hashgraph Guardian through version 3.6.0 is affected. The vulnerability requires an authenticated account with STANDARD_REGISTRY role to exploit, limiting the attack surface to internal or trusted users with registry configuration privileges. Organizations should verify their Guardian deployment version and review access control policies for registry administrator accounts.

Exploitability

Exploitation requires prior authentication and the STANDARD_REGISTRY role, which reduces the attack surface significantly. However, the vulnerability is trivial to exploit once access is gained—a simple API call with a malicious companyName payload triggers persistent XSS. The attack does not require user interaction beyond normal site navigation, as the script executes automatically on every page load. The barrier to exploitation is organizational access and role assignment, not technical complexity.

Remediation

Update Hashgraph Guardian to a version incorporating the fix from commit ba8c566 (confirmed in versions after 3.6.0). Verify the update through official Guardian release notes. As an interim measure, restrict the STANDARD_REGISTRY role to trusted personnel only and audit recent branding configuration changes via API logs for malicious payloads containing script tags or event handlers.

Patch guidance

Obtain the patched version from the official Hashgraph Guardian repository or distribution channel. The fix is present in commits following ba8c566. Review your current version (check Guardian documentation or admin panel for version display) and plan an update to the latest available release. Test patched versions in a staging environment before production deployment to ensure compatibility with existing configurations.

Detection guidance

Monitor branding configuration API endpoint logs (/api/branding or similar) for POST/PUT requests containing suspicious companyName values with HTML tags, JavaScript keywords (script, onerror, onload, etc.), or encoded variants. Audit the stored branding configuration in Guardian's backend database for unexpected HTML or script content. Check browser console errors or JavaScript execution anomalies reported by users after branding updates. Implement Content Security Policy (CSP) headers to restrict inline script execution if not already in place.

Why prioritize this

Although the CVSS score is MEDIUM (4.8), the vulnerability merits elevated priority in multi-user Guardian deployments. The persistent nature of stored XSS, combined with automatic execution on every page load for all users, creates a high-impact attack surface despite the requirement for authenticated STANDARD_REGISTRY access. The fix is already available, making remediation straightforward. Organizations should prioritize this patch within their standard update cycles, especially those with sensitive use cases or regulatory compliance requirements.

Risk score, explained

The CVSS 3.1 score of 4.8 reflects the attack vector (network-based), low attack complexity, high privilege requirement (PR:H), required user interaction via UI navigation, changed scope (affecting the entire web application), and limited impact (low confidentiality and integrity, no availability impact). While the score is MEDIUM, the stored and persistent nature of the XSS increases practical risk—every authenticated user is affected continuously until remediated, justifying prioritization despite the numerical score.

Frequently asked questions