Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Foreign Hackers Got Into Two Colorado Water Systems, Messed With Pump Controls and Killed the Alarms

 




Foreign actors broke into the industrial control systems of two small private water utilities in Colorado last month, altered pumping cycles, changed equipment settings, and shut off the alarms that would have told operators something was wrong. The state confirmed the incidents on Friday. It has not named the utilities or the attackers.

Both systems are privately owned and serve fewer than 200 people each. The intrusions happened in late August. According to the governor's office, the attackers disabled remote access, switched off alarms, and changed how water was being pumped before operators caught on and regained control. Water quality and treatment were not affected at either location.

"These were brief incidents and the risks were quickly addressed by the providers themselves, who subsequently alerted the state," said Ally Sullivan, a spokeswoman for Governor Jared Polis. "To our knowledge, treatment processes and water quality were not impacted at either provider."

Colorado officials did not name a suspect. Sullivan said the office "cannot confirm what foreign actors may have been involved," but pointed to a CISA-tracked Iranian-backed group that has been working to access drinking water and wastewater systems across the country. Federal authorities have made no formal attribution in the Colorado case.


Part of Something Bigger

Colorado is the latest state in a list that has now reached at least 12 reporting intrusions into water system controls this year. The EPA says more than 100 drinking water and wastewater systems have been hit in 2026, most accessed through programmable logic controllers, or PLCs, connected to the open internet via cellular modems, often without the utilities realizing it.

The summer's single worst episode came on July 26 and 27, when attackers hit more than 30 communities in Minnesota in what state IT officials called a coordinated assault. At least four cities publicly confirmed disruptions. One plant went offline entirely; others dropped to manual operation. In Georgia, hackers took down a pump station, cutting pressure enough that residents were advised to boil water before using it. No one reported getting sick.

The FBI and EPA issued a joint warning on July 30 describing attackers who remotely changed IP addresses and passwords on exposed controllers, locking operators out. In some cases, the intrusions created conditions where untreated groundwater could have entered distribution pipes.

CISA said it tracked attacks against more than 100 internet-exposed water sector systems in July alone, the majority accessed through PLCs attached directly to cellular modems.


The Group Investigators Are Watching

The most scrutinized suspect is CyberAv3ngers, a threat group formally tied to Iran's Islamic Revolutionary Guard Corps Cyber-Electronic Command. The U.S. Treasury sanctioned six of its senior officials in February 2024. The State Department has offered $10 million for information on the group's activities.

The group has run through four documented phases since 2020. It started by exploiting default passwords on Israeli-made water utility controllers, moved on to deploying custom malware called IOCONTROL against industrial and IoT devices, and this year shifted to actively exploiting an authentication bypass flaw in Rockwell Automation's widely used Logix PLCs. No vendor patch exists for that vulnerability.

Six federal agencies, CISA, the FBI, NSA, EPA, the Department of Energy, and U.S. Cyber Command, warned jointly on April 7 that Iranian-affiliated actors were actively hitting internet-facing PLCs across water, energy, government, and manufacturing sites.


Congress and Industry Push Back

Senators Adam Schiff and Amy Klobuchar introduced the Water Cyber Shield Act in August, which would give the EPA authority to audit utilities and mandate corrective action. The bill authorizes $300 million annually through existing water infrastructure funds.

At DEF CON, the National Rural Water Association launched the Water Watch Center, pairing five managed security firms with small utilities at no cost. The program targets systems serving under 10,000 people, which make up 91 percent of the country's roughly 50,000 community water systems.

Denver Water, which supplies about 1.5 million people across the metro area, told Axios it evaluated the threat after the Colorado disclosure and found its systems unaffected. Federal investigators are working with state officials to determine how the two utilities were accessed.

Cyberattack Hits University of Munich, Exposing Student Data

 

Germany’s Ludwig Maximilian University of Munich (LMU) is investigating a significant cyberattack that potentially exposed sensitive student information, including financial aid and health insurance data. The breach, detected on a Wednesday, led the university to disconnect affected servers and engage external cyber security experts while cooperating with law enforcement. 

The compromised records reportedly include students’ names, dates of birth, contact details, LMU email addresses, bank account information, and details about their courses of study and prior educational qualifications. In some cases, health insurance numbers and identifiers linked to Germany’s student financial aid program may also have been accessed, along with data related to leaves of absence. However, the university confirmed that examination records, specific course content, and individual academic performance data were not affected. 

Operational impact and response 

Following the discovery of the breach, LMU took several systems offline as a precaution, temporarily disrupting some internal services. While teaching activities continued uninterrupted, enrollment processes were briefly suspended and are expected to resume with extended deadlines to ensure students are not disadvantaged. Some students reported difficulties accessing university services needed for semester preparation, including course registration and grade viewing. The institution has not disclosed the number of affected individuals or the duration of unauthorized access, and no ransom demand has been publicly confirmed. 

Universities remain attractive targets for cybercriminals due to their extensive networks containing vast amounts of personal and financial information across large populations of students, researchers, and staff. Recent ransomware attacks have affected prominent U.S. institutions such as the University of Texas, University of Oklahoma, Stanford University, and the University of Michigan, with several incidents occurring after holiday breaks. Other notable cases include disruptions at the University of Pennsylvania, Columbia University, and Harvard University over the past years.

LMU has enlisted specialists to monitor dark-web forums and other platforms for signs that the stolen information is being circulated or misused. While there is currently no evidence that the data has been altered, deleted, or published, the investigation remains ongoing to determine the full extent of the breach. The attacker has not yet been identified, and the university continues to work with cybersecurity professionals and authorities to secure its systems and protect affected students.

STOMP Backdoor Uses PowerShell for Sensitive Data Theft


An advanced malware campaign known as TASK#STOMP has recently been discovered, which utilizes a PowerShell-based backdoor to collect business documents, Wi-Fi passwords, clipboard data, and screenshots from compromised computers using a PowerShell backdoor. Moreover, the malware also provides attackers with remote command execution and maintains multiple channels for further access. VBScript files are executed via the legitimate Windows Script Host utility wscript.exe in order to initiate the infection. 


In spite of the fact that the exact method of delivery has not been confirmed, phishing or social engineering could be considered possible methods of delivering the script. Following the script's delivery, it sets up a set of scheduled tasks resembling legitimate Windows components, establishing persistence. 

By naming these tasks Local Credential Manager, Network Audio Service, Windows Display Manager, and Device Credential Handler, malicious activities can be blended seamlessly with normal system activities. Another persistence mechanism places another VBScript file in the Windows Startup folder, enabling it to run when the user logs in. 

Upon launching the malware, it executes two PowerShell components. Among these are sys_loader.ps1, which collects documents, gathers system information, steals Wi-Fi passwords, monitors clipboards, captures screenshots, and executes remote commands. Another persistent command-and-control channel, win_conn.ps1, provides additional collection capability as well as a persistent command-and-control channel. 

By monitoring each other and restarting the other process if one is disabled, this setup provides redundancy, making it more difficult to remove the malware if only one process is terminated or a single persistence entry is deleted. In addition to hiding execution activities, timestamp manipulations, and cleanup activities, Task#STOMP can also be used for continuous document theft, increasing the difficulty of detection and forensic investigation. 

As opposed to collecting only files that are already present on an infected computer, TASK#STOMP monitors the file system for newly created or modified documents. This enables the collection of business files as they appear and change during an active infection. In addition to obtaining Wi-Fi credentials and clipboard contents, the malware targets saved Wi-Fi credentials as well. 

