DEV Community: Bishal Chapagain

Four supply chain attacks, and none of them was a bug in our code

Bishal Chapagain — Fri, 31 Jul 2026 07:30:17 +0000

We started the project last spring. New service, six weeks to ship, so we did what everyone does and reached for the ecosystem. By the time the first build went green the lockfile had 1,247 entries in it. We had chosen about thirty. The rest arrived as dependencies of dependencies, and I could not have named one of their maintainers if you had paid me.

One of those maintainers got an email on a Friday evening.

It offered free API credits for an AI coding tool with a countdown to hurry things along. The login page looked right. He typed in his registry password and a one time code, and within a few minutes a stranger held his publishing rights and had pushed a fresh patch release of every package he maintained. He went to bed, and nobody had noticed anything yet.

Our CI did not know it was the weekend. We had that package floating on a version range instead of a pinned version, the nightly build resolved the range, and an install script executed inside the runner while it was holding every secret we had ever handed the pipeline. That meant cloud keys, the GitHub token, and our own publishing token, which the script used to push poisoned versions of our internal packages onward. By Monday three other teams had installed our compromise as a dependency of theirs.

We spent that week rotating credentials and reading logs. Then we did the responsible thing and added a scanner to the pipeline. Well known tool, thousands of projects use it, referenced by version tag like every other workflow file in the company. It sat in front of every install and checked packages against known malicious releases. For four months it was the most reassuring line in our config.

Then somebody rewrote history on that scanner's tags. The tag we referenced still existed, still looked identical in the commit list, and pointed somewhere new. A scanner needs elevated permissions to do its job, so ours read every secret in the runner and posted them somewhere useful, and it did that while returning a clean report. The control we installed to catch the last attack delivered the next one.

I updated my CV.

A recruiter reached out about a senior role. Good money, fully remote, two friendly calls. Before the technical round, the recruiter asked me to clone their repository and come back with recommendations on their API response times. I cloned it, ran npm install, spent an evening in the code and sent back something I was proud of. The stack was interesting and the problem was real, which is why it never occurred to me to be suspicious.

Then I waited on the offer, and the AWS bill arrived instead.

The repository was gone from GitHub by the time I went looking for it. There had been an install script in the package manifest, and it had taken my credentials while I was still reading the README, before I had formed a single opinion about their API. I never did hear back about the role.

What software supply chain security actually means

Four separate attacks in that story, and none of them exploited a bug in code we wrote or required anybody on my team to make an obviously stupid decision.

Your software supply chain is everything that has to happen between a person typing code and that code running in your production environment. NIST treats this under cybersecurity supply chain risk management in SP 800-161 Rev. 1, where the risk spans a full lifecycle from development through delivery, integration and operation rather than stopping at the edge of your own repository [1]. SLSA, the framework most teams reach for when they want something they can actually implement, splits the same ground into source threats, build threats and dependency threats, with its strongest guarantees covering the build [2].

You add one package to package.json and run npm install. Three things had already happened in infrastructure you cannot see: a maintainer wrote the code and pushed a commit, a CI job on a platform you have never logged into built it, and that job used a token to publish a tarball to a registry. The rest happens on your side. Your package manager fetches the tarball, your lockfile records a version and a hash, your build copies it into a container image, and your deploy pushes that image into production. You reviewed none of that sequence, you inherited all of it, and each handoff is a place where what arrives can stop matching what was written.

So the list of things you are trusting is always longer than your dependency list. It runs from the maintainer's inbox all the way through to the base image under your container and the laptop you cloned that repository onto.

Every link in that chain runs code you have not read using permissions you granted earlier and stopped thinking about. Both paths end in the same place, because a laptop and a build runner are the same kind of target: a machine holding live credentials, doing what it was told. Neither NIST nor SLSA has much to say about the laptop, which was never part of anybody's build.

The parts that actually happened

The narrative above is a composite. Each beat in it is a real, documented incident.

The phishing email

On September 8, 2025, the maintainer of chalk and debug received a fake two factor reset notice from support@npmjs.help, a domain registered three days earlier [3]. The attacker captured a password and a live one time code, then published malicious versions of 18 packages carrying a browser based crypto stealer [4]. Those packages draw more than two billion downloads a week. The bad versions were live for roughly two hours, and Wiz still measured the malicious code reaching one in ten cloud environments inside that window [5].

The lure in my version is free AI credits rather than a security notice, a detail that changes every few months while the mechanism stays the same.

The worm in the pipeline

