What happened

On November 3, 2026, mSeven Software, the US developer of the mSecure password manager, emailed current and former customers. According to The Register, which has seen the email, the company "recently learned of suspicious activity" associated with the app. It says it launched an investigation, "took steps to mitigate the issue" and brought in outside cybersecurity experts.

Customers are told to "immediately take steps to protect all confidential information stored within" mSecure. The email lists possible steps: changing passwords, resetting or re-enrolling two-factor authentication (2FA, the second login step via code or app) and removing existing passkeys. Passkeys are cryptographic login keys that replace passwords.

What the email leaves out is the longer list. According to The Hacker News and heise, it doesn't say:

• what the suspicious activity was or when it happened,
• whether it has stopped,
• whether vault data or the keys protecting it were affected,
• which systems were involved or how many customers,
• whether the sync option (mSecure Cloud, Dropbox, iCloud, Wi-Fi) matters,
• whether the 2FA and passkey advice covers the mSecure account itself, the items stored in the vault, or both.

mSeven had not answered The Register's questions at the time of publication. On the support forum, customers with 500 or 800 stored passwords are asking whether they really have to change all of them. So far, nobody from the company has answered there.

What has changed since my post

Nothing of substance. As of today (November 4) I can't find any further statement from the vendor, and no CVE or patch tied to the incident. One correction to my post: the email frames the three steps as possibilities ("may include"), not firm instructions. In practice it still comes down to "everything", because nobody can say which entries are at risk.

Why it matters

mSecure advertises AES-256, end-to-end encryption and zero knowledge. In plain terms, data is encrypted on your device and the vendor shouldn't be able to read it. If that holds, a break-in at the vendor should leave vault contents largely safe. heise rightly points out that advising a full reset after an incident at the vendor raises the question of whether there are weaknesses in the encryption or secondary keys.

There's also an earlier finding. In December 2025, Germany's Federal Office for Information Security (BSI) reviewed ten password managers. For mSecure 6.1.5 on Android, it found that the vendor could theoretically access stored data, and that the overall design fell short of what people usually expect from a password manager (test.de). Only that version was tested. Whether it has anything to do with the current incident is unknown, and the two shouldn't be conflated.

Who is affected

Anyone who uses or has used mSecure. heise gives a rough sense of scale: over 500,000 installs on Google Play, plus roughly 250,000 iOS users estimated from App Store ratings. How many customers are actually affected is unknown.

What you should do now

As long as the vendor stays silent, I'd assume the vault contents are known to someone else.

1. Email accounts first. Whoever has your inbox can reset passwords almost everywhere. New password, re-enroll 2FA, sign out all active sessions.
2. Then banking, payment services and your Apple/Google/Microsoft account, followed by anything tied to money or identity.
3. Re-enroll 2FA. If you kept TOTP codes (the six-digit codes from authenticator apps) in the vault, the secrets behind them are just as suspect as the passwords.
4. Remove and recreate passkeys, especially ones stored in mSecure.
5. Work through the remaining accounts by importance. With hundreds of entries it's tedious, but the order protects what matters most first.
6. Watch out for phishing. An incident notice is perfect bait for fake "reset here" emails. Log in to sites directly, not through links in emails.
7. Consider switching. A password manager that gives no details after an incident is losing the one thing it sells: trust. If you switch, create the new passwords directly in the new manager.

I'll update this article once mSeven says more.

Sources

• The Hacker News: mSecure Warns Users to Change Passwords, Reset 2FA and Passkeys
• The Register: Password manager mSecure tells users to change passwords, won't say why
• heise: mSecure password manager: Secure your credentials after an IT incident
• test.de: Authority criticizes insecure password managers (BSI study, German)

One correction to my post on X and in the WhatsApp channel: there I listed the patch status as unclear. In fact, a fix has been out since October 28.

What happened

The flaw is a TOCTOU race condition. TOCTOU stands for "time of check to time of use": a system checks something, then acts on the result a moment later. Whoever moves faster in that short gap can step in.

In WordPress, this affects core updates that use the full update package. According to WordPress advisory GHSA-4w3m-c66w-69mg, affected versions unpacked the new files into a predictable directory inside the web-served upgrade folder. An attacker who wins the race against that extraction can run PHP code on the server without logging in. No account and no admin action is needed.

How serious is it?

Not everyone agrees on the rating. WordPress itself rates the flaw "Low." The CVE record scores it CVSS 8.1, which is "High," according to Ostorlab and runZero. CVSS is the standard severity scale from 0 to 10. The gap comes down to the time window: it lasts only seconds, so an attack is hard to pull off. The high score already counts that as "high attack complexity."

On the activity so far: Ostorlab reports that Wordfence blocked almost 63,000 requests aimed at the flaw in the 24 hours up to October 30. Those were attempts, not confirmed break-ins. CISA's KEV notice gives no details on successful attacks, but the listing is based on "evidence of active exploitation." How many sites were actually compromised has not been made public.

My take: "hard to exploit" is no excuse to wait. These attacks are automated and run at huge scale, and WordPress is on a vast number of servers. Try often enough and you'll win a race eventually.

Who is affected

Per the advisory, every WordPress version from 4.7.0 through 7.1.3 is affected. The fix is in 7.1.4, with backports to every older branch back to 4.7, for example 7.0.8, 6.9.11, 6.8.12 and 4.7.39. The full list is in the advisory. Pantheon describes 7.1.4 as a security release that fixes 13 issues in total, including several stored XSS bugs.

There is one important condition. According to Ostorlab, the flaw can only be exploited if the staging directory under wp-content/upgrade/ is reachable from the web and PHP files in it can run. That's true on many standard hosting setups.

What you should do now

• Update. Take a backup, then install 7.1.4 or the patched release for your branch. The advisory names this as the fix.
• Know the auto-update catch. Background auto-updates will deliver the fix. But the update itself still runs on the old, vulnerable code. As Ostorlab explains, that means the one update window is still exposed.
• Block the upgrade folder if you can't update right away. Deny web access to /wp-content/upgrade/ at the web server, for example with a 403 rule. This covers only this flaw and doesn't replace the update. It's best to put the block in place before you update, so the update window is covered too.
• Check your logs and the directory. Search your web server logs for requests to PHP files under that path. Look in the directory for PHP files that don't belong there. A single hit is a lead worth following up, not proof of a break-in.
• Clean up. After the update, delete any leftover files in the upgrade folder.

If you run lots of sites, as agencies and hosts do, set the block centrally at the server level. That's faster than touching every install one by one.

Sources

• WordPress Security Advisory GHSA-4w3m-c66w-69mg
• NVD: CVE-2026-119977
• CISA KEV notice, November 3, 2026 (summary)
• Ostorlab: WordPress Core Upgrade-Window RCE
• runZero: WordPress CVE-2026-119977
• Pantheon release notes: WordPress 7.1.4

What happened

XCPE (internally "x.cpe") is a backdoor that ships in the boxes' firmware, the software built into the device. It runs as a system app with full privileges and reports to command-and-control servers, which the operators use to send instructions to the devices. According to Help Net Security, it reinstalls itself from a protected partition after a reboot, so uninstalling the app doesn't get rid of it. To install software silently, XCPE turns off Google Play Protect's app checks.

Google's Threat Intelligence Group attributes XCPE "with high confidence" to Videostrong Technology, a manufacturer based in Shenzhen, China. Videostrong builds Android TV boxes under its own name and for other brands. The Hacker News lists the evidence:

• XCPE passes settings to other Videostrong apps.
• A GitHub account that hosted the botnet's packages is named "yf-videostrong".
• Partner company Synthient found a document signed by Videostrong's R&D director on one of the botnet's servers.
• A Videostrong domain and the operators' control panel shared an IP address.

The reports describe the business model like this: Videostrong sold criminals access to the boxes, and the criminals installed their own modules. Most modules turned the boxes into residential proxies. A residential proxy routes other people's internet traffic through home connections so it looks like ordinary household traffic. Other modules loaded ads in the background that nobody saw, which is ad fraud. The operators could also take screenshots, inject keystrokes, copy account details and system logs, and open a remote shell.

What Google did

Google took legal action against the domains and servers that controlled the botnet. The action also covered the control infrastructure of more than a dozen other malware families. Japan's National Police Agency took part, along with Lumen, HUMAN Security, Plume, Synthient and TrendAI, Trend Micro's enterprise unit. Videostrong and any future subsidiaries are now banned from building certified Android devices and from supplying software to certified manufacturers. Google is also tightening firmware checks for certified Android TV devices and has closed a gap in its manufacturer review process.

What has changed since my post

In my post I said it was unclear how far XCPE had spread in Germany. There are numbers now. According to The Hacker News, Malaysia, Brazil, Iraq, Mexico and Taiwan had the most infections. The US, Germany, the UK, Australia and Canada each had roughly 26,000 to 42,000 devices. Between June and October, TrendAI counted 1,472,554 infected devices across 206 models, more than Google's 1.3 million. MECOOL boxes come up most often among the brands. Synthient has published a list of 182 model names, but a model name alone doesn't prove a device is infected. According to Plume, the botnet included both Google-certified devices and boxes running plain AOSP, the open-source Android without Google services. The backdoor also showed up in telehealth devices, karaoke machines and digital signage.

Google expects the takedown to cut criminals off from at least 10 million more devices that were infected in other ways.

What you should do

As far as anyone has reported, there is no patch. The servers are down, but the backdoor is still in the firmware, so whoever controls it could put the devices back to work.

• Check your box: Do you have a cheap Android TV box, especially a MECOOL or no-name brand? Compare the model against Synthient's list.
• Replace it if in doubt: Synthient advises throwing affected boxes away. Plume recommends at least a full factory reset but doesn't say whether that removes XCPE. TrendAI says getting rid of the backdoor takes action from the vendor, platform protection or a new device. My take: a factory reset probably isn't enough here. The box should go.
• Segment your network: TV boxes and other IoT devices belong on their own network, such as a guest Wi-Fi or a VLAN, kept apart from computers and NAS devices.
• For organizations: Hunt for these devices using the published indicators, block the listed control domains, and treat unmanaged personal devices in home offices as part of your attack surface.

My advice stands: with a $30 box from a brand nobody's heard of, you may end up paying with your internet connection.

Sources

• Help Net Security: XCPE botnet, Android backdoor
• The Hacker News: Google disrupts 1.3 million device botnet

What happened

The theft took place on October 29, 2026. The FBI says more than $6 billion in virtual assets was stolen. The exact figures vary: The Hacker News reports $6.43 billion, heise cites $6.36 billion from TRM Labs, and Chainalysis put it at about $5.9 billion, according to Cointelegraph. Only the scale is certain: this is the largest crypto theft on record. The previous record was the Bybit hack in February 2025, about $1.46 billion, also attributed to TraderTraitor.

According to The Hacker News, the stolen funds sat on eleven blockchains, 82 percent of them on Ethereum and Bitcoin. Heise reports that the attackers moved most of the money out within about 20 minutes.

There is no confirmed account yet of how the attackers got in. Binance first pointed to a compromised laptop belonging to a DevOps engineer, an employee who looks after infrastructure and deployments. According to heise, Binance now believes there were several entry points and that the attack was complex.

What has changed since our post

• Official attribution: Analytics firms such as TRM Labs, Chainalysis and Elliptic were the first to point to North Korea. At first the FBI only said it was investigating. With its alert on October 31, the attribution now comes from a government agency.
• Wallet list: According to SecurityWeek, the FBI published 628 addresses: 608 on Ethereum, 19 on Bitcoin and one on Solana. It asks exchanges, DeFi services (decentralized finance services with no central operator), bridges and node operators to block transactions involving these addresses. The FBI expects the funds to be laundered further through DeFi and instant swap services.
• Frozen funds: According to Elliptic, Tether, Circle, Ripple, Arbitrum and Optimism have frozen about $2.85 billion. TRM Labs estimates $2.7 billion. The attackers converted most of the rest into Ether, which is very hard to freeze.
• Binance covers the loss: According to heise, Binance says the exchange will bear the loss, not its users, and that about 90 percent is already covered. Withdrawals resumed on November 1 and are now running on all 15 networks. On the first day, net outflows were about $3.64 billion.

Why it matters

This was no opportunistic theft. A patient, state-backed attacker looted one of the world's largest exchanges. Elliptic says this single incident almost doubles the total crypto that North Korea has stolen so far. TraderTraitor has been active since at least 2020. The group is also blamed for the attacks on DMM Bitcoin, Bybit, KelpDAO and Bitget.

Its known methods target people and developer tools. They include fake recruiters, front companies and job-themed lures. Reports from SentinelOne, Zscaler and Microsoft also describe trojanized Terraform providers. Terraform is a tool teams use to manage infrastructure as code. A tampered provider puts malicious code straight into the developer workflow. There is no proof that these exact techniques were used against Binance. But the pattern fits what Binance said about the laptop.

What you should do

If you hold crypto personally:

• Don't keep all your holdings on one exchange. Anything you aren't actively trading belongs in your own wallet, ideally a hardware wallet.
• Protect exchange accounts with hardware security keys (FIDO2/passkeys) instead of SMS codes.
• Be wary of job offers, "test assignments" and files from strangers, especially when they come through LinkedIn, Telegram or Discord.
• Watch out for phishing. Fake "compensation" sites spread after every big incident.

If you run a business or a dev team:

• If you handle crypto assets, add the FBI's address list to your transaction screening.
• Treat admin and developer machines as high-value targets. Keep work and signing environments separate, and keep privileges as tight as possible.
• Check where Terraform providers, packages and scripts come from before they reach your pipelines.
• Train HR and engineering staff to spot fake recruiters. Attackers often get in through a job interview, not through the firewall.

My take: no single tool stops a state attacker. What matters is that one compromised laptop should never be enough to move billions.

Sources

• The Hacker News: FBI Links North Korea's TraderTraitor to Binance theft
• heise: FBI – North Korea behind billion-dollar crypto theft at Binance (German)
• SecurityWeek: FBI Flags Over 600 Addresses Tied to North Korea's Binance Heist
• Cointelegraph: North Korea linked to $6.3B Binance hack

What happened

Chainalysis says the access began in early October. Affected customers were notified by email. For users provisioned on the platform, the attacker accessed:

• user IDs
• full names
• email addresses
• organizational role labels

The company says it found no evidence of access to investigation content, authentication credentials or session tokens. A session token is the digital pass that keeps you logged in after you sign in. Anyone who steals one can act as that user without a password. That is Chainalysis's account, and no one has verified it independently so far.

