Atlassian October 2026 Bulletin: 75 Bundled CVEs and the Patch Lag

On 20 October 2026 Atlassian published its monthly Data Center and Server security bulletin: 176 entries covering about 75 unique third-party CVEs, six of them critical, in bundled Tomcat, Netty, Bouncy Castle and Apache MINA SSHD. No exploitation is reported. Self-managed customers should move to the fixed releases, such as Confluence 10.2.19 or Jira 11.3.12.

This is a vulnerability disclosure, not a breach. Neither the bulletin nor the SecurityWeek write-up reports attacks using any of these flaws, none of the critical CVEs is in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the 23 October catalog release, and the CISA coordinator assessment attached to each critical CVE record says "Exploitation: none". Atlassian Cloud is not part of the bulletin, which covers Data Center and Server products only.

The bulletin itself is routine. What makes it worth a long read is the calendar. Most of the upstream fixes it delivers were public in August. The Tomcat CVEs went public on 25 August, the Bouncy Castle CVE on 3 August and the Netty CVE on 19 August. Customers running self-managed Atlassian products receive those fixes when they install Atlassian's release, roughly 8 to 11 weeks after the upstream CVE went public, and they cannot swap the bundled JAR themselves without leaving a supported configuration. That gap is the part of software supply chain risk most teams never see in their own scanners, so this post measures it, explains why it exists, and shows what you can do inside it.

What happened

Atlassian's bulletin page, dated 20 October 2026, lists 162 high severity and 14 critical severity third-party vulnerabilities, fixed in product releases from the previous month. Every entry is a third-party dependency, not Atlassian's own code. The 14 critical entries collapse to six unique CVEs, because the same library flaw is listed once per affected product. SecurityWeek, writing on 23 October, counted 75 unique CVEs across all 176 entries. That figure is SecurityWeek's own count; the bulletin does not print a unique total, so this post says "176 entries covering about 75 unique CVEs".

The affected products are Bamboo, Bitbucket, Confluence, Crowd, Fisheye and Crucible, Jira Software and Jira Service Management, all in their Data Center and Server editions.

Every critical entry carries the same note from Atlassian: "Atlassian's application of this dependency presents a lower, non-critical assessed risk." The bulletin's introduction explains the policy behind that line. CVEs that land in the monthly bulletin have been assessed as non-critical for Atlassian customers, and Atlassian issues separate Critical Security Advisories, outside the monthly cycle, for issues that pose an immediate critical risk based on how its products use the component. The bulletin does not publish the reasoning for any individual CVE.

The six critical CVEs

A seventh Tomcat CVE from the same August release, CVE-2026-65905 (a limited replay with DIGEST authentication), carries a 9.8 score in its CVE record. SecurityWeek reports that Atlassian's vulnerability disclosure portal lists it among the 20 October disclosures for Data Center and Crowd, but it does not appear in the bulletin. We could not confirm the portal entry ourselves, because the portal loads its list dynamically.

Timeline

All CVE publication times below are the datePublished values in the CVE records at cve.org, in UTC. Release dates come from the upstream project pages named in the Source column.

The lag, measured

This is the number to take to your next risk review. The table counts days from two upstream moments to the Atlassian bulletin on 20 October: the day the fixed library release was available, and the day the CVE record was published.

Two points stand out. First, for the Tomcat, Netty and Bouncy Castle entries, the gap between public CVE and Atlassian fix sits between 8 and 11 weeks. Second, the gap is not uniform. The MINA SSHD issue reached Crucible in about three weeks, which suggests the delay depends on release trains and testing per product rather than on a fixed queue.

Measured from the fixed library release, the gap is longer still, because upstream projects often ship a fix days or weeks before the CVE record goes live. Bouncy Castle 1.85 was on Maven Central about three weeks before its CVE was published. A team that builds its own Java services and upgrades on release would have been running the fix in July. A team that consumes the same library inside a vendor product waited until late October.

The Maven Central dates are the Last-Modified timestamps on the published POM files. They mark when the artifact was available, which is close to, but not always identical to, an announced release date.

