You know your Google API key has leaked so you rush to disable it before bad actors can start running up charges on your account. Bad news: According to security researchers at Aikido, people can use the API keys for up to 23 minutes after a user deletes them, creating a window of opportunity that, when combined with Google’s automatic billing tier upgrades, can devastate victims. “We've identified a substantial window where an attacker with access to a leaked Google API key can continue to misuse that credential, after the user believes the key is revoked,” Joseph Leon, a security researcher with Aikido, told The Register. “In that window, an attacker could run up charges, pull sensitive files uploaded to Gemini, and exfiltrate cached context.” Aikido tested the gap during 10 trials over two days. In each trial, researchers created an API key, deleted it, and then sent three to five authenticated requests per second until no valid response came back for several minutes. From the time a user deletes the Google API key to when it can no longer be used propagates gradually across Google's infrastructure, he said. Some servers reject the key within seconds while others keep accepting it for 23 minutes. What this means is that an attacker holding a deleted key can repeatedly send requests until one reaches a server that has not caught up, Leon said. If Gemini is enabled on the project, they can dump files that were uploaded and exfiltrate cached conversations. The paper cited a similar problem researchers disclosed in December involving AWS keys. In that case, after deletion, attackers had a four-second window to exploit, and researchers showed how they could create new credentials in that time. “Four seconds was enough to matter on AWS,” Leon wrote in the paper. “Given recent attention to Google API keys used to access Gemini, we set out to measure how long Google's API key revocation window remains open.” Flaws can hit devs with huge surprise bills The Register has reported numerous cases of Google API key abuse in which developers are suddenly hit with five figure bills after their credentials are compromised. The problem was compounded in April after Google reworked its billing policy to include spending tiers for users. While developers initially thought of it as a way to limit costs, Google automatically upgrades that spending tier to the next highest level without their knowledge. For users who have been working with Google for more than 30 days and have spent more than $1,000 over the lifetime of the account, their cap can be increased from $250 to $100,000 if their usage spikes – a windfall for crooks if the credentials fall into the wrong hands. Developers whose Google API keys were stolen told The Register that their bills rocketed up to five figures minutes after their credentials were stolen, as bad actors loaded up on Google’s Gemini models such as Nano Banana and its video production model Veo 3. Google issued refunds in the three instances that The Register brought to its attention, returning $154,000 to those developers. The victims told The Register that, during the attack, they were frantically trying to shut down the spending and turn off access to their projects even as costs climbed by thousands of dollars. Leon said in cases where a Google developer tries to shut off access to their account, deleting the API key will still give crooks time to inflict damage. “It's hard to put a dollar figure on it,” Leon told us. “The window averaged 16 minutes in our testing and stretched to nearly 23 at the worst. During that window, the success rate is wildly unpredictable. We saw minutes where over 90% of requests still authenticated, and others where fewer than 1% did. An attacker who knows this can send requests at high volume to maximize their odds of hitting a server that hasn't caught up. For Google API keys with Gemini access, the damage isn't just a compute bill. It's the files and cached context an attacker can exfiltrate before the key actually dies.” Using VMs, Aikido tested its findings across three Google Cloud regions – east coast US, western Europe, and southeast Asia – then they spot checked those results on different dates. For each trial, Aikido deleted a single API key and sent requests from each of the three VMs in parallel, Leon wrote in the paper. “VMs further from the US picked up the deletion faster, which is the opposite of what you'd expect. We can't say exactly why from the outside. Google's request routing is more complex than ‘VM region equals server region,’ and a VM in Singapore isn't necessarily talking to servers in Singapore,” the paper states. “But the pattern was consistent across trials, which points to something about regional infrastructure, caching, or routing affinity driving the difference.” The trial used keys with access to Gemini, but he observed the same behavior with keys scoped to other GCP APIs, such as BigQuery and Maps. Google has built faster revocation for other credential types, Leon said. He said Google’s service account API credential revocations propagate in about 5 seconds. Gemini's newer API key format – the one that starts with AQ – propagates in about a minute. “Both run at Google scale. Both suggest this is technically solvable for Google API keys, too,” Leon wrote. But Google told Aikido it has no plans to address the 23-minute gap researchers found with its other API keys. “After reviewing our report, they closed it as ‘Won't Fix (Infeasible)’ with the comment ‘the delay due to propagation of the deletion of these keys is working as intended,’ “ Leon told us. The Register has reached out to Google about this research, but has not yet received a response. ®

