Faveo Helpdesk EUVD-2026-65158

No special authentication or account is required - the post-ticket-reply endpoint processes submissions without verifying the caller's identity, making this exploitable by any remote, unauthenticated party with network access to the Faveo Helpdesk instance. The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N confirms no privileges, no attack prerequisites, and no user interaction are needed. The primary limiting factor is that the attacker must supply or enumerate a valid ticket identifier to target a specific ticket thread; blind submission to unknown ticket IDs is ineffective. Impact is bounded to integrity and availability at low severity (VI:L, VA:L) with no confidentiality breach of existing ticket data. The vulnerability exclusively affects installations running versions 2.0.0 through 2.0.3.

The CVSS 4.0 score of 6.9 with vector AV:N/AC:L/AT:N/PR:N/UI:N reflects genuinely easy remote exploitation - no authentication, no complexity, no user interaction required - but a constrained blast radius (VI:L, VA:L only, VC:N). The E:P modifier confirms proof-of-concept code is publicly available, meaningfully elevating near-term exploitation likelihood beyond what the base score alone suggests. This vulnerability is not in the CISA KEV catalog, indicating no confirmed mass exploitation at time of analysis. EPSS data was not provided in the input. Real-world risk is moderate: missing authentication on a reply endpoint enables spam, social engineering via forged support replies, and ticket data manipulation - making this consequential for any organization where helpdesk communications are trust-sensitive channels. The vendor's non-response to responsible disclosure leaves no patch timeline, and the public POC further shortens the exploitation window. Organizations relying on Faveo Helpdesk in Internet-facing deployments should treat this as an active exposure requiring compensating controls now.

An unauthenticated external attacker sends a crafted HTTP POST request directly to the post-ticket-reply endpoint, omitting any session token or authentication credential. Because FormController::post_ticket_reply lacks an authentication check, the server processes the submission and appends attacker-controlled content to an existing support ticket thread. The attacker can use this to inject phishing links or misleading instructions into active customer support communications. A proof-of-concept demonstrating this exact technique has been publicly published via a GitHub issue.