On October 28 The Record summarized a pile-up of Japanese incidents that has the prime minister talking about emergency measures. I am not going to re-report every one. Three of them share a shape that matters to anyone who rents a server from somebody else.

Three incidents, three trust boundaries

Japan Airlines, via Amadeus. JAL said Amadeus, which runs its reservation, ticketing and check-in systems, told it that attackers accessed a portion of customer reservation data. About 92,000 customers were affected. For about 2,000 of them the data included passport numbers, frequent flyer numbers, email addresses and phone numbers. Flight operations and card numbers were not hit. The breached system was a vendor’s, not JAL’s own data center. The data was still JAL’s customers.

Sony Network Communications / So-net. Help Net Security’s write-up of the company notice: attackers hit the So-net member database on October 19, confirmed October 23. More than 2.58 million current and former customer records (names, phones, emails, user IDs, dates of birth, gender, connection IDs), plus 54,401 email addresses with their passwords, plus 16 bank account records without PINs. Passwords on the email side were reset October 27. NURO and other services were not in the leak, per Sony.

GMO Onamae.com Desktop Cloud. GMO’s own October 21 notice says a third party installed malicious programs in some customers’ server environments. Up to 26,739 servers were potentially affected. The company shut the fleet down starting 4:00 JST on October 21. Later reporting (TechRadar citing BleepingComputer) says attackers demanded roughly $50 million, GMO refused, data leaked, and customers were told to scan, back up, disconnect and shut down their own PCs. Login credentials for MetaTrader 4 and 5 were among what was taken, and some customers reported trades they did not recognize. I have not independently confirmed the ransom figure from GMO’s own English notices; treat that number as coming from secondary reporting.

The angle that travels

JAL is a vendor-of-your-vendor story. So-net is a membership-database story. GMO is the one that should change how you think about a rented desktop or VPS: the provider’s intrusion became malware on the customer’s server.

If you rent a machine from anyone, the question after their incident is not “did they rotate their keys.” It is “what do I still trust on the box they handed back.”

What I would check on my own servers

Assume the provider’s timeline is incomplete. Work from the box you can still reach, or from the replacement they gave you.

1. Inventory what the box could reach. Outbound VPN configs, SSH agent sockets, cloud CLI profiles, browser profiles, saved RDP files, trading-platform terminals, CI runner registrations. Anything with a credential that still works after the host is “cleaned.”
2. Rotate from a clean machine. Do not rotate from the rented desktop. From a laptop you trust, change every password and token that lived on that host, end every session, and revoke every API key. GMO’s own notice told customers to change credentials stored on the server and anywhere they reused them. That is the floor, not the ceiling.
3. Look for what the malware left. New local users, new scheduled tasks or systemd units, unexpected listening ports, browser extensions you did not install, outbound connections to places that are not your broker. On a Windows rented desktop, Autoruns and a full offline AV scan; on Linux, the usual persistence places plus dpkg --verify / rpm -V for system packages.
4. Treat “we cleaned it” as unproven. Prefer a new VM from a fresh image, then restore only the data you can check. If the provider offers a replacement machine, take it.
5. Watch the accounts that ran there. MetaTrader customers saw unrecognized trades. SaaS accounts that had a session open from that host need a session kill and a password change, even if the provider says the data did not include those passwords.

For the Friday roundup

These three sit next to Burger King Japan (about 11 million) and Capcom (about 11.7 million) in The Record’s roundup. The hosting angle is the one worth a full note; the others are volume. Capcom and Burger King numbers are from The Record’s summary, which does not link their primary notices in the same piece, so confirm those against the companies’ own statements before you lean on the figures.

Sources

• The Record, Japan Airlines warns of data breach as country grapples with multiple cyber incidents, October 28, 2026
• Help Net Security, Data breach at Sony-owned internet provider compromises 2.6 million customer records, October 28, 2026
• GMO Internet, Apology and Notice Regarding Unauthorized Access to Onamae.com Desktop Cloud, October 21, 2026
• TechRadar, Japanese internet giant GMO tells customers to shut down, October 28, 2026 (secondary source for the ransom demand and MetaTrader detail)

Almost every headline put AI in the first line. I get why. But I wanted to know what Barclays itself said, in its own documents, so I read the script and slides from its results call. It turns out the bank is telling two stories in the same breath, and only one of them is about AI doing anyone’s job.

If you work in a bank, a support team or a software team, the difference matters. It changes what you should do next.

What Barclays said, in its own words

Barclays published the speech its CEO and finance director gave to analysts, along with the slides (Barclays Q3 2026 call speech). Here is what it says about the cuts, in my words.

• The 5,000 figure comes from what Barclays calls structural cost actions taken in 2026. A footnote says the reduction is still subject to collective and individual consultation where that is required.
• Around 60% of the actions are in support functions, and that includes developers. The finance director, Anna Cross, put it this way: “fewer developers as AI makes our people more productive.”
• In the UK retail bank, better customer technology cut call centre volumes by about 10% over the past year. Technology inside the call centres made staff more productive. Branches now have about 10% fewer employees each.
• The bank expects more than £1.1bn of gross efficiency savings in 2027.

The CEO, C.S. Venkatakrishnan, was asked how many of the cuts were directly down to AI. He did not give a number. He said deep investment in technology and simpler processes were behind most of the savings so far, and that AI was “the icing on the cake, not the cake” (The Guardian).

So the bank named AI, but its own boss said AI is not the main driver yet.

Two stories in one announcement

When I sort Barclays’ statements, they fall into two piles.

The first pile is technology doing work people used to do. Fewer developers because AI tools speed up the ones who stay. Fewer calls because customers use better self-service technology. Fewer people per branch. Only the developer line names AI directly. The call centre and branch changes are described as technology in general.

The second pile is about money. The slide headline says Barclays is cutting its cost base to free up room for investment. The bank had spent £307m on these restructuring actions in the first nine months of 2026 and expects about £300m more in the fourth quarter. Banking Dive points out that the full year total, over £600m, is roughly twice what Barclays first planned. On the same day, Barclays announced a £500m share buyback and a 12% rise in quarterly pre-tax profit, to £2.3bn (CNBC).

The Unite union said Barclays was using AI as an excuse, and it opened urgent talks with the bank. Its global federation, UNI, pointed straight at the buyback announced on the same day as the cuts (UNI Global Union). I don’t think “excuse” is quite fair either. The developer line is a real claim about AI changing how much work one person can do. But the bank has not said how big that part is.

What today’s US layoff report adds

This morning Challenger, Gray & Christmas published its October report on US job cut announcements. It is one of the most quoted counts of layoffs where the employer names AI (Challenger, October 2026). Barclays is a UK bank, so its cut is not what this report is about. But it shows the same pattern from the other side.

The numbers, checked against the report itself:

• October’s US total was 43,994 announced job cuts. That is the lowest October since 2023 and down 71% from October 2025.
• Employers cited AI for 1,265 of those cuts. That is AI’s lowest month of 2026.
• For the year so far, AI has been cited for 121,401 cuts, about 20% of the total. That is a lot. But “market and economic conditions” has now passed it as the top reason, at 130,531.
• Technology companies have announced 171,501 cuts this year, 28% of all cuts and already more than all of 2025.
• FinTech is small but up sharply: 11,979 cuts so far this year, against 1,863 by this point last year.

Andy Challenger said the reasons employers give have moved from technology toward the economy. Here is the part I keep coming back to. Challenger counts the reason the employer states. If a company says “restructuring” when AI is part of it, it lands in restructuring. If a company says “AI” when the real driver is cost, it lands in AI. The count tells you what companies chose to say, which is useful, but it is not proof of what caused the cut.

What the official survey data says

The UK’s Office for National Statistics asked businesses directly. In its July 2026 analysis, among businesses using AI to improve how they run, 63% said their headcount had not changed because of it, 6% said it went down and 1% said it went up. The most common way firms said they were bringing in AI skills was training or retraining the staff they already had (ONS).

One honest catch. That survey leaves out finance and insurance. So it cannot tell us much about banks specifically, which is exactly where Barclays, NatWest and others are now making cuts.

Confirmed and not known

Confirmed, from Barclays’ own documents or on-record statements:

• About 5,000 full-time roles, about 5% of staff, with about 1,000 already gone.
• Around 60% in support functions, including developers.
• Call centre volumes down about 10% and branch staffing down about 10% in the UK retail bank.
• A £500m buyback and £2.3bn quarterly pre-tax profit announced the same day.

Not known:

• How many of the 5,000 are because AI now does the work. The CEO was asked and did not give a figure.
• Exactly which teams and countries. The BBC reported that a significant share is expected in India, where some UK back office work is done, but no breakdown has been published that I could find.
• Whether some cuts will come through not refilling roles rather than layoffs. Barclays did not split that out.

I also did not find any newer Barclays announcement since October 22 that changes these numbers. City AM reported on November 3 that NatWest’s staff count fell by 1,000 last quarter, but NatWest’s boss said no single change explained it (City AM).

Who this affects

• Bank staff in support and back office roles: operations, processing, internal IT, and the people who build and maintain internal software.
• Contact centre and branch staff, where Barclays already reports about 10% fewer people per branch and fewer calls.
• Developers in any large company. Barclays has now said on the record that AI tools mean it needs fewer of them.
• Workers at offshore service centres that do UK back office work.

What I would do if I worked there

I work in IT. I am not a career coach and this is not legal advice. But this is what I would actually do this month.

1. Read the source, not the headline. Most listed companies publish their results script and slides. Search them for “efficiency”, “FTE” and “AI”. Note which reason they give for which cut. It tells you whether your team is in the “tech does the work” pile or the “cost target” pile.

2. Break your job into tasks. Write down what you do in a week. Mark the parts a tool already does or could do soon: summarising calls, routing tickets, writing boilerplate code, filling standard forms. Be honest. Those tasks are where the headcount maths happens.

3. Move toward the exceptions. The work that stays with people tends to be the messy part. The angry customer whose case does not fit the script. The payment that failed for a strange reason. The change that needs someone to sign off and own the outcome. Barclays itself says branch staff are now focused on higher value support. If you can be the person who handles what the tool cannot, you are harder to cut.

