> Blog_

CISA added CVE-2026-85706 to the Known Exploited Vulnerabilities catalog this week, and it is a GitLab path traversal flaw hitting both Community Edition and Enterprise Edition. That should raise alarms for anyone running self-hosted GitLab on the public internet, which is still far too common.

The vulnerability is a path traversal in GitLab CE and EE. While CISA's advisory does not spell out the full exploit chain, path traversal in GitLab typically translates to arbitrary file read. On a code hosting platform that stores source code, CI/CD variables, and embedded secrets, that is not merely a confidentiality issue; it is a direct line into your software supply chain.

What worries me is how often GitLab ends up internet-facing without the security team knowing. Developers spin up instances for collaboration, expose them for remote access, and forget to log them in the asset inventory. BOD 26-04 forces federal agencies to prioritize KEVs like this on publicly exposed assets, but private sector defenders should treat it with the same urgency. A quick Shodan query will show you exactly how common this exposure is.

I am also thinking about post-exploitation. Even if the initial access is limited to file read, that is usually enough to harvest runner tokens, Kubernetes configs stored in project variables, and hardcoded credentials in repositories. From there, pivoting into production is often just a matter of following the automation. This is not a theoretical chain; it is how modern intrusions start.

Practical takeaway: if you run GitLab CE or EE, patch CVE-2026-85706 now, but first make sure your asset inventory actually knows about every instance. Pull self-hosted GitLab off the public internet if you can, and put it behind a VPN or zero-trust access proxy. If it must remain exposed, review access logs for anomalous file or repository access, and rotate any secrets stored in CI/CD variables or project settings this week. If GitLab is not in your vulnerability management program, that is the project for Monday morning.

CISA added three new entries to the Known Exploited Vulnerabilities catalog on Friday, and the alert doubles as the first real exercise of Binding Operational Directive 26-04. The directive moves federal vulnerability management to a risk-based model, and these three CVEs are exactly the kind of publicly exposed, total-control flaws that agencies are now expected to prioritize over lower-risk findings.

The new entries are CVE-2026-42016 and CVE-2026-42018 in JFrog Artifactory, described as incorrect authorization and improper authentication vulnerabilities, plus CVE-2026-84869 in ConnectWise ScreenConnect, an improper privilege management and missing authorization bug. All three are access-control defects rather than memory corruption, which means exploitation does not require sophisticated exploit chains, only a reachable endpoint and a missing check.

Artifactory is the entry that concerns me most. It sits at the heart of CI/CD pipelines, stores binaries, credentials, and build configurations, and if an attacker can bypass authentication or authorization, the supply chain downstream is at risk. ScreenConnect is a perennial target for remote access exploitation, so its presence here is expected, but the JFrog pair signals a continued shift toward attacking the toolchain itself.

BOD 26-04 makes explicit what good defenders already practice: federal agencies must now remediate KEVs fastest when they live on publicly exposed assets and grant total control post-exploitation, while lower-risk vulnerabilities can be deferred. The catch is that this only works if your asset inventory and exposure data are accurate. If you are treating an internal Artifactory instance as not exposed because it lacks a public IP, but it is reachable from a compromised developer VPN or a peered cloud VPC, your risk calculation is wrong.

Practical takeaway: If you run Artifactory or ScreenConnect, treat these CVEs as live threats regardless of your federal status. For Artifactory, audit authentication and authorization settings, remove internet-facing exposure, and verify that administrative interfaces require strong authentication. For ScreenConnect, restrict management planes to known IP ranges and apply the vendor fix. And if you are adopting BOD 26-04 style risk-based triage, audit your exposure assumptions this week, because a stale CMDB is now both a compliance and a security failure.

CISA dropped two MikroTik RouterOS vulnerabilities into the KEV catalog this week, and I read the entries twice. CVE-2026-67277 is a missing authentication bug for a critical function, while CVE-2026-86060 is an improper neutralization of argument delimiters in a command. Neither requires user interaction or a foothold on the internal network; these are direct shots at the router itself.

MikroTik hardware is the invisible backbone of a lot of networks. ISPs, wireless internet service providers, small business edge deployments, and remote office routers all run RouterOS, and too many of them are managed with a set-and-forget mentality. That is exactly why they keep showing up in KEV alerts. The typical exposure is Winbox or Webfig facing the internet because someone enabled remote access and never restricted it. An unauthenticated attacker exploiting CVE-2026-67277 gains access to a critical function without credentials, and CVE-2026-86060 suggests command injection through delimiter abuse. That is not just a configuration leak; it is code execution on the device that controls your traffic flow, NAT rules, and any VPN tunnels passing through it.

This falls under BOD 26-04, so federal agencies must patch these on publicly exposed assets immediately and assess whether the systems were compromised before the fix. I treat any KEV-added router vulnerability as an active incident until I can prove otherwise, and the rest of the private sector should operate the same way. A compromised edge router does not just go down; it becomes a silent gateway. Attackers can redirect DNS, proxy traffic, or drop selective packets without ever touching a server behind it.

Practical takeaway: if you have MikroTik devices in your environment, inventory them today and kill any internet-facing management interface. Patch to the latest stable RouterOS release, restrict Winbox and Webfig to a dedicated management segment or jump host, and verify your firewall rules are not accidentally exposing port 8291 or 80/443 on the WAN side. Because BOD 26-04 now expects pre-patch compromise checks, inspect every device that was exposed while unpatched. Look for unauthorized admin accounts, unexpected scheduler entries, or SOCKS proxy rules you did not create. If you cannot tell me the last time you audited your edge router exposure, that is Monday morning's project.

CISA dropped four new KEV entries this week and the pattern is impossible to miss. CVE-2026-19490 in Citrix NetScaler, CVE-2026-20079 in Cisco Firewall Management Center, CVE-2025-25249 in Fortinet products, and CVE-2026-87491 in Google Chromium V8 are all under active exploitation. Three of the four target network or security infrastructure, and two are authentication bypasses using alternate paths or channels.

The auth bypasses are the ones that worry me most. CVE-2026-19490 on NetScaler and CVE-2026-20079 on Cisco FMC are management-plane flaws. NetScaler ADCs sit in front of critical applications in almost every enterprise, and FMC is the brain of a Cisco firewall deployment. An authentication bypass on either does not require phishing or a compromised endpoint; if the management interface is reachable, an attacker walks straight into the control plane. That is total compromise of the asset with a single request, which is exactly the kind of exposure CISA is targeting with BOD 26-04.

The Fortinet heap overflow, CVE-2025-25249, and the Chrome V8 out-of-bounds write, CVE-2026-87491, round out the set. Fortinet bugs in SSL VPN and firewall services have been reliable targets for years, and a browser vulnerability like the V8 flaw gives attackers a foothold on the endpoint. But the operational through-line here is that all four grant total control post-exploitation on publicly exposed assets. CISA is no longer just cataloging these; under BOD 26-04, federal agencies must remediate them rapidly.

What bugs me is that we are still finding NetScaler and FMC management interfaces on the public internet. These are not user-facing portals. They are infrastructure controls that should never be reachable without a jump host or at minimum a tightly restricted DMZ.

Practical takeaway: audit your external attack surface this week for Citrix NetScaler and Cisco FMC management interfaces. If they are internet-facing, patch to a fixed version or pull them behind a segmented jump host immediately. For the Chrome V8 bug, ensure your enterprise browser update cycle is catching the latest stable channel. If your vulnerability management program treats authentication bypasses on edge appliances as medium priority because the CVSS vector lacks complexity, recalibrate. These are your highest-risk tickets.

CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog on Tuesday, and the list reads like a cross-section of the enterprise attack surface: Adobe Commerce, Microsoft Windows, and N-able's N-central RMM platform. Under BOD 26-04, federal agencies must now prioritize these on any publicly exposed asset that grants total control post-exploitation, which means all four just jumped to the front of the federal queue.

The Adobe entry, CVE-2026-75650, is a template engine improper neutralization flaw in Magento and Adobe Commerce. Bleeping Computer reports it is a zero-day dubbed StyleSmuggler, rated critical, and already being abused to backdoor servers. If you are running an e-commerce stack, this is full-compromise territory with a direct internet attack surface.

The N-able entry, CVE-2026-86218, is a static code injection vulnerability in N-central, the RMM platform used by countless MSPs to manage downstream customer endpoints. N-able has shipped four hotfixes in five weeks for this platform, and the vendor messaging is contradictory: the incident notice says the flaw has been exploited in the wild, while the release notes say that is unconfirmed. That discrepancy matters because an RMM breach does not just own the server; it owns every endpoint the MSP touches.

The two Windows additions, CVE-2026-81963 and CVE-2026-85880, are a link-following bug and a heap-based buffer overflow. They are serious, but they are also the kind of flaws we expect in a standard patch cycle. The Adobe and N-able entries are the outliers because they sit on internet-facing infrastructure and deliver immediate, high-privilege access without user interaction.

Practical takeaway: if you run Adobe Commerce or Magento, patch now and hunt for backdoors in parallel; assume compromise if the server was internet-facing. If you are an MSP or rely on N-central, pull the management interface off the public internet, enforce MFA on every technician account, and audit agent deployment logs for unauthorized packages. For federal FCEB shops, BOD 26-04 makes these four non-negotiable this week. Everyone else should treat them with the same urgency.

SonicWall dropped an emergency notice this week that should ruin the sleep of anyone running an SMA1000 at the perimeter. The company confirmed two zero-day vulnerabilities are being actively exploited, and threat actors are chaining them to achieve remote code execution on the appliances.

I have watched edge security appliances become the favorite initial access target over the last few years. VPN concentrators and secure access gateways sit on the public internet by design, often with privileged tunnels straight into the internal network. When a vendor discloses not one but two zero-days under active exploitation against that exact chokepoint, the risk is not theoretical. It is a direct line into the environment.

The SMA1000 is marketed as a secure mobile access solution, which means it typically lives in a DMZ with sessions tunneling straight through to production. If the attacker already has an exploit chain achieving RCE, they are likely dropping webshells, pivoting to identity infrastructure, or harvesting session cookies from active connections. SonicWall has not published full technical details yet, but the advisory language makes clear this is happening in the wild right now, not a proof-of-concept drop. That distinction matters because it means exploitation is already at scale.

