In this issue

1. 01OpenSSH “sshole”: an oversized password opens the doorAlpine/musl sshd without PAM · KEV due 12 Nov4
2. 02SonicWall SSL-VPN flaw sidesteps SAML MFASonicOS Gen7/Gen8 · no workaround6
3. 03Plex2Shell hits Plex Media Server on QNAP NASFour unauthenticated RCE flaws · port 324008
4. 04Three more on a three-day KEV clockFreeSWITCH · GPUStack · IBM Aspera Faspex9
5. 05Qubole’s own AWS account turned on its customersCross-account IAM role abuse · published IOCs10
6. 06France blames Iran’s IRGC for heating supermarket fridgesRefrigeration controllers become a nation-state OT issue12
7. 07Frontline Education breach doubles to 3.08 millionPlus Amplifon and Revolve count updates14
8. 08Signed, provenanced and malicious: bee-js and Swarm DesktopHijacked maintainer and release-bot accounts15
9. ◆Defender’s Action DeskPrioritised checklist · KEV deadlines this week · watch today17
10. ◆Awareness lesson: “The breach letter is the bait”For employees and leaders · briefly noted18
11. ◆Source registerEvery source, with whether we could open it20

How to read this issue

Links marked like this point to the source for the claim beside them. Diagrams are original MAG212 CYBER work built from those sources; none is a screenshot, photo or live data. Commands come from vendor documentation and were not tested by MAG212 CYBER.

What happened

Confirmed OpenSSH 10.6p2, released on 5 November, includes a “critical security workaround” for Linux systems that use musl libc with PAM disabled. The release notes say the root cause is outside sshd but can be avoided there, and do not cite a CVE. OpenSSH Alpine published its advisory the same day. Alpine On 9 November CISA added CVE-2026-123158 to the Known Exploited Vulnerabilities (KEV) catalog with a 12 November due date and a forensic-triage flag. CISA KEV

Reported Previdian saw a first exploitation attempt less than nine hours after the CVE was published and confirmed root access on an Alpine honeypot. Help Net Security SecurityWeek reported on 9 November that botnets and cryptominers are exploiting it. SecurityWeek OpenSSH’s Damien Miller told affected users to set PasswordAuthentication=no or disable SSH “IMMEDIATELY”. Help Net Security

Who is affected

Confirmed Per Alpine, a system is exploitable only when all of the conditions in the diagram hold. You are not affected with openssh-server-pam and UsePAM yes, with PasswordAuthentication no, on locked (!) accounts, with no $-style hashes on the host, or in containers that don’t run sshd. Root is protected by the default PermitRootLogin prohibit-password, unless another account can escalate, for example through doas. Affected Alpine tiny-cloud images run from 3.18.11 to 3.24.3; fixed point releases are 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Alpine

Reported The researcher names OpenWrt, Buildroot, Yocto and “a lot of the docker images” as other musl-based systems. Alpine AWS and Azure tiny-cloud images 3.18.11–3.24.3 ship a default alpine user with passwordless doas. Debian, Ubuntu, Fedora, Dropbear and OpenBSD are reported unaffected. Help Net Security

MAG212 analysis The main exposure is Alpine-based containers and VMs running sshd, plus embedded builds. Check each network vendor for OpenWrt-based routers and access points rather than assuming either way; many use Dropbear. We found no network-vendor advisory.

How the attack works

Confirmed Without PAM, sshd hashes each password attempt with crypt(). If an account’s stored field is too short to hold a salt, sshd borrows another account’s salt. musl’s crypt() fails on keys longer than 256 bytes and returns *, which matches a stored * password field, so the login succeeds. Alpine Reported On Previdian’s honeypot the attacker ran id, uname and hostname after logging in. Help Net Security Unknown CVSS score, worldwide exposure, and payloads beyond botnet and cryptominer activity.

What to look for

• Vendor guidance In /var/log/messages, Accepted password for on accounts that have no password, such as alpine, root and key-only users. Also review doas use, newly created users and authorized_keys changes. Alpine
• Single honeypot indicator All eight attempts Previdian saw came from 89.116.89[.]18. Treat it as one data point, not a blocklist. Help Net Security
• MAG212 analysis False positives: legitimate password logins on accounts that do have a password. The signal is a successful password login on an account whose password field is *.

Investigate, contain and remediate (in order)