With clipboard monitoring, operators can identify information temporarily copied by users, while screenshot capture allows them to view information displayed on a compromised system. By combining these capabilities with remote command execution, Task#STOMP is able to gather more information about user activity than a conventional file-stealing malware. 

A separate command-and-control path, Win_conn.ps1, is maintained by TASK#STOMP in addition to data collection. From win_conn_cfg.dat, the component decodes its configuration and connects to attacker-controlled infrastructure at corecloudfileshare[.]xyz and attachmentsharingdrive[.]xyz. Researcher identification of related traffic can be improved by using a hardcoded authentication token for communication. 

Parts of network communication are handled by a compiled C# component. During connection times, connections can proceed when certificates are invalid, self-signed, or otherwise mismatched due to the code disabling TLS certificate validation. This reduces the level of protection usually provided by certificate checks and makes it easier for the malware to communicate with its servers. Additionally, TASK#STOMP alters file timestamps and cleans up activity following execution to provide further anti-forensic measures. 

According to the researchers, several files have been backdated to January 15, 2024, but that date is not conclusive of when the campaign began. This date was deliberately inserted by the malware, and therefore cannot be regarded as evidence of the age of the campaign. Securonix has not determined why the malware opens a page associated with irantenders[.]com in Chrome, but the page relates to government contracts and tenders in Iran. 

Securonix has not established whether the site indicates a specific victim profile or why it is opened. Researchers have cautioned that the domain alone may not be sufficient to confirm the campaign's geographical or sectoral targeting. Securonix has not linked TASK#STOMP to a known threat group. Due to the use of a single compromised system, it is unclear how the overall campaign scope and duration were determined. 

The initial delivery method is also unclear, although similar VBScript campaigns suggest phishing involving archive or disk image attachments as a possible route. To detect an infection, researchers recommend examining suspicious Windows Script Host and PowerShell activity that originates from writable locations, newly created scheduled tasks, and instances where PowerShell invokes the C# compiler from .NET C#. 

A suspected infection can be investigated with additional evidence from PowerShell Script Block Logging, AMSI telemetry, and scheduled task records.

TraderTraitor Mac Malware Targets IT Firm Through Weaponized Terraform Projects

 

A North Korean-linked cybercrime group known as TraderTraitor has tied another macOS infection in an IT services company with no cryptocurrency ties to the exploitation of fake job interviews to gain access to developer systems. The second victim, which has been identified as an India-based IT services provider, was targeted through one of the employees’ Apple Silicon MacBook belonging to a DevOps engineer. 

The compromised machine was used to manage AWS, OVH and OpenStack environments with the help of Terraform and Ansible, while the account also held cloud credentials and source code access. SentinelOne attributed the breach to the same FLATROOF and ROOFDECK macOS backdoors employed by TraderTraitor in the attack targeting LayerZero Labs that resulted in the $292 million heist from crypto project KelpDAO. Initially detected on March 18 the malicious implants remained undetected until March 29, when they were triggered by the victim launching a workspace within the Cursor development environment. 

FLATROOF implant, which has been dropped as SystemUpdate, can be used to execute arbitrary shell commands, terminate processes and steal data. Its capabilities also include harvesting browser information, terminal history, installed applications, running processes, system properties and the macOS login keychain database. ROOFDECK, which was deployed as iSync utility, allows for full command and control over the compromised system while also facilitating reverse shell access, file transfer exfiltration of data, reconnaissance, and persistent access through the use of LaunchAgents. 

It also has the capability to read the clipboard content, which may also contain passwords, cryptocurrency seed phrases and two-factor authentication (2FA) credentials. On April 20, which came shortly after the public disclosure of the LayerZero breach, the threat actors deployed a modified version of ROOFDECK while removing the initial implants. The new sample continued to communicate with the C2 infrastructure controlled by the attacker until June 1. “The incident serves as a stark reminder that developer endpoints must always be protected and monitored for suspicious activity,” the report noted. 

“These machines can serve as a gateway to cloud infrastructure, source code and deployment resources, which makes them attractive targets even for organizations with no direct involvement in crypto operations.” It added that organizations should carefully monitor developer workstations for anomalous behaviors, including the launch of unsigned binary from the home directory, processes spawned by the development environments, and unusual network connections. 

It also recommended conducting regular audits of the Terraform lock files and make sure that the providers listed in them are legitimate before launching unfamiliar coding assignments or repositories.

Claude Code Glitch Erases Years of Bengaluru Heritage Data

 

A critical AI mishap has put years of digital heritage preservation at risk in Bengaluru, after an automated coding assistant inadvertently wiped out substantial archival work. The incident involving Claude Code, an AI-powered development tool, has forced The Mythic Society—a Bengaluru-based nonprofit dedicated to documenting the city’s history—to rethink its reliance on autonomous systems for managing irreplaceable data. This incident serves as a stark reminder of the vulnerabilities that emerge when cutting-edge technology intersects with culturally significant archives without sufficient safeguards in place. 

The Mythic Society, which launched its heritage documentation project in 2021, saw years of curated content vanish when Claude Code “went rogue” during a routine update or scripting task. While exact technical details remain under review, reports indicate that the AI agent executed unintended commands that deleted or overwrote critical files. The loss encompasses digitized records, historical narratives, and metadata compiled over nearly five years, representing a significant setback for local heritage conservation efforts. For an organization built on preserving Bengaluru’s evolving identity, the disappearance of such work is not just a technical failure but a cultural loss that cannot be easily quantified. 

In the wake of the data loss, The Mythic Society is now allocating approximately Rs 15 lakh to overhaul its backup and recovery infrastructure. This investment aims to prevent similar incidents by introducing redundant storage, stricter access controls, and human-in-the-loop verification for any AI-assisted operations. The society’s leadership has emphasized that while AI tools can accelerate workflows, they must be governed by robust safeguards—especially when handling culturally sensitive and non-replicable archives. The financial commitment reflects both the urgency of restoring lost capabilities and the long-term necessity of building resilient systems that can withstand unexpected technological failures. 

The Bengaluru incident underscores a growing concern in the AI era: over-reliance on autonomous agents without adequate oversight can lead to catastrophic outcomes. Claude Code, designed to assist developers by generating and executing code, is not inherently malicious, but its actions must be constrained within well-defined boundaries. Experts suggest implementing layered approval processes, sandboxed execution environments, and real-time monitoring to mitigate risks when AI interacts with production systems or valuable datasets. As organizations increasingly adopt AI to streamline operations, this case highlights the importance of treating such tools as powerful yet fallible assistants that require constant human supervision. 

For organizations like The Mythic Society, the path forward involves balancing innovation with prudence. AI can undoubtedly enhance efficiency in digitization, transcription, and metadata tagging, but human oversight remains non-negotiable. The society’s decision to invest heavily in backup systems signals a renewed commitment to preserving Bengaluru’s heritage—with a clearer understanding that technology should serve as a tool, not a trustee, of cultural memory. As AI capabilities evolve, so too must the protocols that protect the irreplaceable work built upon them, ensuring that future advancements support rather than undermine the preservation of history.

Hacker vs. Hacker: ShinyHunters Outsmarts Clop Ransomware Gang

 




The extortion group ShinyHunters hacked the dark web leak site run by Clop, one of the most active ransomware operations in the world, defaced it with their own branding, and is now threatening to put Clop through the same extortion process Clop runs on its corporate victims.

