> Blog_

CISA added two new entries to the Known Exploited Vulnerabilities catalog on July 22, and neither is trivial. CVE-2026-16232 is an improper authentication vulnerability in Check Point SmartConsole, while CVE-2026-50522 covers deserialization of untrusted data in Microsoft SharePoint. CISA does not assign KEV status without confirmed exploitation in the wild, so these are not theoretical risks.

The Check Point entry is particularly concerning because SmartConsole is the management plane for firewall policies and security gateways. An authentication bypass on the console itself puts the integrity of the entire security control set at risk. Attackers hitting this are likely after policy definitions, VPN configurations, or the credentials that govern perimeter trust boundaries.

SharePoint deserialization is a familiar story, but that does not make it less urgent. Deserialization flaws in collaboration platforms typically translate to remote code execution, and SharePoint remains a high-value target because it is internet-facing, data-rich, and deeply tied to identity stores. The fact that it is back in KEV suggests exploitation is ongoing and patch velocity is not keeping up.

What makes this drop notable is the accompanying BOD 26-04 guidance. CISA is now requiring federal agencies to treat KEV-listed vulnerabilities that grant total control as active incident triggers, not just patch-queue items. The directive explicitly expects agencies to verify whether an asset was compromised before the patch was applied. That is a formal acknowledgment that exploitation windows regularly beat remediation windows.

Practical takeaway: If you run Check Point, verify that SmartConsole is not exposed to untrusted networks and gate access through a hardened jump host. If you run SharePoint, prioritize the update and review application logs for anomalous worker process behavior or unexpected assembly loads. Most importantly, do not treat the patch as the finish line. Run a focused hunt on both stacks for pre-patch activity, because BOD 26-04 is reflecting a reality that applies well beyond the federal enterprise.

CISA added four new entries to the Known Exploited Vulnerabilities catalog this week, and three of them are fresh 2026 CVEs already being actively exploited. The list is CVE-2021-27137, a stack-based buffer overflow in DD-WRT; CVE-2026-0770 in Langflow; and two WordPress Core bugs, CVE-2026-63030 and CVE-2026-60137. I find the mix telling: attackers are hitting aging edge firmware, AI tooling, and the world's most ubiquitous CMS with equal enthusiasm.

The two WordPress Core flaws stand out because the platform is usually attacked through plugins or themes, not the core engine itself. CVE-2026-60137 is an SQL injection, and CVE-2026-63030 is listed as an interpretation conflict vulnerability. Both suggest serious bugs in the core parser or database layer, which means every standard WordPress install is in scope regardless of how carefully you vet third-party add-ons.

CVE-2026-0770 in Langflow worries me from an emerging-attack-surface perspective. The description, inclusion of functionality from an untrusted control sphere, points to the application pulling in or executing code from an untrusted source. Langflow is widely used to prototype and run LLM workflows, and instances often end up network-reachable by data-science teams. If that gives an attacker code execution inside an AI pipeline, it is a short hop to model poisoning or lateral movement into the vector database.

Then there is CVE-2021-27137 in DD-WRT, a 2021 stack overflow that is still being actively exploited four years later. That is a reminder that SOHO and branch-office router firmware rarely gets the same hygiene attention as enterprise endpoints, yet it sits at the edge of the trust boundary. A buffer overflow in router firmware is exactly the kind of total-control flaw that makes for a persistent beachhead.

The advisory also serves as a reminder of Binding Operational Directive 26-04, which requires federal agencies to prioritize rapid remediation of high-risk KEVs on publicly exposed assets that grant total control post-exploitation, while allowing lower-risk items to wait. Even if you are not FCEB, that tiering is a sensible model. A SQL injection in WordPress core or a buffer overflow in edge firmware should not sit in your backlog behind a low-risk information disclosure.

Practical takeaway: this week, identify any internet-facing WordPress instances and verify they are on the latest core release. Hunt for Langflow deployments in your environment, especially any that are publicly reachable or running in shared internal namespaces, and treat them as critical code-execution surface until patched. Finally, audit your remote-office and WFH router inventory for DD-WRT or similar consumer-grade firmware and get it off the public internet or patched immediately. If you are still running unpatched 2021 router firmware in 2026, that is the Monday morning conversation.

CISA dropped CVE-2026-58644 into its Known Exploited Vulnerabilities catalog this week, and the binding operational directive gives Federal Civilian Executive Branch agencies until July 19 to patch. That is essentially a weekend deadline. The vulnerability carries a CVSS score of 9.8 and affects Microsoft SharePoint Server, where a deserialization flaw can lead to remote code execution. I do not see CISA handing out 48-hour patch windows for routine bugs; that timeline tells me they are seeing active exploitation at volume against government-facing or internet-accessible instances.

This is on-prem SharePoint Server, not SharePoint Online. That distinction matters because the remaining on-prem farms I run into are often legacy systems with custom workflows, orphaned under application teams who patch on quarterly cycles, or buried in subnets that security assumes are internal. A deserialization RCE in SharePoint is especially nasty because the platform runs with high privileges, sits close to sensitive documents and identity infrastructure, and is frequently reachable from the corporate network or VPN pools. If an attacker can deserialize objects, they can likely pivot straight into the content database or adjacent file servers.

I am tired of this recurring pattern. SharePoint Server has been a reliable source of critical deserialization and authentication bypass flaws for years, yet it remains installed in environments that treat it as a business-critical application with infrastructure-level risk but application-level patch discipline. The July 19 deadline is CISA forcing the issue, but private sector teams should not wait for a BOD to tell them what a 9.8 RCE under active exploitation means. If your vulnerability management program still gates SharePoint patches behind a monthly change board, that process just broke.

Practical takeaway: find every SharePoint Server instance in your environment today, verify its patch level against the July 2026 cumulative update, and treat any system that cannot be patched by Monday as compromised. If patching immediately is impossible, pull it off the public internet, restrict access to a jump host, and block external SharePoint traffic at the perimeter. Then check your WAF and proxy logs for anomalous POST requests to SharePoint endpoints and any unexpected process spawning under the SharePoint application pool. If you are not sure who owns the last on-prem SharePoint farm in your org, that is the person I would call first thing Saturday morning.

CISA's ICS team published ICSA-26-197-04 this week targeting AutomationDirect Productivity Suite, and it highlights a pattern I keep seeing in critical manufacturing environments: engineering workstations treated as low-risk endpoints despite sitting at the intersection of IT and OT. The advisory bundles six CVEs affecting versions 4.6.2.2 and earlier, all requiring local or physical access but carrying a CVSS 7.0 score that reflects serious impact once that barrier is crossed.

The standout is CVE-2026-60063, an out-of-bounds write reachable through a crafted IOCTL request to the software's kernel component. Successful exploitation corrupts kernel memory and yields privilege escalation or system instability. The other five, including CVE-2026-61389 and CVE-2026-60140, cover additional out-of-bounds reads, writes, and divide-by-zero conditions that can trigger denial-of-service or unintended information disclosure from the same local attack surface.

Local access sounds like a lower bar until you remember how engineering workstations are actually run on the plant floor. They are shared among shifts, loaded with USB drives for firmware updates, rarely patched on cycle because of project-file compatibility fears, and often exempt from standard endpoint hardening under the assumption that the air gap or network segmentation handles the rest. Once an attacker has even a basic foothold here, they do not need a slick remote exploit to pivot into the control network; they just need SYSTEM privileges to modify ladder logic or project files before they are pushed to the PLC.

AutomationDirect gear is deployed worldwide in critical manufacturing, so the blast radius is real even if the initial access vector is constrained. The vendor has released an updated version, and CISA is urging users to upgrade past 4.6.2.2 immediately rather than waiting for the next scheduled maintenance window.

Practical takeaway: if you are running Productivity Suite in your plant, patch this week. Restrict local access to engineering workstations to named technicians only, disable autorun, enforce application whitelisting, and audit USB usage. If you cannot baseline what processes should be touching kernel-level IOCTLs on those boxes, or you do not have separate alerting on engineering host privilege escalation, that is your Monday morning project.

CISA added two CVSS-10.0 vulnerabilities to its Known Exploited Vulnerabilities catalog this week, and both target third-party extensions for Joomla. The flaws affect iCagenda, an events and calendar component, and Balbooa Forms, a form builder plugin. According to the reporting, attackers are already exploiting them as zero-days in the wild, using arbitrary file uploads to drop web shells and achieve remote code execution on victim hosts.

One of the two flaws is tracked as CVE-2026-48939. The second vulnerability was also added to the KEV catalog alongside it. Both sit at the top of the severity scale with CVSS scores of 10.0, which typically indicates network exploitation with low complexity and no required privileges. For a Joomla site running either extension, that means a routine interaction with the calendar or form component can become a full server compromise.

What stands out here is the target surface. Joomla does not get the same security press as WordPress, but it still powers a massive long tail of small-business sites, local government portals, and community organizations. Extensions like iCagenda and Balbooa Forms are commercial add-ons with broad install bases, which makes them attractive supply-chain targets. A single vulnerable plugin can compromise hundreds of sites that otherwise keep their core CMS patched.

The TTP is as old as it is effective: abuse a file upload feature to bypass extension filtering, write a PHP web shell to a reachable directory, and pivot from there. Because these are zero-days, there is no patch history to review; defenders are starting from the moment CISA published the KEV entries. If your organization runs Joomla, you need to know exactly which extensions are installed, whether they are actively used, and who is responsible for updating them.

Practical takeaway: if you manage a Joomla property, inventory your extensions today and remove iCagenda and Balbooa Forms if they are not business-critical. If they are required, pull them offline until a patched version is released and validated. Check your web root and temp directories for unexpected PHP files, review access logs for POST requests to upload handlers, and enforce application-level file-upload restrictions at your reverse proxy or WAF. If you cannot name every Joomla extension running in your environment, that is your first task this week.

CISA, NSA, FBI and international partners released AA26-194A this week, and it reads like a decade-overdue maintenance ticket for the internet's edge. The advisory targets Russian FSB Center 16 cyber actors, who are still systematically compromising poorly configured and vulnerable networking devices across critical infrastructure networks worldwide. This is not a new campaign; the agencies frame it as an evolution of the same FSB router-targeting activity that has been ongoing for over ten years.

What stands out is the sheer opportunism of it. Center 16 is not burning zero-days on perimeter hardware. They are scanning for unpatched firmware, default credentials, exposed management interfaces, and enabled remote-access services that should have been locked down years ago. Once inside edge routers, firewalls, or VPN concentrators, they establish persistence and use that foothold to move laterally into operational networks. The victim set spans multiple critical sectors, which tells me they are not picky; they are collecting access wherever the door is already open.

The joint nature of this CSA is worth noting. When CISA co-seals with NSA, FBI, DC3, ASD's ACSC, and CSE's Cyber Centre, the message is as much about geopolitical coordination as technical warning. But operationally, the TTPs remain stubbornly basic: exploit known CVEs, abuse weak or default configs, and live off the device. It is effective because router and firewall hygiene is still an afterthought in too many environments, especially where OT networks meet IT edge gear.

If you have not audited your edge network infrastructure in the last quarter, that is your Monday project. Disable remote administration on internet-facing interfaces unless you have a specific, monitored need for it. Patch your routers, firewalls, and VPN appliances against known disclosed vulnerabilities before you worry about next week's zero-day. Enforce MFA on every admin panel, remove default accounts, and segment critical infrastructure networks so a compromised edge device cannot pivot straight into SCADA or business systems. The FSB has been playing this game for a decade; closing these gaps is table stakes.

CISA added three vulnerabilities to its Known Exploited Vulnerabilities catalog this week, and the combination caught my attention. Two are OS command injection flaws in Fortinet FortiSandbox, and the third is a Microsoft SharePoint deserialization bug. All three carry the KEV label because CISA has confirmed active exploitation in the wild, which means threat actors are already weaponizing them against production networks.

The FortiSandbox pair - CVE-2026-25089 and CVE-2026-39808 - stand out to me. FortiSandbox is a security appliance designed to detonate malware in isolation, not to host attacker shells. OS command injection here does not just mean compromise of a single box; it means the tool you rely on to judge file safety can be turned into a beachhead. An attacker with code execution on a sandbox can suppress detection artifacts, poison analysis results, or pivot into adjacent network segments that trust the appliance.

CVE-2026-58644 in SharePoint is the other side of the same coin. Deserialization of untrusted data against a collaboration platform is a proven path to remote code execution and total system control. When SharePoint sits on the public internet - and plenty still does - this becomes an initial access vector that does not require phishing or stolen credentials. It is exactly the kind of vulnerability I expect to see used for walking straight into an enterprise from a browser session.

CISA's inclusion of these flaws under BOD 26-04 is telling. The directive requires federal agencies to rapidly remediate KEV entries that grant total control of publicly exposed assets, while deprioritizing lower-risk issues. I read that as a clear signal: these are not theoretical bugs, and they are not low-impact configuration quirks. They are total-control vulnerabilities on high-trust systems that process untrusted data daily.

