1,000 pts
@Abss0x7tbh discovered that the route responsible for opting users out of further invites from an organization was vulnerable to CSRF. In order to exploit this, an attacker would need to know the name of the organization and make the request after the invite is created but before the victim accepts or declines it. We addressed the vulnerability by changing all opt-out related controller actions to only allow POST requests, which require valid CSRF tokens.
5,000 pts
@Abss0x7tbh discovered that organization invites could be claimed by unauthorized users if the invitation was sent to an email address, as opposed to a GitHub username. The invite could have been accepted either directly via a link in the email or through the UI on GitHub.com. In order for a user to have accepted an invitation through the UI, the user would have needed to add the email to an existing account and viewed the organization’s page. A banner would display letting the viewer know they were invited to the organization and it allowed them to accept the pending invite. This was intended behavior, however, the flow was returning pending invitations for both verified and unverified emails on the account. This meant that if an attacker knew the email address of a recently invited user, they would be able to claim the organization invite if they added the invited email to a GitHub account before the intended invitee. We addressed the vulnerability by limiting the lookup of pending invitations to the verified email addresses on a user’s account.
This is fixed in GitHub Enterprise 2.9.17, 2.10.12, 2.11.6, and 2.12.
