What this checks: whether an Atlassian Confluence host runs a version affected by unauth-detectable path traversal in downloadallattachments (auth required to exploit). 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.13 / 6.12.4 / 6.13.4 / 6.14.3 / 6.15.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-3398 fixed floors. CVE-2019-3398 is path traversal in the downloadallattachments action that can expose files on vulnerable builds. This check never hits that action and never reads an attachment. Give it hostnames, IP addresses, or URLs you are authorised to test. The workflow GETs /login.action, fingerprints the product from Confluence markers on that page, 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 authenticated exploit and no confirm step.
Run it on a schedule when wiki hosts turn over. A restored 6.x backup that lands below its branch floor 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, ajs-build-number, and Confluence powered-by strings.
Parse the version from ajs-version-number and compare it to the CVE-2019-3398 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 downloadallattachments request and no file read.
Sample output
The records below are illustrative and do not come from a real run. They show one Confluence host below a CVE-2019-3398 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.13, 6.12.4, 6.13.4, 6.14.3, and 6.15.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 path traversal worked?
No. The check only GETs /login.action and reads ajs-version-number. It does not call downloadallattachments and it does not read a file.
Is this check safe on production?
Yes. It is a read-only unauthenticated GET of the public login page. It does not log in or traverse paths.
Does the check need credentials?
No. It fingerprints the public login page the way an external scanner would. The underlying CVE may need auth to exploit; this workflow does not.
What is CVE-2019-3398?
Path traversal in Atlassian Confluence Server and Data Center through the downloadallattachments action. This workflow maps hosts to that CVE by version exposure only.