DEV Community: Etairos.ai

k0t Edge Device Campaign Exposes 70,000+ Credentials Through FortiGate and GlobalProtect Appliances

Etairos.ai — Sun, 25 Oct 2026 20:04:24 +0000

TL;DR

what: Group-IB and NyxLab disclosed a campaign by the actor k0t that scans for exposed Fortinet and Palo Alto Networks edge appliances, then breaks in with CVE-2025-64446, CVE-2026-0257 or brute-forced logins.
impact: More than 70,000 credentials from network devices and LDAP dumps are exposed, and some victims suffered persistent access, data theft to Wasabi and MEGA, and later listings on the Qilin and The Gentlemen leak sites.
fix: Apply the Fortinet fix for CVE-2025-64446 and the Palo Alto Networks fix for CVE-2026-0257, rotate credentials on any exposed edge appliance and directory service, and enforce MFA on VPN access.
who: Any organization running internet-facing FortiGate, FortiWeb, PAN-OS GlobalProtect or Prisma Access, especially in North America, Europe and APAC, regardless of industry.

More than 70,000 credentials tied to enterprise firewalls, VPN gateways and LDAP directories have been exposed in a year-long campaign against internet-facing edge devices. Group-IB and NyxLab attribute the activity to a cybercriminal actor called k0t, also known as CryptoFeel, Member19 and QazWsxShop. The actor was first seen on October 22, 2025, and most compromises happened between February and June 2026. Many of the victims were later listed on the data leak sites of the Qilin and The Gentlemen ransomware groups.

Targeting is not tied to any sector. k0t picks targets by product and location, not by industry. According to the researchers, the actor enumerates exposed appliances at scale instead of researching individual organizations. If your perimeter runs the right firmware in the right country, you are on the list.

Who k0t Is

k0t appears to work as an initial access broker or ransomware affiliate. The link to Qilin and The Gentlemen comes from victim overlap: organizations breached in this campaign later showed up on those gangs' leak sites. The researchers state that the exact relationship is unclear. Either way, access obtained by k0t has ended in extortion.

On dark web forums, k0t has shown steady interest in buying exploit code, offensive tooling and premium accounts on FOFA and ZoomEye, two internet-wide metadata search engines. Those purchases fit the operating model: find exposed devices fast, buy or build an exploit, and work through the target list before defenders patch. k0t's stated geographic priorities start with the United States and Canada, then European countries and selected APAC markets.

The Attack Chain

The intrusion sequence documented by Group-IB and NyxLab runs in six stages:

Reconnaissance: FOFA and ZoomEye queries enumerate internet-facing VPN and firewall appliances, filter them by product, and produce target lists of likely vulnerable devices.
Initial access: custom Python scripts named fortnew.py and exploit_2026_0257.py exploit CVE-2025-64446, a path traversal flaw in Fortinet FortiWeb, and CVE-2026-0257, an authentication bypass in Palo Alto Networks PAN-OS and Prisma Access. Where exploits fail, the actor brute-forces common username and password combinations.
Foothold: the actor connects into the victim network through an OpenConnect VPN session using the stolen or bypassed access.
Discovery and credential theft: enumeration of Active Directory, SMB shares and installed antivirus products, followed by more credential harvesting.
Persistence: legitimate remote management tools including MeshCentral Agent, Atera, Teramind and AnyDesk, plus the open-source adversary emulation framework AdaptixC2.
Exfiltration: Rclone moves harvested data into Wasabi S3 buckets and MEGA cloud drives.

For lateral movement and privilege escalation, k0t relies on standard admin and pentest utilities: NetExec, SoftPerfect Network Scanner, Impacket, noPac, Kerbrute, PetitPotam and Mimikatz. None of these is custom malware. Every tool in the post-exploitation kit is publicly available and often already allowed somewhere in enterprise environments, which makes signature-based detection weak.

⚠️ Why the VPN foothold matters — Once k0t authenticates through OpenConnect, traffic arrives from an address the network already treats as a trusted remote user. Perimeter controls see a valid VPN session, not an intrusion. Detection then depends on spotting behavior after login, such as Kerberos enumeration, PetitPotam coercion, new RMM agents and large Rclone transfers to Wasabi or MEGA.

Scale and Geography

Victim distribution follows exposure density, not the actor's stated priorities. Nearly 38% of victims are in Asia Pacific, 31.9% in Latin America, 15.8% in Europe and 12.7% in the Middle East and North Africa. The gap between where k0t wants to hit (North America first) and where victims actually sit suggests the campaign takes whatever the scanners find exploitable. Regions with slower patch cycles on edge hardware absorb a larger share.

The 70,000-plus exposed credentials include network device logins and LDAP dumps. LDAP data is the more damaging part. A directory dump gives an attacker the user population, group memberships and service accounts needed to plan privilege escalation, and any credential reused across systems turns one edge compromise into domain-wide access.

Relationship to FortiBleed

The peak window from February to June 2026 overlaps with FortiBleed, a separate credential harvesting campaign against Fortinet devices. Group-IB and NyxLab found negligible overlap in compromised data between the two. The researchers note that many operators are likely involved in the FortiBleed activity cluster, and that k0t's haul may be a separate dataset, a subset of operators, or a related access operation inside the broader FortiBleed activity.

In practice, organizations that already reviewed their exposure after FortiBleed should not assume that work covers this campaign. The credential sets are largely distinct.

Vendor Fixes and Mitigation

Both exploited vulnerabilities are known and have vendor fixes. CVE-2025-64446 affects Fortinet FortiWeb, and CVE-2026-0257 affects Palo Alto Networks PAN-OS and Prisma Access. The source report does not list specific fixed builds. Affected versions and patched releases are published in the Fortinet PSIRT and Palo Alto Networks security advisories for each CVE. Group-IB and NyxLab advise organizations to make sure every vulnerability named in their report is remediated.

Patching only blocks the exploit path. It does nothing about credentials already stolen or persistence already installed. The brute-force path also means that fully patched devices with weak or default passwords and no MFA remain exposed. Any appliance that was internet-facing and unpatched during the February to June 2026 window should be treated as potentially compromised. That means credential rotation for the device and connected directory accounts, plus a review for unauthorized RMM agents and AdaptixC2 artifacts.

RedEye assessment — This campaign shows the current edge device economy: commodity scanning, purchased exploits and off-the-shelf tooling, sold onward to ransomware crews. The weak point is the time between disclosure and patch on perimeter hardware, combined with VPN authentication that lacks MFA. Organizations whose exposure assessment covers only patch levels, and not credential hygiene and post-authentication behavior, are the ones turning up on leak sites.

Bottom Line

k0t does not need to know who you are. It needs your firewall to answer on the internet with a vulnerable build or a guessable password. With a confirmed pipeline from access to Qilin and The Gentlemen leak site listings, an exposed edge appliance is a ransomware entry point, not just a patching backlog item. RedEye Security can assess your internet-facing edge footprint, check for indicators of this campaign, and confirm whether exposure during the 2026 window led to persistence inside your environment.

Originally published on RedEye Threat Intelligence.

CVE-2026-111497: Google Brotli Decoder Flaw Reaches Node.js, Bun, Envoy, Istio and Python

Etairos.ai — Sun, 25 Oct 2026 14:04:27 +0000

TL;DR

what: CVE-2026-111497 is an out-of-bounds write in Google's Brotli C decoder, versions 1.0.3 to 1.2.0, triggered by crafted Brotli-compressed data.
impact: Any program that decodes attacker-controlled Brotli can crash, leak memory or run attacker code, and Imperva has demonstrated remote code execution on unpatched Node.js 24.22.0.
fix: Fixed in Brotli 1.0.10, 1.1.1 and 1.2.1, Node.js 22.23.4, 24.22.1 and 26.12.1, Bun 1.4.4, Envoy 1.40.0 and backports, Istio 1.31.2, 1.30.6 and 1.29.9, Python Brotli 1.2.1, brotlicffi 1.2.1.0, and cdxgen 13.5.0 and 12.8.9.
who: Teams running Node.js or Bun services that fetch remote content or accept compressed uploads, Envoy or Istio meshes with Brotli decompression enabled, and any Python application with Brotli or brotlicffi installed.

A memory-corruption flaw in Google's Brotli decompression code, tracked as CVE-2026-111497, gives attackers a way to write past the end of a buffer in any program that decodes Brotli data they control. Google rates it 9.2 (critical) on CVSS 4.0. Imperva's Red Team has turned it into working remote code execution on an unmodified Node.js 24.22.0 build. The vulnerable code also ships inside Bun, Envoy, Istio, cdxgen, and the Python Brotli and brotlicffi packages. Since each project bundles its own copy of the decoder, patching one does nothing for the rest.

Node.js and Google released fixes on October 21, and other vendors have followed one by one. CISA's October 23 assessment recorded exploitation as "none" and automation as "no." Red Hat says there is no reliable public proof-of-concept for code execution. Nobody has reported attacks in the wild yet.

What the Bug Is

Brotli is Google's compression format, used across the web to shrink pages and API traffic. The flaw lives in the C code that unpacks a Brotli stream. A crafted compressed payload makes the decoder write beyond its output buffer and corrupt adjacent memory. The result can be a crash, a memory leak, or execution of attacker-controlled code, depending on the target and how much work the attacker puts in.

Google Brotli versions 1.0.3 through 1.2.0 are affected. The fixed releases are 1.0.10, 1.1.1 and 1.2.1.

Affected Products and Fixed Versions

Node.js: 22.x, 24.x and 26.x before the fix. Fixed in 22.23.4, 24.22.1 and 26.12.1. Node.js 20.x and older are end of life and will not get a patch.
Bun: 1.4.3 and earlier. Fixed in 1.4.4.
Envoy: 1.39.2, 1.38.5, 1.37.7 and 1.36.11. Fixed in 1.40.0, 1.39.3, 1.38.6, 1.37.8 and 1.36.12. Exposed only when the Brotli decompressor is configured.
Istio: 1.31.0 to 1.31.1, 1.30.0 to 1.30.5, and 1.29.0 to 1.29.8. Fixed in 1.31.2, 1.30.6 and 1.29.9. Exposed only when Brotli decompression is enabled.
Python Brotli: 1.2.0 and earlier. Fixed in 1.2.1.
Python brotlicffi: 1.2.0.x and earlier. Fixed in 1.2.1.0.
cdxgen standalone binaries and images: 13.4.0, and 12.8.8 and earlier. Fixed in 13.5.0 and 12.8.9. Exposed when scanning untrusted input.

