The Vercel incident and the phishing campaigns already hiding in plain sight

In April 2026, security teams worldwide were thrown into crisis mode when Vercel — one of the most widely used cloud deployment platforms — disclosed a significant security breach. The incident, stemming from a supply-chain compromise at a third-party vendor, sent security teams scrambling to investigate anything touching Vercel infrastructure.

However, many of those investigations may have uncovered a cybersecurity risk that was entirely separate from the breach itself. Long before the April 2026 incident made headlines, attackers were independently abusing Vercel’s free hosting platform as a key piece of their attack infrastructure, using *.vercel.app subdomains to deliver credential-harvesting phishing campaigns.

In fact, INKY had been detecting and blocking these phishing campaigns since December 2025, months before the Vercel breach was disclosed. Across more than 6,000 blocked emails targeting over 2,000 organizations, three distinct campaign clusters emerged. While the attackers operated independently and used different lures, they shared one notable tactic: hosting credential-harvesting pages on free *.vercel.app subdomains.

This comprehensive report examines all three campaign clusters, breaks down the techniques behind them and clarifies what the Vercel breach and these phishing attacks do — and do not — have in common.

The Vercel security incident: Background

In April 2026, Vercel disclosed a security breach that originated from a supply-chain attack involving Context.ai, a third-party vendor. According to Vercel, a Context.ai employee was infected with Lumma Stealer malware — a widely used infostealer often distributed through malicious software downloads. The malware enabled the attacker to steal Google Workspace OAuth tokens from the employee’s device.

Armed with those tokens, the attacker gained access to Vercel’s internal systems and ultimately reached customer environment variables — configuration secrets stored alongside deployed applications. These variables can contain sensitive information such as API keys, database credentials and third-party service tokens. Vercel later confirmed that the threat actor claimed on BreachForums to have obtained database access keys and portions of source code.

As part of its response, Vercel published a key indicator of compromise (IOC) in the form of an OAuth Application ID and worked alongside Google Mandiant, GitHub, Microsoft, npm and Socket to investigate and contain the incident. The company also stated that no npm packages were compromised during the attack.

Were the phishing campaigns in this report caused by the breach?

No. While both involve Vercel, they are entirely separate threats.

The phishing campaigns analyzed in this report relied on free *.vercel.app subdomains as disposable hosting infrastructure for credential-harvesting pages — functionality available to anyone who creates a Vercel account. The breach, by contrast, involved unauthorized access to Vercel’s internal systems through stolen credentials obtained during a third-party supply-chain compromise.

The overlap is largely one of timing and platform association. Both became prominent in April 2026, and both involved Vercel in some capacity. As a result, security teams investigating suspicious activity related to Vercel may encounter indicators of either threat. The table below clarifies how to distinguish between the two.

Table 1: Distinguishing the Vercel breach from the phishing campaigns in this report

Three clusters, one shared infrastructure

INKY identified three distinct phishing clusters that independently used free *.vercel.app hosting as infrastructure for credential-harvesting attacks. Each cluster differed in delivery method, lure theme and target audience — but all led victims to the same final stage: phishing pages hosted on Vercel’s platform.

Table 2: Side-by-side comparison of the three phishing clusters

Cluster 1: Google AppSheet abuse

The first cluster abused Google AppSheet, Google’s no-code application platform, to deliver phishing emails from legitimate Google infrastructure. By combining trusted email delivery with credential-harvesting pages hosted on Vercel, the attackers created a campaign that bypasses traditional email security controls while appearing highly credible to recipients.

How it works

Google AppSheet is a no-code application platform that lets users build data-driven apps and trigger automated email notifications. When an AppSheet app fires a notification, the email originates from [email protected] — a legitimate Google infrastructure address shared across the entire AppSheet customer base.

Attackers obtained access to one or more AppSheet accounts — likely through credential stuffing attacks or purchases on underground marketplaces — and configured AppSheet to send phishing notifications at scale. Every email was delivered through Google’s own infrastructure and signed with Google’s DKIM key.

