Loading story…
GitHub announced that npm v12 will change default package installation behavior to curb software supply-chain attacks that abuse npm install. The release will require explicit approval before running lifecycle scripts, building native modules with node-gyp, resolving Git-based dependencies, or fetching packages from remote URLs such as HTTPS tarballs. GitHub said the changes remove several automatic code-execution and dependency-resolution paths that attackers have repeatedly used to hide malicious behavior in packages and transitive dependencies executed on developer workstations and CI runners.
The move targets techniques seen in incidents involving malicious preinstall and postinstall scripts, Git dependency abuse, and campaigns tied to packages such as eslint-config-prettier, Toptal’s Picasso packages, and the Shai-Hulud worm. npm maintainers said install-time scripts represent the ecosystem’s largest code-execution surface, though the new defaults will be breaking for some legitimate projects including Playwright, Puppeteer, Electron, and native modules that now must opt in. GitHub urged developers to upgrade to npm 11.16.0 or later ahead of the release so they can receive warnings about workflows that will fail under npm v12’s stricter defaults.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
Alongside the npm 12 announcement, GitHub recommended that developers move to npm 11.16.0 or newer so they can receive warnings about breaking changes and prepare workflows before the new defaults arrive.
GitHub announced that npm v12 will change default behavior to reduce software supply-chain attacks during 'npm install'. The new defaults will require explicit approval for lifecycle scripts, native module builds, Git-based dependencies, and remote URL dependency fetching.
The protections that disable risky install-time behaviors were already available as opt-in features in npm 11.10.0 and later, alongside min-release-age. These features preceded the planned npm 12 default changes.
A reopened npm/cli issue proposed setting `ignore-scripts` to `true` by default to prevent automatic execution of package installation scripts. The reporter argued this would reduce supply-chain risk by making script execution explicit and opt-in.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
11 references tracked. Mallory keeps watching after this page renders.
risky.biz
Open sourcecybersecuritynews.com
Open sourcethehackernews.com
Open sourcelinuxsecurity.com
Open sourcebleepingcomputer.com
Open sourcegithub.blog
Open sourcesemgrep.dev
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Package ecosystem maintainers and security vendors highlighted new guardrails and failure modes in automated dependency workflows. npm CLI 11.x introduced **`minimumReleaseAge`**, a release “cooldown” control that blocks installation of newly published versions until they reach a configured age, aiming to reduce exposure to malicious packages that rely on rapid adoption before detection or takedown. npm also added bulk configuration for **OIDC trusted publishing**, aligning with broader efforts to harden CI-based publishing; similar release-age gating has already been implemented in other Node.js package managers (pnpm, Yarn, and Bun), though npm’s initial implementation lacks an exclusion mechanism for cases like urgent internal hotfixes. Separately, StepSecurity reported detecting a “release storm” affecting multiple Microsoft **`@types/*`** packages on npm, where dozens of semver releases were published within 24 hours with no code changes beyond repeated deprecation-version bumps—attributed to an automation loop tied to a scheduled GitHub Actions workflow in *microsoft/DefinitelyTyped-tools* (`publish-packages.yml`). In the Go ecosystem, a maintainer of widely used cryptography code criticized GitHub **Dependabot** for generating large volumes of low-signal alerts and PRs after a minor security fix, arguing the tool often flags repositories based on dependency presence rather than reachability/actual impact, creating alert fatigue and potentially reducing security; he recommended reachability-aware tooling such as *govulncheck* for Go vulnerability triage.
Jun 29, 2026
Several GitHub-hosted JavaScript projects were modified to include a malicious `postinstall` entry in `package.json`, turning routine dependency installation into unauthorized code execution. Commits affecting repositories including **thedevdojo/genesis**, **katanaui/katana**, and **baskarcm/tzi-chat-ui** added a script that used `curl` with certificate checks disabled to fetch a binary named `gvfsd-network` from a GitHub Releases page tied to `parikhpreyash4/systemd-network-helper-aa5c751f`, save it as `/tmp/.sshd`, mark it executable, and run it in the background. The pattern indicates a supply-chain style compromise designed to hide a backdoor inside otherwise ordinary dependency or build changes. Other repositories moved quickly to remove the payload, with commits in **elitedevsquad/sidecar-laravel** and **katanaui/katana** explicitly reverting the suspicious `postinstall` logic while preserving legitimate build scripts. The repeated use of the same download URL, filename, and execution flow across unrelated projects suggests a coordinated campaign rather than isolated developer error. Separately, CISA added **CVE-2026-48172** in the **LiteSpeed cPanel Plugin** to its Known Exploited Vulnerabilities catalog, but the dominant event across the referenced code changes was the discovery and rollback of a malicious package-install backdoor hosted through GitHub infrastructure.
Jun 29, 2026
Security researchers reported two distinct software supply-chain abuse paths that can make malicious code appear to originate from trusted sources. GMO Cybersecurity by Ierae described an active campaign dubbed **“repo squatting”** that abuses how GitHub renders and links commits from forks: a commit made in an attacker-controlled fork can be viewed under the upstream project’s URL structure, enabling convincing links like `github.com/<official-org>/<repo>/commit/<hash>` that appear to belong to the official repository. The campaign targeted the *GitHub Desktop* project by distributing a trojanized installer carrying **HijackLoader**, with the malicious download link presented in a way that could mislead users and some security tooling into believing it came from the official repo. Separately, Koi researchers disclosed **PackageGate** weaknesses in JavaScript dependency tooling that allow bypassing npm’s post–**Shai-Hulud** mitigations when installing **Git-based dependencies**. They reported that a malicious `.npmrc` in a Git dependency can override the `git` binary path, enabling **code execution even when lifecycle scripts are disabled** (e.g., `--ignore-scripts=true`), affecting multiple tools (including *pnpm*, *vlt*, *Bun*, and *npm*). Vendors reportedly addressed the issue in the non-npm tools, while npm closed the report as “works as expected,” and researchers cited evidence of prior proof-of-concept abuse (e.g., reverse shell) indicating practical exploitation risk for organizations relying on Git dependencies in CI/CD and developer environments.
Jun 29, 2026