October has been a busy month for anyone who owns a patch queue. Two of the flaws below are confirmed exploited and in CISA's Known Exploited Vulnerabilities (KEV) catalog, one is a rare virtual machine escape in the Linux kernel, Microsoft shipped its largest Patch Tuesday on record, and a popular WordPress plugin is being used to take over sites.

There's also a newer theme: reports of attackers using AI agents and MCP (Model Context Protocol) tooling in real intrusions. Those reports are thin, but they're a good reason to look at what your own agents can do.

🛑Editorial note: This write-up is for defenders. We don't publish exploit code, request payloads, or targeting details, and we don't name threat actors. Everything here is about finding exposure and fixing it.

The short version

IssueSeverityExploited?Do this
Atlassian Data Center file access (CVE-2026-21589)9.3Yes, in KEVUpgrade, or pull it off the internet; rotate secrets
FortiOS CLI path traversal (CVE-2025-61624)5.4 (vendor), 6.5 (NVD)Yes, in KEVPatch Fortinet gear; audit admins; check FortiManager
Linux "PwnEscape" VM escape (CVE-2026-99999)9.3No known usePatch and reboot hosts
Microsoft Patch Tuesday (1,411 fixes)Up to critical1 zero-day exploitedDomain controllers first, then the Shell bypass
Bricksforge WordPress plugin (CVE-2026-85097)10.0 / 9.8YesUpdate; hunt for dropped PHP files and new admins
AI agents and MCP in attacksn/aSingle-source reportsRestrict and log what your agents can run

1. Atlassian Data Center: unauthenticated file read (CVE-2026-21589)

What it is. A critical flaw in Atlassian's self-hosted Data Center products lets an attacker with no account read files from the application's web root. Atlassian rates it 9.3 on CVSS 4.0. The attacker has to know the exact file name and path, and can't list directories, but that's less comforting than it sounds: product file layouts are well known, and anything sensitive stored in the web root is fair game.

Who's affected. Data Center editions of Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible, and Fisheye. Atlassian Cloud has already been patched by Atlassian.

What's happened since. Atlassian published its advisory on October 5. Once researchers released technical details the next day, exploitation attempts started within roughly two hours. Honeypot operators counted dozens of distinct sources in the first days, and so far most of the activity looks like broad scanning rather than targeted attacks. CISA added it to KEV on October 15, with a short federal remediation deadline. Early reports said exploitation wasn't observed, so if you read one of those, it's out of date.

Fixed versions. Fixes include Confluence Data Center 9.2.26 and 10.2.19 and Bitbucket Data Center 9.4.26, 10.2.8, and 10.5.1. Fixed builds exist for every affected product, but secondary sources disagree on some of them (Crowd in particular), so take version numbers from Atlassian's own advisory.

What to do:

  1. Upgrade every Data Center instance to the fixed build listed in Atlassian's advisory.
  2. If you can't upgrade today, take the instance off the internet. Put it behind a VPN or an authenticating reverse proxy and apply Atlassian's mitigations until you can patch.
  3. Review access logs since early October for requests that try to climb out of normal application paths. Atlassian says it can't tell whether an individual self-hosted instance was compromised, so this is on you.
  4. Rotate secrets the application holds: database passwords, integration and API tokens, mail credentials, SSO and LDAP bind credentials, and anything in config files the web server can read. If an attacker read them, patching won't take them back.

2. FortiOS path traversal used to plant memory-only malware (CVE-2025-61624)

What it is. A path traversal flaw in the FortiOS command-line interface lets an already privileged user write or delete arbitrary files. On its own it's rated medium (Fortinet scores it 5.4, NVD 6.5), because you need admin-level access first. Fortinet fixed it in April 2026 (advisory FG-IR-26-122), and it also affects FortiPAM, FortiProxy, and FortiSwitchManager.

Why it's a big deal anyway. Researchers reported on October 16 that attackers chained it with an older, critical FortiManager flaw (CVE-2024-47575). After breaking into a managed service provider's FortiManager, which centrally manages many firewalls, they used CVE-2025-61624 to get root on managed FortiGate devices. They then deployed PEERSTITCH, malware that:

CISA added CVE-2025-61624 to KEV in mid-October. The lesson: a "medium" bug that needs admin access is critical once someone has admin access, and a compromised management console hands it to them for every device it manages.

Related: the FortiBleed credential campaign