1. Stop the bleeding. If you can’t patch now, disable password authentication (panel 2) or disable SSH on the system. Alpine
2. Patch to your branch’s fixed package (table) or upstream OpenSSH 10.6p2.
3. Restart sshd. Alpine notes the upgrade does not restart a running sshd.
4. Hunt with the log and account checks above on every host that met the conditions.
5. Decide on compromise. “If a login cannot be ruled out, treat the machine as compromised.” Alpine MAG212 analysis For containers and cloud images, rebuild from a patched image and rotate credentials the host held.

# Upgrade all packages, including openssh
apk upgrade -U -a
# Restart sshd; the upgrade does not do it for you
rc-service sshd restart

# Create /etc/ssh/sshd_config.d/00-no-passwords.conf containing the line:
PasswordAuthentication no
# Validate the config; restart only if validation passes
sshd -t && rc-service sshd restart

# Show the effective setting sshd is using
sshd -T | grep -i passwordauthentication

Verify recovery

Confirm the installed openssh package matches the table for your branch, that sshd was restarted after the upgrade, and that sshd -T reports password authentication off wherever you applied the workaround. Re-run the log check to be sure no new Accepted password for entries appear on passwordless accounts.

Prevention and awareness

MAG212 analysis Make key-only SSH the baseline, and don’t run sshd in containers that don’t need it. Container base images inherit their OS’s authentication quirks. Reported Previdian warns that proof-of-concept code on GitHub is unverified and could contain malware; don’t run it to “test” production. Help Net Security

What happened

Confirmed CISA added CVE-2026-19868, a SonicOS SSL-VPN “use of single-factor authentication” flaw, to KEV on 6 November with a 20 November due date. CISA KEV Reported SonicWall advisory SNWLID-2026-0014 fixes seven SonicOS flaws. SonicWall says it “investigated a report of potential exploitation” of this one, without details, and scores it 7.1. BleepingComputer SecurityWeek CISA’s flagging was covered on 9 November. The Hacker News

Who is affected

Reported Gen7 TZ/NSa/NSsp/NSv on SonicOS 7.3.3-7015 or older, and Gen8 TZ/NSa/NSv on 8.2.2-8015 or older, but only where SSL-VPN is configured for SAML authentication. There is no workaround. SecurityWeek The same advisory fixes two management-interface flaws rated 8.8 (CVE-2026-107155, CVE-2026-107154), a pre-auth SSL-VPN heap overflow causing denial of service (CVE-2026-82308, 7.5), two TACACS+ issues (5.9 each) and weak password hashing on virtual appliances (5.2); their exploitation status is not stated. Oflight digest

MAG212 analysis MSPs and schools that put SSL-VPN behind Entra ID or Google SSO through SAML are directly exposed. Fleets without SAML still need the update because of the 8.8 management-interface flaws.

How the attack works

Reported A user who holds valid credentials for an alternate authentication method can bypass SAML controls, including SAML-enforced MFA, on SSL-VPN logins. SecurityWeek Unknown Who exploited it, how widely, where the alternate credentials came from, and any IOCs; none were published. No source links it to ransomware. MAG212 analysis SSL-VPN is a common initial-access route, which raises the stakes.

What to look for and how to investigate

If SAML SSL-VPN is enabled, review VPN logins that authenticated through an alternate method rather than SAML. SecurityWeek We could not open SonicWall’s PSIRT page, so we don’t reproduce its GUI path or detection guidance; read SNWLID-2026-0014 before acting. Interface labels vary by SonicOS version.

Contain and remediate (in order)

1. Inventory every SonicWall on Gen7 ≤ 7.3.3-7015 or Gen8 ≤ 8.2.2-8015 and flag those with SAML SSL-VPN.
2. Upgrade to 7.3.4-7013 or 8.2.3-8015; there is no workaround. SecurityWeek
3. Restrict the management interface, which has its own 8.8 flaws. SecurityWeek
4. MAG212 analysis Where alternate-method logins look suspicious, reset those credentials and review what the sessions reached.

Verify recovery

Confirm each device’s firmware is at or above the fixed build. Then confirm new SSL-VPN sessions on SAML portals show SAML/MFA completion, not alternate-method authentication. Commands: none were sourced from SonicWall documentation, so none are given.

Prevention and awareness

MAG212 analysis MFA enforced at an identity provider protects only the login paths that go through it. Any parallel authentication method on the same portal is a bypass waiting to happen: inventory them and turn off the ones you don’t need.

What happened and who is affected

