Trending Topics

CISA Sounds the Alarm on Apache ActiveMQ: A 13‑Year‑Old RCE Bug Is Now Being Actively Exploited

CISA has added CVE‑2026‑34197 to its KEV catalog after confirming that attackers are actively exploiting this high‑severity remote code execution flaw in Apache ActiveMQ Classic. The vulnerability, which went undetected in the codebase for roughly 13 years, stems from improper input validation and an overly permissive Jolokia JMX‑HTTP bridge exposed at /api/jolokia/, allowing an authenticated attacker to invoke sensitive broker management methods via crafted HTTP requests. By abusing Jolokia’s default policy, which permits exec operations across all org[.]apache[.]activemq:* MBeans, an attacker can trick ActiveMQ into fetching a remote configuration and ultimately run arbitrary OS commands on the underlying server, effectively taking full control of the broker host. In theory, exploiting CVE‑2026‑34197 requires credentials, but in practice, the bar is much lower. Many deployments still rely on default usernames and passwords (e.g., admin:admin), and in ActiveMQ 6.0.0–6.1.1, the separate bug CVE‑2024‑32114 unintentionally exposes the Jolokia API without authentication, turning this into a fully unauthenticated RCE in those versions. Attack‑surface scans show that thousands of ActiveMQ instances remain internet‑accessible, and security researchers note that ActiveMQ brokers have been repeatedly targeted in malware campaigns since at least 2021, including earlier exploitation of CVE‑2023‑46604 to deploy custom Linux payloads. CISA’s KEV listing now mandates U.S. federal civilian agencies to patch by April 30, 2026, and serves as a strong signal for private‑sector defenders that exploitation is not hypothetical but happening in the wild today. For organizations, this elevates Apache ActiveMQ patching from “important” to urgent. Admins should identify all ActiveMQ Classic deployments, especially any exposed to the internet or reachable from untrusted networks, and upgrade to fixed versions (at least 5.19.4 or 6.2.3) as soon as possible. In parallel, security teams should lock down or disable the /api/jolokia/ endpoint, enforce strong, non‑default credentials, and ideally place the web console behind VPN or zero‑trust access controls rather than leaving it open to the wider internet. Given that exploitation allows arbitrary command execution on the host, defenders should also review logs and telemetry for suspicious Jolokia calls and shell activity, assume that compromised brokers may have been used as beachheads for lateral movement, and be prepared to rebuild and re‑key affected systems if compromise is suspected.

Direct‑Sys Loader + CGrabber: GitHub ZIPs Turn Into Stealthy Stealers for Passwords and Crypto

Researchers have uncovered a disciplined, multi‑stage malware campaign that uses GitHub‑hosted ZIP files to deliver two previously unknown threats: the Direct‑Sys Loader and the CGrabber Stealer. The intrusion starts with ZIP archives distributed via GitHub user attachment links, including samples like Eclipsyn[.]zip, which contain a legitimate, Microsoft‑signed binary (Launcher_x64[.]exe) alongside a malicious DLL disguised as a normal dependency named msys-crypto-3[.]dll. When the signed executable runs, it sideloads the rogue DLL, kicking off the infection chain without immediately dropping any obviously suspicious binaries. From there, the Direct‑Sys Loader takes over as a hardened staging component. It performs several layers of anti‑analysis checks, including searching for more than 60 security tools, scanning for virtualization environments such as VMware, Hyper‑V, and VirtualBox, and looking for tell‑tale text files or artifacts that indicate a sandbox. If any of these are detected, the loader simply exits to avoid noisy behavior. Otherwise, it uses direct syscalls to communicate with the Windows kernel, decrypts its payload in memory with ChaCha20, and hands off control to the final stage, CGrabber Stealer, without relying on APIs that many EDR products monitor. Once active, CGrabber behaves like a full‑spectrum information stealer and targets saved passwords, credit cards, cookies, and autofill data from major browsers (Chrome, Edge, Brave, Firefox), as well as private keys and wallet data from more than 150 crypto apps, including MetaMask, Exodus, Coinbase, and Binance. It also targets messaging and gaming platforms such as Telegram, Discord, and Steam, as well as VPN clients like NordVPN and ProtonVPN, harvesting tokens and configuration data that can be reused for further compromise. Before exfiltration, CGrabber checks whether the victim is located in a Commonwealth of Independent States (CIS) country; if so, it shuts down, a behavior often used by threat actors to avoid attracting the attention of local law enforcement. For everyone else, the stealer aggregates stolen data into an in‑memory ZIP, encrypts it with ChaCha20, and sends it to the attackers via an HTTP POST request with custom headers such as X-Auth-Token, helping it blend in with normal web traffic and slip past basic network filtering. For developers, researchers, and everyday users, this campaign is another warning that GitHub ZIPs and “signed” binaries are not automatically safe. The attackers are abusing trust in GitHub’s infrastructure and Microsoft's signatures to bypass both human suspicion and some automated defenses. Staying safe means being extremely cautious with ZIP archives from GitHub user attachments or unknown repos, avoiding the execution of embedded EXEs and DLLs unless their provenance is clear, and enforcing application control and EDR policies that can detect DLL sideloading and direct‑syscall loaders. Organizations should also monitor for unexpected appearances of binaries like Launcher_x64.exe in unusual directories, watch for outbound traffic with suspicious custom headers, and treat any sign of CGrabber activity as a high‑severity incident requiring credential resets, crypto‑wallet hygiene (moving funds to new wallets), and a thorough endpoint rebuild where needed.

