Friday, August 21, 2026 | Jonathan Brown

A Rust supply-chain compromise executed malware during software builds

The Rust Project responded on August 20 to a supply-chain attack involving three crates published through what appears to have been a compromised maintainer account. Malicious releases of arrayref, internment, and append-only-vec were uploaded to crates.io and then removed within roughly 86 to 107 minutes. The affected versions were arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9.

The attack is important because the malicious behavior occurred during compilation. The altered crates introduced dependencies including the typosquatted proc-macro1, whose build.rs script downloaded and executed a remote binary. A developer did not have to call a malicious function after installing the dependency; simply building a project that resolved one of the poisoned releases could execute the payload on the build host.

The RustSec advisory for arrayref reports that the malicious version was downloaded 2,285 times — under 10 percent of arrayref's overall download traffic — so exposure was limited but not absent, and confirmed use of the payload on any given host still requires local verification. A package download is not, by itself, evidence that malicious code successfully executed.

That distinction leaves CI/CD systems in a sensitive position. Organizations should inspect Cargo lockfiles, dependency caches and CI logs for the affected versions and associated malicious dependency names. Where a build host did execute one of the poisoned dependencies, defenders should investigate the host as potentially compromised rather than simply reverting the package, because build systems frequently hold signing credentials, repository tokens, cloud credentials and deployment secrets.

Watch for: Evidence that the downloaded payload successfully executed in production developer or CI environments, additional packages tied to the suspected account compromise, or identification of the actor behind the intrusion.

Sources: RustSec advisories RUSTSEC-2026-0260 for arrayref, RUSTSEC-2026-0262 for append-only-vec, and RUSTSEC-2026-0266 for internment, August 2026; Rust Project supply-chain incident reporting, August 20, 2026.

Russian-linked espionage clusters are turning legitimate authentication into an attack surface

Google Threat Intelligence Group reported on August 20 that three separately tracked suspected Russian cyber-espionage clusters — UNC6293, UNC7005 and UNC5976 — have been targeting people in government, aerospace and defense, academia and think tanks across Europe, with additional targeting of academics and researchers in the United States.

The operations combine legitimate-authentication abuse with malware delivery. Google observed techniques involving application passwords, Microsoft device-code phishing, Google OAuth authorization and WhatsApp device linking, alongside OS-targeted Vidar malware for Windows and Atomic infostealer payloads for macOS served from attacker-controlled infrastructure.

In one UNC7005 sequence, targets were directed through a legitimate Google login before being handed to an attacker-controlled cloud project designed to obtain authentication tokens. Other operations induced victims to link WhatsApp accounts to attacker-controlled devices. These techniques allow attackers to exploit the trust users place in real authentication workflows rather than relying entirely on obviously fraudulent login pages.

The operational lesson is that multifactor authentication can be functioning as designed while the attacker still succeeds. Defenders protecting diplomatic, defense, research and executive populations should review newly authorized OAuth applications, unusual device-code authentication, creation of application passwords, unexpected token grants and newly linked messaging devices. When compromise is suspected, token revocation and session invalidation can matter as much as password changes.

Google assesses UNC6293 and UNC7005 with moderate confidence as initial-access clusters associated with ICE RELIC, activity formerly associated with APT29. UNC5976 is tracked separately, and the three clusters should not be treated as one proven organization.

Watch for: Additional evidence connecting the clusters more firmly to Russian intelligence infrastructure, expansion into enterprise identity tenants rather than individual accounts, or new defensive controls from Google, Microsoft and Meta against abuse of legitimate authorization workflows.

Sources: Google Threat Intelligence Group, “Going with the Flow(s): Distinct Clusters Target Individuals of Interest to Russia,” August 20, 2026.

A Passportal browser-extension flaw exposed the keys to entire MSP password vaults

Security researcher James Arnott of Bay Area Labs publicly disclosed a serious N-able Passportal weakness on August 20 after privately reporting it in July. Passportal is a cloud-based privileged-access and password-management platform marketed heavily to managed service providers. N-able says the service is used by roughly 2,500 MSPs serving about 165,000 small and medium-sized businesses.

The vulnerable browser extension accepted messages from arbitrary webpages without sufficiently validating their origin. A malicious site, compromised site or hostile iframe could therefore ask the extension for Passportal authentication material. The researcher demonstrated access to both access and refresh tokens; the access token included key material required to retrieve vault credentials, while the refresh token could remain useful for as long as 100 days. That could expose passwords and time-based one-time passwords stored for customer systems.

