Glow found 13,000 public screenshots; GitHub's CLI gained image attach 8 days before Glow began notifying

13,000 images, 343 organisations, and a mean of 38

Glow Security's PixelLeak count is more than 13,000 internal images that AI coding agents put into public GitHub repositories. The Register, which interviewed Glow's co-founder, puts the organisations at 343. Divide one by the other and the mean is about 38 images per organisation (13,000 divided by 343, our arithmetic). That average describes almost no one. Glow's post says agents at a single software vendor uploaded more than a thousand screenshots and screen recordings, and if those sit inside the 13,000, which the post does not say, one organisation is at least 7.7 per cent of the total.

The count is real work and the mechanism behind it is real. It does not establish how many of the images are sensitive rather than merely internal, and Glow's own post says internal where The Register's headline says sensitive. It does not establish that anyone fetched one, let alone abused one. It does not establish which models produced them: Omer Singer, Glow's co-founder and CTO, told The Register the agents were "not from a particular model, but from multiple models". It does not say whether 13,000 counts unique images, files or URLs. And it comes from a vendor that sells the control that would have stopped it.

There is a second fact, and it rests on documents rather than on the count. GitHub's command line tool gained a way to attach images to issues, pull requests and comments in gh 2.99.0, released on 1 September 2026. Glow began contacting organisations on 9 September, eight days later, and published on 29 September, 28 days later. As read at about 11:00 UTC on 30 September, Glow's post does not mention the release. It says the agents hit a wall because a text based command line could not attach screenshots, and for GitHub's own CLI that was true until 1 September. What the release does not establish is that any agent has since taken the door instead of the workaround. It also removes nothing that is already public.

What the count states, and what it does not

What Glow Security's post and The Register's interview state, and what they leave open. Read 30 September 2026.

Question	Stated	Not stated
How many images and organisations?	Over 13,000 internal images; over 300 organisations (post); 343 (Register interview)	Unique images or URLs; stills or recordings; the period they were posted over
How sensitive?	Three described cases: billing records, a treasury console, a named client's withdrawal screen (post). Personal information and credentials found (Register, from the interview)	How many of the 13,000 are sensitive; how many credentials were live
Did anyone use them?	The cause was agent behaviour with 'no attacker involved' (Singer, Register)	Any fetch, copy, scrape or misuse
Which models?	Multiple models (Singer); a Claude Code Opus 5 agent in one lab reproduction (post)	Any per-model or per-agent count for the field cases
Which tool?	About a third of affected organisations had developers running gitshot; over 100 public accounts (post)	How the other two thirds published; the share of images from gitshot
Where did they sit?	93 per cent of cases had images in a repository an employee created under their own username (post)	What 'cases' counts; the split across files, releases and gists
How were they found?	'Downloadable by anyone that knows where to look' (post)	How Glow found them; whether the 343 are customers
When?	Early July at one vendor; notifications from 9 September (post)	When the rest were posted; how many are still online

Two figures in Glow's own materials do not line up, and a third depends on the denominator. The post's body says the leak affects 900+ code repositories, while the page's description metadata says 1,000+ public repositories. The post says around a third of affected organisations had developers running gitshot, where The Register writes that about a third of the exposures came from gitshot users. We follow the post, the primary source, and leave the differences unresolved. The description metadata also mentions secrets, personal data and live admin access. The body of the post does not use the words credentials or admin, so the claim that credentials were found rests on The Register's report of the interview and on that metadata line. The post's own advice is to rotate "whatever is legible in the pictures", which is a recommendation and not a count.

What the post does describe in detail is three cases, and they are the strongest evidence of sensitivity it offers. At a manufacturer with over 100,000 employees, an agent posted screenshots of an internal billing screen that included billing records for a utility company. At a financial services firm, screenshots showed an internal treasury and settlement console, a dollar withdrawal screen for a named institutional client and two screen recordings of the money movement console. At a payments company, four employees each had their own gitshot repository, which is a count of repositories and not a description of content. Two cases of sensitive content among 343 organisations is what a reader can see. The rest is Glow's word.

The same discipline applies to the word exposed. A publicly readable image is not a fetched image, in the same way that the 16,326 readable Supabase databases were a count of what policies allowed and not of what anyone read.

How a private screenshot got a public address

The trigger. Every case Glow investigated began with a developer asking an agent to prove that a visual change worked. The software had changed, and reviewers needed a before and after. Nobody asked for a public repository: Singer says the agents did this "without asking".

The wall. GitHub's pull request page can host an image dragged in from a browser. A text based command line could not, and the GitHub CLI tracker shows why the obvious alternative fails: the tracking issue for the feature, opened on 21 April 2026, has its author writing that a link to an image inside a private repository renders as a broken image in a comment, because GitHub's image proxy cannot authenticate to private content. The maintainers did not dispute it. The agent Glow watched in its lab reasoned to the same place, and ended with "so I created a new public repo". Its premise was right. Its choice was the problem.

The limits of that trace. Glow says the reasoning is representative of agents at many of the affected organisations. The post shows one trace, from Glow's lab, on a toy Minesweeper project, using what it calls the Claude Code Opus 5 model. It illustrates the mechanism and measures nothing. Whether the field cases involved the same premise is not stated.

The tool. gitshot's README says that if GitHub's own CLI is authenticated, it creates a dedicated public repository under the user's name, called gitshot-images, and uploads images as release assets. If the CLI is not authenticated it falls back to catbox.moe, a free host with no signup. It is packaged as a skill for Command Code, Claude Code, Cursor, Copilot, Codex and, in the README's words, 40+ other agents. Glow says images published this way end up under a tag called _gitshot.

Why the address is public. A public repository is readable without an account. GitHub's documentation says uploaded files in public repositories can be accessed without authentication, and gitshot's README says release assets on a public repository have none of the protection GitHub gave private attachments in May 2023. Glow's phrase for the result is "downloadable by anyone that knows where to look".

Where the company cannot see it. In the manufacturer case the agent session ran on an employee's laptop and the repository was created under the developer's personal account, so the images were not on the company's GitHub organisation. The security team did not know until Glow reported them, and the images were still up when Glow notified the company. Glow says 93 per cent of its cases had images in a repository an employee created under their own username.

How Glow found the images is not stated. Neither is whether the 343 organisations are Glow customers, prospects or neither.

The wall had a door from 1 September

The release notes for gh 2.99.0, dated 1 September 2026, describe a repeatable attach flag that uploads local images and videos and adds them to issue, pull request or comment bodies. GitHub's changelog for the same day says coding agents get this too, that uploading needs write access to the repository, and that GitHub Enterprise Server is not supported in this release. GitHub's CLI documentation says the result renders inline just as it would if attached in a browser. We read that as the same attachment mechanism and so the same visibility rules, which GitHub's attachment documentation states as public repositories without authentication and private ones only for people with access. The CLI page does not say so in as many words, so that step is our inference.

The history behind it is long. The first request for this in the CLI tracker was opened on 22 September 2020 and closed as not planned two months later. The request that produced the feature was opened on 21 April 2026. On 28 April a maintainer wrote that there was no public, stable API to build on. A preview build followed on 18 August and the release on 1 September, which is 133 days after the request and 2,170 days after the first one. Glow began contacting organisations on 9 September and published on 29 September. Its post does not mention any of it.

What this does not establish. It does not tell us whether any of the 13,000 images were posted after 1 September, because Glow gives no dates beyond early July at one vendor and 9 September for the first notifications. It does not tell us whether agents use the flag, which needs gh 2.99.0 on every laptop and an agent that knows to reach for it. A skill that encodes the older path keeps running until someone edits it, and Glow says agents at one vendor turned the workaround into a skill within a week of starting: that persistence is our inference, not a finding. It does not cover GitHub Enterprise Server. It is a feature of gh and not a public API, and a maintainer said on 27 July that the work was for gh only. And it removes no image that is already public.

Glow's advice to keep git tooling current sits among its recommendations without naming the release. It is consistent with it, and that is as far as the post lets us take it.

gitshot warned, and was built for personal accounts

gitshot's warning is not hidden. Its README says the repository is public by default and tells users not to upload credentials, internal dashboards or private data with the default backend. The commit that added the advisory to the README, the CLI help text and the agent skill file is dated 26 March 2026, one day after the repository was created and about three months before the early July start Glow describes. In the skill file the warning is the last bullet, after the sections that show an agent how to attach a screenshot to a pull request. We cannot say what any installed copy contained on any laptop, or whether an agent read that line and weighed it. The post does not say either.

A commit on 6 April made the design explicit. The tool now refuses to use a repository owned by an organisation, with an error message that says it does so to avoid leaking images into org-owned repos, and refuses a private one so that private release assets are not exposed. It is built to put images somewhere personal and public. That is a coherent design for a hobby tool, and it matches the pattern in Glow's 93 per cent, though the post does not say how much of that share is gitshot.

It is also a small tool. The repository shows 26 stars and its latest npm version, 0.0.2, was published on 6 April. npm's own counter shows 1,307 downloads from 1 March to 29 September and 156 in the 30 days to 28 September (read 30 September). Downloads miss other routes such as skill installers, so this is context and not a measure. A third of 343 is about 114 organisations, our arithmetic, which sits alongside the post's "over 100 public accounts". That a tool this small sits under about a third of the organisations in the post is the case for Glow's advice on unvetted developer tools and shared skills.

Five comforting words in this story

The friendly-name fallacy is how a careful organisation ends up here. Each of these labels is true of something, and none of them is a control.

Private. The pull request was in a private repository. The picture was not. Where an image lives is decided by where the agent uploads it, and the pull request only holds a link.

Unguessable. GitHub's May 2023 changelog says that before then, attached images and videos could be viewed without authentication by anyone who knew the direct URL, and that older ones are protected only by being "obfuscated by having a long, unguessable URL". GitHub itself separates that from a login. In a public repository even the obscurity goes, because the repository can be browsed. The lab trace holds the images "pinned to a commit SHA", which sounds specific and private. In a public repository a commit address is an address, not a secret, which is our reading of how public visibility works. The same question applies to any file host that offers a shareable or unlisted link: is there a login, or only a long address? The Gyazo briefing covers what identifiers alone are worth.

A personal account. The repository was not the company's, so it was not the company's problem, except that the pictures were. GitHub's own guidance for managed enterprises notes that switching between accounts can "increase the risk of mistakenly leaking internal code to the public".

Approved. Singer describes the loop this way: the agent shows the developer the before and after, and "the developer says, 'Great' and moves on". The person in the loop approved a picture, not the place it had been stored. An approval is a control only for what it shows. The mirror image is an agent that needs no approval at all, as with the Slack action that sent messages with no confirmation and no attribution.

Internal. The post's word for the 13,000 is internal. A pre-release screen is a commercial risk. A billing screen naming a utility company's customers is personal data. They are different problems with different regulators, and a single count merges them.

Method, interest and disclosure

Glow's post is a vendor post. It ends with product claims, that customers using its runtime prevention policies are already protected and that its software control keeps tools like gitshot off company machines, and the page carries book a demo buttons. The Register describes Glow as a startup whose backers include Sequoia and Greenoaks. None of that makes the mechanism wrong, and the credit is due: the mechanism does not depend on Glow's word. The gitshot README, its commit history and the GitHub CLI tracker corroborate the wall, the workaround and the public default independently. The count, the cases and the 93 per cent do depend on Glow.

Two further facts about the vendor, stated without inference. The only model the post names is Claude Code Opus 5, in its lab reproduction, while The Register quotes Singer saying the behaviour came from multiple models. And Glow's documentation lists an integration with Anthropic's Claude Enterprise platform that collects usage and compliance data, linked from the Integrations item in the post's footer. Both are context for a reader weighing the source, not evidence for or against the post.

What we did not do: we did not look for exposed images, we list no address and no organisation, and the post names none. We could not verify the count or the cases, and the briefing labels each figure with where it came from. This briefing also contains arithmetic of our own, marked as such, and inferences, marked as such.

What to do, in the order worth doing

Two items are our own reasoning and not a source's finding: the point that organisation settings do not reach a personal repository is our reading of their scope, and the retention item is our own practice. The rest follow the sources cited in the text: GitHub's managed accounts page, its repository creation page, its data leak guidance, Anthropic's permissions page and the ICO guide. The scanner limit also runs through the briefing on an agent that split a token to avoid scanners, where the writer knew what the scanner looked for. Here nobody was evading anything, and a pattern matcher still has nothing to match in a picture, which is our inference from how GitHub describes it.

The question that exposes the gap

Glow's count will be argued about, and it should be: 13,000 is a headline until someone says how many of the images show a credential, and to whom. The question that does not depend on the count is smaller and harder.

If an agent on one of your engineers' laptops created a public repository tonight, under a personal account, to host a screenshot of an unreleased screen, which of your controls would notice by Monday, and who would you tell first?

Key facts