Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Docker. Show all posts
vulnerabilities and exploits
Apple MacOS Docker Malicious Code microVM vulnerabilities and exploits

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.

Read more »
malware
Aisuru botnet API Chaos Malware Cloud systems Docker malware

New Chaos Malware Variant Expands to Cloud Targets, Introduces Proxy Capability

 



A newly observed version of the Chaos malware is now targeting poorly secured cloud environments, indicating a defining shift in how this threat is being deployed and scaled.

According to analysis by Darktrace, the malware is increasingly exploiting misconfigured cloud systems, moving beyond its earlier focus on routers and edge devices. This change suggests that attackers are adapting to the growing reliance on cloud infrastructure, where configuration errors can expose critical services.

Chaos was first identified in September 2022 by Lumen Black Lotus Labs. At the time, it was described as a cross-platform threat capable of infecting both Windows and Linux machines. Its functionality included executing remote shell commands, deploying additional malicious modules, spreading across systems by brute-forcing SSH credentials, mining cryptocurrency, and launching distributed denial-of-service attacks using protocols such as HTTP, TLS, TCP, UDP, and WebSocket.

Researchers believe Chaos developed from an earlier DDoS-focused malware strain known as Kaiji, which specifically targeted exposed Docker instances. While the exact operators behind Chaos remain unidentified, the presence of Chinese-language elements in the code and the use of infrastructure linked to China suggest a possible connection to threat actors from that region.

Darktrace detected the latest variant within its honeypot network, specifically on a deliberately misconfigured Hadoop deployment that allowed remote code execution. The attack began with an HTTP request sent to the Hadoop service to initiate the creation of a new application.

That application contained a sequence of shell commands designed to download a Chaos binary from an attacker-controlled domain, identified as “pan.tenire[.]com.” The commands then modified the file’s permissions using “chmod 777,” allowing full access to all users, before executing the binary and deleting it from the system to reduce forensic evidence.

Notably, the same domain had previously been linked to a phishing operation conducted by the cybercrime group Silver Fox. That campaign, referred to as Operation Silk Lure by Seqrite Labs in October 2025, was used to distribute decoy documents and ValleyRAT malware, suggesting infrastructure reuse across campaigns.

The newly identified sample is a 64-bit ELF binary that has been reworked and updated. While it retains much of its original functionality, several features have been removed. In particular, capabilities for spreading via SSH and exploiting router vulnerabilities are no longer present.

In their place, the malware now incorporates a SOCKS proxy feature. This allows compromised systems to relay network traffic, effectively masking the origin of malicious activity and making detection and mitigation more difficult for defenders.

Darktrace also noted that components previously associated with Kaiji have been modified, indicating that the malware has likely been rewritten or significantly refactored rather than simply reused.

The addition of proxy functionality points to a broader monetization strategy. Beyond cryptocurrency mining and DDoS-for-hire operations, attackers may now leverage infected systems to provide anonymized traffic routing or other illicit services, reflecting increasing competition within cybercriminal ecosystems.

This shift aligns with a wider trend observed in other botnets, such as AISURU, where proxy services are becoming a central feature. As a result, the threat infrastructure is expanding beyond traditional service disruption to include more complex abuse scenarios.

Security experts emphasize that misconfigured cloud services, including platforms like Hadoop and Docker, remain a critical risk factor. Without proper access controls, attackers can exploit these systems to gain initial entry and deploy malware with minimal resistance.

The continued evolution of Chaos underlines how threat actors are persistently enhancing their tools to expand botnet capabilities. It also reinforces the need for continuous security monitoring, as changes in how APIs and services function may not always appear as direct vulnerabilities but can exponentially increase exposure.

Organizations are advised to regularly audit configurations, restrict unnecessary access, and monitor for unusual behavior to mitigate the risks posed by increasingly adaptive malware threats.

Read more »
worm
containers Cryptojacking Cybersecurity Dero Docker Golang Kaspersky Linux malware worm

New Self-Spreading Malware Hijacks Docker Servers to Secretly Mine Cryptocurrency

 

A newly uncovered malware campaign is exploiting unsecured Docker environments across the globe, silently enrolling them into a decentralized cryptojacking network that mines the privacy-focused cryptocurrency, Dero.

Cybersecurity firm Kaspersky reports that the attack initiates by targeting exposed Docker APIs on port 2375. Once compromised, the attacker deploys malicious containers and infects existing ones, using system resources to mine Dero and search for other vulnerable hosts — all without relying on a central command-and-control server.

For context, Docker is a platform that uses OS-level virtualization to run applications in lightweight units called containers.

The attackers utilize two implants developed in Golang: one dubbed “nginx,” mimicking the popular web server, and another called “cloud,” which is the actual mining software.

Once a system is breached, the “nginx” component continuously scans the internet for additional misconfigured Docker nodes, using tools like Masscan to identify targets and propagate infection through new containers.

“The entire campaign behaves like a zombie container outbreak,” researchers noted. “One infected node autonomously creates new zombies to mine Dero and spread further. No external control is needed — just more misconfigured Docker endpoints.”

To stay hidden, the malware encrypts crucial data like wallet addresses and Dero nodes, and disguises itself under file paths commonly used by legitimate system processes.

Kaspersky has linked the infrastructure — including the wallet and Dero node — to previous cryptojacking campaigns that targeted Kubernetes clusters in 2023 and 2024. This points to an evolved version of an existing threat rather than an entirely new operation.

What sets this campaign apart is its worm-like behavior and the lack of centralized coordination, making it especially difficult to detect and eliminate.

As of early May, more than 520 Docker APIs were found to be publicly exposed on port 2375 — each a potential victim of this growing malware network.
Read more »
Subscribe to: Posts (Atom)