Why the lag exists, and why it is not negligence

None of this means Atlassian was slow by its own rules. Atlassian's published security bug fix policy sets an extended timeline for Data Center products: critical, high and medium issues within 90 days of verification. An 8 to 11 week gap fits inside that window. The monthly bulletin is the delivery mechanism, and an LTS release has to be built, regression tested across a large plugin ecosystem, and published for several supported lines at once.

There is also a real technical reason a library CVE can matter less inside a product. The Netty bug, for example, only becomes a mutual TLS bypass when three specific configuration conditions line up. If a product never configures per-SNI client certificate contexts, the bug is a robustness problem, not an authentication bypass. Atlassian's "lower, non-critical assessed risk" note is a claim of exactly that kind. What it does not give you is the reasoning, so you cannot check it against your own deployment.

The structural issue is ownership. In your own code, you own the dependency, the upgrade and the test. In a vendor product, the vendor owns all three, and replacing a bundled JAR yourself is unsupported and can break the product. For roughly two months, your scanners can tell you the old library is there, and the only supported action is to wait for the vendor release.

Who is affected

Anyone running a self-managed Atlassian product on a version below the fixed releases. Cloud customers are not covered by this bulletin.

Fixed versions per product (from the Atlassian bulletin)

The bulletin notes that the fixed versions are current as of 20 October and points to each product's release notes for later builds. Any later release on the same line should also carry the fixes, but check the release notes before you assume it.

Affected version ranges (from the Atlassian bulletin)

The lines with no fix in this bulletin

Read the affected ranges against the fixed versions and a few lines fall through the gap:

• Confluence 8.5.x and 7.19.x LTS are listed as affected, and no 8.5 or 7.19 build is listed as fixed. The supported path is an upgrade to 9.2.26, 10.2.19 or 11.0.0.
• Jira Software 9.12.x and Jira Service Management 5.12.x and 5.4.x are listed as affected, with fixes only on 10.3.26 and 11.3.12.
• Server editions reached end of support on 15 February 2024, according to Atlassian's Server end of support FAQ. Almost every fixed version in this bulletin is marked Data Center only. If you still run a Server license on these products, the bulletin effectively tells you there is no Server build to install.
• Fisheye and Crucible follow a separate timeline. Atlassian's FAQ says their support and maintenance end on 15 May 2028, which is consistent with Crucible 4.9.15 not being labelled Data Center only.

How the critical issues work

These are plain language summaries of the upstream advisories, for defenders deciding what is reachable. They describe conditions, not attack steps.

CVE-2026-65637: Tomcat HTTP/2 and strict SNI

Tomcat can check that the host name a client asked for during the TLS handshake (SNI) matches the host the HTTP request is addressed to. The fix for an earlier CVE, CVE-2026-32990, added that check. Apache found the fix incomplete: an HTTP/2 request that omits the authority field could slip past it. Only Tomcat 11.0.20 to 11.0.24, 10.1.53 to 10.1.57 and 9.0.115 to 9.0.120 are affected, the releases that carried the earlier fix. Apache rates it Moderate. The 9.8 in the bulletin comes from the CISA scoring attached to the CVE record. In practice this needs TLS, HTTP/2 enabled on the connector, and a deployment that relies on SNI and host matching to separate tenants or virtual hosts.

CVE-2026-65182: Tomcat security constraint ordering

Web applications declare security constraints by URL pattern. If a constraint for a longer path appears before a more restrictive constraint for a shorter sub-path, Tomcat's matching could apply the wrong one and let a request through that should have been blocked. Apache rates it Important, and it affects every supported line up to 11.0.24, 10.1.57 and 9.0.120, plus end of life 8.5 and 7.0. Whether it matters depends on how the product's own web.xml declares its constraints, which is exactly the kind of detail behind Atlassian's lower risk assessment.

CVE-2026-68525: Tomcat FORM authentication redirect