Update on BlueHammer: Three Zero‑Days Put Microsoft Defender, SharePoint, and Browsers Under Pressure

A recent wave of disclosures underscores how Microsoft Defender itself has become a target, alongside SharePoint and Chromium‑based browsers, in the latest round of April 2026 zero‑day activity. The centerpiece on the endpoint side is CVE‑2026‑33825, an elevation‑of‑privilege flaw in Microsoft Defender now widely associated with the “BlueHammer” exploit. The bug stems from insufficiently granular access control and a time‑of‑check to time‑of‑use race condition in Defender’s signature‑update workflow, allowing a local low‑privileged user to gain SYSTEM‑level access by abusing path confusion during an update. PoC code has been public since early April, Microsoft has rated the exploit as “more likely,” and a fix has now shipped as part of an Antimalware Platform update (version 4.18.26050.3011) that Defender should pull down automatically when update channels are healthy. BlueHammer doesn’t exist in isolation. It lands in the same Patch Tuesday cycle as an actively exploited SharePoint Server spoofing/XSS zero‑day, CVE‑2026‑32201, which allows attackers to inject malicious script, impersonate trusted entities, and access or modify sensitive SharePoint content, and a Chromium/WebGPU remote code‑execution zero‑day, CVE‑2026‑5281, arising from a use‑after‑free in Google’s Dawn WebGPU component that has already been added to CISA’s KEV catalog. Together, these issues illustrate an attack chain many defenders now worry about in practice: phishing or browser‑based exploitation to gain a foothold, use BlueHammer (or similar EoP) to reach SYSTEM, and then target SharePoint or other collaboration platforms to move laterally and tamper with high‑value data and workflows. Given that April’s Patch Tuesday also fixed well over 160 CVEs overall, including multiple Critical RCE bugs in Windows TCP/IP, IKE, Active Directory, Office, and RDP, the Defender and SharePoint zero‑days should be seen as part of a broader hardening moment, not one‑off curiosities. For organizations that rely heavily on Microsoft Defender and Microsoft 365, the immediate priority is to verify that Defender’s platform update has actually landed across the fleet, not just assume auto‑update has done its job. Endpoint and security teams should confirm the Antimalware Platform version is at least 4.18.26050.3011, apply all April 2026 cumulative patches, and accelerate SharePoint Server updates on any internet‑exposed or business‑critical farms. In parallel, they should push browser updates for Chrome/Edge to pull in the WebGPU fix, and tighten controls around email attachments and Office macros, including disabling the preview pane for untrusted documents where feasible. More broadly, BlueHammer is a reminder that security products are still software: they must be patched, monitored, and treated as potential escalation pathways, with strong least‑privilege defaults, robust EDR visibility around their update mechanisms, and incident‑response plans that assume an attacker who has touched Defender might already have SYSTEM‑level access on affected endpoints.

Nexcorium: Another Mirai Variant Turns DVRs into DDoS Artillery

