Atlassian’s October Bulletin Patches 75 Third-Party Flaws

Atlassian’s October bulletin is large, and its severity numbers don’t all agree. Here’s what it fixes and how to decide what to patch first.

What You Need to Know

Atlassian’s October 2026 security bulletin, published October 20, addresses 75 unique vulnerabilities in third-party components used across Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible, Jira Software, and Jira Service Management. Six are rated critical upstream, but Atlassian says the way its products use each affected component brings the risk below critical. Atlassian hasn’t reported exploitation of anything in this bulletin, though a lack of reports doesn’t prove none has happened.

What’s Vulnerable

The bulletin has 176 product-specific entries: 162 high severity and 14 critical. Those totals count a vulnerability once for every product it appears under, so there are far fewer than 176 distinct flaws.

SecurityWeek counted six unique critical CVEs across four dependencies. Apache Tomcat flaws CVE-2026-65637, CVE-2026-65182, and CVE-2026-68525 are listed for Confluence and Crowd. Bouncy Castle vulnerability CVE-2026-58062 affects Confluence, Crowd, Jira Software, and Jira Service Management. Netty vulnerability CVE-2026-75595 affects Confluence, Jira Software, and Jira Service Management, and Apache SSHD vulnerability CVE-2026-77185 is listed for Fisheye/Crucible.

The remaining high-severity issues are in libraries including Jackson, Axios, Spring, Apache Struts, and Apache ActiveMQ, plus the dependencies above. Many are denial-of-service bugs. Others involve cryptographic weaknesses, authentication and authorization problems, server-side request forgery, information disclosure, and code execution. Those categories describe the bulletin as a whole; they don’t mean every affected product is open to each one. SecurityWeek also caught a reporting mismatch: Atlassian’s disclosure portal lists another critical Tomcat flaw, CVE-2026-65905, among the October 20 disclosures, but that CVE isn’t in the monthly bulletin.

Why This Matters

A dependency’s upstream severity says little about how exploitable it is inside a particular Atlassian application, which is why Atlassian’s product-specific ratings come in lower than the raw CVE scores. That helps with scheduling, but it’s a weak argument for leaving the updates alone. Earlier in October, attackers started going after CVE-2026-21589, an unrelated critical Atlassian file-access vulnerability, within hours of a public proof of concept appearing. That has no bearing on this bulletin’s exploitation status, but it shows how fast things can move for Atlassian products once working exploit code is out.

The duplicated entries also make tracking harder. A CVE listed under four products is four separate exposures, and patching one application leaves the other three open.

What to Do

Inventory your Atlassian deployments, match installed versions against the bulletin’s product-specific fixes, and upgrade to the latest release or an applicable fixed version. When tracking remediation, deduplicate CVEs for reporting but keep each affected product instance as its own line item, so closing one doesn’t mark the others as done. Base the schedule on external accessibility, business impact, and Atlassian’s product-specific assessment rather than on upstream severity alone. Given the CVE-2026-65905 discrepancy, check Atlassian’s disclosure portal as well as the monthly bulletin when building your list. Push the updates through change control and confirm each deployment actually took. Atlassian’s lower ratings give you room to schedule this properly, but the work still has to get done.

Node2Shell: Code Execution Through Node.js Brotli Decoding

A malformed Brotli stream is enough to get code execution on an unpatched Node.js runtime, according to the Node2Shell research. Below is which applications are exposed, including services that only fetch data, and why the fix has to happen in the runtime rather than in your npm packages.

What You Need to Know

Imperva researchers got remote code execution on an official Node.js build by feeding malicious Brotli-compressed data to its bundled decoder. Their Node2Shell proof of concept exploited CVE-2026-111497 on the official Node.js 24.22.0 Linux arm64 image. They used no debugger and no deliberately weakened build. Node.js disclosed the vulnerability and released fixes on October 21. No exploitation in the wild had been reported as of October 22.

What Happened