GitHub, the world's biggest code repository and DevOps platform, fell victim to a malicious Visual Studio Code (VS Code) extension. The company's initial assessment is that only internal repositories were exfiltrated. The incident was reported by GitHub on X, with follow-up posts revealing a "poisoned VS Code extension" as the cause. The Microsoft-owned code shack continues to "analyze logs, validate secret rotation, and monitor for any follow-on activity." One GitHub post references "the attacker's current claims of ~3,800 repositories" as consistent with its investigation. This may refer to a post attributed to TeamPCP, the malware crew linked to the Shai-Hulud worm, the code for which has been published and caused widespread damage. In a post, the crew advertised GitHub's internal source code for sale, claiming around 4,000 repositories. They said it was not a ransom and if no buyer was found, they would leak the code for free. Claims like these should be treated with caution. A key concern for GitHub users is whether private repositories are at risk, either immediately or in the future if the attackers have gained a foothold into internal systems via stolen credentials. Risks include leakage of commercial code and credentials. Although best practice is not to check secrets into any repository, public or private, some organizations are less disciplined about this when repositories are private. Last month, Wiz Research discovered a remote code execution flaw in GitHub.com and GitHub Enterprise Server (the self-hosted version), which the researchers said was "remarkably easy to exploit." The vulnerability was discovered using AI. Developer reactions to GitHub's latest problems combine alarm and resignation – plus some humor. "How did the attackers find a large enough uptime window to get in?" quipped one. GitHub is in some difficulty. This compromise comes after a surge in npm attacks, many related to Shai-Hulud code, which the company has failed to prevent despite being aware of the issue since September 2025. Further, the platform has reliability issues caused in part by AI bots hoovering public code to feed large language models – problems that led HashiCorp co-founder Mitchell Hashimoto to declare GitHub "no longer a place for serious work." Another said that "the era where a developer machine with source code access also has access to meaningful security systems should be over. Internal repository access should mean nothing... GitHub compromise could happen at any time, even from GitHub themselves." Issues with cloud platforms also increase the appeal of self-hosted systems such as the open source

Checkmarx’s software engineers are still working to remove a malicious version of the code security outfit's Jenkins plugin after detecting an unauthorized upload over the weekend. It updated customers on Saturday, May 9, after discovering a version of its AST Scanner, which is used for security scans in Jenkins CI pipelines, was made available via the Jenkins Marketplace. “We are aware that a modified version of the Checkmarx Jenkins AST plugin was published to the Jenkins Marketplace,” it said in a statement. “We are in the process of publishing a new version of this plug-in.” Versions published as of May 9, 2026, should not be trusted, it added, before urging all users to check they’re running the correct release (2.0.13-829.vc72453fa_1c16) published on December 17, 2025. Installed by several hundred controllers, the plugin remains available at the time of writing, and appears as the most recently available version, although pull requests actioned on Monday morning suggest this will soon be pulled down. “What makes this particularly dangerous for Jenkins users is the trust model at play,” said SOCRadar in its coverage. “The Checkmarx Jenkins plugin is a tool people install specifically to improve the security of their pipelines. “A backdoored version doesn’t just compromise one project; it rides trusted infrastructure into every build pipeline it touches, with access to source code, environment variables, tokens, and whatever secrets the runner can see.” Security engineer Adnan Khan spotted the compromise quickly over the weekend. The crew behind the early supply chain attack affecting Checkmarx in April, TeamPCP, defaced the company’s GitHub and published six packages, each with a description alluding to the Shai-Hulud wormable malware. These packages no longer appear on Checkmarx’s GitHub, but TeamPCP made multiple changes to the AST plugins page, renaming it to “Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now,” and altering the description to claim CheckMarx failed to rotate its secrets. The latest infiltration of Checkmarx’s internals marks the third time TeamPCP has compromised the company’s packages in as many months. As previously seen in The Register, the crooks successfully targeted Checkmarx’s AST plugin for GitHub Actions and its KICS static analysis tool back in March, deploying credential-stealing malware. SOCRadar said the latest TeamPCP compromise of the Jenkins plugin suggests that either TeamPCP was telling the truth about Checkmarx’s secrets rotation, or its members took advantage of an additional persistence mechanism that the security vendor failed to notice during its response to the March intrusion. ®