Repeated GitHub Actions token leaks in release artifacts

[Sofahamster]

Select Topic Area

General

Body

I'm trying to understand what GitHub's position is on secrets being repeatedly published inside GitHub Release assets, and what escalation path exists when a project does not remediate.

I've encountered a well-known open-source library that has now published multiple releases where the release archive contains the entire workspace, including .git/ and .github/. As a result, a ghs_* GitHub Actions token ended up embedded in the release ZIP/7z assets. The maintainers re-released once to fix it, but the very next release repeated the same mistake (and even "double-packed" the workspace by archiving the zip archive in a 7z archive).

I'm not going to test what the token can do, and I am not sharing any secret values here. My goal is to prevent further leakage and understand whether GitHub can apply any platform-side controls.

Is there a recommended GitHub reporting route for secrets exposed in Release assets (as opposed to secrets committed to the repository content)?

Does GitHub Secret Scanning or automated revocation cover archives uploaded to Releases, or only repository contents?

If a project repeatedly republishes leaked tokens, is there any mechanism for GitHub to intervene (revocation, warning banners, temporary disabling of Releases, etc.)?

[midiakiasat]

GitHub Secret Scanning is designed to scan repository content (entire Git history) (and some first-party surfaces like PRs/issues), but it is not documented as scanning Release assets/archives.

So the right escalation path is:

1. Assume compromise and rotate immediately. A ghs_* token in an artifact should be treated as leaked.
2. Privately notify the maintainers with the release URL + asset name + where in the archive it appears (no token value).
3. If the project won’t remediate / keeps repeating it, escalate to GitHub via the Security contact form (sensitive data / security report) and include the release asset URL(s) and evidence.

Platform-side controls (revocation/warnings/disabling releases) are not something Community can do; only GitHub Security/Trust & Safety can act after a report.

[Sofahamster]

1. I can't rotate anything as it is not my repository
2. Sadly Github does not provide any means to privately notify anyone, at least as far as I could see. And the maintainer doesn't provide any means of contact on their profile or repo.
3. I could not manage to escalate via the Security contact form. The process is (probably on purpose) so convoluted that I gave up.

So I did a "full disclosure" and opened a regular issue ticket in the repository with all details. If Github doesn't provide better means to address such issues, that's not my problem.

[midiakiasat]

If it’s not your repo, you’re correct: you can’t rotate/revoke anything yourself.

But “full disclosure” in a public issue is the worst-case outcome because it increases scraping risk. The safe escalation options on GitHub are:

1. Use “Report a vulnerability” (private vulnerability reporting) if the repo has it enabled: Security → Advisories → Report a vulnerability.
2. If PVR is not enabled and there’s no SECURITY.md contact, open a public issue without the token/value, only: release URL, asset name, file path in archive, and “contains a ghs_* runner token”. Ask them to enable PVR/SECURITY.md.
3. To get GitHub involved, use the Private Information Removal / Sensitive Data contact path (include the release asset URLs and evidence, no secret value). GitHub explicitly says they may only assist with sensitive-data removal when rotation isn’t sufficient.