Eight Atlassian Data Center and server products have an unauthenticated file-read flaw that reaches files inside the application web root. A known configuration filename can be enough to expose credentials. Atlassian’s CVE record rates CVE-2026-21589 critical at 9.3 under CVSS v4 and names Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye. Customer-managed instances need a product-specific update; Atlassian Cloud products are already patched, according to Rapid7’s October 7 response.
The sharpest reported consequence came from a Crowd installation connected to Jira. Rapid7 describes watchTowr Labs’ package-comparison testing: reading WEB-INF/classes/crowd.properties exposed application credentials, which the researchers then used, with network access to Crowd, to create a user and add it to jira-administrators. Crowd IP allowlisting can block that direct follow-on route. The file read itself is narrower than a whole-server browse: Atlassian says, “Exploitation requires prior knowledge of the target file’s exact name and path.” That is enough reason to check predictable configuration paths and the credentials they contain.
Web-resource handling exposes known files
Rapid7 attributes the technical analysis to watchTowr Labs, which compared vulnerable and patched Jira, Confluence and Bitbucket packages. In that analysis, a double-colon :: sequence becomes a path separator during web-resource request processing. Traversal components can then reach resource-loading code, and the application returns the requested file contents. NVD’s record carries CWE-552, files or directories accessible to external parties. The researchers’ testing stayed inside the Tomcat context and reached files across the application web root. A defender should scope searches to the exposed application files and the secrets stored there, while also tracing any subsequent use of those secrets.
The attacker needs to know the specific file path and filename; the flaw offers no directory listing. That constraint makes common configuration paths particularly valuable targets. In connected Crowd and Jira deployments, restrict reachability to Crowd while patching the file-read entry point.
Decoded request logs reveal attempts
Start with web access logs for affected Atlassian applications. Atlassian’s investigation guidance, relayed by Rapid7, is to URL-decode each request line up to twice and look for .. immediately adjacent to /, \ or ::. Double encoding and the double-colon separator make a literal search of raw paths less reliable. Atlassian also supplies this raw-log detection expression through the Rapid7 report:
(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*Treat a match as a request to investigate, then correlate the requested resource with access to protected configuration files and any ensuing authentication or administrator changes. Keep the raw and decoded request line together while triaging matches, and compare proxy records with the application’s own access logs to see which requests reached the application. For the Crowd-to-Jira case, review Crowd authentication and Jira administrative membership for a new account associated with a suspect file request. These log and account checks help distinguish an attempted read from an actual exposure and subsequent use.
Rapid7 says file-read proof-of-concept scripts are public and recommends an emergency patch cycle and access-log review.
Match fixes to each product branch
Atlassian’s CVE record and Rapid7 give these first fixed releases. Inventory each customer-managed deployment, including unsupported installations, then compare its installed build within its release branch. Atlassian treats earlier applicable versions as affected.
| Product | Fixed releases by branch |
|---|---|
| Bitbucket Data Center | 9.4.26, 10.2.8, 10.5.1 |
| Confluence Data Center | 9.2.26, 10.2.19 |
| Jira Service Management Data Center | 5.12.40, 10.3.26, 11.3.12 |
| Jira Software Data Center | 9.12.40, 10.3.26, 11.3.12 |
| Bamboo Data Center | 10.2.24, 12.1.12 |
| Crowd Data Center | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible | 4.9.15 |
| Fisheye | 4.9.15 |
Install the applicable fix or the latest available release for each product. If an update is delayed, remove the affected installation from internet reachability or restrict external access. Rapid7 also points to Atlassian’s product-specific WAF/proxy rule, a Tomcat RewriteValve mitigation for Confluence, Jira Service Management, Jira Software, Bamboo and Crowd, and a separate urlrewrite.xml rule for Bitbucket. Those interim rules are limited; schedule the actual upgrade rather than treating a rule match as a repaired installation. Cloud tenants have the vendor-applied patch and need no customer-side update for this CVE.
Verify releases and exposed secrets
For every affected customer-managed instance, record the installed product and branch, its reachable web entry points, and the first fixed build from the table. Apply the release, verify the running version, and repeat the decoded-request review against retained access logs from before the update. The version check confirms the repair on the installed service; historical requests still need investigation. If logs show access to WEB-INF/classes/crowd.properties or another sensitive configuration file, contain the affected system and rotate exposed credentials and secrets. For a connected Crowd and Jira deployment, also verify administrator membership and Crowd’s IP allowlist against the systems allowed to authenticate.
After the update, keep the incident review open for requests made while an older build was reachable. Correlate those requests with exposed file contents and subsequent credential use before restoring normal access.