No source gives the number of affected customers. Chainalysis says it is still working out which records were accessed for each organization and will send customers that breakdown later.

Several questions are still open: how the attacker got in, which vulnerabilities were exploited, which internal tools were reached and how long the attacker stayed. Chainalysis says it is patching vulnerabilities and hardening its systems. It hasn't said what exactly it patched. The company explicitly says the incident is unrelated to last week's Binance theft.

What "agentic" means here

An AI agent is a language model that doesn't just produce text but operates tools on its own. It can run commands, read the results and plan the next step. Used offensively, an agent can automate reconnaissance and exploitation in a loop, much faster than a human.

One caveat: the term comes from Chainalysis, and the company hasn't explained it. According to BleepingComputer, it's unclear whether the attacker used an existing framework or built custom agents. One example of such a framework is ARTEX, which Microsoft says threat actors used in the ConnectWise supply chain compromise. So the only evidence that AI was involved is the company's own wording, and how much it contributed is unknown.

Why it matters

Names, emails and roles look harmless at first glance. At Chainalysis it's a different story. Its customers include law enforcement agencies, compliance teams and crypto firms. A list showing that "person X is an investigator at organization Y" is ideal material for targeted phishing. Phishing means fake messages sent to steal credentials or money. Role labels also tell attackers who holds the interesting privileges inside an organization.

There's a bigger picture too. Chainalysis itself points to an industry-wide rise in AI-driven attacks. I find it notable that a company says this so openly in a breach notice. If agents make hunting for vulnerabilities cheaper, the first targets will be firms with valuable data and a large attack surface in their internal tooling.

What you should do

If you or your organization use Chainalysis:

• Turn on two-factor authentication (2FA) if you haven't already. Chainalysis recommends this too.
• Watch for unexpected password reset emails and login prompts. Don't approve anything you didn't start yourself.
• Be extra skeptical of emails that claim to come from Chainalysis. BleepingComputer reports that the company warns of scammers posing as Chainalysis, especially ones offering fund recovery or recruiting.
• Read Chainalysis's notice to your organization and look out for the promised per-organization breakdown.
• Warn your team. Colleagues whose roles are stored on the platform are the most likely phishing targets.

What has changed since the post

There are two additions since my first post. Chainalysis now gives concrete advice (2FA, caution with reset emails and scammers) and has promised a per-organization breakdown of the affected records. The number of affected customers is still unknown. There is no CVE, which is the public ID assigned to a vulnerability, and no named patch.

Sources

• BleepingComputer: Chainalysis discloses data breach from "offensive agentic techniques"
• The Hacker News: Chainalysis confirms intrusion
• Infosecurity Magazine: Chainalysis Warns Customers After "Offensive Agentic" Security Incident

What has changed since my post

On X and in the WhatsApp channel, I said the reports named neither the affected versions nor a CVE. That's no longer true. There are now two explanations, and they don't fully match:

• Synology doesn't say outright which flaw is being exploited. It only says the flaw was fixed in December 2024 and links to advisory Synology-SA-24:20. That advisory covers flaws shown at Pwn2Own 2024, including CVE-2024-10441, a remote code execution bug rated 9.8 out of 10 on the CVSS scale. Remote code execution means an attacker can run their own code on the device over the network.
• Chinese security firm 360 examined affected devices. According to Gridinsoft, 360 traces the attacks to CVE-2026-13639 and CVE-2026-13684. Both are also rated 9.8 and appear in Synology-SA-26:13, published September 18, 2026. They let attackers read and write arbitrary files without logging in.

Nobody outside can tell which explanation is right. Both could be, if different attackers use different flaws. In practice it barely matters, because updates exist for both. But according to 360's analysis, installing only the 2024 patch doesn't automatically make you safe.

What the attack looks like

According to BleepingComputer, the first victims posted on forums and Reddit more than two weeks before Synology's warning. Encrypted files get a .L0CK3D extension, and a ransom note called read-me3.txt is left in the folders. The note claims that recovery software will destroy the files and that only the attackers' "C3rb3r Decryptor" will work. It costs several thousand dollars through a dark web portal. As proof, the attackers offer to decrypt one file for free. There is no free decryptor so far.

The name comes from Cerber, a ransomware that was rented out as a service starting in 2016. C3RB3R itself has been around since late 2021. Until now it has mostly hit Confluence and GitLab servers.

Who is affected

Any Synology NAS running a DSM version that still has one of these flaws is affected. Devices whose web interface can be reached from the internet are most at risk. BleepingComputer cites Shadowserver counting more than 380,000 Synology NAS devices exposed online. How many of them are patched is unknown.

Minimum versions from the two advisories:

Older branches such as 7.1 and 6.2 appear only in SA-24:20. If you're still on one of them, move to a supported branch if your model allows it.

What you should do now

1. Update DSM right away, to the latest available version, not just the 2024 patch. Then turn on automatic updates, as Synology recommends.
2. Keep the management interface off the internet. For remote access, use a VPN (an encrypted tunnel into your own network) instead of forwarding a port on your router.
3. Keep backups separate from the NAS, either offline or on a system the NAS can't write to. Snapshots on the same device won't help if the attacker controls the whole device.
4. If you're hit, don't rush to pay. Disconnect the device from the network and save the ransom note and some sample files. Then contact Synology support and, if needed, an incident response provider.

My take: updating is mandatory, but it isn't the core problem. The 2024 flaws have been fixed for almost two years and are still being exploited. A NAS that sits open on the internet and never gets updated will be exposed again with every new flaw. The best protection is to never make the device reachable from the internet in the first place.

Sources

• Synology: press release on C3RB3R (Oct 29, 2026)
• Synology-SA-24:20
• Synology-SA-26:13
• BleepingComputer: Synology warns customers of ongoing C3RB3R ransomware attacks
• heise Security: Schwachstellen in Drupal, Ivanti Connect Secure und Synology angegriffen
• Gridinsoft: analysis citing 360's findings

What happened

The bug is in com.android.phone, the Android service that runs cellular connectivity, calls and SMS. When it handles a specific kind of SMS called a WAP Push message (a control message carriers use for things like configuration data), it doesn't check a length value in the header. A manipulated value turns into a negative array size, the service throws an unhandled exception, and it crashes. That's how BleepingComputer and heise describe it.

It's a zero-click attack: the victim doesn't have to tap anything. Android processes the message before it would reach the inbox. You never see it, only what it does:

• Cellular service drops and ongoing calls are cut off. That includes emergency calls.
• Carriers redeliver messages that weren't acknowledged. According to heise, a single SMS caused outages for up to a week in testing.
• About 20 such messages sent one device into a reboot loop, restarting roughly every 90 seconds. Recovery mode then offers to wipe the data.

According to heise, the crash was reproduced on a Pixel 9 and several Samsung Galaxy devices. The attack takes the phone offline but doesn't steal data. None of the sources report real-world attacks. Because the code is public, though, copying it takes little effort.

What has changed since my post

Not every version is patched. Google shipped the fix ("Fix remote DoS in decodeWapPdu") in the October 2026 updates for Android 14 through 17. GrapheneOS says manufacturers already had it in security previews starting in July. Android 12 and 13 will probably never get a fix, because Google no longer supports them. Sources disagree on exactly which versions are affected: some say 12 through 16, others 12 through 17.

It's not in the October bulletin. According to heise and eSecurityPlanet, it's expected in the November bulletin, rated critical by Google. The November bulletin wasn't online yet as of today. There's no CVSS score (the standard severity scale) so far.

The disclosure didn't go smoothly. Blaszczyk reported the bug to Google on May 5. According to heise, the report was first closed as "Will Not Fix." GrapheneOS thinks this was an internal miscommunication. The fix only improves error handling: the service now catches the exception and deletes the bad message. It does not add the length check the researcher proposed.

What you should do

1. Install the update and restart. Your security patch level is shown under Settings → Security or "About phone." On Android 14 through 17 it should say October 2026 or later. Your phone maker and carrier decide when the update reaches you, not Google.
2. On Android 12 or 13? Check whether your device can still upgrade to a newer version. If it can't, no setting will protect you. Reports say WAP Push can't be turned off, and being careful with suspicious messages doesn't help when you never see the message. At that point it's time for a new phone, especially one meant for emergencies, like an older relative's.
3. Stuck in a reboot loop? Do not choose "wipe data" in recovery mode, or you'll lose everything. According to the researcher, the messages can be removed with ADB (Android Debug Bridge, a tool for controlling the phone from a computer). That takes a computer and some experience. If that's beyond you, get help instead of resetting the phone.

My take

A crash sounds harmless until you think about emergency calls. The deeper problem is Android's update model: Google fixes the bug, and millions of devices on Android 12 and 13 still stay exposed for good. Before you buy an Android phone, check how many years of updates the manufacturer promises.

Sources

• BleepingComputer: New Android SMS of Death exploit can remotely crash unpatched phones
• heise: "SMS of Death": Security flaw crashes Android phones
• eSecurityPlanet: Android SMS of Death Flaw Threatens Calls and Phones

What happened

On Thursday afternoon (US Eastern time), users reported withdrawals they hadn't made. Polymarket first put its international exchange into "cancel-only" mode, meaning traders could cancel open orders but not place new trades. It also paused relayer actions. The relayer is the service that submits transactions to the blockchain on users' behalf. Trading resumed after about an hour. According to BleepingComputer, the incident was marked resolved at 3:05 p.m. ET. SecurityWeek reports that Polymarket's US platform appears to have been unaffected.

Polymarket still hasn't named the vendor. It has only said that one of its third-party providers was compromised and that it referred the case to law enforcement. Security researchers at Hudson Rock and GoPlus traced the code to DebugBear, a UK-based website performance monitoring company. The malicious code came through its RUM script. RUM stands for Real User Monitoring: a small piece of JavaScript that runs in real visitors' browsers and measures how fast a page loads. DebugBear has confirmed "an ongoing security incident," brought in outside incident responders, and told customers to remove the RUM snippet from their sites. Hudson Rock also found a Polymarket production build timestamped 17:59 UTC whose change note mentions removing the DebugBear script.

How the malicious code worked

What the script did not do stands out. Hudson Rock found no code that harvested passwords, seed phrases, or private keys. Instead, the script checked whether a visitor was logged in to Polymarket and then worked through that existing session. Depending on the account type, it either sold the user's positions and moved the proceeds, or sent the position tokens straight to an attacker-controlled address. It took its instructions from DebugBear infrastructure and reported account data back there. For logged-in users, the platform saw what looked like their own activity.

How big the damage is

Estimates vary by source, and Polymarket hasn't published its own figures:

• Hudson Rock saw about $2.19 million in the attacker wallet but explicitly calls that figure unverified.
• BleepingComputer traced about 28.6 million POL (roughly $2.57 million) from that wallet to three other wallets.
• GoPlus estimates about $2.71 million across 710 deposit wallets and 731 addresses, and points out that the number of addresses isn't the number of victims.

What has changed since my post: The post only mentioned "a website monitoring tool." Since then, researchers have named the vendor, trading is back up, and Polymarket has promised to fully reimburse every affected trader. How that reimbursement will work is still unclear. It's also unclear how the attackers tampered with the DebugBear script and whether other DebugBear customers were targeted. So far, Hudson Rock has seen no sign of that. This isn't Polymarket's first incident of this kind either: in June, the platform disclosed a separate third-party compromise involving an injected frontend script, with reported losses of around $3 million.

Why it matters

Every third-party script you embed runs with the same privileges as your own code. A performance tracker can reach the same session, the same buttons, and the same API calls as the actual application. On a site where users move money with a single click, that's a master key. Because this script abused the live session and didn't steal credentials, strong passwords and two-factor authentication would not have helped.

What you should do

If you use Polymarket:

• Check your account history for sales and transfers on October 29 that you didn't make, and report them to Polymarket for the promised reimbursement.
• Review your wallet approvals and revoke any you don't need. According to the analyses, this attack went through the session and not through approvals, but cleaning them up never hurts.
• Log out when you're done trading instead of leaving sessions open.

If you run a website:

• If you use DebugBear RUM, remove the snippet, as the vendor itself recommends.
• Take stock of which third-party scripts run on your site and remove anything you don't really need. Monitoring and analytics don't belong on pages where money moves, or only in a tightly restricted form.
• Set a Content Security Policy (CSP), an HTTP header that defines where scripts may load from and where they may send data. It limits the damage, but it won't stop an attack if an allowed source is itself compromised.
• Where possible, self-host third-party scripts and include them with Subresource Integrity (SRI). The browser then checks a hash and refuses to run code that has been changed.

Your site is only as safe as the scripts it loads.

Sources

• BleepingComputer: Polymarket halts trading after crypto-draining script breach, $2.5M traced
• SecurityWeek: $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack
• SC Media: Polymarket trading suspended following third-party supply chain attack

What happened

According to Trezor's own notice, a report came in through its responsible disclosure program on October 28, 2026. Responsible disclosure means that whoever finds a vulnerability reports it to the vendor first instead of publishing it. A customer in Indonesia had bought the Safe 5 from CryptoBilis via the Tokopedia marketplace in August 2026. After opening it, the customer says they found an extra circuit board between the main board and the display, with a cellular module and an antenna.

The board allegedly reads what's on the screen, including the recovery phrase. That's the list of usually 12 to 24 words that can fully restore a crypto wallet. Whoever has it has the money. Whenever the device is plugged in, the board is said to send the phrase out over a mobile network. None of this is confirmed yet. Trezor has photos and a video interview with the customer, and the device is being shipped to its lab (BleepingComputer, The Hacker News).

What's new since my first post

A few things to add or clarify:

• Not just the Safe 5: The warning covers every Trezor model bought from CryptoBilis since March 2026. That includes stores that resold CryptoBilis-supplied devices, such as its Tokopedia store.
• No known losses: The customer who reported it had already moved their funds off the wallet before finding the board. Trezor has received no loss reports from CryptoBilis buyers so far.
• Other devices look clean: According to Decrypt, Trezor has since inspected four other devices bought from CryptoBilis (a Safe 7, two Safe 5s and a Safe 3) and found no evidence of tampering. So far, this is about a single reported device.
• Replacement: Buyers with proof of purchase can get a new device or a voucher from Trezor.

Why it matters

A hardware wallet is a small device that keeps the keys to your cryptocurrency offline. Its whole point is to protect against malware on your computer. An implant inside the device itself breaks that promise completely. This is a classic supply-chain attack: rather than attacking the manufacturer, someone tampers with the product somewhere on its way to the customer.

