Weekly Threat Bulletin – July 15th, 2026

CVE-2026-50656: Windows Defender Patch Introduces Disk Exhaustion Vulnerability

A recent patch for the Windows Defender zero-day vulnerability, RoguePlanet (CVE-2026-50656), which previously allowed remote administrative control of Windows 10 and 11, has introduced a new flaw enabling attackers to exhaust disk space. The researcher NightmareEclipse, who initially disclosed RoguePlanet, identified that "defense-in-depth" additions in the Microsoft Malware Protection Engine update cause mpengine.dll to leak 8 bytes of data when opening files, with new SpyNet functionality also contributing. Attackers can exploit this by configuring a custom Server Message Block (SMB) server to deliver a malicious file followed by a massive Zone.Identifier Alternative Data Stream (ADS) file. Windows Defender will attempt to cache this large ADS file locally, bypassing typical size limits, and if the SMB server maintains the connection without responding to read requests, Defender will hang, continuously writing data and consuming all available disk space, leading to system instability. This issue further escalates an ongoing dispute between NightmareEclipse and Microsoft concerning vulnerability disclosures.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Verify that all Windows 10 and Windows 11 endpoints have the Microsoft Malware Protection Engine updated to the latest version to confirm mitigation for CVE-2026-50656.
• Configure system monitoring tools to generate high-priority alerts for rapid and anomalous decreases in available disk space on Windows workstations and servers.
• Implement a firewall rule to block all outbound SMB traffic (TCP port 445) from the corporate network to the internet.
• In your Endpoint Detection and Response (EDR) or Security Information and Event Management (SIEM) platform, create a rule to alert on sustained, high disk I/O activity from the Microsoft Defender Antivirus process (MsMpEng.exe).

Compliance Best Practices

• Develop and implement a network segmentation strategy that restricts SMB (TCP port 445) communication to only authorized endpoints and servers, following the principle of least privilege.
• Evaluate and deploy a non-Microsoft Endpoint Detection and Response (EDR) solution to provide a secondary layer of endpoint protection and telemetry, independent of the native Microsoft security stack.
• Conduct a formal risk assessment to weigh the security benefits of Microsoft's cloud-delivered protection (MAPS/SpyNet) against the potential risk of exploitation from vulnerabilities like the one described, before making any policy changes to disable the feature.

WP-SHELLSTORM: Exposed Server Unveils Operations Targeting 1.4M Sites

