GitHub Community
Improve notification safety against phishing through user-generated Discussions and mentions #190675
Replies: 2 comments
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
You’ve accurately identified a well-documented threat model known as trusted-channel abuse. While GitHub’s notification emails are cryptographically signed ( GitHub already applies several baseline mitigations:
However, as attackers refine lures (fake CVEs, urgent "patch required" language, off-platform download links), layered defenses are necessary. Here’s how you can mitigate this today and formally push for product changes. 🔒 Immediate MitigationsFor individual users:
For repository/org maintainers:
name: Flag Suspicious Security Mentions
on:
discussion:
types: [created]
issues:
types: [opened]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Detect security lures + external links
uses: actions/github-script@v7
with:
script: |
const body = context.payload.discussion?.body || context.payload.issue?.body || '';
const risky = /(?i)(urgent|cve|critical|patch|security update).{0,120}(https?:\/\/|download|click here|verify account)/;
const number = context.payload.discussion?.number || context.payload.issue?.number;
if (risky.test(body)) {
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: number,
labels: ['⚠️ security-review-needed']
});
}📢 How to Escalate This Product Feedback
GitHub’s security and product teams actively iterate on mention abuse and notification trust. Providing concrete examples (like your screenshot) alongside reproducible abuse patterns will help prioritize UI warnings, sender-context labels, and stricter mass-mention thresholds in upcoming releases. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🏷️ Discussion Type
Product Feedback
💬 Feature/Topic Area
Other
Body
Product safety issue: phishing can be delivered through GitHub’s own notification emails
I want to raise a product-safety issue that can reach users through GitHub’s own notification emails.
The problem is not fake sender headers. These emails really do come from GitHub. The issue is that the content inside them can be controlled by an attacker, because it comes from user-generated Discussions, issues, or comments.
If a malicious account mass-mentions users and posts a fake security or update warning with external links, GitHub can end up sending that content through a trusted notification channel. That is where the real problem is. The email looks legitimate enough that some people may trust it before thinking twice.
GitHub already has abuse-reporting tools, and those matter. But this still leaves a gap: scammers can borrow GitHub’s credibility at the exact moment a user is deciding whether to click.
What I think GitHub should improve
1. Add a clear warning that the email contains user-generated content
Notification emails should make it more obvious that the message was written by another GitHub user, not by GitHub staff and not by the vendor or project being mentioned.
2. Add stronger limits for mass mentions
New or low-trust accounts should not be able to mention large numbers of users freely in Discussions, issues, or comments without more friction. Rate limits, trust checks, or similar controls would help reduce abuse.
3. Warn on suspicious security/update lures with external links
If a post includes urgent security language, fake advisory or CVE-style wording, and off-platform download links, GitHub should show a warning in the web UI. It would also help if that warning carried over into the email notification.
4. Add better safety guidance
GitHub should have a dedicated help page explaining common phishing patterns in notifications, especially fake security/update notices and how users can verify whether something is real before clicking.
Example / evidence
I received one of these as an actual GitHub notification email after being mentioned in a Discussion. I am attaching a screenshot as an example.
To be clear, my point is not that someone spoofed GitHub headers. The message was delivered through GitHub’s normal notification flow. The problem is that attacker-written content was able to ride inside that trusted channel and present a fake urgent security/update lure with an external download link.
That is exactly the trust gap I think GitHub should close.
Why this matters
This is not just spam. It is a trust problem.
If attackers can keep injecting fake security or update messages into GitHub’s notification flow, eventually some users will believe them. That makes the notification system itself part of the attack path, even if the sender is technically legitimate.
GitHub has already made product-level notification changes in other areas to reduce spam and mention abuse, so there is already precedent for this kind of mitigation.
I think this deserves the same kind of attention. GitHub should make it much harder for attackers to use trusted notification emails this way.
Beta Was this translation helpful? Give feedback.
All reactions