Daily Cybersecurity News – November 9, 2026

What happened

Threat actors have begun exploiting a high-severity authentication bypass in OpenSSH known as SSHole, tracked as CVE-2026-123158.

The flaw stems from misinterpretation of whether a string is a password hash. On Linux systems using musl libc without PAM, sshd can treat any password of 257-1024 characters as valid for certain accounts (including root) that store '*' in the password field, because musl's crypt() returns '*' on long inputs and matches the stored value.

OpenSSH released patches last week. Researchers at WatchTowr, Previdian, GreyNoise and Defused observed initial exploitation attempts over the weekend, so far mainly by botnets and crypto miners, with Previdian noting dozens of attempts from multiple countries starting around November 6, 2026.

Who is affected

OpenSSH before 10.6p2 on Linux distributions that use musl libc with PAM disabled. This includes Alpine, Buildroot, OpenWrt, Yocto and similar embedded or minimal systems.

Affected accounts commonly include root, key-only users created without passwords, the default Alpine user in tiny-cloud images, and directory-service users via musl-nscd. Systems using glibc or PAM are not impacted by this specific path.

Why it matters

Successful exploitation grants access to privileged accounts that should reject password logins, enabling full system compromise on exposed SSH services.

While current activity is botnet and miner focused, the ease of the long-password check and the presence of internet-facing Alpine/OpenWrt devices mean broader ransomware or access-broker use is likely. Operators of container hosts, routers and IoT fleets face elevated risk until patched and restarted.

How it could have been prevented

Upgrade OpenSSH to 10.6p2 or later immediately and restart sshd.

On Alpine and similar musl systems, apply vendor updates promptly. Restrict SSH exposure with firewall rules, key-only authentication where possible, and monitoring for anomalous long-password login attempts. Review auth logs for successful logins to accounts that should not accept passwords.

What happened

SonicWall fixed an actively exploited authentication enforcement vulnerability in SonicOS SSL-VPN, CVE-2026-19868 (CVSS 7.5).

When SAML is enabled for SSL-VPN, a user possessing valid credentials for an alternate authentication method can bypass SAML controls and any MFA enforced through the identity provider. The login succeeds with a password alone instead of routing through Okta, Entra ID or similar.

CISA added the CVE to its Known Exploited Vulnerabilities catalog. SonicWall confirmed investigation of reported exploitation but released no attack details or IoCs. The same releases also address six other flaws not flagged as exploited.

Who is affected

Gen7 and Gen8 physical and virtual SonicWall firewalls running SonicOS 7.3.3-7015 and older, or 8.2.2-8015 and older, that have SAML enabled for SSL-VPN.

Fixed in 7.3.4-7013 and higher, and 8.2.3-8015. Gen6 and older hardware are end-of-support and not listed as affected but should be upgraded. Organizations relying on SAML MFA for VPN are the primary exposure.

Why it matters

Stolen or reused VPN credentials become immediately usable despite MFA, defeating a core remote-access control. SonicWall SSL-VPN devices have repeatedly been targeted by ransomware groups, including prior MFA-bypass cases.

Federal civilian agencies face a November 20, 2026 remediation deadline under KEV. Without IoCs, detection relies on log correlation between VPN success and missing IdP MFA events.

How it could have been prevented

Patch to SonicOS 7.3.4-7013+ or 8.2.3-8015+ at once; no workarounds are available.

Review recent SSL-VPN logins for any that lack a corresponding IdP sign-in and MFA event. Reset credentials for those accounts, audit session activity, and rotate secrets. Prefer VPN access via modern IdP-enforced paths and consider network segmentation for residual risk. Upgrade end-of-support Gen6 hardware.

What happened

The LNbits project urged all operators of its open-source Bitcoin Lightning wallet system to shut down servers immediately amid a wave of attacks.

An initial narrower warning targeted the Paywall extension; roughly 80 minutes later the project expanded to a full shutdown notice while preparing multiple security fixes. One operator reported new accounts exploiting a flaw to withdraw 2,285,545 satoshis (about 0.023 BTC) before containment. The project confirmed the specific extension exploit used but had not publicly named it at the time of reporting. No fixed release was available as of early November 9, 2026; patches were estimated within 24-48 hours. The project's own hosted instances on my.lnbits.com were taken offline.

Who is affected

Anyone self-hosting LNbits servers, plus users of the project's cloud service. Lightning nodes and unrelated wallet software are outside the notice.

One documented victim ran BitTipBot; funds for its users remain locked until fixes land. Scale of other compromises and total losses was not quantified by the project.

Why it matters

LNbits is widely used for Lightning tips, paywalls and small custodial wallets. Active exploitation can drain balances quickly, and the lack of an immediate patch plus incomplete public technical detail leaves operators exposed.

Custodial setups concentrate risk; users cannot access funds while servers stay down, and delayed disclosure can allow further laundering of stolen sats.

How it could have been prevented

Shut down LNbits servers now per project guidance and keep them offline until official patched releases are confirmed and applied.

Disable optional extensions such as Paywall until cleared. Monitor for unauthorized account creation or withdrawals. After patching, rotate credentials, review logs, and consider non-custodial alternatives or hardware-backed setups for significant value. Follow only official project channels for recovery steps.

What happened

Google DeepMind, working with cryptographers from UC San Diego and Inria, reported that supervised AI agents found two lower-cost approaches against 1024-bit RSA.

One improves signature forgery against PKCS#1 v1.5 padding used by some PKCS#11 HSM interfaces: once an attacker controls roughly half or more of the signed block, padding adds no protection. In a sandboxed replay the agents cut CPU time about 3.5x (391 core-years versus 1,380). A second line of work improves multi-key factoring by amortizing a large upfront computation across many same-size keys. Modern 2048-bit and larger RSA remains unaffected per the researchers.