An exposed Python SimpleHTTPServer instance, left open for 22 days, revealed the full operational toolkit, logs, and target lists of a financially motivated cybercrime group, now tracked as WP-SHELLSTORM. This operation targeted over 1.4 million domains, weaponized 27 CVEs, and deployed more than 5,700 active webshells. The exposed directory, located at 137.175.93[.]126, contained 800MB of webshells, exploit scripts, scan results, bash history, and C2 configurations. Attribution points to a Chinese-linked actor, evidenced by the system user "tance," the handle "chen-kk," use of FOFA (a Chinese reconnaissance tool), and Simplified Chinese comments in the code. Beyond WordPress, the actor also targeted Apache Nacos, XXL-Job, and Spring Boot infrastructure, exploiting vulnerabilities like CVE-2021-29441 (Nacos authentication bypass) to exfiltrate 613 configuration files from 11 victim systems in May 2026, obtaining cloud credentials, database connection strings, and Alipay RSA private keys. The primary webshell, `down.php`, is a heavily obfuscated BestShell derivative, capable of extensive post-exploitation activities, while a dropper named SNOWLIGHT deploys the VShell implant, which renames its process to `[kworker/0:2]` for stealth. Key vulnerabilities exploited include Breeze Cache (CVE-2026-3844), ThemeREX Addons (CVE-2026-1969), and Joomla JCE (CVE-2026-48907). The actor attempted to cover tracks by deleting log entries after discovery, but weak operational security, including exposed FOFA config and hardcoded webshell credentials, facilitated the investigation. Defense measures include blocking known infrastructure (137.175.93[.]126, 43.108.17[.]80, 113.196.56[.]150, xs.xxooonline[.]eu[.]cc), scanning for specific webshell filenames and hashes (e.g., `down.php` SHA256: 84F7E396A48913851A10CC78C5CC22A25634564ABD0694465236D2F365E2BDEE), monitoring for suspicious `[kworker/X:Y]` processes, upgrading Nacos to 2.2.1+ with authentication enabled, securing XXL-Job and Spring Boot endpoints, and updating or disabling targeted WordPress/Joomla plugins.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Add the IP addresses 137.175.93.126, 43.108.17.80, and 113.196.56.150 to your network firewall blocklist.
• Block the domain xs.xxooonline.eu.cc in your DNS filtering service and web proxy.
• Scan all web server file systems for files matching the patterns: .bd.php, .wp-log.php, .brq-*.php, .sd.php, .leo_*.php, .wvp-*.php, .cc-*.php, .nf-log.php, BZ_*.phtml.
• Use your EDR or file scanning tools to search all systems for a file with the SHA256 hash 84F7E396A48913851A10CC78C5CC22A25634564ABD0694465236D2F365E2BDEE.
• On Linux hosts, investigate any running process named '[kworker/X:Y]' to verify its executable path is a legitimate kernel path and not a masquerading implant.
• Audit all WordPress sites for the presence of vulnerable plugins mentioned in the article (Breeze Cache, ThemeREX Addons, Simple File List, Custom CSS JS PHP, WavePlayer, BerqWP, Ninja Forms, WPBookit, WP File Manager) and update them to the latest patched version immediately.
• Audit all Joomla sites to identify and immediately update any vulnerable versions of the JCE component to a patched version.
• Upgrade all Apache Nacos instances to version 2.2.1 or later to mitigate the authentication bypass vulnerability (CVE-2021-29441).
• Verify that all Apache Nacos instances have authentication enabled by setting 'nacos.core.auth.enabled=true' in the configuration.
• Review all production Spring Boot applications and disable the '/actuator/heapdump' endpoint.
• Identify all XXL-Job executor endpoints and ensure they require authentication and are not directly exposed to the internet.

Compliance Best Practices

• Implement a centralized secrets management solution, such as HashiCorp Vault, to store and manage all application credentials, API keys, and tokens, removing them from configuration files.
• Establish an Attack Surface Management (ASM) program to continuously scan for and inventory all internet-facing assets, identifying and remediating exposures like open ports and unauthenticated services.
• Develop and implement a formal vulnerability management program that includes regular automated scanning, risk-based prioritization of vulnerabilities, and defined SLAs for patching.
• Conduct a thorough audit of all systems that may have been exposed to the Nacos authentication bypass (CVE-2021-29441) and execute a phased rotation of all associated credentials, including database passwords, cloud keys, and API tokens.
• Design and implement a network segmentation strategy that isolates critical application components from each other and from the public internet, applying the principle of least privilege to network traffic.
• Develop and deploy custom detection rules in your SIEM and EDR platforms to alert on behaviors specific to this campaign, such as process masquerading as '[kworker/X:Y]' and the creation of files with suspicious PHP extensions in web directories.
• Deploy a Web Application Firewall (WAF) in front of all public-facing web applications and create a long-term plan to tune its rulesets to block common attack patterns like SQL injection, file inclusion, and known exploit attempts.

Linux FUSE Vulnerability Allows Unprivileged Users to Pop a Root Shell

A critical Linux kernel vulnerability, tracked as CVE-2026-31694, exists within the FUSE subsystem, enabling unprivileged local users to achieve root privilege escalation. This flaw, present in the `fuse_add_dirent_to_cache()` function (fs/fuse/readdir.c), stems from a 24-byte heap overflow past the end of a page cache page. Specifically, when the `FOPEN_CACHE_DIR` flag is enabled, an attacker can craft a FUSE directory entry with a `namelen` of 4095 bytes, resulting in a 4120-byte record that exceeds the standard 4 KiB `PAGE_SIZE` on `x86_64` systems. This overflow allows for controlled corruption of the page cache, which can be exploited by strategically placing the oversized FUSE directory entry page immediately before the `.init` section of a cached SUID binary, such as `/usr/bin/su` on Ubuntu 26.04 with a vulnerable 7.0 kernel. The injected payload, minimal `x86_64` shellcode calling `setuid(0)` and `setgid(0)`, executes with root privileges before the normal authentication flow, granting a root shell. This vulnerability affects Linux kernels from v6.16-rc1 onwards, particularly on systems with 4 KiB page sizes where unprivileged FUSE mounts are possible. The issue is resolved by commit `51a8de6c50bf947c8f534cd73da4c8f0a13e7bed`, which prevents caching directory entries larger than ``PAGE_SIZE`.` Recommended mitigations include deploying kernel updates, stripping the setuid bit from `fusermount3` if not essential, and restricting or disabling unprivileged user namespaces to reduce the attack surface.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Scan all Linux hosts to identify systems running kernel versions v6.16-rc1 or later and flag them as vulnerable to CVE-2026-31694.
• Apply the latest available kernel security updates from your Linux distribution to all identified vulnerable systems to patch CVE-2026-31694.
• On vulnerable systems where immediate patching is not feasible, remove the setuid permission from the `fusermount3` binary using the command `chmod u-s /usr/bin/fusermount3`.
• On vulnerable systems where immediate patching is not feasible, disable unprivileged user namespaces by setting the kernel parameter `kernel.unprivileged_userns_clone=0` via sysctl.

