FreeScout EUVD-2026-46081

The attacker must be able to send email to the helpdesk's public intake address (a default, intended capability of any FreeScout deployment accepting inbound customer email) and must supply a crafted In-Reply-To header referencing an existing conversation's message ID. No credentials, tokens, prior access, or user interaction are required, and default configurations are vulnerable. Practical limiting factors: the attacker needs a valid reference to an existing conversation to hijack (guessed, leaked in prior correspondence, or harvested from an email the attacker received), and impact is confined to the ticketing workflow (spoofed replies and reopenings) rather than host or data compromise. Only versions prior to 1.8.223 are affected.

The signals are internally consistent for a genuine, easy-to-trigger integrity issue but a bounded-impact one. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) correctly reflects trivial remote unauthenticated exploitation - one email, no user interaction, no special conditions against default configurations. The published score of 8.6 is driven by I:H with S:U, plus C:L and A:L; the primary real-world harm is integrity (identity spoofing and social-engineering of agents), not data disclosure or outage, so the C:L and A:L contributions are arguably generous - my independent assessment lands slightly lower (~7.5) by scoring C:N/A:N. No EPSS score, KEV entry, SSVC decision, or POC was provided, so exploitation-probability and automatability cannot be quantified from the input. Net: this is a real priority for any FreeScout operator because exploitation is trivial and abuses a core workflow (agents trusting reply provenance), but it is not a system-compromise or RCE-class event - the ceiling is fraud/social engineering within the ticketing workflow rather than takeover of the host.

An attacker obtains or guesses a live conversation reference for a target organization's public FreeScout address and sends a single crafted email whose In-Reply-To header points at that thread. The message appears to agents as a genuine customer reply, the ticket reopens, and last_reply_from shows the spoofed identity - enabling injection of fraudulent instructions (e.g., 'please send the refund to this new account') that a support agent may act on. No public POC was identified, but the attack requires only a mail client and no authentication.