What concerns me is the recurring pattern. We have seen this movie with Ivanti Connect Secure, Fortinet SSL-VPN, and Cisco ASA. Edge access gear gets zero-dayed, threat actors sit on it for days or weeks, and defenders find out only after the vendor announcement. The SMA1000 is widely deployed enough that SonicWall issued an emergency notice, which tells me the victim footprint is significant.

Practical takeaway: If you have an SMA1000 facing the internet, apply emergency firmware immediately. If you cannot patch today, restrict external access to specific source IPs or disable the external portal entirely until you can. Check appliance logs for unexpected administrative sessions, file drops, or outbound connections originating from the SMA1000 itself. If you do not have integrity monitoring on your VPN edge, that is your weekend project.

CISA published advisory ICSA-26-246-02 on the IXON VPN Client this week, and it pulled me right in. CVE-2026-75925 carries a CVSS 9.6 and affects VPN Client versions below 1.4.7. The product is deployed worldwide across water and wastewater, energy, critical manufacturing, and commercial facilities, so the blast radius is not theoretical.

The bug is a CRLF injection, CWE-93. The client runs a local service that accepts configuration values and writes them to a file later consumed by a privileged subprocess. Because the service does not neutralize line-ending sequences, an attacker can inject additional directives into that file. The advisory also flags CWE-306 as a contributing factor: the configuration interface accepts changes without authenticating the requester or verifying its origin. Unauthenticated input feeding a privileged parser is a classic recipe for disaster.

The result is remote code execution as root or SYSTEM. That is full compromise of the endpoint running the client. In critical infrastructure, these endpoints often sit at the boundary between enterprise IT and operational technology networks. An attacker who owns the VPN client can pivot, persist, and manipulate the very sessions meant to provide remote maintenance. It is a reminder that the tools we use to manage OT remotely are themselves high-value targets, and their compromise can undercut network segmentation that defenders rely on.

Practical takeaway: patch to 1.4.7 immediately, and do not assume the update will find itself. Build an inventory of every endpoint running IXON VPN Client, especially in OT zones, and verify that network access to the configuration interface is restricted to authorized hosts only. If your EDR or SIEM does not alert on anomalous child processes spawning from the IXON service account, add that detection this week. Finally, if your asset list still treats remote access clients as low-risk IT software, fix that taxonomy before an attacker does.

CISA's Friday alert added CVE-2026-85046 to the Known Exploited Vulnerabilities catalog, and it got my attention immediately. It is a type confusion bug in Google Chrome's V8 JavaScript engine, actively exploited in the wild, with a CVSS score of 8.8. Google patched it in Chrome 152.0.7977.82, but the KEV listing confirms threat actors are already using it for remote code execution through the browser before the fix is even widely deployed.

The TTP here is textbook. V8 type confusions give reliable heap corruption from malicious JavaScript or WebAssembly, which makes them a staple of exploit kits, targeted watering holes, and adversary-in-the-middle infrastructure. Attackers do not need local access or a zero-click vector; they just need a user to render a compromised or attacker-controlled page. That makes this an initial-access play capable of dropping a full implant, not a mere browser stability bug.

What makes this KEV entry operationally notable is BOD 26-04. CISA is explicitly tying this catalog addition to rapid-remediation requirements for Federal Civilian Executive Branch agencies, specifically when the vulnerability sits on publicly exposed assets and grants total control post-exploitation. The directive also expects agencies to check for pre-patch compromise rather than blindly patching and moving on. I like the risk-based framing; it acknowledges that a browser RCE on a bastion host is a different beast than a denial-of-service bug on an internal printer.

Practical takeaway: push Chrome, Edge, Brave, and any other Chromium derivatives to version 152.0.7977.82 or newer this week. Pay special attention to internet-facing systems where a browser session is the only barrier between an attacker and your network, like VDIs, jump boxes, or engineering workstations. If you cannot patch immediately, hunt for suspicious child processes spawned from Chrome or unexpected V8 JIT crashes in your endpoint telemetry. Treat browser RCE as infrastructure-critical until you are on the fixed build.

CISA added seven new entries to the Known Exploited Vulnerabilities Catalog this week, and the list is a reminder of how much infrastructure sits outside our standard patching routines. The September 2 update covers VPN appliances, phone systems, AI gateways, and CI/CD tools, all with confirmed exploitation in the wild.

The pair that demands immediate attention is CVE-2026-83548 and CVE-2026-83549 in SonicWall SMA1000 appliances. SonicWall confirmed active exploitation, with the SSRF flaw scoring a 10.0 CVSS and requiring no authentication. Attackers are chaining the two bugs for remote code execution on edge VPN devices. If you are running SMA1000, this is a full-stop moment.

The remaining five are less dramatic individually but just as risky operationally. CVE-2026-9586 is SQL injection in Sangoma Switchvox phone systems. CVE-2026-82329 is an authentication bypass in JFrog Artifactory. CVE-2026-59822 hits BerriAI LiteLLM, CVE-2026-49869 gives OS command injection in Kestra OSS, and CVE-2026-48710 is HTTP smuggling in Kludex Starlette. These are exactly the kinds of tools that get spun up without change control and never enter the enterprise patch cycle: AI proxies, build pipelines, and internal phone gear.

BOD 26-04 makes rapid remediation mandatory for federal agencies, but the KEV catalog is a useful signal for the rest of us. CISA does not add bugs to this list without evidence of active exploitation. When a vulnerability makes the cut, vendor severity ratings become secondary to the fact that someone is already weaponizing it.

Practical takeaway: audit for these seven products this week. Start with any SonicWall SMA1000 appliances on your perimeter; assume they are targeted and patch or isolate them immediately. Then hunt for shadow deployments of LiteLLM, Kestra, Starlette, Switchvox, and Artifactory, especially in dev and research teams that may not be on your standard asset inventory. If you find them, treat them as compromised until patched.

Forescout Vedere Labs dropped a proof-of-concept this week that made me pause. They used Anthropic's Claude to port a working pre-authentication remote code execution exploit from one WAGO PLC to a different model, and ran attacker-controlled ARM shellcode on live hardware. The target was CVE-2021-31886, a stack-based buffer overflow in the Nucleus FTP server's USER command handler that has been public since 2021.

What caught my attention is not the vulnerability itself. CVE-2021-31886 is five years old, and the Nucleus FTP stack has been a known weak point in embedded devices for years. The story here is the speed and fidelity with which a large language model closed the gap between one ARM-based PLC variant and another. Forescout says they fed the original exploit, target firmware, and hardware specs into Claude and got back a ported version that executed cleanly without manual reverse engineering of the second device.

This matters operationally because OT exploit development has traditionally been gated by scarce embedded-firmware skills and expensive hardware access. If an LLM can bridge model-to-model differences in a weekend, that barrier is eroding fast. The WAGO targets are running ARM Cortex processors with the Nucleus RTOS FTP service listening pre-auth, and the ported shellcode gave full system control. That is a pre-authentication RCE on industrial control hardware with minimal human effort.

I am not saying every script kiddie is about to own your plant floor. The researchers had the original exploit, firmware images, and likely iterated heavily. But the trend line is clear: AI is compressing the time between a CVE drop and a working OT exploit. For defenders who have been counting on attacker skill scarcity as an informal control, that math is changing. This does not create new vulnerabilities, but it accelerates the weaponization of existing ones across hardware variants we previously thought were obscure.

Practical takeaway: audit your WAGO and broader Nucleus FTP exposure immediately. If you have PLCs or embedded gateways running Nucleus NET or legacy FTP services, disable the FTP server if it is not operationally required, segment the device behind a unidirectional gateway or at minimum a properly configured OT firewall, and verify your asset inventory actually knows which models are in service. If your vulnerability management program still treats OT CVEs as theoretical because exploits are hard, this is your signal to update that assumption.

CISA added two PaperCut NG/MF vulnerabilities to its Known Exploited Vulnerabilities catalog on Monday, and both deserve more attention than print software usually gets. CVE-2026-81578 is a missing authentication for critical function vulnerability, while CVE-2026-82078 is an unsafe reflection flaw. Both affect PaperCut NG and MF, the print management suites that sit on more enterprise and education networks than most defenders realize, often with web interfaces facing internal VLANs or occasionally the public internet.

Print servers are perpetual blind spots. They are always on, rarely patched, and frequently expose admin interfaces that domain users can reach. A missing authentication bug in a critical function means an attacker can likely hit admin endpoints without credentials, and unsafe reflection in a Java-based application like PaperCut is typically a short hop to remote code execution or authentication bypass. When CISA drops two CVEs for the same product into the KEV catalog simultaneously, it usually means exploitation is reliable, low-complexity, and happening at scale against both public and edge-facing instances.

The addition comes alongside the continued rollout of BOD 26-04, which directs federal agencies to prioritize rapid remediation of high-risk KEVs on publicly exposed assets that grant total control after exploitation. The directive also establishes a concrete requirement that agencies check whether a system was compromised before the patch was applied. That is a notable shift in posture: CISA is explicitly telling defenders to assume breach and forensicate before they remediate, rather than simply patch and close the ticket.

If you run PaperCut NG or MF, treat it as a critical asset this week. Patch both CVEs immediately, and if you cannot, restrict access to the web interface and admin ports at the network layer. Audit where your print servers live; if they are reachable from the internet or overly broad internal segments, narrow that exposure now. Most importantly, check your logs for exploitation indicators before you apply the patch. CISA is signaling that post-patch forensics are now baseline expectations, and that discipline should extend well beyond the federal enterprise.

CISA published AA26-237A this week, and it is a rare side-by-side look at two live red-team assessments. The agency ran simultaneous exercises at two critical infrastructure organizations, and in both cases the red team achieved full domain compromise, accessed sensitive business systems, and reached cloud resources. The divergence was everything that followed.

Organization A never detected or contained a thing. The red team moved from initial access through domain compromise without friction. Organization B, facing the same adversary toolkit, caught the initial compromise attempts, isolated affected systems, and forced the red team into an assume-breach model. Same TTPs, same infrastructure complexity, two radically different defensive outcomes.