Reported QNAP warned of widespread exploitation of Plex2Shell, a chain of four unauthenticated remote-code-execution flaws in Plex Media Server, since mid-October after proof-of-concept code was published. Some users report their Plex servers appear compromised. QNAP says QTS and QuTS hero are not affected and no data loss has been reported. SecurityWeek QNAP’s notice is titled for an update to 1.43.3.10861 or later; SecurityWeek says 1.43.3 or later. We follow the more specific build. QNAP notice

Unknown The actor, payloads, any ransomware link (none reported) and IOCs (none published). MAG212 analysis Schools and SMBs running Plex on a NAS with port 32400 forwarded to the internet are exposed, and a NAS often holds the backups you’d need to recover from a wider incident.

How the attack works

Only the outline is published: four flaws chained for unauthenticated code execution in Plex Media Server, reachable where the server is exposed. The individual steps and payloads were not described in the sources we read, so we don’t speculate.

What to look for, investigate, contain and remediate (in order)

1. Treat internet-exposed devices as potentially compromised. SecurityWeek
2. Disable Plex Remote Access and stop forwarding port 32400; use a VPN if remote access is needed.
3. Reinstall Plex and update to 1.43.3.10861 or later.
4. Rotate Plex and NAS passwords.
5. Work through QNAP’s check-and-remediation FAQ; MAG212 did not review its contents.

Verify recovery and prevention

Confirm the Plex version, that port 32400 no longer answers from outside your network, and that passwords changed. MAG212 analysis Apps installed on a NAS widen its attack surface: a secure NAS operating system doesn’t protect a vulnerable media server port-forwarded beside it. Commands: none were sourced, so none are given.

Confirmed On 9 November CISA added four CVEs: OpenSSH (article 1) and the three below. All four carry the unusually short 12 November due date and a forensic-triage flag, and each required action cites “CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk” and “Forensics Triage Requirements”. There were no additions on 7, 8 or 10 November as of catalog v2026.11.09. CISA KEV MAG212 analysis The three-day deadline appears to pair with the forensic-triage flag; we could not read the directive itself.

FreeSWITCH: SIP MESSAGE command injection (CVE-2026-116779)

Confirmed KEV says it “permits configuration and credential disclosure, arbitrary call control, and command execution”. CISA KEV Reported CVSS 9.8; affects 1.11.2 and earlier; fixed in 1.11.3. The vendor advisory (GHSA-mg63-h38w-8p9p, 28 Oct) states “Exploitation of this path has been observed in the wild.” An inbound SIP MESSAGE reaches the “api” chat handler and runs commands with server privileges. Chat is on by default for internal and external profiles, authenticating a MESSAGE needs only one account on the profile, and older sample configs include a directory user with no password. SecurityOnline

Look for unexpected SIP MESSAGE traffic and API activity in logs. Remediate, in order: upgrade to 1.11.3; keep enable-chat-api-proto off (default); set enable-chat=false where SIP chat isn’t needed; remove passwordless directory users; set ice_verify_message_integrity; leave mod_xml_rpc enable-websocket unset. SecurityOnline Unknown Who is exploiting it and which PBX products embed vulnerable FreeSWITCH. The vendor advisory was not opened by MAG212.

GPUStack: improper authentication (CVE-2026-102895)

Confirmed KEV: “unauthenticated administrative access… persistent administrator API-key creation, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml”. CISA KEV Reported CVSS 9.8. Builds before 2.2.0 trust loopback requests as admin because force_auth_localhost defaults to false; attackers reach this through a same-host reverse proxy or a spoofed X-GPUStack-Real-IP: 127.0.0.1 header. Exploitation was observed against v2.1.1, with custom backends used to launch reverse shells. Fixed in 2.2.0; upgrade to 2.2.2 or later to also fix SAML bypass CVE-2026-102894. Workarounds: force_auth_localhost=true, strip X-GPUStack-Real-IP at the proxy, block /auth/saml/callback. SecurityOnline MAG212 analysis Because cloud-provider and worker secrets are exposed, patching isn’t enough on any exposed instance: rotate those credentials too.

IBM Aspera Faspex: incorrect authorization (CVE-2026-123218)

Confirmed Affects Faspex 5.0.0 to 5.0.19; fixed in 5.0.19 PL1; after patching, the faspex-core image should report “5.0.19 (1ce4b13, Fix Pack: 1)”. IBM offers no workarounds and its bulletin does not mention exploitation. IBM KEV describes it as letting “an authenticated user… bypass authorization, causing privilege escalations”. CISA KEV