A fresh Mirai‑family variant dubbed Nexcorium is hijacking internet‑connected DVRs to fuel new DDoS attacks, underscoring how old IoT weaknesses are still driving very modern outages. Building on publicly available Mirai source code, Nexcorium focuses on DVR‑based monitoring systems and exploits known command‑injection bugs (such as CVE‑2024‑3721 in TBK DVR devices) that allow unauthenticated attackers to execute shell commands via crafted HTTP POST requests. Once a vulnerable DVR is found, the bot downloads an architecture‑specific payload (for example, an arm7 binary), marks it executable, and runs it to enroll the device into the botnet, no user interaction required. From there, infected DVRs can be used to launch high‑volume UDP, SYN, or GRE floods, a pattern consistent with previous Mirai waves that have driven multi‑terabit‑per‑second DDoS attacks against ISPs and online services. Reporting indicates that Nexcorium retains Mirai’s core DNA while adding modern evasion features to make analysis and takedown harder. Researchers describe RC4‑encrypted strings with keys that are themselves XOR‑obfuscated, plus anti‑VM and anti‑emulation checks that cause the malware to behave differently, or not run at all, inside sandboxes and virtualized analysis environments. The bot also verifies that it is running from one of a hard‑coded set of directories, exiting if analysts try to execute it from unexpected paths, and then prepares the compromised DVR to receive commands from remote operators. Telemetry suggests tens of thousands of DVRs remain exposed online, with clusters of infection observed in countries including China, India, Egypt, Ukraine, Russia, Turkey, and Brazil, giving attackers plenty of runway to continue expanding Nexcorium’s firepower if owners don’t patch or replace affected devices. For organizations and individuals, the Nexcorium campaign is another reminder that surveillance and recording gear is part of your attack surface, not just “set‑and‑forget” infrastructure. DVRs should be updated to the latest firmware as soon as vendors release patches for CVE‑2024‑3721 and related flaws, and, wherever possible, taken off the public internet and placed behind firewalls or VPNs instead of being directly addressable. Owners should change default usernames and passwords, disable unused remote‑management interfaces, and consider a factory reset if compromise is suspected, since many Mirai‑derived bots don’t persist across reboots but can quickly reinfect exposed devices. On the network side, security teams should monitor for unusual outbound connections from DVR subnets and be prepared to rate‑limit or geofence traffic if devices begin participating in DDoS activity. In a landscape where Mirai variants continue to evolve and reuse the same classes of IoT weaknesses, basic hygiene on “boring” devices like DVRs is one of the most effective ways to keep your organization from unknowingly contributing to the next record‑breaking DDoS.

ZionSiphon: Politically Charged OT Malware Built to Poison and Break Israeli Water Systems

A newly discovered malware family dubbed ZionSiphon is the latest sign that politically motivated actors are moving from IT disruption into hands‑on manipulation of industrial control systems, in this case, Israeli water treatment and desalination infrastructure. First analyzed by Darktrace, ZionSiphon combines familiar host‑based techniques, privilege escalation, persistence, and USB propagation, with targeting logic tailored to OT environments, specifically targeting systems involved in desalination, reverse osmosis, chlorine control, and hydraulic pressure management. The malware contains hard‑coded Israeli IP ranges and a target list that name‑checks Mekorot (the national water company), major desalination plants such as Sorek, Hadera, Ashdod, and Palmachim, and the Shafdan wastewater facility, leaving little doubt about the operator’s intent and understanding of Israel’s water sector. Once deployed, ZionSiphon runs a series of checks to confirm it has landed on a relevant target: it inspects the host’s IP to see if it falls within Israeli address blocks, scans for water/OT‑related software and processes (for example, process names like DesalPLC, ROController, SchneiderRO, ReverseOsmosis, or WaterGenix), and looks for configuration files tied to desalination and chlorine control systems. If those checks pass, its first action is local file tampering via a routine Darktrace dubs IncreaseChlorineLevel(), which searches a hard‑coded list of ICS configuration files and appends a fixed block of text as soon as it finds one, signaling a clear intent to interfere with how chlorine dosing and pressure controls are set. The code also includes sabotage logic for ICS protocols such as Modbus and S7comm, subnet‑wide scanning for OT‑relevant services, and routines that could raise chlorine levels to unsafe levels or disrupt hydraulic pressure, potentially threatening both operations and public safety if fully implemented. For now, researchers assess ZionSiphon as a prototype rather than a fully weaponized tool: Darktrace found a flaw in its encryption/validation logic (an XOR mismatch) that breaks the country‑verification check, causing the malware to self‑destruct instead of executing its payload, and other implementation gaps suggest it is still under active development. It's hard‑coded Israel‑specific IP ranges, water‑sector process checks, and embedded propaganda strings supporting groups opposed to Israel show that OT attack concepts are now within reach of smaller, ideologically driven actors, not just top‑tier nation‑state units. For water utilities and other critical‑infrastructure operators, ZionSiphon is a warning shot: it underscores the need for tight network segregation between IT and OT, continuous anomaly detection on industrial networks, strong control over USB/removable media, and cross‑visibility between security teams on both sides of the air‑gap, so that “unfinished” experiments like this are caught early, before their next version fixes the bugs and turns intent into impact.