DEV Community: Minimus

[Boost]

Minimus — Thu, 19 Mar 2026 13:45:56 +0000

When Projects Fail: Why Companies Should Treat Open Source as Infrastructure

Kat Cosgrove ・ Mar 18

#opensource #security #kubernetes #devops

New Vulnerabilities in runC Allow Container Escape

Minimus — Wed, 17 Dec 2025 14:00:00 +0000

Minimus builds secure, minimal container images and publishes technical research on container security.

Originally published on minimus.io. Shared here for the developer community.

Recently, three high severity vulnerabilities were disclosed in runC, the low-level container runtime used by Docker, containerd, Kubernetes, and other container platforms. By exploiting these vulnerabilities, it is possible to bypass container isolation boundaries and break out of the container to the underlying host.

What is runC?

runC is the low-level container runtime that Docker, containerd, Kubernetes, CRI-O and others rely on to actually create containers and set up their isolation. While it exposes a CLI, its real role is behind the scenes: configuring namespaces, cgroups, mounts, and setting up the container’s filesystem and other interfaces before your container process starts.

Why runC Vulnerabilities Matter for Docker and Kubernetes Security

Because runC is responsible for container isolation, any vulnerability affecting runC potentially affects the security boundary between the isolated container and the underlying host. This is why, for example, any workload running on top of Kubernetes can be affected.

Breaking Down CVE-2025-31133: “Masking” Turns Into Arbitrary Mount Gadget

The OCI runtime specification has a maskedPath feature that is supposed to hide sensitive files and directories (e.g. /proc/kcore, /proc/sysrq-trigger) by mounting something harmless on top. This protects against privileged users in non-user-namespaced being able to write to files or access directories that would provide sensitive information or allow containers to perform destructive or other privileged operations on the host.

Files are masked by mounting the container’s /dev/null on top of the masked path.

In vulnerable versions of runC, the issue is that runC didn’t verify that the source of the bind-mount (container’s /dev/null) was a real /dev/null. If an attacker races and swaps it with a symlink to an attacker-controlled path, they could cause runC to bind-mount an arbitrary source path to a path inside the container, which can lead to a container escape.

Breaking Down CVE-2025-52565: `/dev/console` Bind-Mount Race

This is pretty similar in concept to the above mentioned CVE, but with a different target. runC bind-mounts /dev/pts/$n to /dev/console inside the container for interactive consoles. If an attacker races and swaps it with a symlink to an attacker-controlled path, runC will bind mount whatever that symlink points to.

Since /dev/console bind mount happens before maskedPaths and readonlyPaths security features are applied, the attacker can potentially gain write access, which can lead to a container breakout.

Breaking Down CVE-2025-52881: LSM Bypass & Arbitrary `/proc` Write Gadgets

This is a more advanced variation of an older procfs/LSM vulnerability CVE–2019-19921. The flaw is in how runC handles writes to a /proc during container setup.

With the right timing and mount tricks, an attacker can potentially redirect these writes to other, more dangerous files such as sysrq-trigger or core-pattern, which could lead to a container escape bypassing LSM label protections.

What Is the Exploitability of These runC Vulnerabilities?

In order to be able to exploit above mentioned vulnerabilities, an attacker would need the ability to start containers with custom mount/runtime configs or to supply Dockerfiles that use custom mounts/clever build tricks via different tactics of a supply chain attack. Such can be achieved via malicious container images or Dockerfiles.

Which runC Versions Are Affected?

CVE-2025-31133

Affected versions: All

Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3, and later

CVE-2025-52565

Affected versions: v1.0.0-rc3 and later

Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3, and later

CVE-2025-52881

Affected versions: All

Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3

Next Steps: How to Patch and Mitigate Vulnerable runC Versions

If you are running vulnerable versions of runC, upgrade to 1.2.8, 1.3.3, 1.4.0-rc.3 accordingly (or follow with vendor equivalent patches and instructions)
Verify the sources of container images and Dockerfiles
Follow security hygiene/good practices:
- Use user namespaces to map container root to an unprivileged user on the host system
- Prefer rootless containers when possible
- Run applications as non-root inside the container to minimize risks

How can Minimus help?