Commands: none of the three sources supply shell commands; the settings above are configuration directives from the sources.

What happened

Reported An attacker holding credentials for Qubole’s AWS account (805246085872) assumed IAM roles that customers had created to trust it, and the AssumeRole requests carried the correct External ID. Most of the roles were no longer used but still trusted Qubole. Sentra spotted the activity in several customers’ environments and alerted Wiz. Neither Qubole nor Idera had made a public statement when The Hacker News checked. The Hacker News (primary research: Wiz, not opened by MAG212)

Reported timeline AssumeRole break-ins ran 14–26 October; from 18 October the attacker used IAM user AIDAJYRRH5Y3A7AAJM2HW. Separately, on 8–11 October, an attacker not linked to the first used customers’ own AWS access keys, an access option Qubole supports. The Hacker News

Who is affected

Any AWS account containing an IAM role that trusts Qubole’s account, including roles nobody uses any more. Reported Qubole’s setup guide includes a sample S3 policy that lets the role read every bucket in the account. Qubole docs

How the attack works

Reported (1) AssumeRole into the customer role from Qubole’s account; (2) read Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values; (3) test the harvested credentials with TruffleHog, including victims’ AWS keys, Entra ID client secrets and Okta client credentials; (4) copy S3 data, sometimes a whole bucket in one session. The Hacker News Unknown How the attacker got Qubole’s credentials, the number of victims, and whether a vendor statement will follow.

What to look for (published indicators)

Investigate, contain and remediate (in order)

1. Review CloudTrail from 1 October in every account holding a Qubole role.
2. Revoke active sessions for any abused role; rotation alone doesn’t end them.
3. Rotate everything the role could reach, including Entra ID and Okta app credentials stored in AWS.
4. Remove vendor roles you don’t need.
5. Where Qubole supports it, replace the :root principal with Qubole’s specific principal.
6. Add an aws:SourceIp or aws:SourceVpce condition. The researchers: “a source IP condition alone would have blocked every role assumption we observed.”
7. Enable an organization trail and S3 data events or server access logs; management events don’t show object reads.

Source for all steps: The Hacker News. Wiz’s exact detection queries could not be verified, so none are reproduced.

Verify recovery

Confirm no Qubole-trusting role remains without a source condition, that rotated secrets are the ones in use, and that S3 data-event logging is active.

Prevention and awareness

Reported Don’t treat the External ID as a secret. AWS guidance MAG212 analysis For MSPs, today’s job is an inventory of vendor cross-account roles across every client AWS account, each with an owner and a reason to exist.

What happened

Reported Paris prosecutors said Iran’s Revolutionary Guard was behind the October attack on supermarket refrigeration, and France’s cyber agency ANSSI attributed it to the Shahid Kaveh group, which it describes as an IRGC-affiliated cyber unit. Prosecutor Laure Beccuau opened a judicial investigation into organised cybercrime “aggravated by serving a foreign power, in this case, Iran”, targeting the group’s leader and two deputies. Cited evidence includes Farsi use and IP addresses linked to devices in Iran. International arrest warrants are being sought but not yet issued. Foreign minister Jean-Noël Barrot summoned Iran’s ambassador and said France would seek sanctions “at the European level”. SecurityWeek/AP

Reported impact Attackers took control of refrigeration in about 700 of France’s 10,000 supermarkets; temperatures reached 50°C for about six hours; Intermarché reported losses of “tens of millions of euros” in a day. SecurityWeek/AP AP dates the attack to 12 October; earlier reporting says overnight 11–12 October, which we use. SecurityWeek

Who is affected

Reported CISA, FBI, HHS, USDA and DoT said they are “aware of malicious cyber actors targeting electronic temperature controllers and commercial refrigeration controllers in retail grocery and cold storage facilities”. SecurityWeek (advisory PDF not opened by MAG212). CERT-FR first flagged Danfoss AK-SM and AK-SC controllers, then Copeland/Dixell XWEB. Danfoss said most hacked units were legacy products it no longer updated, and told customers on 13 October to disconnect them from the internet. SecurityWeek

How the attack works and what to look for

Reported advisory TTPs Attackers exploit unpatched or internet-accessible controllers through authentication bypass, code injection and weak configurations; remotely change settings to force continuous heating and defrost cycles; and cause denial-of-view so operators can’t see the real state. SecurityWeek Look for unexplained setpoint or defrost changes and loss of visibility on controller dashboards. No IOCs were obtained because the advisory PDF was not retrieved.

