DEV Community: Strongthium Labs

Trojanized Claude Code update on Cursor: cleanup and prevention

Strongthium Labs — Sat, 31 Oct 2026 17:59:23 +0000

For about half a day on October 29, 2026, anyone who installed or auto-updated Claude Code from Cursor's extension marketplace could have received a build that planted an SSH backdoor. The package carried the genuine extension identifier, anthropic.claude-code, and arrived as an ordinary update. The live part of the attack has been shut down, but what it left on disk is still there until someone removes it. This article lays out what is known, where the reports disagree, how to clean up an affected machine, and what to change so the next tampered update does less damage.

What happened

According to The Hacker News, the tampered package identified itself as anthropic.claude-code version 2.1.313. Jenn Gile of OpenSourceMalware told the publication that its main JavaScript bundle held "a malicious 66-line loader inserted before the legitimate extension code." Cursor took its marketplace offline for a while to remove the package. It says at most 5,000 users installed the bad version, between about 2:27 a.m. and 1:35 p.m. Pacific time, and that it will contact them directly.

Nobody has said publicly how the attacker got the access to publish under Anthropic's name on Cursor's marketplace. The two companies describe their roles differently, and both accounts can be true at once:

Cursor says the malicious version "was not developed by Anthropic" and that no other extension on its marketplace was altered. It reports that it rotated its keys, rebuilt the marketplace and had the attacker's server taken offline with the cloud provider.
Anthropic says its own systems and employee laptops were not compromised. As The Hacker News reports its statement, an attacker used access to Cursor's marketplace to publish the tampered build, and the official channels were not affected.
The Hacker News argues that Cursor's wording "misses the point": the code did not come from Anthropic, but users got it under Anthropic's real extension ID, not as a look-alike, so the name told them nothing.

Other distribution channels appear clean. The Hacker News cites Socket, which found no sign that 2.1.313 was ever publicly available on Open VSX or npm. It also cites Microsoft, which confirmed the version was never published on the Visual Studio Marketplace or in the anthropic-ai/claude-code npm package. The same article first reported that Open VSX was compromised and later corrected that. For scale, the Visual Studio Marketplace listing shows more than 29 million installs under the Anthropic publisher. The Hacker News gives 2.1.314 as the current clean release on the official channels.

Where the reports disagree

The two news accounts, from The Hacker News and Cyber Security News, differ on several details. Where they do, the safer choice is to assume the wider scope.

Detail	The Hacker News	Cyber Security News
Affected versions	2.1.313	2.1.312 and 2.1.313, per Cursor's notice as updated on October 30
Time available	"close to 12 hours," in Anthropic's account	11 hours and 8 minutes
Platforms	Attempts on Windows, Linux and macOS, with a crontab for persistence on Linux	Aimed at Windows and macOS users

Cyber Security News based its version list on Cursor's revised notice, so treat both 2.1.312 and 2.1.313 as bad. Check Linux machines too.

What the loader did

