AliasVault CVE-2026-94621

Exploitation requires a specific stacked configuration, all stated in the advisory: (1) a publicly reachable self-hosted AliasVault server (<0.30.3), (2) public registration enabled so the attacker can obtain an account, (3) an authenticated AliasVault account (low privilege), (4) an attacker-controlled authoritative DNS server to serve differing records between the validation and connection lookups, and (5) a resolver that permits DNS rebinding. Exploitation is further LIMITED by default port checks that restrict outbound requests to ports 80 and 443, by the high timing coordination needed to win the TOCTOU window between the two lookups, and by scope: only the server-side favicon extractor is affected - the browser extensions, web application, and mobile applications are explicitly NOT affected. Instances with public registration disabled or that are not publicly reachable are not practically exploitable by external attackers.

This is a genuine but conditional SSRF via DNS rebinding (CWE-367 TOCTOU: a first DNS lookup validates the hostname, a second lookup during connection is trusted), and the real-world risk is moderate rather than urgent. The provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N = 6.3 Medium) is internally consistent with the description: network reachable but high complexity (AC:H reflects the need for an attacker-controlled authoritative DNS server plus a rebinding-permissive resolver), low-privilege authentication (PR:L matches 'authenticated low-privileged user'), and a scope change (S:C) because the vulnerable API server is coerced into reaching other internal systems. No EPSS score, KEV entry, or POC was supplied in the input, so there is no public exploitation signal to weigh against the CVSS - meaning priority rests entirely on the theoretical vector, which is itself gated by several stacked preconditions. The one point of tension: the vendor rates confidentiality as C:H, but the described disclosure is limited (Base64 of valid favicon images plus timing/error-based internal reconnaissance), so C:H likely overstates real impact - I assess C:L (see assessed vector). Net: a real priority only for operators running a publicly reachable self-hosted instance with open registration; for everyone else it is a defense-in-depth fix, not an emergency.

An attacker registers a low-privileged account on a publicly reachable self-hosted AliasVault instance with open registration, then submits a hostname served by their own authoritative DNS. During AliasVault's validation lookup the DNS returns a public address, but during the HTTP client's second lookup it returns a private/internal address (classic rebinding), causing the server to fetch internal resources on port 80/443 and return valid images Base64-encoded plus timing/error signals. No public exploit code was identified in the provided data, though the technique is well-understood and the fix diff publicly documents the flawed single-validation path.