Adobe shipped an emergency out-of-band patch yesterday for a pre-authentication remote code execution flaw that attackers had been exploiting for months. That alone would make the day. It shares the brief with a supply chain compromise that turned trusted IT utility downloads into remote access trojans, and an actively exploited Python notebook framework flaw harvesting credentials from exposed instances.

In the News

Adobe Reader Zero-Day Exploited for Months Before Emergency Patch

CVE-2026-34621 is a pre-authentication remote code execution vulnerability in Adobe Acrobat Reader, scored at CVSS 8.6. Adobe released an emergency out-of-band patch on April 11, 2026, confirming that the flaw had been under active exploitation prior to the fix. The specific exploitation timeline has not been fully disclosed, but Adobe’s advisory language — and corroborating threat intelligence reporting — indicates the vulnerability was leveraged in targeted attacks for a period of months before the patch became available.

The attack vector is document-based: a crafted PDF triggers the vulnerability when opened in an unpatched Reader instance. No additional user interaction beyond opening the file is required. Given that Adobe Acrobat Reader is deployed on effectively every enterprise endpoint — and that PDF attachments remain one of the most common email attachment types — the blast radius of this exposure window is substantial.

The months-long gap between initial exploitation and patch availability means that organizations cannot treat patching as the sole remediation step. Any endpoint that ran an unpatched Reader version during the exposure window should be evaluated for signs of compromise.

What defenders should do: Apply the emergency patch immediately across all endpoints. Retroactively hunt for suspicious child processes spawned by Adobe Reader (e.g., AcroRd32.exe or Acrobat.exe spawning cmd.exe, powershell.exe, rundll32.exe, or network-capable binaries) during the pre-patch window. Prioritize endpoints that received PDF attachments from external senders. If your environment uses application sandboxing for document rendering, validate that Reader processes were sandboxed during the exposure period.

Source: The Hacker News

CPUID Website Compromised — CPU-Z and HWMonitor Trojanized for 19 Hours

Between approximately April 9 and April 10, 2026, threat actors compromised the CPUID website and replaced the legitimate installers for CPU-Z and HWMonitor with trojanized versions bundling STX RAT, a remote access trojan. The compromise lasted approximately 19 hours before CPUID identified and remediated the intrusion.

CPU-Z and HWMonitor are among the most widely used free system information utilities in IT operations. System administrators, helpdesk technicians, and hardware engineers download them routinely — often directly from the vendor site, bypassing enterprise software distribution controls. The implicit trust in these tools and their source domain is precisely what makes this supply chain vector effective.

The trojanized installers delivered functional copies of the expected utilities alongside the STX RAT payload, meaning the compromise would not have been immediately obvious to the user. The RAT provides full remote access to the compromised endpoint, including command execution, file exfiltration, and credential harvesting.

CPUID has confirmed the breach and stated that affected downloads have been replaced with clean versions. The company has not disclosed the initial access vector used to compromise the website infrastructure.

What defenders should do: Check download logs and endpoint telemetry for any CPU-Z or HWMonitor installations between April 9 and April 10, 2026. Verify file hashes against CPUID’s published clean hashes. If trojanized versions are confirmed, treat the endpoint as fully compromised — isolate, image, and investigate for lateral movement. Longer term, enforce application allowlisting or hash-based verification for utility software downloads, and route all software acquisition through a controlled internal repository where feasible.

Source: The Hacker News

Critical Marimo Notebook RCE Flaw Under Active Exploitation

A pre-authentication remote code execution vulnerability in Marimo, an open-source Python notebook framework used in data science and machine learning workflows, is now being actively exploited. Attackers are targeting internet-facing Marimo instances to execute arbitrary code and harvest stored credentials, including cloud provider keys and database connection strings stored in notebook environments.

The vulnerability requires no authentication — any exposed Marimo instance is exploitable directly. This is particularly dangerous because notebook environments are frequently deployed by data engineering teams outside the visibility and governance of central security operations. They often run with elevated permissions to access data stores, and credential management within notebooks is notoriously loose.

