FreeScout anfällig für CSS-Injektion über ein gespeichertes Style-Tag in der Mailbox-Signatur (CSRF-Token-Exfiltration)

The vulnerability lies in FreeScout's inadequate sanitization of <style> tags within the mailbox signature field. While the application attempts to remove other potentially dangerous HTML tags like <script> and <iframe>, it fails to strip <style> tags. These tags are then rendered unescaped in conversation views, and due to the existing Content Security Policy (CSP) allowing inline styles, injected CSS can execute freely. An attacker who has access to mailbox settings, either as an administrator or an agent with mailbox permissions, can exploit this to inject malicious CSS. This could lead to XSS, allowing the attacker to steal user cookies, redirect users to phishing sites, or deface the application’s interface.

Organizations using FreeScout for help desk and shared mailbox management are at risk, particularly those running versions 1.0.0 through 1.8.212. Shared hosting environments where multiple users share a FreeScout instance are especially vulnerable, as an attacker could potentially compromise the settings of one mailbox and impact other users.

• php: Examine FreeScout logs for POST requests to /mailbox/settings/{id} containing <style> tags with unusual or obfuscated content. Use grep to search for patterns like style=javascript: or style=expression.

grep 'style=javascript:' /var/log/freescout/access.log

• generic web: Monitor HTTP POST requests to /mailbox/settings/{id} for suspicious CSS content in the request body. Use a WAF or intrusion detection system to flag such requests. • generic web: Check mailbox signatures for unusual CSS patterns. Inspect the HTML source code of conversation views for injected <style> tags.

1. 2026-04-21Disclosure

   disclosure

1. Reserviert2026-04-13
2. Veröffentlicht2026-04-21
3. EPSS aktualisiert2026-04-28

The primary mitigation for CVE-2026-40497 is to immediately upgrade FreeScout to version 1.8.213 or later, which includes the necessary fix. If upgrading is not immediately feasible, consider implementing a Web Application Firewall (WAF) rule to block POST requests to /mailbox/settings/{id} containing potentially malicious <style> tags. Additionally, review and restrict mailbox permissions to limit the number of users who can modify mailbox settings. Monitor FreeScout logs for suspicious POST requests to the settings endpoint. After upgrading, confirm the fix by attempting to inject a simple <style> tag into a mailbox signature and verifying that it is properly sanitized and does not execute.