This case doesn't stand alone. CryptoBilis was also tied to an implant incident at Ledger, where Ledger confirmed tampering designed to capture the recovery phrase during setup. That's why Trezor already dropped CryptoBilis as a reseller on October 9, before it had any sign its own devices were affected. On October 28, the Singapore Police Force also warned about tampered Ledger devices from some retail stores. Trezor says the reported board appears to work like the Ledger implants, but it won't make a direct comparison while investigations continue. Who is behind it remains unknown.

Who is affected

Anyone who bought a Trezor device since March 2026 from CryptoBilis or from a store selling CryptoBilis stock. Trezor says it has no reports involving other resellers or regions. If you're not sure, check the seller's name on your receipt or ask Trezor Support.

What you should do

• Already set up: Move your funds to a new wallet with a new recovery phrase as soon as possible. Restoring the old phrase on a different device doesn't help, because the phrase itself has to be treated as compromised.
• No other secure hardware wallet at hand: Temporarily use a software wallet or an exchange you trust, and verify the full receiving address.
• Not set up yet: Don't set it up, and never enter an existing recovery phrase on it.
• Don't investigate yourself: Don't open or weigh the device. Trezor says weight is not a reliable test. Keep the device and contact Support.
• Expect phishing: Scammers will exploit this with fake emails, letters and phone calls. No legitimate party will ask for your recovery phrase, Trezor Support included.

My general advice: buy hardware wallets only directly from the manufacturer or from officially listed resellers. Marketplace listings and gray-market stock are a bad idea for a device you trust with your money. Once Trezor publishes lab results, I'll follow up here.

Sources

• Trezor: Implant reported in a Trezor sold by CryptoBilis
• BleepingComputer: Trezor warns of suspected crypto-theft implant in hardware wallet
• The Hacker News: Trezor Warns of Suspected Hardware Implant
• Decrypt: Trezor Warns CryptoBilis Buyers After Report of Hardware Implant in Safe 5

Quite a bit has come out since my first post. Here's where things stand now, including what's still open.

What happened

On October 29, reports surfaced of very large outflows from Binance hot wallets. A hot wallet stays online all the time so the exchange can process withdrawals quickly. The funds went to a freshly created Ethereum address. At first, Binance would only say it was aware of "reports of a potential security issue" (BleepingComputer). Later, it gave $6.3 billion as its estimate of the total impact.

On the cause, Binance has said only that its initial investigation suggests the incident "may involve a compromised DevOps engineer's laptop." From that laptop, the attacker reportedly got into a service container and submitted unauthorized withdrawals. Binance says it has found no evidence that wallet private keys leaked (The Register). It has since admitted that the investigation "uncovered additional points of breach" beyond the laptop. There's no full root-cause analysis yet.

Blockchain analytics firm TRM Labs has laid out how it thinks the attack worked. Preparation started at least 36 hours earlier, with test runs a few hours before the attack. Then a single transaction emptied the hot wallet in about three and a half minutes. Elliptic thinks the attacker got Binance's own systems to sign the transactions instead of stealing keys (The Hacker News). That fits with the claim that no keys leaked, and it doesn't make things any better.

The numbers and what they mean

• Impacted: about $6.3B according to Binance. Chainalysis puts the value at the time of theft at roughly $5.9B. Elliptic says $6.43B.
• Frozen: Tether has frozen more than 1.567B USDT and Circle about 800M USDC. Elliptic puts all freezes combined at $2.84B.
• Still with the attacker: about $3.33B across roughly 43 wallets according to Elliptic, including ETH and BTC.

A note on framing, which also corrects my own post. I wrote that "impacted" is not "stolen". On whether funds actually left, that's settled. The analytics firms clearly call this a theft. It would be the largest crypto theft on record, well ahead of Bybit's $1.5 billion in February 2025. What's still open is the final loss once frozen and possibly recovered amounts are subtracted.

Stablecoins are tokens pegged to a currency like the US dollar. Tether and Circle could freeze funds this quickly because they control these tokens centrally. This time, that helped.

Who's behind it?

TRM Labs attributes the attack with high confidence to TraderTraitor, a North Korean group that has gone after crypto companies for years. Chainalysis also points to North Korea, in part because the funds were mixed with proceeds from the Bitget exploit. Elliptic urges caution until there's a root cause. Binance itself hasn't blamed anyone yet (The Hacker News).

Who's affected

First of all, every Binance customer, because deposits and withdrawals are suspended. Binance expects to restart withdrawals within 48 hours, once it has reworked the withdrawal service. It has pledged to cover losses from its SAFU fund and its own money. SAFU is an emergency fund Binance set up for exactly this kind of event. For now, that's a promise, and we'll see how it plays out.

What you should do now

If you use Binance:

• Once things are running again, check your balances and transaction history. If anything looks wrong, contact support, and only through the app or the official website.
• Turn on 2FA (two-factor authentication, a second code on top of your password) and the anti-phishing code. With that code set, genuine Binance emails include a phrase only you know.
• Expect phishing. After incidents like this, emails and messages show up about "compensation", "account verification" or "recovery services". Binance itself warns against unofficial links. No legitimate party will ask for your password or seed phrase.
• As a general rule, crypto you're not actively trading shouldn't sit on an exchange.

If you run a company: If a single developer laptop can open the way to billions, you have an architecture problem, not just an endpoint problem. TraderTraitor is known for fake job offers, coding tests and tampered software. Treat the devices of DevOps staff with production access like crown jewels. And no single system path should be able to sign large withdrawals without independent approval.

I'll update this once Binance publishes a root-cause analysis.

Sources

• The Hacker News: Binance Suffers Security Breach Affecting $6.3 Billion in Assets
• BleepingComputer: Binance probes potential $5.8 billion crypto theft hack
• The Register: Crypto exchanges still have bad security
• NPR: Binance flags 'potential security issue'

Correcting my post

On X and in the WhatsApp channel I wrote that the package was found on Open VSX, the Eclipse Foundation's extension marketplace used by editors such as Cursor and Windsurf. The sources no longer agree on that point:

• Help Net Security cites Mac security firm Phorion, which says it found the package on Open VSX. In the same article, Ax Sharma of Manifold Security disagrees and says the affected build was the official extension in Cursor's marketplace.
• The Hacker News corrected its story. It now confirms only Cursor's marketplace and says there's no evidence for Open VSX or Microsoft's marketplace.
• StepSecurity, on the other hand, says the version was published to Open VSX and has since been purged there, and that Cursor mirrors Open VSX.

What's certain is that Cursor's marketplace pushed the version out as a normal update. Nobody has reported a malicious version on Microsoft's Visual Studio Marketplace so far. Whether Open VSX itself was affected is still unclear, so if you get your extensions from there, check anyway.

What happened

According to Cursor, the tampered version was in its marketplace for about eleven hours on October 29, 2026, from roughly 2:27 a.m. to 1:35 p.m. PT. Reports put the number of affected users at up to 5,000. If you had auto-update turned on, you got the version without doing anything.

The Hacker News says a 66-line loader had been inserted into the extension's main file, and it ran before the legitimate code. According to the analyses, it did the following:

• It added an outside SSH key with the comment svc-telemetry to the authorized_keys file. That file lists who can log in to the machine over SSH without a password.
• It tried to enable SSH and opened a reverse tunnel to the attackers' server. With a reverse tunnel, your own machine opens the connection to the outside. The attackers then use it to get back in, past your firewall and router.
• It set itself up to survive reboots: a startup item on macOS, a cron entry on Linux and a scheduled task called "SysMon" on Windows.
• It sent details about the machine to the attackers: hostname, username, OS, directories, Git email, public IP, and the names of up to 40 environment variables that looked like credentials. According to the analyses, it did not send their values.

Cursor says enabling SSH probably failed on most macOS and Windows machines because it needs admin rights. The key and the persistence were still installed, though, and the host data still went out. If SSH was already running, the door is open. So far nobody has seen any further malware being downloaded.

How the version got into the marketplace hasn't been made public. There's no CVE number, because this wasn't a software vulnerability being exploited. Someone tampered with the supply chain.

Where things stand

Cursor took its marketplace offline for a while and removed the version. It says it also reviewed access, rotated its own keys and got the attackers' server taken down by the hosting provider. Anthropic has released version 2.1.314. One detail conflicts: Cursor's notice lists 2.1.312 as tampered too, while StepSecurity checked 2.1.312 and 2.1.314 from Open VSX and found nothing in either. If Cursor gave you 2.1.312, check that machine as well.

What you should do now

1. Check the version. Look in your editor's extension list to see whether 2.1.313 (or, in Cursor, 2.1.312) is installed now or was before. Then update to 2.1.314.
2. Uninstalling isn't enough. The backdoor keeps running as separate scripts. Search authorized_keys for the "svc-telemetry" entry and delete it. Also check startup items, cron jobs, scheduled tasks and outbound SSH connections.
3. Use the cleanup scripts. Cursor provides scripts for macOS and Windows plus a list of indicators of compromise.
4. Isolate the machine and rebuild if in doubt. If you find traces, take the machine off the network. Cursor recommends considering a rebuild.
5. Rotate credentials. Change any keys, tokens and sessions the machine could reach, and do it from a clean device.

My take

AI coding assistants run with your permissions, inside your projects and often right next to your cloud keys. That's exactly why they're worth attacking. A trusted name on the package didn't help here, because the tampered build shipped under the real publisher ID. Auto-updates are usually a good thing, but for extensions from mirror marketplaces you should at least know where they come from. A coding extension has no business touching your SSH keys, and that's exactly what endpoint monitoring should catch.

Sources

• Help Net Security: Claude Code extension poisoned with persistent SSH backdoor
• The Hacker News: Official Claude Code VS Code extension
• Cursor: Security notice for Anthropic.claude-code 2.1.313
• StepSecurity: Trojanized Claude Code Extension

What happened

According to advisory SA-CONTRIB-2026-254, the module "doesn't sufficiently protect certain routes and entity fields." Routes are the URLs where Drupal exposes functions. Entity fields are the data fields of objects such as orders or products. This is a missing authorization flaw: the system doesn't properly check whether someone is allowed to perform a given action. The result is an access bypass, meaning someone can get around access restrictions.

BleepingComputer reports that attackers can exploit the flaw without logging in. Drupal only says the bypass "may financially impact the vendor." It has not said how the attacks work or how widespread they are, as The Hacker News also notes.

There is no CVSS score yet. CVSS is the usual 0 to 10 scale for rating how severe a vulnerability is. Drupal uses its own rating system instead and gives this flaw 21 out of 25 points. That rating reflects that the flaw is easy to exploit, that an exploit exists (a tool for taking advantage of it), and that it affects all installations.

A correction on affected versions

My posts on X and WhatsApp said "affected: 0.0.0 to 2.41 and 3.0.0 to 3.3.13." The news coverage used the same wording. That wording is misleading. The advisory itself says "<2.41" and ">=3.0.0 <3.3.13". So every version before 2.41 and every 3.x version before 3.3.13 is affected. Those two versions contain the fix:

• 3.x branch: upgrade to Commerce Core 3.3.13
• Older installs: upgrade to Commerce Core 8.x-2.41

If you already run 3.3.13 or 8.x-2.41, you're protected against this flaw.

Who is affected

BleepingComputer says more than 42,000 websites use Commerce Core, including Fortune 500 companies and research universities. Any Drupal site with the module installed is affected, whether it's a large online store or a small club site that sells tickets. Drupal sites without Commerce are not affected by this flaw.

This isn't the only recent Drupal problem. In May 2026, attackers exploited an SQL injection in Drupal core (CVE-2026-9082), and the US agency CISA added it to its Known Exploited Vulnerabilities (KEV) catalog. About two weeks before this advisory, Drupal patched two remote code execution flaws. Those let attackers run their own code on the server from a distance.

What you should do now

1. Check whether you use Commerce. You can see this in Drupal's module list or in your project's Composer dependencies.
2. Compare the version. If it's below 3.3.13 (on the 3.x branch) or below 2.41 (on the older branch), you're affected.
3. Update right away to 3.3.13 or 8.x-2.41. The flaw is already being exploited, so don't wait for your next maintenance window.
4. Audit your orders. Drupal specifically advises checking orders for inconsistencies, such as unusual prices, discounts, statuses or payment details. Updating closes the hole, but it doesn't undo any tampering that has already happened.
5. Ask your agency or host. If someone else runs your shop, ask them directly whether the update is installed.

I think step 4 matters most. When Drupal says a flaw can cost the vendor money, patching isn't enough on its own. You also need to check whether anyone has already changed anything.

Sources

• Drupal Security Advisory SA-CONTRIB-2026-254
• BleepingComputer: Drupal warns of critical Commerce Core flaw exploited in attacks
• The Hacker News: Hackers actively exploit highly critical Drupal Commerce flaw

What happened

According to GitLab's advisory, the bug sits in the compiler for regular expressions (regex, i.e. text search patterns) that GitLab uses for CI/CD configurations. CI/CD refers to the automated build and deploy pipelines. A crafted regex triggers an integer overflow, a calculation whose result is too large for the space reserved for it, so it "wraps around." The end result is that an attacker can run code on the GitLab server without logging in. Rapid7 traces the root cause to Onigmo, Ruby's regex engine.

It affects self-hosted GitLab Community Edition and Enterprise Edition. GitLab says GitLab.com and GitLab Dedicated are already patched. The fix shipped on October 12 in versions 19.2.8, 19.3.5 and 19.4.2. The next day, Rapid7 published a proof of concept, meaning code that demonstrates the flaw can be exploited.

The Alpine Linux case

As The Hacker News and heise report, an unknown attacker tried to exploit the flaw on Alpine Linux's GitLab server on October 20 and 21. Using a newly registered account, they sent crafted CI configurations. GitLab worker processes crashed eight times, and in four of those crashes the attacker got partway into the exploit. Later attempts on October 25 and 26 were blocked.

It's important to keep the attempt separate from any success. Alpine found no evidence that code ran, but it can't rule that out either. A successful exploit would leave no crash and no trace in the web logs, and some logs from the attack day are missing. So Alpine treated the server as compromised, rebuilt it, reset every password and rotated GitLab's secret keys. Package builds from October 20 to 24 matched records kept outside GitLab, and the signing keys were never on the server.

