What this checks: whether an Atlassian Jira host runs a version affected by unauth SSTI to RCE. Read-only: it fingerprints Atlassian Jira and reads the version, no exploitation.
3. Detection — reads the Atlassian Jira version from the version exposed at /login.jsp, compares to 7.6.14 / 7.13.5 / 8.0.3 / 8.1.2 / 8.2.3 (per branch; Jira before 4.4.0 is not affected). Flags vulnerable on an affected build. No exploitation.
1. Target List — paste your Atlassian Jira URLs here, one per line (e.g. https://host.example.com).
Overview
This workflow finds Atlassian Jira Server and Data Center and sorts each host by whether its version falls below the CVE-2019-11581 fixed floors. CVE-2019-11581 is server-side template injection in Jira that can lead to remote code execution. This check never sends a template and never hits a contact or SMTP form. Give it hostnames, IP addresses, or URLs you are authorised to test. The workflow GETs /login.jsp, fingerprints Jira from page markers, reads the version string, and compares it to the per-branch table in the graph. Builds older than 4.4.0 are treated as not affected. Every host comes back affected or not, so a fleet advisory becomes an evidenced list for exposure management. An affected row is a version signal only.
Run it on a schedule when Jira 7.x and 8.x fleets lag on patch windows. A node that stayed on 8.2.2 after neighbours moved is the reason the same fingerprint stays useful.
Pipeline
Read the target list. Hosts, URLs, or ranges, one per line, become the scope.
GET /login.jsp on each host and fingerprint Jira from page markers and version strings on that response.
Parse the version and compare it to the CVE-2019-11581 floors in the graph (7.6.14, 7.13.5, 8.0.3, 8.1.2, 8.2.3), treating builds below 4.4.0 as not affected.
Collect the per-host rows: product match, version, vulnerable flag, and any fetch error.
Emit the summary counts: hosts checked, product hits, vulnerable, and errors.
Inputs
Target scope. Hostnames, IP addresses, CIDR ranges, or URLs, one per line. Full URLs and host:port entries work too, since the workflow normalizes each into a bare host. Point it at scope you are authorised to test.
Outputs
results.jsonl. One row per host: URL, whether Jira was detected, the version read, the vulnerable flag, and detail text.
findings.jsonl. The same per-host verdict shaped for triage, with severity set from the vulnerable flag.
summary.json. Counts across the list: targets, product hits, vulnerable, and errors, plus the detection notes from the graph.
Integrations
HTTP. Unauthenticated GET of /login.jsp only. No contact form, no SMTP path, and no SSTI template.
Sample output
The records below are illustrative and do not come from a real run. They show one Jira host below a CVE-2019-11581 floor, one at or above its floor, and one host that is not the product.
Builds below the per-branch floors in the graph: 7.6.14, 7.13.5, 8.0.3, 8.1.2, and 8.2.3. Versions below 4.4.0 are not affected. The compare uses the version Jira itself served on /login.jsp.
Does an affected row mean SSTI ran?
No. The check only GETs /login.jsp and reads the version. It does not submit a template and it does not confirm RCE.
Is this check safe on production?
Yes. It is a read-only unauthenticated GET of the public login page. It does not send mail or change Jira state.
Does the check need credentials?
No. It fingerprints the public login page the way an external scanner would.
What is CVE-2019-11581?
Server-side template injection in Atlassian Jira Server and Data Center that can lead to remote code execution. This workflow maps hosts to that CVE by version exposure only.