When a resource is protected so that a user may POST to it but not GET it, the redirect that Tomcat performs after a successful FORM login could carry the user past the method restriction. Apache rates it Low. The CVE record carries a 9.1 score from CISA's assessment, which is where the bulletin's number comes from. It only matters to applications that use container FORM authentication together with method specific constraints.

CVE-2026-58062: Bouncy Castle stapled OCSP

When a TLS server staples an OCSP response, the client is supposed to check that the response is about the certificate it is validating. Bouncy Castle's ProvOcspRevocationChecker verified the signature on a stapled response but did not confirm that any SingleResponse inside it matched the certificate's serial number and issuer hashes. If nothing matched, the checker returned without error, so a revoked certificate could pass revocation checking. The network fetch path already did this check; the stapled path did not. This matters to Java code that uses Bouncy Castle for PKIX revocation checking with stapled responses, for example an outbound TLS client inside a product that talks to an external service. Our earlier post on the Bouncy Castle OCSP stapling flaw covers it in depth.

CVE-2026-75595: Netty SNI routing and mutual TLS

Netty's SslClientHelloHandler reads the TLS ClientHello to choose a per host SslContext. A ClientHello whose handshake header is split across TLS records triggered an exception, and the handler then selected the default context. The advisory is clear that this is only an authentication bypass when three things are true together: mutual TLS is enforced solely by the per-SNI context (clientAuth=REQUIRE), the default context is permissive (clientAuth=NONE or OPTIONAL), and the application does no certificate check of its own. Netty's advisory rates it High. Our Netty SNI mutual TLS bypass explainer goes further.

The bulletin labels this entry differently per product: Remote Code Execution for Jira Software and Jira Service Management, and a broken authentication class for Confluence. The upstream advisory describes a routing and mutual TLS bypass, not code execution. Atlassian does not explain the RCE label.

CVE-2026-77185: MINA SSHD asynchronous authentication

Apache MINA SSHD offers an "asynchronous authentication" mechanism to developers who build SSH servers on the library. The implementation could skip the signature check in public key or host based authentication, or return the wrong result. A server has to contain explicit code that uses this feature; Apache calls it a "presumed rare" way to implement an SSH server. Versions 2.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5 are affected. The fixed releases also refuse asynchronous authentication with public key and host based schemes outright, closing the session and logging the attempt. The bulletin lists the component only for Crucible and does not say how Crucible uses it.

Technical details

All values below come from the documents named in each heading. No indicators of compromise exist for this bulletin, because no exploitation has been reported.

Upstream affected and fixed versions per critical CVE

Note the Tomcat 10.1 detail. Apache's 10.x security page says the fixes were made in 10.1.58, but the release vote for that candidate did not pass, so 10.1.59 (20 August) is the first 10.1 release that contains them. If you track Tomcat versions directly, 10.1.58 does not exist as a release.

Where the 9.x scores come from

The scores in the bulletin match the scores in the CVE records, but those records hold more than one opinion. This matters because the bulletin's critical label rests on them.

Three of the four Tomcat issues are rated Moderate or Low by the Apache Tomcat security team and critical by the generic CVSS assessment added later. Neither view is wrong; the generic score assumes the worst reachable configuration, and the project rating reflects how often that configuration exists. For a vendor product, Atlassian adds a third view, "lower, non-critical assessed risk", without numbers.

Every critical CVE record also carries a CISA coordinator SSVC assessment, timestamped within a day of publication, that reads Exploitation: none. All but the Netty CVE are marked Automatable: yes; Netty is Automatable: no.

Weakness classes

Notable high severity entries (from the bulletin)

The rest of the high entries are in the 7.1 to 7.5 range and include Spring (spring-webmvc, spring-expression, spring-web in Confluence), Apache Struts (struts2-core in Crowd) and Apache ActiveMQ (activemq-broker in Bamboo). Three of the high Tomcat entries, CVE-2026-66422, CVE-2026-65183 and CVE-2026-68569, came from the same 18 to 20 August Tomcat releases. Apache rates CVE-2026-68569 Important and the other two Low.

Package coordinates to search for