When a System Is Actually Exposed

The flaw can only be reached when a program decodes Brotli data that someone else controls. Where that happens differs by platform.

In Node.js and Bun, the built-in fetch() decodes any response sent with Content-Encoding: br. A service that fetches from third-party or attacker-influenced URLs can be hit by a malicious server. On the inbound side, request-body middleware such as Express 5 and body-parser 2 unpacks Brotli uploads, so an internet-facing API built on them can be hit by a malicious client. Bun is also exposed through node:zlib. A bare Node.js HTTP server does not decode request bodies by itself.

Envoy and Istio are exposed only when Brotli decompression is switched on, for example through an Envoy filter. With decompression off, the vulnerable code never runs.

⚠️ Python exposure without a single import — If the Brotli or brotlicffi package is installed, HTTP clients including requests, urllib3, httpx and aiohttp decode Brotli responses automatically. An application can be exploitable without ever importing Brotli in its own code, simply because a transitive dependency pulled the package into the environment.

OpenAI's Codex Security team, which reported the flaw, describes it as unauthenticated remote code execution that works in both directions. An unpatched server accepting compressed input can be taken over by a malicious client, and an unpatched client accepting compressed responses can be taken over by a malicious server.

Exploitation: Node2Shell

Imperva's Red Team calls its work Node2Shell. The team ran attacker-supplied code on stock Node.js 24.22.0 for Linux on ARM64, delivering the payload two ways: as a fetched HTTP response and as an Express request body. The exploit needed several attempts, has not been published, and was only tested on that one build. Nobody has shown code execution on Bun, Envoy, Istio or the Python packages. For those, the confirmed impact is memory corruption, and the realistic outcome on any given build is anywhere from a crash to code execution.

Scores vary by vendor. Google, the CVE assigner, gives it 9.2 critical on CVSS 4.0. Node.js rates it high. Red Hat scores it 8.1, important.

An Eight-Month Gap Between Fix and Release

The code change that closes the flaw went into Brotli's source on February 27. No Brotli release included it until October 21. According to OpenAI, the root cause "was actually fixed in the Brotli source code in February, but it wasn't known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli." So for almost eight months, every downstream project that vendored a tagged Brotli release was carrying a bug that was already fixed upstream.

Node.js credits Khai Tran and Sylvie Mayer of OpenAI's Codex Security with the report, and maintainers Matteo Collina and Antoine du Hamel with the fix.

Vendor Mitigations and Their Limits

Patching closes the hole, but only after a restart. A running process keeps the old decoder in memory, and container images keep the vulnerable library until they are rebuilt. For systems that cannot be updated yet, OpenAI's disclosure page and Aikido recommend rejecting inbound requests carrying Content-Encoding: br before any proxy or parser decodes them, turning off automatic Brotli decoding in HTTP clients, and, in Python, removing the Brotli and brotlicffi packages so clients fall back to gzip and deflate.

Two of the obvious defenses fall short. Dropping br from the Accept-Encoding header does not protect a client, because a server can send Brotli no matter what the client asks for. And Node.js has published no workaround, so updating the runtime is the only fix there.

WAFs do not cover outbound fetches — Vercel added firewall rules on disclosure day but said they do not cover "responses your functions fetch from other servers." A WAF in front of a service only sees inbound traffic. On the outbound fetch path, the only fix is an updated runtime or library.

Patch Status Across Distributions and Scanners

OS packages are getting fixed on different schedules. Debian patched brotli for Debian 13 (trixie) on October 23 in version 1.1.0-2+deb13u1. As of October 22, Amazon Linux 2023 still listed its brotli and Node.js 24 packages as pending a fix. Dependency scanners may also miss the Python exposure, because the CVE record names Google's Brotli repository and not the PyPI packages. A clean scan does not prove a Python environment is safe.

RedEye Assessment

This is a vendored-library problem. Fixing it means finding every copy of the decoder across runtimes, proxies, service meshes, Python environments, base images and build tooling, then confirming each one has been patched and restarted. Outbound fetch paths and transitive Python dependencies are where scanners and WAFs are least likely to catch it. RedEye Security can map where Brotli decoding happens across your environment, identify which exposure paths can actually be reached, and confirm remediation. Contact us to schedule an assessment.

Originally published on RedEye Threat Intelligence.

Eye Security Pushed 2 Million Unrequested Updates to Kill an Abandoned Popcorn Time Updater. It Was the Right Call.

Etairos.ai — Sat, 24 Oct 2026 20:04:48 +0000

TL;DR

what: Between November 2025 and March 2026, Eye Security used the Time4Popcorn updater's own flaw to push more than 2 million updates that disabled it on machines the firm did not own.
impact: An estimated 2.5 to 3 million Windows PCs and 250,000 to 350,000 Macs ran an updater that would install any code at SYSTEM or root level from abandoned domains anyone could register.
fix: CVE-2026-30612 has no vendor and no patch, so Eye sinkholed 15 domains through the Shadowserver Foundation and recommends uninstalling Time4Popcorn entirely.
who: Anyone still running Time4Popcorn on Windows up to 6.2.1.18, Mac up to 6.2.1.17 or Android up to 3.5.0.173, including some machines on government, military and corporate networks.

Between November 2025 and March 2026, the Dutch security firm Eye Security pushed more than 2 million updates to computers it did not own. Each one did a single thing: it switched off a forgotten background updater that, by Eye's account, would have given any outsider SYSTEM or root control of the machine. No vendor asked for this and no owner agreed to it. By Eye's estimate, 2.5 to 3 million Windows computers and 250,000 to 350,000 Macs were still calling home to dead web addresses when the firm stepped in.

The software is Time4Popcorn, an abandoned copy of Popcorn Time, the BitTorrent app for streaming pirated films and TV that peaked about a decade ago. The original shut down in 2014, but copies kept running under the same name. A separate, legal project that took the Popcorn Time name in early 2025 has nothing to do with it. Eye described the work, which it calls Operation IXIM, in a write-up and a talk at Hack.lu on October 22, as reported by The Hacker News.

A dead domain, 50 requests a second

It started as a routine threat hunt. A program called Updater.exe on one client's laptop kept trying to reach a web address that was no longer registered. Eye registered the address itself to see what would connect, and about 50 requests a second came in. Over six months those requests carried more than 3.8 million distinct hardware IDs. Eye later revised that count because some Windows PCs shared an ID and some Macs kept changing theirs.

The design flaw is a textbook case. The updater started at boot on Windows and Mac, checked for new versions over an unencrypted connection, and installed whatever it was sent at the highest privilege level without checking who sent it. Once the update domains lapsed, anyone who registered the right one could ship code to every machine still asking. Eye said that put ransomware, password theft and botnet enrollment within reach. A sample of the connecting addresses showed home users around the world, plus machines on government, military and corporate networks, though Eye cautioned that it is "hard to draw conclusions" from that.

⚠️ CVE-2026-30612 at a glance — Eye disclosed the flaw in June, and CISA rates it 9.8 out of 10. It affects Time4Popcorn on Windows up to and including 6.2.1.18, Mac up to and including 6.2.1.17, and Android up to and including 3.5.0.173. There is no vendor and no patch. As of October 23, 2026, it was not in CISA's Known Exploited Vulnerabilities catalog.

Turning the updater against itself

With nobody left to patch the software, Eye got legal advice and then used the flaw as the fix. It served an update that stops and disables the updater. The update deletes no files and collects nothing. Eye compared the step to Operation Ladybird in 2021, when Dutch police pushed an update that disabled Emotet on infected computers. Eye pointed to one difference: Emotet's victims never chose to be infected, while Popcorn Time's users installed the app themselves. Still, as the firm put it, "none of them chose to have a forgotten updater running in the background for years."

Then security tooling got in the way. Someone uploaded Eye's update to VirusTotal, and antivirus engines started flagging it as malware. That is a fair label for code that disables a Windows service. But every product that blocked the update left the vulnerable updater running. Eye reworked the payload until only one scanner still flagged it.

By December 2025, Eye had updated more than 1 million systems and cut traffic to its domains by about 90 percent. By March 1, it was sending about 5,000 updates a day, a 98 percent reduction. Eye judged the remaining numbers too small to interest a botnet operator and stopped, after more than 2 million update downloads in total. In late March it handed the 15 domains it controlled to the Shadowserver Foundation. Registration records for popcorntimeupd[.]xyz now point to Shadowserver's sinkhole servers, with a transfer dated March 20, 2026.

What the cleanup did not fix — Some domains the updater calls were never Eye's to take and are still held by outside owners. Eye found them parked or for sale, not serving code, but machines that reach them are still exposed. The app itself runs a 2014 browser engine with its security sandbox turned off, loads content over unencrypted connections, and pulls in code from other abandoned domains. Eye registered those too and built a working proof of concept for running its own code, but never used it. Android devices were left alone because the updater there only installs if the user taps to accept. Eye's advice is to uninstall the app.

The RedEye take

Eye made the right call, and the way it carried out the operation is a model for others. It got legal advice first, used a payload that did the minimum, collected no telemetry, gave a public account, and finished by placing the domains with a neutral non-profit instead of keeping them. That last step matters most. A private company that holds the update channel for millions of machines is a risk in its own right, however good its intentions.

The bigger story is that it fell to a private firm at all. There was no vendor, no patch, no KEV listing and no agency pushing a fix. A 9.8 flaw stayed open on millions of endpoints, some of them on government and military networks, and the only party willing to act had to take on its own legal risk. Unauthorized remediation should not be the industry's default safety net for abandoned software. Until there is a clear framework for who may act on orphaned update channels, the next researcher who finds one must choose between doing nothing and doing something legally uncomfortable. Many will do nothing, and someone less careful will register the domain.