The most instructive part: on October 13, Alpine mistakenly upgraded to 19.3.4 instead of 19.3.5. Even the later upgrade to 19.3.6 didn't close the hole. That's because GitLab's fix lives in the Ruby that GitLab bundles with its own Linux packages and official images. Alpine's image used a standard Ruby instead. The fixed Ruby versions are 3.3.13, 3.4.12 and 4.0.9.

What has changed since the post

On October 21, GitLab fixed another flaw, CVE-2026-110264, also rated CVSS 10.0. It's also an integer overflow in the regex compiler and also allows code execution without logging in. GitLab says every version from 7.0 onward is affected. The fix is in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Several outlets, including eSecurity Planet, point out that the October 12 patches don't cover this second flaw. I found no reports of active exploitation for CVE-2026-110264, and only CVE-2026-97229 is on the KEV list.

For a sense of urgency: CISA recommends that US federal agencies apply the fixes by November 1, 2026. Formally that deadline only applies to those agencies, but it's a good benchmark for everyone else.

What you should do now

• Update to the latest release, not just the first fix. That means at least 19.5.1, 19.4.3, 19.3.6 or 19.2.9, depending on your version branch. Those cover both regex flaws.
• Check your Ruby if you don't run GitLab from the official packages or images, for example a source install or a distribution image. Ruby needs to be 3.3.13, 3.4.12, 4.0.9 or newer. If you use the alpinelinux/gitlab image, pull 19.3.6 again. Only the October 27 build includes the fixed Ruby.
• Look for traces. Watch for clusters of worker crashes, 502 errors and failed CI jobs since October 12, and for newly registered accounts with odd CI configurations. GitLab provides detection rules for self-hosted instances, including "Onigmo native worker crash."
• If in doubt, do what Alpine did. If you can't rule out a successful attack, rotate passwords, personal access tokens, runner tokens, CI/CD variables and webhook credentials.
• Rethink open sign-ups. At Alpine, a freshly created account was all it took. If you don't need public registration, turn it off.

My take: the danger here isn't just the bug itself. It's the false sense of security after patching. Whether you're actually protected doesn't depend on the GitLab version number alone. It also depends on which Ruby is really running underneath.

Sources

• GitLab: Critical Patch Release 19.4.2 (CVE-2026-97229)
• GitLab: Critical Patch Release 19.5.1 (CVE-2026-110264)
• NVD: CVE-2026-97229
• The Hacker News: CISA adds actively exploited GitLab RCE to KEV
• The Hacker News: Attacker tried to exploit Alpine Linux's GitLab
• heise Security: Cisco firewalls and GitLab flaw under attack
• Rapid7: CVE-2026-97229
• eSecurity Planet: GitLab's second 10.0 flaw in October

What happened

The bug is in the code that sets up new IPv4 connections. It's a race condition, which means two CPUs touch the same data at the same time and the result depends on which one gets there first. That leads to a use-after-free: the kernel reads memory it has already released. Specifically, the kernel hands the IP options from a connection request over to the new socket without copying them. The Hacker News and heise both report that IPv6 is not affected, because there the kernel does copy the options.

According to heise, the faulty commit dates back to October 2015. The kernel fix credits Anthropic researcher Xinyang Ge with reporting the bug. Anthropic says Claude built the exploit itself after "initial prompting." The exploit has two stages. First, the kernel leaks memory addresses, which defeats KASLR (the randomization of where the kernel sits in memory). Then a function pointer gets overwritten so that a command runs as root. If the attacker loses the race, only that one connection attempt fails and the system doesn't crash, so they can just try again. In Anthropic's test, the address leak took 48 minutes and code execution took five more. Anthropic hasn't published the code, the kernel version or the test setup.

There's one important caveat. Anthropic's exploit targeted servers running a service that listens via multipath TCP (MPTCP). That's a TCP extension that spreads one connection across several network paths. Nobody has said yet whether servers without MPTCP are just as exposed. Red Hat says any reachable TCP service is enough to trigger the race. According to heise, Go programs use MPTCP by default.

Why the severity ratings differ so much

The 9.8 comes from the kernel CVE team, and others see it differently. Red Hat gives 5.9 on its CVE page and 8.1 in its machine-readable advisory. Oracle and SUSE give 8.1, and Amazon gives 7.0. The disagreement is mostly about how hard it is to win the race. For me, what counts is this: the attack works remotely, needs no credentials, and a working root exploit exists, even though it isn't public. That's enough to put the update at the top of the list.

No attacks in the wild have been reported so far. Vendors, the CVE record and Anthropic all say nothing about active exploitation, and the flaw isn't in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Who is affected and where patches exist

Every kernel from 4.4 onward running IPv4 is affected, which covers practically every Linux server. Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Here's where the distributions stood as of October 29, according to The Hacker News:

• Debian: Trixie and Bookworm have patches.
• Oracle Linux 7 to 10 (UEK): Patched since October 16.
• SUSE: openSUSE Leap 16.0 and SUSE Linux Micro 6.2 are patched. Some SLES versions are still in testing.
• Amazon Linux 2023: The kernel6.18 and kernel6.12 packages are patched. The rest is still pending.
• Ubuntu (16.04 to 26.10): No fix released yet.
• RHEL 8, 9, 10 and OpenShift 4: No fix yet. Red Hat first said fixes were "deferred to a future update." RHEL 7 is not affected.

What you should do

1. Patch as soon as you can. Where updates are out, install them and reboot. A new kernel only takes effect after a restart.
2. Watch the advisories. If you run Ubuntu or RHEL, check them every day.
3. Start with exposed systems. Servers whose TCP services can be reached from the internet go first.
4. Check for MPTCP. For Go services, the Go Security Team suggests GODEBUG=multipathtcp=0 as a stopgap. The team itself calls this fragile and says systems without MPTCP may still be vulnerable. It doesn't replace a patch. Red Hat says no mitigation meets its standards.

My take

Several experts reviewed and approved this bug eleven years ago, and now an AI model has found it, exploit included. heise author Jürgen Schmidt expects "a huge wave of vulnerabilities." I think that's realistic. Whatever defenders can find, attackers will find too, sooner or later. That makes patch cycles that take weeks a risk in themselves.

Sources

• The Hacker News: Linux Kernel TCP Flaw with 9.8 CVSS
• heise Security: Erneut kritischer Bug in Linux-TCP/IP aufgedeckt (German)
• CVE record CVE-2026-98432 (CVEProject)

What happened

The bug is a race condition, a flaw where the outcome depends on timing: whoever gets in at the right moment "wins the race." The WordPress 7.1.4 release notes describe it as "a race condition during core updates that could lead to remote code execution," reported by security researcher Umut Bayram. Remote code execution (RCE) means an attacker can run their own code on the server from anywhere.

Here's the rough picture. During a full-package core update, WordPress first unpacks the new files into a staging directory under wp-content/upgrade. That path is predictable, and on many servers it can be reached from the internet. The staged copy also contains the WordPress installer. According to The Hacker News, an attacker who reaches the installer during that short window can get all the way to PHP code execution, with no login required.

It's not trivial to pull off. Several conditions have to line up: a full-package update, public web and PHP access to the staging tree, a known or guessed path, and enough time before WordPress deletes the temporary files. In lab environments the directory existed for only a few seconds, heise Security reports, which is why SecurityWeek calls the attack complexity high. The flaw is rated CVSS 8.1 (high). No CVE number has been assigned so far.

The attack attempts

Security firm Wordfence (Defiant) says it blocked 62,969 attacks targeting this flaw within 24 hours. The first hit on its new firewall rule came nine minutes after the rule went live. In the first 21 hours alone, more than 18,500 requests went after the staged installer. Two of the most active sources kept polling small groups of sites for about 14.5 hours, apparently hoping to catch an update in progress.

The key distinction: these are attempts. None of the sources has reported a confirmed successful compromise so far.

What has changed since my post

We now know more about the fix. The current version is 7.1.4, and older branches get backports all the way down to 4.7.39, for example 7.0.8, 6.9.11 and 6.8.12. According to SecurityWeek, WordPress now randomizes the staging directory name, adds an index guard and no longer promotes configuration data from the staging area. Version 7.1.4 also fixes 22 other security issues, including several XSS bugs. Versions older than 4.7 no longer get any security updates.

Why it matters

What makes this flaw nasty is that it strikes at the exact moment you're doing the right thing: updating. As long as a site runs an affected version and the staging directory stays reachable, every future full-package core update opens that window again. The late-September WordPress flaw was also attacked within hours of disclosure. With WordPress, the gap between patch and attack is effectively zero.

What you should do now

• Update: to 7.1.4 or the backport for your branch. Check under "Updates" in the dashboard which version is actually running.
• Verify automatic updates: they are normally on for security releases, but hosts, configuration or file permissions sometimes block them. Don't assume they ran. Check.
• Lock down the staging directory: Patchstack recommends denying web access to wp-content/upgrade/ and making sure the directory isn't listable.
• Check your logs: look for suspicious requests to PHP files under wp-content/upgrade, especially if you updated after October 28.
• Look for traces: unknown admin accounts, plugins nobody installed and PHP files that don't belong.

My advice: if you look after several WordPress sites, check every single one today instead of trusting that updates "run automatically." The attackers are checking every single one too.

Sources

• The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts
• SecurityWeek: Fresh WordPress Vulnerability in Attackers' Crosshairs
• heise Security: WordPress update fixes code execution flaw, exploit attempts observed (German)
• WordPress.org: Version 7.1.4
• Patchstack: WordPress 7.1.4 Security Release

What happened

AI coding agents like OpenAI Codex or Claude Code automatically read instructions files in their working directory, meaning the folder you start them in. For Codex that file is AGENTS.md, for Claude Code it's CLAUDE.md. These files usually hold project rules like "use pnpm" or "tests live in /test". The agent treats their contents as instructions to follow.

According to BleepingComputer, the customer's working directory was their Downloads folder. An AGENTS.md sat in it, disguised as ordinary engineering notes. It told the agent to install the npm package "function-color". npm is the package manager for JavaScript. Per The Hacker News, that package pulls in another one ("function-flag"), a downloader that fetches and runs a Windows payload. The file also told Codex to register a server in its global configuration, so the change would have affected sessions in completely different folders too.

How the file got there is still unknown. Forever Security showed that a web page can drop a file named AGENTS.md into the Downloads folder. Chrome, Edge and Firefox save there by default and only show a notification. BleepingComputer reproduced this proof of concept (a demonstration that the attack is feasible) with a harmless file. Whether a real attacker used this route has not been established.

New since the post: lab results and no patch

On the customer's machine it stayed an attempt. In the lab, things looked different:

• Codex: According to BleepingComputer, a harmless test payload (opening the calculator) worked in about 90 percent of attempts.
• Claude Code: A planted CLAUDE.md, framed as internal gateway setup, tried to redirect API traffic to a server controlled by the researchers. That would have exposed the login token and let the server impersonate the model and send back commands. It worked about half the time. Claude usually asks for approval before such changes and often refuses suspicious ones.

There won't be a patch. Forever Security itself says there is nothing for OpenAI or Anthropic to fix. The agent does exactly what it was built to do: follow the instructions in its working directory. Neither report includes a statement from the vendors. BleepingComputer notes both already recommend running agents from the project directory.

Why it matters

At its core this is prompt injection: outside text gets treated by the model as a command. What's new is the location. Not a booby-trapped repository, not a malicious web page in a chat, but a folder where every browser drops files without asking. And this isn't an edge case. According to BleepingComputer, hundreds of Forever Security customers launch agents like Claude Code, Codex or Cursor CLI from their Downloads folder, with more than 1,300 sessions from Claude Code alone.

I see this as a wake-up call. Instructions files look like documentation, but they act like a script running with the agent's permissions. And those are often the same as yours.

Who is affected

Anyone running AI coding agents locally, especially if they start them in their Downloads or home folder. So far, one stopped attempt at a single customer is confirmed. No damage is known.

What you should do

• Never start agents in your Downloads or home folder. Always use the root of the relevant project.
• Read unfamiliar AGENTS.md, CLAUDE.md and similar files before your agent does. That includes freshly cloned repositories.
• Check your configuration: for Codex, look for unknown server entries in config.toml. For Claude Code, look for an unexpected ANTHROPIC_BASE_URL or other API endpoints in settings.json.
• Keep approval prompts and sandboxing on. Be suspicious of any file that asks the agent to turn them off.
• Allow package installs only after approval. No auto-approve for npm, pip and the like.
• Rotate tokens if you find something. If you find a planted file, assume your login token has leaked.
• Test unfamiliar code in isolation, for example in a VM or container.

In short: treat instructions files like untrusted code. To your agent, that's exactly what they are.

Sources

• The Hacker News: Malicious File in Downloads Folder
• BleepingComputer: AI coding agents hijacked using AGENTS.md file in Downloads folder

What happens

The tool takes a stolen token and pushes a new workflow to every repository that token can write to. A workflow is an automation in GitHub Actions, GitHub's built-in CI/CD system. The planted workflow writes every secret the job can read into its own run log. The secrets are encoded so GitHub's log masking doesn't catch them. The tool downloads the log through the API and deletes the run seconds later.

The tricky part is that the data leaves GitHub through GitHub itself. There is no attacker server and no outbound connection for a firewall to block. According to Wiz, one variant also goes after the secrets of individual deployment environments, which are often production credentials. Since around October 19, another version also searches self-hosted runners for credentials. Wiz calls that variant buggy and has not seen it succeed.

How big is it?

In my original post I cited Dark Reading's figure of thousands of affected developer repos. Wiz's numbers are more precise: more than 13,500 planted branches from over 850 compromised accounts, tracked since September 15. Wiz does not say how many organizations actually lost secrets. On October 24 the campaign was still running, although about two-thirds of the accounts were no longer available on GitHub by then.

According to Wiz, the tokens come from sources including infostealer logs and earlier supply-chain attacks, such as the March compromise of the Trivy scanner. Infostealers are malware that harvest passwords and tokens from developer machines. No software vulnerability is involved, so there is no CVE and no patch. The attack abuses ordinary write access.

What has changed since the post

One detail needs adding: since July 28, GitHub has held potentially malicious workflow runs until someone with write access approves them. That only applies to public repositories on github.com. Every public Gheist run Wiz checked was stuck in that hold, which is why the title of Wiz's report says the attack "stumbles."

The hold does not cover private repositories or GitHub Enterprise Server. In those environments, Wiz saw audit logs showing the runs completing and then being deleted. In one case, cloud credentials from the same organization were used hours later to enumerate AWS Secrets Manager. Wiz doesn't say exactly where those credentials came from.