N-able deployed an origin-checking fix the day after the July 8 report. The disclosed browser-extension attack is therefore patched, and public reporting has not established exploitation in the wild. MSPs should nevertheless verify that managed browsers actually received the updated extension rather than assuming automatic updates succeeded. Any environment that may have encountered the vulnerable extension while browsing hostile content should consider token revocation and examine privileged-account access rather than treating the software update alone as sufficient.

The downstream implications are what make this more than another password-manager bug. An MSP vault can contain administrative access for dozens or hundreds of customer environments. A single credential-vault compromise therefore creates a potential supplier-to-customer compromise path.

Watch for: Evidence of exploitation before the patch, a formal N-able incident assessment, or additional hardening designed to reduce the amount of vault decryption material handled by the cloud service.

Sources: Bay Area Labs, “Solar Winds Part 2 Avoided: N-Able Passportal Vault Leak,” 2026; Dark Reading, “N-able Bug Exposes Password Vault Master Keys,” August 20, 2026.

Gogs fixes a Git-server RCE, but researchers say an authorization bypass remains

Aikido Security disclosed on August 19 that Gogs, the self-hosted Git service, patched CVE-2026-52813 in version 0.14.3. The flaw allowed an authenticated user to create an organization name containing path-traversal sequences through the API, giving the attacker a way to create Git repository structures outside their intended filesystem location. Researchers then combined that primitive with Git hook behavior to achieve command execution as the Gogs git user.

Aikido published working technical details, so this is not merely a theoretical path traversal. The demonstrated chain creates a nested bare Git repository, modifies its update hook through another repository's editable worktree and triggers that hook through a Git operation. Gogs 0.14.3 addresses CVE-2026-52813. No evidence of malicious exploitation was reported in the disclosure.

More concerning for some operators is CVE-2026-52810, a separate Git HTTP authorization flaw. A user who should have only read access can under certain configurations confuse Gogs' distinction between git-upload-pack and git-receive-pack and push content to a repository. Aikido says the vendor's initial correction can still be bypassed using case differences in the path, and at publication time it did not consider any official release fully fixed for that bypass. Private repositories, or installations requiring sign-in to view repositories, are especially relevant.

For repositories tied directly to automated deployment, unauthorized write access can become a supply-chain problem even without server RCE. Gogs operators should upgrade for the fixed RCE, assess exposure to the unresolved authorization bypass, restrict access to the service and review unexpected pushes, repository modifications and CI/CD executions.

Watch for: A Gogs release that closes the remaining CVE-2026-52810 bypass and any evidence that either vulnerability has been exploited against internet-accessible installations.

Sources: Aikido Security, “Yet another RCE in Gogs, but it's fixed this time!”, August 19, 2026; Gogs 0.14.3 remediation referenced in the disclosure.

NASA ground-system software exposed unauthenticated command paths in AIT-GUI

Cycode disclosed on August 18 a critical security chain in AIT-GUI, the browser-based operator interface for NASA/JPL's open-source AMMOS Instrument Toolkit. AIT is intended for ground data systems that send commands to instruments and spacecraft and receive telemetry. Cycode found state-changing command, script and sequence endpoints exposed without conventional authentication or authorization controls, together with cross-site request forgery exposure and a server that could listen on all network interfaces.

The most direct routes could issue commands through /cmd, execute server-side scripts through /script/run, or execute command sequences through /seq. Cycode assigned the chain GitHub identifier GHSA-p9r8-2q67-fp86 and says the issue is fixed in AIT-GUI 2.5.2. No in-the-wild exploitation has been reported, and neither the original research nor subsequent public reporting has identified a spacecraft mission known to have been compromised.

Distribution remains an operational concern. PyPI continues to list AIT-GUI 2.4.1 as the latest packaged release, meaning operators relying on the normal Python package channel may not automatically receive the corrected 2.5.2 release. Administrators should therefore verify the actual version and provenance of the code running in their environment rather than assuming their package source contains the latest security correction.

Operators using AIT-GUI should keep the console on tightly controlled management networks, confirm listener bindings and inspect prior command and sequence activity if the service was reachable from untrusted systems. The central issue is not whether every AIT deployment was exposed, but whether a command interface intended for operational control was reachable beyond its assumed trust boundary.

Watch for: Updated AIT-GUI distribution through standard package channels, clarification from NASA/JPL on supported deployment architecture, or evidence that exposed installations were reachable from untrusted networks.