The antivirus episode matters too. Detection engines flagged the fix as malware and, in doing so, kept machines vulnerable. That is not a scandal, because the flags were technically accurate. It is a reminder that a signature verdict knows nothing about intent.

What defenders should learn

Treat beacons to unregistered domains as a finding, not noise. This whole operation began with one laptop calling a dead address. Persistent processes that keep failing to reach a domain point straight at the abandoned update channels an attacker would buy.
Inventory services, not just applications. The danger here was a boot-time SYSTEM and root service left behind by software nobody maintains. Asset reviews should flag persistent updaters tied to unsupported products, including software users installed themselves.
Do not wait for KEV to set priorities. CVE-2026-30612 is rated 9.8, has no patch, and is not in KEV. For abandoned software, a lack of evidence of exploitation says nothing about how cheap exploitation would be. Here it took one domain registration.
Decide ahead of time how you handle good-faith remediation. If a payload like Eye's reaches your fleet and your endpoint tooling blocks it, your tooling may be what keeps a vulnerable component running. Know who reviews these detections before an automatic quarantine becomes permanent.
Partial cleanup is not cleanup. Disabling the updater left a 2014 browser engine with no sandbox in place. For orphaned software, the only acceptable outcome is removing the whole application, not mitigating one component.

Source: The Hacker News, "Researchers Push Over 2 Million Updates to Remotely Disable Popcorn Time Updater That Could Fuel a Botnet," October 24, 2026.

Originally published on RedEye Threat Intelligence.

Leaked LiteLLM Master Key Sat Unrevoked for 136 Days, Then Shipped a Malicious 1.107.0 Release

Etairos.ai — Sat, 24 Oct 2026 14:04:22 +0000

TL;DR

what: An unrevoked LiteLLM Agent Platform master key leaked on GitHub in May 2026 let an attacker steal an org owner's GitHub token and publish a malicious LiteLLM 1.107.0 on October 21, 2026.
impact: The attacker held owner-level access to every BerriAI repository, harvested maintainer tokens plus API keys for Anthropic, OpenAI, AWS Bedrock, Together AI and more, and pushed poisoned builds to PyPI, Docker Hub and GHCR.
fix: PyPI quarantined 1.107.0, Docker Hub tags v1.107.0, latest, main-latest and main-stable were removed or repointed to verified clean images, and LiteLLM is revoking every token across its internal systems and vendor platforms.
who: Any organization that installed LiteLLM 1.107.0 or pulled the affected LiteLLM container tags on October 21, 2026, plus anyone whose inference keys pass through a LiteLLM gateway.

One secret that was flagged for revocation and never revoked gave an attacker owner-level control of the LiteLLM GitHub organization and a path to publish a malicious release of one of the most widely used open source LLM gateways. LiteLLM disclosed on October 24, 2026 that a master key for its Agent Platform, committed to a public repository on May 27, 2026, was used on October 10 to start a chain that ended with LiteLLM 1.107.0 being published to PyPI, Docker Hub and GHCR on October 21.

The release was live on PyPI for roughly an hour and 45 minutes before quarantine, and the container tags stayed poisoned for about two and a half hours. For a package that sits between applications and every upstream model provider they call, that window matters.

The Leak That Was Caught but Not Closed

On May 27, 2026, a configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key for a deployment of the LiteLLM Agent Platform, an open source tool LiteLLM uses to orchestrate agents. The team spotted the mistake, force-pushed over the commit and marked the exposed keys for revocation. The master key was never actually revoked.

Force-pushing removes a commit from branch history, not from every clone, mirror or scraper that already captured it. The key stayed valid for 136 days until the attacker used it.

From Agent Platform to Organization Owner

On October 10, 2026, an attacker operating from 69.48.229[.]143 authenticated to the Agent Platform with the leaked key and pulled a GitHub CLI OAuth token the service used so self-hosted cloud agents could open pull requests. That token was not scoped down and belonged to the GitHub organization owner's account. It gave the attacker owner-level access to every repository in the organization.

⚠️ The core failure — An automation credential whose only job was filing pull requests carried full organization owner rights. Once the Agent Platform fell, there was no permission boundary left between the attacker and the release process.

Ghost Branches and Credential Harvesting

Between 10:11 and 10:12 p.m. UTC on October 10, the attacker pushed commits to throwaway branches on the internal BerriAI/litellm and BerriAI/litellm-auto repositories. Socket recovered two malicious commits, one on October 10 at 10:11:45 p.m. UTC and a second on October 12. Each followed the same pattern:

Create a branch named ci-tmp- (observed: ci-tmp-a351cc and ci-tmp-4d8517) from a recent legitimate commit so the base looks clean.
Push a commit adding .github/workflows/cache.yml with the subject "ci: bump cache config".
Let the on: [push] trigger run the workflow immediately.
Delete the branch, and later the workflow runs, within minutes.

Socket noted that neither commit landed on a branch that still exists, which is why ordinary repository history shows almost nothing. The evidence lived in activity logs.

The October 10 workflow harvested GitHub CLI OAuth tokens for two engineers with maintainer privileges, plus keys for the Linear workspace, a LiteLLM deployment, Together AI, and a GitHub App identifier and signing key. The October 12 run widened collection to API keys for Anthropic, OpenAI, AWS Bedrock, Tavily and the GitGuardian secret-scanning tenant, along with Playwright storage state, PostgreSQL connection strings and credentials, and Redis endpoint, port and password. Data went to two webhook[.]site endpoints.

Hijacking the Release Pipeline on October 21

LiteLLM's normal release process requires an authorized engineer to start a build and a special account tied to a physical device in the office to approve it. That week the control had been relaxed to allow any two engineers to trigger and approve releases, to support a push for more frequent releases and bugfix backports. The attacker had exactly two maintainer tokens.

10:08 to 11:08 a.m. UTC: branch protection overridden and the release pipeline source repointed to the lookalike repository Berri-AI/litellm instead of BerriAI/litellm.
11:39 to 11:40 a.m. UTC: LiteLLM 1.107.0 published to PyPI, triggered with one stolen token and approved with the other.
11:46 a.m. UTC: Docker Hub and GHCR images published.
11:53 to 11:54 a.m. UTC: production and staging run records deleted.
12:06 p.m. UTC: attack reported by Upwind researcher Lidor Machluf.
1:23 p.m. UTC: PyPI quarantines 1.107.0.
2:20 p.m. UTC: Docker Hub tags v1.107.0, latest, main-latest and main-stable removed or repointed to verified clean images.

LiteLLM pointed out that the attacker already held an owner token and could have disabled the two-person rule outright. The team suspects the attacker chose not to in order to avoid detection. Using the relaxed control as designed produced a release that looked procedurally normal.

Indicators of Compromise

Source IP: 69.48.229[.]143
Exfiltration: webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37
Exfiltration: webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1
Lookalike repository: Berri-AI/litellm
Branch names: ci-tmp-a351cc, ci-tmp-4d8517
Workflow file: .github/workflows/cache.yml, commit subject "ci: bump cache config"
Malicious package: LiteLLM 1.107.0 on PyPI, Docker Hub and GHCR

Vendor Response

PyPI quarantined the release and LiteLLM repointed the affected Docker Hub tags to verified clean images. LiteLLM says it is revoking every token associated with every internal system and vendor platform. The disclosure does not detail the behavior of the code inside 1.107.0, so the full downstream impact on environments that installed it is not yet public.

RedEye assessment — Three separate controls failed in sequence: secret revocation after a known leak, least privilege on an automation token, and release approval that had been loosened days earlier. Each one alone would likely have stopped this chain. AI gateways concentrate provider keys for an entire organization, which makes the secrets they hold and the pipelines that build them high-value targets. RedEye Security can assess your exposure to this incident and review how your CI/CD and AI tooling credentials are scoped.

Originally published on RedEye Threat Intelligence.

BlackX UEFI Bootkit Revives Baton Drop on Patched Windows Hosts That Skipped DBX Revocation

Etairos.ai — Fri, 23 Oct 2026 20:04:39 +0000

TL;DR

what: Kaspersky found BlackX, a BlackLotus-derived UEFI bootkit used against diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan and suspected to be APT41's work, exploiting CVE-2022-21894 to bypass Secure Boot.
impact: After the attacker gains admin rights, BlackX enrolls its own Machine Owner Keys, loads a signed kernel driver that tampers with endpoint security, and installs a RAT that uses Google Drive, OneDrive and Yandex.Disk for C2.
fix: Microsoft's full CVE-2022-21894 mitigation needs more than the update: the Windows Production PCA 2011 certificate also has to be on the Secure Boot Forbidden List (DBX), and that certificate's October 19, 2026 expiry does not stand in for the revocation.
who: Any Windows fleet that has the patch for CVE-2022-21894 but never applied Microsoft's Secure Boot revocation mitigations, with government and diplomatic organizations as the confirmed targets.

A suspected Chinese state group is defeating Secure Boot on Windows machines that pass patch compliance checks. Kaspersky has published research on BlackX, a UEFI bootkit used in early 2026 against diplomatic organizations in Tajikistan, Uzbekistan and Turkmenistan. Kaspersky suspects APT41. BlackX exploits CVE-2022-21894, the Baton Drop flaw that the BlackLotus bootkit made famous in 2023. Microsoft patched that bug years ago, but the patch on its own does not close it.

Fully fixing Baton Drop takes manual steps on top of the update. The key one is adding the "Windows Production PCA 2011" certificate to the Secure Boot Forbidden Signature Database (DBX). Kaspersky found that the attackers were relying on organizations skipping that step. The certificate expired on October 19, 2026, four days before this report. Expiry does not block the vulnerable boot binaries signed under it. Only a DBX entry does.

Why the Update Is Not the Fix

CVE-2022-21894 has a CVSS score of 4.4. Exploiting it requires administrator privileges or physical access. When BlackLotus surfaced, Microsoft called it "primarily a persistence and defense evasion mechanism" and said it was not an initial access vector. Many teams read a low score, a post-exploitation requirement and an installed update as a closed issue. Because the revocation step was separate and manual, it was easy to leave undone.