Who is affected

Any organization is at risk if its members or automation accounts hold tokens with write access that may have leaked somewhere. Private repos and self-hosted Enterprise Server instances are the most exposed.

What you should do

Check:

• Look for branches that start with ci-sync- and contain only a new workflow file named sync-check.yml, committed with the message "ci: sync config."
• Search GitHub audit logs for runs on those branches that were deleted shortly after finishing, and for the gheist user agent.
• If your workflows use OIDC, which lets a workflow sign in to the cloud with short-lived credentials, search your cloud audit logs for role assumptions with ci-sync- in the subject. This works even without GitHub logs.

If a repo is affected:

• Rotate every repository, organization and environment secret the repo could access. Deleting the runs doesn't undo the leak.
• Revoke the tokens that pushed the commits, and check their owners' machines for infostealers.
• If one of these branches ran on a self-hosted runner, treat the machine and its cloud role as compromised.
• Don't approve held sync-check runs.

Harden:

• Require reviewers for environments that hold production secrets.
• Restrict OIDC trust policies to protected branches or environments.
• Use GitHub Apps or short-lived fine-grained tokens instead of classic personal access tokens.

My take: Gheist shows that a token with write access is effectively a key to every secret in a repo. The hold for public repos helps, but the valuable data usually lives in private repos, and there you have to protect yourself.

Sources

• The Hacker News: Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs
• Help Net Security: Private repos still leak secrets to Gheist
• Dark Reading: 'Gheist' Weaponizes GitHub Tokens to Steal Cloud Secrets
• Wiz Research: Gheist

Since I posted this on X and in my WhatsApp channel, there has been new reporting on the next Xbox. You'll find it below.

Nintendo: Switch 2 is selling, just more slowly

According to Nintendo's quarterly figures, Switch 2 had shipped 23.68 million units worldwide by June 30, 2026 (Gematsu). The key word is "shipped." That's sell-in, meaning what Nintendo delivered to retailers. How many units actually reached customers (sell-through) only retailers know. VGChartz estimates about 21.84 million.

There is a flip side. Hardware sales in the first quarter were down 34.4 percent year over year, and Nintendo expects 16.5 million units for the fiscal year ending March 2027 (Game Developer). That's a normal second year after a very strong launch, not a dying market. The next quarterly results are due in early November.

Microsoft: Project Helix is official, the date isn't

At GDC in March 2026, Microsoft unveiled the next Xbox under the codename Project Helix (Xbox Wire, VGC). It runs on a custom AMD SoC ("system on a chip," with CPU and graphics on one piece of silicon) and is designed to play both Xbox and PC games. Alpha dev kits, meaning early developer hardware, are due to reach studios in 2027 (Gematsu).

New since my post: In October, Pure Xbox relayed a Fortune report saying an Xbox handheld would come first, in late 2027, with Helix itself following in 2028. Internal price projections are said to be well above $1,000 unless Microsoft subsidizes the hardware. Microsoft has confirmed neither the date nor the price. This is a report, not an announcement. Still, it fits the picture of a next generation that's later and pricier. According to Pure Xbox, Xbox leadership is also planning a "family" of devices, some of them built by partners. That doesn't sound like the end of consoles either.

Sony: PS6 in the works, no date

Sony said in May and again in August 2026 that the PS6's launch date and price haven't been decided (Push Square, May, Push Square, August). The company's leadership pointed to the component shortage (TechRadar), especially high memory prices (Insider Gaming). This is where AI comes in. Data centers for generative AI buy huge amounts of memory, and that pushes prices up for everyone else. Console makers end up paying for the AI boom too.

So a 2027 launch for the PS6 and the next Xbox is not confirmed. That date comes from leaks. According to Bloomberg, a delay to 2028 or 2029 is possible (Vice).

The market: growth, but fuzzy numbers

Every market forecast I found projects growth through 2032: IMARC at $59.4 billion (IMARC), Meticulous Research at $67.2 billion (Meticulous), Stratistics at $46.4 billion and SNS at $55.4 billion. Their starting figures contradict each other, though, so treat these numbers only as a rough range. None of them predicts consoles falling to zero.

What is actually shifting: according to Newzoo, PC already brings in more revenue than consoles and is growing faster, at 6.6 percent a year versus 4.4 percent (GameDev.net, ChannelNews). The headlines say "by 2028," while the summaries say PC is already ahead. I haven't seen the original report.

What this means for you

• If you want a console now, there's no "end" to wait for. PS5, Xbox Series and Switch 2 will be supported for years.
• If you're waiting for the next generation, plan for 2028 rather than 2027, and for higher prices. There are no official prices. Figures like "$1,000" are speculation.
• If you're torn between PC and console: the line is blurring. Helix is meant to run PC games, and Xbox features are coming to Windows. Your game library matters more than the box.
• When you see headlines about sales figures, check whether they mean "shipped" or "sold."

My take: consoles aren't disappearing. They're becoming more PC-like and more expensive, and they're arriving later. Part of that comes from the AI boom.

Sources

• Gematsu: Switch 2 worldwide sales top 23.68 million
• Game Developer: Switch 2 unit sales down 34.4% YoY
• Xbox Wire: Building the Next Generation of Xbox
• Gematsu: Project Helix alpha dev kits to ship in 2027
• Pure Xbox: Report – handheld 2027, Helix 2028
• Push Square: Sony still hasn't decided when to launch PS6
• Insider Gaming: PS6 launch window uncertain amid memory prices
• GameDev.net: Newzoo on PC vs. console revenue
• IMARC: Gaming console market

What happened

The flaw now has an ID: CVE-2026-111497. It is known as "Node2Shell", and depending on the source also as HTTP2Shell, Broccoli2Shell or Brotli2Shell. It is an out-of-bounds write: the program writes data past the end of a reserved memory area and overwrites whatever sits behind it. According to Brandefense and other analyses, the decoder treats a certain invalid stream as "need more input" instead of a format error. It then keeps adding data to an internal eight-byte buffer and writes past the end of it.

The impact ranges from crashes to leaking process memory to running attacker code. Google scores the flaw 9.2 under CVSS 4.0 (critical). Microsoft gives it 8.1 under CVSS 3.1 and rates exploitation as "more likely" (SecurityWeek).

Brotli versions 1.0.3 through 1.2.0 are affected on all platforms. OpenAI Codex Security found the bug. According to OpenAI, the actual fix had been in the Brotli source since February but wasn't treated as a security fix back then. A new release only shipped now.

What changed since my post

When I posted, nobody knew whether the flaw was being exploited. That has moved: the US agency CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalog on October 27. US federal agencies must patch by November 10. CISA hasn't said who is attacking or how.

So far, the public evidence is attack attempts against honeypots, which are decoy systems set up to log attacks. ELLIO logged a malicious request against Node.js 24.22.0 on October 26. ELLIO says the exploit was broken and produced no shell in 50 tests. Previdian logged an attempt on October 27 and stressed that this does not mean it succeeded. No successful break-ins on production systems have been reported publicly.

The lab results are a different story. Imperva achieved code execution on the official Node.js image, though not on every attempt. Public proof-of-concept (demo) exploits exist. People are still arguing over whether the bug realistically leads to code execution or mostly causes crashes. In practice it doesn't matter: you have to patch either way.

Who is affected

You're only exposed if you decode Brotli data from an untrusted source. That could be compressed HTTP request bodies, responses from servers you don't control, or compressed files. A bare Node.js HTTP server doesn't do this by itself, but middleware such as Express 5 or body-parser 2 does. In .NET the path is off by default. It runs through ASP.NET Core request decompression, HttpClient automatic decompression, or direct use of BrotliStream/BrotliDecoder. Apache and Nginx are considered unaffected in their default configurations.

Patched versions according to SecurityWeek and heise:

• Brotli: 1.0.10, 1.1.1, 1.2.1
• Node.js: 22.23.4, 24.22.1, 26.12.1 (since October 21). Older end-of-life lines get no official fix.
• Python: Brotli 1.2.1 and brotlicffi 1.2.1.0
• .NET: 8.0.33, 9.0.22, 10.0.14 and .NET 11 RC 3 (since October 25), plus Visual Studio 2019, 2022, 2026
• PowerShell: 7.4, 7.5 and 7.6 with current updates
• Bun, Envoy and Istio have shipped updates too.

According to the broccoli2shell.com tracker, DuckDB, Apache Arrow, 7-Zip-zstd, p7zip and EDK II are still unpatched. Broadcom also lists VMware SDDC Manager as affected, with patches still pending. Java, PHP, Ruby and Go bindings that wrap the C library may be affected as well.

What you should do

1. Update runtimes: bring Node.js, Bun, .NET and PowerShell up to the versions above.
2. Check dependencies: search Python projects for Brotli and brotlicffi, including as transitive dependencies. Do the same for Brotli bindings in other languages.
3. Restart services: running processes keep using the old code until they restart.
4. Rebuild container images on a patched base image. Updating the host doesn't fix the container.
5. Turn off Brotli decoding for now if you can't update yet. Aikido has guidance on this.

My take: so far there are only honeypot attempts and no confirmed break-ins. Still, a KEV listing, public PoCs and lab code execution are reason enough not to leave this for the next maintenance window. If you run Node.js services with Express or .NET APIs with request decompression yourself, get it done this week.

Sources

• SecurityWeek: Node2Shell Brotli Flaw Triggers Patching Across Microsoft, Node.js, Python Packages
• SecurityWeek: CISA Warns of Node2Shell Exploitation as Honeypots Log Attack Attempts
• heise Security: Brotli decoder flaw not only in Node.js but also Bun, Python and more (German)
• Sophos: Node2Shell in active exploitation
• Aikido: Node2Shell analysis and fix
• Broccoli2Shell tracker

What happened

PHP2Shell is the collective name for two critical flaws in PHP: CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution (RCE), meaning an attacker can run arbitrary code on the server remotely, and without logging in. According to BleepingComputer, details and proof-of-concept code leaked before the patches. The PHP team said none of them worked. Amazon Threat Intelligence reported exploitation attempts four days before the patches came out. Cloudflare, watchTowr, Patchstack and others judged those early attempts unsuccessful.

Then came the evidence from honeypots. A honeypot is a deliberately vulnerable decoy system that logs attacks. Researcher Adel Karimi (Perplexity) observed an attack on an Apache mod_php setup running PHP 8.4.26. The chain had four stages of HTTP requests: exhaust memory, leak memory contents, and finally run a shell command. According to SecurityWeek, 35 shells were launched across three honeypots on October 24. They came from two IP addresses: one produced 3 shells, the other 32. No second-stage payload download was observed. Marcus Hutchins (Expel) confirmed the findings.

One distinction helps here. These are honeypot numbers, not a count of confirmed victims. Karimi himself notes that his single-worker setup favored the attacker. The data says nothing about how reliable the exploit is on other configurations. But one thing is clear: attempts have turned into successful code execution.

What has changed since our post

Three things I need to add or correct:

• Patches exist. Our post listed the patch status as unclear. In fact, the PHP team fixed the flaws on October 21. According to several distribution and industry sources, including AlmaLinux and computingforgeeks, the fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• CISA confirms exploitation. On October 23, the US agency still reported no successful attacks and published a Sigma detection rule. On October 26, it added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog, as reported by BleepingComputer and SecurityWeek.
• Unit 42 walked it back. Palo Alto Unit 42 had linked an attack on a European government agency to PHP2Shell. It now says, per The Hacker News, that it cannot confirm initial access came through these CVEs. The attack itself still happened. Only its link to PHP2Shell has been withdrawn.

Who is affected

PHP is affected, and PHP runs a large share of the web. According to BleepingComputer, VirusTotal estimates more than 5.1 million publicly reachable PHP hosts. The sources don't say how many of them are actually vulnerable. Older branches, 8.1 and below, are especially tricky because they no longer get official updates (end of life). For those, fixes only come as backports from distributions or commercial vendors such as TuxCare.

There is also a third, separate flaw: CVE-2026-115560. It has no patch yet, only mitigation guidance. According to PHP, it can only be exploited with an unusual combination of configuration and application code.

What you should do

1. Update PHP, either to the versions above or to your distribution's patched packages. Note that Debian, Ubuntu and others often backport the fix without bumping the version number. What counts is your distribution's security update, not the PHP version string it reports.
2. Restart your PHP processes. That means PHP-FPM, Apache with mod_php, or whatever you run. Running workers keep the old code in memory.
3. Use the interim mitigation where you can't patch right away. PHP recommends session.upload_progress.enabled=0. This is also the recommended mitigation for CVE-2026-115560. According to industry sources, though, it doesn't cover every PHP2Shell attack path and is no substitute for updating.
4. Look for traces. Search your logs for unusual clusters of out-of-memory errors and crashed workers. Check web directories for unknown PHP files, which could be webshells. If you run a SIEM, you can add CISA's Sigma rule.
5. Take end-of-life versions seriously. If you still run PHP 7.x or 8.0/8.1, use this as your reason to upgrade now.

My take: these flaws are demanding for attackers, and the honeypot successes came from a favorable setup. I still wouldn't rely on that. With a KEV listing, public exploit code and working shells, the order is: install the patch, restart the processes, check the logs. For self-hosted systems running PHP web apps, ideally today.

Sources

• BleepingComputer: PHP2Shell security flaws now successfully exploited in the wild
• BleepingComputer: CISA confirms PHP2Shell vulnerabilities now exploited in attacks
• SecurityWeek: PHP2Shell exploitation moves from probes to working shells
• The Hacker News: PHP2Shell exploitation and Unit 42 retraction
• AlmaLinux: Patched PHP packages released
• computingforgeeks: Check and patch PHP2Shell
• TuxCare: Patches for PHP 5.2 through 8.1

What happened

A bootkit is malware that hooks into a computer's startup process and loads before the operating system. Antivirus tools barely see it there, and reinstalling Windows won't necessarily remove it. Secure Boot is supposed to prevent exactly that: the UEFI firmware (the modern successor to the BIOS) only starts bootloaders whose signatures it trusts.

BlackX abuses Baton Drop (CVE-2022-21894). This flaw sits in old Windows boot managers that Microsoft still signed, and it can be used to defeat Secure Boot. The attackers used it to enroll their own keys (Machine Owner Keys), which let them load any EFI file they wanted. Kaspersky calls the implementation "remarkably similar" to the well-known BlackLotus bootkit, and The Hacker News describes BlackX as an updated version of it. BlackLotus's source code was never fully public, so the attackers either rebuilt it by reverse engineering or got it some other way.

