GitHub commit Verification logic flaw and bypass

1 point

9 days ago

I know Git is not designed to use in the way GitHub is operating under and the spoofying had been an old issue that had been brought up throughout the years. With Shai Hulud and AI Agent, this time is abit more serious as the commit verification can be spoofed as well if you did not op in Vigilant Mode AND with a registered GPG key.

I understand there are limitations to platform and the Git itself, but design decision and design flaw are totally different things. With the very frustrating bug bounty report dismissal and the ironic branding of commit verification as a mitigation method by the MSRC, I had waited long enough to post it here.

GitHub clearly have the chance to do verification associating with the platform auth token and the user registered email but they chosen not to. And adding even more irony they (GitHub) got hacked when I was waiting for more engagement in this issue that ties to this hacked look is priceless.

Here's the formalized body:

---------------------------------------------------

GitHub's own documentation establishes a chain of trust assumptions that, followed to their logical conclusion, reveals a verification gap that cannot be audited, cannot be programmatically detected, and is available to any GitHub user with a free account.

The documented chain:

1. GitHub docs state that commit signature verification lets other people "be confident that the changes come from a trusted source": https://docs.github.com/en/authentication/managing-commit-signature-verification

2. Verification checks whether the commit is signed with a GPG/SSH key registered to a GitHub account: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

3. Git has two identity fields per commit: author (who wrote the code) and committer (who applied it). Both are set freely via environment variables — GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL: https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables

4. GitHub's UI displays the author prominently. The committer is hidden behind a secondary click. The green "Verified" badge sits next to the author's name and avatar.

5. GitHub's verification binds only to the committer's key. The author field is not verified, not validated, and not constrained. The API exposes this directly — author, committer, and verification are separate objects on every commit: https://docs.github.com/en/rest/git/commits

The logic flaw:

The badge says "Verified" next to the author's name — but it verified the committer's key. These can be two completely different people. GitHub's own API confirms this: a commit can return author=torvalds, committer=<ANYONE>, verification.verified=true. The UI shows Linus Torvalds with a green checkmark. The signing key is mine.

This is not a bug in the crypto. The GPG signature is valid. The flaw is in what "Verified" communicates versus what it actually checks.

GitHub knows about this — and gated the defense behind the victim:

GitHub actually has a "Partially verified" badge state. It triggers when author ≠ committer and the author has enabled vigilant mode: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits

This means GitHub is aware that author-committer mismatch is a trust problem. But the defense is opt-in, off by default, and gated on the impersonated user's account settings — not the attacker's. The attacker controls whether the defense fires by choosing victims who haven't enabled vigilant mode. Linus Torvalds hasn't. Neither have most GitHub users.