Our team is constantly tracking vulnerabilities that might expose our images and packages to potential risks. As a provider of secure, minimal container images, we ensure that foundational components stay hardened and up to date.

When issues like these runC CVEs are disclosed, we patch and rebuild affected components, making sure that images that are relying on runC are secure from the above mentioned vulnerabilities.

If you want to stay ahead of container-runtime vulnerabilities, explore Minimus images.

Originally published on minimus.io: https://www.minimus.io/post/new-vulnerabilities-in-runc-allow-container-escape-what-docker-and-kubernetes-users-need-to-know

Sha1-Hulud 2.0 - The Second Coming: A Technical Breakdown

Minimus — Mon, 15 Dec 2025 19:19:17 +0000

Minimus builds secure, minimal container images and publishes technical research on container security.

Originally published on minimus.io. Shared here for the developer community.

Sha1-Hulud 2.0 - The Second Coming: What You Need to Know

Earlier this year on September 25, the open-source software community was hit by a supply chain attack called Sha1-Hulud, in which a self-replicating worm heavily impacted the NPM ecosystem by compromising hundreds of open-source software packages.

After gaining initial access to a victim’s endpoint via the compromised third party package, the malicious script scanned the environment for credentials including GCP, AWS, Azure, and GitHub Personal Access Tokens. Once found, the data was exfiltrated to the endpoint controlled by the threat actor. On November 24th, Sha1-Hulud returned with a new version. Here is what you need to know.

Sha1-Hulud 2.0: What happened?

A new variant of Sha1-Hulud Software Supply Chain attack emerged
Over 25K GitHub repositories were affected
Hundreds of NPM packages were infected, including few of the famous projects
- Postman
- Zapier
- Posthog
Thousands of files were exfiltrated containing:
- NPM tokens
- Cloud Service Providers keys (AWS, GCP, Azure)
- GitHub tokens
- GitHub actions secrets
Sha1-Hulud 2.0 is able to self-replicate and infect additional projects in the ecosystem

How the Sha1-Hulud 2.0 Attack Works

Sha1-Hulud 2.0 uses a layered, multi-stage infection process designed to blend into normal package installation workflows. By abusing npm lifecycle scripts, and harvesting cloud and GitHub credentials, the worm can silently compromise a developer’s environment and spread across the broader ecosystem.

Step 1: `package.json`

When a package is compromised, two files are added to the root directory of the package:

setup_bun.js
bun_environment.js

The infection is triggered by the following preinstall script that is added to package.json of the compromised package.

After a victim executes npm install, npm will execute lifecycle scripts where preinstall scripts will execute first (before the actual install). The same behavior will take place even if the victim is not directly interacting with the infected package and the package is coming as a transitive dependency; or if the installation fails, the preinstall script will run first.

Step 2: `setup_bun.js`

setup_bun.js serves as an entry point. Its main objective is:

Check if the Bun (JavaScript runtime) is installed on the victim’s endpoint
- This is an interesting behavior that was likely intended to avoid using Node.js and its protections, such as warnings about suspicious lifecycle scripts.

Depending on the operating system, it downloads and installs Bun if not present

Reload user’s PATH to make sure Bun binary is useable
Run bun_environment.js using Bun

Step 3: `bun_environment.js`

This is a heavily obfuscated JS file, over 200K lines of obfuscated code, and it is the heart of a Sha1-Hulud 2.0 worm. Its purpose is to:

Fingerprint victims environment
Collect environment variables
Enumerate local projects and Git repositories
There is an indication that Sha1-Hulud 2.0 is utilizing TruffleHog open-source tool secrets scanner to scan for secrets
- Scan for cloud service providers related secrets (GCP, AWS, Azure)

Abusing NPM tokens — once it obtained victim’s NPM tokens Sha1-Hulud 2.0 has control over the projects maintained by the victim, which allows the worm to perform a self-propagation step by updating and publishing packages with same preinstall script

If no GitHub or NPM tokens are found, it will fallback to deleting data in the victim’s endpoint home directory, depending on the operating system.

Step 4: Exfiltration via Public GitHub Repositories

