PixelLeak GitHub Screenshots Expose the Risk of Public Storage

PixelLeak screenshots on GitHub refer to findings by Glow Security involving internal screens that allegedly ended up in publicly accessible repositories. On September 29, 2026, Glow said it had found more than 13,000 screenshots associated with 343 organizations. This is not a confirmed exploitation of a vulnerability or an active attack on GitHub, but a data leak caused by publicly exposing outputs from development tools or AI agents.

According to Glow, the screenshots could have contained internal development environments, dashboards, personal or financial data, credentials, and information about unreleased products. Independent reports by The Hacker News and The Register similarly describe a scenario in which images from private environments appeared in public repositories, often under developers’ personal accounts rather than company GitHub organizations.

PixelLeak screenshots on GitHub and the role of tools

Some of the cases described are linked to the gitshot project. Its own documentation states that when used with an authenticated GitHub CLI, the tool by default creates a public repository named gitshot-images. It then uploads images as GitHub Release Assets.

gitshot’s documentation also explicitly warns that the default public backend is not intended for credentials, internal dashboards, or private data. Such a configuration can lead to screenshots being publicly exposed when the tool is used in development workflows.

Glow also links the cases to AI coding agents or tools that support them. However, it is not possible to generally attribute every finding to a specific AI model or agent. Available information indicates that some exposures were directly related to the gitshot tool and its default configuration.

Why public repositories can escape oversight

The risk is not limited to the screenshot content itself, but also includes where it is stored. Public repositories created under developers’ personal accounts can escape oversight focused on company GitHub organizations. In automated workflows, a tool or agent may fulfill a task to store or attach an image by creating a separate public repository.

The case therefore does not describe remote code execution or a breach of GitHub’s platform protections. It is a problem of control over data uploads: sensitive output may reach a public location because of a tool or workflow configuration.

The scope of the findings has not yet been independently recalculated

The figure of more than 13,000 screenshots and 343 affected organizations comes from Glow Security. No publicly verifiable methodology, complete list of findings, or independent recount has been made available. It is also unknown whether anyone other than the researchers and affected organizations downloaded or used the screenshots.

Affected teams can check public repositories and Release Assets outside company organizations, especially on accounts used during development. If sensitive content is found, relevant steps include removing public files and replacing credentials if they may have been exposed. gitshot’s documentation already clearly states that its default public storage method should not be used for sensitive data.

Further developments will depend on whether Glow publishes its methodology or a sample of the findings and whether it revises the reported scope. Statements from GitHub and coding-agent makers on securely attaching images to private pull requests may also be expected, along with possible changes to the default settings or warnings in the gitshot project.

Verified and updated: 09/30/2026 15:31