Why authentication fails as a signal: Since the emails genuinely originate from Google infrastructure, SPF, DKIM and DMARC all pass successfully for appsheet.com. There is no spoofing involved. As a result, traditional authentication-based email security controls have little reason to flag the messages as suspicious.

The lure: Facebook Business account suspension

Each email impersonates a Facebook Business notification, warning recipients that their business account is under review for policy violations and will be disabled unless immediate action is taken. The call-to-action directs users to a newly created *.vercel.app subdomain hosting a credential-harvesting page.

To further evade detection, the attackers inserted zero-width hair space characters (U+200A) between letters in the display name. What appears visually as “Facebook Business” is actually rendered as “Fa cebook Bu si ness” at the byte level. This simple obfuscation technique breaks exact-match display name detection rules while remaining invisible to the recipient.

Subject line pattern

Subjects follow the same business name + random alphanumeric ID format seen in the broader AppSheet campaign:

• Valley Cooling & Refrigeration Co. ZV195545707372SGVP
• Westside Eye Center RRPU020121773OTD
• Riverside Charter Academy BE937622771FEE

The random ID ensures that no two emails share the same subject, defeating signature-based subject filters across the entire campaign.

Sample email headers

Table 3: Sample email headers of the AppSheet/Vercel.app campaign

Fig 1: Daily email volume for AppSheet/Vercel.app campaign (April 5 – May 4, 2026). The Vercel breach disclosure on April 19 is marked. Campaign activity predates disclosure, confirming no causal link.

Fig 2: AppSheet/Vercel.app phishing email rendered in an email client: the display name shows Facebook Business constructed using zero-width characters invisible to the recipient; Reply-To routes back to [email protected]

Fig 3: INKY detection reasons: all 6,283 emails flagged as “Phishing Content”; 5,283 were additionally flagged as “Potential Sender Forgery,” indicating that INKY identified a mismatch between the displayed sender identity and AppSheet infrastructure

Cluster B: Compromised Microsoft 365 accounts — targeting construction industry

The second cluster took a different approach. Instead of abusing a legitimate platform to send emails, the attackers leveraged compromised Microsoft 365 accounts belonging to real businesses in the construction sector. By combining trusted sender identities, industry-specific lures and Vercel-hosted phishing pages, the campaign was designed to blend seamlessly into routine business communications.

How it works

This cluster uses legitimate, compromised Microsoft 365 accounts at real companies to send phishing emails. Both identified accounts belonged to businesses in the construction and trades sector, suggesting deliberate targeting of an industry where bid invitations from unfamiliar contacts are common and often expected.

Since the emails originate from genuine, active Microsoft 365 accounts with properly configured authentication, they achieve SPF, DKIM and DMARC alignment naturally. This is not a bypass technique — the messages pass authentication because the sending accounts are legitimately authorized to send email on behalf of their organizations.

The lure: Construction bid invitation with a password-protected PDF

Each email presents itself as a formal invitation to bid on a construction project, appearing to come from a real employee at a legitimate company. The message describes a bid package and provides a password to open the attached PDF, positioning the password as a security measure intended to protect sensitive project information.

Once opened with the provided password, the PDF displays a single page designed to resemble a Microsoft OneDrive document-sharing notification. The page claims that project files have been shared with the recipient and prompts them to click a “View Documents in OneDrive” button. That button directs the victim to melody-swgd-com.vercel.app, where a credential-harvesting page awaits.

Why password-protected PDFs defeat scanning: Many email security tools cannot inspect password-encrypted PDF attachments without access to the decryption key. By placing the phishing lure inside the encrypted PDF and including the password only within the email body, the attacker effectively separates the content from the attachment. Automated scanners encounter an unreadable file, while the recipient can easily open it and view the malicious content.

Shared infrastructure points to a single threat actor

Both compromised accounts — belonging to different companies in different U.S. states — sent emails that directed recipients to the same Vercel-hosted phishing page: melody-swgd-com.vercel.app. The reuse of identical infrastructure strongly suggests that a single threat actor compromised both accounts and operated them in parallel, using a centralized credential-harvesting site to support the campaign.