The advisory makes clear that the gap was not a shinier vendor stack. CISA flags untuned detection tools that flood operators with false positives and routine noise until real threats become wallpaper. Organization B had disciplined baselines and alert filtering; Organization A had alerts, but alerts without tuning are just logs with anxiety. When the red team crossed from IT into cloud and OT environments, silos and bureaucratic hurdles turned into containment failures.

What stands out is the operational detail. The red team did not need exotic zero-days. They needed an environment where detection engineering was an afterthought and where network, cloud, and plant-floor teams each owned a slice but nobody owned the handoffs. That is not a technology problem. That is a choreography problem.

Practical takeaway: audit your top ten detection rules this week. If a rule fires more than it fires true, tune it or trash it. Then run a cross-domain tabletop with IT, cloud, and OT that ends with a live isolation drill, not a policy review. If your team cannot sever a compromised host from the HMI network in under thirty minutes without a committee meeting, you are Organization A.

CISA issued an alert this week on active exploitation of CVE-2026-60004, a critical Gitea flaw scoring 9.8 that turns ordinary repository write access into remote code execution. Attackers are already abusing it in the wild, and the reported payload behaves like a cryptocurrency miner. That combination should get the attention of anyone running a self-hosted Gitea instance, especially if it faces the internet.

The vulnerability is as straightforward as it is dangerous: a user with write permissions to any repository can execute arbitrary shell commands as the Gitea service account. In most organizations, write access is not a high bar. Developers, contractors, automated service accounts, and even compromised partner accounts often have it. Gitea instances are frequently exposed so remote teams can collaborate, which means an attacker does not need stolen admin credentials or a complex authentication bypass. They just need a valid account that can push code, and from what I can see the kill chain is trivial.

A miner payload tells me this is likely opportunistic, mass-exploitation activity rather than a targeted intrusion. But that is cold comfort. The same primitive that drops a miner can modify repository contents, inject malicious CI/CD hooks, or pivot laterally from the Gitea host into the rest of the environment. If your Gitea server sits on your internal network with soft segmentation, or if it hosts source code that feeds into production build pipelines, the blast radius extends far beyond the initial host.

Practical takeaway: if you run Gitea, treat this as an emergency patch cycle. Pull the instance off the public internet unless it is absolutely required, restrict repository write access to the smallest possible set of verified users, and audit for unauthorized webhooks or post-receive scripts. On the host itself, hunt for unexpected child processes spawned by the Gitea service and suspicious outbound connections to mining pools. If you cannot patch immediately, disable external write access until you can. Monday morning is not soon enough.

CISA added CVE-2026-21962 to the Known Exploited Vulnerabilities catalog this week, and the score alone tells most of the story. It carries a CVSS 10.0, impacts both Oracle WebLogic Server and Oracle HTTP Server, and CISA confirms attackers are already exploiting it in the wild. An unauthenticated attacker with HTTP access to the target can get to critical data.

The kill chain here is brutally simple. No credentials, no user interaction, no prerequisite beyond network reach to the HTTP listener. That means a basic scanning operation can hit an exposed WebLogic console or Oracle HTTP Server instance and start pulling sensitive data without ever triggering an authentication failure alert. If your edge defenses are tuned for malware drops or command-and-control traffic, you may be blind to this because it looks like legitimate HTTP requests.

WebLogic has been a reliable target for a decade, from T3 deserialization bugs to console authentication bypasses, but a maximum-severity unauthenticated data-access flaw in 2026 still deserves attention. I am less interested in the vulnerability mechanics than in the reality that organizations still have these systems facing the public internet. A legacy Java application server should not be directly reachable without an aggressive set of compensating controls, and even then it is a gamble.

Practical takeaway: run an emergency external scan for Oracle WebLogic and HTTP Server listeners right now. If you own them, apply Oracle's patch immediately. If patching is gated by change management, restrict HTTP access to known proxy or VPN ranges, enable full HTTP access logging, and alert on any anomalous request patterns to WebLogic endpoints. If you cannot account for every WebLogic instance in your environment in under an hour, your asset inventory is the real vulnerability.

CISA added three new vulnerabilities to its Known Exploited Vulnerabilities catalog on August 27, and the spread of targets should get the attention of both IT and DevOps teams. The entries are CVE-2023-49105 in ownCloud, an improper authentication bug; CVE-2026-53362 in the Linux kernel, which remains unspecified in the advisory; and CVE-2026-66384 in JFrog Artifactory, a path traversal flaw. All three carry evidence of active exploitation, which means they are not theoretical.

Operationally, these hit different parts of the stack. The ownCloud flaw is an authentication bypass, meaning an attacker can potentially access files and shares without valid credentials. The JFrog Artifactory bug is an improper limitation of a pathname to a restricted directory, or path traversal, which on a build artifact server can lead to arbitrary file reads or writes and quickly turn into code execution in CI/CD pipelines. The Linux kernel entry is the wildcard here; CISA lists it as unspecified, so defenders are patching against a threat with no public technical details yet, which is always a frustrating position.

What makes this update more interesting than a routine KEV drop is how CISA is framing it under Binding Operational Directive 26-04. The directive tells federal agencies to prioritize remediation based on actual risk: rapidly patch publicly exposed assets where exploitation grants total control, while deferring lower-risk items. It is a move away from blanket deadlines and toward exposure-driven triage. For private sector defenders, that logic is worth adopting wholesale. Not every KEV deserves a 3 A.M. emergency change window; the ones on your DMZ that give an attacker domain admin or root do.

Practical takeaway: this week, audit your ownCloud and Artifactory exposure. If either is reachable from the internet, treat them as critical. For Artifactory specifically, verify that the host cannot reach production endpoints laterally, because a compromised build server is a supply chain nightmare. On the Linux kernel side, if you are running publicly exposed workloads or multi-tenant containers where a kernel escape would be catastrophic, patch to the latest stable release even without full details. And if your vulnerability management program still treats all KEVs equally, borrow BOD 26-04's criteria and start scoring by exposure and post-exploitation impact.

CISA dropped another KEV catalog update this week and the age spread is staggering. Among the six newly added vulnerabilities are two Red Hat bugs from 2015, a 2019 Microsoft SQL Server RCE, a 2021 Ajax.NET deserialization flaw, a 2022 Linux kernel out-of-bounds write, and one fresh 2026 entry: CVE-2026-8452 in Citrix NetScaler ADC and Gateway. The message is not subtle. Attackers are not burning zero-days. They are cycling through old, reliable flaws and mixing in a new perimeter target when one appears.

The 2015 bugs deserve a second look. CVE-2015-3246 is a race condition in libuser, and CVE-2015-5287 sits in the Automatic Bug Reporting Tool. Both are local privilege escalation paths on Red Hat-derived systems. Eleven years later, they are still showing up in active exploitation chains. That means there are unpatched or unsupported RHEL and CentOS instances in production right now that attackers are already inside of, elevating from low-privilege shells to root.

CVE-2019-1068, the Microsoft SQL Server RCE, and CVE-2022-0995, the Linux kernel out-of-bounds write, fill out the middle of the timeline. They are well-documented, have public exploits, and should have been eradicated years ago. Their presence in the KEV catalog says more about patch velocity and asset visibility than it does about attacker sophistication.

The outlier is CVE-2026-8452. Citrix NetScaler ADC and Gateway is a high-value edge appliance. An improper restriction of operations within a memory buffer on a device that faces the internet is exactly where you do not want active exploitation. If you run NetScaler, this is not a "next quarter" patch. It is a "this weekend" patch, especially with BOD 26-04 now reinforcing rapid remediation for federal agencies and setting the tempo everyone else should follow.

Practical takeaway: pull your vulnerability scan results from the last ninety days and filter for anything on the KEV catalog. If you still have RHEL or CentOS boxes from the 6 or 7 era, prioritize CVE-2015-3246 and CVE-2015-5287 this week. If you run SQL Server 2017 or older builds, hunt for signs of CVE-2019-1068 exploitation in your logs. And if you have Citrix NetScaler ADC or Gateway appliances, patch CVE-2026-8452 immediately and inspect access logs for anomalous HTTP requests. KEV means active exploitation is already confirmed. The only question is whether your asset inventory is accurate enough to find them.

CISA's weekly KEV update landed Tuesday and one entry stood out. CVE-2026-60004, a code injection vulnerability in Gitea, is now confirmed as actively exploited and cataloged alongside the usual edge-network suspects. That matters because Gitea is not an edge device; it is the internal source-control server many teams treat as trusted infrastructure.

The advisory ties the addition to BOD 26-04, CISA's directive forcing federal agencies to prioritize high-risk KEV patches that grant total asset control. While the bulletin is light on exploitation details, the KEV label alone tells defenders this is not a theoretical proof-of-concept. Attackers are finding and hitting Gitea instances in the wild.

I worry about this because self-hosted Git platforms sit at the center of the software supply chain. They house source code, pipeline secrets, and often have trust relationships with CI runners and container registries. A code injection flaw there is a straight shot to poisoning builds, exfiltrating repositories, or pivoting laterally through deployment pipelines. If your Gitea server is reachable from a compromised developer workstation or a misconfigured ingress, that is enough for an attacker to move.

Too many organizations still park internal Git servers on flat networks with weak monitoring, assuming they are protected by perimeter obscurity. The KEV addition is a reminder that developer tools are production infrastructure, and they are being hunted exactly because they hold the keys to everything downstream.

Practical takeaway: If you run Gitea, patch this week and treat the response like a Tier-0 incident. Audit admin logs, repository webhooks, and access tokens for the last 90 days. Rotate any secrets the instance can reach, and verify that your Gitea is not exposed to the open internet. If you cannot patch immediately, pull it behind a jump host or access proxy and restrict outbound CI connections until you can.

CISA added CVE-2026-21962 to the Known Exploited Vulnerabilities catalog on Monday, and the entry is worth more than a quick glance. This is an improper access control vulnerability in Oracle HTTP Server and the Oracle Weblogic Server Proxy Plug-in, and CISA confirms it is under active exploitation. What makes the announcement notable is not just the bug, but the policy framework it triggers.