Compliance Best Practices

• Establish a recurring process to audit all Linux systems for SUID and SGID binaries, and create a baseline of approved executables, removing permissions from any that are not required for business operations.
• Develop and implement a formal security policy that restricts the use of unprivileged user namespaces, enabling them only on systems where they are explicitly required and approved for applications like container runtimes.

Jscrambler npm Supply Chain Attack Steals Cloud Credentials and Crypto Wallet Secrets

A malicious actor compromised the Jscrambler npm package, publishing trojanized versions that deployed a hidden, cross-platform credential-stealing payload. This supply chain attack targeted developers, build pipelines, and CI/CD systems, aiming to exfiltrate source code, cloud credentials, deployment tokens, and sensitive environment variables. The initial malicious release, `jscrambler@8.14.0`, detected on July 11, 2026, utilized an undocumented `preinstall` hook to execute `node dist/setup.js`, which then launched a hidden executable from `dist/intro.js`. Subsequent compromised versions, including `8.16.0`, `8.17.0`, `8.18.0`, and `8.20.0`, evolved their delivery methods; versions `8.18.0` and `8.20.0` injected a self-executing dropper into `dist/index.js` and `dist/bin/jscrambler.js`, activating upon dependency import or CLI execution. The Rust-based payload, using ChaCha20-Poly1305 for string concealment, extensively targeted cloud credentials (AWS, Google Cloud, Azure tokens and keys), cryptocurrency wallet data (MetaMask, Trust Wallet, Coinbase Wallet, Phantom, Exodus seed phrases and vault data), and configuration files from AI coding assistants and developer tools (Claude Desktop, Cursor, VS Code API keys). It also sought browser data, Discord, Slack, Telegram, Steam information, system keyrings, and developer secrets, exfiltrating data via TLS-based multipart POST requests. Organizations must immediately identify and remove installations of these affected versions, rotating all potentially exposed secrets, including npm tokens, cloud keys, GitHub tokens, deployment credentials, API keys, and cryptocurrency wallet credentials. Jscrambler confirmed the unauthorized publishing, revoked compromised credentials, deprecated malicious versions, and released `jscrambler@8.22.0` as a clean update.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Scan all software projects, dependency lock files (e.g., package-lock.json), and build environments to identify any use of malicious Jscrambler package versions: 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0.
• Add the SHA-256 hashes for the malicious loaders and platform-specific executables provided in the article to your Endpoint Detection and Response (EDR) platform's blocklist to prevent execution.
• Using your SIEM or forensic tools, search all endpoints and servers for files matching the SHA-256 hashes provided in the Indicators of Compromise list, including dist/setup.js, dist/intro.js, and the OS-specific payloads.
• On all systems where malicious versions were found, remove the package and upgrade to the clean Jscrambler version 8.22.0 or higher. Rebuild any affected projects from a clean state.
• Immediately begin rotating all potentially exposed cloud credentials, including AWS, Google Cloud, and Microsoft Azure keys, tokens, and service account files on developer workstations and in CI/CD environments.
• Immediately rotate all developer platform credentials, including npm tokens, GitHub tokens, and other API keys stored in configuration files or environment variables on developer machines and CI/CD systems.
• Force a logout and credential rotation for users on potentially affected systems for communication platforms like Slack, Discord, and Telegram.
• Isolate any developer workstations or CI/CD runners where malicious Jscrambler versions were installed from the network pending full remediation and investigation.