One point matters for context: BlackX wasn't how the attackers got in. They were already inside the network with administrator rights before installing the bootkit, and it's unknown how they got there. The bootkit was there to keep a persistent, quiet foothold.

Once running, BlackX loads a kernel driver that shuts down security processes and Windows monitoring features such as ETW, the event tracing system. The driver is signed with a certificate that has since been revoked. Some routines only run if Kaspersky or Avast products are installed. I need to correct my WhatsApp post here: Kaspersky says these particular routines didn't work against its products. On top of that come espionage tools, including a remote access trojan that uses Google Drive, OneDrive and Yandex.Disk as its command channel, and a loader called OxiDLLRunner.

Who is behind it?

Kaspersky attributes the campaign to the China-linked group APT41 with "medium confidence." That's an informed assessment, not proof. ESET sees similarities to its June 2026 research on FishMonger, a group counted under the APT41 umbrella, but won't confirm a link without comparing samples.

Why patching alone isn't enough

This is the real story. The Baton Drop patch fixes the boot manager, but the old vulnerable boot manager still carries a valid signature, so an attacker with admin rights can simply bring it along. The only fix is a revocation: an entry in the firmware's blocklist (DBX) that marks the old "Windows Production PCA 2011" certificate as untrusted. Windows doesn't apply this step on its own. Admins have to trigger it, and Kaspersky says the attackers count on the fact that many organizations never have.

New since my post: the PCA 2011 certificate expired on October 19, 2026. That doesn't protect you, because firmware keeps loading the old binaries as long as the certificate isn't blocklisted. According to its guidance on CVE-2023-24932 (last updated September 30, 2026), Microsoft still hasn't set a date for automatic enforcement. We're still in the "Deployment Phase."

Who is affected

The known targets were diplomats in Central Asia. No German or other Western victims have been reported. But in principle, any Windows machine with Secure Boot that lacks the revocations is exposed, and that's likely a very large number, in companies and government agencies included. Needing admin rights limits the risk but doesn't remove it. If you're specifically targeted, you lose a layer of protection you thought you had.

What you should do

• Install Windows updates. That's the baseline.
• Actively apply the Secure Boot revocations following Microsoft's guidance: add the "Windows UEFI CA 2023" certificate, update the boot manager, then add PCA 2011 to the DBX. Afterwards, check that the status actually took effect.
• Test first and create recovery media. A revocation can't be undone while Secure Boot is on, not even by reformatting. Old boot USB sticks and recovery media may stop working. Start with one device per hardware model.
• Keep firmware (UEFI) up to date so devices can take the new certificates cleanly.
• Keep admin rights scarce. BlackX needed them before it could do anything.

My take: Secure Boot is only as strong as its blocklist. A green "all updates installed" tells you nothing about that.

Sources

• BleepingComputer: BlackX UEFI bootkit exploits Baton Drop flaw to bypass Secure Boot
• The Hacker News: BlackX UEFI Bootkit Bypasses Secure Boot
• Microsoft: Windows Boot Manager revocations for CVE-2023-24932
• Borncity: BlackX bootkit – Windows protection remains incomplete despite updates

What happened

According to BleepingComputer, Quest discovered the access on October 21, 2026, and reported it the next day in an 8-K. That's a mandatory filing with the US Securities and Exchange Commission (SEC), which listed companies use to disclose material events. SecurityWeek carried the Associated Press report, which says Quest believes "certain patient records" were accessed.

Quanum LSM is a web platform for clinicians, hospitals and their staff. They use it to order lab tests, view results, track order status and order supplies. It isn't a patient portal, but it's where patients' order and result data comes together.

What has changed since the post

In the WhatsApp post I said there was no confirmed information about the data types. That's only partly true now. TechCrunch reports that Quest confirmed protected health information was taken, specifically "personal information and patient records." Quest is still working out which fields were involved, such as names, dates of birth, insurance details or actual results.

We now also know:

• Quest shut Quanum LSM down. Customers have been told to use paper requisitions or the separate Quanum eLabs portal. Essential Insights and LabHQ have been paused as a precaution (BleepingComputer).
• Quest says practices connected directly through lab system interfaces (LIS) or their electronic medical records (EMR) are not affected.
• Federal law enforcement has been notified, and outside security experts are helping with the investigation.
• Quest says the incident is unrelated to the PHP vulnerability that was in the news the same week (SecurityWeek/AP).
• No threat group has claimed the attack so far.

Still unknown: the number of victims, the way in, and who did it. There's no CVE and no patch, because no specific vulnerability has been named. Be careful with articles citing 11.9 million victims. That number comes from the 2019 AMCA incident at a billing collections vendor and has nothing to do with this case.

Why it matters

Lab data is about as sensitive as it gets. A test order can reveal pregnancies, infections, drug screenings or chronic conditions. Unlike a password, none of that can be changed. It's also valuable to scammers because it makes their phishing believable: someone who knows your doctor, your lab and your test date sounds legitimate on the phone.

There's a structural problem too. The breach hit a portal used by third parties, meaning practices and hospitals. Patients never use this system themselves and often don't know their data is stored there. It's also not Quest's first incident: per the AP, data on about 34,000 people was exposed in 2016, and the AMCA breach followed in 2019.

Who is affected

Mainly patients in the US whose tests were ordered through practices or hospitals using Quanum LSM. Readers in Germany are unlikely to be directly affected. The lesson applies anywhere labs, practice software and outside portals exchange data, though.

What you should do

As a patient (especially in the US):

• Watch for official notices from Quest or your provider. Under HIPAA, the US health privacy law, affected people must be notified no later than 60 days after discovery.
• Be suspicious of unexpected calls or emails about lab results, outstanding payments or "identity checks."
• Don't confirm personal details through links in messages. Call your provider yourself at a number you already know.
• Check your insurance statements for services you never received.

As a practice, hospital or IT lead:

• Take stock of which external portals process patient data and who has access to them.
• Make sure your incident plan covers a vendor portal going down. Quest had to move customers to paper and backup portals on short notice.
• Require multi-factor authentication for web portals that handle health data, and remove orphaned accounts.

I'll update this post once Quest releases a victim count or explains how the attacker got in.

Sources

• BleepingComputer: Quest Diagnostics confirms data breach exposed patient records
• SecurityWeek (AP): Quest Diagnostics reports cyber breach affecting certain patient records
• TechCrunch: Quest Diagnostics confirms patients' personal and health data was compromised
• MedicalDaily: Quanum portal breach, number of affected people unknown

What happened

On October 19, Capcom detected suspicious activity, blocked the access and confirmed the same day that an unauthorized third party had gotten in. On October 20 the company set up an internal incident response team, and on October 21 it reported the incident to the Osaka Prefectural Police and Japan's data protection authority, the Personal Information Protection Commission. Capcom hasn't said how the attackers got in. It only says it has identified the attack method and put countermeasures in place. As of the latest reports, no group has claimed responsibility (Help Net Security).

What data was exposed

According to Capcom, BleepingComputer and SecurityWeek:

• 11,774,247 records containing an email address plus account metadata: account creation date, last login, number of logins and the IP address used for the last login.
• 43 records that also include date of birth, gender, country/region and nickname.
• 196 accounts where the attackers changed the login password, locking the owners out. Capcom has since reset those passwords.
• Not affected, according to Capcom: credit card data. Capcom also says it hasn't found that any passwords customers set themselves were compromised.

I need to correct my own post a little here. It said "change the password", which made it sound like passwords had leaked. Based on what we know now, they didn't. But the attackers were able to change passwords on 196 accounts, so they had at least some write access to account data. Capcom is still investigating how far that access went. A new password is still a sensible precaution, but it's not the most important step.

Why it matters

An email address on its own sounds harmless. Combine it with the knowledge that someone has a Capcom account, when they last logged in and from which IP address, and you have the raw material for convincing phishing. Phishing means fake messages that try to lure you onto a cloned login page or slip you malware. After news like this, an email saying "We reset your password following the incident, please confirm here" looks worryingly plausible. Capcom itself explicitly warns about emails and messages pretending to come from Capcom.

The IP address can also roughly reveal where someone was and which ISP they were using. For most of the people affected that's no big deal, but for targeted attacks it's one more piece of the puzzle.

A side note: this isn't the first time Capcom has been targeted. In 2020 the company was hit by the Ragnar Locker ransomware group. Capcom said the attackers got in through an old VPN device.

Who is affected

Anyone with a CAPCOM ID account, for example for Capcom's web services or online games. With 11.7 million records worldwide, if you have an account you should assume you're on the list. Capcom plans to notify affected customers in stages and has set up regional support channels: in the Americas through the Capcom USA support form, in Europe through Capcom Europe's contact form. Capcom says your registered email address can still be used.

What you should do now

1. Distrust emails, texts and calls "from Capcom". Don't click links or open attachments. If you want to check something, go to Capcom's website yourself in your browser.
2. Change your CAPCOM ID password as a precaution while the investigation continues.
3. Replace that password anywhere else you reused it. A password manager makes this much easier long term.
4. Check that you can still log in. If you can't, you may be one of the 196 accounts. Contact official support directly, not through a link in an email.
5. Turn on two-factor authentication wherever it's offered, especially for accounts tied to the same email address.

In my view, step 1 matters most. The real risk from this breach is the emails that will show up over the coming weeks.

Sources

• Capcom: Notice and Apology Regarding Customer Information Affected Through Unauthorized Access
• BleepingComputer: Capcom confirms data breach affecting 11.7 million accounts
• SecurityWeek: 11 Million Impacted by Capcom Data Breach
• Help Net Security: Capcom data breach exposes 11.7 million account records

What has changed since my post

When I posted this on X and the WhatsApp channel, the patch situation was still unclear. That is no longer the case. According to Collabora's GitHub advisory, the flaw is fixed in version 26.4.303 of the app. The advisory also adds something my post didn't cover: simply disabling the app does not protect you.

What exactly is broken

The affected component is the Nextcloud app "Collabora Online – Built-in CODE Server", technical name richdocumentscode. CODE is the developer edition of Collabora Online, a browser-based office suite. The built-in variant runs directly inside the Nextcloud server. That is convenient because you don't need a separate office server.

The flaw is an OS command injection. Input from a web request ends up unchecked in a command passed to the operating system. With a crafted request, an attacker can run their own commands with the web server user's privileges. Per the advisory, the bug sits in the app's proxy.php. It can only be exploited while the built-in CODE server is not running, for example after a container restart, an update or a crash. That sounds like a hurdle, but in practice it happens regularly.

According to Collabora, standalone Collabora Online servers and the separate "Nextcloud Office" connector app (richdocuments) are not affected. This is only about the built-in variant.

What attackers are doing with it

This isn't a theoretical risk. According to The Hacker News and an analysis by Corgea, attacks have been going on since at least early September 2026. The attackers planted web shells, small scripts that let them control the server remotely afterwards. They used them to read the Nextcloud configuration, which holds database and mail server credentials among other things. They also looked specifically for password manager files and cryptocurrency wallets. Corgea notes that Italy's CSIRT also published a bulletin about the theft of these configuration secrets.

CISA added the flaw to the catalog on October 23, 2026. US federal agencies had until October 26 to fix it. That deadline doesn't apply to anyone else, but it shows how seriously the agency takes the issue. None of the sources say how many systems are affected worldwide.

Who is affected

Anyone running Nextcloud with the "Built-in CODE Server" app below version 26.4.303 is affected. That typically means self-hosted instances at small businesses, nonprofits, schools and homes, which are exactly the setups where people skip a separate office server. Nextcloud 29 and older are a special case. They are end-of-life, and according to the advisory they can't install the fixed app.

What you should do now

1. Check whether the app is installed, even if it's disabled. Disabled doesn't mean removed.
2. Update to at least 26.4.303 or remove the app. Corgea describes two later releases with further hardening, 26.4.402 and 26.4.502. It recommends the newest one, because that is the first release where disabling the app actually closes the vulnerable entry point. My advice: go straight to the latest version.
3. On Nextcloud 29 or older? Remove the app or upgrade Nextcloud to a supported version.
4. Look for traces. Unexpected PHP files in the app's directory are a red flag. An update won't remove a web shell that's already there, and it won't make stolen data secret again.
5. If you suspect a compromise, clean up properly. Preserve logs and suspicious files, rebuild the server or container from a clean image, and rotate every secret the web server could read. That includes database and mail passwords as well as the secrets in the Nextcloud configuration.

My take: the built-in office variant is a convenience option. If you rely on Nextcloud Office seriously, a standalone Collabora server is usually the better choice. If you don't use it at all, delete the app rather than just switching it off.

Sources

• NVD: CVE-2026-110447
• GitHub Security Advisory GHSA-g3vx-3m76-fghh (Collabora Online)
• The Hacker News: CISA Flags Two Actively Exploited Flaws
• Corgea: Analysis of CVE-2026-110447
• CISA Known Exploited Vulnerabilities Catalog

I wanted to try it. Part 1 is about getting something like this running safely. The AI comes in part 2.

Why a cage

Taking programs apart means having files on your machine you don't trust. Add a tool that is eight days old, has two stars on GitHub and calls itself "pre-alpha". And an AI that writes and runs code.

Before installing anything, I read the repository: no tasks that start automatically when you open it in an editor, no build scripts quietly downloading things, no hidden instructions for AI agents in the project notes. The security design is well thought out. Still: reading is not isolation.

One small thing stood out. The docs promise that downloads are checked against a signature. The install script says the signing key hasn't been created yet. All it checks is a checksum that comes from the same server as the download. That protects against broken files, not against tampered ones.

A machine that isn't allowed anything

KRAKEN runs in its own Linux machine, a virtual machine on my Mac mini. The software is called OrbStack. It has an "isolated" mode: no access to the Mac's files, no Mac commands, no access to other machines.

I measured it. Mac files: not visible. Services on the Mac: not reachable. My private VPN: reachable. The isolated machine got through the Mac to devices on my VPN. One service turned it away because it checks who is asking. Other services on the VPN trust anyone who is inside.

So the machine got its own firewall: internet only, no private networks, no VPN. Then I took admin rights away from the user inside the machine. Whatever runs there cannot switch the firewall off. Only I can change it, from the Mac.

The lesson: "isolated" means something different in every tool. Measure it, don't believe it.

