Secret scanning does not appear to detect credentials inside zip archives. A 112-day real-world exposure.

[mr-fumanchu]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Code scanning

Discussion Details

I want to share a real exposure from my own repositories, because I think it shows a gap a lot of people are relying on without knowing it.

What happened

On 2026-07-17 I pushed a 13 KB zip to two of my public repos as part of packaging a small agent project for distribution. Inside the zip was a macOS launchd plist, and that plist had a live Anthropic API key in plain text inside its EnvironmentVariables block.

It sat publicly downloadable for 112 days. On 2026-11-05 and 06 someone used it for about $142 of API calls.

Why nothing caught it

Anthropic participates in GitHub's secret scanning partner programme. That same key committed as plain text would normally be detected and auto-revoked within minutes. That protection is real and I have seen it work.

Inside a zip, nothing happened. No alert, no partner notification, no revocation. I checked the secret scanning alert list on both repos afterwards and it is empty. GitHub never saw it.

Worth adding: git log -S cannot find it either, because the string only exists inside a compressed blob. I spent a long time clearing my repositories with git searches before realising why they all came back clean.

Why I think this will keep happening

Zipping a project folder for distribution is completely routine across plugin marketplaces, agent registries, skill stores and template repos. The person making the zip is thinking about what to ship, not about which dotfiles get swept in.

And the files that silently ride along are exactly the ones that hold credentials: launchd plists with EnvironmentVariables, .env files, config.txt, credentials.json, token.json.

The result is a key that is fully public, fully valid, and invisible to every scanner in the ecosystem.

What might help

• Scanning inside common archive formats, at least below some size threshold. Mine was 13 KB.
• Or, far cheaper: a push-time warning when an archive contains filenames historically associated with credentials. That alone would have stopped this.
• Or at minimum, documenting the limitation clearly. I assumed partner-programme coverage applied to anything I pushed public. I suspect I am not alone.

One more data point

Traffic on those repos for the two weeks before discovery shows 12 clones from 12 unique sources and zero page views, including two unique clones the day before the unauthorised usage started. Nobody browsed. Machines were pulling.

Update: I asked GitHub Support directly whether secret scanning inspects archive contents. They could not confirm it either way from their own documentation, and could not confirm a documented limitation stating archives are excluded. So this appears to be genuinely undocumented rather than a known gap.

Happy to answer questions. The mistake was entirely mine, and I would rather it be useful to someone else than just embarrassing.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