Practical takeaway: if you run FortiSandbox, patch both CVEs immediately and hunt for signs of prior exploitation, including unexpected shell execution or modified analysis policies. If you manage SharePoint with any external reach, treat CVE-2026-58644 as a drop-everything patch and restrict access until you can remediate. I would start Monday by verifying whether any of these three assets are reachable from outside your perimeter, because exposure time is what separates a near-miss from an incident.

CISA added two new entries to the Known Exploited Vulnerabilities catalog this week, and the pairing tells a story. CVE-2023-4346 is a connection authorization flaw in the KNX protocol used for building automation and control, while CVE-2026-46817 is an improper privilege management vulnerability in Oracle E-Business Suite. One targets the edge of OT, the other the heart of enterprise ERP, and both are being actively exploited.

The KNX entry is the one that stands out operationally. KNX runs lighting, HVAC, and physical access systems, and it is often bridged onto the corporate network with minimal segmentation and almost no logging. The vulnerability sits in the Connection Authorization Option 1 mechanism, which suggests attackers are bypassing or weakening authentication to get onto the KNX bus. From there, they can manipulate environmental controls, disable safety systems, or pivot into adjacent IT infrastructure. Building automation has been treated as a low-priority network for years; a KEV designation means that approach is now a liability.

CVE-2026-46817 is more familiar territory. Oracle E-Business Suite privilege management flaws typically let authenticated users escalate to administrative or application-level access, which in an ERP environment means ledger manipulation, payroll exposure, or supply chain disruption. BOD 26-04 makes it explicit: FCEB agencies must prioritize patches for high-risk KEVs on publicly exposed assets that grant total control post-exploitation. Deferral is no longer an option.

What links these two is the exploitation evidence. CISA does not add vulnerabilities to KEV on speculation. The KNX flaw is particularly notable because ICS-adjacent building protocols rarely appear in KEV alongside enterprise software. It signals that threat actors are probing the seams between IT and OT, hitting the infrastructure that security teams forget to patch because it does not look like a standard server.

Practical takeaway: if you manage facilities or building automation, treat KNX like OT this week. Segment KNXnet/IP gateways from the corporate LAN, audit who can reach your building controllers, and verify that facilities teams are not reusing credentials across sites. For Oracle EBS, restrict administrative interfaces from the internet, validate your privilege model, and apply the July patches if you have not already. Monday morning project: pull your network diagram and highlight every BMS subnet that touches both the boiler room and the corporate Wi-Fi. If you find one, you have found your gap.

CISA added four new entries to the Known Exploited Vulnerabilities catalog on Tuesday, and the lineup reads like an attacker's wish list: two SonicWall SMA1000 appliance flaws, a Microsoft SharePoint Server authentication bypass, and an Active Directory Federation Services access control issue. All four are confirmed in the wild, and CISA made it clear that under Binding Operational Directive 26-04, federal agencies must treat these as high-risk priorities because they grant total control of the asset after exploitation.

The SonicWall pair is particularly ugly. CVE-2026-15409 is a server-side request forgery and CVE-2026-15410 is a code injection vulnerability, both hitting SMA1000 appliances. These devices sit on the perimeter by design, so an SSRF combined with code injection gives an attacker a straight path to abuse the trust placed in a VPN concentrator. I have seen this pattern with other SSL VPN stacks: the appliance is internet-facing, the patch rate is slow, and the exploit chain ends with internal network access.

The Microsoft side is just as active. CVE-2026-56164, a missing authentication flaw in SharePoint Server, is already being chained into remote code execution, IIS machine key theft, and deserialization attacks for persistence and malware deployment according to a parallel CISA alert. CVE-2026-56155 in ADFS is an insufficient granularity of access control vulnerability, which in practice can weaken the identity boundary that SharePoint and other federated apps rely on. Hitting collaboration and identity infrastructure at the same time is a reliable way to expand access without ever needing a zero-day.

What stands out here is the BOD 26-04 framing. CISA is explicitly calling out that these CVEs are on publicly exposed assets and deliver total control post-exploitation. That is bureaucratese for "patch this weekend, not next quarter." The directive forces federal civilian agencies to prioritize rapid remediation, but the same logic applies to every enterprise running on-premises SharePoint or exposing SMA1000 to the internet.

Practical takeaway: if you run SonicWall SMA1000, patch both CVEs immediately, lock down management interfaces to internal jump hosts only, and monitor appliance egress for unexpected outbound connections. If you run on-premises SharePoint, apply Microsoft's July updates, verify the install actually completed, and hunt for web shells or abnormal w3wp.exe behavior. While you are at it, audit your ADFS access policies and token-signing certificate protections, because identity is the next domino to fall once SharePoint is compromised.

CISA added CVE-2008-4128 to the Known Exploited Vulnerabilities catalog this week, and the date is not a typo. This is an 18-year-old cross-site request forgery flaw in Cisco IOS that is now actively exploited in the wild. If you are still running edge routers with the web-based management interface exposed, an attacker can trick an authenticated administrator's browser into forging requests that reconfigure the device or seed persistent access.

The advisory ties the bug to BOD 26-04, which means CISA views it as a high-risk vulnerability on publicly exposed assets that grants total control post-exploitation. Federal agencies are required to patch urgently, but the directive also tells them to check for compromise before applying the fix. That pre-patch forensics requirement is a signal that CISA is seeing follow-on activity, not just opportunistic scanning.

From a TTP standpoint, this is not advanced tradecraft. CSRF is a basic web attack, and Cisco IOS web admin has been a known weak point for decades. The real failure mode here is asset management: edge routers that have been humming along since the late 2000s, management interfaces accidentally exposed to the internet, and a security model that assumed obscurity would hold. If the HTTP or HTTPS admin plane is reachable from an untrusted browser, the attack surface is trivial to exploit.

CISA's alert does not name the actor behind the current wave, and the public advisory is light on exploitation details beyond the CVE itself. But the KEV addition itself is the evidence; CISA does not catalog without incident data. The takeaway is that age of a vulnerability does not equal lack of risk. A CVE from 2008 can be just as damaging as a zero-day if the underlying exposure never got fixed.

This week, inventory every Cisco device in your environment with a web admin listener. If it faces the internet, disable the HTTP server entirely and move management to an out-of-band jump host with strong authentication. Before you patch, audit the running config for unauthorized local accounts, unexpected ACL changes, or altered boot variables, because BOD 26-04 expects you to prove the box was not already owned. If your vulnerability program prioritizes CVSS over exposure, this is the case that breaks that model.

CISA published ICSA-26-188-01 this week on Hydro-Québec's Le Circuit Electrique charging station backend, and it is a stark reminder that transportation critical infrastructure now includes the APIs behind the EV stations we drive past daily. CVE-2026-20744 clocks in at CVSS 9.8 because the backend websocket endpoint accepts connections without proper authentication, allowing an unprivileged attacker to escalate privileges and manipulate charging station operations.

The advisory does not stop at missing auth. It also calls out improper access control, no brute-force protection on excessive authentication attempts, and insufficient session expiration. In other words, if you can reach the websocket, you can likely stay there indefinitely. The affected backend versions are anything prior to the June 2026 release, which covers a broad fleet deployed across Canada.

This is the kind of exposure that happens when operational technology gets internet-facing APIs without going through the same rigor as enterprise web applications. EV charging networks rely on protocols like OCPP to communicate between stations and the central backend, and when that communication plane is exposed with weak or missing session controls, the result is a 9.8-severity vulnerability in the transportation sector. Hydro-Québec reports updating the majority of charging stations, and the advisory lists disabling OCPP among the mitigation steps, but the underlying backend still needs to be patched.

What strikes me is the gap in threat modeling. Charging infrastructure operators often think of the physical station as the asset and the backend as just IT. But CISA classifies this under Transportation Systems critical infrastructure for a reason. A compromised backend does not just mean free charging; it means grid load manipulation, mass denial-of-service across a region, and a potential foothold into the utility's wider environment.

If you operate EV charging infrastructure, treat your OCPP backend like the OT border it is. Audit websocket endpoints for unauthenticated access this week, enforce strong session management and rate limiting on the charging platform, and segment the charging network from your corporate and grid management zones. If you cannot tell me the last time you audited which charging backends are internet-reachable, that is the project for Monday morning.

Microsoft's analysis of GigaWiper landed this week and it is worth reading closely. This is not another single-purpose wiper script; it is a destructive backdoor that bolts three older malware tools into one platform and lets the operator pick how to break the machine.

The menu is straightforward but nasty. The operator can issue a command to wipe the entire disk, overwrite just the Windows drive, or deploy fake ransomware that scrambles files with a key it never saves. There is also a spyware component in the mix. What stands out architecturally is the modularity. Instead of deploying separate payloads for reconnaissance and destruction, the attacker gets a single binary with multiple operational modes.

The fake ransomware angle deserves attention. Because the key is discarded, the encryption is just another wiping mechanism dressed up as extortion. That ambiguity is deliberate. It forces incident responders to treat the event as a potential ransomware negotiation while the attacker never intended to restore anything, buying time and sowing confusion about motive and attribution.

Microsoft does not attribute GigaWiper to a specific actor in its post, and I will not speculate here. But the design tells us something about where destructive tooling is heading. Actors want flexible platforms that can switch between espionage, sabotage, and false-flag ransom operations without swapping malware on disk.

Practical takeaway: pull the GigaWiper indicators from Microsoft's report and hunt for them in your environment this week. More importantly, audit your backup architecture. If your restore drills assume ransomware with recoverable data, test your response against a wiper that destroys the key. Verify your immutable backups actually work offline, and make sure your SOC playbooks trigger full isolation on mass file modification regardless of whether a ransom note appears.

CISA added two new entries to the KEV catalog on Friday, and they are a sharp reminder that the Joomla plugin ecosystem is still very much in play for attackers. CVE-2026-48939 and CVE-2026-56291 are unrestricted file upload vulnerabilities in iCagenda and Balbooa Forms, two widely deployed Joomla extensions. CISA confirmed both are under active exploitation, so this is not a theoretical concern.

The vulnerability class is as old as web applications themselves: an unauthenticated or low-privileged user uploads a file with an executable extension, and the application saves it in a web-accessible path. On a PHP platform like Joomla, that translates directly to remote code execution. iCagenda is an event calendar component; Balbooa Forms is a form builder. Both handle user-supplied files, and both apparently failed to enforce adequate extension or content-type validation.

What makes this KEV addition notable is the target surface. Joomla still runs a surprising number of government, education, and small-business sites, and these third-party extensions are often installed during a project and then forgotten. Security teams routinely audit WordPress plugins while Joomla instances in the same environment quietly accumulate vulnerable components. BOD 26-04 means federal agencies must prioritize patching these on publicly exposed assets, but private organizations should treat them with the same urgency because the same exploit kits are scanning indiscriminately.

The TTP here is mass-exploitation of CMS plugins for initial access. We have seen this playbook for years, but attackers are still finding success with the same file-upload vectors because visibility into Joomla estates is poor. If you cannot name every Joomla instance in your environment and list its installed extensions, you are flying blind.

Practical takeaway: find your Joomla boxes this week. Inventory for iCagenda and Balbooa Forms, patch to the latest versions, and if you cannot patch immediately, disable file upload features or restrict them behind strong authentication. Check your web roots and temp folders for unexpected PHP files. If you have a WAF, enforce a strict file-type whitelist on every upload endpoint. This is not advanced tradecraft; it is basic hygiene, and it is being exploited right now.

CISA added CVE-2026-48282 to the Known Exploited Vulnerabilities catalog on July 7, and it deserves the attention. The flaw is a path traversal in Adobe ColdFusion, reported as scoring CVSS 10.0 and capable of leading to arbitrary code execution. CISA confirmed active exploitation, which means this is not a theoretical risk; attackers are already using it to gain initial access and total control of affected systems.

What makes this KEV addition operationally significant is BOD 26-04. The new binding directive requires FCEB agencies to prioritize rapid remediation of high-risk KEVs on publicly exposed assets that grant total control post-exploitation, while deferring lower-risk bugs. It also establishes a hard expectation that agencies must check whether threat actors compromised the system before the patch was applied. That is a shift from "patch fast" to "hunt, then patch, and do it faster for the stuff that actually matters."

ColdFusion has been a reliable target for years, and path traversal bugs in it have a habit of becoming full RCE. I have seen incident response cases where a ColdFusion instance that was supposedly internal was actually internet-facing, unpatched, and running with privileged service accounts. The advisory does not name a specific threat actor, but the KEV designation tells us the exploit is already commoditized enough to show up in CISA's active exploitation evidence. If you are assuming your ColdFusion server is too obscure to hit, that is exactly the assumption this KEV is designed to break.

Practical takeaway: If you run ColdFusion, do not just patch and close the ticket. Treat every exposed instance as potentially compromised until you verify otherwise. Review web logs for anomalous requests targeting traversal patterns, inspect the CFIDE and runtime directories for unexpected files or JSP shells, and check for new local accounts or scheduled tasks. If you are FCEB, BOD 26-04 means you need to document that compromise check. If you are private sector, adopt the same discipline this week: patch, hunt, and segment any ColdFusion that still touches the public internet.

