CVE-2021-43942

What it actually does

This is a reflected cross-site scripting vulnerability in Atlassian Jira Server and Jira Data Center affecting the /rest/collectors/1.0/template/custom endpoint. The endpoint can reflect attacker-controlled HTML or JavaScript back to a user's browser without sufficient sanitization. Exploitation requires user interaction: an attacker must convince a Jira user to open a crafted link or visit a malicious page that causes the vulnerable Jira endpoint to render attacker-supplied script. If successful, the injected script executes in the security context of the Jira site, allowing actions available to the victim's browser session, such as reading page content, making same-origin requests, altering displayed content, or attempting to capture sensitive data accessible to that user. The CVSS score is 6.1, reflecting network exploitability, low attack complexity, no attacker authentication requirement, required user interaction, and limited confidentiality and integrity impact. It is not listed in CISA KEV and is not identified as ransomware-associated, but the EPSS score of 0.55364 indicates meaningful exploitation likelihood compared with most vulnerabilities.

Why it matters to the business

Successful exploitation can undermine trust in Jira by allowing attackers to abuse legitimate user sessions, target project data visible to the victim, perform unauthorized workflow or issue actions as the user, or launch convincing phishing prompts from within a trusted Jira page. The main operational risk is account misuse and data exposure rather than direct server takeover. Organizations with internet-facing Jira instances, large user populations, or privileged Jira administrators are at higher risk because a single successful click by a high-privilege user can have broader business consequences. The vulnerability is old and fixed versions have been available for a long time, so remaining exposure may indicate unmanaged or unsupported Jira installations that should be prioritized for remediation.

How an attack unfolds

An attacker first identifies a Jira Server or Data Center instance running an affected version: before 8.13.15, or 8.14.0 through versions before 8.20.3. The attacker crafts a URL or malicious web page that causes the victim's browser to request the vulnerable /rest/collectors/1.0/template/custom endpoint with HTML or JavaScript embedded in request parameters. The attacker then delivers the lure through email, chat, a compromised website, an issue comment, or another social-engineering channel. When a logged-in Jira user opens the link or page, Jira reflects the attacker-controlled content into the response, and the browser executes the script as if it came from the trusted Jira origin. The script may read information rendered in the page, issue same-origin Jira API requests using the victim's active session, redirect the user to credential theft pages, or modify issue data if the victim has permission. Because the flaw is reflected rather than stored, evidence is usually concentrated in web access logs, proxy/WAF telemetry, browser history, and any suspicious Jira actions occurring immediately after a request to the vulnerable endpoint.

How to fix it

Upgrade Atlassian Jira Server and Jira Data Center to a fixed version. Fixed Jira versions are 8.13.15 or later for the 8.13 LTS line, and 8.20.3 or later for the 8.20 line; later supported releases should also include the fix. If immediate upgrade is not possible, reduce exposure by restricting access to Jira to trusted networks or VPN, enforcing strong authentication and short session lifetimes, enabling phishing-resistant MFA where supported by the identity provider, and using a WAF or reverse proxy rule to block suspicious requests to /rest/collectors/1.0/template/custom containing script-like payloads such as <script, javascript:, event-handler attributes, or encoded equivalents. Security teams should also harden browser-side controls where feasible, including Content Security Policy, although CSP should be treated as defense-in-depth rather than a substitute for patching. The provided package fixed-version data referencing Debian intel-microcode does not align with the Jira vulnerability description and should not be relied on as remediation for this Jira issue; verify vulnerability management mappings against Atlassian Jira product versions.

How to confirm the fix worked

Confirm the installed Jira Server or Data Center version from the application administration interface, package metadata, deployment manifest, or vendor-supported version endpoint. The instance should be at least 8.13.15 if on the 8.13 branch, at least 8.20.3 if on the 8.20 branch, or on a later supported fixed release. Validate that no exposed Jira nodes in a clustered Data Center deployment remain on vulnerable versions. Review reverse proxy and application routing to ensure /rest/collectors/1.0/template/custom is not reachable from untrusted networks if compensating controls are required. Where safe and authorized, test with a benign encoded HTML marker against a non-production instance to confirm the endpoint no longer reflects executable content. Do not test with live credential-stealing or destructive JavaScript. Verify WAF rules by sending harmless encoded strings that resemble script syntax and confirming they are blocked or alerted. Reconcile scanner results carefully because the supplied affected product metadata may be inconsistent with the actual Jira product family.

Typical attack path