Earlier research on this flaw only achieved code execution against a weakened test build. On a standard build, it produced a crash and some limited process-memory disclosure. Node2Shell goes further, but it has limits of its own. Execution took several attempts, and the researchers tested just one architecture and runtime build. They didn’t show code execution on the affected 22.x or 26.x lines. The patched 24.22.1 rejected the same malicious data without executing code.

The bug is triggered when a malformed Brotli stream hits an invalid block transition. The decoder should reject the stream at that point. Instead, it reads the condition as needing more input and keeps going in a broken state. A separate memory-sanitizer test turned up an out-of-bounds write. The fix pulls in an upstream Brotli change that stops decoding with a format error.

What’s Exposed

What matters is whether an application hands untrusted Brotli data to the vulnerable decoder; running an HTTP server isn’t enough on its own. There are two ways in: incoming compressed request bodies, and Brotli-compressed responses retrieved with Node.js’s built-in fetch(). Express 5 body parsers decompress Brotli request bodies on any route they’re applied to. That includes express.json(), express.urlencoded(), express.text(), and express.raw(). A plain Node.js HTTP server won’t decompress a request automatically just because it receives one. Imperva reproduced execution through both the request and response paths using selected Express and body-parser versions.

Why This Matters

Most teams will probably miss the response path. A service that fetches content from external systems can be exposed even if it never accepts compressed input from users, and network controls don’t help much there. Vercel’s October 21 inbound blocking rules, for example, address incoming attacks but can’t stop a malicious compressed response pulled in through fetch(), and they aren’t a substitute for patching. And because the vulnerable decoder ships inside the Node.js binary, updating npm dependencies does nothing if an old runtime is still baked into a container image or deployment artifact.

What to Do

Start with supported, patched Node.js releases wherever applications decompress untrusted Brotli content, including services that pull responses from external systems. Rebuild and redeploy container images and other artifacts that embed the vulnerable binary. Then check which runtime version is actually serving production traffic. For the 24.x configuration Imperva tested, 24.22.1 rejected the exploit input. Other release lines need their own fixed versions, and anything still on end-of-life 20.x or earlier should move to a supported line. Node.js doesn’t list a runtime workaround. Restricting untrusted Brotli traffic can reduce exposure in the meantime, but inbound filtering won’t protect an application that fetches a malicious compressed response. Until the binary serving traffic has changed, the patch isn’t finished.

Pillow 13.0.0 Closes Code Execution Paths in Python Image Processing

Pillow 13.0.0 fixes several flaws, and each one depends on a different set of conditions. Here’s what each requires and what to do before and after you upgrade.

What You Need to Know

Pillow 13.0.0, released October 16, fixes several vulnerabilities that can turn Python image-processing workflows into paths for command execution, memory corruption, or crashes. The most serious is CVE-2026-112900, an EPS-handling flaw in versions 2.6.0 through 12.3.0. It’s triggered by an attacker-controlled filename rather than malicious image content. No exploitation of any of the release’s vulnerabilities had been reported at the time of writing.

What’s Vulnerable

When Pillow opens an EPS file, it passes the filename to Ghostscript, an external program that renders the image. A carefully chosen filename can get Ghostscript to treat it as instructions and pull in a second file containing commands. Exploitation needs two things: Ghostscript’s gs executable has to be installed, and the attacker has to control the filename passed to Pillow. Upload services that keep user-supplied filenames are the obvious place to look. GitHub’s CVE record gives the flaw a critical CVSS score of 9.2. Pillow’s maintainers rate it moderate because of those prerequisites.

The release also fixes separate decoding and encoding bugs, each with its own requirements:

• FlashPix JPEG decoding: this flaw allowed command execution from a single Image.open() call when the optional olefile package was installed. Pillow identifies formats by content rather than extension, so renaming an uploaded file won’t keep it off that path.
• CVE-2026-112403: causes a buffer overflow when generating a thumbnail from a crafted lossless JPEG. Its advisory shows a crash, not code execution.
• CVE-2026-112393: affects compressed TIFF images saved to an in-memory buffer such as io.BytesIO instead of a file on disk. Researchers showed a crash, and got code execution only by chaining it with a separate memory-address disclosure flaw. A public proof of concept exists for this issue.