The notice explicitly ties this KEV entry to Binding Operational Directive 26-04, which CISA finalized recently. BOD 26-04 does not simply tell Federal Civilian Executive Branch agencies to patch faster. It establishes a risk-based tier: agencies must rapidly remediate high-risk KEVs on publicly exposed assets that grant total control post-exploitation, while lower-risk vulnerabilities can be deferred. Crucially, it also mandates that agencies verify whether a system was compromised before the patch was applied. That is a shift from pure patch velocity to incident validation.

Even if you are outside the FCEB, the vulnerability itself should get your attention. Improper access control in a web server and proxy plug-in stack is a logic flaw, not a memory corruption bug. That typically means an attacker can bypass authentication or reach restricted administrative interfaces without crashing services or dropping obvious payloads. If your Oracle HTTP Server or Weblogic proxy tier is internet-facing, this is exactly the kind of quiet foothold that enables post-exploitation access and lateral movement.

I have seen too many teams deprioritize middleware and proxy patches behind OS and application updates. CISA is signaling that this specific Oracle stack bug is total-control material on exposed assets, and they are backing that assessment with binding operational requirements for federal networks. That should reset the risk calculation for anyone running the same software.

Practical takeaway: if you operate Oracle HTTP Server or Weblogic Server Proxy Plug-ins, especially on externally reachable hosts, make this your Monday priority. Preserve access logs before you patch, and hunt for anomalous requests that might indicate the access control bypass was already exploited. If you are FCEB, BOD 26-04 makes that pre-patch compromise check mandatory. Everyone else should adopt the same standard anyway.

Microsoft disclosed CVE-2026-69836 this week: a CVSS 10.0 remote code execution flaw in Entra ID that the company confirms is already being exploited in the wild. The detail that stopped me was not the severity score, but the note that no customer action is required. That tells me the fix is entirely cloud-side, which is standard for SaaS, but it does not mean the risk to individual tenants is zero.

Entra ID is the identity backbone for most organizations running on Microsoft cloud. An RCE in that stack is not a local privilege escalation on a single endpoint; it is a foothold in the system that issues tokens, enforces conditional access, and federates trust to every downstream application and SaaS dependency. Even if Microsoft has patched the underlying infrastructure, the operative question for defenders is what the exploit touched before the mitigation landed.

Microsoft has not published technical details or attacker TTPs yet, and I expect they will stay tight-lipped while the rollout completes. That is reasonable from an engineering standpoint, but it leaves defenders without concrete indicators of compromise. When a vendor patches a cloud service centrally and tells you to sit tight, you should not interpret that as a clean bill of health. It means no patch to install, not that there is nothing to hunt.

The history of cloud identity exploitation tells us that initial access in the control plane often translates to downstream tenant impact. If an actor achieved code execution in the identity layer, the follow-on effects could include unauthorized token issuance, backdoored app registrations, or privilege escalations that persist after the original vulnerability is fixed. Those artifacts live in your logs, not Microsoft's patch notes.

Practical takeaway: pull your Entra ID sign-in and audit logs for the last thirty to sixty days and hunt for anomalies outside your baseline. Focus on non-interactive sign-ins from unfamiliar locations, new OAuth application consents granted by privileged accounts, unexpected device registrations, and any service principal or conditional access policy changes that occurred during the exploitation window. If you cannot explain every Global Administrator action in that period, that is the project for Monday morning.

CISA added four critical vulnerabilities to the Known Exploited Vulnerabilities catalog on Tuesday, spanning Apple macOS, Microsoft SharePoint, VMware vCenter, and the Windows IKE Extension. Of the four, CVE-2026-65400 is the one that should wake up anyone managing an enterprise Mac fleet. It is an improper authentication vulnerability in macOS carrying a CVSS score of 9.8, and CISA confirms it is under active exploitation in the wild.

A 9.8 in the authentication category on macOS is as bad as it sounds. Improper authentication at this severity typically translates to unauthorized access without valid credentials, which means an attacker could potentially gain a foothold on the endpoint without phishing or malware. For organizations running managed Macs through Jamf, Intune, or Kandji, this is a serious gap because those endpoints often carry elevated trust assumptions. If the login boundary crumbles, your EDR, MDM enrollment, and disk encryption all sit on a broken foundation.

The other three KEV additions are just as operationally painful. SharePoint is external-facing collaboration infrastructure. vCenter is the control plane for your virtualization layer. The Windows IKE Extension handles VPN and network tunneling. But the macOS entry stands out because too many enterprise patching programs still tier Apple endpoints below Windows servers and domain controllers. That hierarchy made sense when Macs were a small marketing slice, but it does not hold when a CVSS 9.8 improper authentication flaw is being actively exploited against enterprise machines.

Practical takeaway: Pull your macOS patch cycle forward immediately and treat this as an emergency change. Verify your MDM is force-deploying the fixed version, check for anomalous authentication events on Mac endpoints, especially off-hours logins or network segments that do not match the user, and review any privileged access workflows that rely on macOS local authentication. If your vulnerability management program still ranks Apple patches lower than Microsoft Tuesday updates, fix that priority matrix before next Monday. Your Mac fleet is infrastructure now, and the attackers have noticed.

CISA added CVE-2026-73570 to the Known Exploited Vulnerabilities catalog on Friday, a Zimbra Collaboration Suite OS command injection bug that grants total control of the host. What grabbed my attention was not just the vulnerability, but the accompanying Binding Operational Directive 26-04 requirement. FCEB agencies must now hunt for evidence of compromise before they patch publicly exposed assets. That is a clear signal that by the time a flaw hits the KEV list, exploitation has already occurred and patching alone will not evict an intruder.

The target is internet-facing Zimbra servers, and the technique is straightforward OS command injection. For a collaboration platform that hosts email, calendars, and file sharing, total host control is about as bad as it gets. CISA specifically flags this as a high-risk vulnerability on public-facing infrastructure that demands rapid remediation, not deferred action.

The pre-patch compromise requirement is what changes the workflow. It forces defenders to treat an unpatched internet-exposed Zimbra instance as an active incident rather than a maintenance ticket. If that server has been reachable from the open internet, the safe assumption is that it was probed, and possibly owned, well before the KEV publication date.

Operationally, this makes sense. Mail and collaboration servers sit at the intersection of identity and data. Total control of Zimbra means access to mailboxes, address books, calendar invites, and often cached credentials that enable lateral movement. An attacker with that foothold does not need to come back through the same vulnerability after you patch.

Practical takeaway: if you run Zimbra, do not just schedule CVE-2026-73570 for your next maintenance window. Pull the server from public exposure today, patch it, and hunt for signs of pre-exploitation activity. Review web access logs for anomalous POST requests to Zimbra endpoints, inspect for unexpected cron jobs or spawned shells, and reset all administrative and user credentials. If you are not a federal agency, follow the BOD 26-04 playbook anyway: verify the system is clean before you call the ticket closed.

CISA added two new entries to the Known Exploited Vulnerabilities catalog on Thursday, and neither of them are the usual suspects. CVE-2026-72529 and CVE-2026-72530 both target TrueConf Server, an enterprise video conferencing platform that does not get the same scrutiny as your Microsoft or Cisco stacks but is apparently juicy enough to be actively hit in the wild.

The pair is nasty. CVE-2026-72529 is a missing authentication vulnerability for a critical function, and CVE-2026-72530 is a code injection flaw. Chained or even used separately, they give an unauthenticated attacker a straight path to administrative control of the server. TrueConf is often deployed as a self-hosted collaboration node, which means it is sitting in a DMZ or on a public IP so external participants can join. That exposure is exactly what makes these CVEs operational for attackers.

What caught my eye is not just the bugs, but the binding language in BOD 26-04 that CISA attached to the announcement. The directive tells FCEB agencies to prioritize rapid remediation for high-risk KEVs on publicly exposed assets that grant total control post-exploitation, but it also establishes an expectation that agencies must check whether the system was compromised before the patch was applied. That is a meaningful shift. It acknowledges that if the box is internet-facing and the vulnerability gives total control, patching after the fact just locks the door behind the intruder.

For the rest of us outside the federal space, the lesson is the same. Self-hosted UC and video conferencing servers are often set-and-forget infrastructure. They get stood up for a project, exposed to the internet, and then buried under layers of NAT rules nobody documents. Attackers know this, and they scan for management interfaces on obscure collaboration software because defenders rarely prioritize them.

Practical takeaway: If you have TrueConf Server in your environment, hunt for evidence of exploitation against CVE-2026-72529 and CVE-2026-72530 before you patch, then segment the host behind a reverse proxy with strict access controls. If you cannot produce an inventory of every internet-facing collaboration server you own, that audit is your Monday morning priority.

CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalog on Tuesday, and the entry deserves more attention than a routine SSRF bulletin usually gets. The vulnerability hits MLflow, the widely used machine learning lifecycle platform, and CISA has confirmed it is under active exploitation. What makes this entry operationally interesting is not just the flaw, but the environment it typically lives in.

MLflow instances tend to sit at the intersection of data science and production infrastructure. They often have liberal network access to object stores, training data lakes, model registries, and internal APIs. A server-side request forgery here is not a simple scanner bounce. It is a pivot point. If the MLflow server can reach cloud metadata endpoints or internal services, an attacker can use it to map the data plane, harvest credentials, or exfiltrate models without ever touching a standard workstation.

The advisory also highlights Binding Operational Directive 26-04, which CISA has been rolling out to federal agencies. BOD 26-04 does not just tell FCEB shops to patch KEVs quickly. It explicitly requires them to prioritize vulnerabilities on publicly exposed assets that grant total control post-exploitation, and, crucially, to verify whether the system was compromised before the patch was applied. The message is clear: patch status alone is no longer sufficient evidence of cleanliness.

That requirement matters for MLflow because these platforms are often deployed by data teams with minimal security oversight, exposed through misconfigured proxies, or dropped into cloud VPCs with broad egress. An SSRF against an ML workload is a low-noise way to probe an organization's crown jewels. If your threat model treats ML infrastructure as internal-only and therefore low-risk, this KEV addition should recalibrate that.

