Previdian, a cybersecurity firm, posted three attacker IP addresses on its X account on October 7 after spotting scanning and exploitation attempts against its honeypot network. The addresses were 38.60.157[.]86, 146.70.187[.]234, and 159.26.119[.]225. The company's note came with a chart of attempts climbing and a blunt line about what to expect next: "Expect to see those bars getting taller over the next few days!"
The target was CVE-2026-21589, a file-read bug in eight Atlassian Data Center products that the vendor disclosed on October 5. Atlassian gave it a CVSSv4 score of 9.3. One day later, watchTowr Labs published technical analysis showing that a double-colon sequence, written as "::", can turn into a path separator during request handling and reach the code that loads web resources. The contents of files inside the application's web root then come back to whoever asks. No login required.
The stakes sit in what Atlassian's software holds. Jira Software, Bitbucket, Bamboo, Confluence, Crowd, Fisheye, Crucible, and Jira Service Management are the systems where engineering teams keep source code, build pipelines, project records, and identity configuration. A single readable properties file can hand an attacker the credentials that also open the CI/CD chain downstream. Exploitation was detected within about 24 hours of a public write-up, which tells you the window for "patch it next week" has already closed. More of our coverage of the day's vulnerability news.
The bug is a separator, not a clever exploit
watchTowr Labs built its analysis by comparing vulnerable and patched builds of Jira, Confluence, and Bitbucket. The team found that Atlassian's resource-loading path treats "::" as a directory boundary in certain conditions. An unauthenticated request that smuggles traversal components through that separator reaches the file reader, and the file comes back over HTTP.
The National Institute of Standards and Technology filed the weakness under CWE-552, files or directories accessible to external parties. Rapid7 published proof-of-concept tooling and told customers to patch outside their normal cycle and to dig through access logs for attempt signatures.
There are limits to the bug. The attacker has to know the exact filename and path, and there is no directory listing, so no browsing of the web root. That sounds like a real defense until you look at how well known those paths are. Sehgal, chief executive officer at BreachLock, put the problem plainly: the requirement for an exact path is less protective than it reads, because those paths are written down in open source code and in CVE write-ups going back years.
Why a file read becomes admin access
In an Atlassian Crowd deployment with Jira configured, watchTowr's testing showed the request could pull WEB-INF/classes/crowd.properties straight out of the web root. That file carries application credentials. From a machine with network access to Crowd, those credentials were enough to create a new user and drop it into the jira-administrators group. Crowd's IP allowlisting blocks that route, but only where administrators have turned it on.
That chain matters for scoping a response. A leaked configuration file is not only an information disclosure event. It can be the first step into source repositories, artifact stores, and code signing.
"Teams running affected versions should treat this as high priority because the follow-on access can compound quickly, where a configuration file leak can expose credentials used across downstream CI/CD systems and connected identity infrastructure," Sehgal said.
Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs, said the same thing from the other side. Attackers need the exact path and cannot list directories, he said, which is limited comfort when the request asks for no credentials at all.
The patch list, and the log check that comes after
Atlassian's October 5 advisory covers every version before the listed fixed release, including builds already outside their support window. Fixed versions are Bitbucket Data Center 9.4.26, 10.2.8, or 10.5.1, Confluence Data Center 9.2.26 or 10.2.19, Jira Service Management Data Center 5.12.40, 10.3.26, or 11.3.12, Jira Software Data Center 9.12.40, 10.3.26, or 11.3.12, Bamboo Data Center 10.2.24 or 12.1.12, Crowd Data Center 6.3.7, 7.0.3, 7.1.7, or 7.2.4, and Crucible and Fisheye 4.9.15.
Teams that cannot patch today have two temporary options. One is to pull the instance off the public internet or block external access. The other is a filtering rule: a WAF or reverse-proxy rule for all eight products, a Tomcat RewriteValve configuration for Confluence, Jira Service Management, Jira Software, Bamboo, and Crowd, and a urlrewrite.xml rule for Bitbucket that has to go on every cluster node, mirror, and mirror farm node. Those controls buy time, and Aaron Beardslee, manager of threat research at Securonix, said so directly. "They do not replace patching."
Patching is not the end of the work. Rapid7 recommends hunting for signs of compromise even after the fix lands. Atlassian's guidance is to URL-decode each access-log line up to twice, then look for ".." sitting next to "/", a backslash, or "::". A vendor-supplied regex does the same thing against raw logs. Horizon3 released a NodeZero test on October 6 that safely checks whether a given instance was reachable.
One clarification that has gotten lost in reposts: Atlassian says its investigation found no evidence of exploitation in its cloud products, and cloud customers need to do nothing. Beardslee read that carefully. "It does not make the same claim for customer-managed instances, and it says it cannot confirm whether any individual customer systems were affected," he said. Self-hosted is where the risk is, and self-hosted is where the evidence is missing.
It is not the only door open this week
October has been crowded for teams running internet-facing infrastructure. Cisco disclosed CVE-2026-76504, an API authentication bypass in Catalyst SD-WAN Manager scored 9.8 on CVSS v3.1, and the Cyber Security Agency of Singapore published an alert on October 6 saying the flaw is being actively exploited. A crafted HTTP request with mishandled URI encoding gets an attacker into the API with admin privileges. Affected builds include everything before 20.9.10.1, 20.12 through before 20.12.8.2, 20.15 through before 20.15.6.1, 20.18 through before 20.18.4.1, 26.1 through before 26.1.2.1, and 26.2.
The pattern across both bugs is the one that keeps showing up: pre-authentication flaws in systems that sit at the edge of a company's network, with working exploitation code public before most patch cycles finish. CISA's known exploited vulnerabilities catalog has carried entries for the Cisco flaw since early October, and a Nuclei template for CVE-2026-21589 is already public, which turns the Previdian honeypot hits into something any script kiddie can reproduce.
For administrators running self-hosted Atlassian, the next move is narrow. Check the version, upgrade to a fixed release, and if that takes a week rather than an hour, block external access to the instance in the meantime. Then run the log search, because a clean patch on a box someone already read credentials from is only half the job. It's not clear the three IPs Previdian posted are the whole picture, and the honeypot data only goes so far.