Emissary has Stored XSS via Navigation Template Link Injection

Upgrade to 8.39.0

Attack vector

An administrator sets a navigation item's link to:

javascript:alert(document.cookie)

Any authenticated user who clicks the navigation link executes the script in their browser context.

Impact

• Session hijacking via cookie theft
• Actions performed on behalf of the victim user
• Requires administrative access to modify navigation configuration
• Requires user interaction (clicking the malicious link)

Mitigating factors

• Exploitation requires administrative access to modify the navItems configuration
• User interaction (clicking the link) is required
• The Emissary web interface is typically accessed only by authenticated operators within a trusted network

Remediation

Fixed in PR #1293, merged into release 8.39.0.

Server-side link validation — NavAction.java

An allowlist regex was added that only permits http://, https://, or site-relative (/) URLs:

private static final Pattern VALID_LINK = Pattern.compile("^(https?:/)?/.*");

private static boolean isValidLink(String link) {
    if (!VALID_LINK.matcher(link).matches()) {
        logger.warn("Skipping invalid navigation link '{}'", link);
        return false;
    }
    return true;
}

Invalid links are logged and silently dropped from the rendered navigation.

Template hardening — nav.mustache

Added rel="noopener noreferrer" to all navigation link anchor tags as a defense-in-depth measure:

<a class="nav-link" href="{{link}}" rel="noopener noreferrer">{{display}}</a>

Tests were added to verify that javascript: and ftp:// URIs are rejected while http://, https://, and site-relative (/path) links are accepted.

Workarounds

If upgrading is not immediately possible, audit the navigation configuration to ensure all navItems link values use only http://, https://, or relative (/) URL schemes.

References

• PR #1293 — validate nav links
• Original report: GHSA-wjqm-p579-x3ww