PolinRider in npm: which release actually executed?
A package recorded in a lockfile and a process that executed its code provide different evidence. Response needs to connect the release with its entrypoint and the authority available on the host.
Leggi in portogheseBy Pentesty
What the November research establishes
In its November 4, 2026 analysis, Sonatype identified loaders in 12 releases across ten compromised npm packages. The examined manifests had no consumer installation or post-installation hooks: code could activate when an affected entrypoint loaded or the bundled application started. A lockfile entry alone does not establish execution.
The loaders share an Ethereum wallet used to resolve infrastructure, overlapping previously documented PolinRider activity. Sonatype does not thereby establish a common operator for GhostAction and PolinRider. GitGuardian’s October 27 context also preserves that distinction. This November 9 analysis addresses release trust, without attributing new compromises to businesses.
Build a trail from package to process
Propose a record for each service: repository, delivered release, approved lockfile, produced artifact and execution environment. Connect those records through identifiers and timestamps. A dependency inventory answers what was selected; delivery records should show where that selection was distributed.
Next, identify the file actually loaded. A package can expose different paths depending on imports and application configuration. Document which path was used, which records support that conclusion and where gaps remain. Missing telemetry requires a limited conclusion, with a deadline and an owner for further investigation.
Approval needs to extend beyond installation
For an authorized exercise, create a harmless internal dependency with a documented function and a local marker when that function is called. Use an isolated environment without production credentials. Compare installation, application testing and startup, recording the stage at which the marker appears. Do not reproduce the campaign loader.
This exercise tests whether review follows the executed function as well as declared installation scripts. Require explicit approval for entrypoint changes and the artifact destined for production. The expected result includes a demonstrable block on an unapproved release while legitimate operation remains possible.
Connect the host to the credentials it could use
Prepare an authority matrix for each context: developer workstation, runner, build server and deployed service. Record credential issuers, permitted resources and session duration. This structure supports containment decisions without publishing secret values in the report.
Use synthetic identities to test revocation at the issuing service and acceptance of the replacement only within its intended scope. If investigation finds malicious execution, coordinate evidence preservation and host recovery with the responsible teams. Removing a version from a project does not by itself establish the state of earlier processes and access.
Define when delivery may resume
Acceptance should combine a reviewed replacement dependency, a rebuilt artifact and records from the environment that received it. Specify who confirms each step and how exceptions will be reassessed. A functional test confirms expected activity; security assessment also needs to cover authority and effects beyond that activity.
Also compare two authorized delivery paths: one that should reject an unapproved artifact and another that distributes the reviewed replacement. Use only harmless files in this test. Connect the internal repository’s decision to the identifier received by the consumer, demonstrating that enforcement applies where the team actually obtains its dependency.
Preserve earlier delivery records after replacement. Mark the investigated period separately from the start of accepted operation. This allows the team to ask whether a credential was valid when a process existed, without presenting a current test as proof that nothing happened previously. Approval should include what remains unknown, which owner must resolve the gap and when that decision will be reviewed. Retain the evidence owner’s decision alongside the artifact identifier and service acceptance record.
Connect this work with workflow and workstation review in the GhostAction case. Different execution paths can reach credentials supporting the same business. The useful release question is which evidence supports trust in that code, that process and that identity.
Frequently asked questions
Does blocking installation scripts complete the assessment?
No. The research describes activation during code loading or startup. Assessment needs to include the entrypoint the application actually uses.
Does a lockfile establish host compromise?
It establishes a dependency selection in the examined record. A conclusion about execution needs other evidence, with limitations made explicit.
Does the technical connection prove one operator?
No. Shared infrastructure and mechanisms are technical links; the reviewed sources do not establish common authorship for GhostAction and PolinRider.
Must a team execute malware to test its process?
No. Use a harmless dependency you control, local markers and synthetic identities within an authorized, isolated scope.
Sources and references
- Sonatype: npm release research, November 4
- GitGuardian: GhostAction and PolinRider context, October 27
Original Pentesty analysis, published November 9, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.