Why This Matters

Each of these flaws sits on a different processing path. Accepting an upload, generating a thumbnail, and re-encoding an image into memory all run different code, even within the same library. How urgent this is for you depends on three things: what your code does with images, which optional packages and external tools are installed, and whether user-controlled filenames ever reach Pillow. That’s also why the EPS flaw can be rated 9.2 in one place and moderate in another. Where the prerequisites exist, the risk is serious. Where they don’t, it’s much smaller.

What to Do

Upgrade to Pillow 13.0.0 and rebuild any deployment artifacts that contain older copies, including containers and packaged application environments. Pillow 13 drops Python 3.10 support, so deployments on that interpreter also need Python 3.11 or newer. Inventory image-processing workers, document pipelines, and upload endpoints, and confirm installed versions after redeploying.

Until the upgrades are done:

• Remove Ghostscript from hosts that process untrusted uploads if they don’t need EPS support.
• Keep attacker-controlled filenames away from EPS handling.
• For untrusted JPEGs, follow the advisory’s options for reducing exposure to the thumbnail flaw: avoid draft() and thumbnail(), load the image first, or set reducing_gap=None.
• Review compressed TIFF output written to memory separately. Saving to a real file avoids that particular vulnerable path.

Each of these steps covers one path, and only the upgrade covers them all.

PHP2Shell: Millions of Exploit Attempts, No Confirmed Compromises Yet

PHP2Shell has drawn millions of exploit attempts, mostly from the Potassium botnet, but no confirmed compromises so far. Here’s what the campaigns look like and how to separate probing from actual intrusion while you patch.

What You Need to Know

Attackers are probing for PHP2Shell at scale and trying to install Potassium, a Mirai-derived botnet. So far, none of the reported campaigns have shown successful exploitation in the wild. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both have CVSS scores of 9.2. They can allow unauthenticated remote code execution through crafted HTTP requests. Fixes are available in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

What Happened

Cloudflare saw tens of thousands of exploit attempts within 45 minutes of disclosure, and millions by early October 22. Several security firms reported scanning, fingerprinting, and failed payload delivery, but no confirmed compromises. Separately, VulnCheck built its own exploit. It chains a memory leak with code execution on ASLR-enabled x86-64 systems running PHP’s recommended production error-display setting.

Sophos and Arctic Wolf found attempted attacks meant to install Potassium, which can run distributed denial-of-service attacks and fetch additional payloads. The analyzed malware contacted command-and-control infrastructure at 134.199.154[.]64, and sandbox analysis identified TCP port 50792. Its downloader checked retrieved content for Linux ELF executable signatures before accepting a follow-on payload.

Other researchers found attacker-hosted tooling aimed at PHP 8.4.26 under Apache mod_php. That chain runs in three steps:

1. Recycle a PHP worker.
2. Leak memory addresses through session cookies to get around ASLR.
3. Abuse session upload progress handling to run a command.

Companion scripts screened targets for compatible versions, server configurations, and session settings. The researchers found no evidence of shell access on the screened sites.

Why This Matters

Attempts vastly outnumber successes so far, but the threat is still very real. VulnCheck’s exploit shows that ASLR, an important barrier to exploitation, can be beaten under a common production configuration. The screened-but-uncompromised sites show the other side: running a vulnerable version doesn’t mean a given exploit will work against you. When one does work, the attacker gets the web application’s permissions. That can be enough to reach database credentials, API keys, and internal services without root. Censys estimated that more than 34.4 million PHP services were still vulnerable on October 23. That number counts assessed services rather than confirmed exploitable hosts or infections, but it gives a sense of how much exposure is left.

What to Do

Patch internet-facing PHP deployments first. Check the runtime versions actually serving requests, including PHP embedded in vendor products, containers, and shared hosting. Updating WordPress, Drupal, Joomla, or your application code won’t fix a PHP engine vulnerability. Unsupported branches need to move to a supported release or a verified distribution backport.

