watchTowr published its technical research and a working proof of concept for CVE-2026-21589, the unauthenticated file-read flaw in eight Atlassian Data Center products. Previdian's honeypot network recorded exploitation attempts within two hours.

The flaw scores 9.3, needs no authentication, and reaches files in the application's web root with a single request. All versions of Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye Data Center are affected.

Two hours

That is the number to carry out of this.

Not two days. Not the next maintenance window. Two hours is shorter than a change-approval process, shorter than a working morning, and shorter than the night that was in progress for most of the people who needed to act.

Set it beside the figure from Microsoft's report: enterprises take 30 to 60 days to remediate critical externally facing vulnerabilities. Those two numbers describe the same event from opposite ends. The gap is not a few days of risk. It is weeks during which the exploit is public, automated and already running against anything reachable.

Nothing about this is specific to Atlassian. It is what publishing a proof of concept for an internet-facing enterprise product now means, and the planning assumption has to move with it: the moment detail becomes public, exposure is immediate rather than imminent.

What we said two days ago

Yesterday we wrote about this advisory and argued with its most-quoted qualifier — that an attacker must know the exact name and path of the file, and cannot enumerate directories.

For bespoke software that is a real constraint. For an off-the-shelf product it is not, because anyone can install a copy and look, and the vendor documents the layout for administrators who need it.

The proof of concept has now removed even that small effort. The paths are in the exploit. The qualifier was never protecting anybody, and it has stopped being even theoretically relevant.

A read primitive is as serious as what is readable

File read tends to be filed below code execution — information disclosure, a tier down, a lower priority on the board.

The ranking is a habit rather than an analysis. What is in the web root of a Confluence or Bitbucket server is configuration: the credentials the application uses to reach its database, integration tokens, keys. Reporting on the exploitation makes the point directly — what comes out is authentication material, and authentication material is how the next step happens.

So the correct way to read a 9.3 file-read on this class of product is as an unauthenticated credential disclosure with extra steps. The attacker does not need code execution on the Confluence box if the Confluence box hands over the keys to everything it talks to.

What to do

  • Patch now if you have not. Every version of all eight products is affected, so there is no older release to sit on.
  • Assume reading, not just scanning. If an instance was internet-facing between 5 October and your patch, treat the contents of its web root as disclosed.
  • Rotate on that assumption. Database credentials, integration tokens and any keys in the application configuration, before you finish reading the logs.
  • Then read the logs. Requests for specific files in the web root, from addresses with no other history, in the window since the advisory.
  • Find the instances nobody owns. Crucible and Fisheye are on this list, and they are exactly the sort of thing that has been running untouched since a migration that finished years ago.

What is not established

  • How many organisations have actually been compromised, as opposed to probed. Honeypot traffic measures attempts.
  • Who is behind the attempts, which nothing published attributes.
  • Whether any specific data has been taken.
  • Whether exploitation predates the public proof of concept, which the honeypot timing cannot answer either way.