The attack happened Friday night, September 19. ShinyHunters found an unauthenticated file upload flaw in Grav CMS, the content management system Clop was running its leak site on, and used it to push a text file directly onto the server. The file read: "THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p - Maybe don't try to threaten us next time." It also linked back to ShinyHunters' own Tor site. The file was confirmed live and downloadable directly from Clop's server.

Hours later, ShinyHunters said they had gone further. A visit to Clop's site showed the entire page replaced with ASCII art of Umbreon, the Pokemon ShinyHunters uses as its logo, and the line "rooting your systems since '19 ;)". The same Umbreon artwork had appeared when ShinyHunters defaced HackForums back in August 2020. Clop's defaced page was still live at the time of writing.

ShinyHunters claimed full access to the server and said they took source code, Grav CMS plugins, and everything stored in the server's /var/log directory, which typically holds authentication logs, system activity records, and the IP addresses of everyone who connected to it. They also claim to have pulled the private keys for Clop's Tor onion service. Those keys are what tie a .onion address to its server. With them, ShinyHunters could host a copy of Clop's site at the exact same onion URL, on infrastructure they control. "We have their onion keys. So if they kick us out it wouldn't matter at all because we control the private keys to host the same exact onion URL," the group said.

The plan is to post an extortion message on their own site and give Clop 72 hours to respond.

The defacement and the uploaded file are independently confirmed. The claims about stolen source code, server logs, and Tor private keys come only from ShinyHunters and have not been independently verified. Clop has not commented.

The dispute behind this attack goes back about a year. In August 2025, Clop quietly began exploiting a zero-day vulnerability in Oracle E-Business Suite, tracked as CVE-2025-61882, a server-side request forgery flaw that gave attackers remote access to enterprise systems without authentication. Oracle did not patch it until October 2025, after Mandiant confirmed active exploitation. By then, Clop had already sent mass extortion emails to executives at dozens of companies, including Cox Enterprises, The Washington Post, Logitech, Michelin, and Estee Lauder.

ShinyHunters says that exploit was originally theirs and that Clop used it without authorization. In October 2025, ShinyHunters, operating under the name "Scattered Lapsus$ Hunters," leaked the proof-of-concept publicly. Oracle confirmed it matched the exploit used in the Clop attacks. ShinyHunters said the leak was deliberate, intended to disrupt Clop's campaign and expose what had been taken from them.

What followed, according to ShinyHunters, was a direct threat from a Clop representative. "During the Oracle EBS campaign they ran and stole from me last year, someone from cl0p personally messaged me and said, and I quote (translated from Russian): I have more money than you and all of your people combined, I'll kill you soon," the group said. Those allegations have not been independently verified.

This is not the first time criminal groups have turned on each other. In March 2025, DragonForce defaced the leak sites of rival operations BlackLock and Mamona. Later in 2026, two groups called 0APT and KryBit hacked and leaked each other's operational data until both were left severely damaged. The difference in the Clop case is the scale of the target. Clop's leak site is the operational center of its entire extortion model, the platform it uses to name victims and apply public pressure when ransoms go unpaid. Losing control of it, and potentially the keys that anchor its onion address, is not a minor disruption.

ShinyHunters' own Tor site went offline shortly after the attack. No connection to Clop has been established.

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host


In OpenAI Codex, security researchers have identified two sandbox escape vulnerabilities, one of which allows developers to execute commands on their machine without prompting them. The vulnerabilities, Heapjack and Overpatch, affect different parts of the coding agent's security boundary. 

The vulnerability was reported to OpenAI by Accomplish AI on August 12. According to the researcher, Codex fixed both issues within eight days. The more serious Heapjack vulnerability demonstrated that malicious code could move beyond the restrictions imposed by Codex's sandbox, even when the agent was running as a read-only application. 

Heapjack Breaks the Sandbox Boundary

The node_repl component installed with Codex Desktop is targeted by heapjack. Although both OpenAI and untrusted agent code are run in separate JavaScript contexts, both operate within the same Node.js process and share the same memory heap, the separation was not sufficiently effective in preventing a security token from coming into contact with an untrusted environment. 

By inspecting the process heap, it was possible to obtain the token generated for the trusted context that remained in shared memory. When the token was obtained, the untrusted code could interact with a native parent process outside the sandbox using the communication channel used by the trusted context. As part of the demonstration of the technique, the researchers launched an application outside of Codex's process tree by utilizing the open command. 

A Unix socket as well as other system-level interfaces could also be reached through this access. This demonstration was especially important since it occurred while Codex was running in a strict read-only sandbox mode, where the agent was not expected to have any writing access to the wider system. 

The attack could be triggered by a seemingly routine development process. The researchers demonstrated a scenario in which malicious content contained in a repository, created by a third party, could exploit the vulnerability after the repository was opened in Codex and a query about its code was made. 

Overpatch Expands Write Access

Second, a vulnerability known as Overpatch affects the open-source Codex command line utility, and it takes an alternative route outside the sandbox. The vulnerability affects the application_patch tool used by Codex to modify files. 

In workspace-write mode, Codex is intended to limit file changes to the project directory. Researchers discovered that apply_patch, instead of expanding write permissions, could expand them based on paths included in patches. By using a path such as /tmp, the tool was able to treat the root of the file system as an accessible parent directory. In addition to the permission extension, researchers modified .zshrc by creating a symbolic link to the user's home directory so that it would be modified as well.

A successful write was not required for the /tmp entry; its presence extended the permissions granted to the patch operation. A modified shell configuration resulted in a file modification outside of the permitted workspace without an approval prompt. When a new terminal session was launched, attacker-controlled content ran. 

Two Flaws, One Security Boundary Problem

It is important to note that though Heapjack and Overpatch affect different parts of the Codex, both expose weaknesses in the way in which the security boundary of the agent was enforced. In the case of Overpatch, the tool responsible for applying changes also determined the scope from which it had access to data. 

In heapjack, trust boundaries were similarly compromised, as the token separating trusted and untrusted execution remained accessible in the same Node.js process and memory space as the untrusted code. The findings suggest that AI coding agents can be restricted in other ways than just controlling their abilities to execute commands. 

Untrusted agent activity must also be prevented from influencing the mechanisms that enforce those restrictions by the tools, processes and interfaces surrounding the model. On August 12, 2026, OpenAI was notified of the issues, and they were both addressed within eight days by Accomplish, who stated that Overpatch was addressed in Codex CLI 0.149.0, while Heapjack had been addressed in Codex Desktop build 26.818.21641.

A later statement by OpenAI confirmed that both issues had been resolved in August, and that additional measures were being taken to strengthen file-write controls and expand sandbox testing across platforms. These findings emphasize the security challenges associated with maintaining strong isolation in AI coding environments. Codex Desktop and Codex CLI have been updated to address both vulnerabilities.

Four Linux Kernel Flaws Expose Systems to Local Root Exploits

 

A security researcher has publicly released working exploit code for four Linux kernel vulnerabilities that can allow local users to escalate their privileges to root, giving them the highest level of access on an affected system. The vulnerabilities, dubbed DirtyAH6, TUNderflow, PPPoEject and DiagSpill, were discovered by researcher Asim Manizada and reported to the Linux kernel security team in mid-July. 

