Weekly Threat Bulletin – June 10th, 2026

Sovereign Compromise: Zero-Day “MiniPlasma” Flaw Grants SYSTEM Privileges in Windows

A zero-day vulnerability, designated MiniPlasma, is actively exploited within the Windows ecosystem, enabling local adversaries to achieve SYSTEM-level administrative privileges. This flaw, which mirrors CVE-2020-17103, affects fully updated deployments of Windows 11, Windows Server 2022, and Windows Server 2025 by subverting the native Cloud Filter driver, specifically targeting a structural anomaly within the HsmOsBlockPlaceholderAccess procedure. Telemetry indicates live weaponization since April 10, 2026, with public exploit code available. Microsoft intends to distribute an official security patch on June 9, 2026. Key indicators of compromise include anomalous symbolic links in `HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps`, `wermgr.exe` materializing outside standard system directories, core system files executing from non-standard folders, and the use of the NtApiDotNet library for low-level registry manipulations. Security teams must monitor modifications within `CloudFiles\BlockedApps` registry keys, scrutinize child processes spawned by the error reporting utility, and isolate any instantiation of `wermgr.exe` outside `C:\Windows\System32` or `C:\Windows\SysWOW64`, as the exploit triggers the `\Microsoft\Windows\Windows Error Reporting\QueueReporting` task. Temporary mitigations involve aggressive monitoring for suspicious registry activity, implementing strict detection rules for non-standard system binary execution paths, and continuously tracking anomalous behavior within the Windows Error Reporting framework.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Prioritize and deploy the Microsoft security patch for the MiniPlasma vulnerability, expected on June 9, 2026, to all affected Windows 11, Windows Server 2022, and Windows Server 2025 systems as soon as it becomes available.
• Create a detection rule to alert on any modifications or the creation of symbolic links within the `HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps` registry path.
• Configure endpoint monitoring to generate a high-priority alert if the `wermgr.exe` process is executed from any directory other than `C:\Windows\System32` or `C:\Windows\SysWOW64`.
• Perform threat hunting queries across endpoint logs to identify any processes that have recently loaded the `NtApiDotNet` library.
• Configure process monitoring to alert on unusual child processes spawned by the Windows Error Reporting service (`wermgr.exe`).

Compliance Best Practices

• Implement and enforce a strict principle of least privilege (PoLP) policy, ensuring that standard user accounts do not have local administrative rights on workstations.
• Deploy an application allowlisting solution, such as Windows Defender Application Control or AppLocker, to restrict software execution to only approved applications and paths.
• Enhance Endpoint Detection and Response (EDR) policies to detect and alert on generic privilege escalation techniques, such as processes manipulating system drivers or core system files executing from non-standard folders.
• Strengthen security controls against initial access vectors like phishing by implementing advanced email filtering and conducting regular user security awareness training.
• Ensure comprehensive logging from all Windows endpoints, including detailed process creation events and registry modifications, is forwarded to a central SIEM for monitoring and analysis.

New 'HTTP/2 Bomb' DoS Attack Crashes Web Servers in Under a Minute

A new denial-of-service (DoS) attack, termed "HTTP/2 Bomb," can rapidly crash web servers by combining HPACK compression amplification with Slowloris-style HTTP/2 flow-control stalling. Discovered by OpenAI's Codex and researchers at Calif, this technique allows a single client on a 100 Mbps connection to exhaust tens of gigabytes of server RAM within seconds, preventing its release. Major web servers, including NGINX, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare Pingora, are vulnerable in their default HTTP/2 configurations; for instance, Apache httpd and Envoy can consume 32GB of memory in approximately 10-20 seconds. The attack leverages HPACK's header compression to amplify small attacker inputs into significant server-side memory allocations (e.g., 5,700:1 for Envoy) and then uses zero-byte flow-control windows to stall requests indefinitely, preventing memory deallocation and bypassing existing defenses like total decoded header size limits. Patches have been released for NGINX (version 1.29.8+, introducing a `max_headers` directive) and Apache httpd `(mod_http2` 2.0.41, assigned CVE-2026-49975), while unpatched servers like IIS, Envoy, and Pingora are advised to disable HTTP/2 or implement proxy/firewall-based hard header-count limits.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Identify all public-facing NGINX web servers and upgrade them to version 1.29.8 or newer, which adds the max_headers directive with a default of 1000. If you can't upgrade, disable HTTP/2 with http2 off;.
• Identify all public-facing Apache httpd servers and upgrade the mod_http2 module to version 2.0.41 or newer to remediate CVE-2026-49975.
• Disable the HTTP/2 protocol on all public-facing Microsoft IIS servers until a security patch is released by the vendor.
• Disable the HTTP/2 protocol on all public-facing Envoy proxies until a security patch is released by the vendor.
• Configure your Web Application Firewall (WAF) or edge reverse proxy to enforce a strict limit on the number of headers allowed per single HTTP request.

