Saturday, August 22, 2026 | Jonathan Brown

The daily feed follows events as they break. The Week in Review steps back from the incident queue and asks a different question: what did the week look like as a whole?

From Monday, August 17, through Saturday, August 22, the answer was trust—specifically, the danger created when organizations trust internet-exposed controllers, cloud authentication flows, software registries, management platforms, signed drivers, and familiar collaboration services more than the evidence justifies.

The individual stories ranged from Siemens industrial controllers and exploited Zimbra servers to poisoned Rust packages, Russian authentication abuse, Chinese-nexus espionage, Microsoft 365 command-and-control, and enterprise software flaws that moved rapidly from disclosure toward probing or exploitation. The technologies differed, but the operational pattern remained remarkably consistent: attackers looked for components already permitted to build software, administer infrastructure, authenticate users, carry trusted traffic, or operate below conventional security controls.

The week was therefore not primarily about an extraordinary new exploit technique. It was about attackers finding more efficient ways to inherit trust that defenders had already granted.

INDUSTRIAL CONTROL SYSTEMS MOVED FROM ABSTRACT EXPOSURE TO ACTIVE CONTESTED TERRAIN

The most consequential development came from the operational-technology environment. On August 19, CISA, the National Security Agency, FBI, Department of Energy, and Environmental Protection Agency warned of an active threat targeting Siemens S7-series programmable logic controllers used in water, energy, manufacturing, agriculture, chemicals, commercial facilities, and the defense industrial base.

The advisory described actors locating exposed controllers, downloading project information, examining logic, and developing capabilities to interact with operational processes. Particularly important was the reported use of AI-generated exploitation scripts disguised as legitimate monitoring tools. Those scripts lower the amount of specialized engineering knowledge required to identify controllers, communicate with them, and perform read or write operations.

This does not mean that a language model has independently devised a sophisticated industrial sabotage campaign. The more defensible conclusion is narrower and more operationally important: AI assistance is compressing the time required to translate publicly available documentation, open-source libraries, and known protocol behavior into usable targeting tools. An attacker still needs access, suitable controller configurations, and knowledge of the physical process before a reliable disruptive effect can be produced. But the preparatory work is becoming faster, cheaper, and easier to distribute.

The advisory arrived against the background of Iranian-affiliated targeting of internet-connected Rockwell Automation, Schneider Electric, and Siemens controllers, along with separate compromises affecting American water systems. Public reporting has not established that the new Siemens activity and the recent water-utility incidents were performed by the same operators, using the same infrastructure, or under one coordinated campaign.

That absence of tactical attribution should not prevent strategic analysis. The target class, timing, operational objectives, and recurring interest in exposed programmable controllers are close enough that defenders should evaluate the activity together. It would be equally irresponsible to declare a single Iranian campaign without evidence or to assume that overlapping attacks against the same fragile operational environment must be unrelated.

The deeper problem is structural. Many small utilities and industrial operators still have controllers exposed through weakly protected remote-access paths, incomplete asset inventories, vendor-default assumptions, or networks in which engineering access is treated as trusted by definition. Once an actor can retrieve project files or manipulate controller logic, the consequences are not limited to losing information. Alarm behavior, shutdown functions, human-machine interfaces, and the operator’s picture of the physical process can all become targets.

This is where comparisons with Stuxnet are useful, provided they are kept proportional. The current reporting does not demonstrate a Stuxnet-level operation, a comparable multi-stage exploit chain, or the same degree of process-specific engineering. The similarity lies instead in the strategic premise: compromise the control layer, understand the physical process, and manipulate the relationship between what machinery is doing and what operators believe it is doing.

Defenders should therefore stop treating the Siemens warning as a vendor-specific patch notice. The immediate question is not simply whether an S7 controller has current firmware. It is whether any controller, engineering workstation, human-machine interface, or programming service is reachable from an untrusted network; whether project-file access is logged; whether logic changes require independent authorization; and whether operators can detect a discrepancy between controller state and physical conditions.

Watch for: Technical indicators connecting the Siemens targeting to identified water-system compromises, evidence of destructive logic changes, or formal attribution by the agencies that authored the advisory.

Sources: CISA joint advisory AA26-231A, “Defending Against an Active Threat to Siemens S7 Series PLCs,” August 19, 2026; CISA advisory AA26-097A on Iranian-affiliated PLC targeting, updated July 22, 2026; Reuters reporting on the Siemens warning and water-sector context, August 19, 2026.