Kaspersky researchers Georgy Kucherin, Vladimir Nestor and Vasily Berdnikov said the actor "took into account that few organizations realized the importance of manually activating the Baton Drop patch" and chose to invest in rebuilding BlackLotus rather than developing a new exploit.

⚠️ Certificate expiry is not revocation — The Windows Production PCA 2011 certificate expired on October 19, 2026. Secure Boot will still load binaries signed under it unless the certificate is in DBX. A host can show the CVE-2022-21894 update as installed and still be fully exploitable by BlackX.

The Infection Chain

Kaspersky did not identify how the attackers got in. Once they had administrator rights on a target, they dropped two files and ran the installer from the command line.

inst.exe: the installer, run as C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1
PVMDIJGKAX2: an encrypted file with no extension that holds the files and strings the installer needs
Q46F6MDLI3RX2KV1: the RC4 key used to decrypt that file
The installer writes files to both the system partition and the UEFI partition, then exploits CVE-2022-21894 in a way Kaspersky calls "remarkably similar" to BlackLotus
The goal is to enroll attacker-controlled Machine Owner Keys (MOK), which lets the attacker load any EFI binary and undermines Secure Boot

The UEFI payload then injects a malicious driver into the Windows kernel. The driver was signed with a certificate issued to Wenjiang District Mingyu Network Technology Service Studio, which the issuer has since revoked. Like a bring-your-own-vulnerable-driver (BYOVD) attack, the driver tries to interfere with installed endpoint security software. Some of its tampering routines run only when Kaspersky or Avast products are present. Kaspersky's analysis found those routines do not work.

Two Espionage Payloads

The driver also drops a user-mode payload for espionage. Kaspersky observed two variants.

A remote access trojan that can load more .NET payloads, collect system information and upload files of interest. It uses Google Drive, OneDrive and Yandex.Disk for command and control, so its traffic looks like normal enterprise cloud storage use.
OxiDLLRunner, a malicious DLL sideloaded by a legitimate googleupdate.exe that the bootkit also delivers. It decrypts and runs a Rust payload that contacts archivetj[.]com to fetch and run more DLL plugins.

The cloud-storage C2 is the bigger detection problem. Blocking traffic to Google Drive or OneDrive is not realistic for most organizations. Spotting this RAT therefore depends on knowing which process is talking to those services, not on the destination.

An APT Rebuilding Crimeware

The BlackLotus source code has never been released publicly. That leaves two possibilities: the BlackX operators reverse-engineered the original bootkit, or they bought its source from someone else. Kaspersky noted that "we rarely see APT actors borrow ideas or code from cybercrime actors." BlackLotus was first advertised on criminal forums in late 2022, and ESET confirmed it in March 2023. More than three years later, a state-linked actor has turned the same technique into an espionage platform.

The APT41 Connection

The attribution draws on an ESET report from June 2026. That report covered FishMonger's use of the SprySOCKS Windows backdoor against government entities in Honduras, Taiwan, Thailand and Pakistan from 2023 to 2024. FishMonger, also tracked as Aquatic Panda and Earth Lusca, is assessed to operate under the APT41 umbrella. ESET found "limited indications" that some SprySOCKS versions include a UEFI bootkit component that likely exploits CVE-2023-24932, another BlackLotus-linked Secure Boot bypass. BlackX and the FishMonger kernel implant also share an "xdd" string. The attribution is still a suspicion, not a confirmed finding.

Indicators named in the report — Files: inst.exe and PVMDIJGKAX2 under C:\ProgramData\Intel. RC4 key: Q46F6MDLI3RX2KV1. Driver signer: Wenjiang District Mingyu Network Technology Service Studio (revoked). Sideload host: googleupdate.exe loading OxiDLLRunner. C2 domain: archivetj[.]com. C2 channels: Google Drive, OneDrive, Yandex.Disk.

RedEye Assessment

BlackX is a gap in remediation, not a new vulnerability. The vendor fix for CVE-2022-21894 has existed since 2022, and Microsoft's revocation guidance spells out the remaining step. The exposure comes from treating an installed update as the end of the job. Patch dashboards cannot see DBX contents, so they report these hosts as compliant.

Removing BlackX is also harder than removing ordinary malware. It runs before the operating system, enrolls its own keys and loads a kernel driver built to interfere with security tools. An EDR alert on the user-mode RAT does not show that the firmware is clean. Organizations in government, diplomacy and other sectors APT41 targets should assume this technique will spread beyond Central Asia. They should treat Secure Boot revocation status as a security control to verify, not a box ticked when the update was installed.

Originally published on RedEye Threat Intelligence.

Sandworm Wiper Attack in Ukraine Used MythicRatatoskr, a New Backdoor With C2 Inside the Yggdrasil Mesh Network

Etairos.ai — Fri, 23 Oct 2026 14:04:27 +0000

TL;DR

what: UAC-0099 broke into a Ukrainian logistics company on July 16, 2025, using spear-phishing, installed a new backdoor called MythicRatatoskr with its command server inside the Yggdrasil mesh network, and later handed access to Sandworm.
impact: On September 17, 2025, Sandworm wiped data across the environment by pushing the SDelete utility through Active Directory Group Policy.
fix: No CVE or vendor patch applies here, because the intrusion relied on phishing, normal admin tooling and an overlay network, so the defense depends on detection, not patching.
who: Organizations in Ukraine's government, energy, logistics and grain sectors are at most direct risk, along with any organization whose network allows outbound peer-to-peer overlay traffic without anyone noticing.

A Russian state-aligned intrusion into a Ukrainian logistics company ended with data wiped across the domain. The attackers had held access for 63 days before the wipe. ESET researchers Anton Cherepanov and Peter Strýček attribute the operation to two groups working in sequence. UAC-0099, also tracked as Earth Sirrush, got in, kept access and checked the target. Sandworm then ran the destructive phase. The most technically significant finding is a previously undocumented backdoor, MythicRatatoskr, whose command-and-control server sits inside the Yggdrasil mesh network. ESET says this is the first documented case of a state-aligned actor abusing Yggdrasil this way.

The Intrusion Timeline

The attack ran through four stages that ESET was able to date:

July 16, 2025: UAC-0099 gains initial access with a spear-phishing email carrying a malicious attachment. The attachment runs the MATCHBOIL downloader, which installs the MATCHWOK backdoor.
July 17, 2025: One day after MATCHWOK runs, UAC-0099 deploys MythicRatatoskr, a second backdoor that talks to its operators over Yggdrasil.
Between those dates and mid-September: MythicRatatoskr deploys a SOCKS5 server to route attacker connections through the compromised network, and UAC-0099 hands access to Sandworm.
September 17, 2025: Sandworm wipes data by distributing the Sysinternals SDelete utility through Active Directory Group Policy.

The two-backdoor setup matters. MATCHWOK was the first foothold. MythicRatatoskr gave a second, separate channel over infrastructure that conventional blocking struggles with. If defenders had found and removed MATCHWOK, the operators would still have had a way back in.

Why Yggdrasil Changes the C2 Picture

Yggdrasil is an experimental, end-to-end encrypted IPv6 overlay network. Nodes find each other through peering, and each node's address is derived from its cryptographic keys, not from an internet provider's allocation. To a defender, that removes most of the usual leverage against C2 servers. There is no domain to sinkhole, no registrar to contact and no hosting provider to send a takedown request to. The traffic that leaves the victim network goes to a Yggdrasil peer, not to the operator's server directly.

⚠️ ESET's assessment — "To our knowledge, this is the first documented case of Yggdrasil being abused in this way by a state-aligned threat actor, and it may signal a broader trend of adversaries adopting experimental peer-to-peer networks to increase the resilience and stealth of their infrastructure."

Some MythicRatatoskr samples wait 10 minutes after startup before connecting to Yggdrasil. ESET reads this as an attempt to avoid detection. Sandboxes often stop observing a sample after a few minutes, and a network connection made right after a new process starts on an endpoint is an easy behavioral signal to catch.

MythicRatatoskr Capabilities

ESET's analysis suggests development started sometime between December 2024 and February 2025. The feature set is simple but covers what operators need for hands-on-keyboard work and for moving traffic through a victim network:

Sends victim metadata to the C2 and polls for new commands
Returns command output, takes screenshots, uploads and downloads files
Changes the working directory and lists directory contents
Changes the C2 server URL at runtime
Runs shell commands through cmd.exe
Starts a reverse SOCKS5 proxy, which in this case turned the infected host into a relay into the internal network

The sample ESET investigated ran on Windows. However, the source code contains references to "crond", which suggests a Linux version may exist. ESET has not confirmed one. Linux servers and appliances should be treated as possible targets until the question is settled.

The Wipe: Built From Admin Tools

Sandworm did not need custom destructive code for the final stage. It pushed SDelete, a legitimate Microsoft Sysinternals tool for secure file deletion, to machines through Active Directory Group Policy. With domain-level control, a single GPO can reach every domain-joined machine at its next policy refresh. That is why the effect was so wide. ESET also notes that NikoWiper, a wiper previously linked to Sandworm, is itself based on SDelete, so this is a known pattern for the group and not a one-off.

Mitigation reality — No CVE, vendor patch or version upgrade addresses this campaign. Every stage used something that works as designed: email attachments, a peer-to-peer overlay network, a signed Microsoft utility and Group Policy. Mitigation therefore depends on spotting the behavior. That means outbound connections to Yggdrasil peers, unexpected SOCKS proxies on endpoints, new or changed GPOs that deploy executables, and SDelete running where it has no business reason to.

Access Brokering Between Russian Groups

The handoff from UAC-0099 to Sandworm fits a pattern ESET has already reported. Its APT Activity Report covering Q2 2025 to Q3 2025 described UAC-0099 carrying out initial access operations and passing "validated targets" to Sandworm for post-exploitation. Those targets were in Ukraine's government, energy, logistics and grain sectors.