Practical takeaway: if you run MLflow, assume it is a production target. Pull it off the public internet immediately if it is exposed, enforce strict egress filtering so the host cannot reach metadata services or internal APIs, and review access logs for anomalous outbound requests from MLflow service accounts. For federal teams, start documenting your pre-patch forensics now, because BOD 26-04 expects proof of no compromise, not just a closed ticket.

CISA added four new entries to the Known Exploited Vulnerabilities catalog on Tuesday, and the spread alone tells a story. The batch covers CVE-2026-33824 in Microsoft IKE, CVE-2026-55040 in SharePoint, CVE-2026-59310 in Broadcom VMware vCenter, and CVE-2026-65400 in Apple macOS. That is network edge to collaboration stack to virtualization core to endpoint, all with confirmed exploitation in the wild and no theoretical stage left.

The two that stand out operationally are CVE-2026-55040 and CVE-2026-59310. SharePoint remains one of the most common internet-facing Microsoft services in enterprise environments, and a weak authentication vulnerability there is exactly the kind of foothold initial access brokers love to farm and monetize. Meanwhile, CVE-2026-59310 is a path traversal in vCenter, which sits at the center of most enterprise virtualization estates. If you can traverse the filesystem on a vCenter Server, you are one step away from owning the entire compute layer underneath it.

The other two round out an ugly picture. CVE-2026-33824 is a double free in Microsoft IKE, putting VPN and remote access infrastructure at risk, and CVE-2026-65400 is an improper authentication bug in macOS. CISA also used this drop to highlight BOD 26-04, which directs federal agencies to prioritize KEVs that grant total asset control when exposed to the internet. The directive is federal, but the logic applies to any organization: once a flaw hits the KEV list, your patching timeline collapses from quarterly to emergency.

Practical takeaway: Pull your asset inventory for SharePoint, vCenter, VPN gateways, and managed macOS fleets this week. If any of these four CVEs match your environment and the asset is publicly routable, that is your Monday morning priority. For vCenter specifically, verify you are on a patched build and hunt for unexpected outbound connections from the management network. If you are still running internet-facing SharePoint without additional authentication hardening, treat it as an active target until the patch is applied.

CISA added CVE-2025-62593 to the Known Exploited Vulnerabilities catalog this week, and the target is worth paying attention to: Ray, the open-source distributed computing framework that underpins a huge slice of modern AI and MLOps infrastructure. This is not a garden-variety web application bug; it is a code injection flaw in a platform explicitly built to execute user code at scale across clusters.

Ray is the engine behind much of what gets marketed as AI infrastructure. Organizations use it to schedule training jobs, serve models, and orchestrate data pipelines, often with deep integration into cloud identity, Kubernetes, and object storage. A code injection vulnerability here does not stop at a compromised dashboard. It means an attacker can likely execute commands across worker nodes, access model weights and training data, and pivot into the broader cloud environment using the service accounts and IAM roles attached to the cluster.

The KEV addition confirms active exploitation in the wild. CISA also used the announcement to highlight BOD 26-04 expectations: federal agencies must now check whether threat actors compromised systems before the patch was applied. That pre-patch forensics step is especially relevant for Ray deployments, where long-running distributed jobs, shared notebook environments, and cached credentials make it trivial for an intruder to leave persistent backdoors that survive a simple version upgrade.

Practical takeaway: if your organization runs Ray, treat it as critical infrastructure, not just a research tool. Pull the Ray Dashboard and API endpoints off the public internet immediately, place the cluster inside a segmented network with strict egress controls, and patch to a fixed version. Before you patch, audit active jobs, inspect node startup scripts, and review any cloud IAM assumptions tied to your ML compute. If you cannot tell me the last time someone scanned your MLOps environment for unauthorized code execution, that is the project for Monday morning.

Cisco confirmed this week that CVE-2026-20349 is being actively exploited against ASA and FTD firewalls. The flaw carries a CVSS score of 8.6 and allows an unauthenticated, remote attacker to trigger a denial-of-service condition by sending a malformed HTTP request. It is not an RCE, but on a perimeter firewall a sustained outage is often just as damaging as code execution.

The bug stems from insufficient error checking when the software processes HTTP requests. Because the attack requires no credentials, anyone who can reach the affected interface can attempt to crash or reload the device. If your ASA handles VPN termination, internet breakout, or site-to-site tunnels, a reload drops every stateful connection and forces a failover that may not be seamless.

I worry about this more than a typical DoS because ASA and FTD devices are frequently single-homed perimeter gateways. Even in active-standby pairs, a reliable remote crash gives an attacker a repeatable way to flap your edge, disrupt operations, and blind telemetry while they move elsewhere. The fact that it is already in the wild means the triggering payload is circulating beyond the lab.

Practical takeaway: patch to a fixed release immediately. If you cannot patch this week, determine whether the vulnerable HTTP path is management traffic or inline inspection. Restrict management access to a dedicated, source-locked jump host if that is the vector. If the flaw is in HTTP deep inspection of transit traffic, evaluate whether you can temporarily disable that inspection without breaking policy, because a brief gap in DPI is preferable to a downed firewall. Finally, audit your ASA and FTD crash logs and failover events for the last thirty days; an unexplained active-to-standby switch may have been an early exploitation attempt.

CISA added three new vulnerabilities to the Known Exploited Vulnerabilities catalog this week, and the spread is telling. The entries are CVE-2026-20349 in Cisco Secure Firewall ASA and FTD, CVE-2026-68820 in the Microsoft Windows Ancillary Function Driver for WinSock, and CVE-2026-72898 in Metabase. All three carry confirmed evidence of active exploitation, and together they hit the network perimeter, the operating system kernel, and the data analytics layer.

CVE-2026-20349 is a heap inspection vulnerability in Cisco security appliances. That is the irony defenders hate: the box meant to inspect traffic becomes the compromise path. CVE-2026-68820 is a use-after-free in a Windows kernel network driver. Bugs in this layer rarely stay contained; exploitation typically translates to privilege escalation, which explains why it graduated to the KEV so quickly. Then there is CVE-2026-72898, a SQL injection in Metabase. A web-facing analytics platform with database access is an attractive target for data theft and follow-on lateral movement.

The timing matters because of BOD 26-04. CISA now requires Federal Civilian Executive Branch agencies to prioritize rapid remediation for KEV-listed vulnerabilities that grant total control of publicly exposed assets, while deferring lower-risk items. The Cisco firewall and Windows kernel bugs fit that high-risk definition precisely. For private sector defenders, the KEV catalog remains the most reliable signal that a CVE is not just theoretical; if CISA has exploitation evidence, scanning and weaponization are already happening in the wild.

Practical takeaway: If you run Cisco ASA or FTD, verify your patch level against CVE-2026-20349 immediately and treat the management plane as compromised until hardened. For CVE-2026-68820, assume every Windows endpoint is a privilege escalation risk until patched; look for anomalous child processes spawning from services tied to the Ancillary Function Driver. If Metabase is in your environment, restrict it from the public internet, apply the fix for CVE-2026-72898, and review database query logs for unexpected SQL statements. Match these three CVEs against your asset inventory before the week ends.

CISA published AA26-222a this week on Gunra, a ransomware-as-a-service operation that graduated from a standalone variant in 2025 to a full affiliate model this year. The targets are exactly who you would expect: government agencies and critical infrastructure organizations across the U.S. Gunra runs a double-extortion playbook, encrypting networks while threatening to publish stolen data to a dedicated leak site if the ransom goes unpaid.

What struck me about the advisory is the complete absence of novelty in the initial access vector. Gunra affiliates are not deploying bespoke zero-days or sophisticated supply-chain implants. They are exploiting known, previously disclosed vulnerabilities in internet-facing VPN gateways and RDP-exposed infrastructure. CISA explicitly warns that unpatched edge devices are the primary entry point, which means the kill chain starts with security debt that defenders have already been told to fix.

This is not a malware problem. It is an exposure and maintenance problem. The advisory confirms that once affiliates breach the perimeter, they move laterally and deploy the ransomware payload, but the hard part should have been the initial access. If your SSL VPN or Remote Desktop Gateway is still sporting a public IP and a missed patch from last year, you are not facing an advanced adversary; you are facing consequences.

The mitigation guidance is fundamentals done right: prioritize patching internet-facing systems, segment networks to contain lateral movement, and maintain offline, immutable backups in a physically separate location. CISA only issues these broad #StopRansomware alerts when the gap between known best practice and observed reality gets too wide to ignore.

Practical takeaway: pull your VPN and RDP exposure list today and patch anything with a known exploited vulnerability by Wednesday. Test your backups by restoring a critical system from scratch this week, and verify the restore does not touch your production network. If your network segmentation is still a flat VLAN design, map one critical asset and build a microsegment around it before the weekend. Gunra is not breaking new ground; it is walking through doors we already know are open.

Metabase posted a warning this week that should make any data engineering team wince. A maximum-severity flaw in its business intelligence and data visualization platform is being exploited in the wild as a zero-day. The vulnerability carries a CVSS score of 10.0 and, notably, has no CVE identifier yet. An unauthenticated remote attacker can inject arbitrary SQL into the Metabase application database, which the vendor warns can grant administrative access without ever presenting credentials.

The attack surface here is ugly. Metabase instances are frequently stood up by analytics teams, connected to data warehouses, cloud databases, and sensitive business metrics, then left exposed to the internet because it is just a dashboard. This is not merely a web application compromise. If you can write arbitrary SQL to the application database, you can alter user permissions, exfiltrate stored connection secrets, pivot toward connected data sources, and backdoor the entire analytics pipeline. A CVSS 10.0 rating is rare, and in this case it feels earned.

What complicates response is the missing CVE. Most enterprise vulnerability management programs are built around CVE feeds. Without an identifier, this gap does not show up in standard scanner signatures or patch Tuesday reports. That means defenders relying on automated correlation are blind while attackers are already probing. It is a reminder that vulnerability databases are lagging indicators, and zero-days do not wait for bureaucracy.