Kernel maintainers have since released fixes for all four flaws, meaning systems running fully updated kernels are not affected. Manizada published his technical analysis and working exploits on September 18 after coordinating with Linux distributions to give developers time to release patches. There are currently no reports of the vulnerabilities being exploited in real-world attacks. The published exploits were developed for specific kernel builds and can crash systems, making them primarily suited for isolated testing environments. 

Despite those limitations, publicly available exploit code increases the risk for systems that have not been patched. Local privilege escalation vulnerabilities are particularly relevant on shared or multi-user systems, where an attacker who has already obtained limited access can potentially use the flaws to gain complete control. Three of the vulnerabilities require unprivileged user namespaces to be enabled. 

This Linux feature allows ordinary users to obtain root-like privileges inside an isolated environment and is enabled by default on many distributions. DirtyAH6, tracked as CVE-2026-80844, affects the IPv6 IPsec Authentication Header code. TUNderflow, CVE-2026-81000, affects TUN/TAP virtual network devices, while PPPoEject, CVE-2026-68121, targets PPP over Ethernet code. DiagSpill, tracked as CVE-2026-74469, differs from the other three because it does not require user namespaces or special privileges. 

Instead, it requires the SCTP networking module to be available. Two vulnerabilities, DirtyAH6 and DiagSpill, can also be triggered remotely in limited circumstances, although the demonstrated remote impact is primarily system crashes. Manizada achieved remote root exploitation with DirtyAH6 in a controlled laboratory environment after first manipulating the target’s memory. He described achieving the same result remotely without that preparation as extremely difficult. He found no path to remote root with DiagSpill.

All four vulnerabilities are memory-safety flaws affecting different areas of Linux networking code. DirtyAH6 involves an out-of-bounds write in IPv6 IPsec handling, TUNderflow results from an integer wraparound in virtual networking code, PPPoEject is a use-after-free vulnerability, and DiagSpill involves a counter overflow that can result in a large out-of-bounds memory write. The researcher said the flaws were discovered using an AI-assisted process designed to map kernel memory handling and reason about memory layouts. 

The Linux fix for DirtyAH6 credits his custom AI tooling in its commit record. Manizada also previously disclosed another Linux kernel privilege-escalation flaw, OVSwrap, in July. Administrators should update to a kernel containing all four fixes. The first stable Linux kernel releases containing the complete set are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Distribution kernels use their own versioning, however, so users should check security advisories from their Linux distributor to confirm the fixes have been included. 

If immediate patching is not possible, disabling unprivileged user namespaces can reduce exposure to DirtyAH6, TUNderflow and PPPoEject. Administrators can also disable AH6, TUN/TAP, PPPoE or SCTP features when they are not required. Manizada recommends patching rather than relying on feature restrictions because alternative exploitation paths may exist.

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution

 

A critical vulnerability in Orkes Conductor is being actively exploited by attackers, potentially allowing them to execute arbitrary commands on vulnerable systems without authentication. Tracked as CVE-2026-58138 and rated 9.8 on the CVSS scale, the flaw affects Conductor, an open-source enterprise framework used to orchestrate microservices, workflows and AI agents. The vulnerability can be exploited through inline workflow definitions submitted to the platform’s workflow API. The security issue stems from the way Conductor executes scripts within workflows. 

Attackers can insert malicious JavaScript or Python expressions into workflow definitions and use them to execute arbitrary system commands. According to Empirical Security, INLINE tasks, along with LAMBDA, DO_WHILE and SWITCH tasks, can evaluate user-controlled JavaScript or Python expressions. Conductor creates the evaluator using a GraalVM context configured with HostAccess.ALL, effectively removing the intended sandbox protections. The attacker-controlled code can then reach the underlying Java runtime and execute operating system commands with the privileges of the Conductor process. 

In many deployments, that process runs with root privileges, potentially giving attackers extensive control over the affected system. Authentication does not prevent exploitation by default because the open-source Conductor server does not enforce authentication and leaves its workflow API accessible. An attacker can reportedly send a single unauthenticated POST request to register a malicious workflow containing an INLINE task and trigger its execution. Orkes patched CVE-2026-58138 in June with Conductor version 3.30.2. 

However, attackers began targeting the vulnerability after proof-of-concept exploit code was publicly released in early August. Empirical Security identified exploitation attempts in the wild on August 21. Fortinet subsequently blocked approximately 1,300 exploitation attempts between September 8 and September 9 and has issued an outbreak alert warning about continued exploitation. Organizations running Conductor should upgrade to version 3.30.2 or later and limit external access to the platform’s workflow API endpoints. 

Security teams should also place Conductor deployments behind firewalls and ensure vulnerable services are not directly exposed to the public internet. Administrators should monitor Conductor instances for suspicious workflow submissions and unexpected command execution. Systems that previously ran vulnerable versions should also be reviewed for signs of unauthorized access or compromise.

An AI Helped Researchers Break Into OpenAI

 



A three-person security research team quietly walked into OpenAI's internal infrastructure last July, submitted a pull request inside the company's private monorepo as proof, and then stopped. The whole operation, from first vulnerability discovery to confirmed repository access, took under 72 hours. The tool that made it possible was not a custom-built hacking suite. It was Claude Opus 5.

The researchers, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, work at Hacktron, an AI-assisted security research firm. They published their full technical account on September 13. OpenAI confirmed a fix roughly 14 hours after receiving the initial report on July 25, and paid out a $6,500 bounty on September 1.

The case is one of the clearest demonstrations yet of what skilled human researchers can accomplish when they hand the grinding, iterative work of exploit development to a capable AI model. It is also a story about a mundane but persistent failure: software that depends on unpatched libraries, and login systems that trust services they probably should not.


The Chain That Got Them In

The attack surface was not OpenAI's flagship products. It was the company's public help forum, community.openai.com, which runs on Discourse, an open-source forum platform used by tens of thousands of organizations.

Discourse allows users to upload images. For most formats, it relies on a tool called FastImage to inspect files before processing them. But FastImage does not support HEIC or HEIF images, the high-efficiency formats popularized by Apple. So Discourse passes those files to ImageMagick instead, which in turn calls an underlying library called libheif to do the actual decoding.

That handoff is where the vulnerability lived. libheif version 1.19.7, the version running inside Discourse's Docker image at the time, contained a heap buffer overflow. A specially crafted HEIC file could corrupt server memory, giving an attacker the ability to manipulate program execution. The flaw is tracked as CVE-2026-32882 and carries a severity score of 8.8 out of 10 in Discourse's own advisory, which classifies the result as remote code execution.

The patch for this bug had been available since libheif 1.22.0, released in May 2026. The CVE existed. The fix existed. But Discourse's Docker image, built on Debian 12, still shipped the old, vulnerable library when the Hacktron team looked in July. Debian had not yet backported the fix into its packaged version. That two-month window between upstream patch and downstream delivery is what the researchers walked through.

Once they had code execution on the Discourse server, the path to OpenAI employee accounts ran straight through the forum's login button. OpenAI's forum offers a "Sign in with OpenAI" option, the same single sign-on system its staff uses for ChatGPT, Codex, and other internal services. With control of the forum server, the researchers could hijack that authentication flow and take over the accounts of any OpenAI employee who had ever used it. The victims did not have to click anything or be online at the time.

Hacktron was explicit in their writeup about what this means: the forum was one path, not the problem. "If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to the same access," the team wrote. The identity flaw was OpenAI's, not Discourse's.

