Jiraffe 🦒

Jiraffe 🦒 - One stop place for Jira security reconnaissance and exploitation in your proximity

Installation    |    Usage    |    Demo    |    Documentation

Jiraffe is a modern Jira security reconnaissance & exploitation framework for identifying misconfigurations, exposed APIs, and vulnerable components in Atlassian Jira deployments.

Built for security professionals who care about correctness, signal quality, and clean architecture.

Features

Jiraffe is a semi-automatic security assessment framework designed for real-world Jira deployments.

Highlights

• Modular recon & exploit framework
• Passive reconnaissance modules (unauthenticated access checks, information disclosure, and misconfiguration detection)
• CVE validation with safe defaults and compatibility gating
• Interactive & automatic execution mode with AWS SSRF helpers (metadata, IAM, custom targets)
• Jira version & deployment detection
• Cloud vs Server/DC awareness to avoid invalid or misleading checks
• Structured JSON output for scripting and CI pipelines

Jiraffe follows a recon-first, exploit-second model with strict separation between discovery and exploitation, keeping assessments accurate and controlled.

A modular design and low-noise defaults ensure extensibility without automatic shell execution or intrusive behavior.

This makes Jiraffe suitable for:

• Bug bounty reconnaissance
• Internal security assessments
• Red team tooling
• Responsible vulnerability validation

Installation

Use pip to install Jiraffe. This is the recommended way of running Jiraffe.

$ pip install jiraffe

or, installing from the source by running

# clone the repo
$ git clone https://github.com/0x48piraj/jiraffe.git

# change the working directory to jiraffe
$ cd jiraffe

# install the jiraffe python package
$ python3 setup.py install --user
# or, the modern way
$ python3 -m pip install .

Usage

$ python3 -m jiraffe --help