These are the Maven coordinates named in the bulletin. On disk inside an Atlassian install, the JAR file names usually include the version, but Tomcat's own JARs often do not (for example catalina.jar), so check those with Tomcat's version tool shown below.

org.apache.tomcat:tomcat-coyote
org.apache.tomcat:tomcat-catalina
org.bouncycastle:bcprov-jdk18on
org.bouncycastle:bcprov-lts8on
org.bouncycastle:bcpkix-lts8on
org.bouncycastle:bcutil-jdk18on
org.bouncycastle:bc-fips
io.netty:netty-handler
org.apache.sshd:sshd-core
com.fasterxml.jackson.core:jackson-core
com.fasterxml.jackson.core:jackson-databind

Indicators of compromise

None. Atlassian, the upstream projects and CISA have published no indicators, and none is expected for a dependency bulletin with no reported exploitation. Treat any vendor or social post offering "IOCs for the Atlassian October bulletin" with suspicion.

What to do now

The supported fix is the vendor upgrade. The steps below get you there in order, with checks you can run today.

1. Find every self-managed Atlassian node

Start with the obvious ones, then look for the forgotten ones: a Crowd instance that only does single sign-on, a Fisheye/Crucible box nobody has logged into for a year, a Bamboo agent host, a staging copy of Confluence. Each product reports its version through a REST endpoint you can query without guessing.

# Jira Software and Jira Service Management
curl -s https://jira.example.com/rest/api/2/serverInfo | jq '.version, .deploymentType'

# Confluence
curl -s https://confluence.example.com/rest/applinks/1.0/manifest | grep -o '<version>[^<]*</version>'

# Bitbucket
curl -s https://bitbucket.example.com/rest/api/1.0/application-properties | jq '.version'

# Bamboo
curl -s -u "$USER" https://bamboo.example.com/rest/api/latest/info | jq '.version'

For Crowd and Fisheye/Crucible, read the version from the administration console or the page footer. Record every result against the affected ranges in the tables above.

2. Map each node to its fixed line

Use the "Fixed versions per product" table. As a rule of thumb, stay on your LTS line where the bulletin lists a fix for it, and plan a line change where it does not:

• Confluence 10.2.x to 10.2.19; 9.2.x to 9.2.26; 8.5.x and 7.19.x need a move to a supported LTS.
• Jira Software and JSM 11.3.x to 11.3.12; 10.3.x to 10.3.26; 9.12.x, 5.12.x and 5.4.x need a line change.
• Bitbucket 10.2.x to 10.2.8; 9.4.x to 9.4.26; 10.5.0 to 10.5.1.
• Bamboo 12.1.x to 12.1.12; 10.2.x to 10.2.24.
• Crowd to 7.2.4. Crucible to 4.9.15.

3. Look at what is actually bundled

Scan the installed product directory, not just your own code. This is how you see the lag for yourself, and it gives you evidence for the change ticket.

# List the bundled libraries named in the bulletin (adjust the install path)
INSTALL=/opt/atlassian/confluence
find "$INSTALL" -name '*.jar' \
  | grep -E 'bcprov|bcpkix|bcutil|bc-fips|netty-handler|sshd-core|tomcat|catalina|coyote|jackson' \
  | sort

# Bundled Tomcat version (Atlassian products that ship Tomcat keep it under lib/)
java -cp "$INSTALL/lib/catalina.jar" org.apache.catalina.util.ServerInfo

# Version from a JAR manifest when the file name does not carry one
unzip -p "$INSTALL/lib/tomcat-coyote.jar" META-INF/MANIFEST.MF | grep -i -E 'version'

Directory layouts differ by product and release. Jira keeps web application libraries under atlassian-jira/WEB-INF/lib, Confluence under confluence/WEB-INF/lib, and Bitbucket and Bamboo under their own application directories. A recursive find from the install root covers all of them.

4. Check whether the risky features are switched on

The upstream conditions are specific, and checking them helps you decide how urgent the change window is.

