ZeroDay Field Notes - Your Tools Are Turning On You

Your vulnerability scanner shows all green. Your patching schedule keeps the auditors happy. Your CISO can tell the board you're 99.7% compliant.

But attackers are still inside.

This week's theme isn't about trust or betrayal or whatever metaphor I've beaten to death. It's simpler: patching has become theater. The checkbox gets checked. The attacker stays in. The ritual continues.

Fortinet: Three CVEs and Counting

Fortinet patched CVE-2025-59718 and CVE-2025-59719 in December. Your team applied the updates. The ticket got closed. The 18 December patch was supposed to be the final fix. On 21 January, admins found active compromises on fully patched devices. Reddit threads blew up. Arctic Wolf quickly confirmed automated attacks. By 27 January, Fortinet announced CVE-2026-24858, a new authentication bypass in FortiCloud's infrastructure. This wasn't just a patch bypass, but a separate vulnerability hiding next to the ones Fortinet had already fixed.

The attack was almost shockingly simple. Anyone with a FortiCloud account and a registered device could access other customers' devices if FortiCloud SSO was turned on. Two malicious accounts, including one with the cloud-init@mail.io address, hit many targets before Fortinet blocked them on 22 January. By then, attackers had automated everything: log in with SSO, create local admin accounts like secadmin, itadmin, and backupadmin, steal device configurations, and set up VPN access. Arctic Wolf observed that the entire process took merely seconds per target. In under a minute, they could compromise and establish persistence on multiple devices, highlighting how far traditional security measures lag in the face of such automation.

The real prize is the config dump. It contains every firewall rule, VPN configuration, LDAP credentials, and hashed passwords. That file is a full network blueprint, and it's likely to appear in targeted attacks months from now.

Fortinet rolled out a server-side fix on 27 January. But here's the catch: the cloud fix doesn't work with older FortiOS versions. If you patched to 7.4.9 in December and stopped there, you're now stuck in a compatibility gap your scanner won't catch.

Disable FortiCloud SSO:

 config system global
  set admin-forticloud-sso-login disable
 end

After you turn off SSO, look for accounts named audit, backup, itadmin, secadmin, support, backupadmin, deploy, remoteadmin, security, and sv. Watch for unusual configuration downloads, especially from unknown IP addresses, and change all credentials linked to the affected firewall, including LDAP service accounts.

The patch you applied in December was real. But in this environment, it simply wasn't enough.

SharePoint: Patching Makes It Worse

This year's SharePoint issues are a clear example of patch theater at its worst.

CVE-2025-49704 and CVE-2025-49706 showed up at Pwn2Own Berlin in May. Microsoft patched them in July. Attackers found ways around the patches. Microsoft then released CVE-2025-53770 and CVE-2025-53771. The cycle keeps repeating.

But the real issue isn't the RCE itself. The real story is what happens after you patch.

The ToolShell attack chain starts with a POST to /_layouts/15/ToolPane.aspx, with a Referer header set to /_layouts/SignOut.aspx to bypass authentication. Deserialization gives code execution. Attackers quickly upload spinstall0.aspx, a web shell that grabs the server's MachineKey—ValidationKey and DecryptionKey.

With those cryptographic keys, attackers can create valid __VIEWSTATE payloads that SharePoint treats as legitimate. They can keep running code indefinitely, even after you patch and remove the web shell.

Here's the twist: if you patch without rotating the machine keys, you only create a false sense of security. The compliance box is checked, but the attacker still has ongoing RCE access.

To follow CISA's guidance, rotate SharePoint machine keys once before patching and once after patching. Before restarting IIS, manually remove any suspicious module entries from applicationHost.config and web.config to prevent malicious modules from persisting.

Bloomberg reported 400+ compromised organizations before widespread patching. Attackers included Linen Typhoon, Violet Typhoon, and Storm-2603 (deploying Warlock and LockBit). The window from public PoC to mass exploitation was 72 hours.

Your SharePoint is patched. But is it actually clean? Don't assume you're safe. These are separate and urgent questions.

WinRAR: Six Months Later, Still Exploiting

CVE-2025-8088 was patched on 30 July 2025. Now it's late January 2026. CYFIRMA just revealed that Sandworm, Turla, TEMP.Armageddon, RomCom, a China-based group, and several financially motivated teams are still exploiting it.

This vulnerability is a path-traversal flaw that leverages Alternate Data Streams. Attackers make RAR archives that look like they only have a harmless PDF, but hidden ADS entries carry payloads with paths like:

 ../../../../../Users/<user>/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/malicious.lnk

If you open the archive, the payload ends up in your Startup folder. The next time you log in, your system is compromised.

The patch has been in place for 6 months. But WinRAR doesn't auto-update. You must download and install a new version manually. In enterprises, this means GPO deployment, testing, and change control.

Meanwhile, RomCom has been delivering SnipBot variants and RustyClaw downloaders. The Russian APTs are hitting Ukrainian targets. The financially motivated crews are burning through hospitality, travel, and banking sectors in Latin America and Brazil.

Your vulnerability management program probably doesn't track WinRAR versions. Your users almost certainly haven't updated it themselves. The patch exists in theory, but attacks keep happening in practice.