CISA added three new entries to the KEV catalog on Tuesday, and the mix is telling. Two are Joomla page builder plugins and one is an authorization bypass in Langflow. All three grant total control of the asset post-exploitation, which places them in the highest tier of BOD 26-04's risk-based patching mandate for federal agencies.

The Joomla pair is CVE-2026-48908 in JoomShaper SP Page Builder and CVE-2026-56290 in Joomlack Page Builder. One is an unrestricted file upload with dangerous type, the other is improper access control. Page builder extensions are installed by the thousands across small government sites, nonprofits, and legacy corporate properties, then forgotten. An unrestricted upload path in a plugin that already has broad content permissions is effectively a web shell delivery mechanism waiting for a POST request.

CVE-2026-55255 in Langflow is the outlier. Langflow is a visual framework for building LLM workflows, and this flaw is an authorization bypass through a user-controlled key. If your AI engineering team has an instance exposed to the internet, or even reachable from a compromised endpoint, this KEV should get your attention. It is a clear signal that the AI toolchain is now part of the external attack surface and is being actively exploited.

CISA's BOD 26-04 explicitly prioritizes KEVs on publicly exposed assets that grant total control, deferring lower-risk items. These three fit that definition exactly. FCEB agencies have binding remediation timelines, but private sector defenders should treat them with the same urgency. The common thread is not the vendor, it is the pattern of internet-facing applications with broad functionality and weak access controls.

Practical takeaway: this week, inventory every internet-facing Joomla site and enumerate installed extensions. Remove or patch JoomShaper SP Page Builder and Joomlack Page Builder if present. Do the same for any Langflow deployments, internal or external. If you cannot patch immediately, pull them behind a VPN or WAF rule set. Then extend that audit to every CMS plugin and AI dev tool your teams stood up without a security review. That shadow infrastructure is what this KEV batch is targeting.

CISA dropped ICSA-26-188-05 this week and it caught my attention for all the wrong reasons. Siemens SINEC OS before version 4.0 on the RUGGEDCOM RST2428P industrial switch is affected by a sprawling cluster of vulnerabilities that CISA scores at CVSS 9.8. The advisory bundles stack-based buffer overflows, integer wraps, race conditions, path traversal, prototype pollution, out-of-bounds reads and writes, improper access control, and even a covert timing channel into a single industrial network operating system.

What stands out to me is not one novel exploit technique but the sheer breadth. When a network OS ships with uncontrolled recursion, expired pointer dereferences, incorrect bitwise shifts, and concurrent execution flaws alongside memory corruption bugs, it signals systemic secure-development failures rather than a narrow coding mistake. The RUGGEDCOM line is deployed in electric substations, rail systems, and heavy industrial sites where the switch is supposed to be the trusted backplane, not the primary attack surface.

Siemens has released SINEC OS V4.0 for the RST2428P and is recommending an immediate update. That sounds straightforward, but in practice I know these devices are often physically remote, running in harsh environments, and managed through centralized network tools that assume the underlying layer is stable. Pushing a firmware update to edge industrial switches can require maintenance windows, traffic baselining, and validation against SCADA and protection relay communication patterns that commodity IT patching tools do not understand.

My practical takeaway is to treat your industrial network fabric with the same scrutiny you give PLCs and engineering workstations. If you are running SINEC OS below V4.0 on RUGGEDCOM hardware, get the update scheduled this week. Verify that these devices are not reachable from less trusted network segments, audit administrative access, and ensure your asset inventory actually captures firmware versions on every switch. If your OT network is flat by design, a 9.8 CVSS finding in the switching layer is exactly the reason to re-examine that architecture before someone else does it for you.

eSentire's Threat Response Unit confirmed this week that CVE-2026-8037 is being actively exploited in the wild. The vulnerability is a pre-authentication operating system command injection in Progress Kemp LoadMaster, rated CVSS 9.6. That translates to unauthenticated remote code execution against a system that usually sits on the network perimeter, which is about as bad as it gets for edge infrastructure.

LoadMaster is a load balancer and application delivery controller. It terminates SSL, proxies traffic to backend pools, and often holds the keys to your internal application topology. Because it lives in the DMZ with inbound internet exposure, a pre-auth command injection means an attacker does not need stolen credentials, social engineering, or an insider. A single crafted request to the management interface is enough to execute arbitrary OS commands.

eSentire has not published the full exploit chain, but in this class of bug the attack surface is typically the web-based management portal or REST API. An unauthenticated POST or GET containing shell metacharacters hits a vulnerable parameter, and the appliance runs it. If your LoadMaster management plane is reachable from the internet or an untrusted segment, you are already in the scanning crosshairs.

The blast radius goes well beyond the appliance itself. Compromise at the load balancer gives an attacker visibility into backend server pools, SSL certificate stores, session persistence tables, and virtual service configurations. From there, lateral movement into the internal network is straightforward. I have seen teams treat ADCs as plumbing rather than endpoints, which means they often skip EDR coverage and log monitoring on these devices.

Practical takeaway: If you run Kemp LoadMaster, treat this as a patch-now event. Pull internet-facing management access immediately and restrict it to a bastion host or VPN gateway. Review your appliances for unauthorized local accounts, unexpected cron jobs, or modified virtual services. If your vulnerability management cycle measures this in weeks, compress it to hours, and make sure your load balancers are in your incident detection scope and not just your network diagram.

CISA added CVE-2026-45659 to its Known Exploited Vulnerabilities catalog this week, and the entry caught my eye immediately. It is a remote code execution bug in Microsoft SharePoint Server, scored CVSS 8.8, and it is being actively exploited in the wild. Microsoft shipped the patch in May, but the gap between patch availability and CISA confirmation is the kind of window that keeps incident responders busy.

The root cause is deserialization of untrusted data. That is a recurring theme in SharePoint, and it is as dangerous as it sounds. An attacker who can reach the server can craft a request that tricks SharePoint into instantiating malicious objects, which leads to code execution under the server account. No zero-day magic is required anymore -- the knowledge is out, and threat actors are using it.

SharePoint is a target-rich environment. It sits on the network edge or deep inside the enterprise, holding sensitive documents and project data, and it often acts as a pivot point into Active Directory. Because it is a collaboration platform, it tends to be accessible from broad swaths of the corporate network and sometimes from the internet. That accessibility is exactly why a deserialization RCE here hurts.

The timeline bothers me. May patch, July KEV entry. That two-month lag suggests either exploitation started recently, or detection took time, or -- more likely -- a lot of environments are still unpatched and attackers know it. SharePoint does not always get the same urgent patch treatment as Exchange, but it should.

Practical takeaway: If you run SharePoint Server, treat the May cumulative update as overdue if you have not applied it. Verify your build version today. If patching is delayed, restrict network access to the farm, especially from untrusted networks, and increase logging on SharePoint application pools. If your SharePoint is internet-facing without a VPN or zero-trust front door, that architecture review needs to happen this week, not next quarter.

CISA confirmed this week that ransomware crews are actively exploiting a Microsoft Defender privilege escalation flaw nicknamed BlueHammer. The bug was already on my radar after earlier reports of zero-day abuse, but seeing it folded into commodity ransomware operations marks a clear shift from targeted APT-style use to broad affiliate deployment.

BlueHammer is a local privilege escalation in Windows Defender, which means it is not your initial access vector. An attacker already sitting on a workstation with user-level privileges can abuse the flaw to escalate to SYSTEM. Once there, they own the endpoint, can tamper with the very security tool they just exploited, and move laterally with far less friction. It turns a phishing foothold or a leaked RDP session into full administrative compromise, and from there into ransomware deployment.

What stands out is the target surface. When the security product itself becomes the vulnerability, the usual assumptions break down. Defenders expect Defender to be the layer catching the payload, not the payload's path to SYSTEM. Ransomware gangs have figured out that disabling or bypassing EDR is often more efficient than evading it, and a privilege escalation chain inside the protection stack gives them exactly that capability with minimal noise.

The timeline matters too. Zero-day exploitation of security products used to be largely the domain of state-level actors. Watching that same capability migrate to ransomware affiliates within a single patch cycle suggests exploit brokers or tool developers are distributing these faster than many organizations are deploying updates. That compression between zero-day and ransomware commodity use is the trend to watch.

If you have not patched Windows and Microsoft Defender this month, treat it as a critical change and push it now, not next Tuesday. In the SOC, prioritize alerts showing unexpected child processes spawning from Defender-related services or sudden SYSTEM-level token privileges after a low-integrity login. And audit your incident response playbooks: if your EDR is the compromise path, your isolation and recovery steps need to account for a blinded or subverted sensor.

Threat actors linked to the Anubis ransomware operation are actively exploiting CVE-2025-5777, the Citrix Bleed 2 vulnerability, to obtain initial access to target networks. Once inside, they are shifting to legitimate Remote Management and Monitoring tools, credential access, and hands-on-keyboard procedures to move laterally and maintain persistence before deploying the payload.

This is not a smash-and-grab campaign. The report highlights a deliberate blend of patched-but-still-present Citrix flaws, BYOVD techniques, and supply chain credentials that lets affiliates blend into normal administrative traffic without triggering noisy alerts. It reflects the operational reality that modern ransomware groups no longer need zero-days when unpatched edge appliances and trusted tooling will suffice, and it raises the bar for defenders who still rely on signature-based detection alone.

The RMM component is especially worth watching. These are not rogue binaries or cracked utilities; they are signed, legitimate applications executing within their intended parameters. When combined with valid credentials, possibly recovered from upstream supply chain compromises, the activity looks exactly like standard remote support until the encryption phase begins. That is a detection gap most SOCs have not closed, and it is why living-off-the-land tradecraft continues to dominate mid-market intrusions.

Practical takeaway: If you run Citrix ADC or Gateway, verify CVE-2025-5777 is patched and assume any internet-exposed appliance has been probed by these affiliates. This week, inventory every RMM agent in your environment and remove anything not tied to an active, approved support contract with a known serial number. Require MFA and device compliance on all remote management sessions, because trusted tools with stolen credentials are now the primary path for Anubis operators to reach your domain controllers.

Oracle E-Business Suite is still the ERP backbone for a lot of large enterprises, and attackers are currently exploiting a critical flaw in its Payments module. CVE-2026-46817, rated CVSS 9.8, is an improper privilege management and authentication bug in Oracle Payments that Defused Cyber reports is being actively exploited to take over instances.

The vulnerability lives in the financial processing layer of EBS, which sits between the general ledger and actual bank integrations. Because the flaw blends authentication weaknesses with privilege escalation, an attacker can reportedly gain full administrative control without needing valid credentials upfront. In practice, that means access to supplier master data, payment runs, bank account details, and the underlying database context.

EBS environments are rarely well-segmented. They tend to live on flat internal networks with broad access and intermittent outbound connectivity for bank feeds or patch delivery. A compromise of the Payments tier does not stop at invoice data; it becomes a pivot point into the database tier, the operating system, and eventually the wider enterprise. Ransomware groups have targeted EBS before, and a 9.8-scored auth bypass in the finance module is exactly the kind of lure that attracts them.

Oracle's quarterly patching cycle for EBS is notoriously slow because custom workflows break. Attackers know this. The public reporting from Defused Cyber suggests exploitation is already happening, which means the window between disclosure and mass exploitation is essentially closed. If your instance is exposed or your Payments responsibility is internet-adjacent, you are already in the crosshairs.

Practical takeaway: inventory every Oracle EBS instance running Payments, verify whether it is reachable from untrusted networks, and restrict access to known middleware and operator subnets immediately. If a patch is available, apply it under emergency change. Until then, enforce MFA on all EBS accounts, especially those with AP, AR, or admin responsibilities, and alert on any new user creation or responsibility elevation in the Payments module. If you cannot tell me the last time someone audited which EBS responsibilities face the internet, that is your Monday morning project.

CISA added CVE-2026-45659 to the Known Exploited Vulnerabilities catalog this week, and the entry is as brief as it is serious: a deserialization flaw in Microsoft SharePoint Server that is actively being abused in the wild. No exploit chain details, no named actor, just a clear signal that SharePoint farms are under direct fire.

Deserialization bugs in SharePoint are particularly ugly because the platform is a large .NET application that routinely trusts serialized objects moving between the web front end and the back end. A successful hit here typically gives code execution in the context of the SharePoint application pool, which is a short hop to farm-level access and, from there, the rest of the domain if service accounts are overprivileged. CISA noted that this vulnerability type is a frequent attack vector and poses significant risk to the federal enterprise, which tells me they have confirmed exploitation against high-value targets.

What makes this KEV entry operationally interesting is how it lands under Binding Operational Directive 26-04. The directive does not just tell FCEB agencies to patch fast; it explicitly requires them to check whether the asset was compromised before the patch was applied, specifically for KEV-listed bugs on publicly exposed assets that grant total control post-exploitation. That is a meaningful shift from the old patch Tuesday and move on rhythm. For SharePoint administrators, remediation now includes a mandatory forensic hunt before the ticket can be closed.