# Is HTTP/2 enabled on a Tomcat connector? (CVE-2026-65637)
grep -n 'Http2Protocol' "$INSTALL/conf/server.xml"

# Which connectors use TLS, and do they define SNI host configs?
grep -n -E 'SSLEnabled|SSLHostConfig' "$INSTALL/conf/server.xml"

# Is container DIGEST or FORM authentication used? (CVE-2026-65905, CVE-2026-68525)
grep -rn -E '<auth-method>(DIGEST|FORM)</auth-method>' "$INSTALL" --include=web.xml

Most Atlassian products handle login in application code rather than through Tomcat FORM or DIGEST authentication, which is one plausible reason for Atlassian's lower risk rating. We have not seen Atlassian say so, so verify on your own install rather than assuming.

For Crucible, check whether its SSH related features are in use and who can reach the host on the network. The upstream bug needs a server that explicitly uses asynchronous authentication; the bulletin does not say whether Crucible does.

5. Upgrade, starting with internet facing nodes

Order the work by exposure: anything reachable from the internet first, then anything that brokers identity (Crowd), then the rest. Follow Atlassian's normal upgrade path for each product, including a database backup, a home directory backup, and a check of Marketplace app compatibility against the new version. For clustered Data Center deployments, a rolling upgrade within the same LTS line is usually the least disruptive route; check the product's upgrade notes for whether your hop supports it.

6. Verify after the upgrade

Re-run the REST version checks from step 1 and the find from step 3. The bundled bcprov, netty-handler and Tomcat versions should now be at or above the upstream fixed versions in the Technical details table. Keep the before and after output; it is the cleanest evidence you will have for an auditor asking how you handled the October bulletin.

Compensating controls while you schedule the upgrade

You cannot patch a bundled JAR in a supported way, but you can reduce exposure while the change ticket moves through approval:

• Restrict network reach. Put Confluence, Jira and Crowd behind a VPN, a zero trust access proxy or an IP allow list if they are internet facing today. This lowers the risk from every entry in the bulletin at once.
• Terminate TLS in front of the product. If a reverse proxy or load balancer terminates TLS and speaks plain HTTP/1.1 to Tomcat, the Tomcat HTTP/2 and SNI checks on the product's own connector are not exposed to clients. If you deliberately enabled HTTP/2 on the bundled Tomcat connector, consider turning it off until you upgrade.
• Limit SSH access to Crucible. If you use any SSH facing feature on the Crucible host, restrict which source addresses can reach it.
• Watch authentication logs. Look for unusual successful logins to protected paths and unusual certificate validation outcomes on outbound connections. These are general signals, not indicators for these CVEs.
• Do not hand patch the JARs. Replacing bcprov or tomcat-coyote inside an Atlassian install by hand is unsupported, can break the product in subtle ways, and will be overwritten by the next upgrade. Use the vendor release.

What changed since first reports

• The count. Early mentions repeated the bulletin's 162 high and 14 critical figures as if they were unique vulnerabilities. SecurityWeek's 23 October count of about 75 unique CVEs, six of them critical, is the better summary of the work involved.
• CVE-2026-65905. SecurityWeek noted that Atlassian's portal lists this Tomcat DIGEST issue while the bulletin does not. It has not been explained.
• The next cycle has started. On 20 October, the same day as the Atlassian bulletin, Apache Tomcat disclosed another batch fixed in 11.0.27, 10.1.61 and 9.0.123, led by CVE-2026-101296. Those fixes are not in this bulletin. If any bundled Tomcat is affected, expect them in a future Atlassian release. Our post on the October Tomcat batch and CVE-2026-101296 has the details.
• No exploitation. Nothing in the bulletin, SecurityWeek or the CISA KEV catalog as of 23 October changes the "not exploited" status.

Open questions