THE PATCH CLOCK DID NOT RECOVER—IT BECAME MORE SELECTIVE

Last week’s review concluded that the patch clock had collapsed from days to hours. This week did not reverse that trend. It clarified it.

Attackers are not attempting to weaponize every critical vulnerability at the same speed. They are selecting flaws that combine reachability, valuable access, and a manageable attack path. The result is a highly uneven environment in which some maximum-severity defects remain unexploited while configuration-dependent flaws with lower scores become immediate operational problems.

SAP Commerce Cloud illustrated the compressed disclosure cycle. CVE-2026-58231 was disclosed and patched on August 11, and exploitation attempts or probing were reported three days later. The observed activity did not prove widespread compromise, but it demonstrated how little time defenders of an internet-facing commerce platform could assume they had.

Ray’s CVE-2025-62593 entered the CISA Known Exploited Vulnerabilities catalog during the week, establishing that exploitation had occurred somewhere in the real world. Public proof-of-concept material showed how browser-based DNS rebinding could reach services that operators may have assumed were protected by network placement. CISA did not identify victims, scale, or the exact observed attack chain, so the catalog entry established exploitation—not a universal description of how every vulnerable Ray deployment was being attacked.

MLflow followed the same pattern at the intersection of AI infrastructure and cloud access. CVE-2026-64849 allows unauthenticated server-side request forgery through the model-registry webhook test functionality under affected configurations. Redirect handling and DNS behavior could allow requests to reach internal services or cloud metadata endpoints, with the response returned to the attacker. Version 3.15.0 contains the fix, and CISA added the vulnerability to its exploited catalog on August 19.

The significance of the MLflow flaw was not merely that an AI-related product had a critical vulnerability. A tracking server may be connected to model artifacts, object storage, databases, credentials, automation systems, and cloud metadata. Server-side request forgery in that position can become a route into the surrounding control environment. The correct response is therefore not limited to upgrading the package. Exposed systems require investigation for requests to metadata addresses, unusual webhook creation or testing, internal-service access, and possible theft of reachable credentials.

Zimbra provided the week’s clearest example of configuration-dependent exploitation. CVE-2026-73570 affects Zimbra Collaboration Suite releases before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Specially crafted SMTP input can reach the notification-processing path and execute operating-system commands as the Zimbra user. CERT Polska confirmed active exploitation, and on August 21 CISA added the flaw to its Known Exploited Vulnerabilities catalog.

The important word is not simply critical. It is enabled. A Zimbra server without the relevant SNMP functionality does not present the same path. A vulnerable server with the package installed and notification processing active can be attacked without authentication. That distinction should drive triage.

The weekend brought two further reminders that exploitation status is evidence, not decoration. Reports attributed active exploitation of GitLab CVE-2026-19478 to WatchTowr observations. GitLab had already issued emergency fixes in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 for the GraphQL flaw, which can allow an unauthenticated attacker under certain conditions to modify or delete public projects and user data. GitLab’s advisory established the vulnerability and affected versions, but did not itself describe a confirmed campaign. Defenders should act on the exposure while keeping the source of the exploitation claim explicit.

Microsoft’s Entra ID CVE-2026-69836 produced the opposite correction. Microsoft’s bulletin initially marked the maximum-severity, server-side remote-code-execution flaw as exploited. On August 21, after questions from The Hacker News, Microsoft changed the status to No and stated that the vulnerability had not been exploited in the wild. The service had already been mitigated by Microsoft, and customers were not required to patch anything.

That correction materially changed the assessment. The vulnerability remained technically severe, but it was no longer an exploited zero-day. More broadly, the episode demonstrated that even vendor exploitation fields can be revised. Automated systems that ingested the original value may continue to repeat a stale conclusion unless their records are refreshed.

Watch for: Additional CISA entries, vendor-confirmed exploitation of the GitLab flaw, or incident-response findings showing cloud credential theft through compromised MLflow servers.

Sources: GitHub advisory GHSA-7gwp-5pfp-969j for MLflow CVE-2026-64849, updated August 17, 2026; CISA Known Exploited Vulnerabilities Catalog; CERT Polska advisory 145/2026 on Zimbra exploitation; NIST record for Zimbra CVE-2026-73570; GitLab critical patch release, August 17, 2026; The Hacker News correction to Microsoft’s Entra ID exploitation status, August 21, 2026.