After confirming the account takeovers, the researchers used one employee's Codex account, which was connected to OpenAI's GitHub organization, to open a single pull request inside OpenAI's internal monorepo. They read nothing, merged nothing, and touched no customer data. The pull request was the proof. Then they stopped and filed their report.


Where the AI Came In

The libheif heap overflow gave the researchers memory corruption primitives, which is a starting point, not a working exploit. Memory corruption bugs require additional work to become reliable code execution, particularly on modern systems protected by Address Space Layout Randomization (ASLR), a defense that scrambles where code sits in memory to make it harder to redirect program flow.

This is where most vulnerability research slows down. Turning a crash into a reliable, weaponized exploit requires significant expertise, patience, and time. The Hacktron team decided to find out how much of that work an AI could absorb.

They started with Claude Opus 4.8, the previous flagship model from Anthropic. Across multiple sessions, it managed to help develop a working exploit when ASLR was disabled. When they enabled ASLR, matching the configuration of real servers, Opus 4.8 struggled and failed to produce anything reliable.

On the evening of July 24, Anthropic released Claude Opus 5. The researchers started a fresh session.

Within three hours, Opus 5 had produced a working exploit for an ARM64 Mac environment. They asked it to adapt the exploit to x86-64 and to the jemalloc memory allocator configuration that Discourse uses. By 6:00 a.m. on July 25, they had confirmed local code execution through an image upload.

The researchers then placed Claude in what they describe as an autonomous "/goal" loop, pointed at their own Discourse Cloud instance, framed as a capture-the-flag practice target. Opus 5 has guardrails meant to prevent it from writing exploits for real systems, so the team disguised the target. When they checked again at 10:00 a.m., the agent had achieved code execution on their cloud instance on its own, demonstrating access by reading /etc/hosts. They then used the generated exploit on OpenAI's forum and confirmed it worked there too.

The researchers are careful to note that this was not fully autonomous hacking. Skilled human judgment and direction were required throughout. But the gap between what they could accomplish in hours with Opus 5 versus the days or weeks such work might have taken without it was significant.

The cost of the entire Discourse and OpenAI portion of the project: a few days of AI compute and a few hours of human time.


One Bug, Many Targets

The OpenAI breach was not a standalone operation. It was one piece of a broader research campaign Hacktron calls HEIF Heist, a multi-month investigation into how widely the libheif library is embedded in major internet services, and how many of those services were running vulnerable versions.

Over roughly two months, the three researchers say they traced the same class of image-decoding flaws across software used by Slack, Meta, GitHub Enterprise, and web frameworks including Next.js, Astro, and Gatsby. The total cost of the entire campaign was under $3,000 in AI model usage, spread across roughly sixty days of work.

The team found that adapting each exploit to a new target environment generally took only one or two days with AI assistance. They report that the only company that appeared to detect their testing activity was Shopify, even after thousands of test images were sent to various targets and image processors at several of those companies crashed repeatedly under the load.

Not all of the claims have been independently verified. The Next.js vulnerability is confirmed in Vercel's own advisory. libheif's maintainers confirmed a working code-execution exploit against Meta's deployment of the library. The wider claim of successful code execution across the full list of targets has not been corroborated by external sources as of publication.

The HEIF Heist project also surfaced a difference between AI models. For cases where the team had information about the target environment, Claude Opus 5 was the primary tool. For targets where they had almost no prior knowledge of the deployment configuration, they switched to OpenAI's GPT-5.6 Sol, which they found performed better in those conditions. Each major model jump brought a clear capability improvement: Opus 5 succeeded where Opus 4.8 failed, and GPT-5.6 Sol handled blind exploitation scenarios that Opus 5 struggled with.

The report documented Russia-linked espionage operations using Claude to run nearly fully automated phishing campaigns against Ukrainian, European, and diplomatic targets. It described a Chinese group, including operators identified as university students in Hunan province, who used Claude as the core engineering layer of an offensive program that found multiple zero-day vulnerabilities in a major security product. It also described a French-speaking hacktivist who used Claude to attack European political parties, media organizations, and think tanks at a scale that previously would have required a well-resourced team.

Anthropic's core observation across all of those cases was the same observation the Hacktron team made in their own writeup: AI is closing the gap between what a small, budget-constrained team can do and what used to require state-level resources.

The Hacktron team put it plainly: "Work that once required a well-resourced team and months of effort can now be compressed into days."

That assessment lines up with what Anthropic itself told the company's own threat report readers, and with what security researchers have been warning about for the past year. The Hacktron operation is the first time those warnings have been backed by a public, step-by-step technical demonstration against one of the most scrutinized technology companies on the planet.


What Needs to Change

The specifics of the OpenAI fix have not been made public. The company acknowledged the finding through payment and remediation rather than through a detailed disclosure of the login flaw.

On the Discourse side, the forum platform responded fast: they received the report on a Saturday, replied on Sunday, had a fix ready on Monday, and published their advisory on Tuesday. They also added image-processing sandboxing as a hardening measure, running ImageMagick in a restricted environment so that even a successful exploit against the image library cannot directly execute arbitrary code on the host server.



Unauthenticated RCE Bug Fixed in SolarWinds Access Rights Manager

 

SolarWinds has issued an urgent security advisory for a high-severity vulnerability in its Access Rights Manager (ARM) product, tracked as CVE-2026-28326. The flaw enables unauthenticated attackers to execute arbitrary code remotely on affected systems, posing a serious risk to organizations using the identity and access governance platform. 

The vulnerability arises from a hardcoded static key embedded in SolarWinds Access Rights Manager 2026.2 and all earlier releases. Because the key is static and known, an attacker within adjacent network access can exploit it to bypass authentication entirely and run malicious code with high privileges. SolarWinds rates the issue 8.8 (High) under CVSS v3.1, reflecting severe impacts on confidentiality, integrity, and availability. 

Patch availability and upgrade path 

SolarWinds has released a fixed version, Access Rights Manager 2026.2.1, which removes the hardcoded key and mitigates the remote code execution risk. Customers are advised to upgrade immediately to 2026.2.1 or later. The advisory, first published on September 17, 2026, includes a downloadable PDF with technical details and recommends that administrators verify their current version and schedule emergency patching where ARM is deployed. 

Given the “unauthenticated” and “remote code execution” characteristics, this bug is especially dangerous in environments where ARM is exposed to internal networks or poorly segmented zones. An attacker who gains adjacent network access—such as via a compromised workstation or rogue device—could leverage the static key to take control of the ARM server, potentially escalating to broader identity management systems. The CVSS vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates low attack complexity and no need for user interaction, amplifying the urgency for remediation. 

Safety tips 

Organizations using SolarWinds Access Rights Manager should treat CVE-2026-28326 as a priority patching target. Immediate steps include: confirming the installed ARM version; isolating ARM servers from untrusted network segments; applying the 2026.2.1 update; and monitoring logs for suspicious authentication bypass attempts. Security teams should also review network access controls and consider threat-hunting activities focused on ARM-related processes. As with any identity management platform compromise, the downstream risk to Active Directory and other directories is significant, making rapid mitigation essential.

Gyazo Server Vulnerability Targeted to Steal Millions of User Records


Gyazo, an image-sharing platform, has confirmed a breach after attackers exploited a vulnerability in its upload server, gaining unauthorized access to the company's systems and approximately 23.62 million user records. 

