GitHub Admits Commit Authors Are Just Strings: A 10-Minute Trust Check

If you verify candidate GitHub profiles, the name on a commit has never proved who wrote it. On October 12, 2026, GitHub's own changelog said so in writing: commit author and committer fields are "just strings that the pushing client supplies." Separately, TestGorilla data reported by HR Dive found that more than 2 in 3 recruiters spend an hour or more checking each candidate's credentials by hand. Both stories lead to the same fix. Ignore the fields anyone can type and read the ones that only a logged-in account could have produced.

What did GitHub actually admit on October 12?

GitHub admitted that the name and email on a commit prove nothing about who wrote it. The changelog says "anyone with write access to a repository can set them to any name and email they choose."

This isn't a new bug. It's how git works. The client writes the author and committer fields into the commit before GitHub ever sees it, and GitHub then looks up that email and shows the matching profile's avatar.

Commit spoofing means setting a commit's author or committer to someone else's name and email so that GitHub shows it as their work. GitHub has treated this as working as intended for years:

• One researcher pushed commits as Linus Torvalds and reported it. GitHub told him it was "by design."
• A commit "by" Torvalds in the no-as-a-service repo shows his avatar, and GitHub treats it as a perfectly valid commit.
• jayphelps/git-blame-someone-else is a public tool that rewrites both the author and the committer.

What shipped on October 12 is a rule called "Committer must match pusher." It blocks pushes where the committer metadata doesn't match any verified email of the authenticated pusher. That fixes a real problem, but only for a narrow audience.

Does GitHub push attribution protect the profiles recruiters read?

No. GitHub push attribution is in limited public preview for GitHub Enterprise customers only. The release adds the control but doesn't say it's on by default, so the public repos that sourcers browse are still unprotected.

Here's what the fix leaves out:

• Personal portfolio repos. Most sit outside any Enterprise setup, so the rule never reaches them.
• Most open-source projects. The rule only works where an Enterprise owner opts in and adds it.
• Older commits. The changelog says nothing about filling in pusher identity for history that already exists. Don't assume it does.
• Author fields. The rule checks the committer against the pusher. A candidate's commit graph is driven by author email, which is a separate field.

For hiring purposes, commit-level identity was exactly as forgeable on October 16 as it was on October 11. What changed is that GitHub now says so in writing, which makes "the commits look real" a weaker defense of any hiring decision.

Where is the trust line between real and fake GitHub signals?

The line runs between git objects and GitHub actions. A git object is data the client writes into the commit before GitHub ever sees it. A GitHub action is something done in a logged-in session on GitHub's servers, so GitHub knows which account did it.

That one distinction sorts nearly every signal on a profile:

The top tier matters because it requires a second person. When a maintainer merges a candidate's pull request into a project the candidate doesn't own, an independent authenticated account had to accept the change. One person can't fake that alone.

A merged PR in someone else's repo took two logged-in humans. A green square took one text field.

TestGorilla CEO Wouter Durville summed up the broader problem: "Recruiters got a better search engine and a worse index in the same 12 months." For GitHub, the index stops being "worse" once you read only the bottom two rows of that table.

Why can't you trust GitHub's green contribution squares?

The squares follow an email string, not a person. A commit counts toward the graph if its author email matches a verified email on the account, and the graph isn't tied to who pushed it.

Since commit dates are also client-written, anyone can fill a year of squares in a single push. The tools for it are public and popular:

• Shpota/github-activity-generator has 3.7K stars and auto-generates 0 to 20 commits per day for the past year.
• 0vm/Commit-Graph-Spoof goes further and makes a fake commit from 1970.

The mechanism matters more than the tools. The graph never asks two questions: did this account push these commits, and did the push happen on these dates? When a green wall of activity is your proof of consistency, you're trusting the two fields git lets anyone edit. That's why fake GitHub commits are a profile-padding problem first and an impersonation problem second.

Whose identity is actually attached to a pull request?

Only the person who opened the PR, the reviewers, and the merger are bound to GitHub accounts. The avatars on the individual commits inside the PR come from email lookup, so they can show anyone.

A known attack works because of this. Someone can fork a public repo, make changes locally while spoofing a contributor's email from the parent repo, and then open a pull request. The commit list shows the respected contributor's face, but the PR itself is tied to the real opener.

When you review a candidate's PR, read three things and skip the rest:

1. The opener. The account that opened the PR.
2. The reviewers. Each one is a logged-in account.
3. The merger. The account that approved and merged it.

If the candidate's handle shows up only on commit avatars and never in those three places, you've learned nothing about them.

