FreeScout EUVD-2026-33437

Exploitation requires an active FreeScout user account with low-level authentication (PR:L per CVSS vector), meaning the attacker must have valid credentials. The specific condition enabling the flaw is that the user's FreeScout account remains active after their mailbox membership is revoked - full account deletion or disabling prevents exploitation. The user must have previously created at least one internal note (private thread) in the target conversation. Exploitation is limited to deletion of notes the attacker created; the policy failure does not grant broader read or write access. There is no requirement for a specific non-default configuration - the flaw exists in the default authorization policy of any FreeScout instance running a version prior to 1.8.221.

The CVSS 4.3 score reflects a moderate but bounded risk: the attack vector is network (AV:N), complexity is low (AC:L), privileges required are low (PR:L), no user interaction is needed (UI:N), and the impact is limited to integrity (I:L) with no confidentiality or availability consequences. The real-world risk profile is almost entirely an insider-threat or improper-offboarding scenario - exploitation requires an active FreeScout account and prior note creation in the target mailbox. No EPSS score was provided, and the vulnerability is absent from CISA KEV, indicating no known active exploitation. There is no publicly available exploit code. Despite the low CVSS, the risk to organizations is non-trivial in contexts where internal notes contain sensitive case discussions or privileged communications, as the damage (permanent deletion) is irreversible. The primary concern is data destruction by a disgruntled or careless former team member whose account was not fully revoked during offboarding.

A former support agent whose mailbox access was revoked but whose FreeScout account remains active authenticates to the application and sends crafted HTTP DELETE requests targeting thread IDs of internal notes they previously authored. Because ThreadPolicy::delete does not validate current mailbox membership, the requests succeed and the notes are permanently destroyed - potentially eliminating sensitive case history or privileged internal communications with no recovery path. No public exploit code exists, but the attack requires only standard authenticated HTTP requests.