4. Learn the tools your team is already using. If AI is making the developers who stay more productive, you want to be one of them. That means getting good with the coding assistant your company approved, and also getting good at checking its output. Someone has to catch the bug it wrote.

5. Ask about internal moves now, not after the letter. According to Bloomberg, as reported by Banking Dive, Barclays told staff it would put about £150m into skills by 2030 and fill open jobs with existing staff first. Whatever your employer, ask HR how internal moves work and how to apply before cuts are final.

6. Know your consultation rights. In the UK, an employer planning 20 or more redundancies at one site within 90 days must follow collective consultation rules, and must give written reasons and selection criteria to staff representatives (GOV.UK). If you are in a union, talk to your rep. Outside the UK the rules differ, so check your own country’s labour office.

7. Keep proof of your work. Save numbers on what you fixed, sped up or saved. Update your CV while you are calm, not in a panic the week the list comes out.

My take

I think the honest reading of the Barclays news is this. AI is real and it is already changing how many developers and call centre staff a big bank thinks it needs. But a large part of this cut looks like a normal cost programme at a profitable bank, and “AI” is the word that travels best in a headline. Today’s Challenger report shows US companies are now quieter about naming AI, even while technology companies keep cutting.

For workers, both stories end in the same place. The tasks that are routine and easy to measure are the ones at risk, whatever label the company puts on the cut. The skills that still hold are judgement on the hard cases, owning a result, knowing how your systems really work, and being the person who checks what the tool produced. I would rather build those now than wait to find out which pile my job is in.

Want one short email a week on breaches, AI and what to do about them? Subscribe to Weekly Breach Notes at weeklybreachnotes.substack.com.

Sources

• Barclays, Q3 2026 Results Analyst and Investor Conference Call Speech (with slides), Oct 22, 2026: https://home.barclays/content/dam/home-barclays/documents/investor-relations/ResultAnnouncements/Q32026Results/Q326%20Results%20Call%20Management%20Speech.pdf
• BBC News, “Barclays cutting 5,000 jobs as it increases reliance on AI,” Oct 22, 2026: https://www.bbc.co.uk/news/articles/cm4g1p347qgxo
• Banking Dive, “Barclays to cut 5,000 employees this year,” Oct 22, 2026: https://www.bankingdive.com/news/barclays-cut-5000-employees-ai-q3-earnings-venkat/833747/
• CNBC, “Barclays to slash 5,000 jobs in AI efficiency push,” Oct 22, 2026: https://www.cnbc.com/2026/10/22/barclays-ai-jobs-cuts.html
• The Guardian, “Barclays to cut 5,000 jobs as bank’s bosses hail AI productivity advances,” Oct 22, 2026: https://www.theguardian.com/business/2026/oct/22/barclays-profits-up-as-uk-banks-brace-for-tax-increase-in-budget
• UNI Global Union, “UNI backs Unite as Barclays cuts 5,000 jobs and hands shareholders £500 million,” Oct 23, 2026: https://uniglobalunion.org/news/uni-backs-unite-as-barclays-cuts-5000-jobs-and-hands-shareholders-500-million/
• City AM, “Barclays and Natwest layoffs signal start of banking’s AI job squeeze,” Nov 3, 2026: https://www.cityam.com/barclays-and-natwest-layoffs-signal-start-of-bankings-ai-job-squeeze/
• Challenger, Gray & Christmas, “October Layoffs at Three-Year Low; Seasonal Hiring Plans Up 26%,” Nov 5, 2026: https://www.challengergray.com/blog/october-layoffs-at-three-year-low-seasonal-hiring-plans-up-26/ (full report PDF: https://www.challengergray.com/wp-content/uploads/2026/11/Challenger-Report-October-2026.pdf)
• Office for National Statistics, “Artificial intelligence in UK businesses: 2023 to 2026,” Jul 20, 2026: https://www.ons.gov.uk/businessindustryandtrade/business/businessservices/articles/artificialintelligenceinukbusinesses/2023to2026
• GOV.UK, “Making staff redundant: Redundancy consultations”: https://www.gov.uk/staff-redundant/redundancy-consultations

I work in endpoint and infrastructure security, not supermarket refrigeration. But I have spent enough years watching control panels land on the public internet to recognise the pattern. Someone leaves a temperature controller reachable. Someone leaves a default password. Someone never patches an end-of-life panel. Then an attacker turns the dial.

If you run grocery cold rooms, a blood bank fridge, a pharma warehouse, a refrigerated truck fleet, or the network those devices sit on, today is the day to check. Not next quarter.

What happened, in order

The advisory sits on top of several public waves:

• Late August 2026. Freezers at US military commissaries switched into defrost or heating modes. The Defence Department is treating those incidents as a suspected cyberattack. The CSA does not say those events are part of the same campaign, and reporting still treats the link as unclear (Military Times, The Record).
• October 12, 2026. A wave against French supermarket refrigeration overnight. Reporting put the hit at about 250 to 350 stores across chains including Intermarché, Coopérative U, Carrefour Market, Monoprix, Leclerc and Super U. Older Danfoss controllers were named in that coverage. Paris prosecutors opened an investigation that included food losses and fires (BleepingComputer).
• Early November 2026. A second European wave hit more than 100 stores, per CNBC. Separately, the French Blood Establishment said cold rooms storing donated blood were targeted and temperatures were set to rise. Staff intervened. The EFS said no blood products were lost and no health impact was identified (BBC, CNBC).
• November 5, 2026. The five US agencies publish the CSA and call the threat ongoing.

Attribution is still open. Some Russian-linked hacktivist groups claimed related activity online. Analysts quoted by the BBC are sceptical of those claims, and Iranian-aligned actors, other groups, or copycats have also been discussed. The US advisory does not name a country or group. I am not going to either.

What the US advisory actually confirms

I read the CSA itself, not just the headlines. Here is what it states.

Targets. Electronic temperature controllers and commercial refrigeration controllers in retail grocery and cold storage. The same class of systems is widely used in healthcare and public health, chemical, food and agriculture, and transportation, including refrigerated transport.

How. Actors may exploit unpatched or internet-accessible controllers. The named vectors are authentication bypass, arbitrary code injection, and weak configurations.

Effects if they get in.

• Change the temperature (shorter equipment life, fire hazard, inventory loss, or harm if unsafe product is later consumed).
• Force continuous heating and defrost cycles.
• Deny operators a view of the real temperature.

What it does not say. It does not name a vendor. It does not publish victim counts. It does not attribute the attacks. It does not claim the US military commissary incidents are confirmed as the same actors.

That gap matters. European reporting named older Danfoss controllers for the French supermarket wave, and CISA has previously published Danfoss AK-SM 8xxA advisories (CVE-2025-41450, CVE-2025-41451). Today’s CSA is vendor-agnostic on purpose. Treat every internet-reachable cold-chain controller as in scope until you prove otherwise.

Who this affects

• Grocery and convenience operators with remote refrigeration management.
• Cold storage warehouses and food distributors.
• Hospitals, blood banks, labs and anyone storing temperature-sensitive medicine or samples.
• Chemical and transport firms that rely on automated cold chain logging.
• The IT and OT people who keep those panels reachable for “convenience.”

If you are a shopper, you are not the direct target. You are the person who ends up staring at empty frozen shelves or, worse, buying product that spent hours warm. The fix still sits with the operators.

How to check if you are exposed, and what to do

The CSA’s mitigations map to Cross-Sector Cybersecurity Performance Goals. Here is how I would run them on a real site this afternoon. These are checks on systems you own or operate. Do not scan someone else’s gear.

1. Inventory what can talk to the internet

Walk the store, warehouse or plant with whoever maintains the fridges. Write down every temperature controller, gateway, BMS panel and cloud monitoring portal. Ask the refrigeration vendor, in writing, which devices have remote access and how that access is reached (VPN, cellular modem, direct port forward, vendor portal).

If you have a public IP inventory, search it for the controller ports and hostnames your vendor uses. Shodan and similar indexes have been used in reporting to show thousands of Danfoss-class devices reachable from the open internet. Use those tools only against addresses you control.

2. Pull panels off the public internet

The CSA’s first mitigation is the important one: do not expose control system devices, especially controller panels, to the internet. If remote support is required, put it behind a firewall or edge device you keep patched. CISA’s own Internet Exposure Reduction and Defend the Edge guidance are linked from the advisory.

A quick self-check from a machine on your office network is not enough. Confirm from outside your network, or ask your ISP or MSP to show you inbound listeners on the controller IPs.

3. Separate OT from office IT

Put controllers on a dedicated OT VLAN. Block casual paths from staff laptops, guest Wi-Fi and the point-of-sale network. The goal is simple: a phishing email on a cashier PC should not be one hop from the freezer setpoints.

4. Kill default passwords and add MFA

Change every default. Use unique, strong passwords. Turn on phishing-resistant multifactor authentication wherever the controller or the jump host supports it. If the panel cannot do MFA, put MFA on the VPN or bastion in front of it and stop exposing the panel itself.

5. Patch, or retire what the vendor abandoned

Update firmware. Build a short list of end-of-life controllers and schedule replacement. Unsupported panels with known remote flaws are exactly what the European supermarket reporting described. CISA’s BOD guidance on prioritising updates and end-of-support edge devices is cited in the CSA for a reason.

6. Allowlist who may change settings

Only known devices and IP ranges should be able to alter setpoints. If your vendor needs remote access for a service call, open it for that window, then close it.

7. Backups and visibility

Keep current backups offsite and offline, and test a restore. Enable logging and review it. Where OT logs are useless, capture the network traffic between the controllers and their management hosts instead. You cannot respond to a denial-of-view attack if you never had a second way to see the temperature.

8. Lock safe ranges and alerts

Define hard setpoint limits so a compromised panel cannot drive a room to cooking temperatures without an alarm. Alert on deviations. Have a human procedure for “the monitoring portal looks fine but the walk-in feels warm,” because denial of view is on the CSA’s effect list.

Commands I would actually run (on my own gear)

These are examples for a Linux jump host that reaches your controller VLAN. Adjust to your environment. Do not point them at systems you do not own.