I have seen Metabase deployments tucked away behind reverse proxies with weak rules, or running on cloud instances with public IPs and default configurations. This is the kind of shadow IT that central security teams often miss until it is too late. The TTP here is dead simple: unauthenticated SQL injection over HTTP or HTTPS. No phishing required, no stolen credentials, just a crafted request to the right endpoint.

Practical takeaway: if Metabase is in your environment, find every instance today. Pull anything internet-facing offline or behind a VPN immediately. Audit application logs for anomalous SQL queries or unexpected administrative account creation. If you do not have a complete inventory of BI and analytics tools, treat that as your highest priority this week. And when Metabase does publish a fixed version or mitigation, deploy it outside of your normal monthly cycle. A CVSS 10.0 zero-day with no CVE is not a wait-for-the-scan event.

CISA did not wait long to flag CVE-2026-8037, and I am not surprised. The agency added the Progress Kemp LoadMaster command injection flaw to its Known Exploited Vulnerabilities catalog on Friday, citing 792 observed exploit attempts. A CVSS 9.6 bug in a widely deployed load balancer is bad enough; seeing that volume of fire in the wild tells me scanners and actors are treating it as reliable infrastructure.

The vulnerability is a command injection issue in LoadMaster, which sits in front of web and application tiers and often handles sensitive traffic. I have always considered load balancers high-value targets because they are always on, usually internet-facing, and when compromised they give an attacker persistence and visibility into everything behind them. Kemp LoadMaster in particular shows up in mid-market and regional deployments where teams may not have dedicated ADC staff watching the management plane.

What grabs my attention is the sheer volume of attempts. 792 is not a boutique APT probing a single target; that smells like mass scanning and automated exploitation against exposed management interfaces. If your LoadMaster admin GUI is reachable from the open internet, you are likely already in someone's scan results. The KEV addition gives federal agencies a three-day patch mandate, but the rest of us should treat it with the same urgency.

Practical takeaway: patch LoadMaster immediately if you are on a supported version, but first verify your management interfaces are not internet-routable. I would restrict administrative access to a bastion host or internal jump box, review your access logs for anomalous POST requests to the management UI, and confirm your edge devices are not defaulting to permissive access rules. If you cannot account for every LoadMaster instance in your environment, that inventory gap is Monday's problem.

CISA added CVE-2026-8037 to the Known Exploited Vulnerabilities catalog on Friday, flagging a command injection vulnerability in Progress LoadMaster that is seeing active exploitation in the wild. LoadMasters are frequently deployed at the network edge, directly exposed to the internet to handle traffic distribution, which makes this flaw particularly dangerous. A successful command injection here does not just leak data; it hands the attacker shell-level control of a device that sits between the public internet and internal services.

The timing matters because this is exactly the kind of vulnerability that BOD 26-04 is built around. The directive requires Federal Civilian Executive Branch agencies to prioritize patches for high-risk CVEs on publicly exposed assets that grant total control post-exploitation, while allowing lower-risk bugs to wait. CISA is explicitly telling FCEB shops to move fast on this one. But even if you are not subject to a binding directive, the logic still holds: an internet-facing load balancer with a known command injection bug is a worst-case scenario for risk-based patching.

I have seen too many environments where load balancers and ADCs are treated like plumbing: set and forget, rarely inventoried, and often managed by the network team rather than the vulnerability management program. That blind spot is how a single edge device turns into a beachhead. LoadMasters handle decrypted traffic, SSL termination, and routing decisions. If an attacker owns the box, they own the flow.

Practical takeaway: If you run Progress LoadMaster, verify its exposure immediately. If it touches the public internet, patch CVE-2026-8037 now, not during the next maintenance window. Check your asset inventory for shadowed or forgotten instances, especially any managed by third parties or sitting in partner DMZs. And if your organization is still patching everything on a monthly cycle regardless of exposure or exploitability, use this KEV addition as the case study to switch to a risk-based model. Start with your edge infrastructure. That is the work for this week.

CISA added three new entries to its Known Exploited Vulnerabilities catalog on August 5, and the one that jumped out at me is CVE-2026-9198, a code injection bug in Langflow that scores a 9.8 and grants unauthenticated remote code execution. CISA confirmed it is being actively exploited in the wild, alongside separate flaws in Tomcat and N-central.

Langflow is the open-source visual framework for building LangChain and LLM workflows. It is popular with teams prototyping AI agents and RAG pipelines, which means it often gets deployed fast and secured later, if ever. An unauthenticated code injection leading to full RCE is about as bad as it gets for an application server, and the 9.8 CVSS reflects that there is no authentication barrier for an attacker to clear.

What worries me operationally is that AI infrastructure is now firmly in the crosshairs. Security teams have spent the last year worrying about prompt injection and data leakage, but this is classic server exploitation: a public-facing dev tool with a trivial unauthenticated RCE. If your ML engineers or data science team spun up a Langflow instance on a cloud VM and gave it a public IP, an attacker does not need to steal credentials or phish a user. They just need to reach the service and inject code.

The Tomcat and N-central additions round out the picture in a familiar way. Tomcat remains ubiquitous and frequently overlooked in asset inventories, and N-central is remote monitoring and management software, a perennial target for attackers looking to hop into MSP environments. CISA putting all three on the KEV list on the same day is a reminder that attackers are not picky about their initial access; they will take unauthenticated RCE in an AI framework just as happily as a misconfigured RMM tool.

Practical takeaway: find every Langflow instance in your environment this week. If any are internet-facing, assume compromise until patched. Move them behind a VPN or bastion host, enforce authentication at the edge, and patch CVE-2026-9198 immediately. While you are at it, audit your Tomcat and N-central exposure, because CISA has already done the threat intel work for you and the answer is that attackers are using them too.

CISA added CVE-2026-63077 to the Known Exploited Vulnerabilities catalog on August 5, and the vulnerability class should make anyone running a DevOps pipeline wince. It is a deserialization of untrusted data flaw in JetBrains TeamCity, and CISA has confirmed active exploitation. Under BOD 26-04, that puts it in the rapid-remediation tier for FCEB agencies because it can grant total control of the asset.

TeamCity is not just another web server. It is a CI/CD build orchestrator with access to source code, build scripts, artifact repositories, and the secrets that glue your pipeline together. A deserialization flaw here typically means an attacker can feed malicious objects to the application and execute arbitrary code. If they own the build server, they can tamper with binaries before they ship, pivot to cloud environments via stored credentials, or silently backdoor every release that passes through.

What makes this KEV addition operationally interesting is the BOD 26-04 framing. The directive does not just tell agencies to patch fast. It explicitly expects them to determine whether the system was compromised before the patch was applied. That is a recognition that simply closing the door does not evict an intruder who walked through it.

For a CI/CD server, that forensic expectation is especially critical. Build logs, agent access records, and artifact integrity checks need to be part of the remediation, not an afterthought. An attacker with total control of TeamCity could have modified build chains, exfiltrated signing keys, or planted persistence in container images that have already deployed downstream.

Practical takeaway: If you run TeamCity, treat this as a potential supply-chain incident, not just a patching ticket. Pull the instance off the public internet if it is exposed, apply the JetBrains fix immediately, and rotate every credential the server ever touched. Review build artifacts and deployment logs for the last 90 days for unexpected modifications or unauthorized pipeline triggers. If you cannot do that forensic check this week, assume compromise and rebuild the instance from a known-clean image.

CISA's August 4 KEV update landed three new vulnerabilities, and the one that should ring alarm bells for anyone running a managed service stack is CVE-2026-18556. It is an authentication bypass in N-able N-central, and it is now on the Known Exploited Vulnerabilities catalog alongside confirmed reports of active exploitation.

N-central sits at the center of an MSP's universe. An authentication bypass there does not just compromise one server; it hands an attacker the keys to every endpoint the platform manages. CISA's binding BOD 26-04 explicitly prioritizes exactly this scenario: publicly exposed assets that grant total control after exploitation. The agency is telling FCEB shops to patch fast and defer lower-risk work, and this flaw is why.

The same update also added CVE-2026-9198, a code-injection bug in IBM Langflow, and CVE-2026-34486, a missing-encryption issue in Apache Tomcat. Langflow is worth noting because it signals attackers are now probing AI and machine-learning infrastructure for initial access, not just traditional web servers. Tomcat, meanwhile, reminds us that decades-old Java stacks are still getting hit for sensitive data exposure.

What ties all three together is exposure. These are not buried deep in internal networks; they are services that routinely face the internet or sit on flat internal segments that might as well be public. The assumption that an RMM portal, an AI workflow tool, or a legacy Java manager is too obscure to be targeted collapsed the moment CISA confirmed active exploitation. Attackers do not need to invent new techniques when they can simply log into a panel that should never have been reachable.

Practical takeaway: if you run N-central, treat this as a live incident. Patch to the latest fixed release immediately, restrict the web console to known IP ranges or a VPN gateway, and force MFA on every account with no exceptions. Then inventory any internet-facing Langflow or Tomcat instances and get them behind a reverse proxy or WAF today. If you cannot patch before the weekend, pull them offline.

CISA added CVE-2026-18577 to the Known Exploited Vulnerabilities catalog this week, and the target should worry anyone running a managed services stack. The vulnerability is an authentication bypass in N-able N-central, the RMM platform used by thousands of MSPs to manage endpoints and tenants. CISA confirmed active exploitation, which means this is not theoretical.

N-central sits in a privileged position. It holds credentials, remote access paths, and deployment rights for every endpoint under management. An authentication bypass using an alternate path or channel does not just compromise one server; it potentially grants an attacker lateral movement into every customer environment managed by that instance. We have seen this movie before with Kaseya and ConnectWise, and the economics for attackers are the same: hit the MSP tool, own the downstream supply chain.

The KEV addition also lands under the new BOD 26-04 framework. CISA is now requiring federal agencies to prioritize rapid remediation of KEV entries that grant total control post-exploitation, but crucially, it also expects agencies to check whether the system was compromised before the patch was applied. That is a tacit admission that patching alone is not enough for high-risk bugs like this one. If the asset is publicly exposed and the bug gives total control, you must hunt first.