How do you verify developer contributions in 10 minutes?

Spend 10 minutes on account-bound signals only: merged PRs outside the candidate's own repos, who merged them, reviews, issue threads, and a timestamp sanity check. Skip the commit graph completely.

2 in 3

Here's the routine, with a time budget for each step. Replace USER with the candidate's handle in GitHub's search bar.

1. Merged PRs in repos they don't own (2 min). Search is:pr author:USER is:merged -user:USER. The -user: filter removes repos under the candidate's personal account. Check whether any of the remaining orgs belong to the candidate, since those aren't independent.
2. Who merged them (2 min). Open three of those PRs. Confirm that a different account did the merge and that the account is a real maintainer of that project.
3. Review history (2 min). Search is:pr reviewed-by:USER. Reviews show judgment on other people's code, and they require the candidate's own logged-in session.
4. Issue threads (2 min). Search commenter:USER. Read one thread and look for technical substance, such as reproductions, root causes, or tradeoffs, rather than "+1."
5. Timestamps (2 min). Commit dates are client-written, but push events carry GitHub's server time. A year of commits that all arrived in one push is the tell. For new profiles, the public events endpoint (api.github.com/users/USER/events/public) shows recent pushes. It only covers recent activity, so don't rely on it for older history.

If steps 1 and 2 come back strong, you're mostly done. A few merged PRs in independent projects outweigh any number of squares.

Doing this candidate by candidate is still slow, and it's where I'd flip the workflow. Instead of collecting profiles and then checking them, start from the trusted signal. With Refolk you describe the person in plain English, for example engineers with merged pull requests in projects they don't maintain, and get back a ranked shortlist. The account-bound check then starts from people chosen for that signal, not from whoever had the greenest graph.

Why are maintainer-grade signals so scarce?

The strongest signal is rare because few people are maintainers, and recruiters far outnumber them. In Refolk's index of professional profiles, there are 21,944 current Technical Recruiters and Technical Sourcers in the US, and only 121 US profiles say "open source maintainer" in their headline.

~181

Some caveats. The UK figure of 736 undercounts, because many UK agency recruiters use titles like "Recruitment Consultant." The 121 also undercounts maintainers, since plenty of them never put the word in a headline. Still, the shape holds. The sampled maintainer profiles include a CNCF profile, an AboutCode lead maintainer, and people at Docker, Microsoft, and AWS, the kind of people who sit behind the merge buttons that make everyone else's PRs trustworthy.

That leads to a practical sourcing move. Maintainers are the second authenticated person in the high-trust row of the table, so their own work is verifiable, and they know which outside contributors did real work. A maintainer who merged a candidate's PR is a far better reference than the candidate's commit graph. Because headlines miss most of them, this is another place Refolk helps: asking for maintainers of a specific project surfaces people who don't advertise the title.

Does a missing Verified badge mean the commits are fake?

No. A missing "Verified" badge is neutral. Most real developers never sign their commits, and unless vigilant mode is turned on, GitHub gives unsigned commits no verification status at all.

Signed commits only help if the candidate set them up, so don't penalize the large majority who didn't. I've covered the reasoning in more detail in the guide to scoring a genuine vs. gamed GitHub profile.

FAQ

Can someone fake GitHub commits to look like a well-known developer?

Yes. Anyone with write access to a repo can set the author and committer to any name and email, and GitHub will show the matching profile's avatar. A researcher did it publicly with Linus Torvalds's identity, and GitHub called the behavior "by design." What can't be faked this way is the account that opened a pull request or the maintainer who merged it.

Does GitHub push attribution stop commit spoofing on public repos?

Not yet. Push attribution launched on October 12, 2026, in limited public preview for GitHub Enterprise customers. Owners have to add the "Committer must match pusher" rule, and the release doesn't say it's on by default. Most personal portfolios and open-source projects sit outside that setup, and nothing indicates older commits get pusher identity added.

What is the single most reliable GitHub signal for a recruiter?

A pull request opened by the candidate and merged by a different, logged-in maintainer in a repo the candidate doesn't control. It needs two authenticated accounts, so the candidate can't produce it alone. Search is:pr author:USER is:merged -user:USER and then check who clicked merge.

How long should it take to verify a candidate's GitHub profile?

About 10 minutes if you only read account-bound signals: merged external PRs, who merged them, reviews, issue threads, and one timestamp check. TestGorilla found that more than 2 in 3 recruiters spend an hour or more per candidate, and 30% spend two hours or more. Skipping the commit graph and author fields, which can't prove anything, is where the time comes back.