Researchers also identified a secondary URL embedded within one PDF’s link annotations: biddingsth.github.io/bidders/. This indicates the actor was using GitHub Pages as an additional hosting option, likely as a backup or alternative payload delivery mechanism alongside Vercel.

Sample email profile

Table 4: Sample email profile of Microsoft 365/Vercel phishing campaign

Fig 4: Cluster B phishing email: construction bid invitation from a compromised Microsoft 365 account

Fig 5: PDF payload after decryption with the password provided in the email body: fake Microsoft OneDrive document share with a CTA “View Documents In OneDrive” that links to melody-swgd-com.vercel.app

Fig 6: Cluster B email volume: two compromised Microsoft 365 accounts sent 26 emails across 9 organizations over just 2 days (May 13-14, 2026)

Fig 7: INKY detection reasons: Protected File flagged across all 26 emails; Phishing Site detected in the carpetplanet.net sender, indicating INKY identified the vercel.app payload URL as a known phishing host

Cluster C: Attacker-owned domain — government tax agency impersonation

The third cluster demonstrates that attackers do not always need to compromise accounts or abuse legitimate platforms to launch effective phishing campaigns. Instead, this actor built their own infrastructure from the ground up, using an attacker-controlled domain for email delivery and Vercel-hosted phishing pages to harvest credentials.

How it works

Unlike Clusters A and B, this actor does not exploit a legitimate platform or use a hijacked account. Instead, they registered and configured their own sending domain, complete with SPF, DKIM and DMARC records, to distribute phishing emails impersonating the Canada Revenue Agency (CRA).

The sender name appears as “Canada Revenue Agency (CRA),” while the actual sending domain is an attacker-controlled domain with no affiliation to the Canadian government. Since the domain is properly configured for email authentication, the messages generate clean SPF, DKIM and DMARC passes despite being malicious.

The lure: T4 tax slip notification

The email claims that a T4 slip — a Canadian employment income statement — is ready for download. Timed around tax season, the lure is highly relevant and credible for Canadian businesses and employees who routinely expect tax-related communications.

Attached to the email is a PDF named using the format “2025 T4SLIP [reference number].pdf.” While the file is not encrypted, it serves as a stepping stone to the phishing site rather than containing the final payload itself.

When opened, the PDF displays a single page that resembles a secure document portal. It provides a password (“2026”) and instructs the recipient to follow a link to access their tax document. That link directs users to a newly created Vercel-hosted phishing page at t4slip[reference].vercel.app, where the credential-harvesting process begins.

Sample email profile

Table 5: Cluster C sample phishing email profile (attacker-owned domain)

Fig 8: Cluster C phishing email impersonating the Canada Revenue Agency, sent from an attacker-registered domain with full SPF/DKIM/DMARC pass

Fig 9: Cluster C PDF payload — fake Microsoft Teams secure file sharing page with vercel.app credential-harvesting link

Fig 10: INKY detection reasons for Cluster C. All 4 emails triggered every reason simultaneously. Misleading Reply-To indicates INKY detected that the reply-to address diverged from the sender domain — a common signal in government impersonation phishing

MITRE ATT&CK-Zuordnung 

The three clusters share a common core of techniques and diverge in their initial access and delivery methods.

Table 6: MITRE ATT&CK technique mapping across all three clusters

All three clusters converge on T1608.001 (Stage Capabilities: Upload Malware) — using Vercel’s free hosting tier as disposable credential-harvesting infrastructure. This convergence across independently operating threat actors suggests that vercel.app has become a widely recognized commodity in the phishing ecosystem: freely available, instantly deployable, TLS-validated and hosted on a domain with a strong reputation.

Why traditional protections fail

At first glance, these three campaigns appear very different. One abuses Google infrastructure, another leverages compromised Microsoft 365 accounts and a third uses attacker-controlled domains. Yet all three successfully bypass many of the controls organizations traditionally rely on to identify phishing emails. The common thread is that they exploit trust in authenticated senders, reputable platforms and familiar business workflows.