Shai-Hulud, first seen in September 2025, does what the fictional install script did. It steals a publish token, enumerates every package that token can reach, injects itself and republishes [6]. The November 2025 wave compromised over 700 packages and exposed roughly 14,000 secrets across 487 organisations [7]. New waves continued through 2026 [8], and by May 2026 one of them needed no stolen credential at all: the attackers poisoned a CI cache through a pull request workflow misconfiguration and waited [9].

The scanner that carried the payload

On March 19, 2026, a group calling itself TeamPCP force pushed 75 existing tags in aquasecurity/trivy-action to malicious commits, preserving the original author names, messages and timestamps so the history looked untouched. One forensic tell was a commit claiming a 2021 date with a parent commit dated March 2026 [10]. More than 10,000 workflow files referenced that action [11]. The payload took everything the runner could see [12]. Aqua Security confirmed the attacker got in using credentials that were never fully rotated after an earlier incident [13], and within 96 hours those stolen CI credentials were used to compromise the Checkmarx AST action as well [14].

The interview that was not an interview

Microsoft tracks this as Contagious Interview and dates it to at least December 2022 [15]. Each campaign uses a fake recruiter from a crypto or AI company, a plausible assessment repository, and a payload in the lifecycle scripts rather than in the code you were asked to review. Some variants now fire when you open the folder in VS Code, through the workspace task file [15]. In July 2026 Elastic documented a version that split its payload across SVG flag images, and no antivirus engine flagged the repositories [16]. Stolen cloud keys get monetised quickly: AWS has seen miners deployed within ten minutes of a credential compromise [17].

The people holding it all up

Tidelift surveyed 437 maintainers in 2024. Sixty percent called themselves unpaid hobbyists, and 61% of that group maintain their projects alone [18]. Census II, from the Linux Foundation and Harvard, found that 136 developers wrote more than 80% of the lines added to 50 of the most used open source libraries [19]. The solo maintainer answering email on a Friday night is what the ecosystem actually looks like, not a device I invented for the story.

How to break the attack chain

Commit a lockfile and install with npm ci in CI, so no build ever resolves a version range on its own.
Add an install cooldown, so a version published an hour ago cannot reach your build. npm supports this through minimumReleaseAge, pnpm 11 enables it by default, and Dependabot ships a default cooldown [20].
Disable lifecycle scripts by default and keep a short allowlist for the packages that genuinely need them. Both the worm and the interview repository needed an install hook to run at all.
Pin GitHub Actions to full commit SHAs instead of version tags. A tag can be force pushed to point at new code, which is not possible with a SHA [14].
Scope secrets per job and retire standing cloud keys in favour of short lived OIDC credentials. That is the same reasoning behind npm revoking every classic token in December 2025 and capping write tokens at 90 days [21].
Rotate everything after an incident, not the parts you can reach easily. The Trivy compromise ran on credentials left behind by a previous cleanup [13].
Open anything a stranger sends you inside a throwaway VM that has nothing worth stealing on it.

None of that is advanced. Every attack in this story worked because code nobody had read ran with credentials nobody had scoped.

References

NIST, SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, updated November 2024.
SLSA, Supply chain threats, OpenSSF.
Aikido Security, npm debug and chalk packages compromised, September 2025.
Checkmarx, Chalk and 17 other npm packages compromised in supply chain attack, September 2025.
Wiz, Widespread npm supply chain attack: breaking down impact and scope, September 2025.
ReversingLabs, New Shai-Hulud worm spreads: what to know, November 2025.
Zscaler ThreatLabz, Shai-Hulud V2 poses risk to the npm supply chain, November 2025.
Unit 42, The npm threat landscape: attack surface and mitigations, updated July 2026.
Akamai, Mini Shai-Hulud: the worm returns and goes public, May 2026.
Upwind, Trivy supply chain incident: GitHub Actions compromise breakdown, March 2026.
Cloud Security Alliance Labs, TeamPCP supply chain CI/CD research note, March 2026.
Wiz, Trivy compromised by TeamPCP, March 2026.
Legit Security, The Trivy supply chain compromise: what happened and playbooks to respond, March 2026.
Sysdig, TeamPCP expands: supply chain compromise spreads from Trivy to Checkmarx GitHub Actions, March 2026.
Microsoft Security, Contagious Interview: malware delivered through fake developer job interviews, March 2026.
Elastic Security Labs, Contagious Interview malware in SVG images, July 2026.
Dark Reading, Attackers use stolen AWS credentials in cryptomining campaign, December 2025.
Socket, The unpaid backbone of open source, on the 2024 Tidelift maintainer survey.
Linux Foundation, Open source maintainers: what they need and how to support them, on Census II.
Socket, npm introduces minimumReleaseAge and bulk OIDC configuration, February 2026.
GitHub Changelog, npm classic tokens revoked, session based auth and CLI token management, December 2025.