Compliance Best Practices

• Configure all CI/CD pipelines and developer environments to use `npm install --ignore-scripts` by default. Establish a formal exception and review process for packages that require lifecycle scripts to run.
• Evaluate and implement a software supply chain security platform to scan third-party dependencies for malicious code, unexpected lifecycle scripts, and other high-risk characteristics before they are integrated into projects.
• Re-architect CI/CD pipelines and developer workflows to use short-lived, ephemeral credentials for accessing cloud resources, such as using OIDC federation with cloud provider IAM roles, instead of storing static, long-lived keys.
• Implement strict egress filtering rules for developer workstations and CI/CD environments to block outbound traffic to non-essential or unknown destinations, allowing connections only to an approved list of services.
• Develop and mandate a recurring security training program for all developers focusing on software supply chain risks, secure dependency management practices, and how to identify suspicious packages.

Dell BIOS Passwords: Weak XOR Encryption Allows Recovery from SPI Flash (CVE-2026-40639)

Dell BIOS administrator and user passwords are stored as XOR-encrypted plaintext in the DVAR region of the SPI flash chip, not as a one-way hash, leading to a critical vulnerability tracked as CVE-2026-40639 (DSA-2026-197). This scheme encrypts a 32-byte password field with a 20-byte key, but the first character remains unencrypted. For passwords up to 12 characters, the unused null-padded tail of the field directly leaks the entire 20-byte key, allowing for instant, exact recovery from a flash dump without brute force. Longer passwords are also vulnerable because the key derivation is largely static per device (only 256 possible keys based on the unencrypted first character) and the log-structured DVAR store retains historical password records, which can leak the full key if a shorter, historically used password shared the same first character. Exploitation requires physical access to the device to read the SPI flash, either with a hardware programmer or by booting an attacker-controlled operating system. This vulnerability affects a range of Dell platforms, including the current-generation Wyse 5070 thin client, Dell Latitude E7250, Latitude 7490, and XPS 15 9560, all of which utilize the SystemPwSmm SMM driver. While newer models like the OptiPlex 3000 use a more secure SHA-256 hashing mechanism, many vulnerable systems remain unpatched, including end-of-life devices. Recovering the BIOS password grants an attacker full BIOS access, enabling changes to boot order, disabling Secure Boot, and potentially bypassing full disk encryption if the BIOS password is part of the boot chain protection. Recommendations include hashing passwords with strong algorithms (e.g., PBKDF2, bcrypt, Argon2), ensuring encryption keys are sufficiently long and not derivable from plaintext, encrypting all password components, securely wiping historical records, and for defenders, assuming BIOS passwords are recoverable with physical access, implementing Secure Boot with enrolled keys, TPM-measured boot, and robust physical security controls.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Identify all Dell models listed in Dell Security Advisory DSA-2026-197 and apply the corresponding BIOS updates immediately.
• Create an inventory of all Dell client hardware models and their current BIOS versions to identify systems vulnerable to CVE-2026-40639.
• Review and reinforce physical security controls for all Dell client devices, especially laptops that travel and thin clients located in public-facing areas.
• For vulnerable devices that cannot be patched immediately, enforce a temporary policy requiring BIOS passwords to be a minimum of 13 characters long.

Compliance Best Practices

• Develop and implement a hardware lifecycle policy to replace end-of-life models that will not receive security patches for vulnerabilities like CVE-2026-40639.
• Implement a centralized management solution, such as Dell Command | Configure, to enforce unique BIOS administrator passwords for each device across the fleet.
• Implement Secure Boot across the Dell fleet using organization-controlled, enrolled keys instead of the default manufacturer keys.
• Configure full disk encryption (e.g., BitLocker) to use a Trusted Platform Module (TPM) and validate boot configuration integrity by binding encryption keys to the correct Platform Configuration Registers (PCRs).
• Update the corporate asset disposal policy to mandate the secure wiping of BIOS/UEFI non-volatile memory (NVRAM) in addition to storage drives before devices are resold or recycled.
• Enable and configure BIOS-level chassis intrusion detection on supported Dell desktops and configure alerting within your security monitoring tools.