LEGITIMATE IDENTITY AND CLOUD SERVICES BECAME PART OF THE ATTACK INFRASTRUCTURE

Several of the week’s espionage stories were connected by a shift away from obviously malicious infrastructure. Attackers increasingly used authentication workflows, residential proxies, cloud-storage services, collaboration platforms, and trusted browsers as parts of the intrusion itself.

Google’s Threat Intelligence Group described three Russian-nexus clusters—UNC6293, UNC7005, and UNC5976—targeting people in government, defense, aerospace, academia, nongovernmental organizations, and think tanks across Europe and the United States. The clusters abused legitimate authentication processes rather than relying solely on conventional credential-harvesting pages.

Google assessed all three clusters as Russian-nexus with high confidence. It assessed UNC6293 and UNC7005 as related, with moderate confidence, to an initial-access subcluster of ICE RELIC, a grouping formerly associated with APT29 activity. UNC5976 remained distinct and may reflect a different intelligence requirement or organizational relationship.

The operational lesson was more important than the naming. Authentication defenses often focus on whether a password is correct, whether multifactor authentication completed, and whether the session came through an apparently normal service. Sophisticated phishing can manipulate the user into participating in a legitimate flow, while residential proxies and carefully staged infrastructure reduce obvious geographic or network anomalies. The resulting session may look less like a stolen password and more like a real user making a bad decision inside an authentic process.

TWINLOOT extended the same concept into command-and-control. Ontinue described a Python implant that used SharePoint Online file dead drops through Microsoft Graph, Microsoft Teams TURN infrastructure for interactive communications, and a headless instance of the victim’s own Edge browser to generate traffic. The framework could present convincing false Windows lock screens to collect credentials and provide a SOCKS5 route into the victim network.

No public reporting established TWINLOOT’s deployment across a large victim population. Its significance was architectural. A defender can block an unfamiliar command-and-control domain. It is much harder to block SharePoint, Teams, Graph, or Edge in an organization that depends on Microsoft 365.

SilkParasite, a separate espionage operation investigated by Bitdefender, showed a similar preference for blending custom tooling with ordinary infrastructure. Bitdefender assessed the campaign as China-nexus with medium confidence and documented seven remote-access-tool families, five of them previously unknown. Targets included government organizations in Central Asia, where Chinese economic expansion and declining Russian influence have increased the intelligence value of diplomatic and economic-policy information.

One SilkParasite tool used Google Drive for communications. Other parts of the campaign relied on password-protected archives, tailored Office documents, macros, and DLL sideloading through legitimate signed applications. These are not revolutionary techniques. They are durable because they place malicious behavior inside tools and traffic patterns that organizations already permit.

The defensive consequence is that identity and cloud telemetry cannot remain separate disciplines. A suspicious consent event, abnormal Graph access, a new SharePoint artifact, a Teams relay pattern, an unusual browser process, and a residential-proxy login may each look inconclusive alone. Together they may describe a coherent intrusion.

Watch for: Microsoft or Google publishing additional indicators for cloud-service command-and-control, confirmed victims of TWINLOOT, or stronger attribution linking the Russian clusters or SilkParasite to established state organizations.

Sources: Google Threat Intelligence Group, “Distinct Clusters Target Individuals of Interest to Russia,” August 20, 2026; Ontinue, “Living Off the Cloud: A Python Implant Hiding Its Entire C2 Inside Microsoft 365 and Azure,” August 18, 2026; Bitdefender Labs, “SilkParasite: Tracking a China-Nexus APT Across Central Asia,” August 2026.

THE SOFTWARE SUPPLY CHAIN FAILED AT THE MOMENT CODE BECAME EXECUTABLE

The Rust supply-chain incident was brief, contained, and operationally serious.

On August 20, the Rust Security Response Team confirmed that malicious versions of arrayref, internment, and append-only-vec had been published from a legitimate maintainer account. Each introduced a dependency on the typosquatted proc-macro1 package. Its build script downloaded and executed a second-stage payload while dependent software was being compiled.