If you are running SharePoint Server, your job this week is two-fold. First, apply the available security update and treat it as a critical priority. Second, assume breach and hunt: review ULS logs for deserialization exceptions or unusual worker process crashes, look for unexpected WSP solutions deployed to the farm, check for new or modified ASPX files in the layouts directories, and validate that your application pool identities are not running with domain admin or excessive SQL privileges. Review any recent full-trust code or farm solution deployments that you did not initiate. If your farm is internet-facing and you cannot patch immediately, pull it behind a VPN or an authenticated reverse proxy until you can. The KEV listing means the exploit kit is already circulating; obscurity is not a control.

CISA added CVE-2026-48558 to its Known Exploited Vulnerabilities catalog this week, and the target made me wince: SimpleHelp, a remote support and access tool. An authentication bypass in remote access software is not just a vulnerability, it is an open door with a welcome mat. CISA's inclusion confirms active exploitation, and under Binding Operational Directive 26-04, federal agencies now have a short fuse to remediate it on any publicly exposed asset.

SimpleHelp is built to let technicians remote into endpoints, which means its server typically sits where it can reach the internet. If an attacker can bypass authentication, they are not just stealing data, they are inheriting the help desk's view of the network. The advisory language notes that KEV entries on exposed assets grant total control post-exploitation, and that is exactly what a compromised remote support server delivers: persistent, trusted access that looks like normal IT activity.

This fits a pattern I have been tracking for years. Threat actors have been hammering remote support and monitoring tools because the return on investment is enormous. ScreenConnect, TeamViewer, AnyDesk, and now SimpleHelp. These platforms are attractive targets precisely because their traffic is expected to be interactive and administrative, making post-exploitation behavior harder to separate from legitimate use. If your organization picked SimpleHelp because it is smaller and less noisy on the threat intel radar, that obscurity just evaporated.

Practical takeaway: if you have SimpleHelp in your environment, I would treat this as an active incident until proven otherwise. Patch to a fixed version immediately, but do not assume the patch cleans house. BOD 26-04 explicitly expects agencies to check for compromise before the patch was applied, and that is good advice for everyone. Audit your SimpleHelp server logs for unknown source IPs, new technician accounts, or sessions outside business hours. If you cannot find your SimpleHelp instance in fifteen minutes, that is your Monday morning inventory project. While you are at it, enforce IP allowlisting and MFA on the admin portal, and if the vendor cannot support that, find a vendor that can.

JFrog Security Research published the first public exploit walkthrough for DirtyClone this week, and it pulled me right back to a conversation I keep having with teams: local kernel privilege escalation is not a relic of the desktop era. Tracked as CVE-2026-43503 and scoring CVSS 8.8, this is the latest variant in the DirtyFrag family of Linux kernel bugs. A local user can corrupt file-backed memory by abusing cloned network packets and walk away with root.

The technique sits at an ugly intersection of the networking and memory management subsystems. By manipulating cloned packets, the attacker triggers corruption in page-cache-backed memory rather than hitting a straightforward stack or heap overflow. That makes it harder to catch with standard mitigations like stack canaries or ASLR, and easier to mistake for benign memory pressure until the privilege escalation completes. JFrog's walkthrough demonstrates the full chain from an unprivileged local shell to root on a vulnerable kernel, using nothing more than standard socket operations and a timing race. It is reliable enough that I am already seeing it discussed in offensive channels.

Calling this local is technically accurate, but operationally misleading. In any containerized, multi-tenant, or CI/CD environment, my starting assumption is that an attacker already has low-privilege code execution inside a pod, a build runner, or a shared host. From there, CVE-2026-43503 is not a theoretical elevation; it is a direct path to host compromise. The boundary between local and remote has collapsed for anyone running Linux infrastructure that allows user-supplied workloads. If your threat model still treats kernel privilege escalation as a secondary concern because it requires local access, your model is outdated.

If you are running Linux hosts with untrusted or semi-trusted local users, patch to the latest stable kernel this week. Do not wait for your distribution's next quarterly cycle. If patching immediately is not viable, disable unprivileged user namespaces and restrict CAP_NET_RAW, because the attack surface starts with the ability to create and clone packets at the socket level. Audit your build pipelines and container platforms for hosts that allow unprivileged users to open packet sockets or manipulate network namespaces. Finally, instrument your endpoint detection to alert on unexpected privilege transitions originating from build agents, web shells, or container runtimes. DirtyClone is local in scope, but in modern infrastructure that is all an attacker needs.

CISA's ICSA-26-176-06 advisory on Delta Electronics DTM Soft landed this week, and it is another reminder that OT engineering workstations remain a dangerously soft target. CVE-2026-12578 is a deserialization-of-untrusted-data vulnerability in the software, rated CVSS 7.8, and it affects every released version. An attacker who tricks a user into opening a malicious project file can execute arbitrary code in the context of the engineering station.

DTM Soft is deployed in critical manufacturing environments worldwide, and its project files are exactly the kind of assets that move between internal teams, integrators, and equipment vendors without any malware scanning. The advisory confirms there is no patch yet; Delta says it is working on one. Until then, the only mitigations are behavioral warnings: do not open unsolicited project files, unexpected email attachments, or untrusted internet links.

That guidance is operationally fragile. Manufacturing floors run on file exchanges. Configuration files arrive from OEMs over email, get pulled from vendor portals, and bounce around on USB drives and network shares. Expecting an engineer to reliably distinguish a legitimate DTM project file from a weaponized one is not a control, it is a liability. The real attack surface is the trust boundary around engineering data, and right now that boundary is effectively nonexistent for this file type.

The kill chain is straightforward. An adversary crafts a malicious project file that exploits the deserialization flaw, delivers it through spear-phishing or a compromised vendor relationship, and gains a foothold on the engineering workstation. From there, lateral movement into the OT network or manipulation of downstream device configurations is a short step. We have seen this pattern with other ICS engineering tools, and it works because those hosts are often poorly segmented and rarely run modern endpoint detection.

Practical takeaway: if you have Delta Electronics devices in your environment, hunt for DTM Soft installations this week and inventory every host running it. Treat all DTM project files as hostile until a patched version drops; block them at your email gateway, restrict imports from network shares, and isolate engineering workstations from the internet and corporate email. If your asset list cannot tell you where DTM Soft is installed, that gap is now a critical finding.

I pulled up CISA's ICSA-26-176-02 this week and it is a sobering reminder that the charging infrastructure we are rapidly deploying has some alarming gaps. The advisory covers all versions of the EVoke CSMS, assigns a CVSS 9.4, and places the product squarely in Energy and Transportation Systems sectors with worldwide deployment. That is a lot of attack surface for a single platform.

The headline bug is CVE-2026-40702: WebSocket endpoints that simply do not authenticate requests. An attacker can impersonate a charging station, interact with the management backend, and escalate privileges to unauthorized administrative control. The advisory also calls out missing brute-force protections, insufficient session expiration, and poorly protected credentials. It is not a single misconfiguration; it is authentication treated as optional across the stack.

Operationally, this matters because EV charging networks are critical infrastructure that sit at a messy OT-IT boundary. Compromising the CSMS does not just mean flipping a station on or off. Administrative access to the management layer can disrupt services at scale, manipulate billing and session data, and potentially pivot into connected energy grid systems. With electric vehicle adoption accelerating, attackers have a growing incentive to target this layer.

What frustrates me is that unauthenticated WebSocket APIs are a well-understood failure mode. This is not a subtle cryptographic bypass or a novel protocol flaw. It is a design-level omission in a product that manages physical charging assets. When every version on the market carries these flaws, you are not looking at a patch timeline; you are looking at a vendor security culture problem.

Practical takeaway: if you operate EV charging infrastructure, audit your CSMS WebSocket and API endpoints for authentication gaps this week. Enforce network segmentation between your charging management layer and corporate IT, implement rate limiting and strong session controls at the reverse proxy or API gateway if the application lacks them, and demand a concrete patch roadmap from your vendor. If your charging network is internet-facing and you cannot verify who is allowed to speak to those WebSocket endpoints, take it offline until you can.

CISA added PTC Windchill PDMLink and FlexPLM to the Known Exploited Vulnerabilities catalog this week, and the entry is a reminder that enterprise application stacks are fair game for targeted exploitation. The agency confirmed active exploitation of a critical remote code execution flaw in the product lifecycle management suite, flagging it alongside continued web shell activity against the platform.

What makes this stick out is the asset class. PLM systems sit at the heart of manufacturing, defense, and critical infrastructure supply chains. They hold CAD models, bill-of-materials data, supplier specs, and engineering workflows. An RCE here does not just mean a compromised web server. It means an attacker can bury a web shell deep inside an application stack that administrators rarely audit with the same rigor they apply to outward-facing infrastructure. The data is sensitive, uptime requirements are high, and forensic visibility is often low.

The KEV addition comes as web shell attacks against the platform continue, which suggests threat actors are already established in some environments and are expanding access by dropping additional payloads. Web shells in enterprise applications are particularly annoying to hunt because they ride on legitimate application pools and listen on expected ports. If your Windchill instance is internet-facing or even exposed to a flat corporate network, you should assume you are in the target pool.

KEV inclusion triggers Binding Operational Directive 22-01, so federal civilian agencies have a hard deadline to patch or remove affected systems. Private sector operators should treat that same timeline as a proxy for urgency. Even if your environment is not bound by BOD 22-01, the KEV designation means CISA has verified exploitation in the wild and considers the risk acute.

Practical takeaway: If you run Windchill or FlexPLM, treat this as a this-week priority. Hunt for existing web shells in application directories and temp folders, look for unexpected script or archive files, and review reverse proxy and application logs for POST requests to non-standard endpoints followed by suspicious child processes. If your PLM instance is reachable from the corporate LAN without segmentation, move it behind a dedicated jump host and restrict outbound internet access. PLM data is crown-jewel material; defend it accordingly.

CISA dropped two new entries into the Known Exploited Vulnerabilities catalog this week, and both target enterprise platforms that defenders routinely underestimate. CVE-2026-12569 affects PTC Windchill and FlexPLM, while CVE-2026-20230 is a server-side request forgery in Cisco Unified Communications Manager. CISA confirms active exploitation for both, which means these are not theoretical risks.

Windchill and FlexPLM sit at the heart of product lifecycle management. They store CAD files, supplier contracts, bill-of-materials data, and pre-release designs. Because engineering teams need to share data with outside partners, these systems often end up exposed to the internet through reverse proxies or partner portals. An improper input validation vulnerability in that context gives an attacker direct access to the crown jewels of your supply chain.

The Cisco CUCM SSRF is a different shape of the same problem. Voice infrastructure is traditionally treated as a trusted internal tier, but CUCM instances frequently face the internet to support remote endpoints, SIP trunks, or mobile softphones. SSRF in the call manager is a pivot point: an attacker can coerce a trusted internal system into scanning, querying, or attacking adjacent services without ever touching the perimeter firewall.

What makes this KEV update operationally interesting is BOD 26-04. CISA used the announcement to highlight the directive's risk-based approach: federal agencies must rapidly remediate KEVs on publicly exposed assets that grant total control post-exploitation, and they must check for threat actor activity before applying the patch. Patching alone is no longer the finish line; you have to prove the box was not already owned.

Practical takeaway: if you run Windchill or CUCM, treat these as incident triggers, not just patch tickets. For Windchill, verify whether the application or any partner-facing portal is internet-accessible, restrict access to VPN or zero-trust gateways, and audit file access logs for anomalous downloads of CAD or BOM data. For CUCM, review call manager logs for unexpected outbound requests, restrict public-facing web and SIP interfaces to hardened session border controllers, and follow Cisco's remediation guidance. Federal shops should start compromise assessments now; everyone else should borrow the same discipline.

CISA's ICSA-26-174-05 covers ABB Freelance Security Lock, and the irony is impossible to miss. The component literally named for securing active operations is the one letting attackers reach underlying OS functions while Freelance Operations mode is still running. That is the exact moment the system is supposed to be most protected.

The affected surface is sprawling. Every version of ABB Freelance Security Lock shipping with Freelance 2013, 2013 SP1, 2016, 2016 SP1, 2019, 2019 SP1, 2019 SP1 FP1, and 2024 is vulnerable. That is more than a decade of process control deployments across manufacturing and energy. CISA scores it CVSS 6.6, noting the impact depends on system configuration and user permissions, but in a DCS environment even limited OS access during active operations can bridge the gap between an HMI session and process manipulation.

What bothers me is the boundary failure. Freelance Operations mode is supposed to be a hard gate that prevents tampering with running processes. If an attacker can bypass that gate to touch the OS underneath, the trust model collapses. It turns an engineering workstation into a pivot point and gives an intruder a path from the operator layer toward the controllers without ever needing a zero-day in the PLC firmware itself.

The advisory language is careful, saying exploitation depends on configuration, which usually means certain default or overly permissive setups are the worst hit. That tracks with what I see in the field: Security Lock deployed as a checkbox compliance control, running under shared service accounts or on improperly hardened Windows hosts where local privileges are already loose.

