Daily Cybersecurity News – November 13, 2026

What happened

Public proof-of-concept exploit code called SignDrop was released, claiming a local Windows user can escalate to SYSTEM privileges by abusing the Common Log File System (CLFS) driver.

It targets a log-authentication feature added in late 2025 updates. A standard user prepares a CLFS log and container under controlled paths. When a privileged process (such as the Defender antimalware service) opens it, clfs.sys creates a companion .cnpf recovery file in the privileged context. Object manager symbolic links redirect that creation so the user can write a SYSTEM-owned file and chain to a shell.

Microsoft has not confirmed the flaw, assigned a CVE, or issued a fix. The researcher (MSNightmare) published the code and writeup on GitHub the same day as November 2026 security updates.

Who is affected

Windows 11 25H2/26H1/26H2 (including experimental builds) and Windows Server 2025 systems where the CLFS authentication registry mode is 0 (enforced) or 1 (learning). Established installs typically enforce after 90 days, so default configurations are in scope.

Older systems or those with the mitigation disabled (mode 2 or 3) fall outside this specific attack surface but lose the protection against prior CLFS memory-corruption issues. Local authenticated access is required.

Why it matters

CLFS has a long history as a privilege-escalation target, with multiple prior flaws in CISA's known-exploited catalog and ransomware use. Turning a security feature meant to harden log handling into an LPE path gives attackers a reliable route from standard user to SYSTEM on fully patched recent Windows builds.

Public PoC lowers the bar for exploitation in malware, ransomware, or post-compromise tooling. Operators running Windows endpoints or servers should treat unconfirmed but detailed local escalations seriously until Microsoft responds.

How it could have been prevented

Monitor for and restrict unnecessary CLFS log creation by unprivileged users. Audit registry settings for CLFS authentication mode and keep it enforced where possible rather than disabled.

Apply defense-in-depth: limit local user privileges, enable attack-surface reduction and application control, monitor for suspicious symbolic-link abuse or Defender service interactions that create unexpected .cnpf files, and watch Microsoft advisories for an official CVE and patch. Isolate high-value systems and use least-privilege service accounts.

What happened

An attacker used stolen credentials for 4,837 GitHub accounts to plant a CI secret stealer across repositories those accounts could write to, according to Aikido Security.

Attacks began with test pull requests titled "docs: dependency audit notes" from branches named wfx-docs (and similar short-lived chore branches) to check write access, hitting 61,764 repositories. The stealer was then injected into at least 1,806 repos (SafeDep observed malicious commits in 8,093+ public default branches). In most cases it was added to existing workflows; in others as an npm postinstall hook. Changes were often reverted within minutes and logs deleted.

The stealer harvests secrets and cloud credentials reachable by CI workflows. Compromised accounts that only opened test PRs are still considered burned.

Who is affected

Any GitHub repository writable by one of the 4,837 hijacked accounts, including public and (unseen) private repos, organization/collaborator-accessible projects, and developer machines that ran npm install on affected commits.

SafeDep and Aikido figures cover only visible public activity; true scale is higher. Owners of repos that received the test PR title or wfx-docs branches from Tuesday onward are in scope.

Why it matters

CI pipelines hold high-value secrets (cloud keys, tokens, deployment credentials). A mass credential-theft campaign that auto-injects and self-cleans stealers turns routine GitHub collaboration into a supply-chain and cloud-compromise vector at scale.

Even brief presence of the stealer can exfiltrate everything the workflow can reach. Developers and organizations relying on GitHub Actions or similar face immediate credential rotation needs and potential downstream cloud breaches.

How it could have been prevented

Immediately audit repositories for branches named wfx-docs or short-lived chore/[a-z0-9]{8}, PRs titled "docs: dependency audit notes", and unexpected workflow or package.json postinstall changes since the incident start. Revoke tokens, OAuth grants, SSH keys, and sessions for any account that opened such PRs.

Rotate all secrets, variables, and cloud roles the repo can access. Enforce 2FA on GitHub accounts, review collaborator and org permissions, restrict who can modify workflows, use OIDC/short-lived credentials instead of long-lived secrets where possible, and treat machines that ran npm install on suspicious commits as compromised.

What happened

Threat actors began exploiting a new zero-day in N-able N-central, dubbed 4EverAble2Shell, hours after a researcher published proof-of-concept code.

The flaw allows remote unauthenticated attackers to achieve root-level remote code execution on N-central servers. It chains an Apache Axis vulnerability (CVE-2026-90436, CVSS 9.8) with an unspecified hole present when the Legacy API is enabled. The chain works even against servers patched to 2026.4 HF2 (build 2026.4.1.26), which fixed earlier Able2Shell issues. Researcher Sean Bales also released related Agent2Shell flaws affecting managed Windows agents.