The exposure windows were measured in minutes. Arrayref version 0.3.10 remained available for approximately 86 minutes, internment version 0.8.7 for approximately 90 minutes, and append-only-vec version 0.1.9 for approximately 107 minutes. Arrayref’s malicious version was downloaded 2,285 times before removal. That number establishes distribution, not 2,285 successful infections, and it does not identify how many downloads occurred in analysis systems, mirrors, repeated builds, or production CI environments.

The incident deserved an AMBER assessment rather than RED. The attack demonstrated successful registry and maintainer-account compromise, malicious publication, payload execution capability, and real downloads. Public evidence did not establish broad downstream compromise, bypass of production security systems, or a large population of infected development environments.

The distinction matters because the all-time popularity of arrayref—hundreds of millions of historical downloads—could easily be used to inflate the incident into a claim that the entire Rust ecosystem had been compromised. It had not. Projects with existing lockfiles resolving safe versions were generally protected from automatically selecting the malicious release. Projects that refreshed dependencies or generated new lockfiles during the exposure window faced greater risk.

Removal from crates.io did not remove packages from developer caches, vendored dependencies, container layers, CI images, internal mirrors, or build artifacts. Nor is a clean current registry result sufficient evidence that a system never built the malicious version. Defenders need to examine resolved Cargo.lock files, package caches, CI histories, outbound connections from build workers, and the published payload indicators.

This incident also reinforced a broader lesson from the Snowflake GitHub Actions test covered during the week. In that authorized assessment, a workflow-injection weakness exposed credentials reachable from the CI environment, including a Jira credential. The reported evidence did not establish that GitHub Copilot had authored the vulnerable workflow, despite speculation around the code’s origin. The important fact was that automation executed attacker-controlled input with access to secrets.

In both cases, the security boundary failed when text became action: a package manifest caused a build script to run, while workflow input became a privileged CI operation. Static reputation, a familiar repository name, or a legitimate maintainer account did not make the resulting execution trustworthy.

Watch for: Confirmed organizations that executed the malicious Rust payload, additional compromised maintainer accounts, or evidence that the campaign reached internal package mirrors and persistent CI images.

Sources: Rust Security Response Team, “Supply Chain Attack on Arrayref,” August 20, 2026; RustSec advisory RUSTSEC-2026-0260 for arrayref; RustSec advisory RUSTSEC-2026-0266 for internment; RustSec advisory RUSTSEC-2026-0262 for append-only-vec.

AI BECAME AN ACCELERATOR, BUT TRUSTED AUTOMATION REMAINED THE REAL SECURITY PROBLEM

AI appeared repeatedly in this week’s reporting, but not in one consistent role.

The Siemens advisory described AI-generated exploitation scripts that reduced the expertise and time needed to interact with industrial controllers. Bitdefender found traces consistent with AI assistance in the professionally engineered SilkParasite toolset, but assessed that capable human developers remained in control. The recovered phishing material showed clearer signs of generation than the malware itself.

Cisco released critical fixes for Crosswork, Secure Workload, BroadWorks, and other products. The corrected account is that the relevant flaws were found through Cisco’s existing testing processes. They should not be presented as discoveries produced by frontier AI systems unless Cisco attributes particular findings that way.

Splunk’s Model Context Protocol and AI Toolkit research illustrated a different category of risk. AI-connected tooling can inherit access to data sources, APIs, search functions, credentials, and automated actions. A flaw in that layer is consequential because the orchestration system may already be authorized to cross several security boundaries.

MLflow belonged in the same category. Calling it an AI vulnerability explains very little. The risk came from an unauthenticated web function, weak request validation across redirects, access to internal network locations, and the possible exposure of cloud credentials. Those are familiar security failures positioned inside a newer operational stack.

This distinction is important because AI attack is becoming too broad to guide defensive action. It can describe AI-assisted exploit development, generated phishing content, vulnerable AI infrastructure, prompt-based manipulation, insecure connectors, or ordinary software defects in products marketed around AI. These do not share one mitigation.

The week’s evidence supports a more restrained conclusion. AI is reducing the cost of preparing attacks, translating technical documentation, producing scripts, and maintaining larger toolsets. At the same time, organizations are connecting AI systems to increasingly privileged services. The resulting risk comes from speed on the attacker’s side and inherited authority on the defender’s side.

Neither development abolishes the need for established controls. It makes asset isolation, least privilege, request validation, credential boundaries, change review, and reliable telemetry more urgent.

