Jira Work Management stored XSS bug could open the door to wider Atlassian compromise

A stored XSS flaw in Jira Work Management could let a lower-tier admin plant malicious JavaScript in a custom priority’s icon URL, then wait for a more privileged admin to load the affected settings page. Snapsec says that chain can end with an organization-level compromise if the victim holds broader Atlassian admin rights.

The issue matters because the vulnerable field sits inside a legitimate Jira administration workflow. Atlassian’s own documentation shows that Jira admins can edit priorities and paste values into the Icon URL field, while Snapsec says the application failed to safely handle a malicious payload placed there during its testing.

In practice, the bug turns a routine configuration screen into a stored code execution point inside an authenticated admin session. That does not automatically mean every Jira tenant is instantly lost, but it does mean a successful payload could abuse the victim admin’s browser to perform sensitive actions across the organization.

How the Jira Work Management bug works

Snapsec says the flaw appeared in the custom priority workflow, specifically the Icon URL property tied to a priority entry. During testing, the researchers inserted a script-breaking payload into that field and triggered stored XSS when the value rendered in the front end.

The report says the main weakness came from missing validation or encoding on the backend for that URL field. Because the payload persisted in Jira settings, anyone with sufficient access who later opened the affected page could trigger the script just by viewing it.

That makes the vulnerability more serious than a reflected XSS bug. Stored XSS lives inside the application until someone removes it, so the attacker does not need to trick the target into clicking a custom phishing link each time.

Vulnerability snapshot

Area	What researchers reported
Product	Jira Work Management
Bug type	Stored cross-site scripting
Injection point	Custom priority Icon URL
Minimum attacker role in demo	Product Admin
Trigger	Higher-privileged admin views affected settings page
Potential outcome	Organization-level compromise through the victim’s session

Why the Product Admin role matters

Snapsec says it looked for the lowest-privileged role that could still create or edit a custom priority and landed on Product Admin. According to the disclosure, that role did not need full access to every Atlassian product to make the malicious change.

That detail matters because many organizations separate product administration from top-level organization administration. A role that looks limited on paper can still become dangerous if it can write data into a page that more privileged admins later load.

Atlassian’s support documentation also confirms that editing custom priority icons belongs to an administrative workflow under Jira Settings > Issues > Priorities, which helps explain why a seemingly small configuration field could become a powerful attack surface.

How Snapsec says the takeover chain played out

In Snapsec’s proof of concept, the attacker used the stored XSS payload to run JavaScript when a Super Admin visited the modified priorities page. The report says that script then sent an automated invite request for an attacker-controlled account.

Once that invite reached the right permission level, the attacker could gain access across multiple Atlassian products tied to the same organization. Snapsec describes the end state as a full organization takeover because the newly added account could then view, create, modify, or delete projects and related resources.

That is the key point security teams should focus on. The XSS itself starts in Jira Work Management, but the real damage comes from what the victim admin’s session can do after the script executes.

Why this bug is high risk

• It stores the payload in a legitimate admin setting.
• It triggers on page view, not on a clicked link.
• It appears to need only a lower admin tier to plant the payload.
• It can target higher-privileged admins later.
• The browser session of the victim does the sensitive work.

What organizations should do now

If your environment lets multiple admin tiers manage Jira settings, review who can edit priorities and other globally rendered configuration fields. Snapsec’s report shows that access control alone does not guarantee safety if trusted admin inputs are not sanitized.

Teams should also audit custom priority entries and their icon URLs for anything unexpected. Since Atlassian’s documented workflow explicitly allows pasted URLs in that field, security teams should treat it as a place worth reviewing during incident response and hardening.

More broadly, SaaS platforms need fail-safe handling for all admin-controlled display fields. Any place where one user can store HTML-like or script-breaking input that another, more privileged user later renders deserves strict validation and output encoding.

FAQ