1. Reconnaissance identifies an Atlassian Jira Server or Data Center instance exposed to users or the internet.
2. The attacker determines or guesses that the instance is running a vulnerable version before 8.13.15, or 8.14.0 through before 8.20.3.
3. The attacker crafts a URL targeting /rest/collectors/1.0/template/custom with encoded HTML or JavaScript payload content.
4. The attacker delivers the crafted URL through phishing, chat, a malicious website, an issue comment, or another user-facing channel.
5. A Jira user opens the link or visits the malicious page while authenticated to Jira.
6. The vulnerable endpoint reflects the payload, causing JavaScript to execute in the user's browser under the Jira origin.
7. The script abuses the victim's session to read accessible data, make Jira requests, alter page content, or present phishing prompts.
8. The attacker uses any collected data or session-abused actions for follow-on access, fraud, workflow manipulation, or additional social engineering.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs from Jira, reverse proxies, load balancers, WAFs, CDN layers, and secure web gateways for requests to /rest/collectors/1.0/template/custom containing raw or URL-encoded HTML/JavaScript. Focus on payload markers such as <script, %3cscript, javascript:, onerror=, onload=, iframe, document.cookie, fetch(, XMLHttpRequest, or encoded equivalents. Because this is reflected XSS, server-side artifacts may show only the malicious request, not persistent changes. Correlate suspicious requests with authentication logs, SSO logs, Jira audit logs, and application activity around the same timestamp. Look for unexpected issue edits, project configuration changes, permission changes, user or group modifications, API token activity, webhooks, workflow changes, or administrative actions by the victim shortly after they accessed the vulnerable endpoint. Review Referrer headers for external websites, webmail, chat platforms, URL shorteners, or unfamiliar domains that may have delivered the lure. Browser history, EDR browser telemetry, and secure web gateway logs can help confirm whether a user clicked a crafted URL. WAF alerts for XSS payloads targeting this path should be treated as high-value leads even if blocked. Absence from CISA KEV and lack of known ransomware association reduce urgency relative to actively weaponized server-side flaws, but the high EPSS score and age of the vulnerability justify retrospective hunting on exposed Jira instances.

• /rest/collectors/1.0/template/custom
• /rest/collectors/1.0/template/custom?
• %2Frest%2Fcollectors%2F1.0%2Ftemplate%2Fcustom
• /rest/collectors/1.0/template/custom%3F
• <script
• %3Cscript
• %3cscript
• </script>
• %3C%2Fscript%3E
• %3c%2fscript%3e
• javascript:
• javascript%3A
• onerror=
• onerror%3D
• onload=
• onload%3D
• onclick=
• onclick%3D
• <img
• %3Cimg
• %3cimg
• <iframe
• %3Ciframe
• %3ciframe
• document.cookie
• document%2Ecookie
• document%252Ecookie
• XMLHttpRequest
• fetch(
• fetch%28
• eval(
• eval%28
• alert(
• alert%28

What your security team should do

• Inventory all Atlassian Jira Server and Data Center instances, including internal, internet-facing, disaster-recovery, and clustered Data Center nodes.
• Prioritize upgrading affected Jira instances to 8.13.15, 8.20.3, or a later supported fixed version, especially internet-facing systems and systems used by administrators or development teams with sensitive project data.
• Do not treat Debian intel-microcode package updates as a fix for this Jira vulnerability; validate product-to-CVE mapping in vulnerability management tooling.
• Until patched, restrict network access to Jira and add WAF or reverse proxy detections for suspicious requests to /rest/collectors/1.0/template/custom containing script-like or encoded payloads.
• Search historical proxy, WAF, load balancer, and Jira access logs for requests to the vulnerable endpoint with encoded HTML, JavaScript schemes, or event-handler attributes.
• Correlate suspicious endpoint requests with the authenticated user, source IP, referrer, user agent, and subsequent Jira actions such as issue edits, permission changes, token generation, project changes, or unusual administrative activity.
• Notify help desk and Jira administrators to report suspicious Jira pages, unexpected login prompts, browser pop-ups, or redirects from Jira links.
• Enforce MFA through the identity provider for Jira access where available and review privileged Jira accounts for unusual activity after any suspected exploitation.
• Consider adding browser and email protections that warn on suspicious links to Jira endpoints, especially links containing URL-encoded script characters.
• Document the exception and compensating controls if upgrade cannot be completed promptly, because this issue has been public since 2022 and should generally be remediated in normal patch baselines.