Contain, remediate and verify (in order)

1. Take control systems off the internet, or put them behind a firewall or edge device.
2. Isolate OT networks.
3. Restrict access to trusted identities, with strong passwords and phishing-resistant MFA.
4. Patch, or replace legacy controllers the vendor no longer updates.
5. Keep offsite backups of configurations; turn on logging and monitoring. SecurityWeek

Verify recovery: confirm from outside your network that controller interfaces no longer answer, and check setpoints against known-good values.

Prevention and awareness

MAG212 analysis The official attribution turns a facilities problem into nation-state OT sabotage. MSPs serving retail, food, pharmacy or healthcare should treat any internet-reachable building controller as an incident waiting to happen. Related background: the CVSS 10 Node-RED flaw CVE-2026-58115 (Siemens SIMATIC IoT2050), which VulnCheck has seen exploited since 30 October through a single HTTP request against instances without adminAuth. SecurityWeek

What happened and who is affected

Reported Frontline Education told the Indiana Attorney General’s Office that 3,085,266 people were affected, more than twice the roughly 1.3 million in its earlier state filings. Attackers exploited a vulnerability in an unnamed third-party software product and stole data from Frontline Central and School Health Management. Those affected are school district employees and students. Depending on the person, data may include names, SSNs, dates of birth, driver’s licence, passport or other ID numbers, health insurance information such as Medicaid IDs, and student IDs. Frontline offers two years of credit monitoring for US adults and dark-web monitoring for eligible minors. No group has claimed the attack. SecurityWeek Unknown Which third-party product was exploited.

What school IT teams should do

Guidance inferred from the reporting, not stated by Frontline. There are no IOCs, commands or technical fixes here, because the compromise is on the vendor’s side.

1. Confirm your district’s notification status with Frontline.
2. Prepare communications for parents and staff, and promote the free monitoring.
3. Warn staff and families about phishing that uses the leaked data (see the awareness lesson).
4. Ask your SaaS vendors which third-party components they rely on and how fast they patch them.

Same-day updates: Amplifon and Revolve

Amplifon Americas (hearing healthcare). Reported Attackers copied files between 18 January and 8 February 2026; Amplifon noticed suspicious activity on 11 February. The Record Data includes government ID numbers, dates of birth, hearing and medical information and health insurance information; SSNs and financial information for some people. Amplifon says it knows of no misuse. SecurityWeek

Revolve (fashion e-commerce). Reported Revolve told the Indiana AG that 1,515,073 people were affected, up from about 197,000 in earlier filings. The intrusion happened on 11 September and Revolve learned of it on 29 September. Card numbers and expiry dates were exposed for customers with stored payment methods; the way in is undisclosed. SecurityWeek

MAG212 analysis None of these is confirmed ransomware or claimed, so we call them data breaches. In all three, the real scale surfaced weeks or months later in state filings: treat early counts as provisional.

What happened and who is affected

Confirmed Compromised maintainer accounts pushed malicious @ethersphere/bee-js 13.3.0 to npm and Swarm Desktop 0.56.2 as a GitHub release for Linux, macOS and Windows. npm removed 13.3.0 about 75 minutes after publication; 13.2.0 is the safe version. The 0.56.2 tag was deleted at 09:04 UTC on 9 November; 0.56.3 is recommended but had not been published as of 10:30 UTC. Socket The Hacker News Socket assesses the actor as the one behind the SleepyDuck/EtherDuck Open VSX campaign, based on on-chain history, shared payload hashes and identical persistence names. Unknown How the GitHub accounts were compromised, download counts for 13.3.0, and whether Ethersphere has published its own advisory.

How the attack works

Confirmed The attacker used nugaon, a maintainer with force-push rights to an unprotected master, and bee-worker, the release bot. In bee-js, unsigned commit de2f74e turned scripts/generate-version.cjs into a loader and renamed prepare to postinstall; a GitHub release then triggered the legitimate publish workflow, whose environment had no required reviewers and no tag policy, so npm provenance is valid. In Swarm Desktop, unsigned branch emergency/0.56.2 added the loader, and a manually dispatched pre-release.yml that accepts any branch and holds Apple and Windows signing certificates built, signed and notarized the trojanized app. Socket

What to look for (published indicators)

Investigate, contain and remediate (in order)