Other Russia-aligned groups have worked together in the same way. ESET has documented Gamaredon and Turla compromising the same Ukrainian entities, including one intrusion in which Gamaredon's PteroGraphin was used to deploy Turla's Kazuar backdoor. Separately, Gamaredon's Pterodo downloader has been seen retrieving and running InvisiMole, a modular spyware tool used against targets in Ukraine and Russia.

For defenders, this division of labor changes how alerts should be prioritized. A UAC-0099 phishing foothold that looks like low-grade espionage may be the first stage of a destructive operation run by a different team weeks later. In this case the gap was more than two months. The detection window is there, but only if an early-stage alert is treated as a possible precursor to a wipe and not closed as routine.

RedEye Assessment

Three points matter beyond Ukraine. First, overlay networks like Yggdrasil are now confirmed as C2 transport for a state-aligned actor, and ESET explicitly flags a possible wider trend. Network monitoring built around domains, IP reputation and takedowns gives little visibility into this traffic. Second, the destructive stage used Group Policy and a signed Microsoft utility, so control of Active Directory was enough to carry out the wipe. Third, the 63-day gap between access and impact shows that access brokering between Russian groups is a working production model, not a theory. Organizations in logistics, energy, agriculture or government that support Ukraine, or that operate in the region, should assume they are in scope. RedEye's threat hunting and Active Directory assessments are built to find this kind of staged, low-noise access before it is handed to a destructive actor.

Originally published on RedEye Threat Intelligence.

CVE-2026-110264: Unauthenticated GitLab RCE (CVSS 10.0) Reaches Every Release Since 7.0

Etairos.ai — Thu, 22 Oct 2026 20:04:37 +0000

TL;DR

what: GitLab fixed CVE-2026-110264 on October 21, an integer overflow in its bundled Onigmo regular-expression engine that allows unauthenticated remote code execution.
impact: Every self-managed GitLab release since 7.0 (2014) is affected, including instances patched on October 12, and a compromised server exposes source code, CI/CD secrets and deploy credentials.
fix: GitLab released fixed versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, and lists no interim workaround.
who: Organizations running self-managed GitLab; GitLab.com and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later are already fixed.

On October 21, GitLab shipped fixes for CVE-2026-110264, a CVSS 10.0 flaw that lets an attacker run arbitrary code on a self-managed GitLab server without logging in. The bug affects every release since GitLab 7.0, which came out in 2014. That is about 12 years of installs, and it includes servers patched only nine days ago.

The October 12 update fixed a related regex flaw, but only in 19.2 and later. Each new fixed version sits one patch above the October 12 build for its branch, so an instance that updated on October 12 is vulnerable again.

What the Flaw Is

GitLab describes the bug as an integer overflow that happens when a specially crafted regular expression is compiled. Under certain conditions, it lets an unauthenticated user execute arbitrary code on the server. GitLab has not said what those conditions are.

The vulnerable component is Onigmo, the regular-expression engine built into Ruby. GitLab ships Onigmo inside its own packages and applies its own patches to it. A defect in that engine is present in every release that bundles it. That explains why the affected range goes all the way back to 7.0 instead of stopping at a recent feature change.

⚠️ No configuration rules you out — GitLab has not published what an attacker needs in order to reach the vulnerable compiler path, and its advisory offers no interim workaround. Until those details are public, administrators cannot clear an instance through configuration. The patched release is the only confirmed protection.

Fixed Versions

GitLab patched seven release branches at once:

19.5 before 19.5.1: fixed in 19.5.1
19.4 before 19.4.3: fixed in 19.4.3
19.3 before 19.3.6: fixed in 19.3.6
19.2 before 19.2.9: fixed in 19.2.9
19.1 before 19.1.9: fixed in 19.1.9
19.0 before 19.0.10: fixed in 19.0.10
7.0 through 18.11, before 18.11.13: fixed in 18.11.13

Four of those versions fall outside GitLab's normal support window. Its policy covers the current release and the previous two monthly releases, which today are 19.5, 19.4 and 19.3. GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 in addition to its standard releases, a step it reserves for severe issues. Any instance on a version from 7.0 through 18.11 is fixed in 18.11.13.

Only self-managed installations are exposed. GitLab.com already runs the fixed code. GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already have the fix.

Exploitation Status and Detection

GitLab reports no evidence that the flaw has been used in attacks. As of October 22, CVE-2026-110264 is not in the CISA Known Exploited Vulnerabilities catalog. That window may not last. The engine is open source, so the fix shows exactly where the overflow is, and this class of bug has now had four public patches in four weeks.

GitLab also published two detection rules for exploitation attempts: "Onigmo native worker crash" and "Org mode render error burst." Both are part of GitLab's open-source TLDR framework, which writes each detection in Sigma format against GitLab's own application logs. The name of the second rule suggests that rendering Org mode files is one route to the vulnerable compiler. GitLab has not confirmed that.

A Pattern, Not a One-Off

This is the fourth code-execution flaw in GitLab's regular-expression engine reported in about a month by the same researcher, who uses the handle joaxcar. It is the first of the four to reach versions before 19.2.

September 23: CVE-2026-93577 and CVE-2026-89078, both CVSS 9.9, both requiring a logged-in account.
October 12: CVE-2026-97229, CVSS 10.0, unauthenticated overflow in the regex compiler, fixed in 19.2.8, 19.3.5 and 19.4.2.
October 21: CVE-2026-110264, CVSS 10.0, unauthenticated, affecting every version back to 7.0.

When researchers focus on a single native component, the bugs tend to come in clusters. Four overflows in one bundled engine in four weeks points to more GitLab releases outside the normal schedule in the coming months. Change windows planned around GitLab's monthly cadence should expect that.

The Rest of the October 21 Release

The release fixes 11 security issues in total: one critical, with the rest rated high, medium or low. Two of the others concern authentication:

CVE-2026-15723, CVSS 8.2: a logged-in user could take over another account, but only when an administrator has turned on both SAML and LDAP auto-linking.
CVE-2026-112212, CVSS 7.5: cache poisoning in the OAuth and OpenID Connect endpoints could let an attacker redirect certain sign-in flows to a server they control, in deployments that use a shared cache.

Upgrade Cost

The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade. On a single-node server, that means downtime until they finish. GitLab says multi-node deployments can apply the patch without downtime by following its zero-downtime procedure. Teams on single-node instances will need to schedule a maintenance window, and that pressure grows with the CVSS score.

Why a GitLab server is a high-value target — A self-managed GitLab host usually holds source code, CI/CD variables, deploy keys, runner registration tokens and integration credentials for cloud and production systems. Unauthenticated code execution on that host is a direct path into every pipeline and environment it deploys to.

RedEye Assessment

CVE-2026-110264 is the most serious GitLab issue of the year so far. It needs no login, the vendor rates it at the maximum score, it reaches back 12 years of releases, and no workaround exists. It also cancels the protection that administrators thought they had after October 12. Every self-managed GitLab instance, including forgotten legacy servers from before 18.11, should be treated as exposed until it runs one of the seven fixed versions GitLab has named.

Originally published on RedEye Threat Intelligence.

Eight eMudhra Intermediate CA Keys Were Computable From Public Certificates: Browsers Blocked Them in Hours, Everything Else Needs Patches

Etairos.ai — Thu, 22 Oct 2026 14:04:24 +0000

TL;DR

what: The private keys for eight eMudhra emSign intermediate CA certificates were generated with too little randomness, so anyone could compute them from the public certificates.
impact: Anyone holding the keys could issue TLS certificates for any website, or code-signing certificates, that clients chaining to emSign ECC Root CA - G3 or the Sectigo cross-signs would accept.
fix: Chrome, Firefox, Apple, Microsoft and Android pushed blocks between October 17 and 20, and Go 1.27.3 and 1.26.10 (CVE-2026-111943), Firefox 158.0.1 (CVE-2026-113470), NSS 3.131.1, certifi 2026.10.19 and webpki-roots 1.0.10 remove or reject the affected trust.
who: Organizations running Go binaries, Python services on certifi, Rust services on webpki-roots, Apple devices trusting Sectigo AAA Certificate Services, and any client that does not check revocation.

Eight intermediate certificate authority keys belonging to eMudhra, the Indian CA that sells certificates under the emSign brand, are compromised. Mozilla and the Chrome Root Program confirmed it on October 20, 2026. The keys were not stolen. They were generated with so little randomness that anyone can compute them from the public certificates. Mozilla did exactly that within two hours of receiving the report, and researchers have since published all eight keys.

An intermediate CA signs the certificates that websites and software publishers present. Whoever holds one of these keys could issue a certificate for any domain that a client trusting the chain would accept. Six of the eight were TLS intermediates covering DV, OV and EV issuance. Two were code-signing intermediates. The weak keys have sat in public root stores since the April 2025 ceremony that created them, roughly 18 months. Whether anyone exploited them in that window is not known.

What Was Compromised

eMudhra said on October 21 that a flaw in its April 2025 key ceremony produced a second, weak set of keys alongside the intended ones, and that the weak set is what was published to browser root stores. The affected certificates, issued through eMudhra BV in the Netherlands and eMudhra Inc in the United States, are:

Domain validated TLS: EM DV TLS CA - G3B and EM DV TLS CA - G3C
Organization validated TLS: EM OV TLS CA - G3B and EM OV TLS CA - G3C
Extended validation TLS: EM EV TLS CA - G3B and EM EV TLS CA - G3C
Code signing: EM OV CS CA - G3B and EM OV CS CA - G3C

The six TLS intermediates were issued by emSign Root TLS CA - G3 and chain to emSign ECC Root CA - G3, which sits in the Chrome and Apple root stores and sat in Mozilla's until October 20. Each of the eight also exists as a second certificate carrying the same public key, cross-signed by Sectigo under its AAA Certificate Services root, according to a list published by Mozilla cryptography engineer Dennis Jackson.

How Fast the Browsers Moved

The researcher, credited by Mozilla only as Wayne, proved possession by signing the message "We have a problem here - Wayne" with each of the eight keys and sending it to the root programs on October 17. The response timeline:

