CVE-2026-105455 in RT for Incident Response
Summary
by MITRE • 10/30/2026
RTIR's ticket creation forms show the subject of the related ticket when splitting a ticket or creating an incident from a report, and they render that subject without HTML escaping. A ticket subject containing script runs it when a user opens either form. RTIR grants everyone the right to create Incident Reports by default, so an unauthenticated sender of an emailed report can set that subject. The script then runs in the session of the incident handler who creates an incident from the report or splits it, and can act in RT with that user's authority.
The issue was fixed in version 6.0.4. RTIR 5.0 is not affected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
RTIR versions prior to 6.0.4 are vulnerable to a stored cross-site scripting flaw within the ticket creation workflow, specifically affecting the forms used when splitting an existing ticket or creating an incident from a report. The core technical deficiency lies in the application's failure to properly sanitize user-supplied input before rendering it in the web interface. When a subject line is provided for a new ticket or incident, RTIR displays this text directly without applying HTML escaping mechanisms. This oversight allows malicious actors to inject executable JavaScript code into what appears to be standard metadata fields within the system.
The severity of this vulnerability is significantly amplified by RTIR's default permission model, which grants all authenticated users the ability to create Incident Reports. Consequently, an attacker who has obtained valid credentials for a low-privilege account can submit a report containing a crafted subject line with embedded script tags and event handlers. Although the initial submission occurs via email or web form, the payload is stored in the database associated with that report. The execution of this malicious code does not occur at the time of submission but rather when an incident handler views the relevant ticket creation interface to process the incoming report.
This delayed execution model classifies the vulnerability as a persistent cross-site scripting attack vector. When an authorized user, such as a security analyst or incident responder, opens the form to split a ticket or create an incident from the compromised report, their browser parses and executes the injected JavaScript within the context of the RTIR application session. Because the script runs in the authenticated user's session, it inherits all privileges associated with that account. This enables attackers to perform actions on behalf of the victim, such as modifying other tickets, exfiltrating sensitive incident data, or manipulating system configurations without detection by standard security monitoring tools focused solely on input validation at submission time.
From a threat intelligence perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. The attack technique maps to the ATT&CK framework under T1059, specifically Command and Scripting Interpretation via JavaScript, and falls within the initial access or persistence phases depending on how the script is utilized by the attacker. The ability to execute arbitrary code in a privileged session allows for potential privilege escalation if combined with other vulnerabilities or social engineering tactics aimed at higher-privileged administrators who might interact with tickets created by lower-level users.
To mitigate this risk, organizations running RTIR versions prior to 6.0.4 must upgrade immediately to version 6.0.4 or later, where the developers have implemented proper output encoding for ticket subjects in these specific forms. It is important to note that RTIR version 5.0 is not affected by this particular flaw due to differences in its codebase structure regarding how input is handled during incident creation workflows. Until an upgrade can be performed, administrators should consider restricting who has permission to create Incident Reports or implementing a web application firewall rule set designed to detect and block common cross-site scripting payloads within ticket subject fields as a temporary compensating control.