Executive summary
Researchers at Aikido, Socket and Wiz reported malicious versions of four packages in the SAP development ecosystem on 29 April 2026. Their analyses describe installation scripts that launch a credential-stealing payload, affecting the developer workstation or build environment where the package runs. Wiz attributes the operation to TeamPCP with high confidence, while the scope of exposure in any individual organisation still requires investigation. We assess it is likely (B2) that removing an affected dependency alone will leave important response work unfinished, because the reported payload targets credentials that can provide access to other services and repositories.
Contextual background
The affected packages support SAP development and deployment workflows. Socket explains that the @cap-js packages belong to the Cloud Application Programming Model ecosystem and that mbt is the Cloud MTA Build Tool. In particular, @cap-js/sqlite is a database-service package in that ecosystem; its name should not be treated as evidence that the general SQLite project was compromised.
The reports describe malicious releases of otherwise legitimate packages. This is a distribution-integrity incident, so a review limited to ordinary vulnerability-version comparisons can miss the relevant question: did the malicious version execute? An organisation’s current dependency manifest may describe the state after an update or rollback. Our recommendation is to retain the historical lockfile, package cache and build records associated with the suspected installation.
The four-version list is a concrete starting point, not a count of compromised organisations. Download estimates or a package’s popularity do not establish how many installations executed the payload, how many machines were affected or which credentials were available. Keep those quantities separate in incident communications.
Affected versions
The following versions are identified in the Aikido and Socket reports. They are the complete four-package set covered by this article.
| Package | Malicious version |
|---|---|
@cap-js/sqlite |
2.2.2 |
@cap-js/postgres |
2.2.2 |
@cap-js/db-service |
2.10.1 |
mbt |
1.2.48 |
Search direct and transitive dependency records, internal mirrors and retained build artefacts. Record whether a match is a manifest reference, a downloaded archive, an installed package or evidence of execution. Those are different levels of exposure. Where installation behaviour cannot be established, document that uncertainty and assess the secrets available to the machine rather than declaring it unaffected solely because the package is no longer present.
Technical analysis
Aikido’s analysis describes a new preinstall hook that starts setup.mjs, which obtains a Bun runtime and launches execution.js. The malicious behaviour therefore begins during dependency installation, before the application using the package needs to run. Aikido also notes that ordinary package files could remain consistent with the legitimate release, so an apparently normal application build is not a sufficient integrity check.
Wiz’s archived analysis describes collection of development and cloud secrets, encrypted exfiltration through GitHub repositories and logic intended to propagate through compromised access. It also describes changes aimed at developer-tool startup paths. These capabilities explain why the investigation should include repository activity and newly introduced automation, as well as the original package files.
The reports identify GitHub as part of the transport and propagation infrastructure. That does not make every connection to GitHub suspicious or justify blocking the entire service without considering operational consequences. Our recommendation is to correlate the identity, repository, action and timing: a package-install process followed by an unexplained public repository creation is more useful than the destination hostname alone.
Separate capability from observed execution. A payload may contain code to retrieve secrets from several providers while the affected machine has access to only one. Conversely, a failed attempt against one provider does not clear credentials available through another path. Establish the environment and permissions of the process that ran, then use provider-side audit records to test what happened next.
Impact assessment
The researchers’ findings place developer workstations and continuous integration and continuous delivery (CI/CD) systems at the centre of exposure. Reported credential targets include GitHub, npm, cloud services and Kubernetes-related access. The relevant scope is what the executing environment could reach, not simply the application that declared the dependency.
Our recommended assessment distinguishes workstation, build-worker and publishing identities. A developer machine may hold interactive sessions and local credentials; a release worker may have narrowly scoped but powerful publishing permissions. Enumerate those rights from the actual configuration. Avoid assuming either that every available secret was stolen or that a short-lived worker had no consequential access.
Consider downstream integrity as a separate workstream. Review repositories, packages and deployment artefacts that the exposed identities could modify. Compare changes with authorised activity and preserve suspicious releases for investigation. Revoking a token limits future use but does not reverse a malicious commit or package already published with it.
Indicators and hunting leads
These selected artefacts are described by Aikido and Wiz. File names are contextual leads; validate their contents and origin.
| Artefact | Reported role | Suggested investigation |
|---|---|---|
setup.mjs |
Installation-stage loader | Relate the file to an affected package archive and installation event |
execution.js |
Credential-stealing payload | Preserve the sample and compare with the primary reports’ hashes |
OhNoWhatsGoingOnWithGitHub |
Commit-search marker used by the malware | Review matching repository activity and the identity responsible |
.claude/settings.json and .vscode/tasks.json |
Developer-tool configuration paths used in propagation logic | Check newly added startup actions against approved project configuration |
The last two paths also have legitimate uses. Do not delete every matching configuration file across the organisation. Review content, change history and associated execution evidence. Similarly, a standard Bun installation is not itself an indicator of compromise; the unexpected relationship between a package install, loader and subsequent secret access is the relevant signal.
Detection and hunting guidance
Our recommended hunt follows the credential path rather than stopping at package detection. Start with installations of the four versions, then associate each with a host, build job, operating identity and time interval. Preserve the package archive and relevant logs. Identify which credentials were mounted, cached or otherwise available to that process, using the organisation’s configuration records.
Next, inspect the connected services for unexpected activity: new repositories, changes to release automation, package publications, altered permissions and access inconsistent with the identity’s normal purpose. These are recommended investigation questions, not a claim that every activity occurred in every victim environment. Where the logs do not answer a question, carry that gap into the containment decision.
For CI/CD systems, examine both successful and failed jobs. An installation-time payload may run before a later build step fails. Our recommendation is to avoid treating a failed pipeline result as proof that no code executed. Correlate the actual step history with endpoint or runner telemetry and the provider’s audit trail.
Incident response guidance
The Aikido report recommends credential rotation after affected-package installation and explicitly extends the scope beyond npm tokens. Use the package findings to begin that assessment, then map each credential to an owner and a service-specific revocation procedure. Record which actions are completed and which remain uncertain.
Our recommended containment sequence is to stop further execution of the affected versions, isolate systems with evidence of malicious execution, preserve the relevant artefacts and recover through trusted software sources. Investigate developer-tool startup configuration and repository changes before reopening affected projects or reusing the worker. Rebuild disposable workers from a trusted baseline where appropriate to the organisation’s operating model.
Rotate or revoke exposed secrets from a trusted administrative environment after containing the path that could steal replacements. Review active sessions and application permissions as well as long-lived tokens. Then validate downstream repositories and releases that the compromised identities could change. Preserve evidence of unauthorised publications and coordinate corrective actions with the relevant registry or service owner.
Recovery should include a clean build using verified dependencies, review of publishing permissions and an audit of unexpected repository changes. Record the basis for concluding that affected credentials and persistence paths have been addressed. A successful build is useful functional evidence, but does not alone establish that the earlier compromise had no downstream consequences.
Our recommended recovery record should connect each secret to the job or workstation that could access it, the time it remained valid, its permissions and the evidence of revocation. This avoids a misleading completion count based only on the number of tokens changed. A publishing credential and a read-only service token create different downstream questions even when both were stored on the same runner.
Assign ownership for registry and repository checks separately from endpoint recovery. For example, rebuilding a runner can close the local execution path while leaving an unauthorised package release available to other teams. Conversely, removing a bad release does not resolve access obtained through a stolen cloud credential. Treat these as linked response tasks and retain the evidence that closes each one.
Threat intelligence context
Wiz attributes this operation to TeamPCP with high confidence, citing shared cryptographic material and technical overlaps. It also states that references to earlier Shai-Hulud operations do not establish whether those operations belonged to the same actor. Keep the branding, the technical observations and the publisher’s attribution as separate fields.
The following ATT&CK mappings are our analysis of the reported behaviours, not additional observations about victims.
| Technique | Basis in the reports |
|---|---|
| T1195.002: Compromise Software Supply Chain | Malicious package releases distributed through a trusted development workflow |
| T1552.001: Credentials In Files | Payload access to local credential material |
Mitigation recommendations and outlook
Our recommended priorities are to reduce unnecessary secrets in dependency-install environments, separate package evaluation from release authority and retain enough build history to investigate an unexpected release. Review who can alter publishing workflows and how those changes are approved. Test the emergency process for rejecting a package version in internal mirrors and replacing it with a verified alternative.
For ongoing monitoring, follow the original researchers and package maintainers for revised scope, while retaining the version of the evidence used for each response decision. This article describes the four SAP ecosystem versions reported on 29 April 2026; later discoveries require their own assessment. The immediate operational objective is a defensible account of where the payload ran, what access was available and which downstream changes must be corrected.
