Apr 1 2026, 05:28 PM, updated 3w ago
QUOTE
In late March and early April 2026, the Axios npm package was the victim of a high-impact supply chain attack, while the npm registry itself was not "hacked" in the traditional sense. Instead, an attacker gained control of a lead maintainer's account to publish malicious versions of the library.
QUOTE
Safe versions: Anything 1.14.0 or lower, or 0.30.3 or lower.
Malicious versions: 1.14.1 or 0.30.4
Malicious versions: 1.14.1 or 0.30.4
in my case, i don't have npm container running, but it does auto update image.....
QUOTE
If a Docker image containing the malicious Axios versions (1.14.1 or 0.30.4) was downloaded but never run as a container, you are likely safe from the Remote Access Trojan (RAT) that triggers during the package's execution. However, the presence of the image on your system is a significant risk that must be addressed immediately to prevent accidental activation.
Why You Are Likely Safe (For Now)
Execution-Based Trigger: The 2026 npm hack involving Axios relies on a postinstall script in the plain-crypto-js@4.2.1 dependency. This script only runs when npm install is executed—typically during a docker build or when a container starts if it's configured to install dependencies at runtime.
Dormant Threat: If the image was pulled (downloaded) rather than built locally, and the container was never started, the malicious code remains dormant as a static file in your Docker storage.
Immediate Actions to Take
Even if the container hasn't run, you must sanitize your environment to ensure no one accidentally deploys it.
Why You Are Likely Safe (For Now)
Execution-Based Trigger: The 2026 npm hack involving Axios relies on a postinstall script in the plain-crypto-js@4.2.1 dependency. This script only runs when npm install is executed—typically during a docker build or when a container starts if it's configured to install dependencies at runtime.
Dormant Threat: If the image was pulled (downloaded) rather than built locally, and the container was never started, the malicious code remains dormant as a static file in your Docker storage.
Immediate Actions to Take
Even if the container hasn't run, you must sanitize your environment to ensure no one accidentally deploys it.
using truenas
so what i did was, go to truenas shell...
CODE
Grep Search: If you have a long list of images, you can search for a specific ID:
summary
CODE
Find the Container ID:
docker ps -a | grep <IMAGE_ID_OR_NAME>
Remove the Container:
docker rm <CONTAINER_ID>
Now Delete the Image:
docker rmi <IMAGE_ID>
docker ps -a | grep <IMAGE_ID_OR_NAME>
Remove the Container:
docker rm <CONTAINER_ID>
Now Delete the Image:
docker rmi <IMAGE_ID>
because i use dockge, i just click stop, inactivate. this releases it.
then i can do the
CODE
docker rmi -f <IMAGE_ID>
then
CODE
docker image prune -a
This removes all images that are not currently associated with a running container.
for safest,
Option 3: Nuclear Cleanup (Best for Security)
Since you are dealing with a potential npm hack, it is safer to wipe all stopped containers and unused images at once:
CODE
docker system prune -a
(This will ask for confirmation and then delete all stopped containers and all images not currently running.)
lastly, for my docker compose, since i use watch towerr for auto updates, just add this to stop watch towerr from auto updating npm.
3. Use Environment Variables (Docker Compose)
If you use Docker Compose, add this environment variable to your Watchtower service to stop all automatic updates globally:
yaml
CODE
services:
watchtower:
image: containrrr/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_MONITOR_ONLY=true
watchtower:
image: containrrr/watchtower
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_MONITOR_ONLY=true
can remove later once this issues dies down (or not). Or set watchtowerr to not update daily, and defer updates to every 2-3 weeks to avoid a situation like this the next time.
if you are a homelabber and u use npm for your docker container, take action NOW if you haven't already
In my situation, i didn't have the container actively running, so dodged a bullet narrowly. but it did make me rethink the auto update for npm that has been targeted more than once. so either a longer deferred update, or not auto update might be in order
Also this is another reminder, WHY, you need to pay close attention to how you deploy your docker containers. so it's not running as root. so create a docker user, then use that for docker containers for deployment. hopefully that will limit any issues.
This post has been edited by Moogle Stiltzkin: Apr 1 2026, 05:40 PM
Quote
0.0126sec
0.44
8 queries
GZIP Disabled