CISA's advisory is light on exploitation specifics, but the operational impact is clear. N-central instances should not face the public internet under any circumstances, yet Shodan regularly shows exposed RMM panels. The alternate path language typically points to an unauthenticated API endpoint or a hidden management interface that bypasses the standard login flow. Either way, if an attacker can reach it, they do not need stolen credentials.

Practical takeaway: if you run N-central, treat this as an active incident until proven otherwise. Pull the server behind a VPN or Zero Trust gateway immediately if it is internet-facing. Patch to the fixed version, but before you do, audit your tenant logs for unknown IP addresses, anomalous API sessions, or unexpected agent deployments in the last 45 days. If you cannot account for every session, rotate all secrets stored in the platform and notify downstream customers. Monday morning is for closing the front door; Tuesday is for checking who already walked through it.

CISA dropped ICSA-26-209-01 this week and it is a reminder that OpenSSL bugs do not stay in the enterprise data center. Siemens Desigo CC, the building automation and energy management platform that underpins plenty of critical manufacturing and smart-building environments, is carrying CVE-2025-15467 with a CVSS of 9.8. Versions V7 and V8 are affected across the board, and V9 installations below 9.0.1 are vulnerable.

The flaw is a stack-based buffer overflow in OpenSSL's parsing of CMS AuthEnvelopedData messages. Send a crafted message with malicious AEAD parameters and the management server can crash or, more worryingly, potentially execute remote code. This is not a configuration error or a weak password; it is a memory corruption issue in the cryptographic library sitting underneath the application.

What makes this sting operationally is where Desigo CC lives. It is the central pane of glass for HVAC, lighting, physical access control, and energy systems. In many facilities it is treated as just a building IT app and left on a flat network with a path to the internet or to corporate workstations. Siemens has a fix for V9 in version 9.0.1, but V7 and V8 are still waiting for patches, with only countermeasures available today. If you are running older releases, you are in patch limbo.

The part that really gets me is the supply-chain angle. Siemens did not write the buggy crypto routine; they consumed OpenSSL and the vulnerability propagated into a system that manages physical environments. Building automation is the forgotten middle child between IT and OT. It has the network exposure of IT and the physical impact of OT, but usually without the rigor of either. An RCE on the management console is a short hop to manipulating building controls or pivoting into the production network.

Practical takeaway: if Desigo CC is in your estate, inventory every instance by version before Friday. Upgrade V9 to 9.0.1 immediately. For V7 and V8, implement Siemens' recommended countermeasures now, which must start with network isolation. Pull the management server off any flat network, put it behind a dedicated jump host, restrict outbound and lateral traffic to known peers, and alert on any anomalous connections to the Desigo service ports. If your building automation is invisible to your SOC, make it visible this week.

Rapid7 published a working proof-of-concept for CVE-2026-16232 this week, and that is the exact moment an already serious vulnerability becomes an urgent one. The flaw is an authentication bypass in Check Point's SmartConsole login process, and it was already under active exploitation before the PoC went public. Now anyone with the code and a line of sight to a Security Management Server can start testing your defenses.

Check Point rates this a 9.3 CVSS, and it affects both Security Management Server and Multi-Domain Security Management Server. The vulnerability sits in the SmartConsole authentication flow itself, meaning an unauthenticated attacker can potentially gain administrative access to the management plane without valid credentials. That is about as bad as it gets for the platform that controls your firewall policies, VPN configurations, and object databases.

What worries me is not just the bug, but the exposure pattern. SmartConsole and SMS instances have a habit of showing up on the public internet, whether through misconfigured remote access, third-party management portals, or flat-out forgotten external interfaces. An auth bypass against the crown jewels of your perimeter defense, now weaponized with public exploit code, turns every exposed management interface into a high-probability breach. The kill chain just went from nation-state or well-funded group to anyone running a scanner.

Check Point patched this recently, so the fix exists. The problem is the gap between patch availability and patch application on management servers that teams often touch only quarterly, or that sit in partner-managed environments with slower change windows. If your security management infrastructure is managed by an MSSP, you need to know their timeline, not assume they are already done.

Practical takeaway: if you run Check Point, treat this as a drop-everything patch. Verify that your Security Management Server and SmartConsole are not reachable from the internet. Restrict management access to a hardened jump host inside a dedicated segment, enforce source IP allowlisting, and review your SmartConsole audit logs for successful logins from non-standard workstations or unexpected times. If you cannot patch today, at least make sure the management plane is invisible to the PoC.

ICSA-26-209-04 dropped this week and it reads more like a Linux kernel changelog than a PLC advisory. I count over 40 upstream CVEs in the GNU/Linux subsystem of the Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP, the high-end variant that runs C++ edge applications alongside the PLC runtime. The bugs span from 2021 through 2025 and hit the kernel, OpenSSH, and other core components Siemens bundles into the Linux side of the controller.

The affected part number is 6ES7518-4AX00-1AB0, including the SIPLUS ruggedized variant. Siemens says it is preparing fixed firmware versions, but for now the recommended path is a set of specific countermeasures for products where patches are not yet available. That language usually means the fix is non-trivial -- likely a full Linux subsystem rebuild and regression test against the PLC runtime -- so the timeline is measured in months, not days.

I am less worried about any single CVE here than I am about the MFP architecture itself. Unlike a standard S7-1500, the MFP runs a full Linux environment alongside the PLC runtime, often hosting analytics or MES-facing applications that need broader network reach than a pure controller. If an attacker reaches that Linux surface -- through a compromised edge app, weak segmentation, or supply-chain code -- they have a persistent foothold on hardware that sits adjacent to the control logic. That is a very different risk model than a buffer overflow in a dedicated PLC OS.

To me, this is a supply-chain debt problem dressed in OT clothing. These are standard Linux vulnerabilities with standard exploit primitives; the only thing making them "industrial" is the badge on the DIN rail. Vendors embedding general-purpose operating systems inside safety-critical controllers inherit the entire upstream maintenance burden, and this advisory shows what happens when that debt accumulates across four years of kernel and library releases.

Practical takeaway: if you run the S7-1500 CPU 1518-4 PN/DP MFP on V3.1.6, treat the Linux subsystem as a standalone server until patched firmware ships. Segment its management and application interfaces from the rest of the OT network, audit which edge apps actually need network reach, and verify your asset inventory can distinguish the MFP part number from standard S7-1500 CPUs. If you cannot locate every 6ES7518-4AX00-1AB0 by Monday morning, that search is your first priority.

CISA dropped CVE-2026-20316 into the Known Exploited Vulnerabilities catalog this week, and it is a reminder that the security products we trust still ship with the same failures we audit everyone else for. The flaw affects Cisco Secure Firewall Management Center software, the centralized brain for firewall policy, logging, and intrusion event analysis across Threat Defense deployments. An unauthenticated remote attacker can use static credentials to log in and gain unauthorized access to the management plane, exposing sensitive configuration data and potentially altering security policy.

Cisco confirmed active zero-day exploitation in the wild. The bug carries a CVSS score of 5.3, which feels artificially low for a compromise of the device that controls your perimeter enforcement. That score reflects the confidentiality impact as scored, but it ignores the operational reality: if you own the FMC, you own the rule sets, the object definitions, NAT policies, and the visibility into what the sensors are seeing. It is a pivot point into the environment, not a dead-end data leak.

Static credentials in enterprise security gear are not a new story, but they are one that should have died years ago. FMC is not an edge IoT toy or a consumer router; it is the aggregation point for enterprise Secure Firewall Threat Defense deployments. The fact that a single known credential pair can unlock remote access to that console means the attack surface was effectively an open door for anyone who knew where to knock. For defenders, this is the worst kind of vulnerability: one that requires no exploit chain, no memory corruption, and no user interaction.

Practical takeaway: if you run FMC, treat this as a full incident response trigger, not a routine patching ticket. Rotate every local, service, and API account on your FMC appliances immediately, audit authentication logs for successful logins from unexpected sources, and verify that your management interfaces are not exposed to the internet or even reachable from user segments. If Cisco has released a patched build, deploy it this week, but do not stop at patching. Review your network architecture and ensure the management plane lives on a dedicated, restricted VLAN with jump-host access only. If your firewall manager can be reached from a standard workstation, you have a design problem that no CVE fix will solve.

CISA added CVE-2026-20316 to the Known Exploited Vulnerabilities catalog on Wednesday, and the entry is as straightforward as it is ugly: a hard-coded password in Cisco Secure Firewall Management Center that is now under active exploitation. This is a management plane vulnerability in the product you use to configure and monitor your firewalls, which means a successful hit gives an attacker total control over the security policy of every managed device.

What grates is that this is not a memory corruption bug or a novel bypass. It is a hard-coded credential baked into enterprise security software in 2026. CISA's inclusion of it in the KEV catalog, alongside the binding requirements of BOD 26-04, tells federal agencies they must remediate this on publicly exposed assets immediately and check for compromise retroactively. The directive explicitly calls out CVEs that grant total control post-exploitation, and this one qualifies.

The operational risk sits in the architecture. FMC is usually positioned inside the management network, but I have seen it reachable through VPN concentrators, partner jump boxes, or mis-routed subnets. An attacker with that hard-coded password does not need to chain anything else; they can authenticate and start pushing policy changes, exfiltrating configs, or pivoting into the firewall infrastructure itself.

Practical takeaway: if you run Cisco Secure FMC, treat this as a confirmed breach scenario until you can prove otherwise. Pull the management interface off any path from the internet today, apply Cisco's remediation guidance, and audit every administrative session and local account for the last ninety days. If you find activity from unknown sources or unexpected policy pushes, assume lateral movement and start incident response. Monday morning is for patching, but Sunday night is for checking your logs.

Arista shipped a patch this week for a zero-day command injection flaw in on-premises VeloCloud Orchestrator, and the active exploitation status is what should grab your attention. This is not an edge device bug. It is the orchestrator itself, the control plane that pushes configuration to your entire SD-WAN fleet.

The advisory labels it maximum severity and confirms attackers are already exploiting it in the wild. Details are still sparse, which is typical when a vendor is racing to get fixes out while incidents are ongoing. What we do know is that the vulnerability sits in on-premises Orchestrator deployments, meaning organizations running their own instances rather than Arista-hosted cloud management are the ones exposed.