Gyazo was developed by Japanese software company Helpfeel and allows users to upload images, GIFs, short videos and generate links for sharing. There are over 23 million users on the platform from 242 countries and regions, and billions of uploads have been processed. According to Helpfeel, the intrusion occurred on September 11, when a third party exploited a vulnerability in Gyazo's image upload server and became able to execute commands on the system as a result. 

On the same day, the company was notified of suspicious activity and began to investigate the incident. In the early hours of September 12, Helpfeel had blocked the access routes used for the attack and terminated any unauthorized connections. As part of the initial response, the exploited vulnerability was also fixed. However, an investigation revealed that the attacker was already able to access Gyazo's database and obtain user-related information. There are approximately 23.62 million records in the affected dataset. 

Depending on the account, information that will be exposed may include name or nickname, email address, password hashes, user and device IDs, login session IDs, profile information, subscription details, billing status and usage statistics. Additional information may be exposed if an account is linked to an external service. 

According to Helpfeel, integration tokens for accounts connected to X may be included, while Google SSO email addresses may also be included for users who signed in through Google. In a statement issued by the company, it clarified that payment information, including credit card numbers, was not exposed. 

The affected records also include anonymous accounts without registered email addresses, therefore it is not yet known how many people will be affected. The incident involved not only account information, but also a much larger collection of image-related metadata. According to Helpfeel, approximately 490 million metadata records were disclosed, primarily those associated with images uploaded before January 2019. It is possible for an image ID to be exposed, as well as IP addresses and User Agent details, EXIF location information, OCR-extracted text, image titles, and source URLs. 

A separate privacy concern arises from the image metadata, as Gyazo uses image IDs to generate URLs for uploaded captures. According to Helpfeel, the stolen IDs may allow access to some images, so the company temporarily disabled access to affected files while investigating. As a result, approximately 490 million images have been compromised, most of which were uploaded in January 2019 or earlier. 

Information may include image IDs, IP addresses, User-Agent strings, EXIF location information, OCR-extracted text, title of the image, and URL of the source. Besides the data exposed, Helpfeel also identified a separate set of approximately 2.4 million image records which were retrieved according to specific filtering criteria, including hacked passphrases associated with private images. This company has not provided information on the criteria used or clarified whether the records overlap with the larger metadata set. Also exposed in the incident was a list of private images. 

Helpfeel did not exclude the possibility that private pictures were viewed by the attacker. The number of private images accessed has not been determined by the company. Because Gyazo handles image privacy in a very sensitive manner, the disclosure of image IDs is particularly significant. The URL of each capture includes a 32-character ID, and older captures can still be accessed through their original URLs even after they are not prominently displayed within a user's account. 

The leaked identifiers therefore could be used to gain access to content that was not intended to be viewed by the general public. By the early hours of September 12, Helpfeel detected suspicious activity and blocked the identified access routes, terminating the attacker's connections. The exploited server vulnerability was immediately addressed. 

In September 14, the company confirmed the data exposure and reported the incident to the Japanese Personal Information Protection Commission. During the course of the investigation, Gyazo temporarily suspended image delivery. A forensic investigation is currently underway by Helpfeel, and affected users will be contacted directly. 

Anonymous accounts will be handled by Gyazo through notifications posted on the website. Despite finding no evidence of the deletion of image data during the incident, the company has not identified a data leak involving its separate Helpfeel and Cosense services. Users have been advised to change their Gyazo passwords and avoid reusing the same credentials on other services in light of the exposed authentication data. 

Helpfeel has also taken action to invalidate or restrict the affected credentials and authentication information. Furthermore, the company has cautioned against the possibility of exploitation of information disclosed in the breach through suspicious emails and messages.

Plugin4Shell: The Zero-Click Flaw That Broke Every Prominent AI Coding Agent at Once



The security promise was simple. A plugin marketplace reviews a piece of code, locks it to a specific, verified version, and every AI coding agent that installs it gets exactly what was reviewed. No surprises or swaps. That promise just got broken, simultaneously, across every major AI coding agent on the market.

On September 17, cybersecurity startup AIR Security publicly disclosed Plugin4Shell, a zero-click, high-severity remote code execution vulnerability affecting Anthropic's Claude Code, OpenAI's Codex, Microsoft's GitHub Copilot, and Google's Gemini CLI. The name is a deliberate echo of Log4Shell, the 2021 Apache flaw that shook enterprise security teams for months. This one hits a faster-moving target: the plugin ecosystems that have quietly become critical infrastructure for millions of software developers.

The researchers who found it, Or Nevo, Dor Granat, and Niv Hoffman, describe it as the first supply-chain vulnerability of the AI agent ecosystem. That is not a small claim, and the technical details back it up.


How the Attack Works

To understand Plugin4Shell, you need to understand SHA pinning, the mechanism it breaks. When a marketplace approves a plugin, it records a cryptographic commit hash, a 40-character string that uniquely identifies an exact snapshot of the plugin's code. From that point forward, every agent that installs the plugin is supposed to check out precisely that commit. Reviewed code, nothing else, forever.

The vulnerability is a single missing verification step. Affected agents fetch the pinned commit during installation but never confirm that the code they actually land on matches it. That gap opens the door to a Git reference resolution trick.

For Claude Code, Codex, and GitHub Copilot, an attacker who controls a plugin repository can create a branch whose name is the exact 40-character pinned commit hash, set it as the repository's default branch, and point it at malicious code. When the agent runs its checkout, Git resolves the branch name instead of the commit object, because Git prefers a matching reference when the name is ambiguous. The agent installs attacker-controlled code, reports a clean install at the trusted hash, and nothing looks wrong.

Gemini CLI has a slightly different variant. Its installer fetches the target commit and then checks out FETCH_HEAD, but if the repository's default branch is itself named FETCH_HEAD, that checkout resolves to the branch instead. The fetched commit gets silently discarded.

What makes this zero-click is auto-update. Claude Code and Codex update installed plugins in the background by default. When a plugin's pinned commit is swapped upstream, an already-installed, already-trusted plugin gets silently replaced with a malicious version. No prompt. No reinstall. Nothing for the user to notice or decline.

Plugins run with the permissions of the developer operating the agent. That means an attacker who succeeds here lands in the developer's machine with access to source code, cloud credentials, SSH keys, internal repositories, and production systems.


The Context Makes It Worse

Plugin4Shell is the third installment in a series of findings from AIR Security, each one showing a different layer of the AI plugin ecosystem collapsing under scrutiny.

In earlier research called "The Story of Skills," the team published a malicious skill to a trusted marketplace and watched it spread to over 26,000 agents. In SkillJacking, they found 925 skills already in active use had been quietly hijacked from their original maintainers, affecting 134,000 agents, by taking over the repositories behind them.

The industry's answer to SkillJacking was SHA pinning. Plugin4Shell is the answer to that answer. The takeovers AIR demonstrated in SkillJacking can now be combined with Plugin4Shell to bypass the exact safeguard that was supposed to contain them. The chain is proven end to end.


Vendor Responses

AIR found the vulnerability in May 2026, built working proof-of-concept exploits against all four agents, and disclosed everything to the vendors in June. What happened next drew a clear line between the companies that acted and the ones that did not.

Anthropic patched Claude Code in version 2.1.179. OpenAI patched Codex in version 0.146.0. Both confirmed fixes after disclosure.