N-able responded by restricting Legacy API, Intune integration, and other features, and is working with customers on indicators of compromise.

Who is affected

N-able N-central servers running recent builds, including those with the latest weekly fixes, particularly deployments that still have Legacy API enabled. Managed endpoints via related agent flaws are also exposed.

MSPs and organizations using N-central for remote monitoring and management are the primary population; unauthenticated network reachability to the management server greatly expands blast radius.

Why it matters

N-central is a widely used RMM platform that holds privileged access to large numbers of customer endpoints. Unauthenticated root RCE on the server, combined with rapid real-world exploitation of a public PoC, creates an immediate path to mass compromise of managed estates.

The speed from disclosure to active probes underscores the risk of public zero-day drops against high-value management infrastructure. Operators face both server takeover and potential lateral movement to every managed device.

How it could have been prevented

Disable or restrict the Legacy API and related integrations immediately if not required. Apply any emergency guidance or feature lockdowns issued by N-able, isolate N-central servers from untrusted networks, and monitor for the published IoCs and probes for 4EverAble2Shell.

Rotate credentials, review agent and server logs for anomalous command execution, ensure management interfaces are behind strong authentication and network controls, and treat any exposed instance as potentially compromised until verified clean. Watch for official patches addressing the full chain.

What happened

An unknown threat actor targeted unpatched Check Point Security Gateways, using PHP2Shell vulnerabilities for initial access and then a local privilege-escalation flaw in Gaia OS to reach root and deploy the TSGA backdoor (with TSProxy component).

Activity started October 30, 2026 against Israeli organizations via vulnerable Mobile Access portals, with a broader opportunistic wave on November 2. PHP2Shell maps to CVE-2026-109618 and CVE-2026-109619 (both in CISA KEV and confirmed actively exploited). After portal access, attackers escalated via the DynamicCLI interface, deployed PHP web shells, then TSGA (as slot_CPconfigdaemon). In some cases they pivoted over SSH to VMware ESXi hosts, deployed the destroy_v6 wiper, and left politically themed notes.

Check Point observed exploitation of the LPE against a couple of dozen customers. The LPE was described as a missing-authorization issue allowing authenticated local users to run arbitrary commands.

Who is affected

Check Point Force Firewalls, Management and Log Servers, Multi-Domain variants, and Maestro Orchestrator on versions R82.20, R82.10, R82, R81.20, R81.10, and R81 that remain unpatched for the PHP2Shell issues and have exposed Mobile Access portals.

Israeli organizations were hit first; the second wave was geographically and sector-agnostic. Gateways with the relevant services reachable are primary targets; downstream ESXi hosts became secondary victims in destructive cases.

Why it matters

Security gateways sit at the network edge with high privileges. Successful PHP2Shell + LPE chains give attackers root on the appliance, persistent backdoors, and a launchpad into internal infrastructure including hypervisors.

Confirmed active exploitation (KEV-listed CVEs), rapid post-patch abuse, web-shell persistence, and selective wiper use against ESXi turn this into both an espionage and destructive threat. Organizations relying on Check Point for perimeter defense must assume internet-facing portals are high-value targets.

How it could have been prevented

Ensure all affected Check Point products are patched for the PHP2Shell CVEs (fixes available roughly a week before the observed campaign) and any subsequent LPE guidance. Disable or tightly restrict Mobile Access portals and unnecessary services if not required.

Monitor for the reported IoCs, unusual DynamicCLI socket activity, new web shells, processes named like slot_CPconfigdaemon, and SSH pivots from gateways. Segment management interfaces, enforce strong authentication, rotate credentials after any suspected access, and review ESXi hosts for wiper artifacts or unauthorized changes.

What happened

Kaspersky published the first article in a series explaining how cloud penetration testing works, focusing on trust boundaries and tenant isolation across three layers: External, Overlay, and Underlay.

It covers common architectures such as OpenStack and Kubernetes, typical attack chains, the attacker model, research goals (code execution, data access, infrastructure control), and real-world incident patterns. The piece uses a hotel analogy to illustrate multi-tenant isolation and where boundaries can fail.

Who is affected

Cloud providers, platform operators, enterprise security teams, and pentesters who assess or defend multi-tenant IaaS/PaaS environments built on OpenStack, Kubernetes, or similar stacks.

Any organization running workloads in public or private clouds where tenant isolation and control-plane security matter.

Why it matters

Cloud breaches frequently stem from broken isolation or misconfigured trust boundaries rather than simple guest escapes. Understanding the External (internet-facing), Overlay (tenant/virtual networking and control), and Underlay (physical/host infrastructure) layers helps defenders prioritize the right controls and helps builders design tests that match real attacker paths.

The series gives operators a structured mental model for what a thorough cloud pentest should examine and which failure modes have appeared in incidents.