Compliance Best Practices

• Evaluate and plan the deployment of a Content Delivery Network (CDN) or a dedicated reverse proxy in front of all public-facing web applications to abstract and protect backend servers from direct client attacks.
• Implement and tune monitoring with automated alerting for sustained high memory and CPU utilization on all critical web servers to ensure early detection of potential Denial-of-Service activity.
• Establish a formal policy and recurring process to review and disable all non-essential protocols, services, and server modules on public-facing systems to minimize the overall attack surface.

New IronWorm Malware Hits 36 Packages in npm Supply-Chain Attack

A new supply-chain attack has infected 36 packages on the Node Package Manager (npm) index with infostealer malware named IronWorm. This Rust-based malware targets 86 environment variables and 20 credential files, including those for OpenAI, AWS, Anthropic, npm, vault configurations, SSH keys, and Exodus cryptocurrency wallets. IronWorm employs an eBPF kernel rootkit for stealth and communicates with its operators via the Tor network. It self-propagates by leveraging stolen credentials, including those from npm's Trusted Publishing workflow, to publish trojanized package versions from compromised developer or CI environments. The attack originated from a compromised account, 'asteroiddao,' which published package versions containing a Rust ELF binary executed via 'preinstall,' with commit timestamps manipulated to evade investigation. While a mechanism exists to exfiltrate stolen secrets via GitHub Actions by serializing them into a file and uploading it as a build artifact, this method was not observed in the analyzed IronWorm campaign. Researchers noted conceptual similarities and shared commit names with the Shai Hulud malware, suggesting a possible evolution. The attack was detected early and contained before widespread propagation, with recommendations for developers to upgrade to fixed releases, rotate keys, and enable two-factor authentication. Concurrently, a distinct but similar JavaScript-based malware, 'binding.gyp,' was observed performing registry poisoning and GitHub Actions infection.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Audit all software projects to identify if any of the 36 npm packages compromised by IronWorm are present in your dependencies. Immediately remove or replace any identified malicious packages.
• Force rotation of all npm access tokens for both developer accounts and CI/CD service accounts.
• Force rotation of all AWS credentials accessible from developer workstations and CI/CD environments.
• Force rotation of all developer and service account SSH keys.
• Scan developer workstations and CI/CD build logs for evidence of unexpected binaries being executed by npm 'preinstall' scripts.
• Update firewall and proxy rules to deny and alert on all outbound traffic to known Tor entry and exit nodes from developer and CI/CD network segments.

Compliance Best Practices

• Enforce mandatory multi-factor authentication (MFA) for all developer accounts on code repositories like GitHub and package registries like npm.
• Configure package managers like npm to disable the automatic execution of lifecycle scripts (e.g., 'preinstall') by default across all developer and CI/CD environments. Establish a process to vet and explicitly allow scripts for trusted packages only.
• Implement automated scanning of CI/CD build artifacts for anomalies, such as unexpected file types or sizes, to detect potential data exfiltration as described in the article's analysis of the malware's GitHub Actions capability.
• Adopt npm's Trusted Publishing feature to tie package publications to specific CI/CD workflows, preventing stolen developer tokens from being used to publish malicious package versions.
• Deploy an Endpoint Detection and Response (EDR) solution on all developer workstations and build servers, ensuring it is configured to detect and alert on suspicious kernel-level activity, such as the loading of unauthorized eBPF programs.
• Establish a formal dependency management policy that requires security vetting and approval of all new open-source packages before they can be used in production code.

FlutterShell Backdoor Spreads to macOS via Malicious Google and YouTube Ads

