Cachet CVE-2026-113712

Exploitation requires a high-privilege authenticated account with permission to create or edit incident messages (and, per the diffs, component descriptions, schedules, updates, or the About page), because those Markdown fields were rendered with the unescaped Blade {!! !!} directive. A second precondition is that a victim must view the affected public status page for the stored payload to execute (UI:P). The vulnerability is present in default configurations of Cachet 2.4.1 and earlier - no special feature toggle is needed - but exploitation is meaningfully limited by the PR:H requirement: status pages typically grant incident-authoring rights only to a small set of trusted operators, so the realistic attacker is a malicious or compromised privileged user rather than an anonymous one.

This is a genuinely low-to-moderate real-world risk, and the signals are consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:P) scores 4.8 (Medium), and the two dominant limiting factors are PR:H and UI:P: the attacker must already hold a high-privilege account capable of creating/editing incidents, and a victim must actively view the affected status page for the stored payload to fire. Impact is confined to the subsequent system (the victim's browser) with SC:L/SI:L and no impact to the Cachet host itself (VC:N/VI:N/VA:N), which matches a classic stored-XSS profile - session/token theft and potential account takeover of status-page viewers rather than server compromise. No EPSS score, KEV listing, or public POC was supplied; there is no public exploit identified at time of analysis, so this should not be treated as an active-exploitation emergency. The main nuance: 'authenticated attacker' in the description plus PR:H means the real threat is an already-trusted operator or a compromised admin account, not an anonymous internet attacker - this is a privilege-abuse / insider-leaning issue, which substantially lowers priority versus an unauthenticated XSS. Patch commits are confirmed in cachethq/core, so remediation is clearly available.

An attacker who already holds a privileged Cachet account (able to create or edit incidents) submits an incident message containing malicious HTML/JavaScript, which is stored and rendered unescaped on the public status page. When any user - including other administrators - subsequently views that status page, the script executes in their browser, enabling session token theft and potential account takeover. No public exploit code was provided, but the payload is trivial to craft (e.g. a <script> tag in the incident message) given the required privileges.