Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessEmail Incident Report with scripted subject
-
ExploitSubject stored unescaped in RTIR
-
ExecutionHandler opens split/create-incident form
-
ImpactScript executes in handler's RT session
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Two preconditions must hold. First, an attacker must be able to submit an Incident Report whose subject they control - satisfied by default because RTIR grants everyone the right to create Incident Reports, so an unauthenticated, remote sender can set the subject via an emailed report. Second, an authenticated incident handler must open one of the specific affected forms - splitting a ticket, or creating an incident from a report - which renders the attacker-controlled subject without HTML escaping and executes the script in that handler's RT session. Limiting factors: exploitation is passive-user-interaction dependent (the handler must open the form), impact is confined to the acting handler's RT privileges, and only RTIR 6.x before 6.0.4 is affected - RTIR 5.0 is explicitly not affected. The complete fix is upgrading to RTIR 6.0.4 as stated by the vendor. |
| Impact | This is a medium-severity stored cross-site scripting flaw (CWE-79) in RTIR's ticket-creation workflows, and the supplied signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) correctly reflects a two-party design: the attacker who plants the payload is unauthenticated and remote (PR:N), because RTIR grants everyone the right to create Incident Reports by default, so a payload can be delivered simply by emailing a report with a scripted subject; execution, however, is gated on an incident handler opening the split or create-incident form (UI:P / Passive user interaction). The vuln.today priority is 'this_month', not act_now or emergency, and there is no CISA KEV listing, no EPSS probability supplied, and no proof-of-concept or exploit reference in the input - so there is no evidence of active exploitation or public exploit code. Impact is explicitly partial (VC:L/VI:L, VA:N) and bounded by the privileges of the targeted handler's RT session rather than yielding full account or system compromise. Net: a genuine, credible stored-XSS risk against incident responders that warrants scheduled patching, but not an emergency; its real-world urgency is tempered by the required handler interaction and the modest, session-scoped impact. Note the primary reference URL cites CVE-2026-105454, one digit off from this CVE ID - the advisory linkage should be verified with CERT-PL/Best Practical. |
| Exploit ScenarioDerived | An attacker emails an Incident Report to an RTIR instance (allowed to anyone by default) with a ticket subject containing a malicious <script> payload. When an incident handler later opens the form to split that ticket or create an incident from the report, the unescaped subject executes JavaScript in the handler's authenticated RT session, letting it act with that handler's authority. No public exploit code or PoC reference is present in the supplied data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 30, 2026
Stored cross-site scripting in RTIR 6.x before 6.0.4 allows an unauthenticated sender of an emailed Incident Report to plant script in a ticket subject that executes in an incident handler's RT session. Because RTIR grants everyone the right to create Incident Reports by default, the attacker controls the subject without any credentials; the payload fires only when an authenticated handler opens the ticket-split form or the create-incident-from-report form, which render that subject without HTML escaping. Impact is therefore limited to the acting handler's RT authority, and the vendor states the issue is fully fixed by upgrading to RTIR 6.0.4, with RTIR 5.0 explicitly unaffected; no public exploit code was identified at time of analysis and the source is not listed as actively exploited (no CISA KEV entry).
RemediationAI
Apply the vendor fix: upgrade RTIR to 6.0.4, which resolves the missing HTML escaping in the ticket-split and create-incident-from-report forms; installations on the 5.0 branch are unaffected and do not need to change. Advisory references are https://requesttracker.com/rtir/ and https://cert.pl/en/posts/2026/10/CVE-2026-105454. As a temporary compensating control for environments that cannot update immediately, tighten the default RTIR privilege that lets everyone create Incident Reports so that emailed, unauthenticated report submission is restricted to known sender addresses or a vetted queue - the trade-off is that this blocks legitimate anonymous incident reporting, and it does not protect against a subject already stored on an existing report, so handlers should still treat pre-existing report subjects as untrusted. The vendor presents updating as the complete fix, so configuration tightening should be viewed as interim only.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
RTIR (RT for Incident Response) is Best Practical's extension to Request Tracker (RT) that adds incident-response workflows - Incident Reports, Incidents, Investigations and Constituencies - on top of RT's ticket engine. The flaw is CWE-79 (improper neutralization of input during web page generation, cross-site scripting), and it is stored rather than reflected: the attacker-controlled value is a ticket Subject that is persisted when an Incident Report is queued by email, then retrieved and interpolated into HTML in RTIR's ticket-creation forms (the split-ticket form and the create-incident-from-report form) without HTML escaping. The default RTIR permission model makes Incident Report creation available to everyone, including unauthenticated email senders, so the injection point is reachable anonymously; the execution point, however, requires an authenticated incident handler to open one of those two forms, which is why exploitation requires user interaction (CVSS 4.0 UI:P; the independent assessment maps this to CVSS 3.1 UI:R). Both the vendor vector and the independent CVSS 3.1 vector place the flaw at network reachability with no privileges required (PR:N) and a scope change (S:C / SC:L, SI:L), reflecting that the script runs with the handler's session and can perform RT actions under that user's authority. Confidentiality and integrity are low-impact, availability is not impacted. The CPE cpe:2.3:a:best_practical_solutions:rt_for_incident_response with a wildcard version applies to the 6.x line before 6.0.4; RTIR 5.0 is explicitly out of scope. The precise code path that constructs the affected HTML is not described in the available sources.
Know when Rt For Incident Response gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Attacker plants payload unauthenticated over the network (PR:N), execution needs a handler to open the form (UI:R), and script runs in the victim's session across a trust boundary (S:C) with partial C/I impact.
Primary rating from Vendor (CERT-PL).
CVSS VectorVendor: CERT-PL
Lifecycle Timeline
1DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
EUVD-2026-114130
GHSA-8whf-jvmp-ghv3
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB