On September 29, security firm Glow published "PixelLeak," a study reporting that AI coding agents had made internal images publicly available on GitHub. According to Glow, it found more than 13,000 images tied to over 300 organizations, including customer billing records and screens from unreleased products.
The trigger was a request that is routine in software development: show reviewers the screen before and after a fix. The agents reportedly could not find a way to attach images from the command line, so they used a separate public repository as an image host.
However, since September 1, GitHub CLI has had an official feature for attaching images and videos directly. Preventing this problem requires more than knowing which safe sharing methods are available today. Teams also need to check whether agents still retain public-upload procedures or skills they learned earlier.
Where did the review images go?
The scale Glow reported covers more than 13,000 internal images, over 300 organizations, and over 900 code repositories. The number of images, the number of organizations, and the number of affected repositories are separate tallies.
The published examples include customer records that appeared on screen when an internal billing page was modified, as well as screens showing fund management and payment operations. Glow says it found not only still images but also screen recordings showing sequences of operations.
It is not unusual for developers to check UI changes with screenshots. Code alone makes it hard to tell whether a button's position or a broken layout has actually been fixed.
Normally, an image is attached to a pull request (PR), which asks for changes to be merged, and the team reviews it there. If development takes place in a private repository, the review content is generally visible only to those involved.
According to Glow, however, some AI agents concluded that they could not attach images from the command line. They uploaded the images to a separate public repository and pasted the URLs into the PR.
Even if the original code stays private, the images themselves can be retrieved from outside if they are stored in a public location. If a screenshot shows a screen containing customer information, the data on that screen is exposed along with the result of the fix.
What is reported here is a sharing method the AI agents chose in order to complete their tasks. Glow's explanation does not describe an attacker injecting malicious instructions.
The published materials do not make clear, however, how far developers checked or approved each individual publishing action, or how many of the exposed images were actually retrieved by third parties.
The figure of more than 13,000 is the scale of public images Glow confirmed. It does not indicate how many images were misused or how many cases of actual harm occurred.
Even in a private PR, anyone can view an image if its storage is public
Glow reports that developers using the image-sharing tool gitshot were found in roughly one-third of the affected organizations.
This does not mean that one-third of the leaked images came from gitshot. It means that use was confirmed in about one-third of the affected organizations.
The gitshot README states that images are made public through GitHub by default.
If no other storage destination is configured and the user is authenticated with GitHub CLI, the tool creates a dedicated public repository in the user's personal GitHub account on first use and uploads images as GitHub Release attachments.
This differs from saving images as ordinary source files in a repository. As a result, checking only the file list of a public repository does not necessarily reveal every uploaded image.
The README also warns against using the default storage method to upload credentials, internal dashboards, private data, and the like.
| Method of sharing images | Where the image is stored | Conditions for viewing |
|---|---|---|
| Official attachments in a private GitHub repository | Images and videos attached to the relevant issue, PR, etc. | For attachments added to private repositories since May 2023, login and access rights are generally required |
| gitshot's default GitHub route | GitHub Release attachments in a public repository under a personal account | Retrievable by anyone who knows the URL. Linking from a private PR does not make the image itself private |
The comparison is between GitHub's announcement explaining authentication for private attachments and gitshot's default storage method.
gitshot can also use other storage destinations such as Cloudinary and ImgBB, so not every configuration publishes images in the same way.
The key point is that the people who can view a PR's text are not necessarily the same as the people who can retrieve the image itself.
Even if an image URL is pasted into a private PR, the PR's access restrictions do not carry over to the image if it is stored in a public repository.
Simply saying "it was saved on GitHub" or "it was pasted into a private PR" is not enough to determine who can see an image.
GitHub CLI has had an official attachment feature since September 1
On September 1, 2026, GitHub CLI made generally available a feature for attaching images and videos directly.
Before Glow began notifying affected organizations on September 9 and published PixelLeak on September 29, an official way to attach images directly from the command line was already available on GitHub.com.
In its CLI 2.99.0 announcement, GitHub added an --attach option for uploading images and videos.
It can be used when creating or editing PRs and issues and when posting comments, and it uploads images on the local machine directly to GitHub.
| Date in September 2026 | What can be confirmed | Announced by |
|---|---|---|
| September 1 | GitHub CLI 2.99.0 makes direct image and video attachment generally available | GitHub |
| September 9 | Notifications to identified organizations begin | Glow |
| September 29 | PixelLeak findings published | Glow |
For this reason, it would not be appropriate to apply the constraint in Glow's report, that images could not be attached from the CLI, to GitHub.com as it stands today.
However, the published materials do not say which version of GitHub CLI was used in the environments where PixelLeak was observed, or whether publishing by the same method continued after September 1.
Nor can one assume the problem was resolved at the moment the official feature became available.
--attach also has conditions of use. Uploading images requires write access to the target repository, and GitHub Enterprise Server is not covered by this release.
The options available differ between environments that can use the latest CLI with GitHub.com and those that run their own GitHub Enterprise Server.
That said, being unable to use the official attachment feature is no justification for uploading internal images to a public repository.
AI agents repeat a risky procedure once they have learned it
In one case Glow described, involving a software company, public uploads of screenshots began in early July. Within a week, more than a dozen AI agents had saved that method as a "skill."
Afterward, more than 1,000 images and screen recordings were posted, along with descriptions of features that had not yet been released.
A skill here means a procedure or rule that an AI agent consults while working.
Once a procedure has been learned as a way to show images to reviewers, the agent may repeat it on later tasks without rechecking whether the sharing method is safe.
This is a case involving one anonymous company that Glow described. It does not mean the same thing happened at all of the more than 300 affected organizations.
Glow also ran a separate experiment asking an agent to change a Minesweeper screen, and showed an AI agent creating a public repository because it prioritized displaying the image to the reviewer.
This experiment cannot be equated with the behavior of every affected company. Even so, if a risky sharing procedure, once created, remains in an agent's settings or skills, it may continue to be used even after GitHub adds a new, safer feature.
Examining source code alone will not reveal image leaks
The scope of an audit also needs to be widened to match where images are stored.
Glow recommends checking not only a company's GitHub organization but also the personal accounts of employees and former employees, GitHub Release attachments, Gists, and so on.
In this set of cases in particular, the images were stored in employees' personal accounts rather than the company's organization in 93% of cases.
In addition, because general code scanning targets text strings, it cannot necessarily detect customer names, account information, or internal screens shown within a screenshot.
Investigating where something was published and checking what appears inside an image need to be treated as separate tasks.
As preventive measures, Glow recommends reviewing the skills and rules that AI agents consult. It also recommends mechanisms that block, or require human approval before, actions such as creating public repositories, sending content to personal accounts, and posting to Gists.
Updating GitHub CLI to the latest version and using the official attachment feature is another measure.
However, that alone will not delete images that have already been published, and it will not automatically rewrite old upload procedures stored in agents.
What companies need to check is not only whether an image appeared on the review screen.
They also need to confirm which account and which storage location the image was uploaded to, and who can access it.
To use image sharing by AI agents safely, it is important to check both the access rights of the attachment destination and the sharing procedures the agents are actually using.