Who is affected

Operators still relying on obsolete 1024-bit RSA keys or signature schemes, including legacy HSMs, old certificates, or long-lived embedded devices that never migrated.

Systems using 2048-bit or stronger keys, elliptic-curve cryptography, or current TLS/code-signing defaults are not practically impacted by these cost reductions.

Why it matters

The work shows AI agents can accelerate cryptanalytic research under human guidance, lowering the practical bar for attacking already-deprecated 1024-bit RSA.

It reinforces the long-standing migration deadline away from 1024-bit keys rather than creating a new break of modern cryptography. Organizations with compliance or long-tail legacy crypto debt should treat remaining 1024-bit material as higher priority for retirement.

What happened

Attackers exploited a security flaw in Web3Auth infrastructure used by the Keplr wallet for Google and Apple sign-in, enabling theft from some social-login wallets.

Keplr described it as a private-key breach for affected Google/Apple accounts. Web3Auth then used the same route to proactively drain other at-risk wallets into recovery addresses across Cosmos-family and EVM chains, working with Keplr so funds could be safeguarded rather than stolen. Wallets created with recovery phrases or hardware devices are unaffected. Google and Apple sign-in were paused. No precise root-cause timeline or dollar total came from the vendors; third-party estimates cited roughly $1M stolen and over $6M moved into recovery wallets from tens of thousands of addresses.

Who is affected

Keplr users who created wallets via Google or Apple login through Web3Auth. Seed-phrase and hardware-wallet users are not impacted.

Rough early signals suggested around 20% of social-login accounts were in scope, with only a fraction exploited by the attacker before the rescue transfers. Staked or locked assets take longer to secure.

Why it matters

Social-login crypto wallets trade convenience for dependency on a third-party auth provider; a provider-side flaw can expose private keys and empty balances at scale.

Users seeing zero balances may have been rescued rather than robbed, creating confusion. The incident highlights supply-chain and custodial risk in Web3 onboarding flows and the need for clear recovery communication.

How it could have been prevented

Do not send new funds to affected social-login accounts. Do not re-import or recreate them. Move unstaked funds to a recovery-phrase or hardware wallet.

Trust only official Keplr and Web3Auth channels; ignore DMs offering recovery help. Use the published recovery-address lists to distinguish official rescue transfers from malicious ones. Prefer non-custodial seed or hardware setups for significant holdings going forward.

What happened

Threat actors are actively exploiting Plex2Shell, a chain of four vulnerabilities in Plex Media Server (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, CVE-2026-96656), against the Plex app on QNAP NAS devices.

The flaws were patched in summer 2026; widespread exploitation began mid-October after technical details and PoC code appeared. All four are in CISA KEV. Exploitation requires no valid credentials and can yield arbitrary code execution as the Plex service. QNAP confirmed user reports of compromise, stated no data loss in assisted cases, and emphasized the issues exist only in Plex Media Server, not in QTS/QuTS hero themselves.

Who is affected

QNAP NAS users who installed Plex Media Server via App Center and have not updated past the vulnerable builds (before 1.43.3). Internet-exposed instances with port 32400 forwarded are at highest risk.

Any organization or home user running unpatched Plex on NAS or other hosts faces the same chain risk.

Why it matters

NAS devices often hold personal media, backups and sensitive files; unauthenticated RCE on a common media app turns them into entry points for ransomware, data theft or botnet recruitment.

QNAP's large consumer and SMB installed base plus easy App Center deployment enlarge the blast radius. Post-PoC mass scanning makes unpatched internet-facing units likely already probed.

How it could have been prevented

Update Plex Media Server to 1.43.3 or later immediately. Internet-accessible devices should be treated as potentially compromised: reinstall Plex, rotate Plex and NAS passwords, and follow QNAP's remediation guide.

Disable Plex Remote Access and stop forwarding port 32400 unless required; use a VPN instead. Keep QTS/QuTS hero and all apps current. Limit NAS exposure and monitor for unexpected processes or outbound connections.

What happened

Attackers stole an estimated $133 million from French cooperative bank Crédit Mutuel Arkéa by initiating fraudulent wires from the bank's own accounts after compromising one of its service providers.

Blockchain investigator ZachXBT tracked more than $100M then an additional ~$27M leaving centralized exchange accounts as USDC/USDT, swapped to ether, passed through instant exchanges, and partly converted to Monero, starting around November 1, 2026. The bank confirmed an attack that enabled fraudulent transactions, notified authorities, and temporarily suspended some transfers. It stated the path was through an unnamed service-provider platform, not customer accounts or its Fortuneo online bank, and denied internal human error. Customer assets were said to be unaffected aside from processing delays.

Who is affected

Crédit Mutuel Arkéa (over 5.8 million customers, hundreds of billions in assets) and the unnamed service provider whose platform was the entry point.

End customers reportedly did not lose deposits; impact was operational delay and the bank's own funds. Downstream crypto exchanges and laundering rails saw the outflow.

Why it matters

A nine-figure theft via a trusted provider illustrates concentrated third-party risk in banking payment rails. Delayed public attribution can hinder freezes and recovery while funds move on-chain into mixers and privacy coins.

Even when customer balances are protected, large treasury losses, regulatory scrutiny and trust damage follow. Similar provider compromises can recur across the sector.

How it could have been prevented

Map and continuously assess critical payment and messaging providers; enforce least privilege, strong MFA, anomaly detection on high-value wires, and out-of-band confirmation for large transfers.

Monitor for mismatched beneficiary patterns and rapid multi-bank hops. Maintain incident playbooks with exchange and law-enforcement freeze contacts. Segment internal systems so a single provider compromise cannot directly originate core bank wires. Review and rotate credentials tied to external platforms after any suspected incident.