GitHub Notifications Abused to Impersonate Y Combinator for Crypto Theft

Campaign Timeline, Lure and Delivery Mechanism

A large-scale phishing campaign abused GitHub’s issue notification system to push tailored invitation lures impersonating Y Combinator’s Winter 2026 (W2026) program and trick developers into signing malicious on-chain attestations that drained wallets.

The campaign unfolded in waves over recent days: attackers created hundreds of issues across multiple repositories, tagged targeted usernames in each issue (which triggers GitHub’s email notifications), and embedded a fraudulent YC application link that led to a wallet-drainer page.

Security reporters observed repositories receiving hundreds of issues from accounts created days earlier, a pattern consistent with automated targeting and scale. For the original reporting and timeline.

The malicious issues used the platform’s legitimate notification flow to reach inboxes—emails that look and feel like real GitHub messages—so many recipients received a trusted notification that directed them to a deceptively similar application page.

Technical Breakdown — How the Drainer Works and Attack Vectors

Abuse of GitHub Notifications and Issue Tagging

When a GitHub issue mentions a username (for example, @alice), GitHub automatically sends an email or web notification to that user according to their notification preferences. Attackers exploited this behavior at scale by programmatically opening issues that list dozens or hundreds of targets; the consequence: real GitHub emails landed in inboxes, increasing click-through rates versus cold emails.

Defenders can detect this pattern with simple telemetry: look for sudden spikes in issue creation from newly created accounts, high issue-to-contributor ratios, or a single actor opening many issues within a short window. A basic SIEM rule example (pseudo-Splunk) to find suspicious issue creation:

index=github_events sourcetype=github_issues action=create
| stats count by actor, repo, actor_account_age_days
| where actor_account_age_days < 7 AND count > 50

Domain Lookalike and JavaScript Drainer Behavior

The malicious landing page mimicked YC but used a visually similar domain where lowercase l replaced the letter i—a classic IDN/homograph and typo-squatting trick. The page served heavily obfuscated JavaScript which requested users to connect their wallet and sign an EIP-712 formatted message (a typed-structured-data signature standard used for safer off-chain signing). Although EIP-712 is legitimate for attestation, the attacker crafted the message to request a signature that authorizes a token transfer or permit, then immediately executed a malicious transaction to drain funds.

Inspecting an EIP-712 sign request in a wallet usually reveals a JSON structure with domain/type/values. A malicious permit will often include spender/amount/nonce fields or strange action text. If you see a signature flow that shows “approve” or “withdraw” semantics in the typed data, treat it as hostile. The EIP-712 spec explains the canonical structure for these signatures and helps defenders parse suspected payloads; see the EIP-712 specification for technical details.

Wallet-Draining Mechanics (What the Signature Actually Does)

There are two common drainer patterns used after the victim signs:

1. Permit/Approve + TransferFrom: The signature serves as an off-chain approval (permit) that lets the attacker call transferFrom() without a separate on-chain approval step.
2. Meta-transaction execution: The signed payload lets the attacker submit a transaction on behalf of the user (or approve a malicious contract) that executes asset transfers, often combined with token swap and routing to mixer addresses.

Defenders and auditors should capture the signed JSON (before the signature) and verify fields: spender address, value, deadline, and the verifyingContract—these reveal whether the signature grants asset-moving privileges.

Victim Profile, Motive and Likely Targeting

Attackers targeted GitHub contributors—developers who are statistically more likely to hold crypto wallets or be responsive to YC invitations. The lure’s social engineering relied on YC’s prestige and the high FOMO around startup funding. The motive is clear: drain wallets or harvest signatures that enable asset transfers, then launder proceeds through mixing services or cross-chain bridges.

This campaign leveraged:

• Trust in platform-originated emails (GitHub headers and layout)
• Social engineering tied to YC’s public application cycle (deadline and funding amount) — the legitimate YC portal is available at Y Combinator’s apply page.
• Technical abuse of off-chain signing standards (EIP-712) to create apparently “safe” interactions that actually grant asset transfer authority.

Comparative Incidents and Trend Context

This campaign fits a growing pattern of developer-focused scams that weaponize trusted platforms:

