The Homebrew team has released version 6.0 of this popular open-source package manager for macOS and Linux, with a new mechanism for trusting packages and support for sandboxing on Linux, to align with existing sandboxing on macOS. Homebrew 6.0 introduces tap trust, a "tap" being a collection of formulae, casks (a package of pre-compiled binaries) and commands which usually reside in a Git repository. The tool trusts official Homebrew taps by default, but requires an explicit agreement before it will trust third-party taps (which can include arbitrary Ruby code) before they install or run any code. Tap trust is part of Homebrew’s approach to supply chain security, which has a number of distinctive features. Package maintainers are Homebrew maintainers, not the authors of the package. Names are maintainer-curated, so typosquats (giving a package a misleading name designed to be similar to one that is popular) can be rejected. Each download is pinned to a sha256 checksum. Package binaries are built from source, which protected Homebrew from incidents like the Trivy compromise earlier this year when official Trivy binaries were replaced with malicious versions. These and other features of Homebrew security are described in the documentation. Project leader Mike McQuaid told us that "Homebrew was less vulnerable 10-15 years ago than npm is today. The trust model is radically different and, even today, we are much quicker to break backwards compatibility in the interest of security." A new security feature is sandboxing on Linux when Homebrew compiles software. This was already implemented on macOS (and has been for a decade). Version 6.0 adds a Linux implementation based on the Bubblewrap project, and this will be on by default for developers. A new Homebrew sub-command, brew vulns, will check installed packages for known vulnerabilities, by checking against the OSV (vulnerability database for open source). The commands brew install and brew upgrade will now show a dependency summary and require a conformation prompt before running, called ask mode, following a developer survey earlier this year where this was highly requested. Another new command, brew exec, will run a Homebrew-provided executable, similar to the way npx works for npm packages. Homebrew startup performance in 6.0 is said to be faster, thanks to parallelised bottle fetching (a bottle is a pre-built package) and other optimizations. Apple is phasing out support for Intel macOS both for future versions of macOS and for Rosetta, the Intel compatibility layer. Homebrew is following: in September this year no new bottles will be built for macOS Intel and from September 2027 macOS Intel will be "unsupported entirely and all related code deleted," according to the post introducing Homebrew 6.0. Homebrew is well-liked by developers, and becoming more popular on Linux as well as macOS. There is some frustration though regarding the dropping of Intel support. "The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple!," said one. McQuaid replied noting that Homebrew will still work for a year after support is dropped to "Tier 3”, meaning almost unsupported, and added that "there’s nothing stopping you for doing the work to setup ‘Intelbrew’ and support it for the community." Another issue he mentioned is that GitHub is dropping macOS Intel runners for continuous integration towards the end of 2027. It is notable that Homebrew 6.0 made extensive use of AI coding. A document on responsible AI usage takes the line that AI contributions must be disclosed and human-reviewed, and that AI is not responsible for any code, rather the human contributor is responsible. "AI is great if used responsibly which means a human reviewing all changes both before PRs submitted and a maintainer reviewing before PRs are merged. I have found despite using it responsibly it has been a huge personal accelerator," McQuaid told us. ®

GitHub will change npm's defaults so the install command no longer runs scripts automatically, disabling a feature commonly exploited by malicious packages such as the notorious Shai-Hulud worm. Maintainer Leo Balter said: "Install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem. Every npm install runs scripts from every transitive dependency, so a single compromised package anywhere in your tree can execute arbitrary code on a developer machine or CI (continuous integration) runner." In npm 12, due July, three security-focused defaults are changing. Scripts configured for preinstall, install, or postinstall will no longer run unless explicitly permitted via allow-scripts. The --allow-git flag, which pulls dependencies from remote URLs, will default to off, closing an attack path where a malicious .npmrc file could override the Git executable and achieve arbitrary code execution. Finally, allow-remote will default to none, blocking dependency downloads from remote URLs entirely. It will still be possible to allow scripts to run via an allowlist in the package.json configuration file. This will be pinned to the installed version of a package by default. These are breaking changes, and Balter recommended developers run the commands to allow scripts for every currently installed package in a project that requires them. "This gets you protected against new, unexpected scripts immediately," he said. The next step is to review these packages and deny scripts for those where they are not needed. Some packages require script approval to function, including native modules that compile on install, testing tools like Playwright and Puppeteer (which fetch binaries via postinstall), and Electron, which wraps the Chromium browser engine for cross-platform desktop applications. These features have been available since npm version 11.10.0, released in February, but as opt-in flags rather than defaults. That version also introduced min-release-age, which blocks installation of package version newer than a specified number of days, designed as a safeguard against newly published malicious packages. Best security practice for developers using npm 11.16, the current version, is to set these flags on in .npmrc or via environment variables, which will also prepare a project for the changes in version 12. One annoyance is that the existing flag ignore-scripts does not support an allowlist, other than via an additional tool. The ignore-scripts setting will override allow-scripts, so developers will need to remove it, if set to true, to enable approved scripts to run. The allowScripts setting exists in npm 11 but is advisory only. Will this fix npm security issues? Unfortunately not. "Now all the malware can move from the install script to the module itself where it will inevitably still be run," said one developer. Another common view is that developers should use pnpm, which already has safer defaults than npm, including a minimum release age. There is consensus, though, that these changes do improve npm security and are long overdue. The pull request for this change includes the remark that "npm is the only remaining major package manager that runs dependency install scripts by default. pnpm v10+, Yarn Berry, Bun, and Deno all block them." ®

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. ®