Mitiga researchers say attackers can silently redirect Claude Code MCP traffic, intercept OAuth tokens, and maintain persistent access to connected SaaS platforms.
The post Claude Code OAuth Tokens Can Be Stolen Through Stealthy MCP Hijacking appeared first on SecurityWeek.
Vercel said the fallout from an attack on its internal systems hit more customers than previously known, as ongoing analysis uncovered additional evidence of compromise.
The company, which makes tools and hosts cloud infrastructure for developers, maintains a “small number” of accounts were impacted, but it has yet to share a number or range of known incidents linked to the attack. Vercel created and maintains Next.js, a platform supporting AI agents that’s downloaded more than 9 million times per week, and other popular open-source projects.
Vercel CEO Guillermo Rauch said the company and partners have analyzed nearly a petabyte of logs across the Vercel network and API, and learned malicious activity targeting the company and its customers extends beyond an initial attack that originated at Context.ai.
“Threat intel points to the distribution of malware to computers in search of valuable tokens like keys to Vercel accounts and other providers,” Rauch said in a post on X.
“Once the attacker gets ahold of those keys, our logs show a repeated pattern: rapid and comprehensive API usage, with a focus on enumeration of non-sensitive environment variables,” he added.
The attack exemplifies the widespread and compounded risk posed by interconnected systems that rely on OAuth tokens, trusted relationships and overly privileged permissions linking multiple services together.
“The real vulnerability was trust, not technology,” Munish Walther-Puri, head of critical digital infrastructure at TPO Group, told CyberScoop. “OAuth turned a productivity app into a backdoor. Every AI tool an employee connects to their work account is now a potential attack surface.”
An attacker traversed Vercel’s internal systems to steal and decrypt customer data, including environment variables it stored, posing significant downstream risk.
The company insists the breach originated at Context.ai, a third-party AI tool used by one of its employees. Researchers at Hudson Rock previously said the seeds of that attack were planted in February when a Context.ai employee’s computer was infected with Lumma Stealer malware after they searched for Roblox game exploits, a common vector for infostealer deployments.
Vercel has not specified the systems and customers data compromised, nor has it described the threat eradicated or contained. The company said it’s found no evidence of tampering across the software packages it publishes, concluding “we believe the supply chain remains safe.”
The company fueled further intrigue in its updated security bulletin, noting that it also identified a separate “small number of customers” that were compromised in attacks unrelated to the breach of its systems.
“These compromises do not appear to have originated on Vercel systems,” the company said. “This activity does not appear to be a continuation or expansion of the April incident, nor does it appear to be evidence of an earlier Vercel security incident.”
It’s unclear how Vercel became aware of those attacks and why it’s disclosing them publicly.
Vercel declined to answer questions, and Mandiant, which is running incident response and an investigation into the attack, referred questions back to Vercel.
Vercel has not attributed the breach to any named threat group or described the attackers’ objectives.
An online persona identifying themselves as ShinyHunters took responsibility for the attack and is attempting to sell the stolen data, which they claim includes access keys, source code and databases. Austin Larsen, principal threat analyst at Google Threat Intelligence Group, said the attacker is “likely an imposter,” but emphasized the risk of exposure is real.
Walther-Puri warned that the downstream blast radius from the attack on its systems remains undefined. “Stolen API keys and source code snippets from internal views are potentially keys to customer production environments,” he said.
The stolen data attackers claim to have “sounds almost boring … but it’s infrastructure intelligence,” Walther-Puri added. “The right environment variable doesn’t just unlock a system — it lets adversaries become that system, silently, from the inside.”
The post Vercel attack fallout expands to more customers and third-party systems appeared first on CyberScoop.
Vercel customers are at risk of compromise after an attacker hopped through multiple internal systems to steal credentials and other sensitive data, the company said in a security bulletin Sunday.
The attack, which didn’t originate at Vercel, showcases the pitfalls of interconnected cloud applications and SaaS integrations with overly privileged permissions.
An attacker traversed third-party systems and connections left exposed by employees before it hit the San Francisco-based company that created and maintains Next.js and other popular open-source libraries.
Researchers at Hudson Rock said the seeds of the attack were planted in February when a Context.ai employee’s computer was infected with Lumma Stealer malware after they searched for Roblox game exploits, a common vector for infostealer deployments.
Each of the companies are pinning at least some blame for the attack on the other vendor.
Context.ai on Sunday said that breach allowed the attacker to access its AWS environment and OAuth tokens for some users, including a token for a Vercel employee’s Google Workspace account. Vercel is not a Context customer, but the Vercel employee was using Context AI Office Suite and granted it full access, the artificial intelligence agent company said.
“The attacker used that access to take over the employee’s Vercel Google Workspace account, which enabled them to gain access to some Vercel environments and environment variables that were not marked as sensitive,” Vercel said in its bulletin.
The company said a limited number of its customers are impacted and were immediately advised to rotate credentials. Vercel, which declined to answer questions, did not specify which internal systems were accessed or fully explain how the attacker gained access to Vercel customers’ credentials.
Vercel CEO Guillermo Rauch said customer data stored by the company is fully encrypted, yet the attacker got further access through enumeration, or by counting and inventorying specific variables.
“We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI,” he said in a post on X. “They moved with surprising velocity and in-depth understanding of Vercel.”
A threat group identifying itself as ShinyHunters took responsibility for the attack in a post on Telegram and is attempting to sell the stolen data, which they claim includes access keys, source code and databases.
The attacker “is likely an imposter attempting to use an established name to inflate their notoriety,” Austin Larsen, principal threat analyst at Google Threat Intelligence, wrote in a LinkedIn post. “Regardless of the threat actor involved, the exposure risk is real.”
Vercel also warned that the attack on Context’s Google Workspace OAuth app “was the subject of a broader compromise, potentially affecting its hundreds of users across many organizations.” It published indicators of compromise and encouraged customers to review activity logs, review and rotate variables containing secrets.
Context and Vercel said their separate and coordinated investigations into the attack aided by CrowdStrike and Mandiant remain underway.
The post Vercel’s security breach started with malware disguised as Roblox cheats appeared first on CyberScoop.
An independent forensic investigation is underway to determine the extent of the intrusion into customer management software Gainsight’s systems and whether the breach has spread beyond Salesforce to other third-party applications. Despite this ongoing analysis, the company maintains that the impact on customer data stored within connected services is limited and largely contained.
“While Salesforce has identified compromised customer tokens, we presently know of only a handful of customers who had their data affected,” Gainsight CEO Chuck Ganapathi wrote in a blog post Tuesday. “Salesforce has notified the affected customers and we have reached out to each of them to provide support and are working directly with them.”
Details about the attack are scattered, and discrepancies remain about the number of companies impacted and the extent to which they are compromised. Information is fragmented, in part, because Gainsight and Salesforce are sharing updates independent of each other and respective to their own systems.
Gainsight is relying on Salesforce and Mandiant, its incident response firm, to identify victims of the attack and provide detailed indicators of compromise.
Salesforce identified three impacted customers in the immediate aftermath of the attack, and has since found more confirmed victims, Gainsight said in an update on its community page. Neither company has provided a specific number of known victims.
“There is a distinction between the number of customers who Salesforce identified as having compromised tokens and the handful of customers we presently know had their data affected,” a company spokesperson told CyberScoop Tuesday.
Google Threat Intelligence Group, which is affiliated with Mandiant under Google Cloud’s security apparatus, said it was aware of more than 200 Salesforce instances potentially affected by the Gainsight breach last week. Google hasn’t provided an updated figure since then.
Inconsistencies are common in supply-chain attacks that flow downstream.
Meanwhile, Mandiant is continuing to sift through logs and analyze token behavior and connector activity to provide Gainsight with a more complete view of what occurred and how far attackers were able to use Gainsight customers’ access tokens to breach additional systems.
Gainsight previously said Hubspot, Zendesk and revenue intelligence platform Gong.io also temporarily revoked Gainsight customers’ access tokens “out of an abundance of caution.” The company hasn’t reported any confirmed impact on other systems and Salesforce maintains that the issue did not involve a vulnerability in the Salesforce platform.
The breach and its root cause is strikingly similar to an expansive downstream attack spree that impacted more than 700 customers who integrated Salesloft Drift into Salesforce two months ago.
While Gainsight and Salesforce are both communicating directly with customers, publicly available threat hunting guidance and information about the attacks exist in multiple places.
Salesforce has shared the most comprehensive IOCs, including dates and observed activities for each malicious IP address. The earliest malicious activity linked to the campaign occurred Oct. 23, according to Salesforce.
The company advised customers to review all available logs for potential compromise and noted that the revocation of Gainsight OAuth tokens does not delete a customers’ logs or hinder their ability to investigate the incident.
Gainsight, however, said its logs are of less use. “Based on the nature of the logs we retain, many of our clients have not found them to be material in assessing any risk to their organization,” Brent Krempges, chief customer officer at Gainsight, said on its community page.
“We strongly recommend that you focus your investigation on the Salesforce logs that show authentication attempts and API calls originating from the Gainsight Connected App,” he added. “These Salesforce-side logs are the authoritative source of information for identifying any anomalous access patterns.”
Gainsight also recommended that customers configure IP restrictions for API calls to ensure only legitimate requests are allowed. This security control is manual and requires cooperation from every vendor in the supply chain. Okta said IP restrictions kept its Drift integrations secure and successfully blocked an attempted attack on its Salesforce environment during the widespread incidents in August.
Ganapathi, who was named CEO in August, acknowledged that Gainsight is critical to its customers’ daily operations and said the company is personally responsible for ensuring access to its products. The company is helping customers manage their Gainsight Customer Success (CS) instances while its Salesforce connected app is offline, he said.
“The only way we beat these threats is by working together and sharing information and strategies,” Ganapathi said. “That is why I am committing to sharing what we learn from this experience to help everyone in the SaaS community strengthen their defenses and, we hope, avoid going through something similar themselves.”
The post Gainsight CEO downplays impact of attack that spread to Salesforce environments appeared first on CyberScoop.
The recent Salesloft Drift breach offered a sobering reminder of how easily trust can be weaponized in today’s SaaS and AI-integrated environments. In this incident, hackers exploited the Drift chatbot, stole OAuth tokens, and used them to obtain data from CRM systems before the tokens could be revoked. In the wake of the incident, many deemed the weak spot to be the tokens, but they are missing the bigger issue. Namely, identity and permission sprawl, and a misuse of excessive trust.
With Drift, attackers used OAuth tokens to make legitimate API calls against CRM environments, and since the tokens were valid, the fraudulent activity didn’t raise any flags. In the eyes of all, it was simply business as usual. Organizations later confirmed that data was stolen before tokens could be revoked. This includes sensitive business records, contact information, support data, and, in some cases, embedded credentials across more than 700 organizations using the compromised integration with Salesforce.
And while those impacted have traced the chain of compromise, the next step is to address the larger underlying problem of the chatbots and the excessive scopes they are given.
Consider the following:
Add it all up, and you can see how a single compromised credential can create significant exposure. And the risk is only growing, thanks to SaaS and AI-powered integrations that are creating an unimaginable number of vulnerabilities. Still, businesses treat integrations and agents as background utilities that have no ownership, governance, or lifecycle management. Ironically, it’s the absence of these controls that gives them greater operating privileges and reach than any human would ever be granted, while making them ideal targets for attackers.
Whether or not an organization was impacted by Drift, it’s time to reassess all SaaS and AI integration footprints. This includes verifying every connected app, API bridge, and automation workflow.
Start with addressing hygiene, including the following:
This tactical cleanup is not a one-time exercise. Everything must be re-evaluated on an ongoing basis. Even then, your work is not done.
The next generation of security requires using adaptive access models such as Zero Standing Privileges (ZSP), where “always-on” automation is replaced by dynamic, ephemeral identities and permissions that are enforceable at runtime. With ZSP, every integration or AI agent receives temporary, just-in-time access that is created at runtime, bound by clear time-to-live parameters and contextual conditions. When the task ends, the permission disappears.
Because these are enabled through runtime authorization, businesses can easily verify not only who or what is making a request, but also why, for how long, and under what conditions. When paired with continuous monitoring, organizations can quickly spot anomalous activities and revoke privileges instantly when behavior deviates from policy.
Another key to success is treating all integrations, whether they are human, machine, agentic AI, or AI-driven assistants, equally. Each of these should have a distinct identity, a defined purpose, ownership, and lifecycle stages. These controls provide teams with critical visibility across all identities and, when irregular activities are spotted, the answers to critical questions—who had access, what they did, and for how long?
Pay special attention to AI-driven tools, ensuring that agents operating on behalf of humans only act within the parameters set by their sponsor. Helpful tools here include allowlisting and runtime guardrails that can keep agents in their assigned lane and, in doing so, prevent them from veering off and initiating unauthorized actions. This includes those that have been compromised or manipulated through prompt injection.
The Drift incident wasn’t an anomaly—it was a preview. As AI-driven automations and SaaS integrations multiply, every organization will face the same question: can you truly see, control, and verify who or what has access to your data at any given moment?
Security can no longer depend on static controls or the assumption that trusted systems will stay trustworthy. The future belongs to those who treat identity as the new perimeter and access as a living, breathing condition—not a one-time approval. When every token, credential, and agent is governed by context, time, and intent, trust becomes measurable—and defensible.
Because in a world where automation never sleeps, trust can’t either.
Art Poghosyan is the CEO of Britive, a cloud privileged access management software company.
The post When trust turns toxic: Lessons from the Salesloft Drift incident appeared first on CyberScoop.
Login