The data collected by the NPM worm is exfiltrated via a public GitHub repository
- A random 18 characters long string generated for a repository name which is published as a public repository under a compromised account with a fixed description name Sha1-Hulud: The Second Coming.
- The repository contains several files with a double encoded Base64 string containing the collected victim’s data
- cloud.json
- contents.json
- environment.json
- truffleSecrets.json
- If no GitHub credentials are found, the worm will use other victims’ compromised GitHub credentials. This is why we see many different random repositories under the same account. One compromised account can publish several repositories containing exfiltrated data of several other victims.
- github/workflows directory containing discussion.yaml file

The injected workflow by the Sha1-Hulud will be triggered whenever someone creates or updates a GitHub discussion
Forced execution on a self-hosted runner — If a victim configured self-hosted runners, Github Actions runners will run arbitrary code supplied by the attacker
RUNNER_TRACKING_ID: 0 — known trick to suppress runner telemetry or GitHub tracking features
run: echo ${{ github.event.discussion.body }} — used to verify code execution. echo can be replaced with any arbitrary command

IOCs (Indicators of Compromise) for SHA1-Hulud 2.0

Preinstall scripts in package.json files
Unintended installation of Bun software
Public GitHub repository created with 18 digit random string under your account
setup_bun.js and bun_environment.js files present on an endpoint

What to Do if You Are Affected by SHA1-Hulud 2.0

Remediations steps should include the following:

Remove the infected packages and scan across all endpoints you suspect that might be affected
Rotate and revoke any affected credentials
Temporary restrict repository creation until the investigation is finished
Delete public repositories that were created by the Sha1-Hulud 2.0 worm
Apply third party dependencies hygiene:
- Constantly scan transitive dependencies for malicious activity
- Use reliable sources for installing third party OSS (commit hashes, trusted versions etc)
- If using NPM, think of applying npm ci instead of npm install for automated environments
Check for additional connected environments and accounts that might be affected

How can Minimus help?

After reading how Sha1-Hulud 2.0 is infecting projects across the NPM ecosystem and the possible damage, you probably understand that an endpoint can be compromised even if it does not interact with the infected package directly. It is enough to build an artifact containing an infected package as a transitive dependency to get infected by the NPM worm, and we all know how easy it is to miss that!

At Minimus, we make sure our images are built using trusted and verified OSS and third party components. By controlling the entire supply chain, endpoints utilizing our images are protected from such supply chain attacks. This eliminates a major source of stress for DevSecOps teams and developers, allowing them to rely on images that are secure by default rather than struggling to build safe, non-vulnerable image versions on their own.

Originally published on minimus.io: https://www.minimus.io/post/sha1-hulud-2-0-the-second-coming-what-you-need-to-know

DEV Community: Minimus

[Boost]

When Projects Fail: Why Companies Should Treat Open Source as Infrastructure

Kat Cosgrove ・ Mar 18

New Vulnerabilities in runC Allow Container Escape

What is runC?

Why runC Vulnerabilities Matter for Docker and Kubernetes Security

Breaking Down CVE-2025-31133: “Masking” Turns Into Arbitrary Mount Gadget

Breaking Down CVE-2025-52565: /dev/console Bind-Mount Race

Breaking Down CVE-2025-52881: LSM Bypass & Arbitrary /proc Write Gadgets

What Is the Exploitability of These runC Vulnerabilities?

Which runC Versions Are Affected?

CVE-2025-31133

CVE-2025-52565

CVE-2025-52881

Next Steps: How to Patch and Mitigate Vulnerable runC Versions

How can Minimus help?

Sha1-Hulud 2.0 - The Second Coming: A Technical Breakdown

Sha1-Hulud 2.0 - The Second Coming: What You Need to Know

Sha1-Hulud 2.0: What happened?

How the Sha1-Hulud 2.0 Attack Works

Step 1: package.json

Step 2: setup_bun.js

Step 3: bun_environment.js

Step 4: Exfiltration via Public GitHub Repositories

IOCs (Indicators of Compromise) for SHA1-Hulud 2.0

What to Do if You Are Affected by SHA1-Hulud 2.0

How can Minimus help?

Breaking Down CVE-2025-52565: `/dev/console` Bind-Mount Race

Breaking Down CVE-2025-52881: LSM Bypass & Arbitrary `/proc` Write Gadgets

Step 1: `package.json`

Step 2: `setup_bun.js`

Step 3: `bun_environment.js`