SecBlog Weekly — Issue 007

Week of Oct 13, 2026 · secblog.reedcloudsec.com

The signal, not the noise, in security. 9 things from this week worth your five minutes.

Microsoft October 2026 Patch Tuesday fixes 1,411 flaws, 3 zero-days (Exploited: CVE-2026-96951 · Disclosed: CVE-2026-108398, CVE-2026-92707)
Microsoft's October update is the largest on record, and the outlets can't agree on the numbers: BleepingComputer counts 1,411 flaws, Dark Reading 1,413, and Krebs says "more than 1,400," with critical flaws reported as 70, 80, and at least 78 respectively. Counting differs by what each outlet bundles. BleepingComputer leaves out 348 flaws fixed earlier in the month, and its own breakdown by type sums to 1,389, which it calls approximate. For scale, September's record was 966 flaws by BleepingComputer's count and 974 by SecurityWeek's, and Microsoft credits AI-assisted vulnerability discovery for the growth. By BleepingComputer's breakdown, elevation of privilege is the biggest category at 677 flaws, ahead of 317 remote code execution flaws.
One flaw is exploited: CVE-2026-96951, a Windows Shell security feature bypass (CVSS 8.8) that defeats Mark of the Web, the label Windows attaches to files from the internet. Automox explains why that matters. SmartScreen, Office Protected View, the Office macro block, Smart App Control, and the Attachment Manager prompt all key off that one label, so "one bug turns off several controls at once." CISA added it to its Known Exploited Vulnerabilities catalog on October 13 with an October 16 deadline for federal agencies, three days. Dark Reading credits Anthropic's Claude AI with uncovering it, while BleepingComputer's account names no discoverer. Two flaws are publicly disclosed. CVE-2026-108398 is a .NET Framework bypass of Windows Defender Application Control; BleepingComputer credits James Forshaw of Google Project Zero, and it needs local access and a low-privilege account, with Microsoft rating exploitation less likely. CVE-2026-92707, a moderate MessagePack-CSharp denial of service, appears only in BleepingComputer's count. Krebs and Dark Reading list two zero-days, not three.
Dark Reading's patch-first list, beyond the exploited flaw: the Outlook Reading Pane RCE CVE-2026-70242 (CVSS 9.8, no click required), the Microsoft QUIC RCE CVE-2026-105016 (9.8, unauthenticated over the network), and the SQL Server deserialization RCE CVE-2026-65674 on any instance reachable from the internet. Tyler Reguly of Fortra supplies the perspective on volume: only 26 Microsoft CVEs have reached CISA's KEV catalog this year, against 30 last year and 32 the year before, under 1% of what Microsoft patches. Start with exploited and exposed, not with the count: the KEV-listed flaw now, then internet-facing and preview-pane exposure, then the rest on a schedule your team has the capacity to test.
Issue 002's Patch Tuesday item made two points that hold at this scale. Elevation-of-privilege flaws, nearly half this month's total, are the second stage after any foothold, so "it's only local" is not a reason to skip them. And a rollout this size argues for staged deployment, not an unattended mass push. The Mark of the Web bug is also the defense-in-depth case from Issue 004's WordPress item in its cleanest form: when five controls trust one label, bypassing the label defeats all five, so no single control should be the only thing between a downloaded file and execution. Windows 11 24H2 Home and Pro also got their final security update this month, a deadline to treat like the end-of-life appliances in Issue 005: migration planned now, not after the next bulletin.
via BleepingComputer, Krebs on Security, and Dark Reading · Oct 13, 2026