1. Search lockfiles, caches and internal registries for 13.3.0; pin 13.2.0 and purge mirrors.
2. Treat any machine or CI job that installed 13.3.0 with install scripts enabled between 00:09:50 and 01:24:58 UTC on 9 November as compromised, even if the install failed.
3. Rotate every credential those machines or jobs could reach, including CI OIDC-trusted cloud credentials.
4. Swarm Desktop users: assume the node password and key are stolen and move funds to a new key from a clean machine.
5. Manually remove ~/.solidity/, the LaunchAgent, the systemd unit and the ScreenConnect service; reinstalling does not remove them.
6. Hunt in DNS and proxy logs for the domain and IPs above. Socket

Verify recovery

Confirm lockfiles resolve to 13.2.0, the persistence artefacts are gone, and nothing still connects to the hub or relay addresses.

Prevention and awareness

Socket’s advice Verify a released commit sits on a protected branch or came from a merged release PR; require reviewers on publish environments and restrict which tags can deploy; don’t expose signing credentials to manually dispatched workflows; scope and rotate release-bot tokens. Socket MAG212 analysis Valid provenance and notarization prove which pipeline built the code, not that the code is benign. Direct impact is probably limited to Swarm and Ethereum users, but the CI/CD lesson applies to anyone who publishes software, and it fits GitHub’s announced change to block pull_request_target workflows by default from 2 December. Socket

Defender’s Action Desk

A prioritised checklist built from today’s stories. Tick what applies to your estate; skip what doesn’t. MAG212 analysis for the ordering; each action’s source is in its article.

• NowAlpine/musl sshd: PasswordAuthentication no, upgrade openssh, restart sshd, grep /var/log/messages for Accepted password for on passwordless accounts. → 01
• NowSonicWall: upgrade to 7.3.4-7013 / 8.2.3-8015, SAML SSL-VPN portals first; restrict the management interface. → 02
• NowNAS: close port 32400, turn off Plex Remote Access, reinstall Plex 1.43.3.10861+, rotate passwords. → 03
• Nowbee-js: search lockfiles for 13.3.0; treat installs in the 9 Nov window as compromised; rotate CI credentials. → 08
• TodayAWS: list roles trusting vendor accounts (start with 805246085872); delete unused; add aws:SourceIp/aws:SourceVpce; CloudTrail from 1 Oct. → 05
• TodayFreeSWITCH / GPUStack / Faspex: 1.11.3 · 2.2.2+ · 5.0.19 PL1; rotate GPUStack cloud and worker secrets. → 04
• TodayBuilding & OT controllers: check from outside that refrigeration and other controllers aren’t internet-reachable. → 06
• This weekSchools: confirm Frontline notification status; send the phishing warning in the awareness lesson. → 07
• This weekCI/CD: require reviewers on publish environments; keep signing secrets away from manually dispatched workflows. → 08
• This weekAI coding tools: scan .claude/, .cursor/, .gemini/, .specstory/ for committed secrets (Briefly noted).

KEV deadlines falling this week

Awareness lesson: “The breach letter is the bait”

Briefly noted

• Claude Code secrets in public repos (7 Nov, ~3 days old). Reported Apiiro found the “Yes, and don’t ask again” option saves approved commands verbatim, including literal secrets, to .claude/settings.local.json. Of 104,185 public copies, 1,122 contain at least one secret (1,379 distinct); Gitleaks and TruffleHog missed 215 of those files. No Anthropic statement was reported; an earlier bug report was closed by a bot. The Hacker News Apiiro Rotate exposed secrets first, then untrack the file:
  Untrack the fileOS: anyShell: any, inside the repoPrivileges: noneCHANGE (git index only)

  git rm --cached .claude/settings.local.json
  # then add .claude/settings.local.json to .gitignore and commit

  Removes the file from version control but keeps it on disk; history still contains old copies, so rotation comes first. Not tested by MAG212 CYBER; syntax from The Hacker News.
• Iris Plaza (9 Nov): a compromised external cloud service may have exposed data on 7.7 million customers; article not read in full. SecurityWeek
• NoName057(16) doxxing (9 Nov): personal data of 18 European officials and journalists, including Italy’s foreign minister Antonio Tajani, published with crypto bounties; the Russian Embassy denied involvement. The Record
• Ukraine arrests (9 Nov): four people held over a call-centre investment scam that took more than €4.3M from 135 German victims. The Record
• AI and attackers (9 Nov): an attacker used BOSSAI agents against Taipei emergency dispatch records The Hacker News; Google DeepMind agents lowered the cost of attacking RSA-1024 SecurityWeek.