A Practical Guide to Claude Code's Security-Guidance Plugin

Bishal Chapagain — Wed, 29 Jul 2026 17:27:30 +0000

Development velocity has moved faster than the machinery built to review it. An engineer working with a coding agent can touch a dozen files, refactor across them, and commit inside an afternoon. The gates around that work mostly stayed where they were: static analysis in CI, dependency scanners on a schedule, and a human reading the diff once it reaches a pull request. Those gates assume that writing code is the slow step.

That assumption no longer holds, and the cost shows up as delay. A vulnerable query gets written, committed, and pushed before anything examines it, and the tool that eventually flags it is describing work the author finished hours earlier and has stopped thinking about. The gates are not wrong. There are simply more diffs arriving than they were built to absorb, and the later a finding lands, the more expensive it is to act on.

Anthropic’s security-guidance plugin moves the first check into the session itself. Claude writes code, the plugin reviews the change, and findings come back to Claude in the same conversation. There is nothing to invoke and no command to remember.

I spent an evening setting it up in a small repository and then trying to get each of its three layers to fire on code written to trip them. This is what that took, and how to tell that each layer is actually running rather than merely installed.

What the plugin does

The plugin is built from Claude Code lifecycle hooks. It registers SessionStart to bootstrap a Python environment, UserPromptSubmit to capture a git baseline for the turn, PostToolUse on the edit tools for the pattern check, Stop for the end-of-turn review, and PostToolUse on Bash filtered to git commit and git push for the deep review. If those event names are new to you, the hooks reference describes what each one fires on.

Those registrations give you three layers at increasing depth and cost.