October 17, 18:05 UTC: Chrome Root Program receives the report
October 17, 19:45 UTC: Chrome CRLSet update blocks the six TLS intermediates, 100 minutes after the report
October 17, 20:06 UTC: Mozilla receives the report
October 17, 22:59 UTC: Mozilla finishes pushing a OneCRL block to Firefox installs with standard settings
October 19: Apple blocks the certificates; other trust stores notified
October 19, about 22:00 UTC: Android devices receive an equivalent block through Google Play Services
October 20: Microsoft blocks the certificates; Go ships URGENT security releases

CRLSets and OneCRL are fetched by the browsers on their own schedule, so users needed no update or restart. Chrome's block matches the public key rather than the certificate, which also catches the Sectigo cross-signed copies. Chrome did not need to block the two code-signing intermediates because its TLS verifier will not build a path through an intermediate restricted to code signing. eMudhra has since revoked all eight.

Certificate Transparency limited the browser exposure — No TLS certificate chaining to the six web intermediates had been logged to Certificate Transparency before Chrome's block. Chrome and other browsers that require CT logging would not have trusted a forged certificate by default. Both Chrome and Firefox also stopped trusting Sectigo AAA Certificate Services for websites in April 2025, so the cross-signs did not widen browser risk.

Where the Exposure Remains

The CT protection and the pushed revocation lists cover browsers. They do not cover most of the software that runs inside an enterprise. Go binaries, Python applications using the certifi bundle, and many other TLS clients do not check revocation data and do not enforce CT. They keep trusting a chain until their code or their root bundle changes. A forged certificate never logged to CT would be accepted by those clients without complaint.

Apple is a second gap. Its root list for iOS 26 and macOS 26, published in December 2025, still includes Sectigo AAA Certificate Services, the root behind the cross-signed copies. Apple's October 19 block addresses the eight certificates, but it depends on devices receiving that update.

The two code-signing intermediates also fall outside the browser story entirely. A signing certificate issued from either key would carry an eMudhra chain into any platform that trusts it for code signing, and the browser CRLSet and OneCRL mechanisms do nothing for that path.

⚠️ Rebuilds, not just updates — Go embeds its fix in the standard library. Services compiled with earlier Go versions keep the old behavior until they are rebuilt with Go 1.27.3 or 1.26.10. Updating the toolchain on a build host does not protect binaries already deployed.

Vendor Fixes Released So Far

Mozilla's guidance for trust store operators is tiered: no action is needed where clients reliably check revocation and fail closed; where software can block individual intermediates, block the eight now; otherwise consider removing trust in the roots that signed them. Published fixes:

Go 1.27.3 and 1.26.10: rejects any chain containing one of the eight keys, CVE-2026-111943, released October 20, rebuild required
Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1: carries the OneCRL block for installs that cannot receive Remote Settings, CVE-2026-113470, released October 20
NSS 3.131.1: removes emSign ECC Root CA - G3 from the trusted list, released October 20
Python certifi 2026.10.19: drops emSign ECC Root CA - G3 from the bundle
Rust webpki-roots 1.0.10: drops emSign ECC Root CA - G3
Homebrew ca-certificates 2026-09-25_1: excludes emSign ECC Root CA - G3 and related emSign roots

Go handled its fix on the URGENT track, which its security policy reserves for threats to ecosystem integrity or flaws exploited in the wild. Neither the Go issue nor the release notes say which condition applied. The eight hash values in Go's code match the eight eMudhra certificates.

RedEye Assessment

This is a key generation failure, not an intrusion, and that makes it worse in one respect: there is no attacker dwell time to bound. The keys were derivable by anyone from the day the certificates were published. Mozilla says it does not currently believe other CAs are affected, and Chrome says it checked every other CA certificate in its store and "found no other instances of this failure mode."

The browser response was fast and effective. The residual risk sits in server-side and embedded TLS clients that rely on static root bundles, in unrebuilt Go services, in Apple devices that trust the Sectigo cross-sign root, and in code-signing trust. Those are the places a forged certificate from these keys would still work, and they are the inventory most organizations know least about. RedEye can assess where your environment depends on static trust stores and which deployed services still carry the affected roots.

Originally published on RedEye Threat Intelligence.

PHP2Shell: Two Critical PHP Runtime Flaws Give Unauthenticated Attackers Code Execution

Etairos.ai — Wed, 21 Oct 2026 20:04:39 +0000

TL;DR

what: PHP released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP runtime collectively named PHP2Shell, a day after details leaked ahead of planned disclosure.
impact: An unauthenticated attacker can achieve remote code execution, with a single-request exploit demonstrated on Apache mod_php, and can read worker memory holding passwords, tokens, API keys and certificates from other requests.
fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both flaws, source backports exist for 7.4, 8.0 and 8.1, and the PHP team states that only updating fully protects a server.
who: Every PHP installation serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, regardless of how secure the application code is.

PHP has shipped emergency updates for two critical flaws in the language runtime that let an attacker with no account execute code on a web server. Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell, both carry a CVSS v4.0 score of 9.2 and affect nearly every PHP version back to PHP 5.4. Because the bugs live in the engine, not in application code, a server is exposed even if the site running on it is flawless. A plain "Hello World" page on a vulnerable PHP build is enough of a target.

The fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 around 14:00 UTC on October 21, 2026. That release came a day after technical details leaked ahead of a coordinated disclosure planned for October 22. Researchers at Wiz, Calif and OpenAI found and reported the flaws. Cloudflare reported early exploit attempts before the patch shipped.

What PHP2Shell Does

The PHP security advisory lists every web-facing deployment model as affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Exposure differs by server API.

Apache mod_php is the highest-risk configuration. Researchers demonstrated an exploit where a single unauthenticated request triggers the attack before any application code runs.
PHP-FPM shuts the worker down when a request fails early in setup, which changes the picture. For one flaw, PHP's analysis supports that FPM is susceptible, but no complete FPM exploit has been shown.
The second flaw was shown to reach code execution on both mod_php and PHP-FPM, though the FPM path depends on an operation inside the running application.
Separately from code execution, an attacker can read memory from the PHP worker process. That memory can hold passwords, authentication tokens, API keys and certificates belonging to other users' requests.

The memory disclosure deserves equal weight with the RCE. The researchers demonstrated reading live worker memory against applications they did not control, meaning the technique does not depend on the application stack above PHP. A server that never yields a shell can still leak session tokens and secrets from concurrent traffic.

⚠️ Application updates do not fix this — Updating WordPress, Laravel or any other framework does not touch the PHP runtime beneath it. The runtime comes from the server package, the hosting provider or the container image, and that is the layer that must change. The PHP team states plainly that only updating the runtime fully protects a server.

The Patch and Branch Status

Fixed versions per supported branch are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below those numbers on the respective branch is vulnerable. PHP 8.1 and older no longer receive official releases, and PHP 8.2 reaches end of life on December 31, 2026. For the unsupported branches, the PHP security team published source backports for PHP 7.4, 8.0 and 8.1 aimed at teams building from source or waiting on a vendor.

Linux distributions and long-term-support vendors received the patches in advance. A distribution package can therefore carry the fix under a version string that looks old. Debian advises confirming the CVE in the package changelog rather than trusting the version number. This matters for inventory: version-based scanners will flag patched distro packages as vulnerable and may miss unpatched custom builds.

The fix also introduces a new hard memory limit. Hitting it terminates the process and prevents shutdown handlers from running, so applications with heavy memory use or cleanup logic in shutdown handlers may behave differently after the update.

Interim Mitigations Are Partial

The advisory lists configuration changes that reduce exposure to specific attack paths while stating they do not make a server safe. For CVE-2026-109618, the advisory covers memory_limit, post_max_size and request-size limits at the web server or proxy, and warns that RLIMIT_AS and RLIMIT_DATA can trigger the same vulnerable path and are not substitutes. For CVE-2026-109619, it covers disabling session.upload_progress.enabled, plus fatal_error_backtraces on PHP 8.5.

The session upload progress setting is the workaround that circulated before the patch, and the release confirms it was never a complete fix. Upload progress is on by default and can reach session handling before PHP finishes setting up a request, which is why it participates in one confirmed path for CVE-2026-109619. Disabling it blocks the confirmed session paths but not other variants, and does nothing for CVE-2026-109618.

"The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much," PHP core developer Gina Peter Banyard wrote before the release, responding to a suggestion that the setting might suffice.

Exploitation Status

Cloudflare CTO Dane Knecht said the company was seeing early attacks and updating its firewall mitigations as new vectors appeared, while calling those rules a stopgap and urging administrators to patch. No source has confirmed a successful compromise. watchTowr, which reproduced CVE-2026-109618, reported no in-the-wild exploitation as of 11:26 UTC on October 21, and neither CVE was in CISA's Known Exploited Vulnerabilities catalog at that time.

Several organizations pulled services offline as a precaution. BambooHR took its service down across the United States, Canada and Ireland, warned that payroll would be interrupted, and had no restoration time. In the Netherlands, NOS reported that MijnOverheid, DigiD, the lower house of parliament's site, the national cyber-security center and several education systems went offline.

Indicators the researchers flagged — For servers that may have been hit before patching, the researchers point to unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, abnormally large PHPSESSID response cookies, and unexplained PHP worker restarts.

RedEye Assessment

PHP2Shell is a runtime-level bug with a public leak, a 9.2 score, a one-request exploit on mod_php and confirmed scanning activity. That combination usually shortens the gap between disclosure and mass exploitation to days. The memory disclosure path widens the blast radius beyond RCE: any credential or token that passed through a vulnerable worker should be treated as potentially exposed. The hardest assets to find will be the ones nobody tracks: legacy PHP 7.x hosts, vendor appliances with embedded PHP, and container images built months ago. Organizations that cannot quickly answer which PHP runtimes they run, and which of those are internet-facing, are the ones most at risk this week.

Originally published on RedEye Threat Intelligence.

ClickFix Crew Weaponizes Signed Siemens Software Center Binary to Sideload RAT (CVE-2026-110936)