What defenders should do: Inventory all Marimo deployments, including shadow IT instances spun up by data teams. Patch immediately. Any internet-facing instance should be taken offline until patched. Rotate any credentials that were accessible from Marimo environments — database connection strings, API keys, cloud provider credentials. Restrict notebook framework deployments to internal networks with authentication enforced at the network and application layers.

Source: BleepingComputer

Today’s Deep Dive — Supply Chain Compromise Through Trusted Utility Sites

The CPUID compromise is a textbook illustration of a supply chain attack pattern that is simultaneously well-understood and poorly defended against in most environments: compromise a trusted distribution point, replace legitimate software with a trojanized version, and wait for the target population to install it themselves.

This is MITRE ATT&CK T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain. The initial access does not require a phishing email, a vulnerability in the target’s perimeter, or any interaction with the target’s security controls. The victim downloads what they believe is a trusted tool from a trusted source. The malware arrives as a guest the user invited in.

The 19-hour window is worth examining. CPUID detected and remediated the compromise relatively quickly compared to historical supply chain incidents — the SolarWinds SUNBURST implant was distributed for months, and the Codecov bash uploader compromise persisted for over two months. But 19 hours on a high-traffic download site for IT practitioners is still a meaningful exposure window. IT workers are the ideal target: their endpoints typically have administrative privileges, access to management networks, and stored credentials for infrastructure systems.

The defensive challenge is that traditional security controls are poorly positioned against this vector. Reputation-based endpoint protection will not flag a binary downloaded from a domain with years of legitimate history. Signature-based detection will not catch a newly compiled RAT that has never been seen before. Network-based detection may flag command-and-control traffic after the fact, but only if the C2 infrastructure is known or the traffic pattern is anomalous enough to trigger behavioral rules.

The controls that do work are structural:

  1. Application allowlisting — if only pre-approved binaries execute on endpoints, a trojanized installer either fails to run or triggers an alert when it attempts to execute an unapproved payload.
  2. Hash verification at download — comparing the SHA-256 hash of a downloaded binary against a known-good value published through a separate channel (e.g., a signed hash list on a different domain or a package manager with integrity checking).
  3. Centralized software repositories — routing all software acquisition through an internal repository where new binaries are scanned and validated before distribution.
  4. Endpoint detection focused on post-exploitation behavior — monitoring for RAT-typical behaviors (unexpected outbound connections, credential access, persistence mechanism installation) even when the parent process appears legitimate.

None of these controls are novel. All of them are under-deployed, particularly for the category of “small free utilities that IT staff download directly.”

Detection Spotlight

Hunt for trojanized CPUID utility installations by looking for child processes spawned by recently installed CPU-Z or HWMonitor binaries. STX RAT will typically establish persistence and initiate outbound C2 communications shortly after installation. The following Splunk SPL query identifies suspicious process chains originating from common CPUID installation paths during the compromise window:

index=edr sourcetype=process_creation
  (parent_process_path="*\\cpuz*" OR parent_process_path="*\\hwmonitor*" OR parent_process_path="*\\CPUID*")
  earliest="2026-04-09T00:00:00Z" latest="2026-04-11T00:00:00Z"
  (process_name="cmd.exe" OR process_name="powershell.exe" OR process_name="rundll32.exe"
   OR process_name="regsvr32.exe" OR process_name="mshta.exe" OR process_name="certutil.exe"
   OR process_name="schtasks.exe" OR process_name="wscript.exe")
| stats count by host, parent_process_path, process_name, process_command_line
| sort -count

Any hits warrant immediate investigation. Legitimate CPU-Z and HWMonitor processes do not spawn command interpreters, scripting engines, or LOLBins. False positive rate for this query is effectively zero — a match is a high-fidelity indicator of compromise.

Also check for outbound network connections from these processes to unknown external IPs in the same time window using your NDR or firewall logs.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.