Docker CopyEscape, MikroTik Root Flaw, Chrome 154 Fix, and AI Agents Leaking Screenshots

CopyEscape Turns Docker File Copies Into Host File Writes

CopyEscape is a race condition in the way Docker builds and unpacks archives when you copy files out of a container. It affects docker cp, and sbx cp in Docker Sandboxes.

What You Need to Know

A routine command to pull a file out of a container can let that container write files somewhere else on the host. The flaw is tracked as CVE-2026-17106. It doesn't give an attacker root by itself, but it lets them create or overwrite any file the Docker CLI process has permission to write. The systems most at risk are the ones that regularly pull logs, artifacts, or evidence out of containers they may not fully trust: developer workstations, CI jobs, and incident-response boxes.

How the Attack Works

CVE-2026-17106 sits in the container-to-host path of docker cp, and in sbx cp when copying out of a Docker Sandbox. The attacker needs control of the container or sandbox, then waits for a person or an automated job to copy something out. Nothing about the container runtime is broken here. The problem is entirely in how the copy is packaged and unpacked.

To build the tar archive, the daemon walks the running container's filesystem, and between two of its checks the container can swap a directory for a symbolic link. The archive ends up listing a symlink followed by a file that appears to live under it. During extraction, the vulnerable CLI validates a constructed path but creates the symlink using the archive's original target, so when it writes the next file, the operating system follows that link out of the destination the user chose.

On a developer machine, an attacker could use this to overwrite something like a shell startup file or a binary in the user's path and get code execution later. Imperva's Linux demonstration went further: a copy run with elevated privileges replaced /usr/bin/runc, and the next Docker operation ran the attacker's version as root. Only copying out of a container triggers this. Copying into one, or simply running one, does not.

Why This Matters

The riskiest workflows are the ones that treat copying out of a container as harmless and read-only. Forensic collection is the obvious case, since pulling evidence from a container you already suspect is compromised is exactly what the attacker is waiting for. CI runners and scripts that run copy commands as root raise the stakes, because the CLI's permissions set the limit on which host files are reachable. Run the copy as root and a file-write bug becomes a path to root code execution.

What to Do

Update Docker Engine and CLI to 29.7.2 or later, and Docker Desktop to 4.86.0 or later. Docker Sandboxes 0.38.0 fixes the affected copy-out operation. Start with systems where docker cp touches untrusted containers (self-hosted CI runners, developer workstations, forensic workflows), and check any scripts or jobs that run copy commands as root.

If you can't update yet, don't copy from a running, untrusted container onto a sensitive machine. Stop the container first; that removes the live filesystem race the demonstrated attack depends on. If you have to collect suspicious material, do it from a disposable VM or a low-privilege account so an attacker has less to overwrite.

Claude’s Compliance API Puts AI Activity in the Audit Trail

Anthropic's Compliance API lets eligible organizations pull Claude activity programmatically and feed it into the security, legal, and compliance workflows they already run.

What You Need to Know

Employees now use Claude to draft documents, analyze files, and run agent tasks, and a login event tells a security team very little about any of it. The Compliance API fills in much more of the record. How much depends on which Claude product you're on, and the data it returns is sensitive in its own right. It's also an after-the-fact record. It won't stop risky content from reaching Claude.

What the API Exposes

For Claude Enterprise, the Compliance API covers conversations, uploaded files, projects, and available session transcripts from Claude Code and Cowork. Transcripts can include prompts, responses, and tool-call content, so an investigator can see what a user asked an agent to do and what the agent did next. An Activity Feed adds logins, admin actions, and configuration changes.

Claude Platform customers see less: administrative, system, and resource events like membership changes and API key creation, with no prompts or model responses. Enterprise customers get user content, which means someone on your side has to decide who can pull it, how long it's kept, and where copies end up.

Putting It to Work

Say you suspect someone uploaded source code. The security team finds the conversation or file record, pins down the user and the time, and checks that against identity, endpoint, and cloud logs. If those records already flow into a SIEM, DLP platform, or eDiscovery system, the case runs through the same process as any other investigation. Those systems are now holding sensitive AI content as well, so plan for that.

