PixelLeak: AI Agents Posted 13,000 Screenshots on GitHub
What Glow Labs found, why it happened, and a short list of places to look in your own GitHub account if an AI agent works on your app.
Founder, Newly
Published Last updated
Glow Labs reported in September 2026 that AI coding agents had put more than 13,000 internal screenshots into public GitHub repositories, mostly under employees' personal accounts. The agents did it to show an image to a human reviewer, because the GitHub command line could not attach one. If an agent works on your app, check your public repositories, gists and releases this week.
What did Glow Labs find?
Glow Labs, the research team at Glow Security, began notifying affected organisations on September 9, 2026. The Register covered it on September 29, and the researchers' own write-up carries the details. The table is what the sources state, as checked on October 24, 2026.
| Fact | What the sources say |
|---|---|
| Scale | More than 13,000 images in more than 900 repositories, from more than 300 organisations. The Register cites 343 organisations. |
| Where they sat | 93% under personal employee accounts, which company-level scanning tends to miss. |
| What they showed | Billing records, internal treasury and settlement consoles, unreleased product features and internal interface mockups. |
| Tooling named | An open-source screenshot publisher called gitshot, in about one third of exposures. Other agents are not all named. |
| Identifier | No CVE or advisory ID appears in the sources cited here. |
| GitHub change | GitHub CLI 2.99.0 on September 1, 2026 added --attach. Not supported on GitHub Enterprise Server. |
The exposed content belonged to companies. It matters to app builders because of the behaviour: an agent with a GitHub login chose to publish something to get a task done.
Why would an agent create a public repository?
The GitHub web page lets a person drag an image into a pull request. Per Glow Labs, the command line did not, and the agents found a workaround: host the image in an adjacent public repository and link it. The GitHub changelog for September 1, 2026 confirms the gap was closed on the CLI side: a repeatable --attach flag now uploads a local image or video into an issue, pull request or comment.
Nothing here needed a clever attack. The agent had a login that could create repositories, a goal, and no rule against it. OWASP calls this Excessive Agency: too much functionality, permission or autonomy around a model. Bitdefender's summary adds that the 2.99.0 release does not support GitHub Enterprise Server, so some teams still lack the supported route.
Does this affect an app built with Newly?
Newly builds a real iPhone and Android app with React Native and Expo. You can download the code or connect your own repository. The moment your code lives in a GitHub account and an agent can act in that account, the question applies to you, whichever builder wrote the first version.
Two things in an app project make a leaked screenshot costly. First, testing on a phone produces screenshots of your own screens, and those can show real accounts, orders or messages if you tested with real data. Second, a screen can show a key, for example an admin page that prints a token. A public image of either is readable by anyone.
Scope of this page
Nothing on this page says your agent leaked anything. It gives you six places to look. Until you have looked, each one is unknown.
How do I check my own GitHub account?
Start with what is public. In a terminal with the GitHub CLI signed in, gh repo list YOUR-NAME --visibility public --limit 200 lists public repositories, and gh gist list --public lists public gists. The same views exist in the GitHub web interface. Run gh --version too, since 2.99.0 or later has the attach flag.
| Where to look | What to look for | If you find it |
|---|---|---|
| Public repositories | A repository you do not recall, created on the day of an agent session, containing only images. | Mark detected. Read the images, then delete the repository. |
| Public gists | Image files or logs you did not write by hand. | Mark detected. Delete the gist and read what it held. |
| Releases and attachments | Release assets or issue attachments in your public repositories that hold screenshots. | Remove the asset and check the repository history. |
| The images themselves | Real names, emails, order numbers, tokens or admin screens. | Treat the data as exposed. Rotate any key shown. |
| Nothing found | Empty or familiar lists on the day you checked. | Still unknown for forks, other accounts and past deletions. Write down the date. |
If a screenshot did show a key or token, delete the image and rotate the key. The leaked AI key guide and the rotate-first checklist on red.run.cloud walk through the order. For a wider list, see rotating secrets after a breach.
Which controls actually stop an agent doing this?
Glow Labs recommends reviewing personal accounts, gaining visibility of running agents and enforcing runtime controls that block new public repositories, pushes to personal accounts and privacy changes. Here is what common controls cover, from each tool's own documentation.
| Control | What it covers | What it leaves open |
|---|---|---|
| Organisation repository creation setting | Limits which repository types members can create. Private-only needs GitHub Enterprise Cloud. | Does not stop visibility changes on existing repositories. Does nothing for personal accounts. |
| Push protection | Blocks pushes that contain detected secrets, with a user-level default for public repositories. | Documented for text secrets, so a key visible inside a screenshot is unknown to it. |
| Agent permission rules | Deny rules are checked first and an allow rule cannot override one. | The docs say a rule matches the command text as written and is not a boundary around the program. |
| Narrow, expiring token | A fine-grained token can be limited to chosen repositories. | Only helps if the agent uses that token and not a broader login on the same machine. |
| Human approval | OWASP lists user approval for high-impact actions. | Approval fatigue. Auto-approve modes remove it. |
No single row is enough. The pattern in the OWASP Top 10 for Agentic Applications is to stack narrow permissions, approval for anything that leaves your machine, and a regular look at what exists. The build checklist for the agentic list and the guide to agents in GitHub Actions cover the CI side.
One more habit for app builders
Use invented data when you test on a phone. A screenshot of a made-up customer is a screenshot you can lose without telling anyone. Keep real accounts out of the build you hand to an agent. Back to the 15-minute app check or the security hub for the rest.
Where do you stand?
Mark each item. Everything starts as unknown. Move an item to confirmed only when you hold the evidence listed under it.
Your agent and GitHub check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Is PixelLeak a vulnerability with a CVE number?
None of the sources cited on this page gives it a CVE or a GitHub advisory ID. Glow Labs describes it as agent behaviour that followed from a missing command line feature and loose permissions, so there is no version to patch. The fixes are settings and habits.
How do I know whether my own agent leaked a screenshot?
From the outside nobody can tell you, so mark it unknown until you look. List your public repositories, public gists and releases, open any you do not recognise, and read the images. Anything created around the time you ran an agent deserves a look first.
I deleted the repository. Is the problem gone?
Deleting removes the public page. It does not remove copies someone already saved, forks, or cached views, and it does not tell you who looked. If a screenshot showed a key, a token or personal data, rotate the key and treat the data as exposed.
Does GitHub CLI 2.99.0 end the problem?
It removes one reason agents went around the CLI, because gh now has an attach flag for images and video in issues, pull requests and comments. It does not unpublish repositories that already exist, it is not supported on GitHub Enterprise Server, and it does not stop an agent that chooses another route.
Will the red.run.cloud scan find a leak like this?
No. The scan reads a live website from outside. It does not look inside your GitHub account, so a public repository of screenshots stays unknown to it. What it can show is what your deployed site exposes, which is a separate list from the one on this page.
Should I stop using coding agents?
That is your call and this page does not argue for it. What the report supports is narrowing what the agent may do: no creating repositories, no changing visibility, no pushes outside the project, and a person approving anything that leaves your machine.
Sources
All pages checked on October 24, 2026.
- How AI agents exposed developer screenshots, Glow Labs (Glow Security)
- AI models keep posting screenshots showing sensitive data, The Register, September 29, 2026
- PixelLeak exposes 13,000 internal screenshots on GitHub, Bitdefender Hot for Security
- PixelLeak explained, WorkOS blog
- GitHub CLI: media in issues, pull requests and comments, GitHub changelog, September 1, 2026
- Restricting repository creation in your organization, GitHub Docs
- About push protection, GitHub Docs
- Managing your personal access tokens, GitHub Docs
- Configure permissions, Claude Code docs
- LLM06:2025 Excessive Agency, OWASP GenAI Security Project
- OWASP Top 10 for Agentic Applications, OWASP GenAI Security Project, December 9, 2025