• Why each CVE is "lower, non-critical assessed risk". Atlassian asserts this for every critical entry and does not publish per CVE reasoning. Customers cannot check the claim against their own configuration.
• Why the Netty entry is labelled RCE for Jira. The upstream advisory describes an SNI routing and mutual TLS bypass, not code execution. The bulletin labels the Jira and JSM entries RCE and the Confluence entry as broken authentication without explanation.
• How Crucible uses MINA SSHD. The upstream flaw needs explicit use of asynchronous authentication. The bulletin does not say whether Crucible uses it.
• Whether later builds carry the fixes. The bulletin lists fixed versions as of 20 October. Later releases on the same lines should include them; confirm in release notes.
• The portal versus the bulletin. Which list is authoritative when they differ, as with CVE-2026-65905, is not stated.

Atlassian's exploited advisory this month is a different story

Do not confuse this bulletin with CVE-2026-21589, a separate critical Data Center vulnerability. That one is in the CISA KEV catalog, and SecurityWeek reports attackers targeted it within hours of a public proof of concept. It was handled through Atlassian's out of cycle Critical Security Advisory process, not the monthly bulletin. If you have not dealt with it, it comes first. See our post on the Atlassian Data Center pre-auth file read in KEV.

What would have helped

There was no breach here. The useful question is how to make the next vendor bulletin a known quantity rather than a surprise, and how to see bundled dependency risk before the vendor tells you about it.

Practices any team can use

• An SBOM for what you run, not only what you build. Most organisations scan their own repositories and images and never inventory the libraries inside vendor software. Generating an SBOM of an installed product directory after each upgrade gives you a record of what is bundled and lets you match new upstream CVEs against it on the day they appear.
• Track upstream dates for vendor components. When a CVE lands in Tomcat, Netty or Bouncy Castle, ask which vendor products bundle that library. Write the date down. When the vendor bulletin arrives, you will know the lag, and you will have had weeks to apply compensating controls.
• Ask vendors for SBOMs and VEX. A software bill of materials from the vendor, ideally with VEX statements that say "not affected because the vulnerable code is not reachable", turns "lower assessed risk" into something you can review. Put the request into renewals and security questionnaires.
• Stay on a supported LTS line. The Confluence 8.5 and 7.19 lines and the old Jira lines have no fix in this bulletin. Being one LTS behind is manageable; being off the supported list means the only fix is a large migration done under pressure.
• Decommission what you no longer use. Forgotten Crowd and Fisheye/Crucible instances often carry the oldest libraries and the least monitoring.
• Keep a fast, rehearsed upgrade path. If upgrading Confluence takes a quarter of planning, every bulletin becomes a risk acceptance exercise. A tested runbook, staging environment and app compatibility check turn it into a routine change.
• Reduce exposure by default. Self-managed collaboration tools rarely need to be on the open internet. Network restrictions protect you during every lag window, not just this one.

Zero-Day Discovery and Gold

Two Safeguard capabilities relate to the habits above. We want to be exact about what they are and what they are not.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. It did not find the vulnerabilities in this bulletin; external researchers reported them to the upstream projects, which fixed them.

Gold Open Source at gold.safeguard.sh is free and needs no login. It provides searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh, a paid service, provides hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

We have not confirmed that Gold holds records or hardened builds for these specific CVEs, so we do not claim it. And neither capability changes what is inside an Atlassian install: that still comes from Atlassian. Where they help is in your own Java services, which very often carry the same Tomcat, Netty and Bouncy Castle versions. Those you can move on the day upstream ships.

Where Safeguard fits

Safeguard is a software supply chain security platform. For this bulletin, the honest fit is inventory, matching and rebuilding your own software, plus visibility into what vendor software carries:

• Finding the libraries. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> scans an SBOM, with results written as JSON under ./output. If your vendor provides an SBOM, or you generate one from an installed product directory, scanning it shows which bundled components match known CVEs. Compare the output against the find listing above, because detection of a bundled JAR depends on the metadata that JAR carries.
• Which projects contain a version. The platform shows which projects contain a given component and version, so "where else do we ship netty-handler below 4.1.137.Final" is a query.
• Matching and reachability. Components are matched against vulnerability databases, and reachability analysis ranks findings by whether your code reaches the vulnerable paths.
• Policies and gates. Policies evaluated in the platform can stop a build that resolves a version you have decided not to ship.
• Autonomous remediation for your own code. When a fixed version exists, fix pull requests can bump the dependency in your repositories. It ships off by default.
• The Safeguard CLI assistant. It can edit a pom.xml or build.gradle and run your build and tests, asking before each command under the permission mode you choose (/permissions: Ask, Accept edits, Plan, Auto, Strict). safeguard exec runs the same work in CI.

