A Critical Zero-Day in Atlassian Jira Service Management Cloud: Password Reset Account Takeover
I want to start this post with a short dedication: may we keep Palestine and its people in our prayers. May peace and justice be restored soon.
always free Palestine🇵🇸🇵🇸
Introduction
Hello Folks, my name is Mo Salah. I’m a security researcher and bug bounty hunter with a passion for finding vulnerabilities in real-world applications. Over the years, I’ve tested many platforms and services, focusing mainly on web application security, access control flaws, and cloud-based environments.
In this blog, I’ll share one of my findings — a critical vulnerability I discovered in Atlassian Jira Service Management Cloud — and walk you through how I identified it, validated it, and reported it responsibly
What is Jira Service Management (JSM) Cloud?
Jira Service Management Cloud is an online tool created by Atlassian that helps companies manage customer support and internal requests. It’s like a digital helpdesk where employees or customers can report issues, ask for help, and track progress until the problem is solved.
Let’s start from the beginning…
While testing my favorite program(external program) in a bug bounty, I noticed that one of its subdomains was running on Jira Service Management Cloud. Since this platform is widely used by organizations to manage customer support requests, I decided to take a closer look and perform some security testing.
I began with common checks such as Broken Access Control, CSRF, and other typical web vulnerabilities, but I didn’t find anything impactful at first. Then, I turned my attention to the password reset functionality
The Reset Password Flow…
Normally, password reset flows are very straightforward:
- A user requests a password reset for their account (e.g.,free@Palestine.com).
- Jira Service Cloud sends a reset token to the user’s registered email inbox.
- The user clicks the link, enters a new password, and the process is complete
That’s how it should work. But in this case, something unusual happened when I tested the flow more deeply.
Exploitation
While testing this process, I used an interception proxy (Burp Suite) to inspect the HTTP request when submitting the new password. I noticed something : The request body contained an `email` parameter.
POST /reset-password
Host: <jira-portal>
Content-Type: application/json
{
"email": "free@Palestine.com",
"newPassword": "NewPassword123!"
}By replacing my own email with `victim@gmail.com`, the server accepted the request — and the victim’s password was updated to the one I provided.
After reproducing the bug on the external program I tested, I wanted to make sure it wasn’t just a configuration issue specific to their Jira Service Management setup. To exclude this possibility, I created an independent JSM Cloud instance using a free Atlassian subscription.
I set up a Jira Service Management project with the default options enabled — especially the portal only account registration setting. Then, I repeated the same steps, and the bug was still there.
Step To Reproduce
Created a Jira Service Management portal with default settings, including portal-only account registration.
1- Create accounts A and B on Jira Service Management Cloud
2- Go to reset password page and Request a password reset for account A.
3- Account A received a password reset link and clicked it.
4- Enter the new password, intercept the request with Burp, and change the email parameter to “B email”.
5- User B’s password has been changed.
6- Now log in with Account B using the new password.
Impact…
This vulnerability allowed:
1- Full Account Takeover — Any Jira Service Cloud account could be hijacked.
2- No User Interaction Required — Once an attacker had their own valid reset token, they could directly target any victim by changing the `email` field.
3- Widespread Effect— Because this flaw existed at the product level, every organization running Jira Service Management Cloud was affected.
In other words, it was a universal password reset vulnerability across JSM Cloud platform.
Finally, The company’s security team triaged the report, resolved the bug within 20 minutes, and rewarded me for the finding.