# From an external vantage you control: which of YOUR public IPs answer on common management ports?
for ip in 203.0.113.10 203.0.113.11; do
  for p in 80 443 8080 8443 502 2222; do
    timeout 2 bash -c "echo >/dev/tcp/$ip/$p" 2>/dev/null \
      && echo "OPEN $ip:$p"
  done
done

# On the OT jump host: what is listening locally, and what routes reach the controller subnet?
ss -tulpn
ip route | grep -E '10\.|172\.|192\.168\.'

# After you change passwords and firmware, record the evidence for your change ticket
date -u
echo "controller: WALK-IN-3"
echo "firmware_before: <fill>"
echo "firmware_after:  <fill>"
echo "default_password_removed: yes"
echo "remote_access: vpn-only"

If something looks wrong, the CSA says US organisations should contact CISA at contact@cisa.dhs.gov or 1-844-729-2472, file with the FBI through IC3, and for healthcare supply impacts use HHSCyber@hhs.gov or the HHS operations centre.

Confirmed versus unknown

Confirmed today, from the CSA:

• Five US agencies judge the threat to industrial refrigeration and cold chain monitoring to be real and ongoing.
• Internet-accessible or unpatched controllers are the entry they care about.
• Effects include temperature change, continuous heating or defrost, inventory loss, fire hazard, and loss of monitoring view.
• Recommended actions are exposure reduction, OT isolation, credential hygiene, patching, allowlisting, backups, logging and setpoint limits.

Confirmed from separate reporting, not from the CSA text:

• French supermarket wave around Oct 12 with roughly 250 to 350 stores named in coverage.
• Older Danfoss controllers named in that French wave.
• French blood bank cold rooms targeted; staff prevented product loss.
• US military commissary freezer anomalies under investigation.

Still unknown:

• Who is behind which wave, and whether the waves are one campaign or several.
• Exact US victim counts for commercial sites.
• Whether every vendor class beyond the ones named in European reporting is affected the same way.

My take

I keep seeing the same OT mistake. A device that should only talk to a technician on site gets a public IP so someone can “check it from home.” That convenience is how you turn a fridge into a remote-controlled oven.

Today’s advisory is useful because it skips the drama and lists the boring fixes. Pull the panel off the internet. Patch or replace it. Separate the network. Lock the setpoints. If you do those four this week, you have already done more than most of the sites that made the news.

Want one short email a week on breaches, AI and what to do about them? Subscribe to Weekly Breach Notes at weeklybreachnotes.substack.com.

Sources

• CISA, FBI, HHS, USDA, DoT, “US Government Partners Urge Hardening Industrial Refrigeration and Cold Chain Monitoring Systems,” Nov 5, 2026: https://www.ic3.gov/CSA/2026/261105.pdf
• TechCrunch, “US government warns of ‘ongoing cyber threat’ amid mass hacks of industrial retail and military freezers,” Nov 5, 2026: https://techcrunch.com/2026/11/05/u-s-government-warns-of-ongoing-cyber-threat-amid-mass-hacks-of-industrial-retail-and-military-freezers/
• CNBC, “U.S. warns of ‘ongoing cyber threat’ to industrial refrigeration systems,” Nov 5, 2026: https://www.cnbc.com/2026/11/05/us-warns-of-ongoing-cyber-threat-to-industrial-refrigeration-systems.html
• The Record, “Harden cooling systems now, feds warn critical infrastructure operators amid attacks,” Nov 5, 2026: https://therecord.media/cyberattacks-refrigeration-cisa-fbi
• BleepingComputer, “Cyberattack shuts down refrigerators at French supermarkets,” Oct 12, 2026: https://www.bleepingcomputer.com/news/security/cyberattack-shuts-down-refrigerators-at-french-supermarkets/
• BBC News, “French blood storage impacted by freezer hacks as theories swirl about culprits,” Nov 4, 2026: https://www.bbc.co.uk/news/articles/c8vgxyvz6y9ro
• Military Times, “Pentagon treating military base freezer malfunctions as suspected cyberattack,” Oct 29, 2026: https://www.militarytimes.com/pentagon/2026/10/29/pentagon-treating-military-base-freezer-malfunctions-as-suspected-cyberattack-officials-say/

Image alt text

• Timeline: “Timeline of freezer and cold-chain attacks from late August 2026 through the November 5 US multi-agency advisory. Late Aug: US military commissaries. Oct 12: French supermarket wave, 250 to 350 stores, older Danfoss controllers named in reporting. Early Nov: second European wave and French blood banks with no product loss. Nov 5: CISA, FBI, HHS, USDA, DoT CSA.”
• Effects: “Flow diagram: internet-reachable controller, then exploit path (auth bypass, code injection, or weak config), then attacker control. Effects: temperature change, continuous heat or defrost, denial of view, unsafe product risk. Source: Nov 5 CSA.”
• Checklist: “Eight numbered checks from the US cold-chain advisory: find internet exposure, pull unnecessary access, separate OT, kill default passwords, patch or retire, allowlist changes, backups and logs, lock safe temperature ranges.”

Every Microsoft 365 tenant I’ve ever looked after has a few apps in it that nobody remembers adding. A backup service. A migration tool from three years ago. Something a reseller set up. They all got admin consent once, and nobody has looked at them since.

In the middle of October, one of those quiet apps woke up in other people’s tenants and started doing admin work. Microsoft now says an AI agent framework was driving it. I want to walk through what’s confirmed, what isn’t, and then the part I actually care about: how to check your own tenant, even if you’ve never used ConnectWise.

What happened

ConnectWise Cloud Backup, which used to be called SkyKick, is a backup service that MSPs use for their clients’ Microsoft 365 data. To back up mail, OneDrive, SharePoint and Teams, its app gets broad read and write access in every tenant where it’s installed.

On October 15, a credential belonging to that app was used from a hosting provider address (144.172.64.128) to get Microsoft Graph tokens in customer tenants. Huntress spotted it and published on October 16. By that evening they had confirmed unauthorized sign-ins in 162 tenants they could see. The credential type matters here: it was a client assertion, which is held on the vendor’s side. No setting in a customer tenant could have caused that or blocked it (Huntress, Oct 16).

The part that made me sit up was one tenant in Huntress’s write-up. There, a second ConnectWise app, the Cloud Management app for Microsoft Teams, put itself into the Global Administrator role. Then a Python script added fresh client secrets to two other apps in the same tenant, one of them Huntress’s own security app. The new secrets were good until 2028. The whole thing took about five minutes, starting at 03:44 UTC. A few days later Huntress found the same pattern in a second tenant, run 47 seconds after the first.

ConnectWise disabled seven of its app identities at 07:00 UTC on October 17 and revoked the certificates behind them. Its own advisory is careful to say that this stops new sign-ins through those apps but does not undo anything already changed inside a customer tenant (ConnectWise Trust Center). On October 28 it started a phased restore through a new app, “ConnectWise Cloud Backup for M365”, that partners have to authorize tenant by tenant. By its November 4 update most features were back, and the old apps are meant to stay off.

The AI part

On October 21, Microsoft put a name on it. It says a China-aligned group it tracks as Storm-0940 was behind the ConnectWise compromise, and that the group has been using ARTEX, an open-source framework where LLM agents run a penetration test from recon to data theft with little human input. Microsoft says the agents tried to sign in to more than 2,250 tenants with the stolen app access. Across the wider ARTEX campaign, it says there were multiple cases where the time from first targeting to privileged cloud access was under three hours (Microsoft Security blog).

Microsoft also tied an earlier password spray (October 10 to 14, from 144.172.64.99) to the same group. That spray went after 327 accounts at eight organizations, logged more than 151,000 failed sign-ins and, by Microsoft’s count, zero successes. So the passwords weren’t what worked. The stolen app trust was.

Huntress did something I appreciated. They went back through their own logs and asked whether it actually looked like an agent (Huntress, Oct 26). Their answer was careful. They saw plain scripts doing most of the work, plus something that changed the tooling between runs in under a minute. After a certificate upload failed, the next run 55 seconds later had retry logic that wasn’t there before. That fits an agent loop. It also fits a quick human. On their telemetry alone they put the chance an LLM was involved at low to medium, and medium to high once you add Microsoft’s attribution. They also saw a loop that kept firing for 22 minutes at a service principal that had already been deleted, which is not what you’d expect from something watching its own output.

So here’s where I land, and it’s an opinion, not a finding. The AI label is real enough that I’d take it seriously, but it isn’t what changes your to-do list. The attack was old: steal an app’s credential, use the consent the app already has, make it admin, plant more credentials so you survive the cleanup. What changes is the clock. If the gap from first touch to Global Admin is a few hours, or five minutes inside one tenant, then “we’ll review it Monday” is not a plan. Huntress put it in a line I’d stick on the wall: “detect what the activity does, not how it paces itself.”

What we know and what we don’t

Confirmed by the companies involved:

• A ConnectWise Cloud Backup app credential was used without authorization to get tokens in customer tenants on October 15 (Huntress, ConnectWise).
• In two tenants Huntress reviewed, a ConnectWise Teams app gave itself Global Administrator and new secrets were planted on other apps (Huntress).
• ConnectWise disabled seven app identities on October 17 and says existing backup archives show no sign of compromise (ConnectWise).
• Microsoft attributes the activity to Storm-0940 using ARTEX (Microsoft). Note that this is an intelligence assessment. Huntress says its data lines up with it but can’t confirm it independently.

Not confirmed, or not public:

• How the attacker got the vendor credential in the first place. ConnectWise says it first spotted a problem on October 14 and that the root cause is still under investigation.
• What data was read. Graph directory reads leave no audit record, and Huntress said none of the victims it knows of had Graph activity logging turned on. “No mailbox changes in the log” is not the same as “nothing taken”.
• The full list of affected tenants. Microsoft’s 2,250 is attempted sign-ins. Huntress only sees its own customers.

Why switching off the vendor app isn’t the end

This is the bit I’d explain to a manager. When the vendor revokes its credential, the front door closes. But if the attacker already used admin rights to add a secret to one of your other apps, that secret is a separate key. It signs in as that other app, from anywhere, with no user and no MFA prompt. Disabling ConnectWise does nothing to it.