Attacker Chains Three Ivanti Connect Secure Zero-Days for Root Access, Only Two Patched So Far (CVE-2026-104935: authentication bypass and RCE · privilege-escalation flaw: no CVE assigned yet)
Volexity found an attacker, tracked as UTA0576, chaining three zero-days in Ivanti Connect Secure to get unauthenticated, root-level code execution on an appliance that was fully patched and running 22.8R2.4. Exploitation began October 3. CVE-2026-104935, which The Hacker News reports Ivanti rates 8.6, covers an authentication bypass and a remote code execution flaw that together let an unauthenticated attacker run code as the cgi-server user; a third, privilege-escalation flaw raises that to root. Ivanti has fixed the first two, in ICS 22.8R2.5, 25.1.1.2, 25.1.3.0, and 25.1.3.1, but not the third, which Volexity says will come "in a future release in the coming weeks." That is why "fully patched" meant only that every available fix was applied. The version details don't reconcile: the CVE record lists 22.8R2.5 and later as unaffected while describing the victim's 22.8R2.4 as patched, so check Ivanti's advisory for your build. CISA added CVE-2026-104935 to its KEV catalog on October 13 with an October 16 deadline. Ivanti reports "limited exploitation," and Volexity saw one customer.
In that one intrusion the attacker stole domain and LDAP credentials stored on the appliance, searched Active Directory for LAPS passwords and BitLocker recovery keys, ran password spraying and a custom Kerberos tool, and left no web shell or backdoor, rerunning the whole chain for each command. Volexity assesses with medium confidence that the attacker used large language models for exploit development and post-exploitation, and with low confidence that the motive is criminal rather than espionage. Ivanti's Integrity Checker Tool does not catch this chain, because the exploit alters library code only in memory and restores the changed configuration, so confirming a compromise takes network and memory forensics. Volexity's indicators include heavy requests to /dana-na/auth/url_default/welcome.cgi, an X-DSCGI-PATH header that doesn't match the URL path, the directory /data/.icscap/, and the address 108.165.147[.]64.
CISA's recovery guidance is the rule from the Cisco gateway in Issue 003 and NetScaler in Issue 005 again, in more detail. Back up the configuration, factory reset and upgrade (rebuild virtual and cloud appliances), and restore. Then reset every account password, revoke and reissue stored certificates, and reset API keys and license-server credentials. Patching alone isn't enough because the attacker held whatever the appliance stores. The integrity-checker gap is Issue 002's F5 rootkit point: once a host can be made to lie, a check run on that host can't be the verdict, so ship telemetry off it and watch the network. And the layers from Issue 004's Check Point item apply to any VPN listener: source-IP allowlists, geo-IP restrictions, and a second factor outside working hours limit what a stolen domain credential can do, and domain credentials are exactly what this attacker went after. Ivanti 22.8 reaches end of life on January 31, 2027, so the migration plan is due now.
via The Hacker News, SecurityWeek, and CISA · Oct 13, 2026

Critical SonicWall SMA 1000 Flaw Targeted in 135 Exploitation Attempts After Patch (CVE-2026-102255, CVSS 10.0)
SonicWall patched CVE-2026-102255 on October 6. The flaw is a pre-authentication server-side request forgery in the WorkPlace portal of SMA 1000 appliances (models 6210, 7210, and 8200v). A remote attacker can make the appliance send requests on their behalf and reach internal functionality, through what SonicWall calls an "unintended access path." Fixed builds are 12.4.3-03670 and 12.5.0-03082 or later; 12.4.3-03526 and 12.5.0-02952 and older are affected, including the builds named on September 1 as the fix for two earlier exploited flaws. SonicWall credits Benoît Sevens of Anthropic with the discovery. SonicWall's advisory said it had no evidence of exploitation and, as of The Hacker News's report, hadn't been updated. Yet Previdian and Defused saw attempts from October 8. Previdian counts 135 attempts from two U.S. IP addresses, including a crafted OPTIONS request aimed at the internal CouchDB service on 127.0.0.1:5984 with admin:admin credentials. Whether any attempt succeeded isn't known. The SMA 100 Series and firewall SSL-VPN aren't affected, and no workaround exists. Shadowserver tracks more than 400 exposed SMA 1000 appliances, and the flaw is not in CISA's KEV catalog as of this writing.
This is the third maximum-severity, no-login SSRF in WorkPlace this year. The July 14 pair (CVE-2026-15409 and CVE-2026-15410) and the September 1 pair (CVE-2026-83548 and CVE-2026-83549) were both exploited, and Rapid7 described attackers on the earlier flaws harvesting credentials, session databases, and TOTP MFA seeds before moving laterally. CISA has added 19 SonicWall flaws to KEV over four years, 13 of them used by ransomware groups. Exploitation began two days after the patch, the same shrinking window as Issue 006's Atlassian item.
Three rounds of the same flaw class in one product in a year is a design signal, and the response has two parts. First, the exposure point from Issue 004's Check Point item: the portal is reachable from the whole internet, so restrict it to known source networks wherever the business allows. Second, the admin:admin attempt shows what SSRF does to everything that trusted localhost: a service that was safe because only the appliance could reach it is now reachable by the attacker, and a default or weak credential on it is the next step. That is the audit-every-access-control discipline applied to internal services. If an affected build was exposed during the window, assume nothing about success, since the earlier flaws were used to take credentials, sessions, and MFA seeds; rotate those, and rebuild rather than patch if there's any sign of compromise, as in Issue 005's NetScaler item.
via The Hacker News, BleepingComputer, and SecurityWeek · Oct 12, 2026