Operationally, this is worse than popping a branch router. If you compromise the orchestrator, you can push routes, tunnel configurations, and policy changes to every managed edge device. That is persistence and lateral movement baked into the network design, and it is invisible to anyone watching branch logs instead of orchestrator audit trails. I have seen teams spend months hardening WAN edges while treating the management layer as an internal back office system that does not merit the same scrutiny.

The on-premises angle matters here. Teams often assume self-hosted orchestrators are shielded by corporate network boundaries, yet active exploitation tells us that assumption has already failed somewhere. Whether that is through internet-facing management interfaces, compromised VPNs, or supply chain access, the result is the same: the SD-WAN brain is bleeding.

Practical takeaway: if you run on-premises VeloCloud Orchestrator, patch now and treat this as a potential compromise until you can prove otherwise. Restrict orchestrator access to a locked-down jump host, review every configuration push to your edge devices for the last thirty days, and monitor for unauthorized policy or tunnel changes. If you cannot account for a recent config revision, re-image the orchestrator and re-establish trust with your edges before the weekend.

CISA added two new entries to the Known Exploited Vulnerabilities catalog on Monday, and both are already being used in the wild. CVE-2025-68686 is an information exposure flaw in Fortinet FortiOS, while CVE-2026-16812 is an OS command injection in Arista VeloCloud Orchestrator On-Prem. CISA published them alongside a reminder that Binding Operational Directive 26-04 is now in effect, requiring federal agencies to rapidly patch high-risk KEV flaws on publicly exposed assets that grant total control after exploitation.

The Arista bug worries me more operationally. VeloCloud Orchestrator is the brain of an SD-WAN deployment; if an attacker can execute arbitrary OS commands on the orchestrator, they can reconfigure edge devices, intercept traffic, or push malicious policies to every branch. The FortiOS issue is labeled information exposure, but in practice that usually means administrative sessions or credentials are leaking to unauthenticated attackers on the network, which is effectively pre-authentication for total control of the firewall.

BOD 26-04 is worth paying attention to even if you are not a federal agency. CISA is explicitly telling FCEB shops to filter the KEV catalog down to vulnerabilities on internet-facing systems that deliver total asset compromise. That is a much sharper prioritization lens than "patch everything on the list." It also means CISA is signaling that these two bugs meet that high bar. If your threat model includes ransomware or state-level intrusion, you should adopt the same filter.

Practical takeaway: audit your Fortinet and Arista exposure today. If your FortiOS management plane or VeloCloud Orchestrator is reachable from the internet, that is your first problem. Remove public access, patch to the latest vendor release, and for the Fortinet exposure, rotate any active sessions or credentials that could have been harvested. If you run a non-federal SOC, borrow the BOD 26-04 logic and build a rule that auto-escalates any KEV hitting an externally facing asset with a total-control outcome. That is a better Monday project than another generic vulnerability report.

Siemens patched a CVSS 10 authentication bypass in Opcenter X this week, and the root cause is the kind of JWT mistake we have been warning about for a decade. CVE-2026-56451 affects versions before V2604 and allows an unauthenticated remote attacker to forge arbitrary tokens by manipulating the algorithm declared in the JSON Web Token header. In a platform deployed worldwide across critical manufacturing, that is not a minor configuration error; it is an architectural miss.

CISA's advisory ICSA-26-202-03 spells out the mechanics: the application does not validate the algorithm specified in the JWT header before verifying the signature. An attacker can craft a token with a swapped or stripped algorithm, present it to Opcenter X, and walk past authentication entirely. From there they can impersonate any user, including administrative accounts, gaining full unauthorized access to the application and its data.

Opcenter X is a manufacturing execution system, the bridge between enterprise planning and the shop floor. It handles production orders, quality workflows, and process data. Full administrative compromise here does not just mean stolen files; it means an attacker can alter batch records, manipulate production schedules, and potentially use the MES as a pivot toward OT networks, historians, and engineering workstations. The advisory notes deployment across critical manufacturing sectors globally, so the footprint is significant.

JWT algorithm confusion is not a novel technique. Security researchers have demonstrated alg:none and algorithm substitution attacks since the mid-2010s. What strikes me is that a modern Siemens industrial platform shipped without server-side enforcement of a strict, expected signature algorithm. It is the kind of vulnerability that falls out of standard JWT security testing, which makes me wonder how many other industrial applications are trusting the client-supplied alg parameter without validation.

Practical takeaway: if you run Opcenter X, treat V2604 as an emergency patch. Inventory every instance, verify your asset list is complete, and assume any internet-adjacent exposure is already being probed. Then extend the scope: audit every JWT-dependent application in your environment for proper algorithm whitelisting. If your apps accept whatever alg the token header claims, you are sitting on the same bug under a different product name.

Cl0p affiliates have moved on from file-transfer appliances and are now hitting product lifecycle management infrastructure. The Hacker News reported this week that internet-exposed PTC Windchill and FlexPLM deployments are under active exploitation as part of a data extortion campaign. The target shift makes sense: PLM systems hold CAD files, bill-of-materials data, supplier contracts, and years of engineering intellectual property. For a ransomware crew, that is higher-leverage data than yet another stolen employee database.

The attack chain is straightforward and nasty. The actors chain a pre-authentication information disclosure in the FlexPLM WSDL endpoint with a server-side flaw in the Windchill login servlet. That combination yields unauthenticated remote code execution without valid credentials. Once inside, they pivot to data exfiltration and extortion. It is the same Cl0p affiliate playbook we saw against MOVEit and GoAnywhere, but aimed at a class of software that rarely gets security scrutiny.

Attribution here is worth a moment of caution. The reporting links this activity to Cl0p, also tracked as Chubby Scorpius, FIN11, Graceful Spider, and Lace Tempest. Cl0p is ultimately a ransomware brand and affiliate ecosystem, not a single intrusion set, so the exact cluster matters less than the fact that a working exploit chain is circulating in the wild. What matters operationally is that manufacturing and critical infrastructure sectors running these platforms are exposed.

PTC Windchill and FlexPLM instances are often internet-facing by design so engineers and suppliers can collaborate across sites. That architecture ages poorly when pre-auth RCE chains appear. If you are running these platforms, your first job this week is to verify whether any instance is reachable from the public internet. If it is, patch immediately or pull it behind a VPN and a properly segmented jump host. Restrict access to the WSDL endpoint and login servlet paths at your reverse proxy or WAF, turn on verbose access logging for those URLs, and hunt for anomalous POST or GET patterns from non-corporate source ranges. PLM data is crown-jewel intellectual property; treat its exposure accordingly.

I dropped everything when I saw Check Point's advisory this week: an actively exploited zero-day in SmartConsole, the thick-client GUI that drives Security Management and Multi-Domain Security Management. The flaw, CVE-2026-16232, scores 9.3 and is an authentication bypass on the login process that grants full administrative access without valid credentials.

This is a worst-case scenario for a security product. SmartConsole is where firewall rules, VPN communities, NAT policies, and threat prevention profiles are defined and pushed to the gateway. An unauthenticated attacker who can reach the management interface can own the entire policy set. Check Point confirmed the flaw is under active exploitation, which means attackers had a working trigger before defenders had a patch.

The target surface is what worries me most. Organizations often park management servers on internal VLANs with soft trust boundaries, or expose them through VPN concentrators with the assumption that authentication is the hard control. An authentication bypass in the management plane shatters that model. Until this week, plenty of teams likely assumed a hardened SmartConsole host was enough; the in-the-wild exploitation proves it was not.

Check Point has not released full technical details yet, and that is standard but frustrating. We do not know the exact exploitation path or whether it requires a specific configuration. What we do know is that the patch exists and exploitation is confirmed, so waiting for the deep-dive blog post is a luxury most environments cannot afford.

If you run Check Point Security Management or MDSM, treat this as a drop-everything patch. Upgrade immediately, then verify that SmartConsole and any management portal are reachable only from dedicated jump hosts or strictly segmented administrative workstations. Review your logs for unexpected successful logins and any policy pushes or rule changes in the last two weeks that did not map to a known change ticket. If your management plane was reachable from broad internal segments, that architecture review is the project for Monday morning.

CISA published AA26-204A this week on LAUNDRY BEAR, and the part that grabbed me is not the phishing or the password spraying. It is the zero-day. Dutch intelligence has tracked this Russian state-supported group for years as a high-volume, low-sophistication actor living on credential abuse and pass-the-cookie attacks. Now they are hitting Zimbra Collaboration Suite with a novel exploit that was a zero-day when the campaign began in July 2025. That is a meaningful shift in capability.

The advisory, co-signed by CISA and international partners, says the target set is Western government and commercial organizations. The objective is almost certainly intelligence collection, specifically the covert acquisition of email data. This is not ransomware or destruction. It is pure espionage, and ZCS is the vector of choice.

What makes this operationally interesting is the TTP escalation. LAUNDRY BEAR's previous campaigns succeeded with unsophisticated initial access because they operated at scale. Burning or acquiring a zero-day for Zimbra suggests either a change in resourcing, access to a broker or partner group, or that self-hosted email is a high-priority target worth the exposure. Zimbra instances are often legacy systems left behind during partial M365 migrations, which means they frequently sit outside modern detection stacks and CASB coverage.

Defenders should resist the instinct to focus only on Microsoft cloud telemetry. Self-hosted Zimbra has local logs, and they matter. If you have ZCS anywhere in your environment, hunt for anomalous mailbox access, unexpected synchronization activity, and privileged account behavior that does not map to known engineering workflows. Review external authentication logs and look for sessions from unusual egress nodes.

Practical takeaway: inventory every Zimbra Collaboration Suite instance in your perimeter this week. If it is internet-facing, restrict access to known endpoints immediately and enforce MFA on all admin and user accounts. Pull mail gateway and ZCS access logs for the last ninety days and look for anomalous IMAP, POP3, or webmail sessions. If you assumed your email security story ended with E5 licensing, this advisory is your reminder that legacy self-hosted mail is still a prime target for nation-state collection.

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.