Practical takeaway: if you run ABB Freelance, inventory every instance of Security Lock across your fleet this week. Validate which user accounts and system configurations can reach OS functions during active Operations mode, and assume any engineering station with Freelance installed is a tier-zero asset. Segment those hosts behind a jump box, restrict local admin rights, and alert on unexpected process execution originating from Freelance sessions. If you are still running Freelance 2013 or 2016, those versions are explicitly called out and well past support lifecycle; treat them as emergency migration candidates.

CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog this week, and three of them target Ubiquiti UniFi OS. CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910 cover an improper access control flaw, a path traversal, and an input validation bug in the same operating system. The fourth entry is CVE-2025-67038, a code injection vulnerability in the Lantronix EDS5000 serial device server. CISA does not add without evidence of active exploitation, so these are being hit in the wild right now.

The Ubiquiti cluster is the headline. UniFi OS runs Dream Machines, Cloud Keys, and other controllers that manage access points, switches, and gateways for a massive slice of the mid-market and MSP space. Three distinct bugs in one platform hitting the KEV simultaneously suggests either a coordinated disclosure or an active exploitation wave against edge network infrastructure. If you have UniFi gear managing guest Wi-Fi, camera networks, or site-to-site VPNs, the attack surface just got real.

CVE-2025-67038 is the one that should worry OT and facilities teams. The Lantronix EDS5000 is a serial-to-Ethernet gateway that shows up in manufacturing, energy, and building automation because it lets engineers reach serial devices over TCP. Code injection on a box that bridges IP networks to serial-connected PLCs or RTUs is a straight path into operational networks, and these devices have a terrible habit of being internet-facing for remote maintenance convenience.

CISA tied the announcement to BOD 26-04, which directs federal agencies to prioritize rapid remediation of KEV-listed vulnerabilities on publicly exposed assets that grant total control post-exploitation. That framing matters: CISA is explicitly telling FCEB shops to treat these four as high-risk, drop-everything patches. The rest of us should read it the same way.

Practical takeaway: If you run UniFi, patch to the latest UniFi OS release today and verify your controllers are not reachable from the internet. If you have Lantronix EDS5000s, pull them offline until you can confirm firmware levels and network placement. And audit your edge device inventory. If you cannot account for every network controller and serial gateway, attackers are already doing it for you.

ShapedPlugin's build pipeline was compromised this week, and the attackers did not bother with exploiting individual sites. They went straight for the vendor's distribution channel, injecting backdoor code into official Pro plugin releases that were then pushed to licensed customers through legitimate update channels.

Wordfence's analysis confirms the supply chain angle: unknown actors gained access to the build and distribution infrastructure and tampered with the official release artifacts. Because these were distributed through ShapedPlugin's licensed update mechanism, affected sites pulled the backdoored code as part of what looked like a routine, trusted update. This is not a case of admins installing nulled plugins from a sketchy forum; these are paying customers who did exactly what they were supposed to do.

Operationally, this is the hardest kind of threat to catch. WordPress admins generally treat plugin updates, especially from premium vendors, as safe. Few organizations run diff checks on every update that hits wp-content, and even fewer have the tooling to spot a subtle backdoor buried in a complex plugin. When the vendor's own signing or delivery process fails, the usual assumption that upstream is clean collapses.

The incident also highlights a gap in WordPress supply chain visibility. Unlike package managers that enforce checksum verification or reproducible builds, the WordPress premium plugin ecosystem largely relies on opaque ZIP distributions delivered over HTTPS to admin panels. If that endpoint or build server is compromised, there is no secondary validation for most users.

Practical takeaway: if you run ShapedPlugin Pro products, treat every recent update as potentially suspect until the vendor publishes a clean build and confirms the compromise window. Rotate any WordPress admin credentials and database secrets that existed on affected sites, and inspect user tables for unauthorized accounts. More broadly, disable auto-updates for premium plugins until you have a way to verify integrity outside the vendor's own channel, and monitor web server processes for unexpected outbound connections. If your plugin vendor does not publish hashes or signatures, ask them why not.

CISA issued ICS advisory ICSA-26-169-02 this week for AzeoTech DAQFactory, a data-acquisition and HMI package deployed worldwide in critical manufacturing. CVE-2026-12390 is a type-confusion flaw in versions 21.1 and prior that triggers arbitrary code execution when the application parses a malicious .ctl file. CISA scored it 7.8, and the affected-product list covers every release through 21.1 with no patched version identified in the advisory.

The kill chain is deceptively simple: an engineer opens what looks like a standard project or configuration file, and the parser confuses object types to achieve code execution. In manufacturing environments, .ctl files move constantly between integrators, vendors, and internal operators over email, shared drives, and USB sticks. They are treated as passive data, but the parser trusts them as code, which bridges the gap between a phishing attachment and an engineering workstation inside the OT network.

What concerns me is the remediation column. CISA does not list a patched release. The recommended mitigations are purely procedural: avoid documents from unknown sources, store .ctl files in directories writable only by administrators, and run DAQFactory in Safe Mode when loading projects. That is a heavy operational lift in environments where outside contractors routinely exchange project files, and it suggests defenders will be living with this exposure for a while.

Practical takeaway: if DAQFactory is running in your facility, treat .ctl files as executable payloads, not office documents. Block .ctl attachments at your email gateway and restrict removable-media autorun this week. Apply application-control policies to the DAQFactory process so it cannot spawn unexpected child processes, and audit every .ctl file that entered the environment from a vendor or integrator in the last 90 days. If you cannot tell me where those files came from, that inventory is your first project for Monday morning.

CISA published ICSA-26-169-03 on Thursday covering three vulnerabilities in Rockwell Automation FactoryTalk Historian Site Edition. The advisory bundles CVE-2025-13036, an authentication bypass, with CVE-2025-44019 and CVE-2025-36539, a race condition and uncaught exception that can crash the system or induce denial of service. Rockwell assigned the bundle a CVSS v3 score of 7.7. FactoryTalk Historian SE is a core data aggregator in critical manufacturing plants worldwide, collecting time-series sensor data and often serving as a bridge between OT floors and IT business systems.

The standout flaw is CVE-2025-13036. By continually firing requests at the login endpoint, an attacker can obtain a valid authentication token without presenting legitimate credentials. It is a brute-force-style bypass against the historian's own session management, not a stolen password or phishing dependency. Once an attacker holds a valid token, they have the same read and potentially write access to process history as a legitimate operator or engineer. In plants where historian data drives batch reporting, quality dashboards, or regulatory logs, that access is a serious operational and safety concern.

The remaining two CVEs are a concurrent execution race condition and an uncaught exception. Successful exploitation can crash the historian service or degrade it to the point of denial of service. That matters because historians are rarely redundant. If the historian goes down, operators lose trend visibility, automated reporting stalls, and downstream ERP or MES systems may stop receiving the process data they expect. A blind spot during a process upset is exactly when you need that data most.

Rockwell notes that FactoryTalk Historian SE is deployed worldwide, and CISA tags it under the Critical Manufacturing sector. In my experience, these historian nodes are installed during commissioning and then left untouched for years because they simply work. They frequently end up on flat networks or on VLANs that are far more reachable than they should be because business users need Excel add-ins or web portals to pull production metrics. The auth bypass is low complexity and requires no malware; a simple script against the login endpoint is enough.

Practical takeaway: if you are running FactoryTalk Historian SE 11.00 or earlier, patch or upgrade according to Rockwell's guidance immediately. If you cannot patch this week, segment the historian so only known OPC or PI clients can reach it, block the login endpoint from general network access, and alert on repeated authentication requests from any single source. Finally, audit where your historian data flows; if it is one hop away from your business network or the internet, that architecture review is Monday's priority.

Cisco released security updates this week for CVE-2026-20262, an authenticated file-creation vulnerability in the Catalyst SD-WAN Manager web UI. The bug carries a CVSS score of 6.5, but Cisco confirmed it is under active exploitation in the wild, which is the only metric that should matter when you are deciding what to patch before the weekend.

Catalyst SD-WAN Manager, formerly vManage, is the control plane for Cisco's SD-WAN fabric. It holds certificates, policy templates, and the configuration state for every WAN edge and branch router under its care. An authenticated attacker who can create files on that system is not just leaving graffiti; they are planting artifacts on the device that orchestrates your entire wide-area network. File creation on a management plane rarely stays a contained event, and in this context it can lead to configuration tampering, lateral movement, or persistent access across the WAN.

The authentication requirement is the only thing keeping this at a 6.5. That suggests the exploitation we are seeing in the wild likely involves compromised administrator credentials, session hijacking, or an earlier bug in the chain. If your vManage instance is exposed to the internet and shares passwords with other gear, the blast radius extends across every site that controller manages. I have seen too many SD-WAN managers sitting on public IPs with nothing more than a self-signed certificate for protection.

CVSS 6.5 is a dangerous label here. Security teams with rigid patch policies often deprioritize anything below a 7.0, but an actively exploited bug in your WAN brain should bypass that queue. The score measures the technical mechanics of the bug, not the operational value of the target to an intruder who already has working access.

Practical takeaway: patch your SD-WAN Manager now, not next maintenance window. While you are at it, force password resets on all vManage admin and service accounts, review the last thirty days of web UI access logs for unusual source IPs or unexpected file operations, and verify that your manager is not reachable from the public internet without strict IP allowlisting or a hardened jump host. If you cannot find your SD-WAN Manager in your asset inventory, that is the scarier discovery.

CISA added CVE-2026-20253 to the Known Exploited Vulnerabilities Catalog this week, and the entry should make any SOC analyst wince. It is a missing-authentication flaw in Splunk Enterprise, and CISA has confirmed active exploitation in the wild. When the platform that ingests all your security telemetry fails to challenge access to a critical function, the integrity of everything downstream is in question.

The timing is what makes this sting. The KEV drop lands just after BOD 26-04 replaced BOD 22-01, and the new directive changes the patching math for federal agencies. Instead of a blanket two-week mandate for every catalog entry, FCEB agencies must now prioritize KEV-listed bugs on publicly exposed assets that grant total control after exploitation, while deferring lower-risk items. CISA is also explicitly requiring agencies to hunt for evidence of compromise before the patch was applied. A Splunk Enterprise instance with an authentication gap on a critical function is exactly the kind of high-value, reachable target this new risk-based framework is designed to surface.

Splunk is not just another enterprise application. It is the aggregation point for firewall logs, endpoint telemetry, authentication events, and often the IR team's primary workspace. If an attacker can reach a critical function without credentials, they are not simply reading data; they are positioned to tamper with the evidence you would use to find them. I have seen too many Splunk instances sitting with broad network reach because it needs to hear from everything. That architecture assumption just became significantly harder to defend.

Practical takeaway: if you run Splunk Enterprise, treat this KEV addition as a drop-everything patch for any instance that is externally reachable or even broadly internal-facing. Verify your version is covered by the vendor fix, and if patching is delayed, front-end it with a hardened reverse proxy and strict network segmentation. For FCEB shops, BOD 26-04 means you need to produce compromise-assessment artifacts before you close the ticket, so start pulling auth logs and session telemetry now. If your Splunk is monitoring itself and you cannot tell me who accessed that critical function last Tuesday, that is your Monday morning project.

CISA added CVE-2026-48907 to the Known Exploited Vulnerabilities catalog this week, and it is a doozy. The flaw sits in Widget Factory Joomla Content Editor, a popular WYSIWYG plugin for Joomla sites, and it carries a CVSS score of 10.0. It is an improper access control vulnerability that is being actively exploited in the wild, and because it can grant total control of a public-facing asset post-exploitation, it lands squarely in the crosshairs of the new Binding Operational Directive 26-04.

What makes this one sting is that it is not core Joomla. It is a third-party plugin that many content managers install and forget. The vulnerability allows an attacker to bypass access controls and ultimately execute arbitrary PHP code, which on a Joomla host typically means full compromise. If your asset inventory only tracks the CMS and not the plugin stack, you might not even know you are exposed.

BOD 26-04 is the new driver here. Unlike the old BOD 22-01, the updated directive explicitly prioritizes KEV-listed CVEs on internet-facing systems that grant total control, while deferring lower-risk bugs. CISA is giving federal agencies until Friday to patch this one. More importantly, the directive now expects agencies to check whether the system was already compromised before the patch goes in, which is a welcome shift from pure patch-race to incident validation.

The exploitation I am seeing reported is straightforward web application abuse: unauthenticated or low-privileged access to admin functions, then code execution. Threat actors have been hitting content management systems hard lately because plugins like JCE often sit outside the patch cycle that security teams run for the core platform. This one is no theoretical risk; it is already being used.

If you run Joomla anywhere in your environment, you need to inventory for JCE this week, not next. Patch to the fixed version immediately, or remove the plugin if it is not essential. If you cannot patch today, pull the instance offline or restrict it behind your WAF until you can. Federal teams should treat this as a BOD 26-04 fire drill: patch, then hunt for web shells, unexpected admin accounts, and suspicious PHP uploads going back at least 30 days. Everyone else should do the same.