Watch for: Evidence that AI-generated industrial tooling has been used to cause physical effects, or confirmed compromises in which an AI connector materially expanded an attacker’s access beyond the initially vulnerable service.

Sources: CISA joint advisory AA26-231A, August 19, 2026; Bitdefender SilkParasite research, August August 2026; GitHub advisory for MLflow CVE-2026-64849; Cisco August 19 security publication notice.

SECURITY TOOLS AND MANAGEMENT PLATFORMS CONTINUED TO OFFER HIGH-LEVERAGE ACCESS

Check Point’s BTR Reforged research provided one of the week’s more unusual demonstrations. Researchers reverse-engineered Microsoft Defender’s signed boot-time remediation driver, BTR.sys, and showed how its transaction format could be used to direct kernel-mode file and registry operations.

This was not a remote initial-access vulnerability. An attacker would first require the ability to place and invoke the necessary components on a Windows system. Microsoft did not classify the behavior as a vulnerability requiring a CVE. Those qualifications prevent the research from being exaggerated into a claim that Defender can remotely compromise Windows computers.

The post-compromise implications remain important. Security and remediation drivers are trusted precisely because they must modify protected parts of the operating system. If an attacker can repurpose that authority, the defensive component becomes a mechanism for disabling endpoint protection or altering files and registry data from the kernel. Traditional vulnerable-driver controls may be less effective when the component is legitimate, signed, and associated with Microsoft’s own security software.

Other stories reinforced the same concentration of authority. NetScaler authentication-bypass flaws demanded rapid review because edge appliances mediate remote access, even though public reporting had not established exploitation at the Finnish national cyber authority’s publication cutoff. Cisco’s Crosswork and Secure Workload flaws affected products designed to administer or enforce network policy, although Cisco reported no known malicious use. Passportal, Gogs, NASA’s AIT-GUI, isolated-vm, and WordPress components each presented different paths, but the recurring question was the same: what does the vulnerable component already have permission to reach?

The answer determines priority more reliably than a score alone. A local elevation flaw can be critical after initial access but does not create that access. An unauthenticated flaw in an exposed mail server or management console can create the foothold directly. A compromised build dependency may execute across developer laptops and CI workers. A vulnerable orchestration system may expose every connector attached to it.

The week’s most useful prioritization rule was therefore not patch everything rated ten. It was: patch or isolate what is reachable, exploitable, and trusted to control something larger than itself.

Watch for: Microsoft changes to the BTR driver or its transaction handling, addition of affected builds to driver-blocking controls, or evidence that attackers have used the technique outside research.

Sources: Check Point Research, “BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive,” August 20, 2026; Cisco August 19 security publication notice; Finnish Transport and Communications Agency Cyber Security Centre NetScaler notice, August 19, 2026.

EXTORTION OPERATIONS CONTINUED TO TARGET DATA SYSTEMS THAT ORGANIZATIONS CANNOT EASILY RECREATE

Ransomware and extortion reporting during the week showed that the operational target is no longer always the endpoint fleet or the production server. Attackers continue to prioritize specialized repositories containing information that is difficult to reconstruct, commercially sensitive, or valuable to downstream partners.

The updated federal Medusa advisory reported more than 500 victims as of April 2026, including organizations across critical-infrastructure sectors. That number described activity accumulated since 2021, not 500 new victims during this week. The update nevertheless confirmed the group’s continued relevance and its use of multiple access methods, including stolen credentials and exploitation of vulnerable services.

Cl0p’s Windchill and FlexPLM campaign demonstrated the value of engineering and product-lifecycle systems. The group claimed data theft from more than 40 organizations, including major industrial and technology companies. Reuters could not independently verify the full scope of the claimed theft, and several named organizations described investigations or more limited impact.

The campaign’s strategic logic is credible even where individual criminal claims remain unverified. Product-lifecycle platforms can hold designs, manufacturing documentation, test results, supplier information, product road maps, and regulated technical data. Theft from those systems can expose more than one company and can remain damaging even when operations continue normally.

This is why an extortion campaign that does not encrypt thousands of workstations can still create a serious resilience problem. Backups may restore a deleted engineering repository, but they cannot make stolen product information secret again. Incident plans built primarily around ransomware encryption will miss the legal, competitive, supplier, export-control, and national-security consequences of a data-centered intrusion.