The two reports agree on how the loader worked. It ran when the extension loaded (The Hacker News says after editor startup and when the extension's webview opens) and then did the following:

It added an attacker-controlled public key to ~/.ssh/authorized_keys, labeled svc-telemetry so that it looks routine.
It tried to turn on the machine's SSH server.
It opened a reverse SSH tunnel to 134.209.82[.]225, which would let the attacker's server reach back into the victim's own SSH service.
It installed persistence. Cyber Security News names a macOS LaunchAgent called com.apple.sysmond and, on Windows, a scheduled task named SysMon running as SYSTEM, with a script in the Startup folder as a fallback. Background scripts retried the connection about every 60 seconds.
It sent an unencrypted HTTP POST to port 8099 at /beacon. The report contained the public IP address (looked up through api.ipify[.]org), the hostname and username, the OS and CPU architecture, the home and working directories, the global Git email, and the names of up to 40 environment variables containing strings such as KEY, TOKEN, SECRET, PASS, AWS or GCP.

The beacon sent variable names, not their values. Researcher Paul McCarty notes that the names still reveal which cloud providers and credential types a machine uses, and that working SSH access would let the operator look at the account directly. No follow-on payloads have been observed.

How far the loader got depends on the host. As The Hacker News quotes Cursor, turning on the SSH service requires admin rights, which the extension lacks on most macOS and Windows hosts. On those machines the attacker "could not have logged in through the tunnel." Cyber Security News adds that bugs in the malicious code also got in the way. Neither limit stopped the key, the persistence or the beacon. On a Linux workstation that already runs an SSH server, the admin-rights obstacle may not apply at all.

Finding out whether you are affected

A machine is in scope if it ran Cursor with Claude Code installed during the October 29 window, especially with automatic extension updates on. In the Extensions view, check the version that was installed then, not only the current one. The Claude Code VS Code documentation says the extension's version number matches the Claude Code version it bundles. The same page explains that running claude in an editor's integrated terminal reinstalls the extension automatically. A developer may therefore have the extension without ever installing it on purpose, so ask about the CLI as well as the extension.

Then look for the indicators. Cursor's published list, as summarized by Cyber Security News, contains the address 134.209.82[.]225, SSH connections on TCP port 22, HTTP POSTs to port 8099 at /beacon, and the svc-telemetry key. Search firewall, proxy and endpoint logs for that address from the morning of October 29 onward.

Cleaning up an affected machine

Microsoft's research team, quoted by The Hacker News, makes the central point: "Removing or updating the extension does not remove artifacts written outside its installation directory." Updating to a clean version is necessary, but it does not clean anything up. Work through these steps in order.

Preserve evidence before you change anything: copy the authorized_keys files, export the scheduled task, and keep copies of the LaunchAgent, crontab and any unfamiliar startup scripts.
Isolate the host from the network if it shows signs that the payload ran.
Remove the artifacts: the key, the persistence entries, and the SSH service if you did not turn it on yourself.
Update the extension to a clean release from the official channel.
Rotate credentials and revoke sessions from a different, trusted machine.
Decide whether to rebuild. Cyber Security News says Cursor advises assessing whether affected machines need a fresh install. If you can't account for everything the machine did during the window, rebuilding is the conservative choice.

On Windows, these PowerShell commands check the known locations. Run them as an administrator so that the system-wide key file and the SYSTEM task are visible.

# Keys the loader may have added
Select-String -Path "$env:USERPROFILE\.ssh\authorized_keys" -Pattern 'svc-telemetry'
Select-String -Path "$env:ProgramData\ssh\administrators_authorized_keys" -Pattern 'svc-telemetry' -ErrorAction SilentlyContinue

# Persistence: the scheduled task (export it before deleting) and the Startup folder
Export-ScheduledTask -TaskName 'SysMon' -ErrorAction SilentlyContinue | Out-File sysmon-task.xml
Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

# Was the OpenSSH server installed or started? Any live connection to the address?
Get-Service sshd -ErrorAction SilentlyContinue
Get-NetTCPConnection -RemoteAddress 134.209.82.225 -ErrorAction SilentlyContinue

On macOS and Linux:

grep -n 'svc-telemetry' ~/.ssh/authorized_keys
ls -l ~/Library/LaunchAgents/ | grep -i sysmond   # macOS
launchctl list | grep -i sysmond                  # macOS
crontab -l                                        # Linux and macOS: look for entries you did not add

Delete the svc-telemetry line, not the whole file, unless you have confirmed every other key in it. Remove the task, LaunchAgent or cron entry, and the script it starts. If the SSH server is running and nobody needs it, stop and disable it.

The servers behind the workstation

To anyone who runs servers, a developer's workstation matters mainly as a way in to everything else. It holds SSH keys, cloud tokens and deployment credentials. The beacon's list of environment variable names works as a list of what to rotate: each name points to a secret that was on the machine. Replace any SSH private keys that lived in that account, remove the old public keys from the authorized_keys files on your servers, and check your servers' authentication logs for logins from addresses you don't recognize since October 29. Do the rotation from a machine that was not exposed. Otherwise the new secrets end up on a host you don't yet trust.

Making the next one less damaging

This attack did not rely on a look-alike name or a typo. It used the real extension ID, delivered through a trusted update channel. Checking the name before installing would not have caught it. What helps is limiting what a bad update can do and noticing quickly when one gets through.

Know which registry each editor uses. The same extension ID lives in several registries. The Claude Code documentation sends VS Code users to Microsoft's marketplace, links a separate Cursor install, and points other VS Code forks to Open VSX. Only one of those registries was compromised. A trusted ID in one registry tells you nothing about the copy in another.
Weigh automatic updates on sensitive machines. "Anyone who has their Claude Code instance set to auto-update could have consumed the malware," Gile told The Hacker News. On workstations with access to production, consider turning off automatic extension updates (in VS Code this is the extensions.autoUpdate setting, so check what your fork offers) and installing updates a day or two after release. The cost is that real security fixes reach you later too.
Control reinstalls. If you remove the extension, the documentation says you can stop the CLI from putting it back by setting autoInstallIdeExtension to false or CLAUDE_CODE_IDE_SKIP_AUTO_INSTALL=1.
Keep developers off admin accounts. In this case, the missing admin rights are what kept the tunnel from working on most Windows and macOS machines.
Don't run an SSH server on a workstation unless it needs one. Watch every authorized_keys file for changes, on workstations as well as servers.
Watch outbound traffic. This loader sent its data out over the network: an IP lookup service, a raw IP address on port 8099, and an SSH session to an unfamiliar host. On a machine where you know what normal traffic looks like, each of these stands out.

Watching a Windows machine with outbound-watch

For Windows workstations, outbound-watch is a small open-source program that lists every outgoing connection. For each one it shows the program, the name that was looked up, the address, the network and country, and the bytes sent and received. It keeps these as history. You write "expected lists" of where programs normally connect, and the tray icon tells you when a program connects somewhere else.

Lists are made of rules, one per line, and every word on a line must match. A starting point for a developer machine might look like this, with the placeholders replaced by what you actually observe over a few normal days:

# Editors: narrow to the destinations you see in normal use
process Code.exe,Cursor.exe port 443 host *.example.com
# SSH only to your own servers
process ssh.exe ip 203.0.113.0/24 port 22

With rules like these, a beacon from the editor to a bare IP address on port 8099 would be flagged as unexpected. So would an SSH session to an outside address, if the OpenSSH client carries it. Two details from the project's README matter here. First, run it as an administrator: without admin rights it misses TCP connections that open and close within a second, as well as UDP traffic and the names programs looked up. Second, it only records from the moment it starts, so it can't reconstruct October 29 on a machine where it wasn't already running. It is for catching the next incident, not for investigating this one.

Note
From Strongthium Labs. For the Linux servers your developers' workstations connect to, Strongthium Guard locks them down, reads their logs and shuts out whoever attacks them within seconds. Strongthium Guard: a firewall that bans attackers by itself. Locks down your Linux servers, reads their logs and shuts out whoever attacks them - within seconds.

Sources

Official Claude Code Extension on Cursor Marketplace Trojanized with Persistent SSH Backdoor - The Hacker News
Cursor Confirms Malicious Claude Code Extension With SSH Backdoor Was Available for 11 Hours - Cyber Security News
Use Claude Code in VS Code - Anthropic
Claude Code for VS Code - Visual Studio Marketplace - Microsoft
GitHub - strongthium/outbound-watch - Strongthium Labs, on GitHub

First published on Strongthium Lab Notes.

CyberStrikeAI and the industrialized hunt for unlocked doors

Strongthium Labs — Tue, 27 Oct 2026 20:57:10 +0000

Early in 2026, an attacker whom Amazon's investigators rated as only moderately skilled got into more than 600 FortiGate firewalls in over 55 countries, and did it without a single zero-day. This month, researchers found an open-source platform that had turned up on that attacker's server running 44 cooperating AI agents against small businesses and local public-sector bodies in Japan. Neither campaign needed a new vulnerability. Both went through doors that were already open: management interfaces facing the internet, weak or default passwords, credentials left in configuration files. What AI added was the ability to try those doors everywhere at once, without tiring, and in the victim's own language.

The FortiGate campaign: no zero-days required

Barrack AI's breakdown of the FortiGate breach brings together three separate investigations and is careful to keep their findings apart. The core facts come from Amazon Threat Intelligence: between January 11 and February 18, 2026, a Russian-speaking, financially motivated actor compromised more than 600 FortiGate devices. Amazon described the actor as having "low-to-medium baseline technical capability, significantly augmented by AI."

The way in was ordinary. According to Amazon's findings as summarized there, the actor went after management ports exposed on TCP 443, 8443, 10443 and 4443 and logged in with weak passwords that had no second factor. What came after was not ordinary at all. Stolen device configurations were decrypted with AI-assisted scripts, internal networks were mapped, Active Directory credentials were pulled with DCSync, and Veeam Backup & Replication servers were attacked through CVE-2023-27532 and CVE-2024-40711 to get at the backup credential stores. Those stores are often an organization's last line of defense against ransomware.

The link to CyberStrikeAI is narrower than some headlines suggest. Amazon's report never names the tool. Team Cymru made the connection after spotting a CyberStrikeAI banner on port 8080 of one of the IP addresses Amazon had shared, and it went on to track 21 servers running the platform between January 20 and February 26. Meanwhile the independent blog Cyber and Ramen found that the operator's most capable tooling, a custom MCP server called ARXON and a VPN scanning orchestrator called CHECKER2, was built by the attacker and is not part of CyberStrikeAI. It also reported logs of more than 2,500 FortiGate appliances queued for access attempts, a different figure from Amazon's 600-plus confirmed compromises. The Hacker News puts it more simply, saying CyberStrikeAI was "previously put to use" in the FortiGate campaign. The more careful reading is that the platform ran on the operator's server alongside other tools.

October: 44 agents and one workflow

TrendAI's analysis of three attack infrastructures targeting Japan was published on October 27, 2026, against the backdrop of a run of data leaks from Japanese web systems and a government alert to businesses on October 9. Its researchers rebuilt the attackers' activity from files left in open directories on servers the attackers controlled.

In the first case, CyberStrikeAI drove the entire workflow: reconnaissance, finding and confirming vulnerabilities, exploitation, command and control, persistence, exfiltration, and reporting. Log entries such as "credential-search agent 8/44" showed the work split among 44 agents. The platform also produced Japanese-language forms and fake login pages. In a short period in October, at least 19 organizations, including at least 16 in Japan, were put through validation, and each got a report in the same format with its own evidence index.

Two details from that case matter to anyone who reads their own logs. First, the platform deliberately throttled its traffic to each target, so the activity was hard to see from inside any single organization. Second, most of the attempts failed. For many targets, the platform's own records say "no session, no web shell, no exfiltration." Even the deepest intrusion TrendAI found started at an administration interface on a legacy web system that was open to the public and needed no login.

The other two cases were run by humans, with AI as an assistant. In one, an operator used a language model for planning and tooling. That operator got into a GIS server that still had default credentials, built a full chain of control at another company running from FTP through a database and a web shell to SSH, and put backdoors back after they had been cleaned up. In the other, an experienced operator went after Cisco SD-WAN, Citrix NetScaler, F5 BIG-IP and Yamaha RTX1210 devices. The Yamaha intrusions used no product vulnerability at all, only credentials found in configuration files the operator had already obtained.

The window for defenders is shrinking too. The Hacker News's report cites Microsoft's 2026 Digital Defense Report as finding that AI has cut the median time from discovering a vulnerability to weaponizing it to "well below 24 hours."

What the platform itself offers

The CyberStrikeAI repository on GitHub describes a Go application with single-agent and several multi-agent modes, more than 100 security tools defined as YAML recipes, MCP integration, batch task queues, and chatbot connectors for platforms including Telegram, Slack, Discord and DingTalk. It also lists WebShell management and a built-in C2 component with listeners, encrypted beacons and task queues. The README says to use it only on systems you own or are explicitly authorized to test, and it ships a call-blocking feature with protection for government domains turned on by default. Those safeguards evidently did not stop the platform from turning up in criminal campaigns.

Two practical notes. When the page was retrieved, the project sat under an AIPentest organization with about 6.9k stars and 1.2k forks, while Barrack AI's March article placed it under the developer handle Ed1s0nZ, and the README's quick start still clones from that account. The default configuration also listens on port 8080, the same port where Team Cymru found its banner. Barrack AI's article relays Team Cymru's warning that operators may start hiding that banner, so treat fingerprinting as a bonus and not something to rely on.

What changed, and what did not

TrendAI sums it up in one line: "AI has increased the attackers' workforce, but the work still consists of looking for unlocked doors." Its comparison of the three cases breaks down roughly like this:

Changed by AI	Not changed by AI
Number of targets handled in parallel	Types of vulnerabilities exploited
Speed of attempts	Entry points: exposed legacy systems, default configurations
Adapting to the target's language	Share of targets that end up deeply compromised
Automated record-keeping and reports

TrendAI also notes that AI-written attack records can be overconfident, logging actions as finished before they were tried, and that language models are known to make up vulnerability identifiers. Treat any reported success counts with caution. Those same habits make decoys and honeypots useful against automated attackers.

What this means for the servers you run

Most readers do not run FortiGate appliances, but the pattern carries over directly to SSH, web control panels, database consoles and any dashboard with a login page. An AI-driven scanner does not need to be clever about your server. It only has to find the one place where you were careless, and it can check thousands of servers while you check one.

Close the doors first

TrendAI's defensive priorities start with inventory: know what faces the internet, update or isolate legacy systems, and look for exposed admin interfaces and default credentials. On a Linux host, a few minutes is enough to get started:

# Services accepting connections on non-loopback addresses
ss -tlnp | awk 'NR==1 || $4 !~ /^(127\.|\[::1\])/'

# Does SSH still accept passwords or direct root logins?
sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'

Anything administrative that turns up in the first list should sit behind a VPN or an address allowlist. Passwords alone should not be enough to get in anywhere that matters. Treat configuration files and their backups as secrets, because the Yamaha case shows what one leaked file can open. If you run inference services or GPU machines, add them to the inventory: TrendAI found attackers specifically hunting for exposed AI infrastructure. Keep backup credentials separate from domain credentials, since the FortiGate operator went straight for the backups.

Make probing expensive

When automation is trying doors at scale, the time between an attacker's first failed attempt and being shut out matters. This is the layer Strongthium Guard is built for: it reads a Linux server's logs and bans whoever is attacking it within seconds, which turns password guessing and scanner sweeps into short attempts from each address instead of steady background noise. It is one layer among several. A firewall that bans attackers does not fix an exposed admin page or a reused password, and it cannot tell a stolen but valid login from your own.

Watch for slow, spread-out attempts

TrendAI's fifth priority comes straight from the throttling seen in the first case: design monitoring for attempts that are infrequent and spread across many targets. Thresholds tuned only for loud bursts will miss traffic that is deliberately quiet. Stricter rules help where they make sense. An admin endpoint that only you should ever touch does not need to allow many failures before it reacts, and patterns are easier to see when you look across several servers than on one.

Warning
A ban stops the next attempt, not the one that already worked. If an administrative login was exposed with a weak password, assume the password is known. Rotate it, then look for new accounts, web shells and unexpected scheduled tasks. For Windows domains, Amazon's guidance as relayed by Barrack AI includes watching for DCSync activity (Event ID 4662), scheduled tasks disguised with service-like names, and unauthorized access to Veeam credential stores.

The platform at the center of both stories is still publicly available. The doors these attacks used have been familiar for years. What has changed is how quickly an automated attacker can find the ones left open.

Note
From Strongthium Labs. Strongthium Guard locks down Linux servers, reads their logs and shuts out whoever attacks them within seconds, which bears directly on the automated password guessing and probing these campaigns rely on. Strongthium Guard: a firewall that bans attackers by itself. Locks down your Linux servers, reads their logs and shuts out whoever attacks them - within seconds.

Sources

CyberStrikeAI Uses 44 AI Agents to Automate Hacking Operations Against Japan Targets - The Hacker News
Not Only ARTEX: The Different Levels AI is Used in Attacks Targeting Japan - TrendAI (Trend Micro)
AIPentest/CyberStrikeAI - GitHub
CyberStrikeAI: the AI Attack Platform Behind the 600+ FortiGate Breach - Barrack AI

First published on Strongthium Lab Notes.

eMudhra's eight-bit CA keys: how it happened and what to fix

Strongthium Labs — Mon, 26 Oct 2026 07:18:45 +0000

In October 2026, eight intermediate certificate authorities run by the Indian company eMudhra turned out to have private keys that were small integers. The smallest was 4. Browsers blocked them within days. Servers, containers, build pipelines and devices that keep their own trust stores take longer to fix, and that work is still going on. This article covers what was found, how a key that small could get into a trusted certificate, how the company behind it was run, and what you can do on the machines you look after.

What was found

SOCRadar's FAQ on the compromise says an independent researcher who signs as "Wayne" reported the weakness on October 17, 2026, to Apple, Google, Microsoft, Mozilla and eMudhra. As proof, Wayne signed a message with each of the eight private keys. Six of the intermediates issue TLS certificates (DV, OV and EV, in G3B and G3C versions). The other two sign code. Sectigo had cross-signed all eight under its AAA Certificate Services root, so each key also appears in a certificate that Sectigo issued.

All eight came from a single key ceremony on April 30, 2025. That means the keys could have been recovered for about 17 months before anyone blocked them. According to SOCRadar, no malicious use had been confirmed as of October 21. Google reported that no TLS certificate chaining to the affected intermediates had been logged to Certificate Transparency (CT) before the block. That rules out attacks on clients that enforce CT. It tells you nothing about clients that don't check CT.

Cloudflare's write-up says the company learned of the compromise on October 19 and patched its own services before public disclosure. Its review found no active exploitation on Cloudflare services. It also stresses that this is a failure of certificate-based authentication, not a weakness in TLS encryption.

How a key can be the number 4

On a curve like P-384, a private key is just an integer d between 1 and the order of the curve's base point, which is about 384 bits long. The public key is the base point added to itself d times. Every integer in that range is a valid key. The curve math does not reject d = 4, and the certificate format has no field that would show it. As SOCRadar notes, the affected certificates "look structurally normal". You only see the flaw when you test the private key against the public key.

All the security comes from choosing d at random from that huge range, so that the only way back from the public key is a search no one can finish. A key below 256 turns that search into at most 255 tries. Anyone with the certificate can run it:

from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import ec

cert = x509.load_pem_x509_certificate(open("intermediate.pem", "rb").read())
target = cert.public_key().public_numbers()
for d in range(1, 256):
    if ec.derive_private_key(d, ec.SECP384R1()).public_key().public_numbers() == target:
        print("private key is", d)
        break

The Wikipedia article on eMudhra lists the eight keys as 4, 56, 66, 115, 155, 156, 230 and 237. It describes them as having between 3 and 8 bits of entropy. SOCRadar rounds this to "roughly eight bits". The two figures don't conflict: 4 needs three bits and 237 needs eight. Wikipedia also reports that security researcher Scott Helme recovered several keys in under a second.

That explains why the keys could be broken. It doesn't explain how they got into certificates. The sources describe eMudhra's preliminary explanation at different levels of detail:

SOCRadar says eMudhra blamed a flaw in its key-generation ceremony script. The script created a second, weak key pair on the hardware security module. Because the two pairs had similar labels, the weak pair was used for the certificate signing requests. eMudhra also cites human error at several steps.
Wikipedia says a flaw in a "key wrap/unwrap" step produced a second, weak set of keys, and staff used them by mistake.

Both say the root cause was still being investigated as of October 21. eMudhra has said it will re-check every key ceremony it has run.

There was an earlier warning that was misread. SOCRadar notes that in June 2025, Mozilla's bug tracker recorded invalid certificate revocation list (CRL) signatures from the same six TLS intermediates. eMudhra said at the time that a manual process had referenced the wrong CA key, published corrected CRLs, and the bug was closed. Its 2026 account links those invalid CRLs to the same key mismatch. Put simply, signatures that didn't verify against the published certificates were treated as a paperwork error, not as a sign that the certificates held the wrong keys.

How the business around it was run

Wikipedia's account shows a company that grew mainly through India's regulated digital signature market. eMudhra was founded in 2008 as a subsidiary of 3i Infotech, licensed by India's Controller of Certifying Authorities, and listed on Indian stock exchanges in 2022. It launched its emSign certificate authority in 2018 after a WebTrust audit. Mozilla accepted four emSign roots, including emSign ECC Root CA – G3, in December 2018. Browsers had been wary of Indian CAs since the National Informatics Centre's CA issued unauthorized certificates in 2014. That made eMudhra the only Indian root CA trusted worldwide.

Publicly trusted TLS was a small part of the business. Wikipedia cites ICRA's figures: enterprise software (secure access, PKI, paperless workflows and certificate lifecycle management) grew to about 80% of revenue by 2026, and international markets made up 64%. In an exchange filing, eMudhra said the affected business accounted for about 1% of revenue. It also said its Indian digital signature and eSign services ran on separate systems.

The effects were not small. eMudhra's shares fell 20% on October 21 and 40% over the two days after disclosure. Indian government sites, including the Aadhaar issuer UIDAI and the income tax portal, used eMudhra certificates. Wikipedia reports that some sites, such as FSSAI, became unreachable after the revocations. CERT-In issued an advisory. The Ministry of Electronics and Information Technology set up a team to investigate and said the regulated signature services were not affected. On October 22, eMudhra announced it would leave the global SSL/TLS certificate business. Wikipedia reports that the company also called the social media scrutiny out of proportion to the division's place in the company.

At the time of writing, eMudhra's own homepage still lists "CLM & SSL/TLS Certificates" among its featured products. Its newsroom shows the October 22 exit notice and a later item saying ICRA kept the company's ratings after the incident. One way to read the record is that 1% of revenue still meant a globally trusted root, about 30,000 customer certificates, and many government websites. Readers can judge how well the controls around that business matched what it carried.

Where the risk remains

Browsers have been dealt with. SOCRadar's timeline shows Chrome blocking the intermediates through a CRLSet update and Firefox through OneCRL, both on October 17, then Apple on October 19 and Microsoft on October 20. Mozilla removed emSign ECC Root CA – G3 from NSS on October 20. Chrome's removal of that root is expected to reach all devices by October 27. Cloudflare's post says browser vendors could fix this "with a flip of a switch" because they have one application to update and fast revocation channels.

Servers have no such channel. API clients, backend services, containers, CI/CD runners and embedded devices often trust a bundled CA store, skip revocation checks and ignore CT. SOCRadar reports that in Scott Helme's tests, curl, Python and Node.js on Linux and macOS accepted a forged certificate issued under one of the compromised intermediates. Go programs only get the block after being rebuilt with a patched toolchain. The two code-signing CAs are also a concern on Windows systems that skip revocation checks. eMudhra says neither was ever used, but code-signing certificates aren't logged to CT, so there is no public record either way. Wikipedia also notes that mitmproxy added an option to sign with the leaked keys, so forging certificates now takes no special skill.

Cleaning it out of your servers

Update, rebuild, test

The order of work is the same in all the sources:

Update every trust store. That means the OS ca-certificates package and language-level bundles. SOCRadar lists fixed versions, including Python certifi 2026.10.19, Node.js 22.23.4, 24.22.1 and 26.12.1, and webpki-roots 1.0.10. It also notes that Bun and FreeBSD fixes were still pending on October 21.
Rebuild, don't just patch. Recompile Go services with Go 1.27.3 or 1.26.10. Rebuild container images from patched base images. Cloudflare adds that you should check whether each application needs a reload, restart or redeploy before the change takes effect.
Look beneath the SDK. Cloudflare points out that an API client may hand certificate checks to an HTTP library, the language runtime, the OS or a custom trust configuration. Updating the SDK alone may change nothing.
Review what you trust as a server. If your origin or proxy verifies client certificates with mutual TLS, check the CA list it uses. Also find any of your own sites that still serve G3-chained certificates.
Test through the real path. The disclosure site serves chains through the compromised intermediates. A certificate error is the result you want:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

As Cloudflare notes, a passing curl test says nothing about an application that uses a different verifier.

Warning
After patching, you may see new certificate errors in logs and dashboards. Do not fix them by turning off verification. As Cloudflare puts it, that "would remove the authentication protection these updates are intended to restore." Replace the certificate or the chain instead.

Distrusting the certificates by hand with emudhra-patch

Some hosts can't take a package update yet, and some you want closed before the next maintenance window. For these, Strongthium Labs publishes emudhra-security-patch, an MIT-licensed, single-file tool for Windows and Linux. It finds the eight G3B and G3C intermediates and their emSign G3 roots in the system trust stores and distrusts them:

emudhra-patch scan       # report where each certificate is; changes nothing
emudhra-patch revoke     # distrust them (root on Linux, administrator on Windows)
emudhra-patch restore    # undo revoke from the backup it made

The README describes how it works. scan exits with code 2 if anything on the list is still trusted, so you can run it as a monitoring check. On Windows, it removes the certificates from the trusted stores and adds them to the machine's Disallowed store. That also blocks a root that Windows Update hasn't fetched yet. On Debian and Ubuntu, it deselects the root in /etc/ca-certificates.conf. On Fedora, RHEL, Arch and openSUSE, it uses the p11-kit blocklist. Every change is backed up and listed in a manifest, and restore undoes the changes in reverse order. The certificate list is a plain file, badcerts.txt, matched by SHA-256 fingerprint.

Some things to know before you run it:

The revoke command distrusts certificates on your machine only. Actual revocation was done by eMudhra and Sectigo.
Distrusting emSign ECC Root CA – G3 drops everything eMudhra issued under that root, which matches Mozilla's decision. To keep it, comment out its line in badcerts.txt.
The tool also distrusts any certificate that shares a key with a listed one, and that certificate's issuers up to the root. SOCRadar warns that removing Sectigo's AAA Certificate Services can break legitimate connections. Read the scan output before you run revoke.
It does not touch Firefox or Thunderbird stores, Java cacerts unless built from the system store, NSS databases in ~/.pki/nssdb, containers, or runtimes that ship their own bundle. Those still need their own updates.
If you download a release build, check it against the published SHA256SUMS. You can also build it yourself with the .NET 10 SDK.

What to take from it

The weakness itself was simple. The certificates were well formed and the ceremony was recorded. Still, a mixed-up key label and a misread CRL error led to six globally trusted TLS CAs, plus two code-signing CAs, whose keys anyone could guess. For people who run servers, the longer-lasting lesson is the one Cloudflare draws: a trust store can't be a static list that changes only when a package updates. Find out which verifier each of your services actually uses, make sure you can push a distrust quickly, and keep scan-style checks running until every host comes back clean.

Sources

8 eMudhra certificates are compromised. Here's what you need to know - Cloudflare
eMudhra CA Key Compromise: Weak Keys, Risks and Fixes - SOCRadar
EMudhra - Wikipedia
eMudhra | Digital Signature & PKI Services in India - eMudhra
strongthium/emudhra-security-patch - Strongthium Labs on GitHub

First published on Strongthium Lab Notes.

Security roundup: October 17–23, 2026

Strongthium Labs — Sat, 24 Oct 2026 23:38:59 +0000

The critical vulnerabilities of the week in the server software we watch and what it runs on: those that score CVSS 7.0 or more, and those CISA says are being exploited in the wild. This week, 3 vulnerabilities.

Software	Vulnerabilities	Exploited	Highest score
Kubernetes	1	–	10.0
PHP	1	–	9.8
Windows Server	1	–	9.8

Kubernetes

CVE-2026-83938

CVSS 10.0, critical · published October 22, 2026

Missing authentication for critical function in Azure Kubernetes Configuration Service allows an unauthorized attacker to elevate privileges over a network.

Weakness: CWE-306
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Read more: NVD

PHP

CVE-2026-109618

CVSS 9.8, critical · published October 21, 2026

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

Affected: PHP from 7.3.0 before 8.2.35; PHP from 8.3.0 before 8.3.36; PHP from 8.4.0 before 8.4.27; PHP from 8.5.0 before 8.5.12
Weakness: CWE-416, CWE-755, CWE-824, CWE-1325
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Read more: NVD · github.com advisory

Windows Server

CVE-2026-83888

CVSS 9.8, critical · published October 13, 2026

Buffer over-read in Windows CD-ROM Driver allows an unauthorized attacker to elevate privileges over a network.

Affected: Windows Server 2012, every version; Windows Server 2012 r2; Windows Server 2016 before 10.0.14393.9612; Windows Server 2019 before 10.0.17763.9376; Windows Server 2022 before 10.0.20348.5761; Windows Server 2025 before 10.0.26100.33650
Weakness: CWE-126
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Read more: NVD · msrc.microsoft.com advisory

From the National Vulnerability Database (NVD), whose descriptions these are, and CISA's catalog of Known Exploited Vulnerabilities. A score is the highest the record gives, NVD's own or its source's. Software we watch: what servers commonly run, from the operating system to the database.

First published on Strongthium Lab Notes.