iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
📝

My Experience and Response to the Vercel Security Incident

に公開
Vercel
Security
インシデント対応
tech

What Happened

On April 19, 2026, Vercel officially announced a security incident.
The incident involved "unauthorized access to specific internal Vercel systems."

However, the cause was not Vercel itself, but rather a third-party AI tool's Google Workspace OAuth app being compromised.
Access to Vercel's internal systems was gained through that tool.

It is reported that the number of potentially affected users is in the hundreds.

What is an "OAuth App Compromise" Anyway?

For those who are not familiar with security, here is a quick supplement.

You might often use tools by clicking buttons like "Login with Google" or "Link with GitHub." That is OAuth integration. You are granting the tool "permission to use your Google account information."

The issue this time was that a certain AI tool was in a position to access Vercel's internal systems using that permission. Because the AI tool itself was taken over by attackers, unauthorized access to Vercel occurred as a chain reaction.

In short, the flow was as follows:

Attacker
  ↓
Compromises a third-party AI tool
  ↓
Exploits that tool's Google OAuth permissions
  ↓
Accesses Vercel's internal systems
  ↓
Environmental variables of some users at risk of being leaked

You didn't do anything wrong directly. It was a form of indirect damage caused by a tool you trusted being compromised. This is what makes this incident scary; it's the type of attack that cannot be prevented just by having a "strong password."

What Was Leaked?

According to Vercel's announcement, environment variables that were not marked as sensitive were at risk of being leaked.

Environment variables are secret information required for an application to run, such as API keys and database passwords. Vercel has a feature to mark them as "Sensitive," which stores them in an unreadable format. Conversely, variables without this sensitive mark could potentially have been read.

Verification Steps I Took

1. Check for Compromised Apps in My Google Account

Using the OAuth App IDs from the IOC (Indicators of Compromise) published by Vercel, I checked myaccount.google.com/permissions to see if any corresponding apps were connected.
→ Not found in my account.

2. Review Vercel Activity Logs

I checked the Dashboard → Projects → Activity tab for any suspicious operations.
I looked for environment variable changes, deployments at unfamiliar times, and addition of new members.
→ No abnormalities found.

3. Check Emails

Vercel announced that they would "directly contact users who were directly affected."
→ I did not receive any such notification.

Measures Taken Just in Case (Key Rotation)

Although I could not confirm any direct damage, I identified all environment variables that should be treated as secret information and rotated every one of them as a precaution.

Additionally, I cleaned up and deleted unnecessary environment variables that were left on Vercel.

After the updates, I redeployed on Vercel to reflect the changes.

Lessons Learned

Even if you are "not affected," you should still update your keys

The investigation is still ongoing, and the scope of the impact could expand.
Vercel's bulletin stated, "Assume environment variables not marked as sensitive have been leaked and rotate them."

Here is what I realized after actually performing the work:

  • There were unused variables remaining in my environment variables (I deleted them this time).
  • I didn't properly understand the meaning of the NEXT_PUBLIC_ prefix (since these values are exposed to the browser, they should not contain sensitive information).
  • Knowing the key rotation procedure in advance prevents panic during emergencies.

Auditing OAuth apps is also important

The compromise path this time was the OAuth integration of a third-party AI tool.
You should regularly remove access for unnecessary apps at myaccount.google.com/permissions.

It has become common to use OAuth integration with convenient tools, but it is surprisingly common to leave permissions for unused tools sitting there. Use this incident as a trigger to audit them.

References

Discussion