That’s why this matters even if you never bought ConnectWise. Any multi-tenant app you’ve consented to with high permissions is the same shape of risk. Backup, migration, compliance, email security, the MSP’s management tool. If you can’t list them right now, that’s the first finding.

Check your tenant

Here’s what I’d do, in this order. I’ve kept it to things a small team can do with the licences they already have.

1. Save the logs before you touch anything. Entra keeps sign-in and audit logs for 7 days on the free tier and 30 days with P1 or P2 (Microsoft Learn). October 15 was 21 days ago. If you’re on the free tier, the key day has already rolled off and nothing will bring it back. If you’re on P1/P2, export now from Monitoring > Audit logs and the Service principal sign-ins tab. That window closes around November 14.

2. Look for the ConnectWise apps by App ID, not by name. Older tenants may show them as “SkyKick Cloud Manager”. The IDs Huntress and ConnectWise published:

506e08f9-6e9a-4da4-942b-a099a03644ae  ConnectWise Cloud Backup
2399d300-6fca-4e6a-a686-399fefe75b83  ConnectWise Cloud Management
24205314-2b89-4e07-a2a4-579e898a5640  Cloud Management - MS Teams
b78f6a77-d4e5-46fb-87e5-d1648bd02519  Cloud Management - Exchange Online
0de14c77-b9b0-4137-9360-34878a929827  Cloud Management - MS Graph
412dcf96-176d-4b3a-a1b0-4981ad66971e  Cloud Management - Partner Center
b2b55f5b-7758-4719-8d8f-88ae172e6bdb  Cloud Management - SharePoint Online

If you find one, set “Enabled for users to sign-in” to No under the enterprise app’s Properties. Don’t delete it. Microsoft and Huntress both say the same thing here: deleting throws away the consent and evidence you may need. And don’t turn the old apps back on. ConnectWise’s restore goes through a new app.

1. List every app that holds a directory role. In most small tenants this list should be short and boring. An app sitting in Global Administrator, Privileged Role Administrator, Application Administrator or Cloud Application Administrator needs a written reason. If it was put there recently and nobody on your team did it, treat that as an incident.

2. List every secret and certificate added recently. Check both app registrations and service principals. Secrets can live on either, and one added straight to a service principal won’t appear on the app registration’s Certificates and secrets page, so clicking around the portal can miss it. For each one added since about October 13, ask who made it. If nobody can say, remove it and rotate whatever that app could reach.

3. Search the audit log for changes started by an app, not a person. The events to look for are “Add member to role”, “Add service principal credentials” and the “Update application” entries for certificates and secrets. In a normal tenant, an app adding itself to a role or editing other apps is rare enough that every hit is worth reading. Huntress noted the vendor’s normal traffic used a .NET SDK user agent (kiota-dotnet), while the changes they saw came from Python-urllib/3.12. A mismatch like that is a good lead, though not proof on its own.

I wrote a read-only PowerShell script that does steps 2 to 5 in one go. It uses the Microsoft Graph PowerShell SDK, asks for read scopes only, and prints four tables. It changes nothing. Here is the core of it (the full file is linked at the end, and it’s worth trying in a test tenant first):

Connect-MgGraph -NoWelcome -Scopes 'Application.Read.All','RoleManagement.Read.Directory','AuditLog.Read.All'

