Short summary

This blogpost presents a tool that identifies the version of Atlassian Jira or Confluence application and maps the identified version to a local CVE database. The detection is primarily based on the presence of JavaScript files and SHA256 hashes. The tool first tries to get the version from application pages (if available); if it fails, it will try to get the version by matching files and file hashes. It also supports adding new versions and updating the CVE database for future detection and vulnerability mapping.

• The script attempts to read the version directly from web pages/resources exposed by the application (if available).
• If no version is found, the tool scans /includes/ files (JS) , compares which files exist versus the database for known versions, and narrows candidate versions.
• For files that differ between candidate versions the script get them and computes SHA256 hashes to identify the exact version (or the narrowest range possible).
• A local cve_database.json maps product → CVE → version ranges, allowing fast correlation and alerting.
• New versions and CVEs can be added to the database to improve future detection.

Why this approach?

Many Atlassian web applications have static assets (especially JS) whose filenames and contents change predictably between releases. By maintaining a small database of which JS files (and their SHA256 hashes) are in each product version, we can:

• Quickly identify which version is exposed.
• Automatically correlate the detected version with known CVEs.

This approach is not intrusive, as it only sends simple HTTP requests against publicly accessible resources.

How it works — step by step

1. Quick page-based detection (fast path): The script first tries a few application pages that often include version numbers: examples in the code are paths like /, /login.action, /about/about-page-content.vm. A regex looks for patterns like Confluence X.Y.Z or HTML elements/meta tags with version content (e.g. name="ajs-version-number" or inputs named JiraVersion). If a version is found here, it’s returned immediately.
2. File-presence scan (fallback): If page-based discovery fails, the tool enumerates a local JSON database (files\_per\_version\_\*.json) that maps known versions → list of JS paths. It sends HEAD requests to the target BASE_URL/includes/ in order to determine which files exist and builds match ratios for all known versions.
3. Detect modified files across candidate versions: For candidate versions that have some file sets in common, the script determines which files contain differing SHA256 values between those versions. Only the modified files are downloaded (with curl) and hashed locally (with sha256sum) to prevent unnecessary downloads.
4. Hash-based filtering: The calculated hashes are compared with the expected hashes in files_per_version_*_hash.json to narrow down the candidates to an exact version or the tightest possible version range.
5. CVE correlation and database updates: The script loads a local files/cve_database.json mapping CVEs to version ranges. New CVEs are also added directly through the tool. Once the version(s) are identified, the tool returns CVE IDs whose version ranges cover the identified version(s).

Usage (examples)

This will:

• Download the archive, extract it to a temp dir.
• Attempt to find the includes/ folder inside the archive and collect .js files.
• Compute SHA256 hashes and update files/files_per_version_jira.json and files/files_per_version_jira_hash.json.
• Future detection will automatically include this new version.

This modifies cve_database.json so that future detections will consider this CVE.

Limitations

• If the system cannot identify the exact file version, it will return the closest possible (approximate) match.
• Maintain a current file database (versions and hashes) to increase the detection accuracy.
• Maintain the CVE database consistently updated to provide accurate vulnerability mapping.

The source code of the project is available on Github