🛡️ CISO Intel — Wednesday, 20-05-2026
By Marcus Reed | 19-05-2026 08:00 IST → 20-05-2026 08:00 IST | Sources cross-referenced
Executive Summary
Today’s intelligence paints a stark picture: AI is no longer a theoretical offensive tool; it’s actively generating zero-days and accelerating vulnerability discovery, as evidenced by the NGINX and 2FA bypass exploits. This, coupled with the relentless and increasingly sophisticated ransomware campaigns targeting critical sectors and, more alarmingly, your backups, means defenders are in a race against machine-speed adversaries. The single most important takeaway is that our traditional “patch and pray” approach is insufficient. We need to shift to proactive verification of our recovery postures and assume our most critical defenses will be directly attacked.
🔴 Critical Threats — Act Now 🚨
ScadaBR — Unauthenticated RCE in OT Environments
What happened: CISA issued an advisory on May 19, 2026, warning about four critical vulnerabilities in ScadaBR 1.2.0 that can be chained together to achieve unauthenticated remote code execution (RCE). The vulnerabilities are tracked as CVE-2026-8602, CVE-2026-8603, CVE-2026-8604, and CVE-2026-8605. This open-source SCADA platform is widely used globally in critical infrastructure sectors such as critical manufacturing, dams, chemical, energy, and water/wastewater systems.
Source verification: This information is confirmed by a CISA industrial control systems advisory published on May 19, 2026. SecurityWeek also reported on the CISA warning, detailing the specific CVEs and their impact on OT environments. Previous ScadaBR vulnerabilities, like CVE-2021-26828 and CVE-2021-26829, have been added to CISA’s Known Exploited Vulnerabilities catalog, indicating a history of active exploitation in this software.
Technical breakdown: The CISA advisory describes the four vulnerabilities as:
CVE-2026-8602: Missing authentication for a critical function.CVE-2026-8603: OS command injection.CVE-2026-8604: Cross-site request forgery (CSRF).CVE-2026-8605: Hard-coded credentials.
While the exact chaining mechanism for RCE isn’t fully public, the combination of missing authentication, hard-coded credentials, and OS command injection is a classic recipe for disaster. An attacker could bypass initial authentication, leverage hard-coded credentials to gain a foothold, and then use command injection to execute arbitrary code on the underlying system. The CVSS v3 score assigned by the vendor is 9.1, confirming its critical severity. This attack would likely map to MITRE ATT&CK techniques such as T1078.001 (Valid Accounts: Default Accounts), T1210 (Exploitation of Remote Services), and T1059.004 (Command and Scripting Interpreter: Tcl) or similar for OS command execution.
Blast radius: The primary concern here is the deployment context. ScadaBR, being a browser-accessed SCADA system, often sits on networks that blur the lines between IT and OT. If these systems are internet-facing, or on flat internal networks without proper segmentation, the blast radius is enormous. The affected software is present in environments where disruption can lead to real-world physical consequences, from manufacturing shutdowns to impacts on essential services like water and energy. While CISA states no known public exploitation specifically targeting these new CVEs at the time of the advisory, the ease of understanding these weakness classes (e.g., “command injection”) means opportunistic scanning and exploitation can follow quickly.
Marcus’s verdict:
This isn’t just another bug report; it’s a flashing red light for OT security. The fact that ScadaBR is an open-source, Java-based system often deployed in critical infrastructure means it’s a prime target for attackers looking for a low-cost entry point into high-value environments. The “unauthenticated RCE” part is the headline, but the underlying issue is systemic exposure. If your ScadaBR instance is on the internet or a flat network, you’ve already lost the battle. Patching, when available, is necessary, but the real fix is architectural. This is a wake-up call to re-evaluate your OT network segmentation and internet exposure, not just for ScadaBR, but for all your industrial control systems.
What to do:
- Immediate Network Review: Identify all ScadaBR 1.2.0 instances within your environment. Prioritize those with any direct or indirect internet exposure.
- Isolate & Segment: Implement strict network segmentation to isolate ScadaBR systems from both the internet and corporate IT networks. Use firewalls to restrict communication to only essential services and trusted sources.
- Minimize Exposure: If internet access is not absolutely critical, remove it. For necessary remote access, enforce multi-factor authentication (MFA) and use secure VPNs or jump boxes.
- Audit Credentials: Review and change any default or hard-coded credentials immediately. Implement a robust credential management policy.
- Monitor & Alert: Deploy intrusion detection/prevention systems (IDS/IPS) to monitor traffic to and from ScadaBR instances for anomalous activity, especially related to web requests and command execution.
- Prepare for Patch: While no direct patch is mentioned yet, monitor vendor and CISA advisories for updates and apply them immediately upon release.
Windows MiniPlasma — SYSTEM Privilege Escalation Zero-Day 💥
What happened: A security researcher, Chaotic Eclipse (also known as Nightmare-Eclipse), has released a Proof-of-Concept (PoC) exploit, dubbed MiniPlasma, for a Windows zero-day vulnerability. This exploit grants SYSTEM privileges on fully patched Windows 11 systems. Alarmingly, this is effectively a re-exploitation of a 2020 flaw, CVE-2020-17103, which Microsoft claimed to have fixed.
Source verification: This is widely reported by multiple reputable security news outlets including The Hacker News, Dark Reading, SecurityWeek, and others. The researcher, Chaotic Eclipse, has publicly released the PoC. Will Dormann, a well-known security researcher, confirmed MiniPlasma works reliably on Windows 11 systems with the latest May 2026 updates.
Technical breakdown: MiniPlasma targets the cldflt.sys (Windows Cloud Files Mini Filter Driver), specifically within the HsmOsBlockPlaceholderAccess routine. The original vulnerability, CVE-2020-17103, was an elevation-of-privilege flaw reported by Google Project Zero’s James Forshaw in September 2020 and supposedly patched in December 2020. Chaotic Eclipse’s investigation revealed that “the exact same issue… is actually still present, unpatched.” The researcher weaponized Forshaw’s original PoC to spawn a SYSTEM shell, demonstrating that the fix either failed or was silently rolled back. The exploit is a local privilege escalation (LPE) and works reliably on current Windows 11 builds, but not on the latest Insider Preview Canary build, suggesting Microsoft might be aware and working on a fix for future releases. This attack maps directly to MITRE ATT&CK technique T1068 (Exploitation for Privilege Escalation).
Blast radius: This is a significant zero-day. Any attacker who gains initial low-level access to a Windows 11 system (e.g., via phishing, malware, or another vulnerability) can use MiniPlasma to escalate to SYSTEM privileges. This grants them full control over the compromised machine, enabling them to disable security software, install persistent backdoors, access sensitive data, or move laterally within the network. The fact that it works on fully patched systems means there’s no immediate software fix available to most users. All Windows versions are likely affected, though current testing confirms Windows 11.
Marcus’s verdict:
This is exactly why I preach defense-in-depth and assume breach. Microsoft claiming a fix for a 2020 flaw, only for it to resurface as a zero-day on fully patched systems, is a brutal reminder that patches aren’t always complete, and sometimes, they just plain fail. The researcher, Chaotic Eclipse, has been on a tear, dropping multiple Windows zero-days. While some might argue about responsible disclosure, the reality is the cat’s out of the bag. If you’re running Windows 11, assume any local attacker can get SYSTEM. This isn’t theoretical; it’s actively exploitable.
What to do:
- Endpoint Detection & Response (EDR): Ensure your EDR solutions are configured to detect and alert on suspicious process creation, driver loading, and privilege escalation attempts, especially those involving
cldflt.sysor attempts to spawn SYSTEM shells. - Least Privilege: Re-emphasize and enforce the principle of least privilege for all users and applications. Minimize the attack surface by limiting what even a compromised low-privilege account can do.
- Application Whitelisting: Implement application whitelisting where possible to prevent unauthorized executables, including PoC exploits, from running.
- Monitor for Microsoft Advisory: Keep a close eye on Microsoft’s official security advisories for an emergency patch. The next scheduled Patch Tuesday is June 10, 2026, but an out-of-band fix might be necessary given the severity.
- Insider Preview Canary Build: While not a production solution, note that the exploit does not work on the latest Insider Preview Canary build. This suggests a fix is in the pipeline, but production systems remain vulnerable.
NGINX CVE-2026-42945 — 18-Year-Old Buffer Overflow Found by AI 🤖
What happened: A critical buffer overflow vulnerability, CVE-2026-42945 (CVSS 9.2), has been discovered in NGINX, affecting versions 0.6.27 through 1.30.0 of NGINX Open Source and NGINX Plus vR32 through R36. This flaw, present for 18 years, was unearthed by Depthfirst researchers using AI tools. It allows unauthenticated remote code execution (RCE) or denial-of-service (DoS) under specific, though uncommon, rewrite and set directive configurations.
Source verification: This vulnerability is confirmed by multiple sources, including Help Net Security, Axonius, AlmaLinux OS, NVD, and Red Hat. F5, the company behind NGINX, has released fixes and a security advisory. Depthfirst researchers, who discovered the flaw, have published technical details and a PoC exploit. VulnCheck’s canary systems began flagging exploitation attempts on May 16, indicating active exploitation.
Technical breakdown: The vulnerability, dubbed “NGINX Rift,” is a heap-based buffer overflow in NGINX’s ngx_http_rewrite_module. The specific trigger is a common configuration pattern: a rewrite directive that uses an unnamed PCRE capture (e.g., $1, $2) in the replacement string, where that string also contains a question mark (?), and is then followed by another rewrite, if, or set directive in the same context.
When this pattern is present, NGINX calculates the destination buffer size using one set of escaping assumptions but then writes to it using another, causing the write to go past the allocated buffer. The corrupted bytes are derived from the attacker’s URI, allowing for deterministic memory corruption. This can lead to a worker process crash (DoS) or, if Address Space Layout Randomization (ASLR) is disabled, remote code execution. A single crafted HTTP request can trigger the overflow. This maps to MITRE ATT&CK techniques such as T1190 (Exploit Public-Facing Application) for initial access and T1068 (Exploitation for Privilege Escalation) or T1499 (Endpoint Denial of Service) depending on the outcome.
Blast radius: NGINX is the most popular web server globally, serving as a reverse proxy, load balancer, and web server at the network edge. This makes the vulnerability highly exposed. While the specific rewrite configuration required is “uncommon,” it’s not rare, and the 18-year lifespan means many legacy configurations could be vulnerable. The impact extends to F5 products incorporating NGINX, such as NGINX Ingress Controller and F5 WAF for NGINX. Active exploitation attempts have already been observed.
Marcus’s verdict:
Eighteen years. Let that sink in. This isn’t some esoteric corner case; it’s a fundamental memory safety issue in a widely deployed piece of infrastructure that has been lurking for nearly two decades. The fact that AI tools found it is both impressive and terrifying. It confirms my long-held belief that our existing security paradigms are fundamentally flawed when it comes to finding deep-seated bugs at scale. This isn’t just a patch-and-move-on situation; it’s a prompt to question what else is hiding in plain sight in critical software, waiting for an AI to unearth it. The CVSS 9.2 is well-deserved, and the RCE potential, even with ASLR, is a nightmare.
What to do:
- Patch Immediately: Update NGINX Open Source to version 1.30.1/1.31.0 or later, and NGINX Plus to R37 or later. AlmaLinux has already released patches.
- Configuration Review: If immediate patching is not possible, audit your NGINX configurations for the vulnerable pattern: a
rewritedirective using unnamed PCRE captures ($1,$2, etc.) in a replacement string containing a?, followed by anotherrewrite,if, orsetdirective in the same context. - Apply Mitigation: If the vulnerable pattern is found and patching is delayed, modify the configuration to remove the problematic pattern.
- WAF/IPS Rules: Implement Web Application Firewall (WAF) or Intrusion Prevention System (IPS) rules to detect and block crafted HTTP requests targeting this vulnerability.
- Monitor for Exploitation: Actively monitor NGINX access logs for unusual URI patterns or repeated worker process crashes.
Drupal — Highly Critical Emergency Patch 🚨
What happened: Drupal is preparing an emergency patch for a “highly critical” vulnerability, with patches expected today, May 20, 2026, between 17:00 and 21:00 UTC. The Drupal Security Team has issued a strong warning, advising users to reserve time for immediate updates as exploits are expected to be weaponized quickly, possibly within hours or days of disclosure.
Source verification: This is confirmed by official Drupal security advisories (PSA-2026-05-18) and widely reported by SecurityWeek, The Hacker News, and other security news outlets. The severity is underscored by Drupal’s unusual step of providing patches for end-of-life minor core versions due to the issue’s criticality.
Technical breakdown: The exact nature of the vulnerability is not yet disclosed, which is standard practice for coordinated vulnerability releases to prevent pre-patch exploitation. However, the “highly critical” designation and the urgent warning suggest a severe flaw, likely allowing for remote code execution, SQL injection, or a critical authentication bypass. Drupal’s past “Drupalgeddon” vulnerabilities (e.g., in 2019) were RCE flaws that led to widespread site compromises. The patches will be released for Drupal versions 11.3.x, 11.2.x, 10.6.x, and 10.5.x. Additionally, “best-effort” patches will be provided for end-of-life minor versions like 11.1.x and 10.4.x, and even manual patch files for Drupal 8.9 and 9.5, though with warnings about potential issues. Drupal 7 is not affected.
Blast radius: Drupal powers hundreds of thousands of websites, including government sites, universities, media organizations, and enterprise portals. A highly critical core vulnerability could expose a significant portion of the web to rapid exploitation. The Drupal Security Team’s explicit warning about quick weaponization means that any delay in patching will put sites at extreme risk.
Marcus’s verdict:
When the Drupal Security Team tells you to “reserve time” for an emergency patch, you listen. This isn’t a drill. The fact that they’re going to the trouble of issuing best-effort patches for end-of-life versions tells you how bad this is. This is a potential “Drupalgeddon” in the making. If your team isn’t already scheduling this, you’re behind. The window between disclosure and active exploitation will be measured in hours, not days. Get ready to update.
What to do:
- Prepare for Update: Immediately update your Drupal site to the latest patch release for your current supported branch (e.g., 11.3.x, 11.2.x, 10.6.x, 10.5.x) before the security window. This ensures any pre-existing upgrade issues are resolved.
- Schedule Downtime/Maintenance Window: Clear your schedule between 17:00 and 21:00 UTC today, May 20, 2026, to apply the security patch as soon as it’s released.
- Monitor Drupal.org: Keep a constant watch on Drupal.org’s security advisories for the official release, detailed information on the vulnerability, and specific mitigation steps.
- Backup: Ensure you have recent, verified backups of your Drupal sites before applying any updates.
- Older Versions: If you are on end-of-life Drupal 8 or 9, treat this as an urgent signal to plan a full upgrade to a supported version (e.g., Drupal 10.6 or 11.3) as soon as possible. While manual patches may be offered, they are not a long-term solution.
🛡️ CVEs — Full Analysis
CVE-2026-0300 — Palo Alto Networks PAN-OS (affecting Siemens RUGGEDCOM APE1808)
Summary: This is a critical vulnerability allowing unauthenticated root-level code execution on affected OT edge devices. CISA has issued an advisory, implying its severity and potential for real-world impact in industrial environments. CVSS/Details: Details pending, but the “unauthenticated root-level code execution” description implies a CVSS score likely in the 9.x-10.0 range. CISA’s involvement suggests it’s a serious threat to critical infrastructure. No public PoC yet, but CISA advisories often precede or accompany private exploitation. Marcus take: This is another OT nightmare. Unauthenticated root RCE on edge devices means an attacker can own the box and potentially pivot deeper into the OT network. The combination of Palo Alto (network security) and Siemens RUGGEDCOM (industrial hardware) makes this a potent cocktail. Don’t wait for a public PoC; assume it exists and act on CISA’s warning.
AV26-477 — HPE Unified OSS Console (UOC) v3.1.20 and prior
Summary: Multiple critical vulnerabilities in HPE Unified OSS Console (UOC) v3.1.20 and prior versions could lead to potential system compromise. HPE has released an advisory and a patch. CVSS/Details: Critical (details pending). HPE published a security advisory (AV26-477) and a solid fix. Specific CVEs and CVSS scores are not yet public, but the “critical” designation means high impact. Marcus take: HPE is a major player in enterprise IT. “Multiple vulnerabilities allowing potential compromise” is vague but usually means a mix of authentication bypass, injection, or logic flaws. The key is that HPE has a fix, so there’s no excuse for not patching. Prioritize this, especially if UOC manages critical network or service operations.
⚡ TTPs & Attack Research — Deep Dives
AMD Infinity Fabric ‘Fabricked’ Attack (CVE-2025-54510) 🧠
What happened: Researchers at ETH Zurich discovered “Fabricked,” a software-only vulnerability in AMD EPYC processors that completely bypasses SEV-SNP confidential computing protections. This attack allows a malicious cloud host to gain full read/write access to protected virtual machine (VM) memory and forge attestation reports, effectively undermining the core promise of confidential computing. The flaw affects Zen 3, Zen 4, and Zen 5 architectures.
Source verification: This research is confirmed by reports from Tom’s Hardware and other security outlets, citing ETH Zurich’s work. AMD acknowledged the vulnerability (CVE-2025-54510) after responsible disclosure in August 2025 and published security guidance (AMD-SB-3034) when the embargo lifted in April 2026. Firmware updates have been released.
Technical breakdown: Confidential computing relies on hardware-level memory encryption and integrity protection (like AMD SEV-SNP) to shield VMs from the underlying cloud infrastructure. The “Fabricked” attack exploits flaws in how the CPU’s Infinity Fabric interconnect handles memory routing during the boot process.
The attack involves two main steps:
- UEFI Bypass: A malicious UEFI can skip crucial integrity checks during boot, leaving the Data Fabric (memory routing layer within Infinity Fabric) writable by the attacker even after SEV-SNP is active.
- MMIO Shadowing: The researchers found that Platform Security Processor (PSP) memory requests were incorrectly checked against MMIO (Memory-Mapped I/O) routing rules before standard DRAM routing rules. By configuring MMIO mappings to shadow the RMP (Real-time Memory Protection) memory region, the attacker causes the PSP’s initialization writes to be silently discarded.
This combination allows the malicious cloud host to gain read/write access to supposedly protected VM memory and, crucially, forge the cryptographic attestation reports that tenants use to verify their environment’s integrity.
MITRE ATT&CK Mapping:
- T1552.006 (Credentials in Files: Memory): Gaining read/write access to VM memory allows for exfiltration of sensitive data, including credentials.
- T1552.007 (Credentials in Files: Kernel Memory): Direct access to VM memory can expose kernel-level secrets.
- T1552.004 (Credentials in Files: Private Keys): Private keys or other secrets stored in memory could be exfiltrated.
- T1552.001 (Credentials in Files): Generic access to data within the VM.
- T1550.002 (Use Alternate Authentication Material: Pass the Hash): If credentials are extracted, they could be used for lateral movement.
- T1550.003 (Use Alternate Authentication Material: Pass the Ticket): Similar to pass-the-hash, but for Kerberos tickets.
- T1562.001 (Impair Defenses: Disable or Modify Tools): By forging attestation reports, the attacker can hide their presence and tampering from the tenant.
Detection Opportunities:
- Attestation Verification: While the attack forges attestation reports, any discrepancies or failures in the attestation process should be immediately investigated.
- Hypervisor Monitoring: Enhanced logging and integrity checks on the hypervisor/cloud host side, though this is difficult if the host itself is malicious.
- VM-level Integrity Checks: Within the VM