# Apps that hold a directory role
$roleNames = @{}
Get-MgRoleManagementDirectoryRoleDefinition -All -Property 'id,displayName' |
    ForEach-Object { $roleNames[$_.Id] = $_.DisplayName }
Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty 'principal' |
    Where-Object { $_.Principal.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.servicePrincipal' } |
    ForEach-Object { '{0,-35} {1}' -f $roleNames[$_.RoleDefinitionId], $_.Principal.AdditionalProperties['displayName'] }

# Secrets and certificates added since a date, on service principals
$since = [datetime]'2026-10-13'
Get-MgServicePrincipal -All -Property 'id,appId,displayName,passwordCredentials,keyCredentials' |
    ForEach-Object {
        $sp = $_
        @($sp.PasswordCredentials) + @($sp.KeyCredentials) |
            Where-Object { $_ -and $_.StartDateTime -ge $since } |
            ForEach-Object { '{0:u}  {1}' -f $_.StartDateTime, $sp.DisplayName }
    }

# Audit events where an app (not a user) added someone to a role
Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge 2026-10-13T00:00:00Z and activityDisplayName eq 'Add member to role'" |
    Where-Object { $_.InitiatedBy.App.AppId } |
    Select-Object ActivityDateTime, @{n='ByApp';e={$_.InitiatedBy.App.DisplayName}}, Result

Honest limits. I checked that it parses and that the cmdlets and parameters exist in the current Graph modules, but I haven’t run it against a tenant hit by this incident, because I don’t have one. Credential start dates can be set by whoever creates the credential, so don’t treat “nothing recent” as a clean bill. The audit log is the better witness, if you still have it. And role assignments that are only PIM-eligible won’t show in the role list. In a small tenant that’s usually fine. In a bigger one, check PIM too.

If you hold the Defender XDR or Sentinel licences, Microsoft’s post has ready-made hunting queries that join service principal sign-ins with Graph activity. Use those. My script is for the tenants that don’t have them, which in my experience is most small ones.

Then make the next one slower

None of this stops a vendor from losing its own credential. It just makes what an attacker can do with it smaller and noisier.

• Block new client secrets. In the Entra admin center, go to Enterprise apps > Application policies > Block password addition and switch it on for all applications (Microsoft Learn). Test it first. Some of your own automation may still create secrets, and you can exempt specific apps. It won’t stop certificates, and a Global Admin can switch it off, but it removes the cheapest way to plant a key.
• Shrink who can edit apps. Count the people and apps holding Application Administrator and Cloud Application Administrator. Each one can add credentials to apps. Most small tenants need one or two at most.
• Get an alert, not a report. If you have P1 or P2 but no Sentinel, you can still send audit logs to a Log Analytics workspace and alert on “Add member to role” where the initiator is an app. The point is that someone’s phone buzzes within minutes, because that’s the timescale now.
• Turn on Graph activity logs if you can. It’s the one log that would have shown what was read, and Huntress said nobody they knew had it on.
• Ask your vendors one question. “Which permissions does your app hold in our tenant, and which of them do you actually use?” A backup app needs to read mail. It almost certainly doesn’t need to grant directory roles. If the answer is vague, that tells you something.

On Linux boxes I keep a baseline of who has sudo and which SSH keys exist, and I diff it, which is why I built sudodrift. It doesn’t touch Entra and won’t help with this incident directly. But the habit carries over: write down which apps hold roles and secrets today, save it, and compare next week. You can’t spot a new key if you never knew the old list.

Sources

• Huntress, “ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks” (Oct 16, updated through Oct 27): https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
• Huntress, “AI, Scripts, Operator: Inside the ConnectWise Attack” (Oct 26): https://www.huntress.com/blog/connectwise-attack-ai
• Microsoft Security, “AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise” (Oct 21): https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
• ConnectWise Trust Center advisory, Cloud Backup (Oct 16, updated through Nov 4): https://www.connectwise.com/company/trust/advisories
• ConnectWise, Cloud Backup technical investigation and remediation guide (Oct 18): https://www.connectwise.com/contentassets/10777cd3364d440c86ed5270a94a5f24/connectwise-cloud-backup-technical-investigation-and-remediation-guide-1.pdf
• Cybersecurity Dive coverage: https://www.cybersecuritydive.com/news/china-nexus-actor-attack-connectwise-cloud-backup/833727/
• Microsoft Learn, Entra data retention: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
• Microsoft Learn, app management policies: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies

Full script (read-only, it changes nothing): vendor-app-check.ps1 on GitHub. Read it before you run it, and try it in a test tenant first.

All images are original drawings by sudodrift.

I’ve done enough access reviews to know this one isn’t really about AI. It’s about a database rule nobody checked. But AI made it very easy to ship an app with real users before anyone asked who can read what.

If you built something with Lovable, or any app that talks to Supabase straight from the browser, this post shows you how to check it from the outside in about ten minutes.

What happened

Crissy Field GmbH, an application security firm, did the research with the German business paper Handelsblatt, which published its story on November 2, 2026. Crissy Field put its own write-up online in English, and Cybernews and others picked it up on November 4 (Crissy Field, Cybernews).

Here are their numbers, as they report them:

They found the projects in Common Crawl, a public archive of the web, covering December 2025 to September 2026. 24,664 sites sent database records as soon as the page loaded. That part can be fine, since some data is meant to be public. The problem came when they made a few more read-only requests with the same key. On 7,403 of those sites they could read tables holding email addresses.

The examples they give are the bad part. A German lifestyle forum with more than 80,000 profiles and over 200,000 chat messages. Event organizers and restaurants with ticket and food orders, including phone numbers, home addresses, payment information and ticket codes. A service provider with more than 1,000 passport records. And one I keep thinking about: a property management company that stored AI-written summaries of its internal emails about tenants and owners, readable by anyone.

What’s confirmed and what isn’t

Confirmed, by the researchers: the data was reachable without logging in, and they only used read-only requests.

Not confirmed: whether anyone else found this data first and used it. Crissy Field says plainly it could not tell. It also warns that the 30% figure is not a leak rate. Some of those email addresses could be public contact addresses or test data, and their sample is not every Lovable app.

Not public: which apps were affected. The researchers have not named them, and they kept their exact method to themselves. Good. I won’t guess at it either.

Lovable’s side: according to the coverage, Lovable said this is a known problem across the industry with how people set up Supabase, not a hack of Lovable. That’s partly fair. UpGuard separately reported readable tables on 16,326 Supabase databases, per Cybernews. But “it’s everyone’s problem” doesn’t help the person whose passport number is sitting in a table.

Why the key in your page isn’t the problem

This trips people up, so here’s how it works.

A Supabase app running in the browser carries a public key, often called the anon key or publishable key. It is supposed to be visible. Anyone can open developer tools and see it.

What protects your data is Row Level Security, or RLS. It’s a set of rules inside the database that says which rows each visitor may read or change. With RLS on and good rules, the public key gets a stranger almost nothing. With RLS off, or with a rule that says “allow everyone”, that same key reads the whole table.

So the fix is never “hide the key”. The fix is the rules.

How to check your own app

You need to own the app or have permission to test it. Only test your own project.

1. Run Lovable’s own scan, and read it

Lovable’s docs say a Quick scan runs when you open the Publish dialog and checks for things like tables without RLS and access rules that let everyone through. There’s also a Deep scan you start yourself from the project’s Security view, and your policies are under More, then Database, then Manage, then Policies (Lovable docs).

One detail matters. The same docs say findings do not block publishing by default. So a scan that warned you and got clicked past is exactly how a table ends up open. If you’re a workspace admin, Lovable has a setting to block publishing on critical findings (Lovable publish docs). I’d turn it on.

2. Look at the rules yourself

Open the SQL editor in your Supabase dashboard and run this. It’s read-only.

-- Which tables in the public schema have RLS switched off?
select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

-- What rules exist, and what do they allow?
select tablename, policyname, cmd, roles, qual
from pg_policies
where schemaname = 'public'
order by tablename;

In the first result, any table with rowsecurity set to false is readable through the public key, as long as that table is exposed through the API. In the second, look for rules where qual is just true and roles includes anon or public. That means “anyone can read every row”. It’s fine for a menu or a blog post. It’s not fine for orders, profiles, messages or anything with an email in it.

Supabase’s dashboard also has a Security Advisor that flags tables with RLS off. Worth a look, but read the rules yourself too.

3. Test from outside, the way a stranger would

This is the step most checklists skip, and it’s the one that tells you the truth. Open your live site in a private window, open developer tools, and look in the Network tab for requests to supabase.co. You’ll see your project address and the public key in the request headers.

Then, from a terminal, ask for one row of each table that holds anything private:

PROJECT="https://YOUR-PROJECT.supabase.co"
KEY="the public key your page sends"

for t in profiles orders messages bookings; do
  echo "== $t"
  curl -s "$PROJECT/rest/v1/$t?select=*&limit=1" \
    -H "apikey: $KEY" \
    -H "Authorization: Bearer $KEY"
  echo
done

Change the table names to yours. If your key is one of the newer sb_publishable_ keys and the request complains about the Authorization header, drop that line and keep apikey.

What you want back for private tables is an empty list [] or a permission error. If you get a real row with a real person’s data, that table is open to the world right now.

4. If something is open

Turn RLS on for that table and write a rule that limits rows to their owner. For a table with a user_id column, the common pattern looks like this:

alter table public.orders enable row level security;

create policy "owners read their own orders"
on public.orders for select
to authenticated
using ( (select auth.uid()) = user_id );

Test the app afterwards, because turning RLS on with no rules blocks everyone, including your own users. Then run the curl test again and make sure you get nothing back.

If personal data was readable, treat it as possibly seen. You can’t prove it wasn’t. Depending on where you and your users are, that may mean you have to notify people or a regulator. In Canada that’s PIPEDA’s breach rules, in Europe it’s GDPR. I’m not a lawyer, so if you’re unsure, ask one.

One more habit: don’t store what you don’t need. Nobody can leak a passport number you never collected.

If you’re a user of a small app

Honestly, you can’t check this from your side, and the researchers didn’t name the apps. What you can do is expect the follow-up. Exposed order and ticket records are perfect material for scam emails and texts that quote a real booking or a real ticket code. If a message knows your recent order and asks you to “confirm payment” or “reissue your ticket”, go to the site yourself instead of clicking.

My take

I don’t think the lesson is “don’t build with AI”. People have shipped open databases by hand for years. The difference is speed. An app can go from idea to taking payments in an afternoon, and the one thing the tool can’t know is which of your tables is private. You have to tell it, and then you have to check.

If you only do one thing from this post, do the curl test. It takes five minutes and it shows you what a stranger sees.

Sources

• Crissy Field GmbH, “Lovable: Many Apps Expose Sensitive Data”: https://www.crissyfield.de/research/lovable-en/
• Cybernews, “Apps built on Lovable AI expose passport details and 200,000 chat messages” (Nov 4, 2026): https://cybernews.com/security/lovable-ai-apps-expose-personal-information/
• Lovable docs, Security overview: https://docs.lovable.dev/features/security
• Lovable docs, Publish your Lovable project: https://docs.lovable.dev/features/publish
• Lovable docs, Security best practices: https://docs.lovable.dev/tips-tricks/security-best-practices

If you want one short, practical security note like this each week, subscribe to Weekly Breach Notes.

On October 16, 2026, Google changed one sentence in its privacy policy. It used to say Google does not show you personalized ads based on your content from Drive, Gmail or Photos. Now that sentence ends with an exception: “unless you choose to make data from these services available to other Google services that support personalized ads” (Google Privacy Policy).

Most of the coverage stopped at the ads part. That is fair, it is the news. But I went and read Google’s own help page for the feature behind it, and the ads are the smallest part of what you agree to when you click Connect.

This post is about what that switch actually lets Google’s AI see, where it goes after that, and how to check your own account in a few minutes.

What changed, in plain words

Google has a feature called Personal Intelligence. In Search, it lets AI Mode and Ask Maps use your past searches, and, if you connect them, your Gmail, Google Calendar and Google Photos, to give answers that fit you. Google’s example is using an old restaurant booking in your email to suggest new places to eat (Google Search Help).

The October policy change says that if you make that data available to a Google service that shows personalized ads, it can shape those ads too. The Verge and Ars Technica both reported this after Android Authority spotted it (The Verge, Ars Technica).

Google told Ars that connecting is fully optional, and that ads won’t be built straight from your inbox or photo library.

So if you never clicked Connect, this does not apply to you. If you did, or you are not sure, keep reading.

What the connection reaches

This is the part I did not expect. Google’s help page says that connecting your apps means all Search services are allowed to access them, not only AI Mode. It lists those services as Google Search (including AI Mode and Discover), Maps (including Ask Maps), Shopping, Flights, Hotels, Translate and News.

Right now the Workspace side means Gmail and Google Calendar, and Google says more Workspace apps will follow. Calendar is only offered in the US in English. Photos is not offered everywhere.

Canada, the US, India and Australia are all on the list of places where this is available. Google’s help page says it is for users 18 and over with a personal Google account.

What happens to what it reads

Here is what Google’s help page says, in my own words.

It uses summaries, not your whole inbox. Mostly. Google says Search works from summaries, short excerpts and guesses it draws from the emails and photos that matter to your question. But the same page also says that when an email or file is short, or very relevant, the summary “may just be the email or file.” So for a short booking email or a one line message, the summary can be the message itself.

It can train Google’s AI models. If you connect, Google says it may use that data to improve its services for all users, and that includes training its generative AI models on those summaries and excerpts. It also trains on your questions and its answers. Google says it takes steps to reduce personal information before training.

People may read some of it. Google says a subset of the data that AI Mode and Ask Maps process is reviewed by human reviewers, including outside service providers. That subset can include summaries and excerpts from your emails, and again, sometimes the summary is the email. Google says it disconnects these from your account and reduces personal details first. For Photos, it says humans do not view your actual media except for abuse cases or when you send feedback.

Google’s own advice on that page is blunt. Do not connect your apps if they hold personal or confidential information you would not want a reviewer to see. I think that sentence should be on the Connect button, not halfway down a help page.

It feeds ads. Google says the same summaries and excerpts Search uses to answer you can also pick the ads you see. Advertisers do not get your inbox or photos, and Google says it does not target ads on sensitive categories like race, religion, sexual orientation or health.

Disconnecting does not clean up. Google says that disconnecting an app, or deleting the email or photo, does not delete anything already saved in your Search Services History. Google can keep using that saved copy to improve its products, AI training included. You have to delete the history yourself.

What we do not know

I want to be honest about the gaps.

Google does not say how big the “subset” sent to human reviewers is. It does not say how long reviewed data is kept. It does not explain what an “inference” looks like in practice, for example whether “this person is planning a trip to Lisbon” counts.

I also could not click through these settings on a real account for this post. The menu names below come from Google’s help page and from Android Authority’s walkthrough. Google also says the Search services settings are being updated right now, so your screen may look a bit different.

Who this affects

• Anyone who tried AI Mode or Ask Maps and clicked Connect when it asked to use Gmail or Photos.
• Families that share one Google account on a tablet or laptop. One person connecting it connects it for everyone’s mail on that account.
• People whose inbox holds medical, legal, money or work email they would never paste into a chatbot.

How to check your account in about 5 minutes

1. See what Search is connected to. Go to your Google Account, then Data & privacy, then Personalization settings, then Manage Personalized Recommendations in Search Services. Under Additional Personal Intelligence, open Connected Content Apps. If Google Workspace or Google Photos says Connected, click it to disconnect. Android Authority says you will see a warning that data already collected can still be used.

2. Decide on the bigger switch. On that same Search Services page you can turn off Personalized Recommendations entirely. That is the stronger option. You will get less tailored results.

3. Delete what is already saved. Disconnecting is not deleting. Go to activity.google.com, find your Search Services History, and delete it, or set auto delete to the shortest period you are comfortable with.

4. Check Gmail’s own switch. In Gmail on a computer, open Settings, then See all settings. On the General tab, find Google Workspace smart features and select Manage Workspace smart feature settings. Google’s help page says “Smart features in other Google products” needs to be on for Search to personalize from Gmail. Turning it off is a second lock. Be aware it can turn off other helpful features too, so read what it lists before you save.

5. Check Gemini separately. The Gemini app has its own Personal Intelligence and connected apps settings. Android Authority says disconnecting in Search does not stop the Gemini app from reading Gmail or Photos if you allowed it there. Open Gemini’s settings and look at its connected apps list too.

If you use a work or school Google account, your admin controls most of this, and Google says the feature needs a personal account.

My take

I do not think connecting is always wrong. Asking Maps for directions to the hotel in your booking email is useful. But the trade is bigger than “better answers, maybe some ads.” It is answers, ads, AI training and a chance that a person reads a short email of yours. If your inbox is the place where your whole life lives, I would leave it disconnected and paste in the one booking email when you need it.

Want one short email a week on breaches and what to do about them? Subscribe to Weekly Breach Notes.

Sources

• Google Privacy Policy, effective October 16, 2026: https://policies.google.com/privacy
• Google Search Help, “Connect your Google content apps to get a Search services experience that’s tailored to you”: https://support.google.com/websearch/answer/16859283?co=GENIE.Platform%3DDesktop&hl=en
• The Verge, “Now Google says it might use your Gmail and Google Photos data to target ads,” Oct 23, 2026: https://www.theverge.com/tech/1017600/google-personal-intelligence-privacy-policy-ads-update
• Ars Technica, “Updated Google privacy policy says your Gmail might be used for advertising,” Oct 2026: https://arstechnica.com/gadgets/2026/10/updated-google-privacy-policy-says-your-gmail-might-be-used-for-advertising/
• Android Authority, “How to stop Google from using your Gmail or Photos info for ads”: https://www.androidauthority.com/google-personal-intelligence-ads-opt-out-3729942/

Most phishing advice comes down to one check. Look at who really sent the email.

This scam passes that check. The email really does come from Google. It’s signed by Google, it lands in the same thread as your other Google alerts, and the buttons in it go to real Google pages. The only fake part is a single line of text in the middle. A scammer typed it.

I think this one is worth ten minutes, mostly because the usual tips make it more convincing, not less.

What happened

Two security teams wrote up the same trick from different sides.

In September, Switzerland’s federal cybersecurity office (BACS, the former NCSC) described a case that started with a genuine Google security warning (NCSC Switzerland, Week 38). The scammers had made their own new Google account and put the victim’s email address in as that account’s recovery address. Then they created an app password in their own account. An app password is an old style passcode for apps that can’t do a normal Google sign-in, and Google lets you give it any name you like.

They named it something like “Kevin W. Case ID: 834333 To view your case”. Google sent its normal alert about the new app password to the recovery address, which was the victim. Google’s email repeated the name. So the victim saw what looked like Google opening a support case, with a case handler and a case number.

A phone call followed from someone claiming to be Google security support, showing a Swiss number. The caller pushed the victim to a login page built on Google Sites, so the web address still said google. The form sent the password to the scammers.

On October 6, the University of Michigan’s IT security team posted a second version (U-M Safe Computing). This time the app password was named after a fake McAfee invoice for $399 with a support phone number. The genuine Google alert was then forwarded on to people at the university, and because it carried valid signatures it passed all of their mail checks.

The clever part

U-M points out something I hadn’t thought about. If you do the careful thing and click the real “check activity” button, you land on your own Google account. Nothing is wrong there, because the app password was made on someone else’s account.

That’s on purpose. You’re worried, you checked, and you found nothing. The only thing left in the email that looks like it might explain the charge is the phone number.

What’s confirmed and what isn’t

Confirmed by the two official write-ups:

• The alert emails are genuine Google messages. The scam text rides inside the app password name.
• One version pushes you to call about a fake invoice. The other is followed by a call from fake Google support.
• In the Swiss case, after getting the password, the scammers set up their own app password inside the victim’s real account within minutes. BACS says that let them keep access even after the victim changed the password, and email and contacts kept syncing to a device abroad for some time.

Not known: how many people got these emails, how many called, or how much money was lost. Neither source gives numbers, so I won’t guess.

One honest wrinkle. Google’s own help page says it revokes your app passwords when you change your Google password (Google Account Help). The Swiss report says the scammers kept access after a change anyway. I can’t tell from the outside why those two don’t match, maybe the timing or how the change was done. So I’d do both: change the password and also delete app passwords by hand. It costs you thirty seconds.

How to read one of these emails

1. Read the account line first. A Google alert names the account it’s about. If that address isn’t your account, the alert isn’t about you. It’s about the scammer’s account, with you listed as their backup.
2. Treat any invoice, case number or phone number as the scammer’s words. In this trick, that’s the only part they control.
3. Never call a number from an email about a charge. If you think you were billed, open your bank or card app yourself and look.
4. Check your account by typing the address. Google’s advice is to go to myaccount.google.com/notifications yourself to see recent security activity (Gmail Help). If nothing is there, good. That matches this scam.
5. Google won’t phone you about this. BACS’s advice is to hang up on any unexpected call about a security incident. Never read out a code or type a password while someone on the phone is telling you to.
6. Real Google sign-in pages are on accounts.google.com. Not sites.google.com, even though that one also says google.

If you think you already gave out your password

Do this from a device you trust, not one the caller asked you to install anything on.

1. Change your Google password at myaccount.google.com, then Security.
2. On the same Security page, open “Your devices” and sign out anything you don’t know.
3. Go to myaccount.google.com/apppasswords. Delete every entry. BACS says all of them, without exception. If you have an old printer or mail app that needs one, make a fresh one later.
4. In Security, check your recovery email and recovery phone. Remove anything that isn’t yours.
5. In Gmail on a computer, open Settings, See all settings, then Forwarding and POP/IMAP, and Filters and Blocked Addresses. Delete any forwarding or filter you didn’t set up.
6. If you paid or let anyone onto your computer, call your bank now, then report it. In Canada that’s the Canadian Anti-Fraud Centre. In the US, the FTC at reportfraud.ftc.gov.

What I didn’t test

I haven’t recreated this. I didn’t make an app password with a scam name to see what Google sends, because I’m not going to try a scammer’s recipe on Google’s mail system. Everything above about the email itself comes from the two security teams’ write-ups. The steps for cleaning up your own account use Google’s own help pages.

My honest take

For years we told people to check the sender. That’s still good advice. But this scam shows the sender check isn’t enough on its own anymore, because the sender is real.

The better habit is simpler. A security email can tell you something happened. It should never be the place you get a phone number from. If a number is in there, someone put it there for you to call, and that someone isn’t Google.

If your parents use Gmail, this is the one I’d mention at dinner. Older relatives are exactly the people who’ve learned “check it’s really from Google” and will feel safe when it is.

Weekly Breach Notes is my free newsletter. Subscribe if you want one short email a week on what leaked and what to do about it.

Sources

• NCSC Switzerland (BACS), “Week 38: Genuine Google emails, fake support and a dangerous back door,” Sep 22, 2026: https://www.bacs.admin.ch/en/26w38-en
• University of Michigan Safe Computing, “App password created to sign in to your account,” Oct 6, 2026: https://safecomputing.umich.edu/phishing-alerts/app-password-created-sign-your-account-tue-10062026-1200
• Google Account Help, “Sign in with app passwords”: https://support.google.com/accounts/answer/185833?hl=en
• Gmail Help, “Avoid and report phishing emails”: https://support.google.com/mail/answer/8253?hl=en
• Canadian Anti-Fraud Centre: https://antifraudcentre-centreantifraude.ca/
• FTC, ReportFraud: https://reportfraud.ftc.gov

All images are original drawings by sudodrift. The email is a mock-up with made-up addresses and a fake number, not a copy of a real message.

Most teams I talk to have a careful process for production. Named people, MFA, change tickets, logs someone actually reads. Then there’s the domain. It was bought years ago on someone’s personal card, the login lives in a shared password manager entry, and the recovery email points at a mailbox nobody has opened since the founder left.

That login can send every visitor to any server on the internet. Over the weekend of Oct 30, a group of crypto projects found out what that looks like.

What happened

Late on Friday, Oct 30, the websites of several DeFi projects started serving a wallet drainer. Security firm Blockaid flagged Flap and Kintsu first, then ten more sites, including Pickle Finance and Origami Finance. The pages ran Step Drainer, a kit that gets visitors to sign wallet approvals that move their funds out (The Block).

The common thread was the registrar. Registry records showed all twelve sites Blockaid named were registered through Name.com, even though their DNS was hosted in different places: some on Cloudflare, some on Vercel, some with Name.com itself. Name.com later told The Block that 15 customer domains were affected, that all of them had been restored, and that it had “taken steps to secure the accounts involved” (The Block, Crypto Briefing). Vercel posted a bulletin saying 10 affected domains were associated with its platform (Vercel).

The Block traced about $138,000 to three attacker wallets on EVM chains. That number leaves out anything taken on Solana or Aptos, where some of the affected projects run, so treat it as a floor. The projects that commented said their smart contracts were untouched. The money went out through signatures on a page that looked right, at the right address.

What nobody knows yet

How the attackers got in. As of Sunday morning, no one has published a root cause. Some projects blamed Vercel. FluxBeam’s developer said Name.com’s representative was pointing at third parties. Name.com told customers to check their DNS records and turn on two-factor authentication, which tells you what it thinks matters, but not what happened.

So I’m not going to tell you this was a stolen password. It may have been an internal system, a reseller path, or something else. The useful point holds either way: whoever can edit the delegation of your domain controls your users. Your job is to make that set of people and systems as small and as noisy as you can.

Why I call it a production admin account

Think about what the registrar login can do without touching a single one of your servers:

• change the nameservers, so a different company answers every DNS question about you
• point your login page, your API and your mail at someone else
• let an attacker pass the domain check a certificate authority runs, so their copy of your site gets a real padlock
• in the worst case, start a transfer to another registrar

That’s more reach than SSH on any one box. Yet most of us would never let ten people share a root password, and plenty of us share the registrar login without blinking.

The access review

This is the checklist I’d walk through for every domain that carries logins, payments or a wallet connection. It takes about an hour for a small team.

1. Find out who really holds the account. If you bought the domain through a hosting or app platform, the registrar account may belong to that platform, not to you. Ten of these domains sat behind Vercel. Write down the registrar, the account owner, and any reseller in between. If you don’t control the account, you can’t harden it, and you should decide whether that’s acceptable for this domain.

2. Count the humans. List everyone who can log in, including old shared logins and sub-accounts. For most small companies the right number is two named people. Not one (you get locked out when they leave) and not everyone in engineering.

3. Strong second factor, with no SMS fallback. Turn on 2FA for every person and every account in the chain: registrar, DNS host, reseller. Use a security key or passkey if the provider supports one, because a code from an app can be phished in real time. If only app codes are on offer, use them, store the backup codes offline, and remove SMS as a fallback where you can.

4. Give the recovery email its own home. Whoever controls the recovery mailbox can usually reset the account. If that mailbox is admin@yourdomain.com, you have a loop: lose the domain, lose the email that would get it back. Use an address on a different domain, protected with the same strong 2FA, and readable by at least two people.

5. Kill the API keys you don’t use. Registrar APIs are great for automation and terrible as forgotten credentials. List every token. Delete the ones nobody can explain. Scope the rest to the domains they need, if the registrar allows it.

6. Turn on the registrar’s change lock. A plain transfer lock (clientTransferProhibited) stops transfers out. It does nothing against a nameserver change. Look for the lock that also blocks updates. On Name.com that’s PrivacyLock, which needs 2FA to turn on and a 2FA code to turn off, and blocks DNS, nameserver and contact changes (Name.com docs).

7. Ask for registry lock on the domains that carry money. Registrar locks live in the account you’re trying to protect. Registry lock is set at the registry itself, using the serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited statuses (ICANN EPP status codes). Undoing it needs an out-of-band step between the registrar and the registry, so a stolen login alone isn’t enough. Not every registrar or TLD offers it, and it usually costs extra. For a domain that fronts a wallet, I’d pay for it or move the domain to a registrar that offers it.

8. Turn on DNSSEC, and know what it doesn’t do. DNSSEC lets resolvers check that answers really came from the nameservers you delegated to. That protects you from spoofed answers and some attacks on the DNS host. It does not stop someone who controls your registrar account from changing the nameservers and the DS record together. It’s worth having. It isn’t a substitute for steps 3, 6 and 7.

9. Alert on changes from outside. Don’t rely on the registrar to tell you. Check from the internet every few minutes and alert on any difference in:

• the NS records at the parent zone (dig +short NS example.com @a.gtld-servers.net for a .com)
• the EPP status codes (an RDAP lookup shows them; a new clientHold, or a lock that vanished, is a red flag)
• new certificates for your names in Certificate Transparency logs, especially from a CA you don’t use

Free tools already do this well, so I won’t write another one. Pick one and make sure the alert lands somewhere a person sees at 11 PM on a Friday.

10. Write the bad-night runbook now. Who calls the registrar’s abuse line? Who has the account number and the security phrase? Who posts the warning to users? Some of the affected teams limited the damage by moving their nameservers quickly. That only works if someone already knows how, and has the access, before it happens.

The short version

No single row is enough. Together they turn “one login moves everything” into “several people and an offline step move everything, and we hear about it in minutes.”

My honest take

DeFi teams spend a lot on smart contract audits, and that’s fine. This weekend the contracts were fine and users still lost money, because the weak part was a web account most of us set up once and forget. You don’t need to run DeFi for this to apply. If your domain hosts a login page, it’s production. Give its keys the same respect.

Weekly Breach Notes is my free newsletter. Subscribe if you want one short email a week on what leaked and what to do about it.

Sources

• The Block, “Hackers hijack a dozen DeFi websites, all registered with Name.com, and steal about $138,000,” Oct 31, 2026, updated 3:37 PM ET: https://www.theblock.co/news/defi/2026-10-31-hackers-hijack-a-dozen-defi-websites-all-registered-with-name-com-and-steal-about-138000-432251
• Crypto Briefing, “Name.com restores hijacked domains after attack hit at least 12 DeFi front ends,” Oct 31, 2026: https://cryptobriefing.com/name-com-restores-hijacked-defi-domains/
• Vercel, “Name.com domain takeover notice,” Oct 31, 2026: https://vercel.com/kb/bulletin/name-com-domain-takeover-notice
• Name.com Core API docs, “Understanding Domain Locks”: https://docs.name.com/guides/domain-locks
• ICANN, “EPP Status Codes: What do they mean, and why should I know?”: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

The image is original by sudodrift.

On October 19 a stolen developer account was used to replace the release files of ovhcloud-cli v0.11.0 through v0.15.0. The tags stayed the same. On the newest releases the attacker replaced checksums.txt too, last, so the published hashes matched the new files. Anyone who checked the binary against that file saw a clean result and ran a credential stealer.

OVHcloud’s advisory says a customer reported the problem through a GitHub issue. StepSecurity’s write-up of the swap shows how that customer noticed: their CI pinned the SHA-256 of the Linux arm64 tarball in their own repository, and the build failed. Nobody who trusted the release’s own checksums file caught anything. (I covered the incident itself in an earlier post.)

So “verify the download” has to mean something stronger than “the hash matches a file next to it.”

Three checks that ask who built it

1. GitHub artifact attestations, with the workflow pinned.

gh attestation verify ./tool \
  --repo OWNER/REPO \
  --signer-workflow OWNER/REPO/.github/workflows/release.yml

That fetches the signed attestation for this exact digest and checks that it was produced by that workflow in that repository. Use --signer-workflow or --cert-identity (exact SAN), not both; gh rejects the combination. Add --deny-self-hosted-runners if you do not want attestations from runners you do not control. --repo alone is the floor. Pinning the workflow is the useful part.

2. Immutable releases, then the local file.

gh release verify v1.2.3 -R OWNER/REPO
gh release verify-asset v1.2.3 ./tool -R OWNER/REPO

gh release verify checks that the release exists and is immutable. gh release verify-asset checks that your file on disk is an exact match for the attested asset of that tag. It cannot verify the auto-generated source zip or tarball, because those are built at download time.

OVHcloud’s clean v0.16.0 is an immutable release, so the fixed CLI is a real example: gh release verify-asset v0.16.0 ovhcloud-cli_Linux_x86_64.tar.gz -R ovh/ovhcloud-cli.

3. Cosign on a container digest, with identity constraints.

cosign verify ghcr.io/OWNER/REPO@sha256:DIGEST \
  --certificate-identity=https://github.com/OWNER/REPO/.github/workflows/release.yml@refs/tags/v1.2.3 \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Verify the digest, never a floating tag. Since Cosign 2.0, keyless verification refuses to run without an identity and an issuer, which is good. The trap now is a regex so loose it matches anyone, such as --certificate-identity-regexp '.*'. That only proves someone in the Sigstore ecosystem signed it. Pin the digest in the Dockerfile or the deploy script so a later run fails if the image moves.

What still proves almost nothing

• A SHA256SUMS or checksums.txt downloaded from the same release or the same server as the binary. The ovhcloud-cli swap replaced both.
• Fetching the GPG key from the same site as the package.
• cosign verify with an identity regex of .*.
• curl | sh. The ovhcloud-cli install script did no checksum check at all.

Store the expected SHA-256 in your own repository, next to the download instruction. Then the release can be swapped and your CI still fails.

Where releasedrift fits

Most teams never get as far as attestations because the download is not pinned at all. releasedrift walks a source tree, finds every GitHub release download in Dockerfiles, shell scripts, Makefiles, Actions workflows and Ansible playbooks, and tells you which ones have no SHA-256 nearby and which ones only check against a checksums file from the same release. Without --offline it also asks the GitHub API for the digest GitHub reports for each asset and keeps it in a state file, so a later run notices when a file was replaced, and it warns when a release is not immutable. It only reads, and works without a token.

go install github.com/sudodrift/releasedrift/cmd/releasedrift@latest
releasedrift --offline /path/to/your/repo

Here it is on the sample tree that ships in the repository:

The finding that matches the ovhcloud-cli failure mode is tagged same-release-checksums. The fix line is the whole point of this post: store the expected SHA-256 in this repository instead of fetching it from the release.

Once every download is pinned, add the attestation or cosign check for the ones that publish one. Pinning without provenance still beats a checksums file that travels with the binary. Provenance without a pin still lets a later tag move under you.

Sources

• GitHub Docs, Verifying the integrity of a release (gh release verify, gh release verify-asset)
• GitHub CLI manual, gh attestation verify (use --signer-workflow or --cert-identity, not both)
• Sigstore, Verifying signatures with Cosign and Cosign 2.0 released (identity flags required)
• OVHcloud CLI advisory GHSA-862f-55f5-vmvw, the reporter’s issue #300, and StepSecurity’s write-up of the swap
• Free tool: sudodrift/releasedrift (v0.1.0)

On Thursday, the AI coding assistant a lot of developers trust with their whole repo turned into an SSH backdoor for part of a day. Nobody’s model went rogue. Someone got a poisoned copy of the extension into the store, and auto-update did the rest.

Most write-ups already give you the one-line check. It’s a good check. But it only looks at the account you’re logged in as. I look after endpoints for a living, and that’s not how shared Macs, lab machines or build boxes work. So this post is about checking the whole machine, and then the whole fleet, with two small read-only scripts.

What happened

Cursor posted a security notice on Oct 29. Between about 2:27 AM and 1:35 PM Pacific time (5:27 AM to 4:35 PM in Toronto), a maliciously modified Anthropic.claude-code extension was served from the Cursor VS Code Extension Marketplace. Cursor’s notice, updated Oct 30, names versions 2.1.312 and 2.1.313 for Windows and macOS (Cursor notice).

Cursor says the code:

• collected host details (hostname, username, OS, home folder, the names of environment variables, Git email, public IP) and sent them to a server at 134.209.82.225
• added an attacker SSH key, labelled svc-telemetry, to authorized_keys
• tried to switch on SSH on the machine and dial a reverse tunnel out to that server
• set up persistence that keeps retrying the tunnel about every 60 seconds: a LaunchAgent on macOS, a scheduled task called SysMon on Windows

Microsoft Threat Intelligence published its own analysis the next day. It says the packages were never on the Visual Studio Marketplace or the npm CLI package, and that Anthropic told Microsoft its systems were not compromised and it did not build the bad package (Microsoft Security blog). Ars Technica reports Cursor put the reach at “at most 5,000 users” (Ars Technica).

What’s confirmed and what isn’t

Confirmed by Cursor: the time window, the behaviour above, that the attacker server is now offline, and that switching SSH on requires admin rights, which most installs of the extension never had. On most Macs and Windows PCs that part broke, so the attacker had no way to log in through the tunnel. The planted key, the startup items and the host report went through anyway.

Not known yet: how the package got into the marketplace. Ars says neither Cursor nor Anthropic has explained it. Sources also disagree on whether only 2.1.313 was bad or 2.1.312 too, and on whether Linux builds were served. Cursor’s own indicators only list macOS and Windows packages, but researchers describe a Linux branch in the loader (HOL Guard write-up). I’d check Linux dev boxes anyway. It takes a minute.

There’s one case where “the tunnel probably failed” doesn’t help you: a machine where SSH was already on. Think Macs with Remote Login enabled, Linux workstations and dev VMs running sshd, or anyone who launched Cursor as admin. On those, the key plus the tunnel is a working way in.

Why I’d check every profile

The public check is grep svc-telemetry ~/.ssh/authorized_keys. That’s the right first move on your own laptop.

On a shared Mac, a classroom PC or a build server, the person who used Cursor on Thursday may not be the person sitting there today. Every piece of this lives in a user’s home folder: the key, the .config/.smt files, the LaunchAgent, the temp key file. Uninstalling or updating the extension removes none of it, because none of it is inside the extension folder. So a check that only reads ~ can come back clean on a machine that isn’t.

Two more small things I’d watch for:

• The svc-telemetry label is only a comment at the end of the key line. Anyone can rename it. I match on the key itself too.
• Phorion, as summarised by HOL Guard, found that the Linux persistence step can wipe your existing cron jobs if it ran more than once. Save crontab -l before you touch anything.

How to check one whole machine

These two scripts only read. They don’t delete, change or send anything. Each one prints what it found and exits with 1 if anything turned up, so you can drop them straight into an MDM or remote management tool.

macOS and Linux

Run it with sudo so it can read every user’s folder. Save it as cc-sweep.sh and run sudo sh cc-sweep.sh.

#!/bin/sh
# cc-sweep.sh: read-only check for the Oct 29, 2026 Claude Code extension backdoor.
# Looks at every user profile on a macOS or Linux machine. Changes nothing.
# Run with sudo so it can read other users' folders. Exit code 1 means something was found.
KEYBODY='AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P'
HOMES="${HOMES:-/Users/* /home/* /root}"
hits=0
hit() { echo "FOUND  $1"; hits=$((hits+1)); }
for h in $HOMES; do
  [ -d "$h" ] || continue
  ak="$h/.ssh/authorized_keys"
  if [ -f "$ak" ]; then
    if grep -q -e svc-telemetry -e "$KEYBODY" "$ak"; then
      hit "attacker key in $ak"
    fi
  fi
  for f in "$h/.config/.smt" "$h/.config/.smtk" "$h/Library/LaunchAgents/com.apple.sysmond.plist"; do
    [ -e "$f" ] && hit "persistence file $f"
  done
  for e in "$h"/.cursor/extensions/anthropic.claude-code-2.1.312* "$h"/.cursor/extensions/anthropic.claude-code-2.1.313*; do
    [ -e "$e" ] && hit "bad extension folder $e"
  done
done
for t in /tmp/.stk_* /var/folders/*/*/T/.stk_*; do
  [ -e "$t" ] && hit "tunnel key file $t"
done
for c in /var/spool/cron/crontabs/* /var/spool/cron/* /usr/lib/cron/tabs/*; do
  [ -f "$c" ] && grep -q '\.config/\.smt' "$c" 2>/dev/null && hit "cron entry in $c"
done
ps axww | grep -q '[1]34\.209\.82\.225' && hit "tunnel process running"
echo "findings: $hits"
[ "$hits" -eq 0 ]

Windows

Run it from an admin PowerShell, or as SYSTEM. Save it as cc-sweep.ps1 and run powershell -ExecutionPolicy Bypass -File .\cc-sweep.ps1.

# cc-sweep.ps1: read-only check for the Oct 29, 2026 Claude Code extension backdoor.
# Looks at every user profile on a Windows machine. Changes nothing.
# Run as admin or SYSTEM (for example as an Intune Remediations detection script).
# Exit code 1 means something was found.
param([string]$UsersRoot = 'C:\Users', [string]$ProgramData = 'C:\ProgramData')
$KeyBody = 'AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P'
$found = @()
$keyFiles = @(Join-Path (Join-Path $ProgramData 'ssh') 'administrators_authorized_keys')
foreach ($u in Get-ChildItem -Path $UsersRoot -Directory -Force -ErrorAction SilentlyContinue) {
    $p = $u.FullName
    $keyFiles += Join-Path (Join-Path $p '.ssh') 'authorized_keys'
    $paths = @(
        (Join-Path (Join-Path $p '.config') 'smt.cmd'),
        (Join-Path (Join-Path $p '.config') 'smtk'),
        (Join-Path $p 'AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd')
    )
    foreach ($f in $paths) { if (Test-Path -LiteralPath $f) { $found += "persistence file $f" } }
    $tmp = Join-Path $p 'AppData\Local\Temp'
    Get-ChildItem -Path $tmp -Filter '.stk_*' -Force -ErrorAction SilentlyContinue |
        ForEach-Object { $found += "tunnel key file $($_.FullName)" }
    $ext = Join-Path (Join-Path $p '.cursor') 'extensions'
    Get-ChildItem -Path $ext -Directory -Force -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -match '^anthropic\.claude-code-2\.1\.31[23]' } |
        ForEach-Object { $found += "bad extension folder $($_.FullName)" }
}
foreach ($k in $keyFiles) {
    if ((Test-Path -LiteralPath $k) -and (Select-String -LiteralPath $k -SimpleMatch -Pattern 'svc-telemetry', $KeyBody -Quiet)) {
        $found += "attacker key in $k"
    }
}
if (Get-Command Get-ScheduledTask -ErrorAction SilentlyContinue) {
    if (Get-ScheduledTask -TaskName 'SysMon' -ErrorAction SilentlyContinue) { $found += 'scheduled task SysMon' }
}
if (Get-Command Get-CimInstance -ErrorAction SilentlyContinue) {
    Get-CimInstance Win32_Process -ErrorAction SilentlyContinue |
        Where-Object { $_.CommandLine -like '*134.209.82.225*' } |
        ForEach-Object { $found += "tunnel process $($_.ProcessId)" }
}
$found | ForEach-Object { "FOUND  $_" }
"findings: $($found.Count)"
if ($found.Count -gt 0) { exit 1 } else { exit 0 }

I tested both against a folder of planted fake files and a clean one. This is what the Mac and Linux version looks like:

Running it across a fleet

If you manage more than a handful of machines, push the same scripts instead of asking people to run commands.

• Intune: Remediations treats a detection script that exits with 1 as “issue found”. Run cc-sweep.ps1 as detection only, as SYSTEM, and read the output column. Don’t attach an automatic fix. You want a person to look before anything is cleaned.
• Jamf or any Mac tool that runs scripts as root: run cc-sweep.sh once against everything and pull the logs.
• No management tool: ssh loops for Linux boxes are fine. It’s read-only.

Then look at your network logs for 134.209.82.225 on ports 22 and 8099 from Oct 29 onward. Cursor had the server taken down, so a quiet log today doesn’t prove nothing connected on Thursday.

If something turns up

1. Take the machine off the network. Copy the files the script named somewhere safe before deleting anything.
2. On macOS and Windows, use Cursor’s own cleanup scripts, linked from its notice. The Mac one runs as the affected user. The Windows one needs an admin PowerShell. Both report failure if something is still there.
3. On Linux there’s no official script. Save your crontab first, then remove the .config/.smt cron line, the key line, and the .smt, .smtk and .stk_ files. Reboot once and run the sweep again.
4. Check SSH logs for logins you don’t recognise. If the machine already had SSH on and you find one, rebuild it.
5. From a different, clean machine, rotate what that user could reach: GitHub and CI tokens, cloud keys, package registry tokens, SSH keys, live sessions. The attacker has the names of their secret variables, which is a handy list of where to look. Start there.
6. Then update the extension to 2.1.314 or later. Do this after the cleanup, never before it.

What I’m changing

I like auto-update for most things. For extensions that can read my whole repo and run code the moment the editor opens, I’m turning it off for a while. In VS Code and its forks that’s "extensions.autoUpdate": false in settings. A bad release then waits for me instead of landing overnight. I lose silent fixes for a few weeks. That’s a trade I’m fine with.

If you hold keys on your dev machines anyway, keydrift is the small free tool I wrote that lists which keys sit in agent logs, shell history and config files (without printing them) and builds a rotation order. It won’t detect this backdoor. It helps with step 5.

My honest take

This wasn’t the AI doing something wrong. It was the trust we give AI tools. We hand them our code, our shell and our tokens, and then let them update themselves from a store we don’t control. The good news is the attacker’s own bugs stopped the worst of it on most machines. I wouldn’t count on that next time.

Weekly Breach Notes is my free newsletter. Subscribe if you want one short email a week on what leaked and what to do about it.

Sources

• Cursor, “Security notice: malicious version of Anthropic.claude-code (2.1.312 and 2.1.313) identified in the Cursor VS Code Extension Marketplace,” Oct 29, 2026, updated Oct 30: https://cursor.com/blog/claude-code-extension-security-notice
• Microsoft Security blog, “Inside a malicious Claude Code-branded extension and its persistent SSH backdoor,” Oct 30, 2026: https://www.microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/
• Ars Technica, “Anthropic VS code extension on Cursor backdoored for nearly 12 hours,” Oct 30, 2026: https://arstechnica.com/security/2026/10/anthropic-vs-code-extension-on-cursor-backdoored-for-nearly-12-hours/
• HOL Guard, “Claude Code 2.1.313 SSH backdoor in Cursor: how to check and fix” (summarises Phorion, OpenSourceMalware and StepSecurity findings), Oct 30, 2026: https://hol.org/blog/claude-code-2-1-313-cursor-marketplace-ssh-backdoor
• Unbound, “Claude Code 2.1.313 Backdoor in Cursor: Checks and Cleanup”: https://getunbound.ai/blog/claude-code-extension-backdoor-cursor-marketplace

Both images are original by sudodrift. The terminal image is from a test folder with planted fake files, not a real machine.