A macOS malvertising campaign, dubbed Operation FlutterBridge, is actively distributing a new backdoor named FlutterShell. This campaign is attributed to the cybercrime group CL-CRI-1089, which is also linked to previous activities like JSCoreRunner (FileRipple) and TamperedChef. The group employs malicious Google and YouTube advertisements, often delivered via Google-verified shell companies, to lure macOS users in the U.S., Canada, Australia, France, and Germany into downloading trojanized desktop applications. FlutterShell, developed using the Flutter framework, operates as both adware and a backdoor, enabling shell command execution, file system manipulation, and exfiltration of environment variables. Upon execution, it modifies Google Chrome configuration files to hijack the browser, redirecting all traffic through attacker-controlled, ad-filled intermediary sites. A notable technical aspect is its WebView-based architecture, which utilizes a JavaScript-to-native bridge to host malicious logic externally, allowing dynamic alteration of the malware's behavior without requiring recompilation. Identified variants include PodcastsLounge, PDF-Brain, and PDF-Ninja, with some leveraging an AI-powered summarization capability to exfiltrate documents via an attacker-controlled server. The malware successfully bypassed Apple's automated security checks and notarization by using valid Apple Developer IDs. This evolution from prior campaigns signifies a substantial increase in the attackers' technical depth and distribution scale.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Obtain the list of Indicators of Compromise (IOCs) for FlutterShell and Operation FlutterBridge from the Palo Alto Networks Unit 42 report and add all associated domains, IPs, and file hashes to your blocklists in the firewall.
• Obtain the list of Indicators of Compromise (IOCs) for FlutterShell and Operation FlutterBridge from the Palo Alto Networks Unit 42 report and add all associated domains and IPs to your blocklists in the web proxy.
• Obtain the list of Indicators of Compromise (IOCs) for FlutterShell and Operation FlutterBridge from the Palo Alto Networks Unit 42 report and add all associated file hashes to your blocklists in your Endpoint Detection and Response (EDR) or antivirus solution.
• Using your endpoint management or EDR tool, scan all macOS devices for recent, unauthorized modifications to Google Chrome configuration files.
• Send an immediate security alert to all employees, particularly macOS users, warning them not to download software from advertisements, and to be suspicious of apps like 'PodcastsLounge', 'PDF-Brain', and 'PDF-Ninja'.

Compliance Best Practices

• Implement an application allowlisting policy on all macOS endpoints to ensure only company-vetted and approved software can be executed.
• Tune your Endpoint Detection and Response (EDR) solution to create high-fidelity alerts for behavioral anomalies on macOS, such as an application modifying browser settings or executing shell commands unexpectedly.
• Deploy a centrally managed ad-blocking solution or enhance web filter policies to block advertising-related domains and scripts on all corporate devices.
• Enforce a policy of least privilege across all endpoints by removing local administrator rights from standard user accounts, requiring administrative approval for all software installations.
• Incorporate specific modules on the dangers of malvertising and downloading software from unvetted sources into your mandatory, recurring security awareness training program.
• Task the security engineering team with developing a detection rule that monitors for macOS applications using a WebView component to make suspicious calls to the native operating system via a JavaScript bridge.

Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)

A critical use-after-free vulnerability, CVE-2026-23479, has been patched in Redis's blocking-client code, enabling an authenticated user to execute arbitrary OS commands on the host machine. Discovered by an autonomous AI tool named Team Xint Code, this flaw was introduced in Redis 7.2.0 and remained undetected across all stable branches for over two years until fixes were released on May 5. Rated 8.8 by NVD (CVSS 3.1) and 7.7 by Redis (CVSS 4.0), the vulnerability resides in `unblockClientOnKey()` within `src/blocked.c`, where a client pointer is used after being potentially freed by `processCommandAndResetClient()`. The exploit chain involves leaking a heap address via a Lua script, memory grooming to inject a fake client, and overwriting a function pointer in the Global Offset Table to redirect `strcasecmp()` to `system()`, facilitating shell command execution. While requiring an authenticated session with specific ACL categories (`@admin`, `CONFIG`, `@scripting`, `@stream`, `@read/@write`), the default Redis user typically possesses these privileges, and analysis indicates that a large majority of cloud Redis instances run without a password, increasing exposure. Patched versions include 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3; immediate upgrades are recommended. Interim mitigations include keeping Redis off the public internet, using TLS, tightening ACLs to prevent a single role from holding all necessary privileges, and disabling Lua scripting if not utilized.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Identify all Redis instances running versions 7.2.0 through 8.6.2 and immediately upgrade them to the corresponding patched version: 7.2.14, 7.4.9, 8.2.6, 8.4.3, or 8.6.3.
• Review firewall and cloud security group rules to ensure no Redis instances are accessible from the public internet. Restrict access to only trusted internal IP addresses.
• Audit Redis Access Control Lists (ACLs) and modify roles to ensure no single user has the combined permissions of `@admin`, `CONFIG`, and `@scripting`.
• If your applications do not use Lua, disable the `@scripting` capability for all Redis users to block the initial stage of this specific exploit.
• Identify and immediately rotate any shared or default credentials used to access Redis instances.

Compliance Best Practices

• Establish and enforce a formal policy of least privilege for all database access. Create granular Redis roles for applications and operators that grant only the specific commands required for their function, avoiding the use of the default user in production.
• Implement a mandatory security policy that requires strong, unique passwords for all Redis instances. Integrate automated checks into your CI/CD pipeline to prevent the deployment of Redis instances without authentication enabled.
• Implement a network segmentation strategy where Redis instances are placed in a secure, isolated network zone, accessible only by specific, authorized application servers.
• Establish a process to build and maintain hardened container base images for critical services like Redis. Ensure these images are compiled with all modern security features enabled, such as full RELRO (Relocation Read-Only).