Vercel security breach explained: How a third-party AI tool exposed internal systems and what it means for developers
Vercel , a cloud development platform, recently confirmed that someone gained unauthorised access to some of its internal systems. This has led to an active investigation involving top cybersecurity firms, law enforcement, and other companies in the same field. The breach, which the company disclosed through a formal Security Bulletin, originated not from a direct attack on Vercel’s own infrastructure but from a compromise of a third-party AI tool used by one of its employees.
Vercel is a cloud platform built for frontend developers, specialising in the hosting of websites and web apps. The company, which is valued at over one billion dollars, serves a wide global customer base of developers and organisations that rely on its infrastructure to deploy and run production apps. The security incident has raised pointed questions about the risks posed by third-party software integrations in enterprise environments, particularly as AI tools become more embedded in daily workflows.
“We’ve identified a security incident that involved unauthorized access to certain internal Vercel systems,” the company said in its bulletin. “We are actively investigating, and we have engaged incident response experts to help investigate and remediate. We have notified law enforcement and will update this page as the investigation progresses.”
Where the cyberattack began
The incident did not begin inside Vercel. According to the company’s investigation, the incident originated with a compromise of Context.ai, a third-party AI tool that a Vercel employee had been using. The attacker leveraged that initial foothold to take over the employee’s Vercel Google Workspace account. From there, the attacker gained access to some Vercel environments and environment variables that had not been marked as “sensitive.”
The distinction between sensitive and non-sensitive environment variables is central to understanding the scope of what was accessed. In Vercel’s system, environment variables marked as sensitive are stored so they cannot be read back in plaintext. The company said it has no evidence at this time that those protected values were accessed.
“Environment variables marked as ‘sensitive’ in Vercel are stored in a manner that prevents them from being read, and we currently do not have evidence that those values were accessed,” Vercel confirmed in its bulletin.
This is a classic example of how a series of connected access points can be used one after the other. The attacker used compromised AI tools to access the Google Workspace account of one of their employees, then gained access to Vercel's environments. According to Vercel, the hacker is “a highly sophisticated one due to their speed of operation and in-depth knowledge about Vercel’s infrastructure.” Guillermo Rauch, CEO of Vercel, explained this in a blog post on X (formerly Twitter).
“We assess the attacker as highly sophisticated based on their operational velocity and detailed understanding of Vercel’s systems,” the bulletin states.
What Vercel CEO Guillermo Rauch said
Rauch discussed the event publicly, providing a firsthand account of what happened and the actions being taken in response.
“A Vercel employee got compromised via the breach of an AI platform customer called Context.ai that he was using. The details are being fully investigated. Through a series of manoeuvres that escalated from our colleague’s compromised Vercel Google Workspace account, the attacker got further access to Vercel environments,” Rauch wrote on X.
He continued: “Vercel stores all customer environment variables fully encrypted at rest. We have numerous defence-in-depth mechanisms to protect core systems and customer data. We do have a capability, however, to designate environment variables as ‘non-sensitive’. Unfortunately, the attacker got further access through their enumeration.”
Rauch also pointed to the threat actor's nature, suggesting the group was assisted by artificial intelligence. “We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel.”
He noted that the number of customers believed to be directly affected remained limited at the time of writing. “At the moment, we believe the number of customers with a security impact to be quite limited. We’ve reached out with utmost priority to the ones we have concerns about.”
Rauch addressed the supply chain directly, confirming that Vercel’s open-source projects had been reviewed. “We’ve analysed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe for our community.”
His statement closed with a commitment to transparency and continued improvement: “It’s my mission to turn this attack into the most formidable security response imaginable. It’s always been a top priority for me. Vercel employs some of the most dedicated security researchers and security-minded engineers in the world. I commit to keeping you updated and rolling out extensive improvements and defences so you, our customers and community can have the peace of mind that Vercel always has your back.”
In a follow-up reply to his own post, Rauch addressed a specific misconception circulating among users. “One misconception we’ve seen that I need to call out. Deletion (e.g.: of an env var, project, account) does not imply Rotation. Rotating keys means invalidating the previous value with the vendor/service you’re using, and getting a new one. Do that. i.e.: if you only delete the resource on the Vercel side, the associated key can ‘live on’ with the other provider, and be mis-used.”
Who is impacted and what Vercel has told its customers
Vercel has said that it has identified a limited subset of customers whose Vercel credentials were compromised in the incident. Specifically, the company identified a limited subset of customers whose non-sensitive environment variables stored on Vercel, meaning those that decrypt to plaintext, were compromised. The company has reached out to that subset directly and recommended an immediate rotation of credentials. For customers who have not been contacted, the company offered reassurance, though it stopped short of declaring the matter closed.
“If you have not been contacted, we do not have reason to believe that your Vercel credentials or personal data have been compromised at this time,” the bulletin states. “We continue to investigate whether and what data was exfiltrated and we will contact customers if we discover further evidence of compromise. We’ve deployed extensive protection measures and monitoring. Our services remain operational.”
The bulletin also carries a caution that has practical implications for users who might consider deleting their Vercel projects or accounts as a quick fix. According to Vercel’s guidance, deleting a project or account is not sufficient to eliminate the risk. Compromised secrets may still provide access to production systems via third-party services, so the keys themselves need to be invalidated directly with the providers that issued them.
The npm supply chain question
One area of concern that emerged during the incident was whether any npm packages published by Vercel had been tampered with. Vercel addressed this in its bulletin, confirming that it had conducted a review in collaboration with GitHub, Microsoft, npm, and Socket.
“In collaboration with GitHub, Microsoft, npm, and Socket, our security team has confirmed that no npm packages published by Vercel have been compromised. There is no evidence of tampering, and we believe the supply chain remains safe,” the bulletin states.
This is a relevant point for the wider developer community, as Vercel maintains several widely used open-source packages and frameworks. The confirmation that the supply chain has not been affected is intended to reassure developers who rely on those packages in their own apps.
Signs of possible breach shared with the wider community
Vercel published an indicator of compromise in its bulletin, making it available to Google Workspace administrators and users at other organisations to check whether the same OAuth app used in the attack had been authorised in their environments.
The bulletin explains that the incident originated from what it describes as a small, third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, one that potentially affected hundreds of users across many organisations.
The OAuth app identifier published by Vercel is: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Vercel recommended that Google Workspace administrators and account owners check for usage of this app immediately.
Brendan Falk, founder and CEO of Hercules.app, provided a practical walkthrough for users who wanted to check their own environments on X. “To check if your Google Workspace has been compromised by the same tool that compromised Vercel: 1. Go to https://admin.google.com/ac/owl/list?tab=apps – This is Google Admin Console > Security > Access and Data Control > API Controls > Manage app access > Accessed Apps. 2. Filter by ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com – This is the ID of the compromised OAuth app. If you see an app after filtering, you have potentially been compromised.”
Falk added further advice in a follow-up reply: “Also a good time to remove apps you aren’t using or reduce permissions for apps that don’t need them.”
What impacted customers are being told to do
Vercel has published recommendations for customers who may be affected. The guidance covers several areas, from reviewing account activity to ensuring that environment variables containing sensitive credentials are properly protected going forward.
Regarding environment variables, the company has recommended that customers review and rotate any that were not marked as sensitive. This includes API keys, tokens, database credentials, and signing keys, all of which should be treated as potentially exposed and rotated as a priority. Customers are also advised to take advantage of the sensitive environment variables feature going forward, to ensure that secret values are protected from being read in future.
Vercel has also recommended that customers review activity logs for their accounts and environments, looking for any suspicious activity. These logs can be accessed through the dashboard or via the command-line interface. Customers are being asked to investigate recent deployments for anything unexpected or suspicious and to delete any deployments that appear questionable.
Additionally, Vercel has advised that Deployment Protection be set to Standard at a minimum and that Deployment Protection tokens be rotated if they have been configured.
Regarding account-level security, Vercel encourages users to enable multi-factor authentication, configure an authenticator app, and create a passkey to add an additional layer of protection.
Product changes being rolled out in response
Vercel said its teams have been actively shipping product updates in response to the incident. Several changes have already been deployed, with more in progress.
Among the enhancements already rolled out, environment variable creation now defaults to sensitive on. The company has also improved team-wide management of environment variables and made the activity log easier to use, including deep-linking to filtered views and a higher information density. Clearer team-invite emails have also been sent.
Rauch confirmed some of these changes in his post on X, noting that new capabilities had already been rolled out in the dashboard, including an overview page for environment variables and a revised user interface for creating and managing sensitive environment variables.
The investigators who were involved
Vercel has brought in several external parties to assist with the investigation and response. The company said it is working with Mandiant , additional cybersecurity firms, industry peers, and law enforcement. It has also engaged Context.ai directly to understand the full scope of the underlying compromise.
“We are working with Mandiant, additional cybersecurity firms, industry peers, and law enforcement. We have also engaged Context.ai directly to understand the full scope of the underlying compromise,” the bulletin states.
Rauch specifically acknowledged the role of Google’s Mandiant team. “I also want to thank the Google Mandiant team for their active engagement and assistance,” he wrote.
The investigation is still going on. Since the incident was first reported, the bulletin has been updated several times. Entries on April 19 and 20 added new information about the attack's origin, updated recommendations, product improvements, and advice on using multi-factor authentication. As the investigation goes on, Vercel has said it will keep updating the bulletin.
A broader lesson about third-party AI tool risk
The Vercel incident draws attention to a risk that many organisations may not have fully reckoned with. As AI tools become embedded in everyday professional workflows, the OAuth integrations they require often grant significant access to corporate accounts. A compromise at the tool level can directly compromise the accounts it has been granted access to, as was the case here.
The indicator of compromise that Vercel has shared suggests the impact of the underlying Context.ai breach extends beyond Vercel, potentially reaching hundreds of users at many organisations. Google Workspace administrators at any organisation whose employees use third-party AI tools integrated through OAuth should consider this incident a prompt to audit which apps have been granted access and to revoke those that are no longer in active use or that carry permissions broader than necessary.
For Vercel specifically, the company has framed its response as an effort to turn the incident into a basis for comprehensive security improvements across its platform. Whether the scope of the breach expands or contracts as the investigation continues, the steps the company is taking, including public disclosure, active engagement with law enforcement and outside investigators, and rapid product changes, represent the kind of response that security professionals generally recommend when an incident of this nature occurs.
Vercel is a cloud platform built for frontend developers, specialising in the hosting of websites and web apps. The company, which is valued at over one billion dollars, serves a wide global customer base of developers and organisations that rely on its infrastructure to deploy and run production apps. The security incident has raised pointed questions about the risks posed by third-party software integrations in enterprise environments, particularly as AI tools become more embedded in daily workflows.
“We’ve identified a security incident that involved unauthorized access to certain internal Vercel systems,” the company said in its bulletin. “We are actively investigating, and we have engaged incident response experts to help investigate and remediate. We have notified law enforcement and will update this page as the investigation progresses.”
Where the cyberattack began
The incident did not begin inside Vercel. According to the company’s investigation, the incident originated with a compromise of Context.ai, a third-party AI tool that a Vercel employee had been using. The attacker leveraged that initial foothold to take over the employee’s Vercel Google Workspace account. From there, the attacker gained access to some Vercel environments and environment variables that had not been marked as “sensitive.”
The distinction between sensitive and non-sensitive environment variables is central to understanding the scope of what was accessed. In Vercel’s system, environment variables marked as sensitive are stored so they cannot be read back in plaintext. The company said it has no evidence at this time that those protected values were accessed.
“Environment variables marked as ‘sensitive’ in Vercel are stored in a manner that prevents them from being read, and we currently do not have evidence that those values were accessed,” Vercel confirmed in its bulletin.
This is a classic example of how a series of connected access points can be used one after the other. The attacker used compromised AI tools to access the Google Workspace account of one of their employees, then gained access to Vercel's environments. According to Vercel, the hacker is “a highly sophisticated one due to their speed of operation and in-depth knowledge about Vercel’s infrastructure.” Guillermo Rauch, CEO of Vercel, explained this in a blog post on X (formerly Twitter).
“We assess the attacker as highly sophisticated based on their operational velocity and detailed understanding of Vercel’s systems,” the bulletin states.
What Vercel CEO Guillermo Rauch said
Rauch discussed the event publicly, providing a firsthand account of what happened and the actions being taken in response.
“A Vercel employee got compromised via the breach of an AI platform customer called Context.ai that he was using. The details are being fully investigated. Through a series of manoeuvres that escalated from our colleague’s compromised Vercel Google Workspace account, the attacker got further access to Vercel environments,” Rauch wrote on X.
He continued: “Vercel stores all customer environment variables fully encrypted at rest. We have numerous defence-in-depth mechanisms to protect core systems and customer data. We do have a capability, however, to designate environment variables as ‘non-sensitive’. Unfortunately, the attacker got further access through their enumeration.”
Rauch also pointed to the threat actor's nature, suggesting the group was assisted by artificial intelligence. “We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel.”
He noted that the number of customers believed to be directly affected remained limited at the time of writing. “At the moment, we believe the number of customers with a security impact to be quite limited. We’ve reached out with utmost priority to the ones we have concerns about.”
Rauch addressed the supply chain directly, confirming that Vercel’s open-source projects had been reviewed. “We’ve analysed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe for our community.”
His statement closed with a commitment to transparency and continued improvement: “It’s my mission to turn this attack into the most formidable security response imaginable. It’s always been a top priority for me. Vercel employs some of the most dedicated security researchers and security-minded engineers in the world. I commit to keeping you updated and rolling out extensive improvements and defences so you, our customers and community can have the peace of mind that Vercel always has your back.”
In a follow-up reply to his own post, Rauch addressed a specific misconception circulating among users. “One misconception we’ve seen that I need to call out. Deletion (e.g.: of an env var, project, account) does not imply Rotation. Rotating keys means invalidating the previous value with the vendor/service you’re using, and getting a new one. Do that. i.e.: if you only delete the resource on the Vercel side, the associated key can ‘live on’ with the other provider, and be mis-used.”
Who is impacted and what Vercel has told its customers
Vercel has said that it has identified a limited subset of customers whose Vercel credentials were compromised in the incident. Specifically, the company identified a limited subset of customers whose non-sensitive environment variables stored on Vercel, meaning those that decrypt to plaintext, were compromised. The company has reached out to that subset directly and recommended an immediate rotation of credentials. For customers who have not been contacted, the company offered reassurance, though it stopped short of declaring the matter closed.
“If you have not been contacted, we do not have reason to believe that your Vercel credentials or personal data have been compromised at this time,” the bulletin states. “We continue to investigate whether and what data was exfiltrated and we will contact customers if we discover further evidence of compromise. We’ve deployed extensive protection measures and monitoring. Our services remain operational.”
The bulletin also carries a caution that has practical implications for users who might consider deleting their Vercel projects or accounts as a quick fix. According to Vercel’s guidance, deleting a project or account is not sufficient to eliminate the risk. Compromised secrets may still provide access to production systems via third-party services, so the keys themselves need to be invalidated directly with the providers that issued them.
The npm supply chain question
One area of concern that emerged during the incident was whether any npm packages published by Vercel had been tampered with. Vercel addressed this in its bulletin, confirming that it had conducted a review in collaboration with GitHub, Microsoft, npm, and Socket.
“In collaboration with GitHub, Microsoft, npm, and Socket, our security team has confirmed that no npm packages published by Vercel have been compromised. There is no evidence of tampering, and we believe the supply chain remains safe,” the bulletin states.
This is a relevant point for the wider developer community, as Vercel maintains several widely used open-source packages and frameworks. The confirmation that the supply chain has not been affected is intended to reassure developers who rely on those packages in their own apps.
Signs of possible breach shared with the wider community
Vercel published an indicator of compromise in its bulletin, making it available to Google Workspace administrators and users at other organisations to check whether the same OAuth app used in the attack had been authorised in their environments.
The bulletin explains that the incident originated from what it describes as a small, third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, one that potentially affected hundreds of users across many organisations.
The OAuth app identifier published by Vercel is: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Vercel recommended that Google Workspace administrators and account owners check for usage of this app immediately.
Brendan Falk, founder and CEO of Hercules.app, provided a practical walkthrough for users who wanted to check their own environments on X. “To check if your Google Workspace has been compromised by the same tool that compromised Vercel: 1. Go to https://admin.google.com/ac/owl/list?tab=apps – This is Google Admin Console > Security > Access and Data Control > API Controls > Manage app access > Accessed Apps. 2. Filter by ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com – This is the ID of the compromised OAuth app. If you see an app after filtering, you have potentially been compromised.”
Falk added further advice in a follow-up reply: “Also a good time to remove apps you aren’t using or reduce permissions for apps that don’t need them.”
What impacted customers are being told to do
Vercel has published recommendations for customers who may be affected. The guidance covers several areas, from reviewing account activity to ensuring that environment variables containing sensitive credentials are properly protected going forward.
Regarding environment variables, the company has recommended that customers review and rotate any that were not marked as sensitive. This includes API keys, tokens, database credentials, and signing keys, all of which should be treated as potentially exposed and rotated as a priority. Customers are also advised to take advantage of the sensitive environment variables feature going forward, to ensure that secret values are protected from being read in future.
Vercel has also recommended that customers review activity logs for their accounts and environments, looking for any suspicious activity. These logs can be accessed through the dashboard or via the command-line interface. Customers are being asked to investigate recent deployments for anything unexpected or suspicious and to delete any deployments that appear questionable.
Additionally, Vercel has advised that Deployment Protection be set to Standard at a minimum and that Deployment Protection tokens be rotated if they have been configured.
Regarding account-level security, Vercel encourages users to enable multi-factor authentication, configure an authenticator app, and create a passkey to add an additional layer of protection.
Product changes being rolled out in response
Vercel said its teams have been actively shipping product updates in response to the incident. Several changes have already been deployed, with more in progress.
Among the enhancements already rolled out, environment variable creation now defaults to sensitive on. The company has also improved team-wide management of environment variables and made the activity log easier to use, including deep-linking to filtered views and a higher information density. Clearer team-invite emails have also been sent.
Rauch confirmed some of these changes in his post on X, noting that new capabilities had already been rolled out in the dashboard, including an overview page for environment variables and a revised user interface for creating and managing sensitive environment variables.
The investigators who were involved
Vercel has brought in several external parties to assist with the investigation and response. The company said it is working with Mandiant , additional cybersecurity firms, industry peers, and law enforcement. It has also engaged Context.ai directly to understand the full scope of the underlying compromise.
“We are working with Mandiant, additional cybersecurity firms, industry peers, and law enforcement. We have also engaged Context.ai directly to understand the full scope of the underlying compromise,” the bulletin states.
Rauch specifically acknowledged the role of Google’s Mandiant team. “I also want to thank the Google Mandiant team for their active engagement and assistance,” he wrote.
The investigation is still going on. Since the incident was first reported, the bulletin has been updated several times. Entries on April 19 and 20 added new information about the attack's origin, updated recommendations, product improvements, and advice on using multi-factor authentication. As the investigation goes on, Vercel has said it will keep updating the bulletin.
A broader lesson about third-party AI tool risk
The Vercel incident draws attention to a risk that many organisations may not have fully reckoned with. As AI tools become embedded in everyday professional workflows, the OAuth integrations they require often grant significant access to corporate accounts. A compromise at the tool level can directly compromise the accounts it has been granted access to, as was the case here.
The indicator of compromise that Vercel has shared suggests the impact of the underlying Context.ai breach extends beyond Vercel, potentially reaching hundreds of users at many organisations. Google Workspace administrators at any organisation whose employees use third-party AI tools integrated through OAuth should consider this incident a prompt to audit which apps have been granted access and to revoke those that are no longer in active use or that carry permissions broader than necessary.
For Vercel specifically, the company has framed its response as an effort to turn the incident into a basis for comprehensive security improvements across its platform. Whether the scope of the breach expands or contracts as the investigation continues, the steps the company is taking, including public disclosure, active engagement with law enforcement and outside investigators, and rapid product changes, represent the kind of response that security professionals generally recommend when an incident of this nature occurs.
Next Story