The Apple chip and the sandbox

KRAKEN's ready-made packages only exist for Linux on Intel and AMD processors. The Mac mini has an Apple chip. No problem, I thought: OrbStack can translate Intel Linux through Rosetta.

Installed, started, refused. KRAKEN requires Landlock, a sandbox feature of the Linux kernel that stops a program from touching files outside a folder or reaching the network. The kernel had Landlock. But under Rosetta the call never arrives, and the kernel answers "doesn't exist".

For plain analysis I could have switched the sandbox off. Not for the interesting part: KRAKEN only builds and runs the Rust code an AI writes inside this sandbox. There is deliberately no switch for that. I think that's right.

So a second machine, this time for the Apple chip, and KRAKEN built from source. There the kernel reports Landlock version 10.

Three stumbling blocks in the build

The silent placeholder. The first build finished in 98 seconds, no errors. Suspiciously fast. Without the Ghidra decompiler sources, KRAKEN quietly builds a placeholder that decompiles nothing. The setup command only fetches part of the files. The decompiler sources need a second command.

The missing library. With the real sources the build failed: functions for unpacking data were missing when the program was put together. KRAKEN ships the library for that, but on the Apple chip it ends up in the wrong order. So far the project is only tested on Intel and AMD. One extra reference to the system library fixed it.

The emulator. For programs that use the system's shared libraries, KRAKEN needs a copy of those libraries for its emulator. Programs that bring everything with them ran right away.

The first look

My test case: a small calculator from the project's practice programs, compiled with optimizations and without function names. That's what a program looks like when you know nothing about it.

KRAKEN found 14 functions. Most are just called FUN_00101280 and the like. The decompiler turns them into readable C code. With one function you can tell after a few lines what it does: skip spaces, check for brackets and minus signs, put digits together into a number. That is the part of the calculator that reads numbers. A second practice program ran in the emulator and printed the same output as when run for real.

So far no AI has done anything. That's part 2: can a model name these functions correctly and rewrite them in Rust so the result behaves the same? I'll use an open-source program whose source code I know. Then we can check how close the AI gets.

I only take apart programs I'm allowed to analyse. KRAKEN says so in its own docs, and that doesn't only apply there.

Free models first

OpenRouter has models that cost nothing. I tried five. None of them got to a result.

Nemotron 3 Ultra passed numbers as text, "50" instead of 50. KRAKEN rejected that every time, and after eleven calls the budget was gone. Laguna S recognised the program right away, then got tangled up paging through the function list. Flint used 243,000 tokens in nine calls. Inkling is only open to certain apps on OpenRouter, and Gemma was overloaded.

KRAKEN behaved well throughout: it asks about cost before any AI work, stops cleanly when a limit is reached, and can undo any run with one command.

Claude outside, KRAKEN inside

Then Claude, through my regular subscription. Claude runs on the Mac, not in the test machine. It gets no shell and no file access, only KRAKEN's tools: list functions, decompile, search text, rename, comment. KRAKEN itself stays in the cage.

The task was the same for both programs: find the program's own functions, name them, say what they do. I didn't say which program it was.

Test 1: 2048

The game 2048 as an open-source C version, 577 lines. I compiled it myself, removed all names and built the C library in, like many real programs do. KRAKEN found 1,111 functions, 196 of them unnamed. Somewhere in there are the game's 19 functions.

Claude took 78 seconds. It found all 19. 17 names were exactly the ones in the source: slideArray, rotateBoard, findPairDown. One was only spelled differently, one named differently but correct in meaning. Along the way Claude noticed that the compiler had copied one function into another.

Test 2: the real xxd

Then a file I didn't build: xxd, Vim's hex dump tool, exactly as Ubuntu ships it. 22 kilobytes, no function names. I checked the file against Ubuntu's signed package lists, from signature to checksum. The answer key is the official debug package with the real names. The AI never saw it.

Claude took 53 seconds. 10 out of 10 functions, all with exactly the original name: xxdline, skip_to_eol, exit_with_usage, fclose_or_die. Plus every option and the exit codes. And it named functions the compiler had folded into main, with address ranges, although those names appear nowhere in the file.

Why that doesn't reassure me

Both programs contain a version string. For xxd it includes the author. Claude found it and then wrote, on its own: "The helper functions match xxd.c." It knows Vim's source code. It's in its training data, just like 2048, a project with more than 600 stars on GitHub.

So the names partly come from memory. The file only confirms what the AI already knows.

It's not quite that simple, though. Where exactly in the machine code each function sits, which parts the compiler merged, which option triggers which exit code: none of that is in any source code. Claude read that from the file.

For attackers and defenders this means the same thing. Known software, and that's almost all software, an AI sees through in seconds. What used to take days now takes a minute.

What this doesn't prove yet

Whether the AI understands a program it cannot know, I don't know yet. That's part 3: a program written after the model's knowledge cutoff. Then we'll see how much of the 100 percent was reading and how much was remembering.

I only took apart open-source programs. Their licences allow it, and we have the source code to compare against.

That can be tested. You need a program no one can know. So I wrote one.

A program that exists only on my machine

It's called tierstat, 234 lines of C, published nowhere. It reads lines with a name and four numbers, turns them into a score, sorts them into tiers and prints a ranked table.

The point: I made the logic deliberately odd, so that no standard knowledge would help. The columns have invented weights. The score is a blend of 85 percent weighted sum and 15 percent of a trimmed mean that drops the highest and lowest value. The tiers start at awkward thresholds. And I made up the checksum myself: start at 777, each step multiply by 131 and add the character weighted by its position, mask to 20 bits, finally XOR with a shifted copy of itself. No known algorithm. Describe it correctly and you must have read it.

Then I compiled the program, stripped all the names and put it in the same test machine. My own built-in self-test ran in the emulator: all 16 checks passed. The program works.

The same blind run

Claude again got only the bare file through KRAKEN, no shell, no source. The task: find the program's own functions, name them, say exactly what they do, with every constant.

After 130 seconds the answer was in. Of my 13 functions Claude found all 13. Every description was right. It named the weights {0.15, 0.25, 0.30, 0.30}, the 85/15 blend, the trimmed mean. And it described the checksum character by character: start value 0x309, which is 777, times 131 plus character times position, mask 0xFFFFF, finally h ^ (h >> 7). It even found two helper functions the compiler had folded into others.

It looked like the clean proof: the AI reads code it cannot know.

My test cheated

Before celebrating, I looked at what was actually in the file. And there was a mistake, mine.

My self-test checks things like classify_tier(82.0) == 'S'. The compiler writes those check lines into the file as plain text, so that something readable appears if one fails. That put the real names of my functions and several thresholds right there in the program, in black and white:

clamp_value(-5.0) == 0.0
classify_tier(82.0) == 'S'
weighted_score(full)
fold_checksum("A") != fold_checksum("B")

So the names were not a blind test. Claude didn't have to work out classify_tier from the code; the name was lying out in the open. That is exactly the kind of thing real programs leak all the time, through error messages, log text, debug leftovers. Reverse engineering almost always starts with the strings in a file. In that sense my mistake was a realistic one. It was still a mistake, and I'm saying so here rather than hiding it.

What holds up anyway

The checksum saves the test. Its formula appears nowhere as text, I searched for it: no 777, no 131, no mask. It exists only as arithmetic steps in the machine code. Claude read it out exactly. The same goes for the weights, which sit as raw numbers in the data section, and for the 85/15 blend.

That answers the question from part 2. The AI really does read compiled code. Where no name and no text helps, it reconstructs the logic from the machine instructions. The 100 percent on known software was not just memory.

For security that means something uncomfortable. It no longer matters whether a piece of software is known. Your own never-published code, the firmware in the living-room gadget, a company's internal tool, all lie open the moment someone has the file. What used to need a specialist and days is now a minute and a chat window. That holds for attackers, and it holds for defenders.

I only took apart programs I'm allowed to. This one I wrote myself.

What happened

The flaw is tracked as CVE-2026-114625. It's an SQL injection: an attacker slips their own database commands into input that the application passes to its database without proper checks. According to The Hacker News and SecurityWeek, Arista rates it CVSS 9.9 out of 10. A few other reports cite 9.4, but that doesn't change its critical rating.

VCO is the central management console for VeloCloud SD-WANs. SD-WAN means software-defined networking between sites: branch offices, data centers and cloud links are all configured through it. Whoever controls the orchestrator controls a large part of the company network.

An attack requires network access to the web interface and a valid login. That sounds like a barrier, but it's a low one. According to Arista, even the weakest built-in role is enough. That role is "Enterprise Read Only", a pure read-only account. With it, an attacker can gain operator privileges and impersonate a local "superuser operator". That's the highest level of control in VCO. BleepingComputer reports that the attack has low complexity and needs no user interaction.

What has changed since my post

More details are out now. The fixed versions are known, the CVSS score is published, and the scope is clearer. The two earlier flaws, from July (CVE-2026-16812) and September (CVE-2026-93952), could be exploited without a login. The new flaw is the first of the three that requires an account.

According to The Hacker News, several questions remain open. Arista hasn't said when the attacks started, which orchestrators were hit, or what the attackers did afterward. It's also unclear whether updating removes access an attacker has already gained.

Who is affected

On-prem VCO installations running these versions are affected:

• 5.2 before 5.2.3.18
• 6.1 before 6.1.3.10
• 6.4 before 6.4.2.12

Arista has already patched its hosted and dedicated orchestrators. VeloCloud Gateway and Edge are not affected, and neither is the 7.0 branch. Arista hasn't evaluated end-of-support releases. If you run one, contact Arista support (TAC). According to The Hacker News, Arista also notes that VCO is exposed by default and that no configuration setting prevents this. The sources don't say how many installations are affected.

What you should do now

1. Install the update. Upgrade to 5.2.3.18, 6.1.3.10, 6.4.2.12 or later. If you're on 6.1, also check whether the September flaw is covered. According to The Hacker News, Arista lists no fixed 6.1 release for it.
2. Restrict access. Make the web interface reachable only from trusted admin networks, and block unneeded outbound connections from the VCO host.
3. Clean up accounts. Since a read-only account is enough, every forgotten or shared login is a risk. Review accounts and remove the ones you don't need.
4. Look for traces. Arista's advisory lists two IP addresses seen in attacks. Block them and search your logs for them. Also watch for unusual paths, encoded characters, references to internal services and high request rates. Check recent admin activity for unexpected changes, and look for webshells and backdoor daemons.
5. Preserve evidence if you suspect compromise. Save web, application, system and database logs plus file timestamps before cleaning up, then contact Arista TAC.

My take

Three exploited zero-days in the same management product within a few months is no accident. Attackers are clearly targeting VCO because it's a lucrative target: whoever takes it over holds the keys to the entire site network. If you run VCO on-prem, treat it like a domain controller. That means keeping it off the open internet, patching immediately and actively monitoring its logs. After this series, I'd also seriously consider whether the hosted version is the calmer choice. This time it was already patched when the news broke.

Sources

• CISA: KEV catalog addition
• The Hacker News: Arista warns of critical VeloCloud SQL injection
• BleepingComputer: Arista patches new VeloCloud Orchestrator zero-day
• SecurityWeek: Third VeloCloud Orchestrator zero-day in four months
• NVD: CVE-2026-114625

LiteLLM is a widely used open-source proxy that routes requests to many LLM providers through a single interface. According to BleepingComputer, the package gets around 92 million PyPI downloads a month. That's what makes it such an attractive target: a LiteLLM host holds the API keys for every AI provider connected to it.

What happened

A supply chain attack goes after the way software is delivered rather than the software running on your machine. In this case the target was the release pipeline. According to LiteLLM's incident report, the artifacts were available during these windows (UTC, October 21):

• PyPI: litellm==1.107.0, seven wheels for Linux, macOS and Windows, from 11:39 to 13:23
• Docker Hub: tags v1.107.0, latest, main-latest and main-stable, from 11:46 to 14:20
• GHCR: the same tags for the litellm, litellm-database and litellm-non_root images, until 13:51

Customers on the private enterprise edition were not affected. The official source tag on GitHub is clean, because the build came from a lookalike repository called Berri-AI/litellm (the real one is BerriAI/litellm). SecurityWeek puts the downloads at more than 49,000 based on PyPI data. Keep in mind that downloads don't equal 49,000 infected systems.

What the malware does

The malicious code isn't in LiteLLM itself. It sits in three files in the site-packages directory (cook.pth, cook.py, sitecustomize.py), which Python loads every time the interpreter starts. So the malware runs even if LiteLLM is never imported, and even when you run pip to investigate.

According to Help Net Security and BleepingComputer, it collects credentials for AWS, Azure, Google Cloud, Kubernetes and Docker, Git, SSH and GPG keys, .env files, shell histories, browser logins and cookies, plus auth files for AI tools such as Claude, Codex, Gemini and Cursor. It also tries to read the provider keys stored in the LiteLLM database. A separate loader checks a GitHub-hosted source every hour for more Python code to run.

The attackers actually used what they stole. About four and a half hours after exfiltration, Wiz saw them validating stolen AWS credentials and testing access to Amazon Bedrock models. That points to LLMjacking, where attackers run AI workloads on stolen credentials and the victims pay for it.

What has changed since my post

In my post I said the attackers used hijacked GitHub CLI OAuth tokens, and that's still true. What the first version of the incident report got wrong was where those tokens came from. LiteLLM initially suspected they leaked through logs on an internal deployment that was exposed to the internet. The corrected root cause analysis from October 23 tells a different story. In May, an admin key for an internal agent platform was accidentally committed to a public repository, and nobody ever revoked it. On October 10, the attackers used that key to get a GitHub organization owner's token. From there they took the tokens of other maintainers, and on October 21 they used them to take over the release pipeline. LiteLLM itself says its earlier assumptions turned out to be "inaccurate or incomplete."

The takeaway is that this didn't start with a clever zero-day. It started with a leaked key that stayed valid for months.

What you should do now

• Check whether LiteLLM 1.107.0, or any of the Docker tags listed above, is in your projects, CI runners or images. If you pulled latest or main-stable during the window, you may be affected without realizing it.
• Don't start Python or pip first in a suspect environment. Search the file system for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py instead. LiteLLM notes that finding nothing doesn't prove a system is clean.
• Rebuild, don't repair. Isolate affected systems, rebuild virtual environments and images from scratch, and pin to litellm==1.106.2 or another release from before the incident. Updating alone is not enough.
• Rotate everything the host could reach: cloud roles and keys, every provider key in the LiteLLM database, master and virtual keys, database passwords, SSH keys and any tokens in environment variables.
• Check your logs. In AWS CloudTrail, look for GetCallerIdentity calls around the time of installation and for your credentials being used from outside your infrastructure.