Where Safeguard does not help: it cannot patch the libraries inside an Atlassian product, and it cannot make an unsupported Server or old LTS install supported. It does not read your server.xml and decide whether HTTP/2 is reachable; the commands above do that. It would not have prevented any of these vulnerabilities. What it can shorten is the time between an upstream fix and a rebuilt service in the parts of your estate you control.

When you are ready to try it, download Safeguard and read the CLI documentation.

For the method behind step 3, see using SBOMs in incident response to find affected products fast. For the wider month, our roundup of October 2026 security incidents and what would have helped puts this bulletin in context.

Common mistakes and troubleshooting

• Counting 176 vulnerabilities. The bulletin repeats CVEs per product. Plan the work by product upgrade, not by CVE count.
• Treating the bulletin score as the project's rating. Three of the four August Tomcat CVEs are Moderate or Low in Apache's own rating; the 9.x numbers come from a generic assessment. Use the scores to sort, then read the conditions.
• Treating "lower assessed risk" as "not affected". Atlassian still shipped the fixes and recommends upgrading. The note lowers urgency; it does not remove the need.
• Upgrading to a version not in the table. A feature release on a different line may or may not include the fixes. Use the listed versions or a later build on the same line, confirmed in release notes.
• Forgetting the Data Center only label. Most fixed builds are Data Center only. A Server license cannot install them.
• Replacing JARs by hand. It looks like a quick fix and leaves you with an unsupported, untested product that the next upgrade silently reverts.
• Searching for Tomcat by file name only. Tomcat's JARs inside Atlassian products usually lack a version in the file name. Use ServerInfo or the manifest.
• ServerInfo fails with a class not found error. You are pointing at the wrong JAR or path. Search for catalina.jar under the install root and pass that path.
• The REST version endpoint returns a login page. Some instances restrict anonymous access. Use an authenticated request or read the version in the administration console.
• Mixing up this bulletin with CVE-2026-21589. That one is exploited and in KEV; this one is not. Different urgency, different process.

FAQ

What did the Atlassian October 2026 security bulletin fix?

