A heap buffer overflow in the NGINX rewrite module is being actively exploited in the wild less than 48 hours after disclosure. Separately, a fully weaponized Windows kernel zero-day has no patch, and 7-Eleven has confirmed a major breach by ShinyHunters. Monday morning starts with patching.

In the News

CVE-2026-42945: NGINX Heap Overflow Now Exploited in the Wild

A heap buffer overflow in the NGINX rewrite module — tracked as CVE-2026-42945 with a CVSS score of 9.2 — is under active exploitation. The vulnerability affects NGINX versions 0.6.27 through 1.30.0, which covers effectively every production deployment that has not updated to the 1.30.1 patch released this week.

The flaw is in the rewrite module’s handling of regex-driven URI transformations. A crafted request can trigger an out-of-bounds heap write in the worker process. On default configurations, this results in worker crash and denial of service. On systems where ASLR (Address Space Layout Randomization) is disabled — more common in embedded appliances, legacy containers, and certain CI/CD runners than most teams realize — the overflow is exploitable for remote code execution.

Exploitation was observed in the wild within 48 hours of the advisory. The attack surface is enormous: NGINX sits in front of an estimated 34% of all web servers and is the default reverse proxy and load balancer in most Kubernetes ingress controllers, ADC deployments, and WAF configurations. Any environment that has not patched is exposed.

What defenders should do: Update to NGINX 1.30.1 or later immediately. If patching requires a maintenance window, deploy WAF virtual patching rules to block malformed rewrite-triggering URIs and confirm ASLR is enabled on every host running NGINX worker processes. Scan your asset inventory — NGINX is often deployed in places teams forget about (sidecar containers, CI runners, internal tooling).

MiniPlasma: Windows Zero-Day Grants SYSTEM With No Patch Available

A fully weaponized proof-of-concept exploit dubbed “MiniPlasma” has been publicly released for a privilege escalation vulnerability in the Windows Cloud Files Mini Filter Driver (cldflt.sys). The exploit grants SYSTEM-level access on fully patched Windows systems. Microsoft has not released a fix or announced a timeline.

The cldflt.sys driver handles cloud file placeholder operations — the mechanism Windows uses for OneDrive and other cloud storage sync. MiniPlasma exploits a flaw in how the driver processes reparse point operations, allowing a local attacker to escalate from a standard user account to SYSTEM. The PoC is reliable and does not require unusual configurations or specific Windows editions.

This is a classic post-initial-access escalation tool. Threat actors who gain a foothold through phishing, web exploitation, or credential abuse can use MiniPlasma to immediately escalate to the highest privilege level on the compromised host. With no patch available, this will remain exploitable until Microsoft ships a fix — likely not before the June Patch Tuesday cycle.

What defenders should do: Monitor for suspicious cldflt.sys activity, SYSTEM token creation from unprivileged user contexts, and behavioral indicators of kernel driver exploitation. EDR platforms should be evaluated for coverage of this specific exploit chain. Application allowlisting that prevents execution of unsigned binaries in user-writable directories will block the PoC binary in its current form, though sophisticated actors will adapt.

7-Eleven Breach Confirmed — ShinyHunters Claims 600K+ Salesforce Records

7-Eleven has confirmed a data breach after the ShinyHunters threat group — associated with the broader Coinbase Cartel operation — claimed responsibility for exfiltrating more than 600,000 records from the retailer’s Salesforce environment. The stolen data reportedly includes customer personally identifiable information (PII) and internal corporate records. A ransom demand followed the theft.

The exact initial access vector has not been publicly confirmed. ShinyHunters has a well-documented history of targeting SaaS platforms, developer environments, and cloud infrastructure. The group’s previous operations include breaches of AT&T, Ticketmaster, and Santander, all involving cloud-hosted data stores. The Salesforce attack surface — connected apps, API integrations, and overprivileged service accounts — is a recurring theme in their campaigns.

What defenders should do: Organizations using Salesforce or any CRM holding PII should audit connected app permissions, API access tokens, and data export policies. Review Salesforce login history for anomalous access patterns. Enforce phishing-resistant MFA on all Salesforce administrator and API service accounts. Implement data loss prevention controls that alert on bulk record exports.

Shai-Hulud Worm Clones Hit npm — Supply Chain Attacks Using TeamPCP Framework

Four malicious npm packages have been identified delivering infostealers and the Phantom Bot DDoS malware: chalk-tempalte, @deadcode09284814/axios-util, axois-utils, and color-style-utils. At least one package is a direct clone of the Shai-Hulud worm, built using the recently open-sourced TeamPCP attack framework.

The packages exploit typosquatting — mimicking legitimate, widely-used packages like chalk-template and axios-utils with subtle misspellings. Developers who install them via npm install execute the malicious payload, which deploys an infostealer targeting browser credentials, SSH keys, and environment variables, alongside a DDoS bot that enrolls the compromised system into Phantom Bot infrastructure.