Etairos.ai — Wed, 21 Oct 2026 14:04:21 +0000

TL;DR

what: Siemens patched CVE-2026-110936, a DLL sideloading flaw in Siemens Software Center, after confirming that ClickFix operators abused a signed copy of the application to load a malicious archive.dll.
impact: A victim who pastes a ClickFix lure command ends up running PowerShell that drops an MSI, which launches the trusted Siemens binary and executes attacker code that installs a remote access trojan.
fix: Siemens fixed the flaw in Siemens Software Center 4.0.9.8, says the application must be started to apply the update, and recommends blocking the published IP addresses and domain.
who: Any Windows user reachable by ClickFix lures is at risk whether or not Siemens software is installed, and organizations running Siemens Software Center 3.5.8.7 or earlier also carry the local privilege-context exposure.

A signed, trusted Siemens binary is being used as the launch vehicle for a remote access trojan. Siemens confirmed on October 20, 2026 that threat actors running ClickFix campaigns abused a genuine copy of Siemens Software Center, complete with a valid digital signature, and placed a crafted DLL named archive.dll next to it. When the Siemens executable started, it loaded the attacker's DLL from its own folder without checking it, and the malicious code ran under the cover of a legitimate industrial vendor's software.

The underlying weakness is tracked as CVE-2026-110936, rated 8.4 on CVSS v4. Siemens has fixed it in Siemens Software Center 4.0.9.8. Huntress Labs researcher Jose Oregon is credited with finding and reporting the flaw.

The Vulnerability: Uncontrolled DLL Search Path

Siemens describes the flaw as a classic uncontrolled search path issue. In the advisory, the vendor states that the application loads dynamic-link libraries from an uncontrolled search path, which could allow an authenticated local attacker to place a specially crafted DLL in a directory the application searches, leading to arbitrary code execution with the privileges of the affected application.

In a separate alert, Siemens explained why attackers picked this program. It is signed and trusted, and version 3.5.8.7, the latest release at the time of the campaign, loaded helper files from its own folder without verifying them. That combination is ideal for DLL sideloading: security tooling sees a reputable, signed Siemens process, while the code actually executing belongs to the attacker.

⚠️ Siemens software does not need to be installed — In the observed campaigns, attackers delivered their own signed copy of SiemensSoftwareCenter.exe alongside the malicious archive.dll. Any Windows endpoint reachable by a ClickFix lure is exposed to this chain, not only engineering workstations that already run Siemens tooling. Allowlisting decisions that trust Siemens-signed binaries by publisher alone are the weak point here.

The Attack Chain

Huntress and Siemens together describe a multi-stage intrusion that starts with social engineering and ends with persistent remote access:

Lure: some campaigns used malicious ChatGPT Custom GPTs to steer victims to a fake URL hosting a ClickFix page.
ClickFix: the page instructs the victim to copy and execute a command, which runs PowerShell code on the host.
Installer: the PowerShell stage drops an MSI package, and msiexec.exe launches AllMyBasic.msi.
Sideload: the MSI executes SiemensSoftwareCenter.exe, which loads the attacker-supplied archive.dll from its own directory.
Payload: the sideloaded code deploys a remote access trojan.

The use of Custom GPTs as the first hop is notable. Users who trust output from an AI assistant are less likely to question a link it provides, and the ClickFix step then turns that trust into user-initiated code execution, which sidesteps many email and attachment controls entirely.

Attribution: The Romulus ClickFix Platform

The activity has been attributed to Romulus, a ClickFix delivery platform that Forescout documented the week before Siemens' disclosure. Forescout reported Romulus being used to deliver Legion Loader and other malware families, with DLL sideloading as a recurring technique. The Siemens Software Center abuse fits that pattern: Romulus operators appear to rotate signed carrier binaries that will load an adjacent DLL, and the Siemens executable was one such carrier.

Platform-style delivery matters for defenders. A shared ClickFix service means the same lure infrastructure and loading tradecraft can push different final payloads for different customers, so the RAT seen today is not a reliable predictor of what the next wave delivers.

Why This Lands in the ICS/OT Lane

Siemens software is a fixture in industrial environments, and Siemens-signed processes are often treated as expected, low-risk activity on engineering and operations hosts. Attackers exploit exactly that expectation. A RAT running behind a Siemens process name and signature on a workstation that bridges IT and OT networks is harder to spot and more valuable to an intruder than the same implant on a generic office laptop.

The source reporting does not describe any confirmed impact on control systems, PLCs or industrial processes. The documented outcome is remote access to compromised Windows endpoints. The risk to OT is indirect: what an operator does with that foothold if the compromised machine has a route into plant networks.

Indicators of Compromise

Siemens published the following network indicators (defanged):

96.62.218[.]59: payload hosting and command-and-control
wizardexpensive[.]com: payload hosting and command-and-control
2.27.248[.]127: distribution channel for AllMyBasic.msi

Siemens also identified a host-level behavioral marker: SiemensSoftwareCenter.exe running from an AppData\Local\Programs path with msiexec.exe as the parent process. A legitimate installation launched by a user or an update mechanism would not normally present that parent and path combination, which makes it a strong signal for this campaign.

Vendor Fix and Mitigation

Siemens addressed CVE-2026-110936 in Siemens Software Center version 4.0.9.8. Per the vendor, the update is applied when the application is started after updating, so a host that has downloaded the fix but never relaunched the application may still be running vulnerable code. Siemens additionally recommends blocking the IP addresses and domain listed above and hunting for the msiexec.exe to SiemensSoftwareCenter.exe execution pattern from AppData\Local\Programs.

Patching closes one carrier, not the technique — Version 4.0.9.8 fixes the search path flaw in new installs and updated hosts. It does not stop an attacker from delivering an older, still validly signed 3.5.8.7 binary alongside a malicious DLL, as was done in these campaigns. Detection on process lineage and execution path, plus controls against ClickFix-style paste-and-run behavior, remain necessary after the patch.

RedEye Assessment

This campaign combines three trends that keep producing results for attackers: ClickFix lures that make the victim run the payload, AI assistant abuse as a trusted first touch, and signed vendor binaries used as sideloading carriers. The Siemens patch fixes the immediate flaw, but older signed builds remain usable as carriers for as long as their signatures are trusted. Organizations with Siemens tooling on engineering workstations, or with allowlisting policies that trust industrial vendor signatures by default, should verify whether this chain could execute and go unnoticed in their environment. RedEye Security can assess exposure to the Romulus tradecraft and the published indicators across IT and OT endpoints.

Originally published on RedEye Threat Intelligence.

APT28 Breaches NATO Naval Shipbuilder With HOOKEDGE, a Persistent SSH Tunnel and a New Reflective Loader

Etairos.ai — Tue, 20 Oct 2026 14:04:21 +0000

TL;DR

what: APT28, tracked by Symantec as Swallowtail, used new HOOKEDGE backdoor variants and an undocumented reflective loader against defense and law enforcement targets in two NATO countries.
impact: At a naval shipbuilder the attackers held hands-on-keyboard access for a week, captured NTLM credentials, planted an SSH key and opened a persistent tunnel from their infrastructure into the internal network.
fix: No single patch closes this campaign; the HOOKEDGE chain starts with macro-enabled Word documents, and APT28's related operations exploit CVE-2026-21509 in Microsoft Office and CVE-2026-8496 in SOGo webmail, both of which have vendor fixes.
who: Defense manufacturers, shipbuilders, aerospace suppliers, law enforcement and government bodies in NATO countries, plus anyone in their supply chains.

Russia's GRU-linked APT28 (also tracked as Fancy Bear, BlueDelta and Forest Blizzard) has breached a naval shipbuilder in a NATO member state and stayed active inside its network for at least two months. The Symantec Threat Hunter Team, which tracks the activity as Swallowtail, says the same campaign hit a military aircraft engine manufacturer and a law enforcement agency across two NATO countries. These are organizations whose design data, contracts and investigative records are worth a lot to a foreign intelligence service.

What sets this report apart is what happened after the attackers got in. Earlier public reporting on this campaign stopped at delivery. Symantec documents hands-on-keyboard activity over a full week, two independent credential theft techniques, a persistent SSH tunnel into the internal network and a reflective loader nobody had documented before.

HOOKEDGE: A Batch Script Backdoor Hiding Behind a Browser

Recorded Future's Insikt Group first described HOOKEDGE in late August 2026, linking it to APT28 attacks on government and diplomatic targets in Romania, Spain and Türkiye between September 2025 and early April 2026. HOOKEDGE shares a lot of code and tradecraft with HEADLACE, a modular Windows implant APT28 has used against diplomats since April 2023.

The backdoor itself is minimal. It is a Windows batch script delivered through macro-enabled Microsoft Word documents attached to spear-phishing emails. It takes attacker commands and sends the output back. The original variants ran all command and control through a webhook[.]site URL, a legitimate request-capture service, and pulled tasks with a hidden, off-screen Microsoft Edge instance instead of a conventional downloader. To network monitoring, that traffic looks like a browser talking to a public web service.

Infrastructure shift — In the late July 2026 shipbuilder intrusion, the new HOOKEDGE variants dropped webhook[.]site and used a dedicated IP address, 185.82.218[.]119 on port 443, for both tasking and exfiltration. Detections built only around webhook[.]site traffic will miss these variants.

Inside the Shipbuilder: A Week of Hands-On Operations

Symantec says operators came back to one compromised host again and again over the course of a week. That points to a human operator working toward a goal, not an automated implant running a script. The post-compromise chain had four parts.

SSH key planting and reverse tunnel: the attackers pushed an SSH private key onto the host and immediately used it to connect back to their own server, asking for a persistent, backgrounded tunnel. That gave them a route from their infrastructure straight into the internal network, independent of the HOOKEDGE channel.
NTLM capture over loopback: a short, self-contained PowerShell script started a listener on the host's own loopback address and forced the machine to authenticate to it, capturing the resulting NTLM handshake. Captured NTLM material can be cracked offline or relayed to move laterally.
Loader delivery over SSH: using curl through the SSH session, the attackers dropped ld.exe, a reflective loader that decrypts and runs an encrypted payload in memory using a key supplied at runtime.
Continued presence: the latest activity Symantec saw was on September 24, 2026, when a Visual Basic Script launcher tied to HOOKEDGE showed up on the shipbuilder's network, roughly two months after the July intrusion.