It fixed 176 entries covering about 75 unique third-party CVEs (SecurityWeek's count) in bundled libraries such as Apache Tomcat, Netty, Bouncy Castle, Apache MINA SSHD, Jackson, Axios, Spring, Struts and ActiveMQ, across Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible, Jira Software and Jira Service Management.

Is any of it being exploited?

No exploitation is reported. Neither the bulletin nor SecurityWeek mentions attacks, none of the six critical CVEs is in the CISA KEV catalog as of version 2026.10.23, and the CISA assessment on each critical CVE record says exploitation none.

Is Atlassian Cloud affected?

The bulletin covers Data Center and Server products only and says nothing about Cloud, so there is nothing in it for Cloud customers to install.

Which versions should I upgrade to?

Bamboo 12.1.12 or 10.2.24; Bitbucket 10.2.8, 10.5.1 or 9.4.26; Confluence 10.2.19, 11.0.0 or 9.2.26; Crowd 7.2.4; Crucible 4.9.15; Jira Software and Jira Service Management 11.3.12 or 10.3.26. The first version listed for each product is Atlassian's recommendation.

Why did it take Atlassian 8 to 11 weeks to ship these fixes?

For the Tomcat, Netty and Bouncy Castle entries, the bulletin arrived 56 to 78 days after the upstream CVE was published. Atlassian's policy allows up to 90 days for critical, high and medium issues in Data Center products, ships fixes through monthly releases across several LTS lines, and rated these entries non-critical in context. The MINA SSHD fix arrived in about three weeks, so the lag varies.

Can I patch the bundled Tomcat or Bouncy Castle JAR myself?

Not in a supported way. Replacing a bundled library can break the product and will be reverted by the next upgrade. Use the vendor release, and use network restrictions and TLS termination in front of the product as interim controls.

I am on Confluence 8.5 or 7.19. What now?

Those lines are listed as affected with no fix in this bulletin. The supported path is upgrading to Confluence 9.2.26, 10.2.19 or 11.0.0, all Data Center only. Plan it as a migration, not a patch.

Why does the bulletin call a Tomcat Low issue critical?

The bulletin uses the CVSS score on the CVE record, which for the Tomcat issues comes from CISA's generic assessment. Apache's own Tomcat team rates CVE-2026-68525 Low, CVE-2026-65637 Moderate and CVE-2026-65182 Important.

Is the October Tomcat batch, including CVE-2026-101296, covered?

No. Tomcat released those fixes on 12 October and disclosed them on 20 October, the same day as the bulletin. If an Atlassian product bundles an affected Tomcat version, expect the fix in a later release.

Is this related to CVE-2026-21589?

No. CVE-2026-21589 is a separate, exploited Atlassian Data Center vulnerability handled by a Critical Security Advisory. This bulletin contains only third-party dependency fixes and nothing reported as exploited.

Fix it without waiting for upstream

For a vendor product like Confluence or Jira, the honest limit at the end of this section applies directly: the bundled libraries have to be fixed by Atlassian. Everything below applies to the Java services and images you build yourself, which very often carry the same Tomcat, Netty and Bouncy Castle versions, and which you can move the week upstream ships.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows an Atlassian product, and none of them patches a vendor install. Each shows a real flow that maps onto the part of this story you control: your own Java services that carry the same libraries.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this bulletin you would ask the same assistant to move netty-handler to 4.1.137.Final or bcprov-jdk18on to 1.85 in your own pom.xml, then run mvn verify and approve each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is the step that answers "which of our own services and images ship Tomcat below 11.0.25, Netty below 4.1.137.Final or Bouncy Castle below 1.85", across the repositories you already have checked out, so the vendor lag stops being your lag too.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. The same flow fits a Spring Boot service that embeds Tomcat: point it at the repository, let it propose a tomcat.version override to a fixed release, and approve the build and test commands one at a time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Atlassian Security Bulletin, 20 October 2026 (confluence.atlassian.com)
• Atlassian vulnerability disclosure portal (atlassian.com)
• Atlassian security bug fix policy (atlassian.com)
• Atlassian Server end of support FAQ (atlassian.com)
• CVE-2026-65637 record (cve.org)
• CVE-2026-65182 record (cve.org)
• CVE-2026-68525 record (cve.org)
• CVE-2026-65905 record (cve.org)
• CVE-2026-58062 record (cve.org)
• CVE-2026-75595 record (cve.org)
• CVE-2026-77185 record (cve.org)
• Apache Tomcat 11.x vulnerabilities (tomcat.apache.org)
• Apache Tomcat 10.x vulnerabilities (tomcat.apache.org)
• Apache Tomcat 9.x vulnerabilities (tomcat.apache.org)
• Netty advisory GHSA-c4c3-7fpv-j4q5 (github.com)
• Netty 4.1.137.Final release (github.com)
• Netty 4.2.17.Final release (github.com)
• Bouncy Castle CVE-2026-58062 advisory (github.com/bcgit)
• Bouncy Castle bcprov-jdk18on 1.85 on Maven Central (repo1.maven.org)
• Bouncy Castle bcprov-lts8on 2.73.12 on Maven Central (repo1.maven.org)
• Apache MINA SSHD sshd-core 2.20.0 on Maven Central (repo1.maven.org)
• CISA Known Exploited Vulnerabilities catalog feed (cisa.gov)
• SecurityWeek: Atlassian patches 75 third-party flaws in Data Center and Server products, 23 Oct 2026

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.