# Leaked CA keys, a hijacked backup tool and open AI panels > Go wants a rebuild, AOMEI hasn't told anyone, and AI-agent crims forgot to lock the door. - Series: It's Probably Nothing - Publisher: Sierra Echo Charlie - Edition date (Pacific/Auckland): 2026-10-21 - Edition number: 6 - Status: Published edition - Language: en-NZ - [Canonical web edition](https://ipn.nz/editions/2026-10-21) - [Download PDF](https://ipn.nz/pdf/IPN-2026-10-21.pdf) - [MP3 audio](https://ipn.nz/audio/IPN-2026-10-21.mp3) (5:14, 5017225 bytes) - [Standalone transcript](https://ipn.nz/transcripts/2026-10-21.md) ## Opening Three stories today, and two of them are about software you trusted doing the thing you trusted it for, just on someone else's behalf. The third is about attackers automating their way into shops and leaving the control room open. ## 1. Eight eMudhra intermediate CA keys compromised, and Go wants you to rebuild Mozilla says it got a report at 20:06 UTC on Saturday 17 October that private keys for eight eMudhra intermediate certificates had been compromised. Those keys could be used to issue fraudulent HTTPS certificates for sites the attacker doesn't control. Firefox users mostly never noticed. Mozilla pushed a OneCRL block that had reached standard installs by 22:59 UTC the same day, with no update or restart needed. Since then it has shipped Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for people whose settings might have blocked that, plus NSS 3.131.1, which removes the signing root entirely. Go is where the real work is. Go 1.27.3 and 1.26.10 block 'a small set of intermediate certificates due to specific security concerns around their operation'. That's [CVE-2026-111943](), and Go recommends upgrading immediately. Go doesn't name the CA, but a commenter on the Go issue matched all eight hashes to eMudhra intermediates. By that mapping, six are TLS intermediates under emSign Root TLS CA - G3 and two are code-signing intermediates under emSign Root CS CA - G3. The Hacker News hasn't verified that match. If it holds, this stops being purely a TLS story. Go's verifier doesn't do revocation checks or read browser blocklists, so nothing is protected until you rebuild. The Hacker News reports that the filter matches on public-key hashes, which catches cross-signed copies too, and that it can't be disabled. It also reads the filter as applying to custom trusted roots, though Go hasn't said whether that's intended. Go 1.25 and older get no fix. eMudhra hadn't said anything publicly as of 20 October, and nobody has explained how the keys got out. It's also not established what Chrome, Apple or Microsoft are doing about it. ### Worth asking If you ship Go services, rebuild them. If anything you run chains through emSign G3 intermediates, it'll need a certificate from a different intermediate, or patched Go clients will stop connecting. ### Qualifications The root cause is undisclosed, the TLS/code-signing split rests on an unverified community mapping, and other root programmes' responses are unknown. ### Sources - [Protecting Firefox users following the compromise of eMudhra intermediate certificates]() — primary source - [\[security\] Go 1.27.3 and Go 1.26.10 are released]() — primary source - [Go Issues Emergency Update Blocking Eight CA Keys Over Undisclosed Security Concerns]() — reporting/context - [eMudhra Intermediate Key Compromise Triggers Firefox Blocks and Emergency Go Updates]() — reporting/context ## 2. AOMEI confirms the update hijack but hasn't told infected customers Last week Google's threat intel group and ManageEngine described UNC7017 tampering with AOMEI Backupper's update configuration. On 20 October AOMEI confirmed it to Recorded Future News: attackers repeatedly altered config files on its update servers between April and July, redirecting downloads to malware for minutes at a time. AOMEI also said it hasn't yet identified or notified infected customers. It has put out a free detection tool instead. The technique was neat in an unpleasant way. According to BleepingComputer, the attackers edited down\_html.ini and Notifycfg.ini and changed the expected checksum, so the malicious ZIP passed verification and ran without any user interaction. From there, the CROSSROAD downloader set up a scheduled task, and the SHINYROAD backdoor used legitimate Radmin components to reach its C2. In the 20 July window, an invisible pop-up also tried to coerce NTLM hashes to an attacker-controlled WebDAV server. The Record says that could work even where the malware itself was blocked. The identified windows are 28 May 05:40–05:50 UTC, 16 July 08:33–08:39 UTC and 20 July 10:35–10:40 UTC. Google thinks there was probably more tampering it couldn't see. Victims span almost a dozen countries, Australia among them. ManageEngine says it warned AOMEI in June, that AOMEI initially blamed in-transit interception, and that the attackers struck at least twice more after that. ManageEngine also says AnyViewer was targeted, while AOMEI says only Backupper showed anomalies. Attribution is open: the malware avoids machines that appear to be in China, but researchers say that doesn't tell you where the attackers are. ### Worth asking If Backupper was on your fleet between April and July, hunt across that whole period. The server fix doesn't clean machines that were already infected. ### Qualifications The primary GTIG and ManageEngine reports weren't read, and ManageEngine hasn't verified that the attackers have lost access. ### Sources - [AOMEI yet to notify customers after hackers hijacked its software updates]() — reporting/context - [Hackers hijack AOMEI update servers to secretly spread malware]() — reporting/context - [Ephemeral AOMEI Update Tampering Redirects Downloads to Malware]() — reporting/context ## 3. AI agents hacking shops, watched through their own unlocked panels NorForge found more than 20 exposed panels for Cairn, an AI agent harness, that it assesses as likely malicious. Through them it could watch agents choose targets and go to work. The biggest cluster, AIA0001, operates in Chinese and runs over 1,100 projects across 14 panels, mostly against the US, Japan and Australia. Its task feed picks e-commerce sites with 200,000–1.5 million in traffic that Playwright has confirmed can actually take orders. The agents are told to find unauthenticated RCE and plant an uploader shell. The worker is named 'claudecode\_deepseek-v4.1-flash', which NorForge says 'could mean' Claude Code driving DeepSeek. Its own rough estimate is about a 10% success rate at around US$5 a task, with considerable uncertainty. One of its case studies is an Australian shop with command execution on the web server. Citing Reuters, Tom's Hardware reports that the agents tried more than 1,200 sites and got into more than 100, including Deere and SharkNinja. SharkNinja says only a product-support information site was affected. Then there's the self-own. Trufflehog over the panel data turned up hundreds of secrets, 11% of them verified valid, and the panels appeared to expose full admin controls without authentication. NorForge says it didn't test those controls. Cheap, patient, automated exploitation is the worrying bit. The attackers forgetting a login page is just the funny bit. NorForge says it's working with Reuters to notify victims and chase takedowns. ### Qualifications The Reuters original wasn't read, and timing may straddle the start of this coverage window. ### Sources - [Inside Cairn: Open Windows into massive AI-Driven Cyber Operations]() — primary source - [A Chinese hacker used AI agents to break into more than 100 company websites]() — reporting/context - [AI Platform Cairn Abused to Hack Over 100 Organizations]() — reporting/context - [Exposed AI Agent Panels Reveal Reported Breaches of More Than 100 Websites]() — reporting/context ## Audio transcript Narrated using an AI voice. Kia ora, welcome to It's probably nothing. Three stories today, and two of them are about software you trusted doing exactly what you trusted it for, just on someone else's behalf. The third is about attackers automating their way into online shops and leaving the control room open. First, eMudhra. Mozilla says it got a report on Saturday the 17th of October that private keys for eight eMudhra intermediate certificates had been compromised. Those keys could be used to issue fraudulent HTTPS certificates for sites the attacker doesn't control. Most Firefox users never noticed. Mozilla pushed a OneCRL block that reached standard installs within about three hours, no update or restart needed. It's since shipped Firefox point releases for people whose settings might have blocked that, plus an NSS update that removes the signing root entirely. Go is where the real work is. The latest Go 1.27 and 1.26 patch releases block what Go calls a small set of intermediates due to specific security concerns around their operation, and Go recommends upgrading immediately. Go doesn't name the CA, but a commenter on the Go issue matched all eight hashes to eMudhra intermediates: six TLS intermediates and two code-signing ones under emSign's G3 roots. The Hacker News hasn't verified that match, but if it holds, this stops being purely a TLS story. Here's the catch. Go's verifier doesn't do revocation checks or read browser blocklists, so nothing's protected until you rebuild. The Hacker News reports the filter matches on public-key hashes, so it catches cross-signed copies too, and it can't be disabled. It also reads it as applying to custom trusted roots, though Go hasn't said whether that's intended. Go 1.25 and older get no fix. eMudhra hadn't said anything publicly as of the 20th, nobody's explained how the keys got out, and we don't know what Chrome, Apple or Microsoft are doing. So, rebuild your Go services, and if anything you run chains through emSign G3 intermediates, get a certificate from a different intermediate, or patched Go clients will stop connecting. Next, AOMEI. Last week Google's threat intel group and ManageEngine described a group called UNC7017 tampering with AOMEI Backupper's update configuration. On the 20th AOMEI confirmed it to Recorded Future News: attackers repeatedly altered config files on its update servers between April and July, redirecting downloads to malware for minutes at a time. AOMEI says it hasn't yet identified or notified infected customers, and has put out a free detection tool instead. According to BleepingComputer, the attackers edited the update config and changed the expected checksum, so the malicious ZIP passed verification and ran without user interaction. A downloader called CROSSROAD set up a scheduled task, and the SHINYROAD backdoor used legitimate Radmin components to reach its command server. In the 20 July window, an invisible pop-up also tried to coerce NTLM hashes to an attacker-controlled WebDAV server, which The Record says could work even where the malware was blocked. The identified windows are the 28th of May, the 16th of July and the 20th of July, each only five to ten minutes, and Google thinks there was probably more it couldn't see. Victims span almost a dozen countries, Australia among them. ManageEngine says it warned AOMEI in June, that AOMEI initially blamed in-transit interception, and that the attackers struck at least twice more after that. ManageEngine also says AnyViewer was targeted; AOMEI says only Backupper showed anomalies. Attribution's open. If Backupper was on your fleet between April and July, hunt across that whole period, because the server fix doesn't clean machines already infected. Finally, NorForge found more than twenty exposed panels for Cairn, an AI agent harness, which it assesses as likely malicious. Through them it could watch agents pick targets and go to work. The biggest cluster runs over 1,100 projects, mostly against the US, Japan and Australia, picking e-commerce sites that can actually take orders and hunting for unauthenticated remote code execution to plant a shell. NorForge roughly estimates about a ten percent success rate at around five US dollars a task, with considerable uncertainty. Citing Reuters, Tom's Hardware says the agents tried over 1,200 sites and got into more than 100, including Deere and SharkNinja, though SharkNinja says only a product-support site was affected. Then the self-own: the panel data held hundreds of secrets, eleven percent verified valid, and the panels appeared to expose full admin controls with no authentication. NorForge says it didn't test those. Cheap, patient, automated exploitation is the worrying bit. Forgetting a login page is just the funny bit. That's it for today. Go rebuild something, and I'll catch you next time. Don't forget, all our threat intelligence comes from Mallory dot A I. If you want intelligence your team can act on, reach out for a chat. ## Publisher Researched by our AI agents using [Mallory](https://mallory.ai) and original sources. Reviewed and published by [Sierra Echo Charlie](https://sierraechocharlie.com). Want intelligence your team can act on? [Reach out for a chat.](mailto:letsgo@sierraechocharlie.com)