Layer 1 is a string and regex match with no model call, so it is free and instant. It covers dynamic execution such as eval( and os.system, unsafe deserialization such as pickle, DOM injection such as .innerHTML = and dangerouslySetInnerHTML, and edits under .github/workflows/, which can quietly grant repository permissions. Those are the built-ins you get before writing anything. Your own rules from security-patterns.json run in this same pass, covered further down.

Layer 2 diffs the working tree at the end of a turn and sends the result to a separate Claude call with a security-only prompt. It covers what a string match cannot: injection, server-side request forgery, weak cryptography, authorization bypass. It runs in the background, so Claude’s reply is not delayed, and it covers up to 30 changed files per turn.

Layer 3 fires when Claude runs git commit or git push through its Bash tool. This reviewer reads surrounding code, including callers and sanitizers, before deciding whether a finding is real. It is capped at 20 reviews per rolling hour.

One point is worth saying to your team early, because it is the first thing they will assume wrongly. None of these layers stops anything. They find problems and hand them to Claude, which fixes them in the conversation. Nothing gets blocked. If you want a hard stop, you build it yourself with a PreToolUse hook or a check in CI.

Prerequisites

Claude Code 2.1.144 or later (Scroll to the end if you’re on OpenRouter)
Python 3.10 or later, and a git repository

A repository worth attacking

None of the checks below mean anything against an empty directory, so the first thing I built was a small Python service with a few files: a data layer , a couple of route stubs, and a front-end file so the JavaScript patterns had somewhere to land. The baseline is deliberately clean, which makes the contrast visible when Claude adds something unsafe on request.

Then git init and a first commit. Layer 2 diffs the working tree and Layer 3 only fires on git commit or git push, so without a repository two of the three checks quietly do nothing.

Installing security-guidance plugin

1.Run this inside a Claude Code session to install the official plugin from the Anthropic:

/plugin install security-guidance@claude-plugins-official

2.The installer asks for a scope. Choose “Install for all collaborators on this repository”, which writes .claude/settings.json for you with the plugin enabled.

3.Then apply it to the open session:

/reload-plugins

Confirm the file settings.json landed under the .claude folder in your project root.

Note: If the marketplace is not registered on the machine, add it first with /plugin marketplace add anthropics/claude-plugins-official and retry.

What ends up in the repository

The installer writes one of the three files. You write the other two, because the plugin has no opinion about your codebase and never generates them.

The full working example, including the demo repository these snippets come from, is on [GitHub]

They are configuration, they belong next to the code they protect, and versioning them means a rule change shows up in review like any other change.

Your threat model, in plain English

The two model-backed reviews load .claude/claude-security-guidance.md as extra context alongside the built-in vulnerability checklist. There is no DSL. Write the rules the way you would explain them to a new hire.

This is the file that carries knowledge a generic scanner cannot have. Nothing about org_id is universal. It is your schema, and the reviewer only knows about it because you wrote it down.

Custom patterns for the free layer

Anthropic’s security plugin includes built-in detection patterns in patterns.py. You can locate the file with:

find ~/.claude/plugins -path '*security-guidance/hooks/patterns.py'

You can add your own custom patterns in .claude/security-patterns.json. These feed the free Layer 1 checks, so they run instantly with no additional model cost.

The plugin also supports .yaml, .yml and .json using the same schema. YAML requires PyYAML to be installed separately, while JSON works on any standard Python installation.

What each layer can see

The layering is worth understanding before you decide how much of it to pay for.

Layer	Sees	Strength	Limitation
Layer 1	Single edit only	Free, instant pattern matching	No project context or data flow awareness
Layer 2	All changes in the current turn	Tracks data flow across the diff	Limited to current-turn changes
Layer 3	Diff plus related files	Uses project context to reduce false positives

Proving each layer fires

Installing the plugin and reading the docs tells you what should happen. It does not tell you what is happening on your machine.

Start a fresh session from the repo root and run /hooks, which should show registrations against SessionStart, UserPromptSubmit, PostToolUse, and Stop. That screen makes a good opening slide for a team walkthrough, because it shows there is nothing hidden in the design.

Then make each layer fire on purpose. The plugin keeps its own log at ~/.claude/security/log.txt, and that is the thing to read rather than the session transcript. Claude sometimes adds its own security comments to code unprompted, which is easy to mistake for the plugin having spoken.

Keep a second terminal open on the log before prompting claude-code:

tail -f ~/.claude/security/log.txt

Check 1: the built-in pattern layer

Ask for something the built-in list covers.

In app/routes.py, add a function run_report(expr) that evaluates the expr string the caller passes in and returns the result. Keep it to three lines.

Claude writes eval(expr). The warning appears in the transcript with no perceptible delay. Next, screen shows the hook event and pattern matched.

Check 2: your own pattern rule

Same free layer, your vocabulary. This one exercises the paths glob, which is the part most likely to be silently wrong.

In app/db.py add a function list_invoices() that returns Invoice.objects.all().

The warning text should be the reminder string you wrote, not a generic one.

Note: A rule that never appears here, with no error anywhere, is almost always a paths glob missing its **/ prefix.

Check 3: the end-of-turn model review

Now ask for something no string match will catch cleanly.

Add a function search_users(term) to app/db.py that runs a LIKE query against the users table. Build the SQL as an f-string so it is easy to read.

Claude replies without delay. A few seconds later the review returns in the background. Claude is re-prompted with the finding. If it acknowledges the finding but leaves the code as it is, prompt “apply the security review’s recommendation” and it will rewrite the query with parameter binding.

Check 4: the commit review

Let Claude make the commit itself, since this layer only sees commits that go through its Bash tool.

Commit everything we just changed with a sensible message.

The commit completes, then the deeper review runs in the background and reports separately after a few minutes:

This reviewer reads related files before deciding, so it takes longer than Layer 2 and may run several model turns. If its findings duplicate what the end-of-turn review already reported, Claude is not re-prompted, so a clean commit can produce no visible output at all. That silence is documented behaviour rather than a failure.

Worth noticing while this is on screen: the commit already exists by the time the finding arrives. Any fix becomes a second commit. “Review on commit” sounds like a gate and is not one.

Limits worth stating up front

Manual commits, shell escapes, or commits made outside Claude are not reviewed. A CI security check is still recommended.
Findings are suggestions, not guarantees. The model can miss vulnerabilities, generate false positives and its results may vary across codebases, languages and model versions.
This plugin complements, but does not replace, static analysis, dependency scanning, pull request reviews, or human review.
The plugin is an early security gate. Anthropic also provides deeper repository scanning with its multi-agent scanner and pull request reviews through Code Review for Team and Enterprise plans. Each stage helps catch issues missed by the previous one.

What it does well is cheap: it puts your team’s actual rules in front of the model at the moment code is written, in a file any engineer can edit in five minutes, versioned in the repository like everything else.

Workaround for OpenRouter

Skip this if you are not on OpenRouter.

I was running Claude Code through OpenRouter instead of a first-party

Anthropic account. Sessions worked fine but the plugin did not, because both model-backed reviews default to Claude Opus 4.7 and my OpenRouter key had roughly the spending power of a library card. It asked for Opus. It got a polite note about credits.

The fix is environment variables that redirect the reviews to a model the key actually serves. Here is the relevant part of my .bashrc:

export OPENROUTER_API_KEY="your-key"  
export ANTHROPIC_BASE_URL="https://openrouter.ai/api"  
export ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"  
export ANTHROPIC_API_KEY=""  

export ANTHROPIC_DEFAULT_SONNET_MODEL="openrouter/free"  
export ANTHROPIC_DEFAULT_HAIKU_MODEL="openrouter/free"  
export ANTHROPIC_DEFAULT_OPUS_MODEL="openrouter/free"  
export CLAUDE_CODE_SUBAGENT_MODEL="openrouter/free"   

export SECURITY_REVIEW_MODEL="openrouter/free"  
export SG_AGENTIC_MODEL="openrouter/free"

SECURITY_REVIEW_MODEL covers the end-of-turn review and SG_AGENTIC_MODEL covers the commit review. The plugin reads them independently of the session model, which is the point: you can run a cheap model for coding and a stronger one for review, or the reverse if you are watching spend.

Hooks run as subprocesses of Claude Code, so they inherit the environment of the shell that started claude. Putting these in .bashrc rather than typing them in a second terminal is the reliable way to make sure the reviews see them.

References

Anthropic. “Catch security issues as Claude writes code.” Claude Code documentation. https://code.claude.com/docs/en/security-guidance

Anthropic. “Hooks reference.” Claude Code documentation. https://code.claude.com/docs/en/hooks

Anthropic. “Automate actions with hooks.” Claude Code documentation. https://code.claude.com/docs/en/hooks-guide

Anthropic. “Settings.” Claude Code documentation. https://code.claude.com/docs/en/settings

Anthropic. “security-guidance plugin.” claude-plugins-official repository, GitHub. https://github.com/anthropics/claude-plugins-official/tree/main/plugins/security-guidance

Anthropic. “Code Review.” Claude Code documentation. https://code.claude.com/docs/en/code-review

Anthropic. “Claude Security plugin.” Claude Code documentation. https://code.claude.com/docs/en/claude-security

ENABLE EBS ENCRYPTION BY DEFAULT IN 30 SECONDS

Bishal Chapagain — Fri, 21 Nov 2025 08:09:01 +0000

The One Security Setting Every AWS Account Needs

We have all been there. You are in a rush to launch an EC2 instance. You click through the configuration screens, hit "Launch," and then realize... you forgot to tick the "Encrypt" box for the storage volume.

In the world of cloud security, human error is the biggest risk. But what if you could "future-proof" your account so that you never have to remember to click that button again?

There is a setting in AWS that takes literally 30 seconds to turn on, costs nothing extra to enable, and ensures that every single new hard drive (EBS volume) you create is encrypted automatically. Here is how to turn it on, why it matters, and the few things you need to know.
Why should you care?

Think of EBS Encryption by Default as automatically locking your front door every time you close it.

Peace of Mind: You don’t need to rely on your team remembering to encrypt data. AWS enforces it for you.

Compliance: If you are handling sensitive data (GDPR, HIPAA, etc.), encryption at rest is usually mandatory.

How to Enable it (The 30-Second Guide)

If you are familiar with AWS CLI, use the following command and it's done.

aws ec2 get-ebs-encryption-by-default --region <region>

Else, you don’t need to be a coding wizard to do this. Just follow these steps in the AWS Console.

1. Pick your Region

Log into your AWS Console.
Select your region from the top right corner.

Crucial: This setting is Region-Specific. If you work in both us-east-1 (N. Virginia) and ap-south-1 (Mumbai), you need to do this in both places.

2. Navigate to the EC2 service.

3. Find the Settings

Look at the navigation pane on the left side.
Scroll all the way down to the bottom and click on Settings

Click on the Data Protection and Security tab.
You will see a section called EBS Encryption.
Click Manage.

Check the Enable box.

Key Selection: You can leave it as the default (aws/ebs) or pick a Customer Managed Key (CMK) if you plan to share snapshots later.

Note: While the default key is free, AWS charges approx. $1/month to maintain a Customer Managed Key.

Click Update EBS encryption.

Done. That’s it. You are now secure by default.

Things to Consider Before You Switch It On

While this setting is fantastic for security, there are a few details you should know so you aren't surprised later.

1. It doesn’t fix the past

Turning this on acts like a fresh start. It encrypts every new volume you create from this moment forward. However, for your old volumes, you can’t simply turn on encryption for drives that already exist. You have to create a snapshot and copy it to a new drive to secure them.

2. It is Region-Specific

AWS settings often apply to just one specific location (Region). If you enable this in N. Virginia, it does not automatically turn on in Mumbai or Sydney. You need to repeat this process for every Region where you have servers.

3. Be careful with "Key Selection"

Default Key: It is totally free and auto rotated every year but you cannot share snapshots encrypted with this key to other AWS accounts.

Customer Managed Key (CMK): If you plan to share disk images with a client or a different production account later, you must create and use your own Customer Managed Key. AWS charges for using CMK and you are responsible for rotating it.

4. It is "All or Nothing"

Once you enable this for a Region, it applies to everything you create in that Region. You cannot disable encryption for just one specific volume later. This is actually a good thing; it prevents accidental loopholes in your security.

5. A note on storage costs

If you decide to clean up your old data by copying unencrypted snapshots to make them encrypted, be aware that AWS creates a full copy, not a partial one. This means you will be storing more data, which might result in a small increase in your storage bill.

Final Thoughts

Security doesn't always have to be hard. By enabling EBS Encryption by Default, you are removing the chance of human error and ensuring that your data remains locked tight, no matter who launches the instance.

Go do it now,it will take less time than finishing your coffee!

For more technical details or CLI commands, you can check the official AWS Documentation.

AWS Support: "We're here to help"

Bishal Chapagain — Sat, 19 Jul 2025 04:46:47 +0000

They said they’re “here to help.”

They meant help me cry more.

From Container to Root

Bishal Chapagain — Fri, 25 Apr 2025 17:18:04 +0000

Background

In many companies, employees are often provided with limited user privileges. These accounts often lack sudo or root privileges, preventing direct access to install packages or make system-wide changes. But what if you could break through these restrictions with a Docker container?

In this article, I’ll show you how I got root access onto the host all from within a container.

About Docker

Docker makes extensive use of cgroups and namespaces to provide containerization. These are core Linux kernel features that enable Docker to isolate and manage resources for containers effectively. Even with root inside a container, you can't affect the host system unless you explicitly allow it. Docker containers are isolated environments that share the host kernel but are otherwise sandboxed.

By running containers in --privileged mode and mounting the host filesystem, we effectively give the container god-mode access to the host. This is what we exploit in this method.

This method is tested on Ubuntu 24.04.2 LTS with Docker installed on it.

Disclaimer:

This method is dangerous as it breaks the isolation model of Docker.
One wrong move and you can corrupt your host system.

Steps

1. Run a Docker Container

First, run a privileged Ubuntu container with the host root directory mounted on it.

docker run -it --rm --privileged -v /:/mnt/host ubuntu:latest

Once inside the container, you can check the contents of the host root directory.

ls /mnt/host

2. chroot into the host system

The chroot command changes the apparent root directory for the current process and its children.
The directory /mnt/host becomes the new root for the processes. Thus, host files and directories can be accessed with an isolated bash shell.

chroot /mnt/host /bin/bash

Now, we’re in the host environment and can install packages or make other modifications as if we were logged in directly.

If it fails, check for missing binaries or libraries using strace.

strace -f chroot /mnt/host /bin/bash

3. Install packages

For this demo, let’s install python3.

4. Test it from your end

We can see a running Ubuntu container using docker ps command in the new terminal.
On testing, python3 has been successfully installed on our system.

5. Fixing DNS Issues

If you face any DNS issues inside the container, you can resolve this by manually setting the DNS.

echo "nameserver 8.8.8.8" > /etc/resolv.conf

How to prevent it?

When an employee gains unauthorized root access to a company's end device, the impacts can be severe, affecting security, operations and compliance.

The following ways can be considered for prevention :

Use Rootless mode

This is the safest way to run containers without risking the host system’s security as both Docker daemon and containers runs in rootless mode.
Leverage SELinux/AppArmor

Mandatory Access Control via SELinux or AppArmor prevents containers from accessing host paths, even if privileged.

Final Thoughts

This method granted me the freedom to act as root on a machine where I didn’t have direct access. However, never test this on critical systems.

Happy hacking!