TeamPCP’s public release has lowered the barrier to entry for npm supply chain attacks. The framework provides templated malicious package creation, obfuscation, and exfiltration infrastructure — turning supply chain poisoning from a bespoke operation into a repeatable playbook.

What defenders should do: Scan npm dependency trees using npm audit and dedicated software composition analysis (SCA) tools. Check for the four named packages in package-lock.json across all repositories. Implement package provenance verification and consider using npm’s --ignore-scripts flag in CI/CD pipelines to prevent automatic execution of install scripts from untrusted packages.

Today’s Deep Dive — Tycoon2FA Adds Device-Code Phishing to Bypass MFA

The Tycoon2FA phishing-as-a-service (PhaaS) platform — already one of the most prolific adversary-in-the-middle (AiTM) phishing kits — has added support for OAuth device-code flow attacks targeting Microsoft 365 and Entra ID. This represents a significant capability expansion beyond traditional AiTM session hijacking.

The Mechanism

Standard AiTM phishing intercepts credentials and session cookies in real time by proxying the victim’s authentication to the legitimate identity provider. Device-code phishing takes a different approach entirely. It exploits the OAuth 2.0 device authorization grant flow — the mechanism designed for devices without browsers (smart TVs, IoT devices, CLI tools) where a user is prompted to navigate to https://microsoft.com/devicelogin and enter a code.

The attack works as follows:

  1. The attacker initiates a device-code authentication request to Microsoft Entra ID, receiving a user code and a device code.
  2. A phishing email — now using Trustifi click-tracking URLs to bypass email gateway URL rewriting and reputation checks — directs the victim to the Microsoft device login page.
  3. The victim enters the attacker-supplied user code and authenticates normally, including completing MFA.
  4. Microsoft issues an access token and refresh token to the attacker’s session, not the victim’s browser.
  5. The attacker now holds a fully authenticated session with a long-lived refresh token, independent of the victim’s device.

This bypasses MFA entirely because the victim completes the MFA challenge themselves on a legitimate Microsoft page. There is no credential interception, no session cookie theft, and no fake login page. The victim’s authentication is real — it is just authorizing the wrong device.

MITRE ATT&CK mapping: T1528 (Steal Application Access Token), T1566.002 (Phishing: Spearphishing Link).

Detection

Device-code flow authentications generate distinct signals in Entra ID sign-in logs. The key fields to monitor:

  • Authentication protocol: deviceCode in the sign-in log
  • Application: look for device-code grants to unexpected applications (anything other than your sanctioned CLI tools and device management apps)
  • Location mismatch: the device-code grant will show the attacker’s IP, not the victim’s
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where AppDisplayName !in ("Azure CLI", "Azure PowerShell", "Microsoft Teams Rooms")
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, DeviceDetail
| sort by TimeGenerated desc

This query surfaces successful device-code authentications to non-sanctioned applications. False positive rate is low in environments that have baselined their legitimate device-code usage — most organizations have fewer than a handful of applications that should ever use this flow.

Primary Mitigations

  1. Block device-code flow via Conditional Access. Microsoft Entra ID allows creating a Conditional Access policy that blocks the device-code authentication flow entirely. For organizations that do not use smart TVs, IoT devices, or CLI tools that require this flow, blocking it eliminates the attack surface.
  2. Restrict device-code flow to sanctioned applications. If blocking entirely is not feasible, scope the Conditional Access policy to allow device-code grants only to specific, named applications.
  3. Deploy phishing-resistant MFA (FIDO2). Device-code phishing works because the victim can complete a push notification or TOTP-based MFA challenge on behalf of the attacker. FIDO2 security keys are bound to the origin — they cannot be used to authorize a device-code flow initiated by an attacker.
  4. Monitor Trustifi and similar click-tracking URL abuse. Email security gateways should flag click-tracked URLs that redirect to microsoft.com/devicelogin as suspicious.

Detection Spotlight

The DirtyDecrypt Linux kernel privilege escalation PoC (rxgk module) was released this week. For Linux hosts — including cloud worker nodes on EKS, AKS, and GKE — this Sigma-style detection targets the post-exploitation pattern of a local user suddenly obtaining root via kernel exploit:

1# Audit rule to detect privilege escalation via kernel exploit
2# Add to /etc/audit/audit.rules or auditd.conf
3
4# Monitor for execve from non-root user resulting in uid=0 process
5-a always,exit -F arch=b64 -S execve -F euid=0 -F auid!=0 -F auid!=4294967295 -k priv_escalation
6
7# Monitor for changes to kernel module loading (rxgk or other)
8-w /sbin/insmod -p x -k kernel_module_load
9-w /sbin/modprobe -p x -k kernel_module_load

These audit rules flag when a non-root user’s process suddenly executes as root (the signature pattern of a kernel privilege escalation exploit) and when kernel modules are loaded. On containerized workloads, kernel module loading from within a container is almost always malicious. Review hits against your baseline of legitimate administrative activity — on most servers, the false positive rate is negligible outside of scheduled maintenance windows.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.