Oracle published an alert this week on CVE-2026-35273, a critical unauthenticated remote code execution flaw in PeopleSoft Suite that is already under active exploitation. The actor in question is ShinyHunter, a group with a long track record of mass data theft and resale, and they are using this zero-day to pull sensitive records from victim environments before defenders can react.

PeopleSoft is not some obscure edge system. It sits at the heart of HR, payroll, and financial operations for thousands of large enterprises, government agencies, and universities. An unauthenticated RCE here means ShinyHunter does not need phished credentials, a prior foothold, or any insider access. If the application is reachable from the internet, that alone is enough to get code execution and start exfiltrating employee records, salary data, and payment details.

Oracle says it has mitigated the flaw. I am less interested in exactly how the fix is delivered than in the fact that exploitation is already widespread. Waiting for a traditional patch cycle or a monthly maintenance window is not a viable option when a data-theft group is already inside target networks harvesting information for resale.

What concerns me is how many PeopleSoft instances remain directly internet-facing because they serve self-service portals for employees, applicants, or vendors. Those endpoints hold some of the most sensitive data in the organization, yet they are often monitored less aggressively than external marketing sites and lack the same EDR coverage as standard corporate workstations.

Practical takeaway: identify every internet-facing PeopleSoft instance in your estate today and apply Oracle's mitigation immediately. If you cannot confirm the fix is in place, pull the system behind VPN-only access until you can. Review your web and application logs for anomalous requests to PeopleSoft endpoints over the past two weeks, and treat any HR or financial data stored in those systems as already prioritized by threat actors. If you do not have an accurate inventory of your public-facing Oracle applications, building that list is Monday morning's job.

CISA posted two new additions to the Known Exploited Vulnerabilities catalog this week, but the part that caught my eye was the formal rollout of Binding Operational Directive 26-04. I have been watching for CISA to refine the old BOD 22-01 approach, and this advisory finally does it. The notice pairs CVE-2026-20262, a directory traversal bug in Cisco Catalyst SD-WAN Manager, and CVE-2026-54420, a symlink-following vulnerability in the LiteSpeed cPanel plugin, with a new federal mandate that replaces uniform patching timelines with risk-based prioritization.

CVE-2026-20262 is the kind of flaw that keeps infrastructure teams awake. Cisco Catalyst SD-WAN Manager is a centralized control plane; a path traversal vulnerability on an internet-exposed instance is essentially an open invitation to pivot into the WAN edge. CVE-2026-54420 targets the LiteSpeed plugin for cPanel, a staple of shared hosting environments, where symlink following can let an attacker break out of user jails and compromise neighboring accounts or the host itself. Both are already under active exploitation.

BOD 26-04 introduces risk-based prioritization for Federal Civilian Executive Branch agencies. Instead of treating every KEV entry the same, agencies must now rush fixes for KEV catalog CVEs that sit on publicly exposed assets and grant total control post-exploitation, while lower-risk vulnerabilities can be deferred. I think this is a pragmatic admission that not every KEV deserves the same SLA, but it also means agencies need accurate asset exposure data and solid risk scoring to comply.

For defenders outside the federal space, this is worth watching. If CISA is formally tiering KEV risk based on exposure and impact, private-sector vulnerability management programs should follow suit. In my view, an unpatched SD-WAN manager with a known traversal bug on a public IP is not a Tuesday ticket; it is a weekend patch. The same goes for shared hosting platforms running the LiteSpeed cPanel plugin.

Practical takeaway: audit your externally facing Cisco SD-WAN Manager instances and cPanel or LiteSpeed deployments this week. Patch CVE-2026-20262 and CVE-2026-54420 if they are in your environment, and if you cannot patch immediately, pull the management interfaces behind a VPN or restrict access at the edge. Then apply the BOD 26-04 logic to your own program: any KEV that gives total control of an internet-facing asset should be at the top of your queue, regardless of what your old SLA matrix says.

VulnCheck published findings this week on CVE-2026-5027, an unpatched path-traversal flaw in Langflow that is already seeing active exploitation in the wild. I have been watching AI dev tooling become a target for months, and this confirms the trend: the vulnerability carries a CVSS score of 8.8 and allows unauthenticated attackers to write files to arbitrary locations via a POST request, which on a Python-based platform quickly translates to remote code execution.

Langflow is an open-source, low-code environment for building AI applications with LangChain components. It is popular with data science teams because it removes boilerplate, but that convenience comes with a familiar cost. These instances are often spun up in cloud environments, exposed to the internet for easy collaboration, and then forgotten by central IT because they do not look like traditional production servers.

The TTP is clean and effective. The flaw sits in an API endpoint that accepts file writes without proper path sanitization. An unauthenticated attacker can place files anywhere on the filesystem. On Langflow, that means overwriting Python modules, injecting malicious flows, or dropping payloads into directories that execute during normal operation. VulnCheck confirms exploitation is happening now, and with no vendor patch available yet, network access controls are the only real defense.

What bothers me is the inventory gap. Security teams usually have visibility into standard web apps and container fleets, but AI dev tooling often lives in a governance gray zone--not quite production, not quite lab, and frequently outside the patching cycle. Attackers are clearly scanning for it anyway.

Practical takeaway: If Langflow is in your environment, treat it like any other internet-facing application server, not an internal experiment. Pull every instance off the public internet today until a patch ships. If remote access is required, put it behind a VPN or authenticated reverse proxy, and alert on unauthenticated POST requests to Langflow API paths. Run an inventory this week for AI dev tools--Langflow, Flowise, Chainlit, and similar--because if you do not know where they are, assume someone else already does.

Mandiant and Google Threat Intelligence Group published a report this week on UNC6240, also known as ShinyHunters, running an active compromise-and-extortion campaign against Oracle PeopleSoft. The group was exploiting CVE-2026-35273, a CVSS 9.8 unauthenticated remote code execution vulnerability in the Environment Management Hub component, as a true zero-day between May 27 and June 9. That activity predates the June 10 Oracle advisory, so this was not a post-patch race; the vendor was behind the curve.

The victim footprint is heavily tilted toward higher education. Google notified over 100 organizations globally, most in the United States, and 68 percent were in the higher education sector. Universities have run PeopleSoft for decades to handle student records, financial aid, and HR, and too many instances still sit on the public internet with legacy configurations. ShinyHunters knows this ecosystem well, and this time they skipped credential stuffing and went straight to the application layer.

The technical details are straightforward but painful. The attackers scanned for exposed PSEMHUB endpoints and leveraged the missing authentication for critical function to gain code execution. There is an interesting operational nugget: public posts from @nahamike01 on X highlighted open attacker directories on staging servers, which gave GTIG a rare direct look at the tooling and files being staged before exfiltration. That kind of sloppy infrastructure is unusual for a group this prolific, but it gave defenders a useful window.

CISA moved quickly. On June 12 the agency added CVE-2026-35273 to the Known Exploited Vulnerabilities catalog, and BOD 26-04 now requires federal agencies to check for pre-patch compromise rather than just applying the fix and moving on. The directive explicitly prioritizes rapid remediation of high-risk vulnerabilities on publicly exposed assets that grant total control post-exploitation, which describes this flaw exactly.

Practical takeaway: if you run PeopleSoft, treat CVE-2026-35273 as an incident response trigger, not just a patch ticket. Verify whether any Environment Management Hub or PSEMHUB endpoints were internet-facing between May 27 and June 9. Patch immediately, then review logs for unauthorized access, hunt for web shells or newly created accounts, and perform a full compromise assessment. If you are FCEB, document that assessment for BOD 26-04 compliance. If you cannot say for certain whether your ERP is exposed to the internet, that is your Monday morning project.

CISA added CVE-2026-10520 to the Known Exploited Vulnerabilities catalog this week, and the detail that matters is not just another Ivanti edge appliance getting command-injected in the wild. It is the formal activation of BOD 26-04, which changes how federal agencies must respond to active exploitation.

The vulnerability is an OS command injection in Ivanti Sentry, the API gateway that typically sits in front of mobile device management stacks. Sentry is internet-facing by design, which means this flaw likely grants total control of the host without user interaction. CISA explicitly states that evidence of active exploitation drove the KEV entry, so this is not theoretical.

What makes this addition different is the policy wrapper. BOD 26-04 updates the old BOD 22-01 checklist approach with risk-based triage. Federal Civilian Executive Branch agencies must now prioritize rapid remediation for KEV-listed CVEs on publicly exposed assets that grant total control post-exploitation, while lower-risk bugs can be deferred. More importantly, the directive establishes baseline expectations that agencies check for threat actor compromise before they apply the patch. That is a significant operational shift.

That pre-patch compromise check sounds obvious, but it is a heavy lift in practice. Most FCEB shops lack clean pre-exploitation baselines or immutable logging on edge gateways. If an agency simply patches CVE-2026-10520 without pulling Sentry logs, hunting for web shells, or auditing OS-level accounts, they risk sealing an attacker inside a patched but still-compromised box. And Ivanti edge products have been a recurring theme in KEV for years. If you are still running Sentry on a public IP without an incident response maintenance window, this should not be a surprise.

Practical takeaway: If you run Ivanti Sentry, treat CVE-2026-10520 as an active incident, not a patch ticket. Pull the appliance off the public internet until you can patch, or at minimum put it behind a reverse proxy with strict WAF rules. Before you patch, preserve logs and check for unexpected OS accounts, cron jobs, or web root artifacts. If you are in the FCEB, read BOD 26-04 carefully because your vulnerability management SLA is now tied to asset exposure and post-exploitation risk, not just CVSS. If you cannot tell me whether your Sentry instance was scanned in the last 72 hours, start there.

CISA's June 9 KEV update dropped three vulnerabilities into the catalog, and the spread of affected products tells the story: attackers are not picky about where they get initial access. The most visible addition is CVE-2026-11645, an out-of-bounds read and write in Google Chrome's V8 JavaScript engine. It is reported as actively exploited in the wild with a CVSS score of 8.8, affecting versions prior to 149.0.7827.103. A V8 renderer bug like this is typically exploited via drive-by compromise or malicious web content, which makes it a direct threat to any endpoint that browses the internet, including your SOC analysts' workstations and executive laptops.

The other two additions hit infrastructure that defenders often deprioritize because it does not show up in standard Windows patch reports. CVE-2026-7473 affects Arista's Extensible Operating System, specifically an incomplete comparison with missing factors that CISA confirms is under active exploitation. CVE-2026-20245 targets Cisco Catalyst SD-WAN Manager with an improper encoding or escaping flaw that is also being actively targeted. I do not have CVSS scores for either yet, but KEV inclusion means CISA has verified exploitation, and that is the only severity rating that matters in my book.

What stands out is the operational breadth across the stack. A browser bug gives you userland initial access on a trusted endpoint. An SD-WAN manager bug potentially gives you control over branch connectivity, policy enforcement, and VPN paths. An EOS bug sits on the network fabric itself. An actor chaining even two of these could move from a malicious web page through the perimeter and into the switching layer without ever touching a domain controller or a VPN concentrator.

Practical takeaway: If your vulnerability management program is still organized around Patch Tuesday and Microsoft CVSS thresholds, this week is a good time to fix that. Check your asset inventory for Chrome builds older than 149.0.7827.103, Arista EOS deployments, and Cisco Catalyst SD-WAN Manager appliances. Patch all three this week. If you cannot patch the network gear immediately, pull their management interfaces off the public internet, segment them behind a jump host, and enforce strong authentication until you can. And if you do not have an inventory that covers browser versions, switch firmware, and SD-WAN controllers in the same query, that is the project for Monday morning.

CISA's Monday KEV drop landed two vulnerabilities that sit on opposite ends of the modern stack, and both are already under active exploitation. The first is CVE-2026-42271, a command injection in BerriAI LiteLLM, the open-source proxy that sits between applications and large language model APIs. The second is CVE-2026-50751, an improper authentication vulnerability in Check Point Security Gateway appliances.

The LiteLLM flaw is the one that should make AI teams nervous. It is reported as an authenticated command injection, meaning any user with valid credentials can run arbitrary commands on the host running the proxy. In practice, that turns your LLM middleware into a pivot point for lateral movement, especially if the LiteLLM instance has access to internal model endpoints, vector databases, or cloud API keys. I have seen too many AI projects spin up LiteLLM on internet-facing infrastructure with default configs and no network segmentation.

Then there is the Check Point gateway bug. Improper authentication on a security appliance is a special kind of problem because the device is supposed to be the control point, not the target. CISA does not need to detail the exploit chain for the risk to be obvious: if an attacker can abuse the authentication mechanism on a perimeter gateway, they own the policy enforcement point that everything else trusts.

What ties these together is not the vendors or the attack surface, but the deployment pattern. Both are infrastructure components that get stood up quickly, trusted heavily, and patched slowly. LiteLLM instances are often treated like internal plumbing despite handling external model traffic, and firewalls are assumed to be self-defending until they are not.

