A CVSS 8.6 arbitrary code execution flaw in Adobe Reader was exploited in the wild for months before a patch shipped on April 12. Separately, two supply chain incidents — CPUID’s compromised download site and the cascading Axios GitHub Actions breach that forced OpenAI to revoke its macOS signing certificate — underscore that trusted sources are the preferred attack surface.

In the News

Adobe Reader Zero-Day Exploited for Months Before Patch (CVE-2026-34621)

CVE-2026-34621 is an arbitrary code execution vulnerability in Adobe Acrobat Reader with a CVSS score of 8.6. The flaw requires no authentication. A user opens a crafted PDF, and the exploit triggers code execution in the context of the current user. Adobe released the patch on April 12, 2026, but SecurityWeek reports the vulnerability had been under active exploitation for months prior to that date.

The months-long exploitation window is the operational problem. Adobe Reader is installed across virtually every enterprise environment — it is one of the most universally deployed desktop applications in existence. Any organization relying on monthly or quarterly patch cycles was exposed for the entire duration of active exploitation. The attack surface is as simple as an email attachment or a link to a hosted PDF.

The exploitation pattern — crafted document, user interaction, code execution — maps directly to MITRE ATT&CK T1204.002 (User Execution: Malicious File) for initial access and T1203 (Exploitation for Client Execution) for the execution phase.

What defenders should do: Patch immediately and validate deployment fleet-wide within 24 hours. Do not treat this as a routine update. Because exploitation predated the patch by months, defenders should also hunt retroactively: look for anomalous child processes spawning from AcroRd32.exe or Acrobat.exe during the pre-patch window. Endpoint detection and response tooling with process lineage visibility is the primary detection surface. Application sandboxing that isolates PDF rendering (e.g., Protected View, or browser-based rendering) would have limited the blast radius for organizations that had it enabled.

CPUID Website Compromised, Served Trojanized CPU-Z and HWMonitor

The official CPUID website — publisher of CPU-Z, HWMonitor, and other widely used hardware diagnostic utilities — was compromised on April 9–10, 2026. During that window, downloads of CPU-Z and HWMonitor delivered trojanized installers containing STX RAT, a remote access trojan. The compromise has been attributed to a Russian-speaking threat actor.

This is a textbook trusted-source supply chain attack. IT engineers and system administrators download CPU-Z and HWMonitor routinely for hardware diagnostics, inventory, and thermal monitoring. The tools are not enterprise-managed software — they are utilities that practitioners grab from the vendor site when they need them. That trust relationship is exactly what the attacker exploited. The trojanized installers appeared legitimate and were served from the expected domain.

STX RAT provides remote access, credential harvesting, and data exfiltration capabilities. Once installed, it establishes persistence and command-and-control communication. The technique chain maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain) for initial access, with T1059 (Command and Scripting Interpreter) and T1071 (Application Layer Protocol) for execution and C2.

What defenders should do: Any system where CPU-Z or HWMonitor was downloaded from cpuid.com on April 9 or 10 should be treated as potentially compromised. Isolate, scan for STX RAT indicators of compromise, and examine outbound network connections for C2 traffic. Going forward, this incident justifies enforcing application allowlisting policies and requiring hash validation for any software downloaded outside managed distribution channels.

OpenAI Revokes macOS Certificate After Axios Supply Chain Cascade

OpenAI revoked its macOS application signing certificate after the Axios supply chain incident — which compromised a GitHub Actions workflow on March 31 — exposed the signing pipeline used for the macOS ChatGPT application. OpenAI states no user data was compromised, but the exposure of the signing workflow required a full certificate rotation and application re-signing.

This is the second-order effect of the Axios GitHub Actions compromise that has been cascading through downstream consumers for two weeks. The attack did not target OpenAI directly. It compromised a widely used CI/CD component, and OpenAI’s build pipeline consumed that component. The signing certificate — a critical trust anchor for macOS application distribution — was in the blast radius.

The broader lesson is that code-signing certificates are only as trustworthy as the CI/CD pipeline that handles them. If secrets (signing keys, API tokens, deploy credentials) are accessible to third-party GitHub Actions dependencies, a compromise of any dependency in the chain exposes those secrets. This maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise) and T1588.003 (Obtain Capabilities: Code Signing Certificates).

What defenders should do: Audit CI/CD pipelines for third-party action dependencies. Signing keys and deploy credentials should be isolated in hardware security modules or dedicated signing services that are not accessible from the build runner environment. Pin GitHub Actions to specific commit SHAs rather than mutable tags. If your organization consumed the affected Axios component, assume secret exposure and rotate all credentials accessible to the affected workflow.

APT37 Shifts to Facebook for Social Engineering and RokRAT Delivery

North Korea’s ScarCruft group (APT37) is using Facebook friend requests as an initial access vector, targeting individuals with access to North Korea policy information. The group builds trust through social media interaction over time, then delivers RokRAT — a well-documented remote access trojan associated with ScarCruft operations since at least 2017.

The shift from spear-phishing email to social media-based social engineering is tactically significant. Email security controls — URL rewriting, attachment sandboxing, DMARC enforcement — do not apply when the initial contact happens on Facebook. The attacker builds rapport in a channel defenders do not monitor, then transitions to a delivery mechanism (direct message link, shared file) after trust is established.

