CVE-2022-36801

What it actually does

CVE-2022-36801 is a reflected cross-site scripting vulnerability in Atlassian Jira Server and Jira Data Center affecting versions before 8.20.8. The TeamManagement.jspa endpoint accepts attacker-controlled input that can be reflected into an HTML response without sufficient neutralization, allowing arbitrary HTML or JavaScript to execute in the victim user's browser. Because exploitation is anonymous but requires user interaction, an attacker typically needs to convince a Jira user to open a crafted URL. Successful execution can allow actions within the victim's Jira session, exposure of page-visible data, phishing content injection, session-adjacent abuse depending on browser and cookie protections, and modification of user-accessible Jira content or settings.

Why it matters to the business

An attacker can use a malicious link to make Jira users unknowingly run attacker-supplied code in their browser. This can lead to theft of information visible to the user, unauthorized actions performed as that user, credential phishing, workflow disruption, or manipulation of issue-tracking content. The risk is higher for organizations with internet-facing Jira instances or users with elevated Jira privileges. Although this vulnerability is not listed in CISA KEV and no mature public exploit is indicated in the provided data, the EPSS score is high, so exposed systems should be prioritized for remediation.

How an attack unfolds

An attacker identifies a Jira Server or Jira Data Center instance running a vulnerable version before 8.20.8. The attacker crafts a URL targeting the TeamManagement.jspa endpoint with a parameter value containing HTML or JavaScript payload syntax. The attacker then delivers the link through email, chat, issue comments, external ticket submissions, documentation links, or another social-engineering path. When a logged-in Jira user opens the URL, Jira reflects the malicious input into the page response and the victim's browser executes the script in the Jira origin. The script can read page content available to the user, present fake login prompts, modify the displayed page, or perform actions that the victim is authorized to perform through Jira's web interface. If the victim has administrative or project-management privileges, the impact can extend to configuration changes, project data manipulation, or access to sensitive issue data.

How to fix it

Upgrade Atlassian Jira Server and Jira Data Center to version 8.20.8 or later. If direct upgrade is not immediately possible, restrict access to Jira to trusted networks or VPN users, reduce exposure of internet-facing Jira instances, and use a web application firewall or reverse proxy rule to block suspicious requests to TeamManagement.jspa containing script-like input such as <script, javascript:, event-handler attributes, encoded angle brackets, or HTML injection patterns. Enforce strong browser security controls where possible, including modern SameSite and HttpOnly cookie protections, and ensure users with administrative privileges avoid opening untrusted links while authenticated. Mitigations should be treated as temporary; upgrading to a fixed version is the definitive remediation.

How to confirm the fix worked

Confirm the installed Jira Server or Data Center version is 8.20.8 or later. Review Atlassian application version information from the administrative UI, package inventory, deployment manifests, container images, or installation metadata. Validate externally that requests to TeamManagement.jspa no longer reflect unsanitized HTML or JavaScript by using a harmless test payload in a controlled environment and confirming it is encoded rather than executed. Confirm reverse proxy, WAF, and access-control mitigations are active if the system cannot yet be upgraded. Re-scan application inventory and vulnerability management tooling to ensure no vulnerable Jira instances remain, including staging, disaster recovery, and non-production systems.

Typical attack path

1. Attacker discovers a Jira Server or Jira Data Center instance exposed to the network or internet.
2. Attacker determines or infers that the instance is running a version before 8.20.8.
3. Attacker crafts a malicious URL targeting the TeamManagement.jspa endpoint with injected HTML or JavaScript.
4. Attacker sends the link to a Jira user through phishing, chat, ticket comments, documentation, or another lure.
5. Victim opens the crafted link while authenticated to Jira.
6. Jira reflects the attacker-controlled content in the HTTP response.
7. Victim browser executes the malicious script in the Jira site context.
8. Attacker abuses the victim's Jira permissions to read visible data, phish for credentials, alter issue content, or perform unauthorized actions.

How to detect it

Investigate web server, reverse proxy, load balancer, WAF, CDN, and Jira application access logs for requests to TeamManagement.jspa containing HTML or JavaScript payloads. Focus on GET requests with encoded or raw characters associated with cross-site scripting, including <script>, %3Cscript, javascript:, onerror=, onload=, iframe, svg/onload, img src, document.cookie, fetch(, XMLHttpRequest, or encoded angle brackets. Correlate suspicious requests with authenticated Jira user sessions and subsequent Jira audit events such as permission changes, project configuration updates, user or group changes, workflow modifications, issue edits, unusual bulk changes, or unexpected administrative actions. Review authentication logs for unusual logins following suspicious link activity, especially from new geographies, new user agents, or impossible-travel patterns. Check browser telemetry or endpoint detection data, where available, for Jira pages spawning unusual outbound connections, loading unfamiliar external script URLs, or users reporting unexpected login prompts within Jira. Because this is reflected XSS, durable server-side artifacts may be limited unless the payload caused follow-on actions; access logs and user activity correlation are the most important evidence sources.

• TeamManagement.jspa
• GET /secure/TeamManagement.jspa
• POST /secure/TeamManagement.jspa
• %3Cscript
• <script
• %3C%2Fscript%3E
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• %3Cimg
• <img
• %3Csvg
• <svg
• %3Ciframe
• <iframe
• document.cookie
• document.domain
• window.location
• eval(
• alert(
• prompt(
• confirm(
• fetch(
• XMLHttpRequest
• new Image()
• String.fromCharCode
• atob(
• btoa(
• %253Cscript
• %3Cbody%20onload
• svg/onload

What your security team should do

• Prioritize upgrade of all Jira Server and Jira Data Center instances running versions before 8.20.8, especially internet-facing systems.
• Inventory all Jira deployments, including Data Center nodes, test systems, archived systems, and externally reachable instances.
• Temporarily restrict access to Jira from untrusted networks until the upgrade is complete.
• Add WAF or reverse-proxy detections for suspicious TeamManagement.jspa requests containing script tags, encoded HTML, javascript: URLs, or browser event-handler attributes.
• Search web access logs for historical requests to TeamManagement.jspa with XSS payload patterns to assess possible prior exploitation.
• Review high-privilege Jira user activity around suspicious requests, including administrative changes, project permission changes, issue modifications, and user-management events.
• Educate Jira users and administrators not to open unsolicited Jira links while remediation is in progress.
• Ensure phishing-resistant MFA is enabled for Jira and related identity providers to reduce follow-on account compromise risk.