I have observed unexpected behavior regarding collaboration invitations to private repositories. #168079
Replies: 5 comments
-
|
Yes, this seems like a real security issue. The invitation link sent by GitHub works like a token ,and anyone who has that link can use it, even if they weren’t the person originally invited. That means if User A shares the link with User B, User B can still join the private repo. FIXES:
I also recommend reporting this directly to GitHub Security:https://github.com/contact/security Hope this helps! |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
|
This is a significant security concern you've identified. You're absolutely correct that repository invitations should be tied to specific GitHub accounts for security reasons. This is actually intended behavior (though counterintuitive), but it does create a security risk. GitHub's invitation links are designed as "anyone with this link can join" tokens rather than being strictly bound to the invited account. Why this happens: Invitation tokens are treated as reusable access keys They're not validated against the original invitee's identity when redeemed This makes collaboration easier but creates the security gap you've found Recommended actions: Immediate mitigation: Revoke any outstanding invitations and re-invite specific users Report this to GitHub Security: File a detailed report through GitHub's security reporting process describing the vulnerability Best practices moving forward: Only share invitations with trusted users Regularly audit repository access Consider using organization-level invites with stricter controls You should emphasize in your report that this allows bypassing of repository access controls and could lead to unauthorized access to private code. This is particularly concerning for enterprises and organizations with sensitive repositories. Thank you for catching and documenting this issue thoroughly. The security team should definitely review this behavior. |
Beta Was this translation helpful? Give feedback.
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Question
Body
Steps to reproduce:
Expected Behavior:
The invitation link should only be redeemable by the GitHub account (username/email) that was originally invited. No other account should be able to use the link to gain repository access.
Actual Behavior:
Any user with access to the invitation link (token) is able to accept the invitation—even if they are not the intended recipient.
Impact:
This behavior can lead to unauthorized access to private repositories, violating intended access controls and exposing sensitive code/data.
Beta Was this translation helpful? Give feedback.
All reactions