usage: jiraffe [-h] [-t https://jira.company.com]


                                                                           /)/)
                                                                          ( ..\
      ___  __      _______        __       _______   _______   _______    /'-._)
     |   ||  \    /       \      /  \     /       | /       | /       |  /#/ v2.2.0
     ||  |||  |  |:        |    /    \   (: ______)(: ______)(: ______) /#/  @03C0
     |:  ||:  |  |_____/   )   /' /\  \   \/    |   \/    |   \/    |
  ___|  / |.  |   //      /   //  __'  \  // ___)   // ___)   // ___)_
 /  :|_/ )/\  |\ |:  __   \  /   /  \\  \(:  (     (:  (     (:       |
(_______/(__\_|_)|__|  \___)(___/    \___)\__/      \__/      \_______)


optional arguments:
  -h, --help            show this help message and exit
  -t https://jira.company.com, --target https://jira.company.com
                        Target Jira instance URL
  -a, --auto            Automatic mode
  --check-only, --dry-run
                        Only check for vulnerabilities, do not run exploits
  --list-exploits
  --cmd CMD             Command for CVE-2019-11581
  --ssrf SSRF           SSRF target URL
  --user-agent USER_AGENT
                        Custom User-Agent header
  --severity {LOW,MEDIUM,HIGH,CRITICAL,INFO}
                        Run only exploits of this severity
  --json                Output results in JSON format (for automation / scripting)
  --insecure            Disable TLS certificate verification (allow self-signed HTTPS)
  -v, --verbose         Enable verbose output (debug information)

$ python3 -m jiraffe -t https://jira.example.com
$ python3 -m jiraffe -t https://jira.example.com --auto
$ python3 -m jiraffe --list-exploits

Documentation

Detailed documentation is available over the wiki, including:

• Architecture & Execution Flow
• Recon Module Development
• Exploit Module Lifecycle
• Severity Handling & Filtering
• Machine-Readable Output & Automation
• Reporting & Usage
• Supported CVEs & Validation
• Threat Model

Recon modules

Module	Severity	Summary
Jira Dev Mode Enabled	LOW	Detects whether Jira development mode is enabled, which may expose debug functionality
Query Component Field Disclosure	LOW	Identifies exposed Query Component fields accessible without authentication
Service Desk Signup Enabled	MEDIUM	Checks for publicly accessible Service Desk signup that may allow unauthorized account creation
Unauthenticated Admin Menu	INFO	Detects presence of the admin menu without authentication
Unauthenticated Dashboards	INFO	Enumerates dashboards accessible without authentication
Unauthenticated Gadget Configuration	LOW	Identifies exposed gadget configuration endpoints
Unauthenticated Group Picker	INFO	Checks for unauthenticated access to group picker functionality
Unauthenticated Popular Filters	INFO	Enumerates popular filters accessible without authentication
Unauthenticated Project Categories	LOW	Identifies exposed project categories via unauthenticated access
Unauthenticated Projects API	LOW	Enumerates projects using the unauthenticated Projects API
Unauthenticated Resolutions API	INFO	Detects unauthenticated access to issue resolutions
Unauthenticated Screens API	LOW	Identifies exposed Screens API endpoints
Unauthenticated User Picker	INFO	Checks for unauthenticated access to user picker functionality
User Registration Enabled	MEDIUM	Detects whether unauthenticated user self‑registration is enabled

Supported vulnerabilities

CVE	Severity	Affected	Summary	References
CVE-2017-9506	HIGH	< 7.3.5	OAuth IconUriServlet SSRF leading to internal network access and XSS	NVD · Atlassian
CVE-2018-20824	HIGH	-	Wallboard dashboard XSS	NVD
CVE-2018-5230	HIGH	-	Reflected XSS via Velocity template (.vm)	NVD
CVE-2019-11581	CRITICAL	< 7.6.14	Velocity template injection leading to remote code execution (RCE)	NVD · Atlassian
CVE-2019-3396	CRITICAL	-	Tinymce macro read-only path traversal	NVD
CVE-2019-3402	HIGH	-	Labels gadget XSS	NVD
CVE-2019-3403	LOW	-	Unauthenticated REST user enumeration	NVD
CVE-2019-8442	LOW	-	Jira Maven POM.xml disclosure	NVD
CVE-2019-8443	LOW	-	Jira Maven POM.xml disclosure via alternate path	NVD
CVE-2019-8449	LOW	2.1 - 8.3.4	Unauthenticated username enumeration via GroupUserPicker API	NVD · Atlassian
CVE-2019-8451	HIGH	>=7.6.0,<7.13.9 and >=8.0.0,<8.4.0	Pre-authenticated SSRF via gadgets makeRequest	NVD · Atlassian
CVE-2020-14178	LOW	-	Unauthenticated project existence disclosure	NVD
CVE-2020-14179	LOW	-	QueryComponent disclosure via QueryComponent!Default.jspa resource	NVD
CVE-2020-14181	LOW	-	User hover disclosure via ViewUserHover.jspa resource	NVD
CVE-2020-36287	LOW	-	Gadget preferences brute-force disclosure	NVD
CVE-2020-36289	MEDIUM	-	QueryComponentRendererValue information disclosure	NVD

CVE-2019-11581: Server-side Template Injection (RCE)

POC

Component(s)

• ContactAdministrators action
• SendBulkMail action
• Velocity template rendering pipeline

Vulnerability Class

• Server-Side Template Injection (SSTI)

Impact

• Remote Code Execution (RCE)

Attack Surface

• Unauthenticated (when Contact Administrators form is enabled)
• Authenticated (JIRA Administrators role required if form is disabled)

Exploitation Preconditions
At least one of the following must be true:

• An SMTP server is configured and the Contact Administrators form is enabled
• An SMTP server is configured and the attacker has JIRA Administrators privileges

Root Cause

• Unsafe evaluation of user-controlled input within Velocity templates
• Insufficient input sanitization prior to template execution

Affected Versions

• Jira Server / Data Center 4.4.0 ≤ version < 7.6.14
• Jira Server / Data Center 7.7.0 ≤ version < 7.13.5
• Jira Server / Data Center 8.0.0 ≤ version < 8.0.3
• Jira Server / Data Center 8.1.0 ≤ version < 8.1.2
• Jira Server / Data Center 8.2.0 ≤ version < 8.2.3

Fixed Versions

• 7.6.14 (LTS)
• 7.13.5 (LTS)
• 8.0.3
• 8.1.2
• 8.2.3
• 8.3.0+

Severity

• Critical (CVSS High)

Notes
Successful exploitation allows arbitrary code execution on the Jira application host, resulting in full system compromise.

Reference

• Atlassian Advisory: JRASERVER-69532

Majority of the bugs stated above poses Server-Side Request Forgery (SSRF) vulnerability, where attacker can abuse a specific functionality on the server to read or update internal resources. The attacker can supply or a modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.

Currently, some of the common Amazon AWS credentials leak attacks are present with an additional Custom Payload Option for sending crafted payloads for any cloud platform (Amazon AWS, Google Cloud, etc.). For sending custom payloads, take help from PayloadsAllTheThings — SSRF URL for Cloud Instances. Feel free to implement more post exploitation modules for vendor specifc deployments. For looking under the hood, read wiki.

Reconnaissance modules

In addition to exploits, Jiraffe includes a modular reconnaissance (auxiliary) framework for structured information gathering and weak-signal detection.

Recon modules are non-exploit checks designed to identify conditions that may enable or influence exploitation, without actively attacking the target.

What recon modules cover

Recon modules typically fall into one of the following categories:

• Unauthenticated access checks:
  Endpoints or resources accessible without authentication.

• Information disclosure:
  Version leaks, configuration exposure, banners, metadata, or other passive signals.

• Misconfiguration / weak settings:
  Insecure defaults, exposed services, or deployment weaknesses.

Architecture

Recon modules live under:

jiraffe/recons/

Each module is implemented as a subclass of ReconModule, providing a consistent interface and lifecycle similar to exploit modules, while remaining strictly separated from exploitation logic.

This auxiliary-style design allows reconnaissance to scale independently, reusing the same modular discovery model as exploits without coupling reconnaissance to exploitation.

Contributing recon modules

Adding a new recon module is simple:

1. Create a new Python file under jiraffe/recons/
2. Implement a subclass of ReconModule
3. Define metadata (name, severity, description)
4. Implement the run() method

No changes to core logic or registries are required — modules are discovered dynamically at runtime.

This makes it easy to contribute new reconnaissance checks without impacting existing exploits or execution flow.

Demonstration

Below is a typical Jiraffe workflow showing target detection, reconnaissance, and controlled exploit validation.

Tests

The tests are next to the package i.e. tests are not part of the package, only of the repository. The reason is simply to keep the package small.

Running the unit tests

$ python3 -m unittest --verbose # Python 3 and up

Legalese

Jiraffe is intended for authorized security testing and defensive research. Only assess systems you own or have explicit permission to test. The project follows responsible disclosure principles and aims to improve the overall security posture of Jira deployments.

This project is a personal development. Please respect it's philosophy and don't use it for evil purposes. By using Jiraffe, you agree to the MIT license included in the repository. For more details at The MIT License — OpenSource.

Using Jiraffe for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

Licensing

This project is licensed under the MIT license.