On October 6, the FBI and U.S. Secret Service issued a joint advisory saying the "FortiBleed" campaign against FortiGate firewalls and SSL VPN gateways is still active. This one isn't a software bug. Attackers use leaked passwords, credential stuffing, and password spraying against exposed VPN portals, crack stolen password hashes offline, and then add or delete administrator accounts, sometimes locking the real admins out. Tens of thousands of devices are reported compromised.

The two stories overlap in one important way: both end with an attacker holding admin access to your firewall.

What to do:

  1. Patch FortiOS (7.4.10+ or 7.6.5+; older 7.2, 7.0, and 6.4 branches need to migrate to a fixed release), FortiPAM, FortiProxy, and FortiSwitchManager per FG-IR-26-122.
  2. Patch and isolate FortiManager. Confirm it's fixed for CVE-2024-47575 and that its management interface isn't reachable from the internet.
  3. Audit administrator accounts on every Fortinet device. Remove anything you don't recognize, and confirm you can still log in with your break-glass account.
  4. Reset admin and VPN passwords and enforce MFA on both admin access and SSL VPN.
  5. Restrict management access to trusted internal networks only. Admin interfaces should never face the internet.
  6. If you suspect compromise, don't rely on file scans, since memory-only malware won't show up. Follow Fortinet's integrity and incident guidance, and rotate every credential, private key, and certificate on affected and managed devices.

3. Linux "PwnEscape": a guest VM can read host memory (CVE-2026-99999)

What it is. A flaw in the Linux kernel's IPv4 networking code lets code inside a guest virtual machine read the host's memory. In plain terms, one tenant on a shared server may be able to see data belonging to the host or to other tenants. It's rated 9.3 and was disclosed on October 15.

At a high level, different parts of the kernel ended up trusting different versions of the same network packet, and the guest controlled the difference. The bug is in the kernel itself, not in KVM, Firecracker, or any one cloud. AWS says self-managed KVM hosts using virtio-net/TAP networking on unpatched kernels from 4.4 through 6.18 can be affected, while its managed EC2, Lambda, and Fargate services are not.

What's been shown. A researcher found it during Vercel's public sandbox security challenge and demonstrated host memory disclosure against Vercel's production sandboxes. More serious outcomes, such as writing to host memory, gaining code execution on the host, or crashing it, were reproduced only on the researcher's own lab machines. Vercel reported no evidence that customer data was accessed. There's no known exploitation in the wild, no public exploit, and it's not in KEV.

Why it matters to you. Anyone running untrusted workloads in VMs should care: hosting providers, CI runners, and especially sandboxes for AI agents and code execution, which exist precisely to contain untrusted code.

Fixed versions. The first fixed stable kernels are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, and 7.2.11, and later point releases in each line also carry the fix.

What to do:

  1. Update the host kernel, not just the guests. The guest kernel doesn't matter here.
  2. Reboot the host. There's no published workaround, and a patched kernel does nothing until it's running.
  3. Check your distribution's advisory, not just the version number. Distros backport fixes, so a vendor kernel can be fixed while showing an older version, or unfixed while showing a newer-looking one. Several distros were still evaluating at the time of writing.
  4. Ask your providers for their status if you rent VMs or use a hosted sandbox.

You can confirm which kernel a host is actually running after the reboot:

uname -r

4. Microsoft's October Patch Tuesday: 1,411 fixes, three zero-days

Microsoft's October 13 release fixed a record 1,411 vulnerabilities, according to BleepingComputer. Other trackers counted between 1,409 and 1,415, and between about 70 and 80 are rated critical, depending on who's counting.

The three zero-days:

Also worth flagging: CVE-2026-70229, Active Directory Domain Services RCE. An unauthenticated attacker could run code on a domain controller over the network. Microsoft scores it 8.1 with high attack complexity (a 9.8 score circulating online isn't Microsoft's), and exploitation is reported as limited. Still, a remote, no-login bug on the server that controls your whole Windows domain goes to the top of the list.

What to do, in order:

  1. Domain controllers and AD FS servers first. Test quickly and deploy.
  2. The Windows Shell MotW fix on workstations, since it's being exploited and phishing reaches everyone.
  3. WDAC-enforced systems, if you rely on application control as a security boundary.
  4. Rebuild your own .NET apps that depend on MessagePack-CSharp with the patched version.
  5. Everything else on your normal cycle. With 1,400+ fixes, prioritize by exposure, not by count.