Why This Matters

A usage count shows that someone used an AI tool. Content and activity records show whether sensitive information went into it and whether a connected tool acted on it afterward. With agents, what the person typed is only part of the picture. You also need to know which tools and resources the agent called, what came back, and whether anything happened outside Claude. Collecting all of that puts a lot of sensitive data in one place, and it gets exactly the access controls and retention settings of wherever you send it.

What to Do

Map which Claude products your organization uses and confirm what each one actually records. Ingest only the records you need. Keep Compliance Access Keys to a short list of people, and check the permissions on any security tool connected to the API. It's worth running a test investigation before a real one comes along, to confirm the events carry enough user and session context to be useful. Finally, treat your SIEM, DLP, and eDiscovery destinations as stores of prompts, generated content, and file data, and set access and retention to match.

One Crafted Request Can Give Attackers Root on MikroTik Routers

A critical pre-authentication flaw in the MikroTik RouterOS web management service affects versions earlier than 7.24 and carries a CVSS v3 score of 9.8.

What You Need to Know

Anyone who can reach the RouterOS web management service can take over the router with one malformed HTTP request. The attacker doesn't need a password or any existing access. Internet-facing devices carry the most risk, but a management interface that can be reached from an untrusted internal network is exposed too. RouterOS 7.24 and later fix the issue.

What’s Vulnerable

CISA's September 29 advisory says CVE-2026-84411 allows an attacker to run arbitrary code as root or cause a denial of service. The bug is an integer underflow in how the web management service processes an HTTP request body, and it happens before authentication. A calculation in that code can produce an invalid value that the service doesn't handle safely, and a crafted request can set that off.

The advisory names the web management service specifically, so exposure varies by service and configuration. Assessing it comes down to two questions: which devices are running an affected version, and which networks can reach their web management interface.

Why This Matters

A compromised router can cut connectivity, have its configuration changed, or give an attacker a starting point for further activity. The routers most likely to be overlooked tend to be the most exposed: devices at branch offices and remote sites, and equipment run by service providers. These may not show up in a central vulnerability scan, and their management access rules may differ from your standard. CISA said it knew of no public exploitation targeting CVE-2026-84411 when it published the advisory, but that only covers what had been seen at that point. An attack that needs no credentials and only one request, and ends with root access, belongs near the top of the patch queue.

What to Do

Upgrade affected devices to RouterOS 7.24 or a later supported release. Before deploying, confirm the right upgrade path for each device and plan around any operational constraints. Start with routers whose web management service is reachable from the internet or other untrusted networks, and restrict that service to trusted management addresses or a protected management network. Turning off management services you don't use reduces exposure further, but restricting access is only a stopgap until the update is installed. Before and after remediation, review device configurations and available logs for unexpected changes, unfamiliar accounts, or signs of unauthorized administration.

Chrome 154 Security Update Fixes Critical ANGLE Buffer Overflow

Google's September 29 Chrome desktop update fixes 32 security flaws. The most serious is a critical buffer overflow in ANGLE, the layer Chrome uses to translate graphics calls for web content.

What You Need to Know

ANGLE handles graphics for ordinary web pages, so this flaw sits in code that runs during routine browsing. This is a point release within Chrome 154, not the initial major release. If your inventory only tracks the major version, a device reporting "Chrome 154" could still be missing these fixes. Google hasn't reported active exploitation, but it's holding back some bug details until most users have updated.

What’s Fixed

The ANGLE issue, CVE-2026-102331, is fixed in Chrome 154.0.8037.92 or .93 for Windows and macOS, and 154.0.8037.92 for Linux. Google is rolling those builds out over the coming days and weeks. (An earlier Chrome 154 release covered a separate set of vulnerabilities.) Google hasn't published an exploit scenario for CVE-2026-102331.