Sources: Cycode, “When the NASA Ground Station Has No Lock on the Door,” August 18, 2026; PyPI AIT-GUI project page, accessed August 21, 2026.

Researchers turn HTTP/3 translation inside major CDNs into a denial-of-service amplifier

Academic researchers have disclosed a class of attacks they call “CDN Tsunami,” exploiting the protocol mismatch that can occur when a content-delivery network accepts HTTP/3 from clients but communicates with an origin server using HTTP/1.1. Their paper describes both bandwidth-amplification and connection-amplification variants.

The researchers identified 42,330 subdomains that appeared potentially vulnerable in their large-scale measurement. Testing covered Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly and Tencent. Public reporting says all six were susceptible to the bandwidth technique in researchers' testing, while five were susceptible to connection amplification. Reported amplification reached as high as roughly 350 times the attacker's input traffic under laboratory conditions.

This is research, not evidence of an ongoing Internet-wide attack campaign. The authors responsibly disclosed the findings, and the paper says two vendors had acknowledged the issue and deployed mitigations by publication. The broader lesson is architectural: a CDN may absorb malicious client traffic successfully while translating it into much more expensive traffic or connection pressure against the supposedly protected origin.

Operators should examine how their CDN translates HTTP/3 to backend protocols, whether origins are directly reachable, and whether origin-side bandwidth, connection and request limits are sized for traffic generated by the CDN rather than merely by apparent clients.

Watch for: Vendor-specific advisories, broader mitigation deployment, or evidence that attackers have begun using protocol-translation amplification against production origins.

Sources: Ziyu Lin et al., “CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks,” July 29, 2026, accepted at IEEE SRDS 2026.

A JavaScript sandbox escape challenges another layer used to contain untrusted code

Researchers disclosed on August 20 a critical flaw in isolated-vm, a Node.js library specifically designed to execute JavaScript inside separate V8 isolates. The issue, tracked as GHSA-864f-rcv7-6rh4, affects versions through 7.0.0 and is reported fixed in the 6.x branch at 6.2.0 and the 7.x branch at 7.0.1.

The weakness involves type confusion around ExternalCopy transfer handling. Research demonstrated a crash and a control-flow-hijack proof of concept providing a path toward code execution outside the expected sandbox boundary. That matters wherever the library serves as a security boundary for customer-supplied scripts, plugin systems, workflow automation or AI-agent execution.

No active exploitation has been reported. The project's security documentation already warns that V8 isolates should not be treated as the sole protection layer against hostile code and recommends separate processes for higher-risk environments. Organizations using isolated-vm should identify the deployed major branch, move to a corrected release, and review whether host secrets, filesystem access, cloud credentials or network privileges are reachable if an isolate boundary fails.

This has particular relevance to agentic and automation platforms. Any system accepting semi-trusted JavaScript and relying on an in-process sandbox should assume that sandbox escape remains part of the threat model and use operating-system or workload isolation as an additional barrier.

Watch for: A CVE assignment, wider technical proof-of-concept release, and disclosures identifying major services that rely on vulnerable isolated-vm deployments.

Sources: Endor Labs analysis of GHSA-864f-rcv7-6rh4, August 2026; isolated-vm project security documentation.

Elementor Pro file uploads can become unauthenticated server code execution

Patchstack disclosed CVE-2026-32475 on August 19, affecting Elementor Pro installations through version 4.2.1. The WordPress plugin's Forms module can mishandle multipart file uploads in a way that allows an unauthenticated attacker to bypass extension filtering and place a PHP file into a web-accessible directory. Version 4.2.2 is listed as corrected.

The vulnerability depends on site configuration. The target needs a published Elementor form containing a File Upload field. Where that condition exists, no WordPress account is required. Patchstack's analysis found that validation and file-processing loops handle an empty file entry differently; by supplying multiple file parts for the same form field, an attacker can cause a dangerous file to escape the intended extension check. Successful placement of executable PHP provides a direct path to code execution as the web-server account.

There is now enough technical detail to make reproduction plausible, but public reporting does not establish active exploitation. Operators should upgrade Elementor Pro to 4.2.2 or later, determine whether public forms include file-upload fields, and examine web-accessible upload directories and HTTP logs for unexpected PHP creation or suspicious multipart submissions if vulnerable versions were exposed.

The larger concern is scale. WordPress plugins create a common route from a public web form to the underlying server, and compromised sites are often repurposed as malware distribution infrastructure, credential-phishing hosts or command-and-control infrastructure rather than merely defaced.