Practical takeaway: if you are running LiteLLM anywhere in your AI stack, treat this as an emergency patch. Verify the instance is not internet-exposed, rotate any API keys it had access to, and audit its host permissions. For Check Point, check the vendor portal for the CVE-2026-50751 patch and verify your gateway management interfaces are not reachable from untrusted networks. Monday morning is a good time to stop trusting infrastructure to patch itself.

Cisco dropped a zero-day warning Thursday that I flagged immediately. CVE-2026-20245 is a high-severity flaw in Cisco Catalyst SD-WAN Manager, actively exploited in the wild, with no patch available. It grants root privilege escalation and hits every deployment flavor: on-prem, Cloud-Pro, Cisco-managed cloud, and the FedRAMP government variant. CVSS 7.8.

This is a control-plane nightmare. SD-WAN Manager is the brain that pushes policies, certificates, and routing logic to every branch and data center edge. Root access here does not require an attacker to hop from site to site; they simply reconfigure the network to route traffic wherever they want, disable segmentation, or inject backdoors into device templates before they ever reach the edge. I am not usually alarmist about WAN bugs, but this is not lateral movement; it is an adversary who owns the central nervous system.

Cisco has acknowledged active exploitation but has not released full TTPs, exploitation timeline, or whether the attacks are targeted or indiscriminate. The attack surface is almost certainly the Manager's web or API interface, which means either an internet-exposed management portal or an internal host that can reach it. If your network team treats the Manager as a trusted internal asset with flat segmentation, that assumption just collapsed.

The FedRAMP inclusion is worth noting. Government SD-WAN instances running under FedRAMP authorization are supposed to withstand sustained targeting, yet they are vulnerable to the same unpatched root escalation as commercial clouds. That tells me the flaw is deep in the shared codebase, not a configuration edge case.

Practical takeaway: with no patch, this is a harden-and-hunt play. If your Catalyst SD-WAN Manager is internet-facing, remove it from the public internet immediately and place it behind a bastion host with strict IP allow-listing and MFA. Audit every local and remote admin account for unauthorized creation or privilege changes. Enable and review configuration change logs for every policy push, device template update, and certificate event going back 30 days. If you cannot explain a change, roll it back and investigate. Start Monday by asking who has root access to your WAN brain, and whether you would notice if they were not supposed to be there.

CISA dropped CVE-2026-28318 into its Known Exploited Vulnerabilities catalog this week, and it is a reminder that denial-of-service bugs deserve the same urgency as remote code execution when they hit edge infrastructure. The flaw affects SolarWinds Serv-U, a multi-protocol file server that sits on the perimeter handling SFTP, FTPS, and HTTPS transfers, and it is being actively exploited to crash the service.

Serv-U has been on attacker radar before. I still remember the 2021 RCE chain that gave threat actors a foothold in downstream networks. This time it is a DoS condition with a CVSS score of 7.5, but the operational impact is nearly as severe. When a managed file transfer gateway goes down, it does not just cause an outage; it breaks automated ingestion pipelines, halts backup windows, and can blind security teams if log forwarding is funneled through the same path.

What bothers me is how quickly a DoS label gets a vulnerability deprioritized in patching queues. I have seen risk committees kick availability bugs to next quarter because they are not remote code execution. But CISA does not add bugs to KEV because they are theoretically dangerous. They add them because someone is weaponizing them right now against real targets. On internet-exposed file transfer infrastructure, an availability hit is often indistinguishable from a targeted attack, especially if the crash is used to cover follow-on activity or force admins to expose recovery interfaces.

Practical takeaway: if you have Serv-U anywhere in your environment, find it this week. These instances are often spun up by application teams and forgotten on the edge. Verify your version against SolarWinds release notes, treat unexpected service crashes as potential exploitation rather than routine instability, and if you do not need the web management console or anonymous access, turn them off. If you cannot patch immediately, at least get the instance behind a VPN or restrict upstream sources until you can.

Eight federal agencies signed this one. CISA, FBI, NSA, DoE, EPA, TSA, DOT, and USDA dropped a joint advisory on automatic tank gauge systems this week, and the sheer number of seals on the page tells you how broadly this exposure cuts. ATGs are the remote monitoring backbone for fuel storage, chemicals, agriculture, and transportation, and right now too many of them are sitting directly on the public internet with weak or default authentication.

The authoring organizations say they are tracking malicious cyber activity against U.S.-based ATG systems. These devices monitor tank levels, temperature, and leak detection, and they are widely deployed across sectors that do not always get the same security attention as enterprise IT. The advisory explicitly notes that the U.S. government has not attributed this activity to a nation-state actor, which makes the campaign feel more like opportunistic infrastructure scanning than a targeted APT operation, though the operational impact is identical.

What strikes me is the simplicity of the attack surface. There is no CVE chain here, no zero-day exploit, no sophisticated malware. This is internet-facing ATG management interfaces protected by default or easily guessed credentials, giving remote actors direct access to tank telemetry and potentially to control functions. If you can Shodan for tank monitoring panels and log in with a weak password, you are inside the process environment without ever touching the endpoint detection stack or firing a single exploit.

These systems often fall into the gap between facilities maintenance and cybersecurity teams. They were deployed years ago for remote convenience, letting a fuel vendor or maintenance contractor check levels without a site visit, and nobody remembered to pull them back behind a VPN or a jump host when the threat model changed. That organizational gap is exactly what this advisory is trying to close before disruption becomes physical.

If you operate in energy, chemical, food and agriculture, or transportation, find every ATG on your network this week. Pull them off the public internet immediately, place remote access behind a properly authenticated jump host, enforce strong unique passwords or certificate-based auth where the device supports it, and audit who actually needs remote telemetry access. If your facilities team manages the device and your security team does not know the IP range, that coordination meeting is Monday morning's priority.

CISA added CVE-2026-28318 to the Known Exploited Vulnerabilities catalog on Friday, flagging an uncontrolled resource consumption bug in SolarWinds Serv-U as actively exploited. Serv-U has appeared on this list before, and seeing it return is a clear signal that edge file-transfer infrastructure remains a reliable target.

The vulnerability class is worth a closer look. Uncontrolled resource consumption is not a remote code execution flaw, but CISA does not add bugs to the KEV catalog unless they are being leveraged in real intrusions. These issues can be used to degrade service and disrupt monitoring ahead of a broader attack, or simply to knock a critical file transfer node offline during an extortion attempt.

The pattern matters more than the individual CVE. File transfer appliances have become a persistent attack surface. MOVEit, GoAnywhere, and Serv-U itself have all been hammered because they sit on the perimeter, handle bulk sensitive data, and often bridge external partners to internal storage. Attackers scan for them constantly, and they tend to live in network segments that are patched on slower cycles than public web servers.

CISA's BOD 22-01 gives federal agencies a remediation deadline, but the exploitation is not limited to government networks. In private environments, Serv-U instances frequently hide in OT-adjacent DMZs or partner-facing subnets that do not get the same scrutiny as corporate SaaS apps. Those are the instances that will get hit first.

Practical takeaway: patch CVE-2026-28318 this week if Serv-U is anywhere in your environment. Then audit every file transfer and remote administration tool on your edge for internet exposure, enforce IP allow-listing where possible, and set resource monitoring alerts on those hosts. A sudden spike in CPU or memory on a file transfer server should trigger an incident response check, not just a performance ticket.

CISA added CVE-2026-45247 to the Known Exploited Vulnerabilities catalog on Wednesday, and it is a sharp reminder that Magento third-party extensions remain prime real estate for attackers. The vulnerability is a deserialization flaw in Mirasvit's Full Page Cache Warmer, a popular Adobe Commerce extension, and CISA lists it as actively exploited in the wild. Reports put the CVSS score at 9.8, which fits for a deserialization bug in an internet-facing storefront component.

Deserialization bugs in PHP storefront extensions are especially ugly. The cache warmer is designed to sit on the edge, trigger page renders, and keep the site fast. That usually means it is internet-facing and running with privileges that let it touch the Magento core. An attacker who can feed a malicious serialized object to that component does not need a zero-day in Adobe Commerce itself; they can just ride the extension straight into the application server.

I am not surprised this made KEV. E-commerce targets are catnip for ransomware affiliates and payment-skimmer groups, and Magento extensions have a long history of weak input validation. What frustrates me is how often these plugins are installed by a marketing team or contractor, then forgotten until they show up in an advisory. If your storefront is running Mirasvit Cache Warmer unpatched, you are one crafted request away from a full compromise.

CISA's inclusion triggers BOD 22-01 deadlines for federal agencies running the software, but the signal applies everywhere: this is under active exploitation now, not someday.

Practical takeaway: if you run Adobe Commerce or Magento 2, inventory your Mirasvit extensions today and patch CVE-2026-45247 immediately. If you cannot patch, block external access to the cache-warmer endpoints at the WAF or edge and start hunting your web logs for suspicious POST bodies containing serialized PHP objects or unexpected requests to Mirasvit routes. Do not wait for the next shopping season to find out you are already hosting a skimmer.

CISA added two vulnerabilities to the KEV catalog this week, and only one of them is new. CVE-2025-48595 is the Android Framework integer overflow that Google patched in its June 2026 bulletin, a privilege escalation with no user interaction that is already under targeted exploitation. The other is CVE-2022-0492, a Linux kernel improper authentication bug from 2022 that is still being actively exploited four years later.

The Android zero-day is urgent if you manage corporate mobile fleets, but the Linux entry is the one that should keep infrastructure teams awake. CVE-2022-0492 is the cgroup v1 release_agent flaw that allows container escape. An attacker with code execution inside a container can break out to the host kernel. Public exploits have circulated since early 2022, which means this is not a novel technique. It is a reliable, well-documented TTP that is still working because too many hosts never got patched.

This is exactly the kind of long-tail vulnerability that gets overlooked in cloud and on-prem environments. Container orchestration nodes, CI/CD build servers, and legacy Linux appliances often run kernels on patch schedules measured in years, not days. Threat actors know this. They do not need a zero-day when a four-year-old container escape will open the door just as cleanly.

The pairing also reveals attacker pragmatism. CVE-2025-48595 shows continued investment in mobile surveillance and espionage entry points, while the 2022 kernel bug shows a willingness to mine old ground for unpatched infrastructure. Both are efficient. Neither requires custom exploit development against hardened targets.

Practical takeaway: This week, audit your Linux fleet for kernel versions vulnerable to CVE-2022-0492, with special attention to container hosts and build nodes that avoid reboots. Patch or replace them. If you run managed Android devices, push the June 2026 security patch through MDM immediately. Finally, automate KEV ingestion across your entire asset inventory, not just your Windows endpoints, so a four-year-old bug does not sit undetected for another four years.

CISA added CVE-2024-21182 to the Known Exploited Vulnerabilities catalog this week, and the only surprising part is that anyone is still surprised by Oracle WebLogic showing up on the list. This is a server class that should have been sunset years ago, yet it remains a reliable initial access vector because organizations simply cannot locate every instance they are running.

The vulnerability is rated 7.5 on the CVSS scale and is characterized as allowing an unauthenticated attacker with network access to take control of the server. CISA's advisory does not detail the specific exploitation mechanism, but the pattern for WebLogic is well established: exposed administration or T3 interfaces on TCP/7001 and TCP/7002, followed by deserialization or console bypass, leading to immediate code execution as the service account. Oracle addressed this flaw in its 2024 Critical Patch Update, meaning the remediation has been available for approximately two years. Its appearance in KEV now confirms that attackers are still finding unpatched targets at scale.

The operational problem is rarely the patch itself. WebLogic instances are typically legacy application servers owned by development or application teams, not infrastructure or security, and they often live outside standard vulnerability management workflows. They get cloned, migrated, and forgotten. Worse, they frequently sit on internal flat networks or partner DMZs with firewall rules that predate zero trust by a decade. I have seen organizations discover production WebLogic consoles reachable from the guest wireless because of a mislabeled VLAN.

This is not a zero-day emergency. It is a hygiene and visibility failure. The exploit is public, the patch is tested, and the only variable is whether your asset inventory is lying to you about what Java middleware is actually listening on the network.

Practical takeaway: run an authenticated and unauthenticated sweep for TCP/7001 and TCP/7002 across your entire address space this week, including cloud VPCs and partner colocation. Anything running WebLogic goes on an emergency patch cycle for the latest Oracle CPU. Until you patch, block console and T3 access at the network layer to authorized jump hosts only, and alert on any inbound connection to those ports from non-management subnets. If you find a WebLogic instance that nobody owns, treat it as compromised until proven otherwise.

CISA added CVE-2026-0257 to the Known Exploited Vulnerabilities catalog on Friday, and this one deserves immediate attention if you run Palo Alto Networks PAN-OS firewalls with GlobalProtect. It is an authentication bypass in the VPN gateway, and CISA's inclusion means there is confirmed exploitation in the wild, not just a theoretical concern.

