> Blog_

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.