CVE-2026-113712 in Cachet
Summary
by MITRE • 10/20/2026
Cachet is an open-source status page system. Versions 2.4.1 and earlier have a stored Cross-Site Scripting (XSS) vulnerability in the incident creation form, allowing an authenticated attacker to inject malicious HTML/JavaScript that executes in the browser of any user who views the status page, potentially leading to session token theft and account takeover. Commits 57b44a8bac0b250b0d5751e93e0349070d14606e and 23adbb88ffa819f92be4a905ff1d812670d980a2 in `cachethq/core` patch the issue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
Cachet is an open-source status page system widely used by organizations to communicate service health and incident updates to their user base. In versions 2.4.1 and earlier, a critical security flaw exists within the application's architecture that permits stored Cross-Site Scripting attacks. This vulnerability specifically targets the incident creation form, which serves as the primary interface for administrators or authorized personnel to publish status updates. The core technical deficiency lies in the insufficient validation and sanitization of user-supplied input fields before they are persisted to the database and subsequently rendered back into HTML responses without proper encoding. Because the application treats stored content from this form as trusted data, it fails to neutralize special characters that carry executable script payloads. This architectural oversight allows an attacker who has obtained valid authentication credentials for a low-privilege account capable of creating incidents to inject malicious JavaScript code directly into the status page content.
The operational impact of this vulnerability is severe due to its stored nature and broad exposure surface. Unlike reflected XSS, which requires tricking a user into clicking a specific link, stored XSS persists on the server side until manually removed. Consequently, any user who visits the public-facing status page will have their browser execute the injected script automatically upon loading the compromised incident report. This execution occurs within the security context of the Cachet application domain, granting the malicious script full access to session cookies, local storage data, and other sensitive information associated with that origin. The most immediate consequence is the potential theft of session tokens for administrators or high-privilege users who view the page. Attackers can leverage these stolen credentials to perform account takeover attacks, gaining unauthorized administrative control over the status page infrastructure. This level of access allows attackers to manipulate public communications, deface the organization's reputation, or use the compromised system as a pivot point for further network intrusions by redirecting traffic to malicious domains or harvesting additional sensitive data from connected systems.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific mechanism is classified under CWE-83 in contexts where the script execution occurs within an HTML context without proper encoding. In terms of offensive security frameworks, this attack vector maps to MITRE ATT&CK technique T1059, specifically sub-technique 007 for JavaScript-based command execution or data exfiltration via browser environments. The persistence aspect of the vulnerability corresponds to techniques involving stored payloads that remain active until remediation is applied by system administrators.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Organizations running Cachet versions prior to 2.4.1 should immediately upgrade to a patched version, specifically utilizing commits 57b44a8bac0b250b0d5751e93e0349070d14606e and 23adbb88ffa819f92be4a905ff1d812670d980a2 from the cachethq/core repository, which implement proper input sanitization. For environments where immediate patching is not feasible, implementing a Web Application Firewall with rules capable of detecting and blocking script injection patterns in form submissions can provide temporary protection. Additionally, enforcing strict Content Security Policy headers that restrict inline script execution can significantly reduce the impact of any successfully injected payloads by preventing the browser from executing untrusted scripts unless they are explicitly whitelisted via nonces or hashes. Regular security audits focusing on input validation and output encoding practices across all user-facing forms are essential to prevent recurrence of such vulnerabilities in future development cycles.