What this checks: whether an Atlassian Confluence host runs a version affected by unauth Widget Connector SSTI -> path traversal + RCE. Read-only: it fingerprints Atlassian Confluence and reads the version, no exploitation.
3. Detection — reads the Atlassian Confluence version from the version exposed at /login.action, compares to 6.6.12 / 6.12.3 / 6.13.3 / 6.14.2 (per branch). Flags vulnerable on an affected build. No exploitation.
1. Target List — paste your Atlassian Confluence URLs here, one per line (e.g. https://host.example.com).
Overview
This workflow finds Atlassian Confluence Server and Data Center and sorts each host by whether its version falls below the CVE-2019-3396 fixed floors. CVE-2019-3396 is server-side template injection in the Widget Connector that can lead to remote code execution. This check never hits the Widget Connector and never sends a template. Give it hostnames, IP addresses, or URLs you are authorised to test. The workflow GETs /login.action, fingerprints Confluence from page markers, reads ajs-version-number, and compares that number to the per-branch table in the graph. Every host comes back affected or not, so a fleet advisory becomes an evidenced list for exposure management. There is no SSTI probe and no confirm step.
Run it on a schedule when older Confluence 6.x nodes linger. A forgotten staging wiki on 6.13.2 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.action on each host and fingerprint Confluence from page markers such as ajs-version-number and the powered-by footer.
Parse the version from ajs-version-number and compare it to the CVE-2019-3396 per-branch floors in the graph.
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 Confluence 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.action only. No Widget Connector request and no SSTI template.
Sample output
The records below are illustrative and do not come from a real run. They show one Confluence host below a CVE-2019-3396 floor, one at or above its branch floor, and one host that is not the product.
Builds below the per-branch floors in the graph: 6.6.12, 6.12.3, 6.13.3, and 6.14.2. A version picks the matching band, then compares to that band's floor. The compare uses the version Confluence itself served on /login.action.
Does an affected row mean SSTI ran?
No. The check only GETs /login.action and reads ajs-version-number. It does not call the Widget Connector and it does not confirm template injection or RCE.
Is this check safe on production?
Yes. It is a read-only unauthenticated GET of the public login page. It does not render a widget or evaluate a template.
Does the check need credentials?
No. It fingerprints the public login page the way an external scanner would.
What is CVE-2019-3396?
Server-side template injection in the Atlassian Confluence Widget Connector that can lead to remote code execution. This workflow maps hosts to that CVE by version exposure only.