The Notification You Almost Didn't Question
There is a GitHub notification in your inbox. It looks exactly like every other GitHub notification you have ever received — the same header, the same formatting, the same sender address, the same unsubscribe footer. The subject line says something about an invoice. You almost click it.
I say almost because I know myself well enough now to pause. I check PR notifications in GitHub directly, not through email. I've learned to go to the source. But I learned that because I've been studying how these attacks work — and most people reading this GitHub notification haven't.
What Cisco Talos documented in April 2026 and named Platform-as-a-Proxy is not a new vulnerability in GitHub or Jira or any other platform. It is the deliberate weaponization of how those platforms work. The attacker never sends an email. They make the platform send it for them. And because the email comes from the platform's own infrastructure, it passes every technical security check that exists.
What makes this different: Traditional phishing sends email from a fake domain — noreply@github-security.com. DMARC catches it. PaaP sends email from notifications@github.com — the real address. SPF passes. DKIM passes. DMARC passes. There is no technical grounds for any email gateway to block it. The only thing left to catch it is the human reading it, and the human sees an email that looks exactly like the real thing — because it is the real thing, carrying a fake message.
How It Works — Three Platforms, Three Methods
The PaaP model works on any platform that sends notification emails and allows user-generated content in those notifications. The attacker's job is to find the field where they can inject their message and the feature that triggers the notification. Cisco Talos documented two platforms in detail. I'll add a third that concerns me more than either of them.
notifications@github.com to the target's email. The notification contains the attacker's exact message — invoice language, urgency, a link to a credential harvesting page — wrapped in GitHub's trusted branding and footer. The target sees a real GitHub notification. The attacker never touched their inbox directly.The same mechanism works on Notion (@mention in a page), Figma (@mention in a comment), Trello (@mention in a card), Asana (@mention in a task), Linear (@mention in an issue), and any forum or collaborative platform that sends email notifications for user-generated content. The attacker needs a free account and knowledge of which field triggers the notification. That information is in every platform's help documentation.
The Sender Is Real. The Email Is Real. The Content Is the Attack.
Every email security control we have is built around one question: is this sender who they say they are? SPF checks whether the sending server is authorized. DKIM checks whether the email was cryptographically signed by the domain. DMARC checks whether both of those passed and enforces a policy if they didn't. These are the three pillars of email authentication, and PaaP bypasses all three simultaneously — not by breaking them, but by making them irrelevant.
The sender is authorized. The signing is valid. The policy passes. Because the email actually came from GitHub. The controls worked exactly as designed. They just answered the wrong question.
The question that's not being asked: Is the content inside this legitimate notification legitimate? Email authentication verifies the envelope — who sent it and from where. It says nothing about what's inside. A GitHub notification that contains "Your account has an unpaid invoice — click here to resolve" is technically indistinguishable from a GitHub notification that contains "Someone commented on your PR." Both come from the same address. Both pass the same checks. One is an attack.
The existing Sublime Security rule for GitHub notification abuse (service_abuse_github_excessive_mentions_sus_link.yml) catches the bulk spam version — twenty or more @mentions combined with a suspicious external link. That's the noisy, high-volume campaign. The targeted version uses one or two mentions, legitimate-looking language, and a link to a newly registered domain or a page that passes link analysis at delivery time. The signal has to be in the content — what the notification says, not who sent it.
GitHub never sends billing or invoice notifications from notifications@github.com. Jira customer invites from organizations you've never interacted with are inherently suspicious. The platform behavior is predictable enough that deviations from it are detectable — if you know what normal looks like. Most people, and most email security tools, don't check.
Three Rules and One Caveat
The defense against PaaP is not technical at the platform level. These are features, not vulnerabilities, and the platforms are not going to remove them. The defense is behavioral at the individual level and content-based at the detection layer.
The Slack caveat: The three rules above work for email notifications. They are harder to apply when the message comes from a colleague in Slack. You have worked with this person. You recognize their name. The message feels like a conversation, not a notification. If a colleague sends you a link in Slack asking you to check something — especially something unexpected — verify out of band before clicking. Send them a separate message, or ask them in person. A compromised colleague account is indistinguishable from the real person until you check. That thirty-second verification is the only technical control that works at this layer.
The thing that makes PaaP attacks effective is the same thing that makes the platforms they abuse valuable: they've earned our trust through consistent, legitimate behavior. GitHub notifications are real. Jira invites are real. Slack messages from colleagues are real. The attack works because it borrows that earned trust and uses it to carry something that doesn't belong there.
The sender is real. The email is real. Read the content before you click.
This field note is based on Cisco Talos research "Weaponizing SaaS Notification Pipelines" (April 7, 2026), CyberSecurityNews coverage of the GitHub and Jira PaaP campaigns (April 13, 2026), and Help Net Security reporting on the Talos findings (April 9, 2026). The Slack escalation scenario represents the author's original analytical synthesis connecting PaaP initial access to downstream collaboration platform exploitation. The existing Sublime Security rule referenced (service_abuse_github_excessive_mentions_sus_link.yml) covers the bulk spam variant; targeted PaaP phishing remains a detection gap in the open-source feed. This field note represents independent analytical work based entirely on public information.