Public Exploit Code Triggers Rapid Probing of Eight Atlassian Product Families

Security company Previdian observed attempts to exploit CVE-2026-21589 against its honeypot network within two hours of watchTowr publishing technical research and a public proof of concept.

The vulnerability permits unauthenticated access to known files inside the web root of affected Atlassian applications. It spans eight self-hosted product families, including Jira, Confluence, Bitbucket and Crowd.

The Hacker News reported 15 attempts from three IP addresses. BleepingComputer identified the same addresses but did not give an attempt total. This telemetry shows active probing of honeypots, not confirmed compromise of Atlassian customer systems.

BleepingComputer published its report on October 7, 2026, at 08:49 AM. It described Atlassian’s advisory as having been issued on “Monday,” without providing a calendar date. The reporting says watchTowr released its technical analysis after that advisory, but does not date the research publication to Monday.

Exact file knowledge is required, but authentication is not

CVE-2026-21589 is an arbitrary file-access vulnerability affecting these self-hosted products:

• Bitbucket Data Center
• Confluence Data Center
• Jira Service Management Data Center
• Jira Software Data Center
• Bamboo Data Center
• Crowd Data Center
• Crucible
• Fisheye

An attacker does not need an account. However, exploitation requires the exact name and location of the target file because the flaw does not provide directory listing or enumeration.

That constraint limits discovery through the vulnerability itself, but it does not prevent attackers from requesting predictable application files. The consequences depend on the files present in a particular configuration and whether they contain credentials, tokens, keys or other authentication material.

The Hacker News reported a CVSS score of 9.3. The supplied NVD information classifies the issue as CWE-552, although it does not include a CVSS vector.

Verified NVD data provides introduction points for four of the eight affected families:

• Bitbucket Data Center: introduced in version 4.6.0 and later
• Confluence Data Center: introduced in version 5.10.0 and later
• Crowd Data Center: introduced in version 2.11.0 and later
• Jira Software Data Center: introduced in version 7.1.0 and later

These entries are not a complete vulnerable-version matrix for every product or maintained branch. Administrators should use the fixed releases applicable to their deployments rather than infer coverage for the other four families.

Atlassian said affected Atlassian Cloud products had been patched. The available reporting does not name those Cloud products individually.

Resource-path conversion produces the traversal sequence

The technical analysis connects the flaw to a shared Atlassian web-resource library. According to the researchers’ account, the library translates double colons, ::, into forward slashes.

A crafted resource string can therefore become a traversal path during processing. For example:

..::..::..::..::WEB-INF::web.xml

may be transformed into:

../../../../WEB-INF/web.xml

watchTowr combined that behavior with Atlassian plugin-resource endpoints. The technique used the path and trailing slash associated with a plugin resource to request a different file inside the application.

The Hacker News reported this example targeting Jira’s WEB-INF/web.xml:

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: {{Jira-Hostname}}

The request does not include authentication. Its success nevertheless depends on the attacker knowing a valid target path and filename.

According to BleepingComputer’s account, watchTowr verified file reads in Jira, Confluence and Bitbucket. The researchers’ demonstrated technique did not traverse outside the Tomcat application context.

That boundary applies to the method watchTowr tested. The available evidence does not establish that every possible exploitation route has the same limitation.

Crowd-integrated deployments face a conditional escalation route

The vulnerability’s immediate effect is access to particular files under the application web root. A more serious outcome becomes possible when a readable file contains credentials that can be reused elsewhere.

Researchers highlighted WEB-INF/classes/crowd.properties in Crowd-integrated Jira environments. BleepingComputer reported that this file can hold plaintext application credentials for the Crowd identity system.

If those credentials are valid, Crowd is reachable and the affected application has sufficient permissions, an attacker could use the Crowd API to create a Jira administrator account. Administrative access to Crowd could also support creation of new users and changes to existing permissions.

Several prerequisites separate the file read from that escalation. Crowd must be accessible from a system controlled by the attacker, either directly or through another route. Researchers said an attacker might need to pivot through another machine or use an SSRF-like capability in Jira, Confluence or Bitbucket to contact Crowd.

Restricting Crowd to an allowed-IP list would make this path significantly harder, according to the research reported by BleepingComputer.

These are conditional attack chains demonstrated or described by researchers. They are not evidence that the escalation occurred during the honeypot activity or that a customer’s Jira administrator account was created.

Atlassian said it could not determine whether individual customer instances had been compromised.

Honeypot telemetry identifies three probing addresses

Previdian reported that its honeypots began receiving exploitation attempts within two hours of watchTowr releasing its research and public PoC.

The Hacker News put the volume at 15 attempts from three unique IP addresses. It said the addresses were located in Japan and the United States, without mapping each indicator to a specific country.

The reported addresses are:

• 38.60.157[.]86
• 146.70.187[.]234
• 159.26.119[.]225

BleepingComputer listed the same three indicators and said Previdian recommended blocking them, but its report did not specify the number of attempts.

Blocking these addresses can filter the sources already observed by Previdian. It does not address exploitation from other infrastructure and should not replace an update or traversal-pattern filtering.

Previdian’s Ryan Dewhurst expected activity to increase because technical details, a public PoC and a Nuclei scanning template were available across a broad set of products. That statement was a forecast, not confirmation of a later rise in exploitation.

Fixed releases and temporary controls

Atlassian urged administrators of self-hosted deployments to install the available security updates. The reported fixed releases are:

These are corrected versions, not complete vulnerable-version ranges. Operators should select an appropriate fixed release for the branch they maintain.

For systems that cannot be updated immediately, Atlassian’s reported temporary measures include removing affected instances from the public internet and applying a Web Application Firewall rule. BleepingComputer also reported that a WAF or proxy can block the specified traversal patterns across all eight affected product families, including Crucible and Fisheye.

Product-specific controls include:

• Tomcat’s RewriteValve for Confluence, Jira Service Management, Jira Software, Bamboo and Crowd
• A rule in urlrewrite.xml for Bitbucket

The reporting does not reproduce the exact WAF, proxy, RewriteValve or urlrewrite.xml rules. watchTowr also released a free scanner to assess whether an instance is vulnerable, but the scanner’s address was not included in the available material.

The durable response is to install a fixed version. Network restrictions and request filtering reduce exposure while that work is completed.