Listen to this Post
Introduction: When a Developer Install Becomes a Security Incident
Modern software development depends on an enormous ecosystem of open-source packages. A single npm install can pull in hundreds or even thousands of dependencies, often created and maintained by people and small teams far removed from the organization using them.
That convenience has created one of the most dangerous fault lines in modern cybersecurity: the software supply chain.
The latest incident involving @7nohe/openapi-react-query-codegen is a sharp reminder of just how quickly a trusted development dependency can become an entry point into an organization’s entire engineering environment. According to Aikido Security, multiple malicious versions of the npm package were published in a coordinated campaign, turning a tool used to generate type-safe TanStack Query hooks into a vehicle for credential theft, repository compromise, and further package poisoning.
The incident is particularly concerning because the package reportedly receives more than 150,000 weekly downloads. That means the compromise was not aimed at an obscure dependency sitting unused in some forgotten project. It targeted software sitting directly inside developer machines, CI pipelines, build environments, and potentially production-oriented engineering infrastructure.
And the most unsettling part is that the attack did not stop at stealing credentials.
The malware was designed as a worm.
Once it obtained publishing tokens and repository credentials, it could potentially use those privileges to spread into other npm, PyPI, and RubyGems packages or inject malicious developer tooling into accessible GitHub repositories.
This is exactly the kind of supply-chain attack security teams have increasingly feared: one compromised package becoming the starting point for a much larger ecosystem infection.
What Happened: Ten Malicious Releases in Minutes
A Rapid and Coordinated npm Compromise
Aikido Security reported identifying 10 malicious versions of @7nohe/openapi-react-query-codegen published within approximately 20 minutes.
The package is designed to generate type-safe hooks for TanStack Query, making it part of a workflow familiar to modern JavaScript and TypeScript developers.
The speed of the publication campaign is important. Attackers did not need weeks to gradually establish themselves inside the ecosystem. Once they gained control of the relevant release mechanism, they could push malicious versions rapidly and allow automated package installation to do much of the work.
For organizations that automatically consume dependency updates, that creates a particularly dangerous window.
Why This Package Was an Attractive Target
Developers Already Trusted the Dependency
Supply-chain malware succeeds because it hides behind trust.
Developers generally do not expect a package they install through npm to behave like an information-stealing trojan. They expect it to install, compile, and perform the functionality described by its documentation.
That trust becomes extremely valuable to attackers.
Instead of convincing an employee to open a malicious attachment, an attacker can compromise a dependency and wait for developers or CI systems to execute the package’s installation process.
The resulting execution may happen automatically.
The Name Behind the Payload: “Trinitite”
A Distinctive Malware Fingerprint
Researchers identified the payload using the label:
Trinitite: Sponsored by Preview 2 Effects
The tradecraft reportedly resembles activity associated with TeamPCP-linked campaigns, although attribution remains unresolved.
That distinction matters.
Similar technical techniques can appear across different threat actors, and researchers should avoid treating malware similarities as definitive proof of attribution.
What is much clearer is the operational goal: steal credentials, gain additional access, and use those credentials to spread.
The GitHub Actions Problem
Valid Provenance Does Not Automatically Mean Safe Software
One of the most interesting aspects of this incident is the reported abuse of a GitHub Actions workflow.
The attackers are believed to have modified or abused the release process in a way that allowed malicious releases to retain valid provenance attestations.
This exposes an important misconception in modern software security.
A provenance attestation can help answer a question such as:
“Did this artifact come from the expected build workflow?”
But that is not necessarily the same as answering:
“Was the build workflow itself trustworthy?”
If an attacker compromises the workflow, credentials, repository, build logic, or release process, a cryptographically valid artifact can still contain malicious code.
Provenance tells you where something came from. It does not automatically prove that everything involved in producing it was uncompromised.
The Clever Installation Trap
binding.gyp Was Used as an Execution Mechanism
Most compromised versions reportedly weaponized a file called binding.gyp.
Normally, binding.gyp is associated with Node.js native addon compilation and the node-gyp build system.
In this attack, however, the configuration was reportedly abused as an installation-time execution mechanism.
Instead of simply compiling legitimate native code, the malicious configuration caused Python code to execute during dependency installation.
That creates a powerful attack surface because developers may trigger it merely by installing the package.
Python Class Hierarchy Abuse
Turning a Build Configuration Into Code Execution
The malicious binding.gyp reportedly abused
From there, the attacker-controlled code could import the os module and execute the obfuscated Node.js payload.
Conceptually, the chain looked like this:
npm installation → node-gyp → Python evaluation → built-in access → OS interaction → Node.js payload → credential harvesting
That is an important lesson for defenders.
A file does not need to look like a traditional executable to become an execution mechanism.
Build systems, package managers, configuration files, lifecycle hooks, and compiler tooling can all become attack surfaces.
No Native Addon Was Actually Needed
The “Build” Was a Disguise
Researchers reportedly found that no legitimate native build was necessary for the malicious behavior.
The presence of binding.gyp therefore served primarily as an installation-time execution mechanism.
Some prerelease versions reportedly used explicit preinstall scripts instead, while later versions combined multiple techniques.
That evolution suggests an attacker willing to experiment with different execution paths while maintaining the same underlying objective.
The 5.4 MB Payload
3FWCvzduYZg.js
The primary payload was identified as:
3FWCvzduYZg.js
The file is reportedly approximately 5.4 MB, compressed into a single line and protected by multiple layers of obfuscation.
Researchers identified techniques involving:
XOR-based obfuscation
AES-GCM
JavaScript obfuscation
Runtime downloading
Environment detection
Credential harvesting
Cloud credential validation
Automated exfiltration
Further propagation
The large, heavily obfuscated JavaScript file was not simply a passive downloader.
It reportedly contained functionality designed to operate as a credential stealer and as a propagation mechanism.
Downloading Bun Before Executing
Another Layer of Indirection
The malware reportedly downloaded the Bun JavaScript runtime before executing portions of its functionality.
This provides another layer between the package installation process and the actual malicious execution.
From a
Attackers can bring their own runtime environment into a compromised machine.
Anti-Analysis Checks
The Malware Did Not Want to Be Watched
The malware reportedly performed several environment checks designed to identify analysis and security research environments.
Among the reported checks were:
Russian locale settings
Security-tool directories
Known scanner decoy credentials
Research accounts
StepSecurity’s harden-runner
Other indicators associated with automated analysis
If certain conditions were detected, the malware could terminate rather than reveal its behavior.
This is classic defensive evasion.
The objective is not necessarily to defeat every security product. It is often enough to recognize common automated analysis environments and remain quiet there.
The Real Prize: Credentials
The Attack Went After the
The stolen information reportedly included a remarkably broad collection of credentials and configuration data.
Potential targets included:
GitHub tokens
npm tokens
PyPI tokens
RubyGems credentials
AWS credentials
Azure credentials
Google Cloud credentials
HashiCorp Vault credentials
Kubernetes service-account information
Kubernetes kubeconfig files
SSH keys
Docker configuration
.env files
Git credentials
Shell history
Cryptocurrency wallets
Messaging-session information
VPN configurations
Claude-related files
This is why supply-chain malware can be disproportionately dangerous.
The attacker does not need to compromise every service individually.
They can compromise the developer workstation that already has access to those services.
Cloud Metadata Is Also in the Crosshairs
From Developer Machine to Cloud Environment
Aikido Security reportedly observed functionality capable of querying cloud metadata services and validating discovered cloud credentials.
This is particularly concerning in environments where developer or CI workloads have access to cloud infrastructure.
A stolen credential can be much more valuable when the attacker can determine whether it is still valid and what environment it can access.
The attack therefore moves beyond simple information theft.
It becomes an access-discovery operation.
The Malware Exfiltration Strategy
Stolen Data Was Hidden in GitHub Repositories
The collected information was reportedly encrypted and committed to attacker-controlled GitHub repositories.
Researchers noted that these repositories were commonly named after Touhou Project characters and used the Trinitite description.
This provides defenders with useful hunting clues.
A compromised machine may not necessarily communicate with an obviously malicious command-and-control domain. Instead, stolen information can be hidden inside legitimate cloud platforms and code-hosting infrastructure.
That makes traditional network-based detection more difficult.
The Worm Changes Everything
This Was Not Just a Credential Stealer
The most dangerous characteristic of the campaign is its ability to potentially use stolen credentials to spread.
If npm, PyPI, or RubyGems publishing credentials are obtained, the malware can potentially use them to inject malicious files into other packages.
That creates a chain reaction:
Package A → stolen credentials → Package B → new victims → additional credentials → Packages C and D
This is what makes a supply-chain worm fundamentally different from a conventional infostealer.
The victim can become the next attacker-controlled distribution point without realizing it.
GitHub Repositories Can Become Weapons
Backdoors Hidden Inside Developer Tooling
Stolen GitHub credentials reportedly allowed the malware to poison accessible repositories with malicious developer configuration.
Potential targets included:
VS Code tasks
Claude Code hooks
Fake CodeQL workflows
Developer configuration files
Other automation mechanisms
This is especially dangerous because developer tooling is increasingly powerful.
A malicious task or hook may execute automatically when a developer opens a repository, runs a command, or starts a development workflow.
The supply chain therefore extends beyond packages.
It can reach the development environment itself.
Why CI/CD Systems Are Especially Vulnerable
Automation Can Turn One Compromise Into Hundreds
CI/CD environments often contain exactly what attackers want:
Cloud credentials
Deployment keys
Package publishing tokens
GitHub tokens
Secrets
Build permissions
Production-adjacent access
If a compromised dependency runs during CI installation, the attacker may gain access to a machine that is far more privileged than an ordinary developer workstation.
This is one reason organizations should never assume that package installation is a harmless preliminary step.
The Hidden Risk of Environment Files
.env Files Remain a High-Value Target
Environment files frequently contain API keys, database credentials, service tokens, and internal endpoints.
Developers may consider .env files temporary configuration rather than sensitive assets.
Attackers do not make that distinction.
When an infostealer searches broadly across a development workstation, .env files can become one of the easiest ways to discover secrets that were never intended to leave the machine.
Why npm Install Deserves More Attention
Installation Is an Execution Event
A common misconception is:
“I only installed the package. I
In reality, npm package installation can execute lifecycle scripts and trigger build tooling.
That means the boundary between installing software and executing software is much thinner than many developers realize.
For security-sensitive environments, dependency installation should therefore be treated as code execution.
Deep Analysis
Understanding the Attack Chain
At a high level, the campaign can be represented as:
Compromised Package
|
v
npm install | v node-gyp / lifecycle execution | v
Python-based execution path
|
v
Obfuscated JavaScript payload
|
+-+
| |
v v
Environment discovery Credential theft
| |
+-+–+
|
v
Credential validation
|
v
Exfiltration
|
v
GitHub-controlled storage
|
v
Package/repository poisoning
|
v
Further propagation
Defensive Dependency Inspection
Before deploying or updating a dependency, security teams can inspect package metadata and lifecycle scripts.
npm view @7nohe/openapi-react-query-codegen versions --json
Inspect a specific version:
npm view @7nohe/[email protected] scripts --json
Review package metadata:
npm view @7nohe/[email protected] dist --json
Inspect the local dependency tree:
npm ls --all
Search a project for suspicious lifecycle hooks:
grep -R "\"preinstall\"" package.json . 2>/dev/null grep -R "\"postinstall\"" package.json . 2>/dev/null
Look for suspicious build configuration:
find . -name "binding.gyp" -o -name ".gyp"
Search for the reported payload filename:
find . -name "3FWCvzduYZg.js" -print
Search Git history for unexpected changes:
git log --all --stat --oneline
Look for suspicious recent commits:
git log --all --since="30 days ago" --oneline
Organizations can also search repositories for unexpected VS Code automation:
find . -path "/.vscode/" -type f -print
And inspect GitHub Actions configuration:
find .github/workflows -type f -maxdepth 1 -print
These commands are defensive investigation techniques intended to help identify suspicious package installations, repository modifications, and unexpected automation.
Credential Rotation Must Come First
If a machine executed an affected package, simply uninstalling the package is not enough.
The attacker may already have copied credentials.
Organizations should therefore assume that secrets accessible to the affected environment may have been exposed.
Prioritize rotation of:
GitHub tokens
npm tokens
PyPI tokens
RubyGems credentials
AWS credentials
Azure credentials
GCP credentials
Vault credentials
SSH keys
Kubernetes credentials
Docker credentials
VPN credentials
CI/CD secrets
Revocation should happen before cleanup whenever practical.
Otherwise, investigators may spend hours cleaning malware while stolen credentials remain usable.
Investigating GitHub
Security teams should review:
git log --all --since="14 days ago"
But repository history alone is not enough.
Organizations should also inspect:
New GitHub Actions workflows
Modified workflow permissions
New repository secrets
Unexpected deploy keys
Unexpected collaborators
VS Code tasks
Developer automation files
Claude Code hooks
CodeQL configuration
Changes to package publishing workflows
A compromised token can allow an attacker to make changes that look surprisingly legitimate.
Hunting for the SHA-256 Indicator
The reported SHA-256 indicator is:
8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3
On Linux, defenders can search known files with:
sha256sum suspicious-file.js
For broader investigation:
find . -type f -print0 | xargs -0 sha256sum 2>/dev/null | grep 8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3
The presence of the hash should be treated as an investigation indicator, not as the only detection mechanism.
Dependency Pinning Matters
Using broad dependency ranges can make supply-chain incidents significantly more difficult to contain.
For example:
{
"dependencies": {
"example-package": "1.2.3"
}
}
is more deterministic than allowing a wide range such as:
{
"dependencies": {
"example-package": "^1.2.3"
}
}
Lockfiles should also be committed and protected.
npm ci
is generally preferable to unconstrained dependency installation in reproducible CI environments because it uses the lockfile as the source of truth.
But Lockfiles Are Not a Complete Defense
Pinning dependencies reduces exposure to unexpected upgrades, but it does not solve every supply-chain problem.
A compromised version can remain malicious indefinitely.
An organization may also already have a compromised version recorded in its lockfile.
Therefore, dependency security requires multiple layers:
Dependency pinning
+
Lockfile integrity
+
Package reputation
+
Malware scanning
+
Build isolation
+
Least privilege
+
Credential rotation
+
Repository monitoring
+
CI/CD hardening
No single control is sufficient.
Least Privilege for Publishing Tokens
Publishing tokens should never provide more access than necessary.
If a developer needs to publish one package, that credential should not automatically provide unrestricted access across every organization package.
The same principle applies to CI/CD.
A build job that only needs to publish an npm artifact should not simultaneously have broad AWS administrator credentials, GitHub organization-level write permissions, and unrestricted access to unrelated repositories.
Supply-chain attacks thrive on excessive privileges.
Provenance Should Be Treated as a Layer
One of the most important lessons from this incident is the difference between authenticity and security.
A valid provenance statement can provide valuable evidence about an artifact’s origin.
But if the trusted build pipeline is compromised, an attacker may still produce an artifact that passes provenance verification.
Therefore:
Provenance is evidence. It is not immunity.
Organizations should combine provenance with source review, workflow protection, build isolation, artifact scanning, and runtime controls.
What Undercode Say:
- The Developer Has Become a High-Value Target
Developers now sit at the intersection of source code, cloud infrastructure, package registries, CI/CD systems, and production environments.
2. That Makes Developer Machines Extremely Valuable
Compromising one workstation can provide access to dozens of unrelated services.
3. Package Managers Are Security Boundaries
An npm install operation should no longer be treated as harmless.
4. Installation Scripts Deserve Security Review
preinstall, install, and postinstall hooks can execute code before developers ever interact with the package.
5. Build Tools Can Become Attack Vectors
The abuse of binding.gyp demonstrates how legitimate development infrastructure can be repurposed.
- Configuration Files Can Become Executable Attack Surfaces
The malicious workflow did not need a traditional executable installer.
7. The Attack Was Designed for Scale
Credential theft alone would have been serious.
- The Worm Component Makes It Far More Dangerous
Stolen credentials could potentially be used to compromise additional packages and repositories.
- npm Is Only One Piece of the Puzzle
The malware reportedly targeted npm, PyPI, and RubyGems credentials.
10. Cross-Ecosystem Propagation Is the Nightmare Scenario
One compromised developer environment can potentially become a bridge between multiple software ecosystems.
- GitHub Is Becoming Part of the Supply Chain
Repositories are not simply places to store source code anymore.
12. GitHub Actions Are Infrastructure
A compromised workflow can influence what software organizations build and distribute.
- Workflow Security Deserves the Same Attention as Application Security
Teams should protect workflows with restrictive permissions and strong review processes.
14. Provenance Is Valuable but Limited
A valid signature or attestation should not end an investigation.
- Trust Must Extend Through the Entire Build Chain
Source code, workflow, dependencies, secrets, builders, and publishing credentials all matter.
- CI/CD Environments Should Be Treated as High-Value Assets
They frequently contain more privileges than developer laptops.
17. CI Credentials Should Be Short-Lived
Long-lived secrets give attackers a much larger window of opportunity.
18. Cloud Credentials Are Especially Dangerous
A stolen developer credential can potentially become a cloud compromise.
19. Kubernetes Credentials Raise the Stakes
A compromised kubeconfig or service account can potentially expose entire workloads.
20. SSH Keys Should Not Be Forgotten
They can provide persistent access even after the original malware disappears.
21. .env Files Remain a Persistent Problem
Secrets frequently accumulate in local development environments.
- Shell History Can Reveal More Than Expected
Developers sometimes accidentally place tokens and credentials directly into commands.
- Cryptocurrency Wallets Show How Broad the Collection Was
The malware was reportedly interested in much more than software-development credentials.
- Anti-Analysis Shows That the Attackers Expected Investigation
Security researchers were not an afterthought.
- Malware That Checks for Security Tools Is Adapting
Attackers increasingly understand how automated analysis works.
- Legitimate Cloud Services Can Become Exfiltration Infrastructure
Using GitHub repositories for stolen data can make malicious traffic harder to distinguish from normal developer activity.
27. Security Teams Need Repository-Level Monitoring
Unexpected commits can be as important as suspicious network traffic.
28. Developer Tooling Needs Supply-Chain Protection Too
VS Code tasks and AI coding-agent hooks can become attack surfaces.
- AI Development Tools Add Another Layer of Risk
Modern coding agents can interact with repositories, files, shells, and credentials.
30. Claude-Related Files Being Targeted Is Significant
Attackers are clearly paying attention to the modern AI-assisted development ecosystem.
31. Automated Updates Need Guardrails
“Latest version” should never automatically mean “trusted version.”
- Organizations Should Know Exactly What Their CI Installs
Blind dependency resolution creates unnecessary exposure.
33. Dependency Inventory Is Essential
You cannot protect packages you do not know you are using.
- Lockfiles Should Be Treated as Security Artifacts
They provide reproducibility and make dependency changes easier to investigate.
35. Security Teams Need Historical Visibility
Knowing which version was installed last week can be crucial during incident response.
36. Token Rotation Must Be Comprehensive
Changing one GitHub token does not help if AWS or npm credentials were also stolen.
37. Incident Response Should Assume Credential Exposure
If malicious code executed with access to secrets, those secrets should be considered potentially compromised.
38. Supply-Chain Security Is Becoming Identity Security
The most valuable asset may no longer be the package itself.
39. The Real Target Is Trust
Attackers exploit the assumption that trusted development infrastructure is inherently safe.
40. The Biggest Lesson Is Simple
Your dependency tree is part of your attack surface.
✅ The Package Had a Significant Download Footprint
The article reports that @7nohe/openapi-react-query-codegen receives more than 150,000 weekly downloads, making a compromise potentially impactful beyond a small group of users.
✅ Multiple Malicious Versions Were Reported
Aikido Security reportedly identified numerous malicious releases published within a short period, supporting the characterization of the event as a coordinated supply-chain compromise.
✅ The Attack Used Installation-Time Execution Techniques
The reported use of binding.gyp, Python evaluation, and package lifecycle mechanisms is consistent with the broader technical description of an attack designed to execute during installation.
⚠️ Attribution to TeamPCP Should Remain Unconfirmed
The reported tradecraft has similarities to TeamPCP-linked activity, but similarity alone does not establish attribution. The responsible actor should therefore be described as unresolved unless additional evidence emerges.
⚠️ Provenance Does Not Equal Safety
A valid build attestation can establish useful information about artifact origin, but it cannot independently prove that a compromised workflow, repository, or build environment was safe.
Indicators of Compromise
Malicious Package Versions
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
@7nohe/[email protected]
Malicious Payload
3FWCvzduYZg.js
Reported SHA-256
8e5d1af68ca340ae0c6e8132cb00c686ec2d60502c1994d94ce353d1472ad5a3
Immediate Response Checklist
1. Identify Affected Installations
Search developer workstations, CI runners, build containers, and dependency lockfiles for affected package versions.
2. Stop Further Installation
Prevent CI systems and developer environments from installing known malicious versions.
3. Revoke Credentials
Assume credentials available to systems that executed the malicious package may have been exposed.
4. Rotate Cloud Secrets
Prioritize AWS, Azure, GCP, Vault, Kubernetes, and other infrastructure credentials.
5. Rotate Registry Credentials
Review and rotate npm, PyPI, and RubyGems publishing credentials.
6. Inspect GitHub
Look for unexpected commits, workflows, deploy keys, repository changes, VS Code tasks, and developer-agent configuration.
7. Review CI/CD Logs
Search for suspicious network connections, unexpected package publishing, unusual workflow executions, and unknown commands.
8. Examine Package Registries
Determine whether compromised credentials were used to publish or modify other packages.
9. Investigate Downstream Repositories
If the worm obtained GitHub access, inspect repositories that the affected identities could modify.
10. Preserve Evidence
Before wiping affected systems, preserve relevant logs, package files, timestamps, Git history, and authentication records when incident-response procedures allow.
Prediction
(+1) Supply-Chain Security Will Move Closer to Developer Identity Protection
Over the next several years, organizations are likely to stop treating dependency security as merely a software-composition problem.
The industry is moving toward a broader model in which packages, developers, build systems, repositories, credentials, CI/CD pipelines, and cloud identities are treated as one connected security boundary.
That shift will likely accelerate as AI-assisted development expands.
Coding agents increasingly interact with source repositories, terminals, package managers, cloud services, and development credentials. A supply-chain compromise like this demonstrates why those capabilities need strong isolation and least-privilege controls.
The organizations that adapt early will have a significant advantage.
The ones that continue assuming that a package manager is simply a convenient way to download libraries may eventually discover that their most dangerous security incident began with something as ordinary as:
npm install
The Bigger Warning
The most frightening aspect of this campaign is not the size of the malicious JavaScript file, the obfuscation, or even the number of compromised package releases.
It is the trust relationship.
Developers trusted the package.
The build system trusted the workflow.
The package manager trusted the release.
The CI pipeline trusted the dependency.
And the organization trusted the credentials already present on the machine.
Attackers only needed to break one link.
Once they did, the rest of the supply chain became a potential path forward.
That is the uncomfortable reality of modern software development: the code you write may be yours, but the software you depend on can become someone else’s doorway into your environment.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.twitter.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