• Valid SPF, DKIM and DMARC across all three clusters: Each delivery method produces clean authentication results. Cluster A passes because the email genuinely originates from Google infrastructure. Cluster B passes because the sender is a legitimate, active Microsoft 365 account. Cluster C passes because the attacker correctly configured email authentication on their own domain. In all three cases, authentication validates the sender’s infrastructure, not the sender’s intent.
• Trusted sender reputation: The AppSheet campaign benefits from the strong reputation of [email protected], which routinely sends legitimate notifications on Google’s behalf. The compromised Microsoft 365 accounts inherit the reputation of the organizations they belong to. As a result, reputation-based filtering provides little protection against these attacks.
• Payloads hosted on a trusted platform: All three clusters direct victims to phishing pages hosted on *.vercel.app subdomains. Since Vercel is a legitimate and widely used developer platform, some security controls may apply less scrutiny to its subdomains. The phishing pages are also served over HTTPS using valid certificates, further reinforcing the appearance of legitimacy.
• Encrypted attachments limit visibility: In Cluster B, the phishing link is embedded within a password-protected PDF attachment. Without the decryption key, automated scanning tools cannot inspect the contents of the file. If the security solution does not also analyze the surrounding email context, the phishing payload remains hidden from inspection.
• Display name obfuscation breaks name-match rules: In Cluster A, attackers inserted zero-width characters into the “Facebook Business” display name. Although invisible to recipients, these characters alter the underlying text enough to break exact-match and substring-based detection rules, allowing the phishing email to evade simplistic filtering techniques.

How INKY caught them

INKY’s behavioral and generative AI analysis evaluated the full context of each email rather than relying on any single signal:

Cluster A: The combination of a known legitimate platform sender (AppSheet) with newly created, previously unseen *.vercel.app payload domains was flagged as anomalous. INKY identified the mismatch between the purported sender identity (a business notification) and the actual sending infrastructure, and detected phishing content within the email body despite the clean authentication results.

Cluster B: INKY’s generative AI read through the password-protected PDF attachment — using the password provided in the email body — and identified the credential-harvesting lure inside. The combination of a construction bid invitation subject with a fake OneDrive payload behind an encrypted PDF was classified as phishing content.

Cluster C: The mismatch between the Canada Revenue Agency display name and a non-government sending domain, combined with the *.vercel.app link inside the PDF attachment, was flagged as phishing content with a misleading sender identity.

Table 7: INKY detection reasons by cluster

Table 8: Indicators of compromise (IOCs) associated with all three phishing clusters

Bewährte Verfahren: Leitlinien und Empfehlungen

The three phishing clusters examined in this report use different tactics, but they share a common goal: exploiting trusted infrastructure and familiar business workflows to steal credentials. The recommendations below can help security teams and end users reduce their exposure to these attacks and identify suspicious activity before credentials are compromised.

For security teams

• Enforce Multifactor authentication (MFA) on all Microsoft 365 and Google Workspace accounts.

Cluster B demonstrates that compromised accounts with valid authentication are among the hardest attacks to detect at the email layer. MFA prevents account takeover even when credentials are stolen or purchased from underground markets. Phishing-resistant MFA (FIDO2/passkeys) provides the strongest protection against credential-harvesting attacks.

Emails where the To field is blank or shows the sender’s own address, combined with unusual sending patterns (bulk outbound, new recipient domains), may indicate an account takeover. Enforce MFA across all Microsoft 365 and Google Workspace accounts.

• Audit Microsoft 365 accounts for post-compromise indicators.

After account takeover, attackers commonly create inbox forwarding rules, send bulk email to unknown recipient domains and sign in from unfamiliar locations. Review Microsoft 365 audit logs for these patterns, particularly for accounts in industries that regularly exchange documents with external contacts — construction, logistics, financial services — which are prime targets for the bid invitation lure in Cluster B.

• Apply behavioral context to emails from trusted SaaS platforms.