RokRAT provides screen capture, keylogging, file exfiltration, and command execution capabilities. It has historically used cloud services (Dropbox, Yandex, pCloud) for C2, making network-based detection difficult. The technique chain includes MITRE ATT&CK T1566.003 (Phishing: Spearphishing via Service) for initial access and T1102 (Web Service) for C2.

What defenders should do: Security awareness training should explicitly cover social media-based social engineering — not just email phishing. Endpoint detection tooling should be tuned to detect RokRAT-family behaviors (cloud service C2, screen capture API calls, credential dumping) regardless of the delivery vector. Organizations in the policy, defense, and diplomatic sectors should consider social media monitoring for targeted approaches against key personnel.

Today’s Deep Dive — Software Supply Chain Attacks: When Trusted Sources Become the Vector

Two of today’s top stories — CPUID’s compromised download site and the cascading Axios-to-OpenAI pipeline breach — share a common root: the exploitation of trust in software distribution channels. This is not a new category, but the operational frequency is accelerating, and the attack surface is expanding from large package registries into small utility publishers and CI/CD dependency chains.

The supply chain attack model inverts the normal defensive assumption. Perimeter controls, email security, and user awareness training all assume the threat arrives from an untrusted source. Supply chain compromise delivers the payload from a source the organization has already decided to trust — a vendor website, a package registry, a CI/CD component. The malicious artifact arrives through the same channel as legitimate software, often with valid signatures and expected file hashes (because the attacker controls the distribution point).

There are two distinct patterns in today’s stories:

Pattern 1 — Distribution site compromise (CPUID). The attacker gains access to the vendor’s web infrastructure and replaces legitimate binaries with trojanized versions. The domain, the download page, and the file names all appear legitimate. The defense is binary integrity validation — checking hashes against an out-of-band source, or enforcing application allowlisting that blocks unsigned or unknown binaries. MITRE ATT&CK: T1195.002.

Pattern 2 — CI/CD dependency chain compromise (Axios → OpenAI). The attacker compromises a component consumed by the build pipeline. The target organization’s own build process then incorporates the compromised component, potentially exposing secrets, injecting code into artifacts, or — as in the OpenAI case — exposing signing credentials. The defense is dependency pinning (commit SHA, not mutable tag), pipeline secret isolation (HSM-backed signing, short-lived credentials), and build provenance attestation (SLSA framework). MITRE ATT&CK: T1195.002, T1588.003.

The common thread is that neither pattern is stopped by endpoint detection alone. EDR will detect the payload after execution, but the initial access leveraged a trusted channel. Defense requires controls earlier in the chain: software bill of materials (SBOM) tracking, hash validation before installation, allowlisting policies that block unsigned binaries, and CI/CD pipeline hardening that isolates secrets from third-party dependencies.

Organizations that treat “we trust this vendor” as a permanent security decision — rather than a continuously validated assumption — will keep appearing in these stories.

Detection Spotlight

This week’s detection focuses on identifying anomalous child processes spawning from Adobe Reader — the primary observable behavior during CVE-2026-34621 exploitation. When a crafted PDF triggers arbitrary code execution, the exploit typically spawns a child process (cmd.exe, powershell.exe, rundll32.exe, or a dropped binary) under the Reader process tree. This is almost never legitimate behavior.

Splunk SPL — Anomalous Adobe Reader child processes:

index=endpoint sourcetype=sysmon EventCode=1
(ParentImage="*\\AcroRd32.exe" OR ParentImage="*\\Acrobat.exe")
NOT (Image="*\\AcroRd32.exe" OR Image="*\\Acrobat.exe" OR Image="*\\AdobeARM.exe" OR Image="*\\AdobeCollabSync.exe")
| eval suspicious=if(match(Image, "(?i)(cmd|powershell|rundll32|mshta|wscript|cscript|regsvr32|certutil)\.exe"), "high", "medium")
| stats count by Image, ParentImage, User, ComputerName, suspicious
| sort - suspicious, - count

What it catches: Any process spawned as a child of Adobe Reader that is not a known legitimate Adobe subprocess. The suspicious field flags common living-off-the-land binaries (LOLBins) as high-priority. In a healthy environment, this query should return near-zero results. Adobe Reader does not legitimately spawn command interpreters, script hosts, or system utilities.

False positive rate: Low. Legitimate Adobe subprocesses (AdobeARM.exe for updater, AdobeCollabSync.exe for collaboration features) are excluded. The primary false positive scenario is a legitimate browser plugin or accessibility tool that interacts with the Reader process tree — tune by adding specific exclusions after initial baseline review.

KQL equivalent for Microsoft Sentinel:

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("AcroRd32.exe", "Acrobat.exe")
| where FileName !in~ ("AcroRd32.exe", "Acrobat.exe", "AdobeARM.exe", "AdobeCollabSync.exe")
| extend Suspicious = iff(FileName in~ ("cmd.exe", "powershell.exe", "rundll32.exe", "mshta.exe", "wscript.exe", "cscript.exe", "regsvr32.exe", "certutil.exe"), "High", "Medium")
| project Timestamp, DeviceName, AccountName, FileName, InitiatingProcessFileName, ProcessCommandLine, Suspicious
| sort by Suspicious desc, Timestamp desc

Deploy both queries now. If CVE-2026-34621 was exploited in your environment during the months-long pre-patch window, this is how you find the evidence.

References

Subscribe to the it-learn Brief

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