Ransomware attack disrupts Japan's IDCF Cloud used by govt clients
IDC Frontier, a SoftBank Group subsidiary, says a ransomware attack at 3:40 a.m. local time on October 7 forced it to shut down the network and systems in the East Japan Region 1 data center cluster of IDCF Cloud, its infrastructure-as-a-service platform. The company says 495 companies and local governments use the service and are affected, though BleepingComputer names no specific government client. Customer access to management consoles is disabled in every region until security is verified, there is no restoration timeline, no ransomware group is named, and no data theft is confirmed. Customer screenshots show a message in which the attackers claim the intrusion took seven minutes and that they encrypted 225 databases (3.6 PB), reached 239 hypervisors, sealed 16,000 virtual machine disks, and wiped 554,153 snapshots. IDC Frontier has confirmed none of those figures. Nissui Logistics separately reports an outage at a third-party data center it uses, and it's unclear whether the two are linked. Macnica has logged 119 incidents involving personal data theft or exposure in Japan this year, 83 of them since July 1.
Whatever the final scope, the claim worth taking seriously is the one about snapshots. Backups that live in the same control plane as production share its fate, and the attackers say they wiped them. The JadePuffer attack stripped backup protections on its way through Azure for the same reason, and resource locks there stopped some deletions but not all (Issue 005's JadePuffer item). Keep at least one copy of anything you can't lose outside the provider's control plane, immutable and encrypted, with the keys under your control, the archive discipline from Issue 004's FBI item. Test the restore, because a provider's outage is your outage and its recovery timeline isn't yours. Shared platforms also share a blast radius: one data center cluster took 495 organizations down at once.
via BleepingComputer · Oct 8, 2026

SAP Discloses Critical CVSS 10 Flaw in Cloud SDK for Python Allowing OAuth2 Credential Theft (CVE-2026-89111, CVSS 10.0)
SAP's advisory (GHSA-4mv3-jxxm-9cx2, October 13) describes a server-side request forgery in the SAP Cloud SDK for Python (sap-cloud-sdk on PyPI), used with SAP Business Technology Platform. In multi-tenant applications that pass a tenant subdomain to the SDK, the SDK substitutes that value into the token URL without checking it. It then sends the application's OAuth2 client ID and client secret to the resulting address, so an attacker who controls the subdomain value can route those credentials to a server they run. SAP says all versions below 0.45.2 are affected. The check arrived in 0.45.2 on August 21 and in the shared token code in 0.55.1 on September 18, and the newest release on PyPI on October 13 was 0.58.4. The Hacker News's own tests found six releases between 0.53.0 and 0.55.0 that lack the check for Destination calls, which the advisory doesn't list, so confirm your version against SAP's advisory rather than assuming 0.45.2 is enough. SAP reports no attacks and credits the discovery to a GitHub user, SunandM. For applications that can't upgrade, SAP's workaround is to validate each tenant subdomain against a list of registered tenants before it reaches the SDK.
The timeline is the part to remember. The unchecked code shipped in the SDK's first PyPI release on March 16. The August 21 release notes listed the fix under "Bug Fixes" with no mention of security, and the advisory followed 53 days later, so a scanner that waits for an advisory had nothing to flag until October 13.
It's Issue 005's MCP SDK flaw in a different SDK: a client sends its secrets to an endpoint it never validated, and here the endpoint is an input the caller controls. Validate anything that decides where credentials go against an allowlist, as SAP's workaround does. The 53-day gap is the library-integrity point from the Terraform and npm items. Scanning keyed to CVEs is only as current as the advisories, so read the release notes for the SDKs that handle your credentials, and treat an upgrade that touches token handling as security-relevant even when it's labeled a bug fix. A client secret is also a standing credential: it works from anywhere until someone rotates it, the problem the GitHub Actions OIDC cheat sheet addresses for CI/CD by replacing stored cloud keys with short-lived federated tokens. Where a platform you depend on offers a comparable short-lived or federated option, prefer it; the advisory doesn't address whether SAP's does. The advisory also doesn't say whether to rotate the affected client secrets. If an application ran an affected release and let tenant-controlled input reach the SDK, rotating them is the cautious call, though that is our recommendation, not SAP's.
via The Hacker News and BleepingComputer · Oct 13, 2026

GitHub Tightens npm Publishing After Flaw Left 1,500+ Packages Vulnerable to Hijacking
Bloom Security found the flaw in research it calls SlugFest. npm's trusted publishing, the OIDC route that lets a GitHub Actions workflow publish without a stored token, identified a package's source repository by its name (owner/repository) rather than by GitHub's permanent numeric repository ID, and ignored the ID until a package's first successful publish. An attacker could claim a name freed by a rename, transfer, or deletion, create a repository there, trigger an npm publish workflow, and exchange the resulting token for a publish credential on the victim's package, with no stolen credentials and no race. The single precondition is that the victim's trusted-publisher binding points at a claimable name and has never completed a publish. Bloom, which reported it to GitHub on June 6, counts more than 1,500 vulnerable packages with more than 10 million downloads between them; The Hacker News elsewhere says "thousands" and doesn't reconcile the two. No package is reported to have been hijacked.
GitHub's response came in a changelog dated October 2. An unvalidated trusted-publishing configuration now expires after 48 hours, becoming validated, and exempt from expiry, once it completes its first successful publish. Changing the repository or project identity starts a new 48-hour window. And npm rejects trusted-publishing tokens from issue_comment events, on top of the existing block on pull_request_target. Maintainers should confirm each binding's name still resolves to a repository they control, delete and recreate bindings after a rename or transfer, delete the binding when a repository is deleted, and watch for unexpected publishes.
This is the flaw at the center of this issue's Cloud Security cheat sheet: trust that names a repository by its name trusts whoever owns the name next. GitHub's own OIDC reference now says the old name-based subject claim was vulnerable for the same reason. The GitHub Actions OIDC Hardening Cheat Sheet covers the cloud side. Its Worth flagging section explains the name-recycling risk, its migration checklist moves AWS, Azure, and Google Cloud trust to immutable IDs, and its What changed recently list includes this same October 2 npm change from the OIDC side. For registry maintainers, Issue 005's audit-every-access-control rule applies to publishing bindings, and the "check who the publisher is" step from the Terraform item now includes checking that the publisher is still who you bound.
via The Hacker News and GitHub · Oct 13, 2026

Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains
Google disclosed on October 6 that attackers obtained unauthorized HTTPS certificates for Google domains by hijacking domains in the country-code top-level domains for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as). Google says its own systems weren't compromised. Reporting differs on how: BleepingComputer, following Google, says the attackers compromised third-party operators and changed authoritative DNS records, while The Hacker News says three registries were compromised, and neither explains how the intrusions happened. Controlling DNS let the attackers pass a certificate authority's domain-ownership check. The Hacker News, searching Certificate Transparency logs, found at least 12 certificates for seven names, including google.com.gh, youtube.com.gh, google.sl, and youtube.as: 11 from Let's Encrypt and one from ZeroSSL, logged September 22 (.gh), September 25 (.sl), and September 27 (.as). The two .gh certificates and the ZeroSSL one were revoked September 26 and the other nine on October 1, and all 12 showed as revoked on October 7. Google says the transparency data also showed other affected organizations, "including several leading global brands," and that it may not have found every domain. Chrome blocked the certificates through CRLSets, which protect only Chrome, so other browsers may not have been covered during the window. No one has been named, and whether any certificate was used to impersonate a site or intercept traffic is unknown.
DNS is the root of trust for certificate issuance: whoever controls a domain's authoritative records can obtain a certificate every browser accepts, which makes registry and DNS-provider access as sensitive as the certificates themselves. Google's advice is the practical part. Monitor Certificate Transparency logs for every domain you own, parked and country-code names included, and publish strict CAA records, ideally tied to your CA account. As Google notes, CAA can't stop issuance during an active hijack; its value is preventing a CA from reusing cached validation after you regain control. On October 7 all seven domains carried a strict CAA record naming only pki.goog, though the report doesn't say whether it was in place during the hijacks. The transparency alert is the tripwire, and it works only if a person reads it on a short cadence, the case Issue 006's Denmark item made for logs generally. The compromise also came through third-party operators, the vigilance point from the Astrana item in Issue 004: a domain is only as secure as the weakest operator in its registration path.
via BleepingComputer and The Hacker News · Oct 7, 2026

Unpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely (CVE-2026-105192, CVSS 9.8)
LMCache, open-source software that speeds up LLM servers such as vLLM, has a critical remote-code-execution flaw in its multiprocess mode, where the cache runs as a standalone server that LLM workers reach over ZeroMQ. The socket has no authentication, and messages are unpacked with Python's pickle before the server checks their type, so one crafted message runs the sender's code with the privileges of the LMCache process, which is root in the project's official container images. JFrog's Yuval Moravchick disclosed it on October 7, and it affects versions 0.3.9 through 0.5.5. The server listens on localhost by default and is reachable from other machines only when an operator sets a routable address, which LMCache's example Kubernetes DaemonSet does, listening on every interface. A copy of LMCache running inside a single vLLM process doesn't open the port.
The status has moved since The Hacker News reported on October 7 that no fix existed. LMCache published a GitHub security advisory on October 13 (GHSA-w5f2-9q9c-ff4h, CVSS 9.8) that lists 0.5.6 as the patched version, but 0.5.6 isn't out as a stable release: the latest on PyPI is 0.5.5, with 0.5.6 release candidates through rc5 on October 12. The first fix, removing pickle from the device IPC descriptors, merged to the development branch on October 12. An open pull request replaces a separate pickle path for tensor data in the engine-driven mode, so treat the flaw as partly fixed in development and unfixed in any stable release. No exploitation is reported. A GitHub user filed six more reports on October 6 alleging cross-tenant data access and unauthenticated command execution; they are unverified, with no CVE or maintainer confirmation.
The pattern is one researchers reported in other AI inference frameworks in November 2025, pickle over an unauthenticated socket (they called it ShadowMQ), and the root cause is the class from Issue 003's Cisco gateway: untrusted input reaching a code-execution sink, here as deserialized bytes. Until a stable fix ships, don't give the multiprocess server a routable address; keep the port on the local machine or a trusted cluster network, as JFrog advises, and treat a firewall as a reduction, not a fix, since any host that can connect can run code. We'd also change the example DaemonSet's all-interfaces binding before it reaches production, because example manifests tend to become production configurations, and stop running the cache as root. These are our suggestions beyond JFrog's. Inference infrastructure sits next to model weights, prompts, and cached data, which makes it a place to apply the audit-every-access-control rule from Issue 005 early.
via The Hacker News, LMCache's GitHub advisory, and PyPI · Oct 7–13, 2026

