npm Software Supply Chain Attack

sushant.kumar

Hi All,

Is this npm Software Supply Chain Attack also affect our spryker project?

Is there any way to check the project is affected or not?

Thanks

fsmeier

Heyhey @sushant.kumar ,

are you referring to https://www.securityalliance.org/news/2025-09-npm-supply-chain ?

This was topic of internal discussions in the beginnin of September and there I can quote one of our main frontend architects:

nothing is required on customer side as all the packages with malicious code has been removed from the npm.

Does this answer your question?

All the best,

Florian

sushant.kumar

Hi Team,

We have received these details from security team:-

Background and Overview

Summary: “Shai Hulud” npm Supply Chain Attack

keyboard_arrow_down

“Shai Hulud” represents one of the most severe JavaScript supply chain attacks to date.

Target: Multiple URLs were compromised hosting malicious npm packages.
Attack Type: Self-replicating supply chain worm
Campaign Name: “Shai Hulud” (named after the attacker’s GitHub repository, referencing Dune)
Key Details

keyboard_arrow_down

Over 500 npm packages compromised (as of 19 September 2025), including widely used libraries such as @ctrl /tinycolor, ngx-bootstrap, ng2-file-upload, and several CrowdStrike packages.
Malware behavior:
Executes a post-install script that downloads a free security scanning tool TruffleHog to scan for secrets (e.g., GitHub tokens, AWS keys).
Discovered credentials arepublicly exposed via GitHub repositories titled “Shai-Hulud Migration.”
Injects malicious GitHub Actions workflows into compromised repositories to exfiltrate additional data.
Private repositories are forcefully made public, exposing source code and infrastructure details.
Self-replication mechanism:
Once a developer’s package is infected, the worm automatically compromises all other packages the developer has access to.
Possible Impact

keyboard_arrow_down

Exposure of sensitive credentials (GitHub, npm, cloud providers).
Public leakage of proprietary source code and internal configurations.
Increased risk of follow-up attacks due to stolen code and secrets.
Erosion of trust in open-source dependencies and software integrity.
Potential compromise of CI/CD pipelines, especially via GitHub Actions.

Key Guidance

Following up on our earlier communication regarding the supply chain attack, we have identified that an additional 500+ npm-package versions have been compromised.

The list of impacted packages can be found in the link below.
https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised
https://phoenix.security/npm-shai-hulud-tinycolor-compromise/
https://www.truesec.com/hub/blog/500-npm-packages-compromised-in-ongoing-supply-chain-attack-shai-hulud

Could you please let me know, is there any update or change we have to perform for our spryker project? Please suggest.

Regards,
Sushant

fsmeier

Heyhey @sushant.kumar ,

do you have the possibility to create an official support ticket through the portal and let me know the case number?

In the meantime I will already try to gather information from our security team.

All the best,

Florian

sushant.kumar

Hi Florian,

Thank you for your quick response.

Yes, I have raised this on the support portal with case number 00070036. This issue has also impacted a large set of projects, both on the software level as well as the infrastructure level.

Regards,

Sushant

fsmeier

Heyhey @sushant.kumar ,

the support ticket should now be updated - after consulting with our security team I can tell you that there is no action needed reg. Spryker code. We are not affected.

All the best,

Florian

sushant.kumar

Hi Florian,

Thanks for your quick response on this security concern. Really appreciated.

Regards,

Sushant

victor.vanherpt

Hi there! @fsmeier
We are also looking to take action, one suggested action is to pin the packages to specific versions (removing carets or tildes).
Due to how spryker is built, this can be a nightmare with all dependencies in the project.

Is spryker planning to provide some mitigation?

fsmeier

Heyhey @victor.vanherpt ,

you mean to take action to be on the safe side in the future if these things ahppen again?

What for mitigation would you expect? I can ask the team but I think i am not fully understanding what you mean right now.

All the best,

Florian

victor.vanherpt

I mean, if we have not pinned dependencies, we are safe only until an npm update will pull packages that are infected, no?

For the future, it'd be greate to pin them, of course , but is the dependency tree verified on spryker's side? Is there a place we can go to have any more information?

victor.vanherpt

It's just that lately I see more and more npm packages compromised in some way or another

fsmeier

But isnt the pinning then responsibility of a project? Also with a proper lock file this should also not be a problem or am I missing something here?

victor.vanherpt

ok, I just checked again, and you're right, I thought the NPM packages worked in a similar fashion to our composer packages, where dependencies are traversed (I assumed spryker composer packages could add npm dependencies 😅).

For the longer term, still, we treat our package.json as "vendor code", as we start from the demoshop and try to keep demoshop-code as vanilla as possible to ease upgrades.

For now, I can pin our packages manually, but then every upgrade I'll have to go through the process again, and I guess diffing will become more difficult.