Microsoft has not shipped a fix for GitHub Copilot. GitHub has argued that its platform blocks branch and tag names that resemble commit hashes, which limits the attack surface for GitHub-hosted plugins. AIR's counter is that Copilot also supports marketplaces hosted on Bitbucket and self-hosted git servers, which permit such names, and that GitHub's restriction does nothing for those configurations. The two positions describe different scopes. Copilot users currently have no patch.

Google's response was to deprecate Gemini CLI entirely. The company confirmed in August that no fix would ship, directing users to migrate to an alternative product called Antigravity. Every existing Gemini CLI installation remains permanently vulnerable.


What Users Should Do Now

The fix, technically, is a single line of verification that every affected agent was missing: after checkout, compare the actual HEAD commit against the pinned hash and abort if they do not match. Because the check runs inside the agent rather than at the marketplace, no marketplace can enforce this guarantee on its own. Only an agent-side fix closes it.

Claude Code users should update to version 2.1.179 or later. Codex users should update to version 0.146.0 or later. Gemini CLI users should migrate away from the product. GitHub Copilot users have no patch available and no confirmed timeline for one.

For enterprise teams that have built internal vetting processes around SHA pinning, Plugin4Shell is a harder problem. The review passed. The pin was written. Different code got installed. Every downstream security process built on that guarantee inherits the failure.

The most striking detail in AIR's disclosure is not the vulnerability itself. It is that four independent engineering teams at four separate companies all made the same mistake, building the same flawed assumption into their auto-update pipelines, and none of them caught it until an outside lab did. That is not an implementation error in one product. That is a design assumption the entire industry shared, and nobody questioned it.

Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0

 

Microsoft has patched a maximum-severity vulnerability in Azure AI Foundry that could allow unauthorized attackers to escalate their privileges over a network. Tracked as CVE-2026-85889, the flaw carries a CVSS score of 10.0, making it one of the most serious security issues affecting Microsoft’s cloud-based artificial intelligence services. The company said the vulnerability resulted from missing authentication for a critical function within Azure AI Foundry. There is currently no evidence that the flaw has been exploited in real-world attacks. 

Azure AI Foundry, also known as Microsoft Foundry, is an enterprise platform used to build, deploy and manage generative AI applications and autonomous agents. A successful exploit could have enabled an unauthorized attacker to gain elevated privileges, potentially increasing access to sensitive resources or administrative functions. Security researcher Rémy Marot, who uses the handle @R_Marot, discovered and reported the vulnerability to Microsoft. The company has already addressed the issue across its cloud infrastructure. 

Microsoft said customers do not need to take any action because the affected cloud services have been fully mitigated. Alongside CVE-2026-85889, the company also fixed several other critical cloud vulnerabilities. These include CVE-2026-85885, a command injection flaw in Microsoft 365 Copilot rated 9.9; CVE-2026-85878, an improper authorization issue in Azure Database for PostgreSQL rated 9.9; and CVE-2026-87701, an improper neutralization vulnerability in Azure Cosmos DB rated 9.6. 

The tech giant separately released updates for two Windows vulnerabilities. CVE-2026-62721 affects the Windows User-Mode Power Service and could allow an authorized local attacker to gain SYSTEM privileges. CVE-2026-85921 is a double-free vulnerability in Windows Secure Kernel Mode that could enable privilege escalation to Virtual Trust Level 1. Both vulnerabilities were fixed through an out-of-band update for Windows 11 version 26H1, distributed as cumulative update KB5129194 for arm64 and x64 systems. 

The latest fixes arrive shortly after Microsoft patched 974 vulnerabilities across its software portfolio. Two of those flaws, affecting Windows Advanced Local Procedure Call and the Windows Update Stack, were reportedly exploited in active attacks. Proofpoint and Volexity said the ALPC flaw was chained with two Google Chrome vulnerabilities to create the BlueMoon exploit kit, which multiple espionage-linked threat actors allegedly used to deliver malicious payloads. The developments highlight the growing security risks surrounding cloud platforms, enterprise AI tools and widely deployed operating systems.

WeaselBiscuit Stealer Found in 13 Malicious npm Packages


Researchers have discovered 13 npm packages carrying a previously undocumented JavaScript information stealer called WeaselBiscuit, introducing yet another malicious threat to the npm package ecosystem. In addition to linking the packages together via shared indicators, OpenSourceMalware found several similarities between BeaverTail and OtterCookie, two North Korean malware families. 


A number of packages are included, including @biz44/id10-client, @biz44/id12-client, @biz44/id44-client, @biz44/id79-client, @biz44/id95-client, @biz44/id99-client, @biz44/process-runtime-utils, @biz44/runtime-utils, @biz44/engin1, id79-client, process-lhpm, process-mite, and process-tailwind. Many were first observed between September 12 and September 16, 2026, with some versions still available on NPM at the time of analysis. 

In comparison to BeaverTail and OtterCookie, WeaselBiscuit appears much smaller. In addition to remote access and cryptocurrency theft functions, the malware focuses on profiling hosts and collecting data collected by Chrome extensions rather than carrying a broad range of remote access functions. Malware loaders are launched when a compromised package is imported, causing detached Node.js processes to begin execution.

After retrieving an encoded payload from an Npoint URL, the loader executes the decoded code directly in memory. Following execution, the malware obtains its command-and-control configuration from another Npoint endpoint before connecting to 103.170.217.184:8787. Among the data collected are hostnames, usernames, operating systems, CPUs, and memory, as well as local and public IP addresses. 

Chrome profiles are also searched for extension storage on Windows, Mac OS, and Linux platforms. Chrome's Local Extension Settings directory may contain information associated with browser extensions, including cryptocurrency wallet extensions, which makes this collection especially significant. 

Instead of relying on a specific list of wallet extensions, OpenSourceMalware reported the stealer uploads readable, non-empty files from these locations. C2 servers can also provide commands for monitoring the clipboard and logging Windows keystrokes. 

Despite these capabilities, the recovered malware does not include direct wallet draining functionality, browser password decryption, seed phrase searching, screenshots, or a remote shell access. Additionally, some BeaverTail and OtterCookie activities have a Python-based InvisibleFerret stage that is not present in any other activity. 

Possible Links to DPRK Malware

WeaselBiscuit has been compared to malware associated with the DPRK-linked Contagious Interview campaign, but the attribution has yet to be confirmed. OpenSourceMalware did not find conclusive evidence that the attack was originated by North Korea based on operational infrastructure, victimology, campaign metadata or other identifying materials. 

WeaselBiscuit employs the dead-drop technique of Npoint.io as a dead-drop service, a technique previously observed in Contagious Interview campaigns. Some of its technical indicators, however, overlap with earlier campaigns. Additionally, its code performs public IP and geolocation checks using IPify.org and IP-API.com, while parts of its command-and-control design are similar to OtterCookie's. 

Among the numeric identifiers found in the malware are 10, 12, 44, 79, 95, and 99. These identifiers are similar to campaign markers associated with PolinRider activity, however their exact purpose in WeaselBiscuit is unclear. In terms of capability, BeaverTail and OtterCookie are more closely related. 

Several features are retained in WhistlerBiscuit, including system profiling, Chrome extension data collection, clipboard monitoring, and keylogging, all of which are common to those malware families. However, several of their heavier features are removed, including remote access functions, wallet draining capabilities, screenshots, and secondary payload delivery. 

Researchers at Cisco Talos observed a similar overlap in October 2025, when they discovered that the node-nvm-ssh package contained characteristics related to both BeaverTail and OtterCookie. The findings suggest that code and techniques from these malware families have been found in a variety of combinations within npm-based malicious code. 