Ledger confirms spy chip implant behind wallet crypto thefts
Ledger says hardware wallets sold through CryptoBilis, a Southeast Asian reseller (Malaysia-based, per BleepingComputer), contained an unauthorized hardware implant that steals the wallet's recovery phrase. Funds were drained on October 9. Ledger asked CryptoBilis to stop selling its devices, confirmed tampering on at least one device on October 10, and said on October 13 that every confirmed loss involves a device sold through that reseller. By Ledger's account, the implant sits inside the enclosure and reads the screen: during setup, when the device displays the 24-word recovery phrase, the implant decodes the words and sends them over LTE through an eSIM, without altering the operating system, transactions, or signatures. Independent researchers Mark Karpelès and Tibane Labs describe an ST STM32G431 microcontroller, a 2×2 mm eSIM, and a shielded LTE module on a flex board. Tibane found two variants, one swapping in a smaller battery and the other fitted into the foam under the display, and both researchers say the antenna wire is the visible giveaway. Their units came from sellers shipping from Malaysia on Amazon Japan and Yahoo! Auctions Japan, which BleepingComputer doesn't tie to CryptoBilis.
The dollar figure is an estimate, not Ledger's. On-chain investigator Specter says losses "may top" $86 million, SecurityWeek's lead says "at least" $86 million, and Ledger hasn't confirmed a total or a count of devices or victims, calling the affected volume "limited" while it reviews reports of implants in other signers and locations. SecurityWeek says it "appears" someone along the distribution chain soldered the implant in by hand, based on a social media post; no one has been named, and Ledger says it is working with authorities. Ledger's advice: don't begin setup on an unused device bought from the reseller, and if you already did, move your assets to a new signer with a new recovery phrase.
This is the library-integrity framework from Issue 004's Terraform item and PhantomSub applied to hardware. Check who the publisher is, here who the seller is, and put a triage step in front of anything new, so security hardware comes from an authorized channel and nobody restocks returns, as Ledger asks of resellers. The verification problem is Issue 002's F5 rootkit point in physical form. Ledger's Genuine Check can't detect an added implant while the original Secure Element is intact, because the device is vouching for itself and the implant sits beside the chip doing the vouching. A check has to come from outside the thing being checked, which for hardware means physical inspection and a trusted supply chain, not a self-test. Issue 006's SConnect item makes the companion point: a hardware token is only as trustworthy as everything that touches it, from the middleware to the reseller. And the exposure comes at setup, when the phrase is displayed once, in the clear, so a compromised device is compromised before first use.
via BleepingComputer, SecurityWeek, and The Record · Oct 13, 2026

That's Issue 007. Free weekly, no spam, unsubscribe anytime — secblog.reedcloudsec.com