Authentication results alone cannot flag platform abuse. An email from a legitimate Google, Zoom, DocuSign or AppSheet sender that links to a newly registered or free-tier hosting subdomain is a high-confidence anomaly regardless of whether SPF, DKIM and DMARC pass. Email security tools that evaluate full message context — sender platform, link destination age, subject pattern and sender-identity mismatch — provide detection that rules-based systems cannot.

• Treat *.vercel.app and *.netlify.app links from unknown senders with elevated suspicion.

Legitimate product communications rarely link to free developer hosting subdomains. Flag these for additional scrutiny regardless of sending domain reputation. Also, report abused Vercel deployments. Vercel accepts abuse reports at [email protected]. Including the full *.vercel.app URL ensures the rapid takedown of the credential-harvesting page.

If your organization uses Vercel, check Google Workspace audit logs for the breach IOC. Search for OAuth Application ID (110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) to determine whether any users authorized the compromised application.

For email recipients

• Always inspect the actual sending address, not just the display name.

A display name can be set to anything — “Canada Revenue Agency (CRA),” “Facebook Business,” or “Microsoft OneDrive” — regardless of who is actually sending the email. The real sender address is shown next to or below the display name in every major mail client. Legitimate government agencies in Canada send from gc.ca domains (the CRA uses cra-arc.gc.ca). Facebook sends notification emails from facebookmail.com. Any message claiming to be from these organizations but arriving from an unrelated commercial domain should be treated as suspicious before anything else.

• Check the link destination before clicking.

Hover over a link on desktop or long-press on mobile to see the actual URL before following it. A button labelled “View Documents in OneDrive” or “Open PDF File” that resolves to a *.vercel.app, *.netlify.app or GitHub Pages subdomain is not a Microsoft or government service. Legitimate platforms host their own login and document pages on their own domains.

• Treat a password-protected attachment whose password is in the same email as a red flag.

If an attachment is encrypted for your protection, the sender would not include the password in the same message. When a password is provided in the email body, the encryption exists solely to prevent automated security tools from scanning the attachment — not to protect you. Open such attachments only if you are certain of the sender’s identity through an independent verification.

• Verify unexpected requests through official channels, not links or phone numbers in the email.

If you receive an unsolicited bid invitation, tax notice or account suspension warning you were not expecting, go directly to the organization’s official website by typing the address yourself or call them using a number from that website. Do not use contact details, links or phone numbers provided in the email — these can lead directly to the attacker.

• Free developer hosting subdomains are not legitimate business infrastructure.

Established organizations — government agencies, banks, large enterprises — do not host official documents, login pages or tax forms on free developer platforms such as vercel.app or netlify.app. If a link or PDF directs you to a subdomain on one of these platforms in the context of a tax notice, invoice or account alert, the email is almost certainly a phishing attempt.

• Be especially cautious with construction and trade industry bid invitations.

Attackers in Cluster B specifically targeted subcontractors and suppliers who routinely receive bid invitations from unfamiliar contacts. If you work in construction, facilities or a related trade, verify any new bid invitation by calling the general contractor directly before opening attachments or entering credentials.

Abschließende Überlegungen

The Vercel security incident brought widespread attention to Vercel’s platform in April 2026. What investigators searching for Vercel-related threats may have found in their email security queues are these three phishing clusters — campaigns that had been running for months, all independently choosing Vercel’s free hosting tier as disposable credential-harvesting infrastructure.

The convergence is not coincidental. *.vercel.app offers everything a phishing operator needs from a payload host: instant deployment, no identity verification, valid TLS certificates, high domain reputation and trivial rotation when a subdomain is taken down. Until free hosting platforms implement stronger abuse controls, they will remain an attractive infrastructure for phishing campaigns across the threat landscape.

The deeper lesson is about authentication. All three clusters pass SPF, DKIM and DMARC. All three use real or legitimate-looking sending infrastructure. The signals that matter — behavioral anomalies, payload context, the full chain from sender to link to page — require analysis that goes beyond header inspection. That is where behavioral and AI-riven email security provides detection that rules-based systems miss.