5. Bricksforge WordPress plugin: unauthenticated upload to code execution (CVE-2026-85097)

What it is. Bricksforge, an add-on for the Bricks website builder, lets an attacker with no account upload and run PHP code on the server. That's full site takeover. Patchstack rates it 10.0, Wordfence 9.8.

Who's affected. Bricksforge 3.1.8 build 9 and earlier (the vendor writes it as a four-part version number). The fix arrived in 3.1.8 build 10.

What's happened. Patchstack saw exploitation start on October 7, with attempts from 63 unique sources within 48 hours. Automated scanning for vulnerable WordPress plugins means any public site running an old version should be treated as a target.

What to do:

  1. Update Bricksforge to the latest release (3.1.8 build 10 or later) from your WordPress dashboard or the vendor.
  2. Look for unexpected PHP files, especially in the plugin's upload folders and in wp-content/uploads, which normally shouldn't contain PHP at all. A quick way to list them from the site root:
find wp-content/uploads -name "*.php"
  1. Check for new administrator accounts you didn't create, and for recently changed plugins, themes, or wp-config.php.
  2. If you find anything, treat the site as compromised: restore from a known-good backup, then rotate WordPress admin passwords, database credentials, and the salts and keys in wp-config.php.
  3. Block PHP execution in upload folders at the web server level, so a future upload bug can't turn into code execution.

6. AI agents and MCP are showing up in attacker workflows

Two reports this month suggest attackers are using the same AI agent tooling defenders are adopting. Both are unconfirmed or come from a single source, so treat them as early warnings, not established fact.

Neither should be surprising. MCP is the standard way to connect AI assistants to tools, files, and systems, and researchers have been documenting the risks for a while: MCP servers with command-injection bugs, servers exposed to the internet without authentication, and prompt injection, where hidden instructions in a message, document, or web page steer an agent into calling a command-running tool. That risk is highest when tool calls are auto-approved.

Why it matters: an AI agent with a shell tool is a remote execution service. If an attacker can reach it, or talk it into doing something, they get whatever access the agent has.

What to do:

  1. Inventory your agents and MCP servers. Know which assistants, IDE plugins, and internal agents are running, which MCP servers they connect to, and who installed them.
  2. Restrict what agents can execute. Allowlist specific tools and commands rather than granting a general shell. Turn off auto-approve for anything that runs commands, writes files, or touches production.
  3. Never expose MCP servers to the internet. Bind local servers to localhost, require authentication on remote ones, and scan your own network for MCP ports you didn't expect.
  4. Run agents with least privilege. Use separate, short-lived, narrowly scoped credentials, keep production keys out of developer machines, and run agents in containers or VMs, which is where the PwnEscape patch above also applies.
  5. Log every tool call. Record what each agent ran, with what arguments, on whose behalf, and feed it to your SIEM. If an agent is ever misused, those logs are the only record of what happened.
  6. Control outbound traffic from agent sandboxes so a hijacked agent can't freely download tools or send data out.
  7. Vet MCP servers like any dependency. Install from trusted sources, pin versions, and review what each tool can actually do.
💡Quick win: if you use an AI coding assistant, open its settings today and check which tools are allowed to run without asking. Shell access on auto-approve is the setting to fix first.

Priority checklist

If you only have an afternoon, work through it in this order:

  1. Internet-facing Atlassian Data Center instances: upgrade or take offline, then rotate secrets.
  2. Fortinet firewalls and FortiManager: patch, audit admins, lock management to internal networks, enforce MFA.
  3. Domain controllers: apply October's updates.
  4. WordPress sites: update Bricksforge and check for dropped PHP files.
  5. Virtualization and sandbox hosts: patch the kernel for PwnEscape and reboot.
  6. Workstations: roll out the Windows Shell MotW fix.
  7. AI agents: review auto-approve settings, MCP exposure, and tool-call logging.
🎓More on running AI tooling safely: see our guides to Claude Code for cybersecurity workflows and agentic workflows with Ollama, and our recent write-ups on the LiteLLM 1.107.0 compromise and the PHP2Shell flaws.

Sources

Compiled from vendor advisories and security reporting published October 5–24, 2026. Where sources disagree on scores, dates, counts, or fixed versions, we've said so; always take final version numbers from the vendor. Threat actor names, and some attribution details that appear in a few sources, have been left out on purpose.

Several of these stories are still developing. We'll update this page as vendors and investigators publish more.

← All Write-ups