If so it seems like that's a relatively easy fix for Github, just check if the commit is actually contained in userB's fork of the repo.
These are "known issues" I believe GitHub doesn't intend to fix:
1. With youtube-dl[0] (and probably long before?) we know you can push a commit and view it under the web UI under another user, GitHub hasn't indicated this is a vulnerability at all.
2. Many people know you can impersonate another user through Git email addresses[1] (GPG signing is supposed to solve this, but a lot of people don't use it and even when they do others don't really know they should look for "Verified" in GitHub's web UI.)
Combine these two known-issues and you get a really convincing phishing attack.
I really hope this doesn't become a common-place thing. Hopefully this raises some awareness that, basically, you should not trust any GitHub URL with a commit SHA in it - only trust ones with branch names - because it could be a phishing attack otherwise.
[0] https://news.ycombinator.com/item?id=24882921
[1] https://bounty.github.com/ineligible.html#impersonating_a_us...
Though I probably wouldn't use a thing from a random hash? I'd go to the repo's main GitHub page and look for branches/tags that interest me. Doesn't everyone do that?
Very close to that, yes. There's actually just one more step you need to take: you have to also open a pull request from userA/project to userB/project. As a convenience feature, GitHub automatically makes PR commits available under a special namespace. You can try it yourself with any pull request that comes from another repo--just `git fetch origin pulls/<PR #>/head.
Since the foreign commit is there in this special 'pulls' namespace, it can be viewed in the web UI by its commit ID. That's how people are adding youtube-dl to github's DMCA notice repo; they're just opening a PR containing youtube-dl's commit history.
It's not that easy. First of all, you'd need to define "contained in". The naive choice would be anything reachable by a named ref. However, all pull requests also create a ref in your repository, so you'd need to exclude those. But that would mean that if you make a PR and then delete the branch the PR is made from, the PR contents aren't visible anymore.
But even if you have the set of refs that you consider to be in a repository, that means every time an object is requested you'll have to walk the whole graph backwards to find if an object is reachable from a ref. That's an expensive operation, and Git is usually pretty fast because it tries really hard to avoid this.