The release also fixes 25 high-severity issues in V8, GPU, WebGPU, WebGL, Mojo, Bluetooth, Passwords, Skia, and Media. Six are V8 type-confusion bugs. The rest include use-after-free, out-of-bounds access, buffer overflow, and uninitialized-resource issues. Those are categories of memory and data-handling errors. The label alone doesn't tell you whether a given bug can be reached from a website or exploited by itself.

Why This Matters

The browser is usually the most exposed application on an endpoint, and any page that renders can reach a memory-safety bug in the graphics path. The bigger practical problem is the version gap. With a staged rollout, some devices won't get the fixed build for days. A downloaded update also does nothing until the browser restarts. And with technical details restricted, if you wait for a public exploit before acting, attackers may know about it before you do.

What to Do

Check the full Chrome build number across Windows, macOS, and Linux devices, and start with anything below the fixed builds. Users can trigger an update from Chrome's About page, but they have to relaunch for it to take effect. Until they do, the old version is still the one running. In managed environments, make sure update policies and staged deployments aren't holding back high-risk groups, especially people who regularly open untrusted links or handle sensitive accounts. Browser controls and endpoint monitoring still help, but you still need the patched build.

AI Coding Agents Published 13,000 Internal Screenshots to Public GitHub

Ask an AI coding agent to prove a visual change works, and it may take a screenshot and post it where anyone on the internet can see it. According to new research, that happened to more than 13,000 internal images.

What You Need to Know

Security company Glow found more than 13,000 internal images from developers at over 300 organizations in public GitHub repositories. They included customer billing records, internal financial interfaces, and screenshots of features that haven't shipped. Nobody hacked the agents. They hit a workflow problem and solved it by publishing the images, which their developers never asked them to do. Many of the images ended up on developers' personal accounts, so an audit of your organization's GitHub footprint won't find them.

What Happened

Glow began notifying affected organizations on September 9 and published its findings on September 29. There are two caveats. The report doesn't show that anyone outside these organizations downloaded the images, and Glow hasn't said how it found or counted them. The findings still show a real failure mode in agent-assisted development: in these cases, a task that started as "prepare a pull request" ended with a public upload.

How the Screenshots Got Out

Agents wanted to put screenshots in code reviews and ran into two problems. GitHub's command-line tool couldn't attach images to pull requests, and images stored in a private repository could look broken to reviewers. In the cases Glow examined, agents got around both by creating separate public repositories to hold the screenshots. These were often under a developer's personal account instead of the company's organization. Glow reproduced the behavior in a lab, where an agent created a public repository to host two screenshots for a test project.

Reusable instructions make the problem spread. At one software company, Glow said, agents saved the upload method as a skill and went on to post more than 1,000 screenshots and recordings. Some agents used gitshot, a tool that, in the version Glow reviewed, stores images as publicly downloadable release assets in a repository on the user's personal account. The gitshot documentation does warn that the repository is public. That warning doesn't stop an agent from uploading a screenshot of a customer's billing page.

Why This Matters

The agents did what they were told, which was to finish the PR. The trouble is that no one had to approve how they did it, so this is an authorization failure more than a model failure. Once the workaround is saved as a skill, one agent's bad call becomes the default for the whole team. The images also end up in places most security programs don't watch. Personal accounts and release assets usually aren't monitored, and text-based secret scanners won't reliably flag a credential that shows up in a screenshot.

What to Do

Start by looking outside your organization's repositories. Check public repositories, releases, and gists on developers' personal accounts, including accounts of former contributors. Searching for gitshot-images repositories and _gitshot releases will find one known upload path. Plan to review the images by eye, because text-based scanners won't reliably catch what's in a screenshot. If an exposed image shows credentials, take down the public copies and rotate those secrets.

To prevent this, require human approval before an agent can create a public repository, post to a personal account, or change a repository's visibility. Also review your shared skills and remove any instructions that treat external uploads as normal. If your agents need to include screenshots, GitHub CLI 2.99.0 added an --attach option for images on pull requests, issues, and comments. On supported GitHub services, that keeps review images under the access controls of the intended repository.