Telnetd: Eleven Years of Theater

CVE-2026-24061 existed in the GNU inetutils telnetd for 11 years. The vulnerable code was added in March 2015. It was included in version 1.9.3 and stayed there through version 2.7.

The bug is a remote authentication bypass. Telnetd passes the USER environment variable to /usr/bin/login without sanitization. Set USER=-f root via Telnet's NEW_ENVIRON option negotiation, and login interprets -f as the "preauthenticated" flag. Unauthenticated root shell.

The exploit only takes five lines of Python.

GreyNoise detected exploitation from 18 unique IPs within 18 hours of disclosure. TXOne Networks saw three payloads: validation probes, inline command execution, and full stager downloads, using curl, wget, and /dev/tcp to maximize success.

There's a patch now. Version 2.8 fixes the issue. But think about it: who still runs internet-exposed telnetd in 2026 and also keeps inetutils updated? These systems are still around because they've been forgotten. The vulnerability persisted for 11 years because these systems never received patches.

Patching telnetd is the right solution. But it's also the solution that probably won't happen.

The Marketplace Problem: No Patch Available

Some vulnerabilities don't have patches because they aren't bugs; they're the result of design choices.

Koi Security's analysis of "ChatGPT – 中文版" and "ChatMoss" (dubbed MaliciousCorgi) revealed extensions with 1.5 million combined installs operating as full-spectrum collection platforms:

Channel 1: Hook onDidOpenTextDocument and onDidChangeTextDocument. Every file you open gets Base64-encoded and shipped to a hidden iframe. Open your .env to check an API key? Gone.

Channel 2: Server-controlled bulk harvest. The C2 pushes a command, and the extension silently exfiltrates up to 50 files from your workspace. Any file type except images. No user interaction.

Channel 3: Zero-pixel iframe loading Zhuge.io, GrowingIO, TalkingData, and Baidu Analytics. Device fingerprinting, behavior tracking, and company identification. Profiling first, targeted exfiltration second.

The extensions really worked. The AI features were genuine. The reviews were real. That's why 1.5 million developers installed them.

Checkmarx flagged ChatMoss in October 2025. The extensions stayed in the Marketplace until late January. Microsoft eventually removed them. But there's no patch for a trust model that assumes marketplace vetting is enough.

Separately, Aikido Security caught a fake "ClawdBot Agent" extension (77 installs) that dropped a weaponized ScreenConnect client. The attackers set up their own relay server, generated a pre-configured installer, and distributed it through VS Code. The binary is signed, legitimate remote administration software. Your security tools allow it. The only thing malicious is the destination.

What's the fix for trusting the wrong thing?

Blockchain C2: Infrastructure You Can't Patch

ClearFake's latest variant stores its payload URL in a smart contract on the BNB Smart Chain at 0xA1decFB75C8C0CA28C10517ce56B710baf727d2e. The PowerShell stager queries the blockchain, Base64-decodes the response, and executes it.

Smart contracts can't be changed. You can't take them down or seize the domain. Only the wallet owner can change the stored URL.

EtherRAT, deployed via React2Shell exploitation (CVE-2025-55182), takes this further. Instead of one RPC endpoint, it queries nine simultaneously—Cloudflare, Flashbots, PublicNode, others—and uses majority consensus. Sinkhole one provider, the botnet self-heals.

The implant also self-modifies: on first C2 contact, it POSTs its own source to /api/reobf/ and replaces itself with the response. Each deployed instance diverges from the original, rendering signatures invalid.

Traditional incident response assumes you can disrupt the attacker's infrastructure by seizing domains, blocking IPs, or sending takedown requests. None of that works with a smart contract.

There's no patch for infrastructure that can't be changed. The defensive model assumes you can do things that just aren't possible anymore.

Quick Hits

Phishing targets your cloud. Attackers set up phishing sites on Azure Blob Storage, Google Firebase, and Cloudflare Pages. Trusted domains get past reputation filters. Your users' browsers trust microsoft.com by default. There's no patch for when the hosting provider is legitimate.

Chrome extensions are stealing AI chats. OX Security found two extensions (900,000 installs, one with Google's "Featured" badge) that send ChatGPT and DeepSeek conversations out every 30 minutes. Look for "Chat GPT for Chrome with GPT-5, Claude Sonnet & DeepSeek AI" and "AI Sidebar with Deepseek, ChatGPT, Claude and more."

React2Shell exploitation continues. Besides EtherRAT, GreyNoise is tracking campaigns that use MeshCentral RMM agents for persistence. Attackers keep using legitimate remote administration tools because your security stack allows them.

The hard truth is that patching is necessary but not enough, and more often than not, it's not even necessary in the ways that really matter.

Fortinet patched twice, but a third CVE appeared. SharePoint patching can give you a false sense of security if you don't rotate keys. WinRAR was patched six months ago, but most people haven't updated. Telnetd stayed vulnerable for 11 years because those systems never get patched. The VS Code Marketplace can't patch its trust model. Blockchain C2 can't be patched at all.

Your compliance dashboard shows green. Your patching stats keep the auditors happy. The ritual is complete.

But the attackers are still inside.

—UncleSp1d3r