Because the decryption key arrives at runtime, the payload sitting on disk is useless for analysis without it. That is why Symantec could not identify the next-stage component ld.exe was built to run. It is also unclear whether any data left the network.

⚠️ Why the tunnel matters — A persistent reverse SSH tunnel turns one infected workstation into a standing entry point. Even if the HOOKEDGE script is found and removed, the tunnel and the stolen credentials can keep the attackers inside. Cleanup that only targets the initial implant will leave them with access.

The Broader APT28 Picture: Ukraine and Webmail

The shipbuilder intrusion fits a wider pattern. In a report published late last month, CERT-UA said APT28 has been exploiting CVE-2026-21509, a security feature bypass in Microsoft Office, to deliver the COVENANT malware. It has also exploited CVE-2026-8496, a zero-click flaw in the SOGo webmail client, to steal mailbox credentials and data. CERT-UA added that the group is still using cross-site scripting bugs in Roundcube webmail, describing the older techniques as tried and tested and still effective.

CERT-UA also reported that Russian operators are increasingly going after smartphones belonging to Ukrainian military personnel and officials. That includes the DarkSword iOS exploit kit, served through watering-hole attacks on compromised Ukrainian news and government sites. Google Threat Intelligence Group tied DarkSword and the Coruna kit to the Russian espionage actor UNC6353 in March 2026. On Android, the clusters UAC-0244 and UAC-0263 use decoy apps to deliver CAMELSPY, which collects location, contacts, call logs, SIM details and photos, and BTMOB RAT, which gives full device control.

Assessment: Defense Supply Chains Are the Target

The targets picked here (a naval shipbuilder, a military engine manufacturer and a law enforcement agency) line up with collection priorities around NATO naval and air capability. These are often mid-sized industrial companies with corporate IT built for manufacturing, not for resisting a state intelligence service that is prepared to spend a week on one host.

The tradecraft is cheap and hard to spot. The initial implant is a batch script. Command and control first rode a legitimate web service and then a single IP on port 443. Credential theft used built-in PowerShell and native NTLM behavior. Persistence came from standard SSH. None of it needs a zero-day, and every step blends into normal administrative traffic. The only custom component, ld.exe, keeps its payload encrypted until the operator supplies the key.

On mitigation, the vendor fixes that apply are the Microsoft patch for CVE-2026-21509 and the SOGo fix for CVE-2026-8496, both exploited in APT28's parallel operations. The HOOKEDGE chain in this report does not rely on a software vulnerability. It relies on a user enabling macros in a Word document, so it falls under Office macro policy and email controls rather than patching. Symantec's report is the main source for indicators, including the 185.82.218[.]119 infrastructure. Organizations in the defense industrial base should assume this activity is still going on, since the most recent sighting was less than a month ago.

Originally published on RedEye Threat Intelligence.

Rank Math PRO Update Channel Hijacked: 11-Hour Window Delivered a Self-Restoring WordPress Backdoor

Etairos.ai — Mon, 19 Oct 2026 20:04:23 +0000

TL;DR

what: Rank Math PRO copies served from rankmath.com, by direct download and by update, between 20:02 UTC on October 15 and 07:12 UTC on October 16 contained malware that installs a self-restoring backdoor.
impact: Any site that installed and activated an affected copy should be treated as fully compromised: it may have rogue administrator accounts, extra PHP backdoors, cron and SSH persistence, and every reachable secret may be exposed.
fix: Rank Math removed the malicious files and released 3.0.124, tracked as CVE-2026-111862, but the update does not clean up files, accounts or scheduled tasks the malware already created, so the vendor recommends restoring from a backup taken before the window and rotating every credential.
who: WordPress sites running the paid Rank Math PRO plugin that pulled 3.0.123 from rankmath.com during the window; the free WordPress.org plugin with more than 4 million installs is not named in the notice.

For 11 hours and 10 minutes, the official distribution channel for Rank Math PRO, the paid version of one of the most widely used SEO plugins for WordPress, delivered malware. Rank Math said in a security notice on October 16 that copies downloaded from rankmath.com or delivered as updates between 20:02 UTC on October 15 and 07:12 UTC on October 16 were malicious. Any site that installed and activated one of those copies should be treated as compromised. The malware plants a hidden backdoor that rebuilds itself whenever someone visits the site.

Wordfence assigned the incident CVE-2026-111862 and scored it 9.8 out of 10. Patchstack classifies it as a backdoor and notes that because the attack happened on Rank Math's own systems, "a rule is not possible for mitigation." No virtual patch or WAF signature stops a payload that arrives through the vendor's signed update path.

Why the Version Number Does Not Tell You If You Are Affected

The malicious copies carried version 3.0.123, but that version number alone does not mean a site is infected. Rank Math's changelog dates 3.0.123 to October 7, more than a week before the window opened. A copy of 3.0.123 obtained before 20:02 UTC on October 15 is clean. What matters is when the file was pulled, not the version string it reports.

Rank Math's notice sorts sites into three cases:

Installed and activated during the window: treat the site as compromised, even if it has since moved to 3.0.124.
Installed but never activated: Rank Math advises removing the plugin files, installing 3.0.124 from the customer account and scanning the site.
Downloaded but never installed or activated: nothing in this incident alone indicates compromise.

The notice covers only the PRO plugin, which customers get from rankmath.com rather than WordPress.org. The free Rank Math SEO plugin on WordPress.org, with more than 4 million active installations and a last update on October 6, is not named. Rank Math has emailed some affected users.

⚠️ Updating is not remediation — Installing 3.0.124 replaces the plugin folder. Wordfence's October 17 advisory says it does not remove files, administrator accounts or scheduled tasks the malware may already have placed elsewhere on the server. Rank Math also states that deactivating the plugin alone is not enough. A site that ran the malicious build and was simply updated is still compromised.

What the Malware Does

Everything known about the payload comes from Rank Math's notice. Neither Rank Math nor Wordfence has published a code analysis, and neither names an attacker. The notice describes a backdoor that is rebuilt by code triggered on site visits, so removing visible files while the rebuild trigger stays active may not fix anything. According to Rank Math, the attacker may also have:

Dropped PHP backdoors into other plugins' folders, theme folders, the must-use plugins directory and uploads.
Created administrator accounts with usernames beginning wpsupport_ or email addresses ending in @wp-mail[.]net.
Added a fake core file, wp-includes/class-wp-cache-util.php, which is not part of WordPress.
Modified .htaccess so .cache files run as PHP, and planted .cache files containing PHP code.
Added WordPress scheduled events, crontab entries tagged #ms6v46, and SSH authorized_keys entries.
Communicated with the domain rank1cdn[.]com.

Rank Math also lists code traits: PHP using base64_decode with XOR loops, the key xmmqhn, proc_open calls, and PHP-FPM socket code. Three wp_options entries are tied to the malware: _uf6qdn2hmm, t8krdk990phb and _np5pvf754c. proc_open and PHP-FPM socket access mean the payload can run commands at the OS level, which is why the vendor tells owners to check crontabs for other users, running processes and any writable location outside the web root.

Indicators of Compromise

Network: rank1cdn[.]com
Database: wp_options rows _uf6qdn2hmm, t8krdk990phb, _np5pvf754c
File: wp-includes/class-wp-cache-util.php
Accounts: wpsupport_* administrators, @wp-mail[.]net addresses
Persistence: crontab tag #ms6v46, .htaccess rules executing .cache as PHP, new SSH authorized_keys
Code: XOR key xmmqhn, base64_decode with XOR loops, proc_open

Wordfence adds a caveat: "Their absence does not, by itself, prove that a website is clean." These are the indicators that have been published so far, not a full list.

Credential Exposure Is the Bigger Problem

Rank Math says owners should assume any secret the site could reach was exposed. That includes WordPress passwords, the database credentials and the security keys and salts in wp-config.php, payment gateway and SMTP keys, other API keys, hosting panel, FTP, SFTP and SSH access, and secrets stored in environment variables. On WooCommerce or membership sites, payment gateway keys are a direct path to financial fraud. The vendor's guidance requires rotating credentials even after a clean restore, because restoring files does nothing about secrets that have already been stolen.

Vendor Remediation Guidance

Rank Math's preferred path is to restore from a site and database backup taken before 20:02 UTC on October 15, rotate all credentials, and only then install 3.0.124, downloaded by logging in at rankmath.com directly. Without a clean backup, the vendor lays out a manual cleanup in a fixed order: remove the plugin folder, purge the three wp_options entries and block egress to rank1cdn[.]com, and only after that hunt for the other changes. The order matters because of the self-restoring trigger.

Integrity checking has a gap — WordPress.org publishes no checksums for Rank Math PRO. The Hacker News checked the plugin-checksums service on October 19 and found none under either of the plugin's names, though checksums exist for the free plugin. Comparing against a clean copy from rankmath.com is the fallback. Rank Math says it will never send login or download links by email, and some customers may need to reset their account password to log in.

What Rank Math Has Not Disclosed

Rank Math is part of the Swedish hosting group group.one. It has not said how the malicious files got into its download and update system, how many customers received one, or who is responsible. Without a root cause, customers cannot judge whether the vendor's build and release pipeline is now secure. The case follows a familiar pattern: commercial WordPress plugins update outside the WordPress.org review and checksum system, so a compromised vendor server can reach every paying customer with no independent check in between.

RedEye Assessment

This is a full-site compromise delivered through a trusted channel, and it comes with OS-level execution and multiple persistence layers. Organizations running Rank Math PRO need to establish whether they pulled the plugin during the 11-hour window, treat any affected site as breached, and look beyond WordPress to the hosting account, the database and every integration the site touches. If you need help scoping exposure, validating cleanup or rotating credentials across connected systems, contact RedEye Security for an incident assessment.

Originally published on RedEye Threat Intelligence.