My advice goes beyond this one incident. An AI gateway is effectively a vault for API keys, so treat it like one. Pin versions instead of using latest, reference images by digest, and let new releases sit for a few days before you deploy them. If you publish software yourself, revoke leaked keys right away, even when the leak looks harmless. There's no CVE for this incident so far, which means you can't count on your vulnerability scanner to flag it.

Sources

• LiteLLM: Security Incident Oct 21, 2026
• LiteLLM: Root cause analysis / attack chain
• BleepingComputer: LiteLLM release pipeline hacked to distribute info-stealer malware
• Help Net Security: LiteLLM compromised in supply chain attack
• SecurityWeek: LiteLLM Compromised in Fresh Supply Chain Attack

What I tested

On October 23, 2026, I checked whether the free models call tools correctly. This is known as tool calling: the model returns a structured call like "function X with parameter Y", and the agent software runs it.

Results from my test:

• It worked with Nemotron 3 Ultra 550B (NVIDIA), Flint 1.0 (Recursive), Laguna S 2.1 (Poolside), Dots 3 (Dots Studio) and North Mini Code (Cohere).
• Gemma 4 31B (Google) and Xing 4.0 only returned error 429.
• Inkling (Thinking Machines) only ran for me inside agent tools.

These come from a single test run, not an independent benchmark. What I can back up: all of these models are listed as free, and according to their model pages and CostGoat's overview, they accept the tools parameter.

On error 429: according to the OpenRouter docs, it means "rate limit exceeded", so too many requests. I can't tell from outside whether the cause was an overloaded provider or a limit on my side.

On Inkling: the Inkling (free) model page doesn't say the free endpoint only works with agent tools. The only restriction it mentions is that the model isn't currently available through EU in-region routing. So the agent-only part is just what I saw, not something documented.

What has changed since the post

Not much. The CostGoat list was updated on October 29 and still shows all eight models as :free, each with tool support. It now lists 17 free models in total. That also shows how quickly the list changes. A model that's free today may be gone next week.

The limits

According to the official docs, confirmed by TrueFoundry, every :free model has these limits:

• at most 20 requests per minute,
• at most 50 requests per day if you've bought fewer than 10 credits in total,
• 1,000 requests per day once you've bought at least 10 credits.

That's tight for agents. An agent often sends many requests per task, because every tool call is its own round trip, so 50 requests go fast. TrueFoundry also notes that failed requests can count against your daily allowance.

Privacy: the real price

"Free" doesn't mean you give nothing in return. According to TrueFoundry, 9 of the 19 free models they examined run on hosts whose terms allow training on prompts, including NVIDIA and Thinking Machines. Other hosts keep prompts for a while without training on them. Google AI Studio, for example, keeps them for 55 days. If OpenRouter can't determine a provider's policy, it marks the endpoint as both training and retaining, just to be safe.

That doesn't mean every prompt ends up in training data. But it's allowed. For an agent that reads files, sees code or parses logs, that's a real risk: whatever the agent sees goes to the provider.

What I recommend

• Fine for experimenting: If you want to try out agent workflows or get to know a model, you get usable models at no cost.
• No confidential data: No customer data, no credentials, no internal code. It's safest to assume this for every :free model.
• Check your privacy settings: OpenRouter has privacy toggles and a data_collection: "deny" request option. That rules out providers that train on data, which often means losing free models too.
• Don't depend on it: With 50 requests a day, 429 errors and a list that keeps changing, nothing in production should run on these endpoints.
• Plan a fallback: If you use them anyway, set up a second model in case one disappears or gets throttled.

My verdict: good for playing around and learning, not for work you need to rely on.

Sources

• OpenRouter: models, search "free"
• OpenRouter Docs: API limits
• OpenRouter: Nemotron 3 Ultra (free)
• OpenRouter: Flint (free)
• OpenRouter: Dots3-Note Preview (free)
• OpenRouter: Gemma 4 31B (free)
• OpenRouter: Inkling (free)
• CostGoat: OpenRouter Free Models
• TrueFoundry: OpenRouter free models – what's actually free

I looked at the core claims. In short: the situation is serious. The post is louder than the facts.

What holds up

PHP2Shell. Two flaws in PHP, the software behind a large share of all websites, severity 9.2 out of 10. Exploiting them lets an attacker run their own code on the server without logging in. The patches came out on October 21. The flaws were found by researchers at Wiz together with Calif and OpenAI, using AI-assisted tools, and reported back in August. (Recorded Future)

Amazon saw a first attempt in its honeypots, servers that exist only as bait for attackers, on October 17. Four days before disclosure. Amazon now speaks of broad exploitation, Cloudflare of a sharp rise in attacks. According to Help Net Security, a working exploit shows that a single request without login is enough. None of the reports I read names a confirmed successful break-in so far, though. Amazon's find from October 17 also hit a bait server. (The Register, Techzine, Help Net Security)

Governments pull sites offline. Germany, the Netherlands and other countries took websites offline as a precaution, and Wikimedia some of its systems. According to the German digital ministry, no incidents were known there. Switching off was caution, not a break-in. (CNBC)

One attacker, more than 100 companies. According to Reuters and researcher Snorre Fagerland, a single attacker used AI agents on the Cairn platform to break into the websites of more than 100 companies, including Deere and SharkNinja. Cost: about 5,000 dollars, roughly 50 dollars per successful break-in. How much data was taken is unclear. Deere says it sees no sign that sensitive data was accessed. (TNW)

Banks lock out AI agents. JPMorgan no longer lets outside AI agents into customer accounts. According to Jamie Dimon, anyone who hands their login to an agent carries the risk themselves. (Cybernews)

What I could not confirm

• That the claim "half of the servers are too old for the fix" comes from Cisco. A similar number does exist, more on that below.
• The quote that bank executives called the situation "horrifying".
• Other numbers in the post (Latin America, South Korea, Japan) I did not check, so I leave them out.

Half too old? Handle the numbers with care

A Shodan count cited by the security firm CybelAngel: of about 1.5 million servers that openly show their PHP version, 59 percent (883,717) run a branch with no official update. So the "half" in the post is not made up. (CybelAngel)

But these scanners count version numbers, not vulnerabilities. Linux distributions like Ubuntu build the fix into their own packages and keep the old version number. A server I look after reports "PHP 8.3.6". That sounds years old. The package does contain the patch for exactly these two flaws, installed the morning after disclosure. A scanner still counts it as vulnerable. The real number is lower. By how much, nobody knows exactly.

For PHP 7.4, 8.0 and 8.1 there are only minimal source code fixes, meant for people who build PHP themselves. If you sit on one of those versions at a hosting provider, they do not help you.

What is off about the post

"Black October", "send this to everyone", cash and supplies at home: that is alarm. Yet Shumer himself writes that no successful break-in through the PHP flaw has been confirmed so far.

The advice to avoid small websites is well meant but not workable in everyday life. And deposit insurance depends on where you live: in Germany and the EU, deposits are protected by law up to 100,000 euros per customer and bank, in the US the FDIC covers 250,000 dollars.

What you can do today

1. Install updates. Phone, computer, browser and router. Never an "update" from a pop-up, a text message or an email.
2. Use a password manager. Every account gets its own password. iPhone and Android have one built in.
3. Turn on two-step login, email and bank first. Your email is the master key to everything else.
4. If "your bank" calls, hang up and dial the number on your card yourself. No bank asks for a one-time code or your password.
5. Do not give banking logins to AI assistants or other apps, even when it would be convenient.
6. Do not pull your money out. Panic is exactly what scammers count on.

If you run a website on PHP yourself: check your version and update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Amazon recommends reviewing logs from October 17 onward, not just from the disclosure date. For 8.1 and older there is no ready-made update: upgrade, or ask your hosting provider or distribution. On Ubuntu and Debian the old version number stays, apt changelog php8.3-common (with your version) shows whether the fix is in. If your site is behind Cloudflare, you get firewall rules against the known attack paths, on the free plan too. That does not replace the update.

Faster, not unstoppable

Attackers have gotten faster because AI does part of the work for them. That is real. The answer is not panic, though, but the boring stuff: updates, unique passwords, a second factor.

The first 48 hours of this week are also a video: The 48 Hours, Episode 1.

The setup

Everything runs in containers, held together by a single Compose file:

• Caddy as the web server in front. It routes every request to the right place based on the hostname.
• WordPress for the main blog, with MariaDB as the database.
• Nextcloud for files, calendars and video calls.
• Forgejo as my own Git server.
• A few static sites, like this one.

The data lives on an external drive. The idea: plug the drive into another computer, start the stack, everything keeps running.

No open doors

The router has not a single open port for the websites. Instead, a small service builds a connection to Cloudflare from the inside, a tunnel. Visitors land at Cloudflare, and Cloudflare passes the request through the tunnel to Caddy. From the outside, my connection is not visible at all.

For myself there is a second way in, through a private VPN. That also reaches things that are deliberately not public.

What happened along the way

A lesson I did not expect: my Git server was publicly reachable for a while. Within about a day and a half, AI crawlers sent around 300,000 requests and downloaded thousands of archives. Not an attack in the classic sense, just bots grazing on everything they can find.

Since then the Git server is no longer on the tunnel. I only reach it through the VPN. And I keep access logs that I review regularly.

Is it worth it?

For me, yes. I learn more from it than from any course, I know where my data lives, and it costs little more than electricity. The price: when something breaks, I am the admin. At three in the morning, too.

PHP: two bugs, severity 9.2 out of 10. Patch it, or take it offline.

GitLab: 10.0, the top score. Every version since 2014 is affected.

eMudhra: one private key had the value 4.

LiteLLM: a poisoned package on PyPI for almost two hours.

Onamae: 26,739 servers, every plan switched off.

Cairn: one attacker, more than 100 companies, around 50 dollars per breach.

SBI: 3,897 records affected.

US, EU, Japan. Patch, or go offline.

How the video was made

Script, design and code with Claude Code, rendered from HTML with HyperFrames. The voice is Kokoro-82M and runs locally on my machine. No stock footage, no cloud rendering.

By the way, the "9.2" on the board is not a PHP version. It is the CVSS score, the severity. I tripped over that myself, so now it says so.

That is supposed to change here.

What you will find here

Two kinds of articles:

• Built: reports on my projects. What it is, how it works, where it broke. No gloss.
• Everything else: thoughts on technology, society, everyday life, whatever is on my mind. No fixed topic.

What "ungefiltert" means

"Ungefiltert" is German for unfiltered. Not: loud, provocative, thoughtless. But: I write it the way it was. If a project is half done, it says "half done". If I was wrong, it says that too.

And the AI?

I write these texts together with an AI. It works like this:

1. I set a topic, often with bullet points, notes or just the project itself.
2. The AI turns that into a draft.
3. I read, cut, correct and approve. Only then does the text appear here.

The AI helps me get from a thought to a text faster. I still stand behind what is written here. If something is wrong, that is my mistake, not the machine's.

The tech, briefly

This blog is a handful of static HTML files. No content management system, no database, no cookies, no tracking, no external fonts. It runs on a Mac mini at my home and is reachable through a Cloudflare tunnel. Every article exists in German and English. If you want to follow along, use the RSS feed.

Why so small?

Because I do not want to know how it does in front of a thousand people. I want to know how it feels with ten. With only a few players I can read every piece of feedback, trace every bug and fix things fast, without a support department.

If you want to play, you ask for a personal access code. As long as there are free spots, you get one. Save games stay on your own computer.

What is inside

• The game core is written in Rust and holds all the rules. It runs without graphics and has its own tests; the game and the server both use it unchanged.
• An automated pipeline builds the Windows version. I build the Mac versions myself.
• The website runs as a small worker on Cloudflare, with an intro video and a download area.

The seed room

From level 50 on there is a seed room. You cross plants, name new varieties, collect them in a seed book and show them off in a variety show. Varieties only change how plants look, not the game values. That was deliberate: if you do not want to breed, you lose nothing.

I did not tune the balance by gut feeling, I simulated it. Getting from level 50 to 100 takes 26 days in the simulation, and a bit over a quarter of the experience points come from the seed room. Along the way I had to nerf trees: they gave so many points that nothing else was worth doing.

The village square

Since version 0.3 you no longer play only on your own. There is a game server and a shared village square: one chat for all players, plus messages when someone reaches a level or breeds a rare variety. Everyone can switch those messages off for themselves.

I took the chat more seriously than ten people strictly need. It is end-to-end encrypted with MLS (Messaging Layer Security), an open standard for group chats. The server only delivers messages and cannot read them. On top of that comes post-quantum cryptography, meaning methods that even a future quantum computer should not break: key exchange with ML-KEM and X25519 combined, signatures with ML-DSA. The connection to the server is protected the same way and runs through a Cloudflare tunnel instead of open ports.

To be honest: the combination I use is still an IETF draft, not a finished standard. The game says so too. Among other things I tested what happens when the server lies, faking a sender or swapping messages. The game then shows none of it, only a warning. I still think an independent look at the implementation makes sense before I rely on it.

Characters that talk

Characters walk around the farm, do work, and you can talk to them. With a local language model they answer freely; without one, the answers come from templates. Since 0.3.1 the game starts without AI, and you switch it on in a conversation with "Talk with AI". The reason is simple: most players do not have a language model on their computer, and a game should not stall just because an AI is missing.

The radio

Along the way, Farmaradio came about: a web radio as a web component that you can add to any page with a single line. It started out just for the game, is now a small project of its own, and also plays in the game's footer.

The most annoying part was not playback but browser security rules: which site may load audio from which other site? That cost me an evening and is now handled with two lines.

What comes next

Nothing, for now. Development is on hold until a few people have joined. A village square without a village makes little sense, and I do not want to keep building things nobody has tried yet.

The plans are ready in the drawer anyway. Next would be the village show: a weekly round where everyone shows their best varieties and the top ones win a prize. After that, the same farm should run on a second computer, Mac in the morning and Windows in the evening.

One open question is where the characters' AI should run once more people use it. On the player's own machine it costs nothing but needs a strong computer. On my server or with a provider, the typed text would leave the device. I want that properly sorted before I offer it.

What comes, and in what order, is up to the people who play. If you want in, ask for an access code at farmeramania.de.