Review web and process telemetry for these signs:

• suspicious session-related requests
• unexpected PHP worker restarts
• web-server processes launching shells
• newly written PHP files
• outbound payload retrieval, including connections to the Potassium infrastructure listed above

Treat these as leads to investigate, since none of them proves compromise on its own. The priority right now is closing verified runtime exposure while keeping failed probes separate from real evidence that an attacker ran code. With millions of attempts already logged, the stretch with no confirmed compromises may not last long.

BlackX Bootkit Shows Why Secure Boot Revocation Matters

BlackX abuses a Secure Boot flaw Microsoft patched in 2022, and it still works on fully updated systems. Here’s how the bootkit operates and which revocations close the gap.

What You Need to Know

Suspected APT41 operators have used the BlackX UEFI bootkit against diplomatic organizations in Tajikistan, Uzbekistan, and Turkmenistan. The bootkit exploits a Secure Boot protection gap that can still exist on fully patched Windows systems. Kaspersky discovered the campaign in early 2026 and attributes it to APT41 with medium confidence. Attackers use BlackX for persistence after they’ve already gotten in; it isn’t an initial-access tool. Because of that, revocation matters more than patching as a defense.

What Happened

BlackX resembles BlackLotus and exploits Baton Drop (CVE-2022-21894) to slip malicious components into the boot chain. Microsoft patched that vulnerability in January 2022. However, older boot components that were legitimately signed stay usable until Microsoft explicitly revokes trust in them. The attackers compromise the network and get administrator privileges before deploying the bootkit.

How BlackX Works

The installer uses a separate RC4-encrypted container and drops components on the Windows and EFI partitions. It then exploits Baton Drop to enroll attacker-controlled Machine Owner Keys. Those keys let malicious EFI applications load through the manipulated boot chain. BlackX then injects a malicious driver into the Windows kernel. The driver does three things:

• disables security-related process, thread, and registry callbacks
• interferes with Event Tracing for Windows providers
• redirects attempts to open protected bootkit files to calc.exe

The driver’s signing certificate was issued to Wenjiang District Mingyu Network Technology Service Studio and has since been revoked. Kaspersky reported that the driver’s product-specific tampering routines failed against Kaspersky’s own security software in testing. So the findings don’t show that the driver can bypass endpoint protection across the board.

Researchers also found two other tools. One is a remote-access trojan that uses Google Drive, OneDrive, or Yandex.Disk for command and control. The other is OxiDLLRunner, which relies on DLL sideloading, encrypted payloads, and downloadable plugins. The similarities to BlackLotus point to reverse engineering or access to its source code, but they don’t confirm that the same people developed both.

Why This Matters

Installing Windows updates won’t necessarily stop vulnerable boot components from loading. Secure Boot can show as enabled and the patch level can be current, yet the revocations that actually close the gap can still be missing. Incident response has the same blind spot. A cloud-backed trojan or a sideloaded DLL is easy to find and easy to mistake for the whole intrusion. Meanwhile, the persistence mechanism sits earlier in the boot chain, below the point where most investigations stop.

What to Do

Check Secure Boot revocation status directly. An enabled Secure Boot setting or a current patch level isn’t enough to go on. Microsoft’s mitigation requires two steps:

1. Update the Secure Boot trust databases.
2. Explicitly revoke Windows Production PCA 2011 through the forbidden-signature database (DBX).

The guidance notes that these mitigations aren’t enabled by default. The certificate’s October 19, 2026 expiration doesn’t block vulnerable binaries by itself.

Follow Microsoft’s staged deployment process before enforcing revocations:

1. Prepare trusted replacement boot components.
2. Update recovery media.
3. Test compatibility.

Applying the revocations too early can leave systems unable to boot.

When investigating a suspected intrusion, look past user-mode malware. Check for EFI partition changes, unexpected key enrollment, kernel drivers, and related payload activity. Until the revocations are in place, a patched system can still be running an untrusted boot chain.