Watch for: Public exploit automation, scanning for vulnerable forms, or evidence of webshell deployment against unpatched Elementor Pro installations.

Sources: Patchstack advisory for CVE-2026-32475, August 19, 2026; CVE record for CVE-2026-32475.

Manic malware can move stolen Android data through nearby infected phones

ThreatFabric has identified a new Android malware family called Manic that combines banking-fraud capabilities with extensive surveillance and remote control. Reporting published August 20 says the malware particularly targets applications associated with Ukrainian banks, government and electronic-identity services, while its target list also includes financial institutions, cryptocurrency services, messaging applications, authenticators and military-oriented communications.

Manic can abuse Android Accessibility services to capture text and PIN entries, monitor the screen, collect SMS messages, notifications, contacts, files and location data, and provide interactive remote access through WebRTC. The novel part is its store-and-forward exfiltration system. If one infected phone cannot reach command-and-control infrastructure, Manic can search for another infected device using Wi-Fi Direct, Bluetooth RFCOMM or Bluetooth Low Energy and relay encrypted data through that device. The implementation supports multiple hops, with four relays reported as the default limit.

That does not mean Manic can magically extract data from a truly isolated device with no nearby infected peer. It means simply removing Internet access from a compromised phone may not stop exfiltration when another infected handset is physically nearby. That distinction matters for government, military and controlled facilities where mobile devices may be locally connected while WAN access is restricted.

Organizations managing high-risk Android fleets should review sideloading controls and Accessibility-service grants, restrict unnecessary Bluetooth and Wi-Fi Direct functionality through mobile-device management where operationally possible, and treat unexpected peer-to-peer discovery from managed phones as potentially meaningful telemetry.

Watch for: Evidence of Manic spreading within government or defense populations, expansion of the peer-relay architecture, and identification of the operators or distribution infrastructure behind the campaign.

Sources: ThreatFabric research on Manic, August 2026; The Hacker News reporting based on ThreatFabric findings, August 20, 2026.

Microsoft Defender's own remediation driver can be repurposed as a kernel-level attack tool

Check Point Research published its full “BTR Reforged” analysis on August 20 after presenting the work at Black Hat earlier this month. The research reverse-engineers BTR.sys, Microsoft Defender's signed Boot-Time Removal driver, which is designed to modify or remove malicious files and registry data early during system startup. Researchers found that the driver's proprietary transaction system can be recreated so the legitimate Microsoft-signed component performs attacker-chosen file and registry operations from kernel mode.

This is not a remote vulnerability and should not be described as an initial-access technique. An attacker already needs substantial control of the Windows system, including SeLoadDriverPrivilege, before the technique becomes usable. Its value comes after compromise: rather than exploiting memory corruption or loading an obviously vulnerable third-party driver, an operator can attempt to make a trusted defensive driver perform privileged operations it was built to perform.

Check Point tested signed BTR.sys builds spanning Windows 7 through fully updated Windows 11 systems. The researchers found a hard-coded RC4 key shared across 18 signed driver builds, released a research tool called BTR_CLI and demonstrated deletion of Defender components during the early boot phase. Microsoft Security Response Center did not classify the finding as a vulnerability requiring a normal CVE or software security update.

That makes behavioral detection particularly important. Defenders should focus on unexpected staging or invocation of BTR transaction material, unusual boot-time file and registry modifications, attempts to disable endpoint-security components, and the broader sequence of privileged activity that must precede successful abuse. The presence of Microsoft's signature on the driver should not be treated as evidence that the resulting operations are benign.

Watch for: Real-world use of BTR-style transaction abuse by malware or red-team tooling, Microsoft changes to the remediation architecture, or new endpoint detections capable of distinguishing legitimate Defender cleanup from attacker-generated transactions.

Sources: Check Point Research, “BTR Reforged: Weaponizing Defender's Remediation Driver as a Kernel Operation Primitive,” August 20, 2026; Check Point Black Hat research summary, August 2026.

Search Tags: Rust supply chain, Russian cyber espionage, Passportal, Gogs, NASA AIT-GUI, CDN Tsunami, Android Manic, Microsoft Defender

Introduction: Today's feed follows attacks on the systems we trust most: developer packages, identity flows, password vaults, code sandboxes, ground-control software and even Defender itself.

Jonathan Brown is a cybersecurity researcher and investigative journalist at bordercybergroup.com.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.