Watch for: Independent confirmation of Cl0p’s claimed victims, downstream supplier notifications, or evidence that stolen engineering data is being sold or used in follow-on intrusions.

Sources: CISA, FBI, and Department of Health and Human Services StopRansomware advisory on Medusa, updated August 18, 2026; Reuters reporting on Cl0p’s Windchill and FlexPLM claims, August 13, 2026; Ransom-ISAC guidance on exploitation affecting PTC Windchill and FlexPLM.

WHAT DEFENDERS SHOULD CHANGE ON MONDAY

Start with trust concentration, not the weekly CVE total. Identify systems that administer other systems, authenticate users, execute builds, operate industrial processes, store enterprise secrets, or connect AI workflows to internal services. Those systems deserve priority even when their vulnerability scores are lower than unrelated defects.

Remove operational technology from direct internet reach. Verify the real path from external networks to controllers, engineering stations, human-machine interfaces, and vendor-support services. Do not accept a diagram or policy statement as proof. Test the route, review firewall rules, and validate that logic changes and project-file access generate usable records.

Treat known exploitation as a possible incident. For MLflow, Zimbra, Ray, and other KEV-listed products, upgrading closes the known vulnerability but does not explain what happened before the upgrade. Review the telemetry appropriate to the actual attack path and rotate credentials that a compromised service could reach.

Search resolved dependencies and build history. Rust teams should inspect Cargo.lock files, caches, vendored directories, CI images, internal mirrors, and build logs for the malicious versions and packages. Checking only current crates.io results will miss deleted packages retained locally.

Correlate cloud identity with endpoint and collaboration activity. Authentication success should not end the investigation. Residential-proxy access, unusual OAuth flows, Graph activity, SharePoint dead drops, Teams relay use, abnormal Edge processes, and new application permissions need to be evaluated together.

Separate technical severity from exploitation status. The Entra ID correction showed how quickly an assessment can change when a vendor updates one field. Vulnerability-management systems should refresh vendor and KEV metadata rather than preserving the first published status indefinitely.

Review security tools as privileged software. Signed remediation drivers, endpoint agents, management consoles, and monitoring systems possess capabilities an attacker may want to inherit. Application allowlisting and signature trust should be combined with behavioral monitoring of what those tools actually do.

Prepare for data-theft extortion without encryption. Engineering, product-lifecycle, identity, and cloud-management systems require response plans that address stolen information, downstream notification, credential exposure, and long-term competitive harm—not only restoration from backup.

THE WEEK’S CONCLUSION

This week’s stories did not describe one unified campaign, one actor, or one newly dominant technique. They described a common operating environment.

Industrial controllers trusted engineering access. Cloud platforms trusted completed authentication. Build systems trusted package manifests. Developers trusted maintainer accounts. Organizations trusted Microsoft 365 traffic because it belonged to Microsoft. Windows trusted a signed remediation driver. Management systems were trusted because controlling other systems was their purpose.

Attackers repeatedly approached those relationships as opportunities.

The resulting defensive challenge cannot be solved by abandoning trust altogether. Modern infrastructure cannot function without delegated authority, automation, reusable packages, remote administration, cloud identity, or signed privileged software. The practical requirement is to make trust narrower, observable, and revocable.

That means reducing direct exposure, limiting connector permissions, recording privileged operations, preserving build provenance, correlating identity and endpoint telemetry, and investigating exploited vulnerabilities according to what the affected system could reach. It also means resisting both directions of analytical error: understating an active threat because attribution remains unresolved, and overstating a vulnerability because a score, headline, or initially incorrect vendor field appears dramatic.

The week’s central lesson is simple. The most dangerous component is often not the one with the highest score. It is the one the rest of the environment has already agreed to obey.

Watch for: Evidence connecting currently separate industrial campaigns, confirmed downstream infections from the Rust compromise, and additional cases in which trusted cloud or security infrastructure becomes the attacker’s preferred operating layer.

Sources: CISA, NSA, FBI, Department of Energy, and Environmental Protection Agency advisories; Rust Security Response Team and RustSec notices; Microsoft Security Response Center; Google Threat Intelligence Group; Bitdefender Labs; Ontinue; Check Point Research; GitLab; Cisco; CERT Polska; Reuters reporting, August 17 through August 22, 2026.

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.