The WeaselBiscuit stealer should be viewed for the time being as a distinctive lightweight stealer with distinct technical similarities to DPRK-related tooling rather than a new DPRK malware family confirmed by the DPRK. For a more conclusive attribution, further evidence from infrastructure, campaigns, or code levels would be required.

With the discovery of WeaselBiscuit, security risks are highlighted within the npm ecosystem, particularly for developers utilizing third-party packages. In addition to the ability to collect Chrome extension data and similarity to BeaverTail and OtterCookie, it warrants continued investigation as researchers investigate its origins and wider activities.

RatHat Android Malware Uses AI to Control Infected Devices

 

A new Android backdoor called RatHat utilizes an AI-powered system to remotely navigate compromised devices, while also stealing sensitive information and using a variety of methods to maintain its presence. Researchers at Zimperium’s zLabs found indications that RatHat may be associated with threat actors based in China after they discovered Chinese language prompts within the malware’s AI subsystem. 

The malware is reported to be distributed through malicious advertising, SMS messages and phishing websites that promote APK downloads outside Google Play. RatHat takes advantage of Android’s Accessibility permissions to obtain extensive control over infected devices. This allows it to enable Developer Options and Wireless Debugging, granting it a local shell-level execution environment without the need for a separate computer. Researchers observed similarities with this technique that have been previously seen in the ToxicPanda and RedHook Android malware families. 

The malware utilizes Android Debug Bridge (ADB) access to install a Go-based agent called liblocal-service.so. The agent can execute commands with ADB shell privileges, bypassing battery restrictions and establishing persistence. It can also restore the malware in the case that the main component is removed or stopped. The relationship works in both directions, with the malware being able to restore the agent if the agent itself is deleted. 

RatHat also makes use of a second component, libmedia_codec.so, which acts as an FRP reverse-proxy client and establishes a persistent tunnel to the attackers. The malware has the ability to display HTML overlays over targeted banking and cryptocurrency applications in order to acquire the users’ credentials. Its information-stealing capabilities include SMS messages and notifications, including one-time passwords. RatHat can also monitor text changes, extract URLs from browser address bars and capture lock-screen PINs, passwords and unlock patterns. 

One of RatHat’s most interesting features is its AI-powered interface automation engine. According to Zimperium, the malware converts the Android Accessibility tree into XML and sends the resulting information to an unnamed popular AI assistant. This system can recognize the screen coordinates of requested interface elements and determine their displayed text and provide navigation commands such as scrolling instructions. This enables the malware to navigate Android interfaces more dynamically than other malware that exclusively rely on predetermined scripts. 

Zimperium stated that the AI-driven system makes the malware more adaptable and arguably harder for security software to detect. RatHat actively prevents victims from uninstalling the malware. When an uninstall confirmation screen appears, the malware can intercept the process and cancel the removal and display a fake Google Play overlay, which shows a fraudulent error message. The malware also contains a number of anti-analysis measures, including APK container manipulation, an unusually large 61MB Android manifest and invalid DEX pseudo-instructions that are designed to confuse or disrupt the functionality of security analysis tools. 

Android users are advised to avoid downloading APK files from outside Google Play unless the publisher is explicitly trusted and to be careful when granting Accessibility permissions to applications. In addition, users should regularly scan their devices using Google Play Protect.

Docker Fixes Critical Sandboxes Flaw That Could Expose Host Files

 




Docker has patched two vulnerabilities in Docker Sandboxes that could allow malicious code running inside an isolated sandbox to cross its intended workspace boundary and interact with resources on the host system.

The more severe issue, tracked as CVE-2026-77179, affects Docker Sandboxes versions 0.28.0 through versions before 0.42.0 on macOS and is rated Critical. Docker fixed the vulnerability in Sandboxes 0.42.0, released September 7. The company disclosed the security issues publicly on September 15.

Docker Sandboxes are designed to give AI coding agents their own microVM environment where they can execute code, install packages and use development tools without directly accessing the host. The security architecture treats the microVM as the primary trust boundary, with the agent receiving full control, including "sudo", inside that environment. Resources such as a developer's project directory are selectively exposed across the boundary.

The problem in CVE-2026-77179 occurs in the virtio-fs host server, which handles filesystem sharing between the macOS host and the sandbox. Docker said the component could follow a symbolic link when reopening an unlinked file through a previously stored pathname.

A malicious process inside the VM could exploit this behavior by changing a parent directory into a symbolic link after the original path had been accepted. When the host subsequently reused the stored path, the operation could be redirected to a different location outside the authorized workspace.

This creates a path traversal condition across the VM boundary. Docker said an attacker could consequently read or modify arbitrary host files available to the account running the virtual machine monitor. Depending on what files can be changed, the access could potentially be turned into host-side code execution.

The requirement for malicious code to already be executing inside the sandbox does not eliminate the security concern. Docker Sandboxes are intended to contain precisely the type of untrusted code that an autonomous coding agent might encounter through a compromised repository, malicious dependency, poisoned package or manipulated instruction. If that code can alter host-visible filesystem paths, the microVM's isolation boundary becomes vulnerable at the point where the host performs the subsequent filesystem operation.

The second vulnerability, CVE-2026-79994, affects versions 0.37.0 through versions before 0.42.0. Docker rates it High with a CVSS 4.0 score of 8.7.

This issue affects the guest-to-host relay used for Unix domain sockets. The relay initially verified that a requested socket was located inside an authorized workspace, but later established the connection by using the pathname again. A malicious guest could change an intermediate directory into a symlink during that interval, causing the host to connect to an AF_UNIX socket outside the permitted workspace.

The vulnerability is classified as a time-of-check to time-of-use (TOCTOU) race condition, because the security decision is made against a pathname whose meaning can change before the privileged operation occurs. The resulting connection could expose data or host-side capabilities provided by the targeted socket.

Together, the two flaws expose different host interfaces through a similar underlying weakness: trusting a pathname after an attacker-controlled environment has had an opportunity to alter what that pathname resolves to.

The risk is amplified by how Sandboxes share development workspaces. Docker says "sbx run" normally mounts the current directory into the sandbox with read-write access, meaning an agent can directly modify the developer's working tree. Docker also warns that files such as Git hooks, CI configuration, IDE task definitions and project scripts can affect subsequent host-side development activity.

For users unable to update immediately, Docker recommends clone mode and advises against additional read-write host mounts. Clone mode mounts the repository read-only at "/run/sandbox/source" while the agent works from a private clone inside the VM. However, it is not a confidentiality boundary: files available in the mounted repository, including untracked files such as ".env", may still be readable by the agent.

Docker has reported no exploitation of either vulnerability. Neither issue was listed in CISA's Known Exploited Vulnerabilities catalog at the time of disclosure.

The company credited Oren Yomtov of accomplish.ai with discovering CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994.

The fixes arrived amid wider security scrutiny of AI coding environments. Earlier research from Cyera Research Labs demonstrated how a prompt-injected coding agent operating inside a Docker-based environment could be used as part of an attack chain against the host through a separate Docker Engine vulnerability. The latest disclosures reinforce the importance of treating autonomous coding agents as potentially hostile workloads, even when they are placed inside purpose-built isolation mechanisms.

Users running affected Sandboxes versions should upgrade to 0.42.0 or later. Docker Sandboxes 0.43.0, released September 15, is the latest stable release as of September 18.