• Attacks that use GitHub issues or Pages to host or distribute phishing content have recurred in recent years, often because GitHub’s reputation bypasses some email filters. Community warnings and discussions about these scams are visible in GitHub’s own community forums.
• Crypto drainers using EIP-712 or “permit”-style approvals have been used in multiple waves of wallet thefts; prior writeups show how attackers craft typed data to conceal the approval semantics.
• Similar social-engineering campaigns have impersonated accelerators, airdrops, or NFT mints to get victims to sign malicious messages.

Together, these incidents show attackers blending platform abuse, high-trust social engineering, and on-chain signature mechanics to maximize success against technically savvy victims.

Risk Implications — Asset Theft, Identity Risk and Organizational Exposure

Immediate user risk: signature-based draining can empty wallets in minutes. Even if a user doesn’t lose funds immediately, the attacker can harvest signatures for later use. Users who connected hot wallets or reused addresses across services are at higher risk of sustained fraud.
Organizational risk: open-source projects and enterprises that rely on GitHub for coordination may see credential phishing spill into corporate environments—developers who fall for scams can expose company infrastructure, SSH keys, or CI tokens if social-engineers pivot.
Regulatory and reputational risk: impersonation of a reputable institution (Y Combinator) and misuse of a trusted platform (GitHub) can create broader trust and legal challenges for affected organizations.

Remediation Advice — For Developers, Security Teams and Platforms

Immediate Actions for Individuals (Wallet Owners)

1. Revoke approvals and move funds immediately: If you clicked or signed anything, transfer remaining assets to a brand-new wallet using a cold-storage hardware wallet. Revoke token approvals for the compromised wallet via tools such as Etherscan’s Token Approvals or revoke.cash.
2. Check the signed payload: Before signing, always inspect the raw typed data. If you already signed, capture the JSON payload and check for spender/amount fields.
3. Treat GitHub emails carefully: verify the issue in the repository (go to the repo URL directly, not via links in email), and confirm author account age and comment history before interacting.
4. Rotate secrets: If you followed any links that asked for OAuth scopes or GitHub app authorizations, revoke those app tokens and rotate any API keys or CI secrets that could be stored in your environment.
5. Report the incident: Report phishing repositories and accounts to GitHub and the site host; file a report with IC3 or your local cybercrime authority if funds were stolen.

Immediate Actions for Orgs and Security Teams

1. Hunt for suspicious GitHub activity: Query audit logs and webhook activity for spikes in issue creation from new accounts and bulk mentions that correlate with developer inboxes. Example GitHub audit search (GraphQL/REST): request events of type issue where actor.created_at is recent and issue.body contains external domains.
2. Block lookalike domains and phishing hosts: Add the observed domains to web proxies and email gateway blocklists; use DNS RPZ or enterprise URL filtering to prevent access.
3. Push safe-signing guidance: Require developers to use hardware wallets for high-value signing and train teams to inspect EIP-712 payloads (showing what constitutes an approval).
4. Enforce least privilege in CI/CD: Ensure GitHub app scopes and machine account tokens are minimized; rotate CI tokens if a developer is compromised.
5. Enable email DMARC/DKIM/ARC checks: Encourage GitHub users to enable stricter inbox filtering and train employees to validate original repo URLs via the browser.

Platform-Level Recommendations (GitHub, YC and similar providers)

• Rate-limit issue creation for new accounts and flag massive bulk mentions for automated review.
• Enhance automated detection for mass-mention patterns and offer in-email UI warnings (e.g., “This message includes mentions from a very new account—verify before clicking links”). GitHub community security threads already recommend user awareness for this exact pattern.
• Work with registrars and certificate providers to rapidly take down homograph or typo-squatted domains used for credential harvesting.

“This kind of scam targets developers who trust GitHub’s notification system. It exploits the familiar layout of issue creation emails and leverages that implicit trust to bypass inbox skepticism.” — GitHub community security discussion and practitioner analysis.

What To Monitor Next

1. Leak and funds flow: Monitor blockchain addresses linked to the drainer for activity; law enforcement and blockchain analytics firms can trace fund movement into mixers or bridges.
2. Phishing reuse: Attacks that succeed often get reused—expect lookalike lures impersonating other accelerators, airdrops, or high-profile launches.
3. Supply-chain escalation: If developers who fell for the scam pushed code or CI changes, audit recent commits, pipeline runs, and secret exposures.