Palo Alto Networks disclosed the flaw earlier in the week and assigned it a CVSS score of 7.8, which lands it in the medium severity range on paper. That rating feels disconnected from the operational reality. An authentication bypass on a VPN concentrator lets an attacker establish a tunnel into your network without valid credentials, effectively erasing the perimeter for that session. Whether the bug is in the GlobalProtect portal or the Prisma Access edge, the result is the same: unauthorized internal access with whatever privileges the VPN profile grants.

The KEV designation triggers Binding Operational Directive 22-01 for federal agencies, which means FCEB shops now have a hard deadline to remediate. Private sector teams should operate on the same clock. CISA does not add vulnerabilities to this catalog lightly; the bar is evidence of active exploitation against real targets, not just a proof-of-concept on social media. If your PAN-OS gateways are internet-facing and running affected code, assume someone is already scanning for and attempting to leverage this bypass.

What bothers me is how often VPN concentrators still sit with their management and user portals exposed to the entire internet, maintained on quarterly patch cycles as if they were internal file servers. A device whose entire purpose is to extend the network boundary should not be treated like routine infrastructure when an authentication bypass drops.

Practical takeaway: patch your PAN-OS GlobalProtect gateways to the fixed releases Palo Alto has published, and do it before your next routine maintenance window. Pull GlobalProtect logs and look for successful VPN sessions from unexpected source IPs, geographies, or device profiles that do not match your asset inventory. If you cannot patch immediately, restrict VPN listener access to known source ranges and disable any unused GlobalProtect portals until you can. Your VPN concentrator is Tier 0 infrastructure; treat any authentication bypass on it as a full network compromise until you can verify otherwise.

Google Threat Intelligence Group caught UNC1069, a North Korea-nexus actor, pushing malware through the axios NPM package on March 31. Between 00:21 and 03:20 UTC, the attacker added a malicious dependency called plain-crypto-js to axios releases 1.14.1 and 0.30.4, which together see roughly 183 million weekly downloads. That is a three-hour window where pulling the most popular HTTP client library in JavaScript silently dropped the WAVESHAPER.V2 backdoor onto Windows, macOS, and Linux build machines.

The payload is not a supply-chain footnote. plain-crypto-js is an obfuscated dropper that deploys WAVESHAPER.V2, an updated variant of a backdoor GTIG has previously tied to UNC1069. The cross-platform targeting tells me this is not opportunistic graffiti; it is a deliberate effort to compromise developer and CI/CD environments at scale. Infrastructure artifacts from the attack also overlap with past UNC1069 operations, which tracks with the group's financially motivated targeting of the software and cryptocurrency sectors.

What makes this sting is that axios is not a fringe package. It is a foundational dependency. When a first-party package with this much reach gets trojanized, traditional dependency scanning that looks for known vulnerable versions or transitive risk scores can miss the blast radius. Your build likely trusts axios implicitly, and if your pipeline pulled 1.14.1 or 0.30.4 during that UTC window, you ingested a dropper before most of the world had coffee.

Practical takeaway: hunt your lockfiles, SBOMs, and artifact caches immediately for plain-crypto-js and for axios versions 1.14.1 and 0.30.4 pulled between March 31 00:21 and 03:20 UTC. If you find them, treat the host as compromised and rotate every secret that touched that build. Then audit your own NPM publish pipeline this week: enforce MFA on all maintainer accounts, scope publish tokens to the minimum required, and verify that no unexpected dependencies were added to packages under your control. Supply chain integrity starts at home.

Google Threat Intelligence Group's latest AI Threat Tracker landed this week, and the headline is less science fiction and more productivity software. GTIG says that in the final quarter of 2025 it observed threat actors increasingly integrating artificial intelligence across the attack lifecycle, including reconnaissance, social engineering, and malware development. The goal is not to invent new exploit classes, but to execute existing ones faster and at greater scale.

The more technically specific finding is a measurable spike in model extraction attempts, or "distillation attacks," targeting Google's own AI services. These attempts aim to steal model weights or intellectual property by systematically querying APIs and rebuilding a local copy, which violates terms of service but is clearly valuable enough that Google is actively detecting and disrupting the activity. GTIG explicitly notes it has not yet observed direct attacks on frontier models or generative AI products from advanced persistent threat actors, which is worth repeating before anyone spins this into an AI apocalypse narrative.

What this means operationally is that the barrier to entry for competent social engineering and malware variation is dropping. An actor with access to a mainstream large language model can generate convincing phishing pretexts, localize them for specific regions, or refactor code to evade signature-based detection without needing native language skills or a dedicated development team. The TTPs are not novel, but the velocity, volume, and polish are.

I have seen defenders freeze waiting for some mythical AI attack while missing the fact that their inboxes are already filling with LLM-polished business email compromise lures. The distillation angle matters too: if your organization exposes AI APIs to partners or the public, you are now a target for intellectual property theft, not just data theft. Both trends point to the same conclusion: AI is not replacing the attacker, it is augmenting them.

Practical takeaway this week: refresh your phishing simulation content to account for AI-generated fluency. Train users to look for messages that are grammatically perfect but contextually off, and to verify requests rather than trust tone. If you manage AI endpoints, implement query logging, rate limiting, and anomaly detection for repetitive structured probing that smells like model extraction. Do not wait for an APT to steal your model; mid-tier criminals and opportunists are already experimenting.

CISA published an alert this week on software supply chain intrusions targeting CI/CD pipelines, and one detail in particular made me stop scrolling. Threat actors compromised Nx developer systems and used a poisoned third-party Visual Studio Code extension -- Nx Console version 18.95.0 -- to compromise a GitHub employee's device. Because VS Code pushed the malicious build through its automatic update channel, machines with the extension already installed received the backdoored version without any manual action from developers. The result was unauthorized access to, and exfiltration of, internal GitHub repositories.

The technique is a straightforward abuse of trust in developer tooling. By hitting the Nx Console extension, the attackers gained a foothold on engineering workstations that likely had access to source code, secrets, and CI/CD workflows. CISA notes this is part of a broader pattern that includes the Megalodon campaign, and it all points to the same conclusion I have been reaching lately: CI/CD environments and the IDE extensions that feed them are now primary targets, not peripheral ones.

What bothers me is the auto-update vector. Most security programs I see spend enormous energy on container scanning and dependency checks, but treat IDE plugins as benign productivity tools. A compromised extension runs with the privileges of the developer, can read workspace secrets, and in this case served as the initial access point for a major code-hosting platform. CVE-2026-48027 captures the malicious Nx Console build, but the underlying problem is that we have allowed unattended software delivery directly onto the machines that build everything else.

Practical takeaway: audit every VS Code extension, JetBrains plugin, and IDE add-on in your environment this week. Disable automatic updates for anything that is not explicitly allowlisted and cryptographically verified. Map which developer machines and CI runners can reach sensitive repositories, and enforce least-privilege access so a single compromised workstation cannot walk out with your source code. If you cannot show me an inventory of your IDE extensions, that is your Monday morning project.

Mandiant refreshed its destructive attack preparation guide this week, and the timing is deliberate. The update explicitly ties spikes in destructive malware, wipers, and modified ransomware to geopolitical instability, treating cyber attacks as an inexpensive weapon that escalates alongside physical conflict. The March 13 addition that stood out is new guidance around the abuse or misuse of endpoint and MDM platforms, which signals that adversaries are leveraging trusted management infrastructure to prepare for widespread impact rather than relying solely on bespoke wipers.

The post frames destructive attacks as part of a broader kill chain that includes reconnaissance and privilege escalation. That tracks with operational reality: actors do not simply drop a payload and run. They establish persistence, move laterally, and use native tools and legitimate platforms to position for maximum damage before the final trigger.

What makes the guidance useful is that it is built to be practical and scalable, aimed at organizations that need to harden quickly without boiling the ocean. The emphasis on endpoint and MDM abuse is a clear reminder that your own management stacks can be turned against you, and that defenders need to scrutinize internal platforms with the same skepticism they apply to perimeter threats.

Practical takeaway: audit your MDM and endpoint management platform configurations this week. Ensure administrative interfaces are not internet-facing, enforce MFA on all management accounts, and monitor for anomalous policy pushes or mass agent uninstalls. If you do not have offline backups and a tested gold image ready for critical systems, make that your Friday project.

GTIG published its breakdown of DarkSword this week and the detail that pulled me in was not just the technical stack, though six zero-days in a single iOS full chain is notable. It is the speed at which the capability is propagating across completely unrelated threat actors. DarkSword targets iPhones running iOS 18.4 through 18.7, and since at least November 2025 it has already shown up in the hands of multiple commercial surveillance vendors and suspected state-sponsored actors hitting targets in Saudi Arabia, Turkey, Malaysia, and Ukraine.

The exploit chain does not stop at initial compromise. After a successful exploit, DarkSword deploys one of three distinct final-stage payloads that GTIG calls GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER. The campaign that worries me most is UNC6353, the suspected Russian espionage group previously linked to the Coruna iOS exploit kit, now integrating DarkSword into watering hole operations. We watched Coruna follow the same arc: from a surveillance vendor customer to UNC6353, and later to a Chinese financially motivated actor running broad campaigns. DarkSword appears to be on an identical trajectory.

This collapses the usual distinction between commercial surveillance and nation-state espionage. iOS is often treated as the harder target in an enterprise fleet, a soft control relied on by executive protection programs, journalist safety workflows, and regional operations in high-risk areas. DarkSword cuts through that assumption on fully patched devices through 18.7 with no user interaction required beyond visiting a watering hole. If your threat model assumes that current-gen iOS and a standard MDM enrollment are sufficient for high-risk users, this chain invalidates it.

Practical takeaway: audit your mobile fleet and network telemetry this week. Get high-risk users onto the latest available iOS version immediately, enforce Lockdown Mode for anyone with a credible targeting risk, and verify that your MDM is actually applying supervised policies rather than just enrolling devices. More importantly, review your network logs for anomalous iOS traffic that might match GHOSTBLADE, GHOSTKNIFE, or GHOSTSABER C2 patterns. At this stage of proliferation you are far more likely to catch the post-exploitation beacon than the zero-day itself. If your iOS visibility is not on par with your Windows endpoint detection, that is the gap to close before Monday.

Mandiant published a deep look at the ransomware economy this week and the headline is not what most executives want to hear: the business is getting worse for the criminals. After years of RaaS commoditization lowering barriers to entry, operator profitability is now in measurable decline. The drivers are exactly what defenders have been working toward -- improved security practices, faster organizational recovery, and steadily dropping ransom payment rates. Layer on law enforcement disruptions and the profit squeeze is real.

I read this as a pivot point, not an all-clear. Financially motivated actors do not retire when margins shrink; they adapt. The report frames this as a shift in TTPs, and historically that means harder extortion leverage, more selective targeting, or a turn toward destructive outcomes when payment looks unlikely. An oversaturated affiliate market also means more variable operator quality -- some incidents will be amateur hour, but the mature groups will refine targeting to maximize yield per intrusion.

The operational detail that matters most is the specialization. Initial access brokers, payload developers, and negotiators now operate as separate services. That modularity means a single compromise can pass through several criminal vendors before encryption, which complicates attribution and makes intrusion timelines less predictable. For incident responders, the ransomware event is increasingly a supply chain of underground services rather than a single actor with a single toolkit.

Practical takeaway: audit your recovery posture this week, not just your prevention stack. Pick one business-critical system and execute a full restore from immutable backups without relying on your production network or internet-facing management portals. Time the recovery. If your backup console requires domain credentials or cloud connectivity that an active intruder could disable, that is your Monday project. The actors feeling margin pressure are already prioritizing backup and recovery infrastructure before they drop payloads.

CISA dropped AA26-097A this week and it pulled me right in. Iran-linked actors are back in U.S. critical infrastructure, and they are not bothering with fancy zero-days. They are walking through the front door on internet-exposed PLCs.

The advisory, co-sealed by CISA, FBI, NSA, EPA and DoE on April 7, names the target: Rockwell Automation / Allen-Bradley PLCs sitting on the public internet. The operators are reaching in with Studio 5000 Logix Designer from leased overseas infrastructure, opening legitimate sessions to the controllers, and messing with project files and HMI/SCADA displays. Water and wastewater, local government, and energy sector victims have already reported operational disruption.

If the TTPs sound familiar, they should. This lines up with CyberAv3ngers, aka Shahid Kaveh Group, the IRGC Cyber Electronic Command crew that lit up the Aliquippa water authority back in 2023 by hitting Unitronics Vision PLCs with default creds. Same playbook, new vendor. Escalation is tracking with the current Iran / U.S. / Israel tensions, and NERC says it is actively watching the grid.

What bugs me is that none of this requires a CVE. It is exposed ICS on TCP/44818 and 2222, weak or default authentication, and engineering workstations trusting any source that speaks EtherNet/IP. A Shodan query and a copy of Studio 5000 is most of the kill chain.

Practical takeaway: if you own OT, stop assuming obscurity is a control. Pull your PLCs off the public internet today, put them behind a properly segmented DMZ with a jump host, enforce CIP Security or at minimum strong auth, and alert on any Logix session from an unknown source. If you cannot tell me the last time someone audited your HMI's exposure, that is the project for Monday morning.