How My Docker Setup Saved Me From a Supply Chain Attack (And Why Yours Should Too)

Versión en español aquí.

It's finally Friday! You leave work and go home to work on your side project (yep, that's me). You open your computer and start working on it by running composer update because you want to keep your dependencies up to date.

Next morning, you wake up to the news that a popular Laravel package you use has been compromised. Attackers injected a credential stealer into 233 versions, ready to exfiltrate your SSH keys, cloud credentials, browser data, crypto wallets—the whole digital enchilada ¹. Panic sets in. You check your composer.lock. Your heart skips a beat. You have version 15.29.3 of laravel-lang/lang, one of the compromised versions ².

Been there? I was, on May 22, 2026.

But here's the plot twist: When I dug deeper, I realized my Dockerized PHP setup had just become my unexpected bodyguard. Let me tell you how running PHP through Docker containers added a security layer I never planned for, and why you should consider it too.

1. The Attack: When composer update Goes Rogue

On May 22, 2026, attackers compromised the Laravel-Lang organization on GitHub. They didn't just publish a malicious version—they rewrote every git tag across four popular packages to point to their own commits. The payload? A credential stealer disguised as a harmless helper file that runs automatically via Composer's autoloader.

What it stole is nightmare fuel:

• Cloud credentials (AWS, GCP, Azure)
• SSH private keys
• Browser passwords and cookies
• Password manager vaults
• Crypto wallets
• .env files with secrets
• And basically anything else that looks valuable

The attack hit during a 15-minute window and compromised 233 versions across four packages. If you ran composer update between 22:32 UTC and midnight on May 22, you might have invited a digital burglar into your machine.

2. My Setup: PHP in a Box

Here's how I run PHP and Composer on my local machine:

The php-docker script spins up a Docker container and runs PHP inside it:

• Gets the current working directory from where the command is being executed (ex: ~/Projects/my-awesome-project)
• Mounts the current working directory as a volume in the container and changes to it
• Does NOT mount any other directory, like /tmp, /home, /root, etc.

/usr/local/bin/php-docker

#!/bin/bash

# get specified version and remove it from arguments
PHP_VERSION=$1
shift

# get the current working directory from where the command is being executed
ORIGIN_PWD="$PWD"
# move into the dockerized php project directory
cd "/opt/docker/php-fpm/" || exit

# execute the specified php version container
command docker compose run --rm --remove-orphans --quiet --quiet-build --quiet-pull \
  --interactive \
  # mount the origin execution directory and cd to it
  --volume "${ORIGIN_PWD}":"${ORIGIN_PWD}" \
  --workdir "${ORIGIN_PWD}" \
  php-fpm-"$PHP_VERSION" php "$@"

# go back to original directory
cd "$ORIGIN_PWD" || exit

Instead of the php binary, I have a small script that runs the php-docker script with the specified PHP version (obtained from the filename):

/usr/local/bin/php

#!/bin/bash

# get the version from the filename
PHP_VERSION=${0##*-}
# validate version format
if [ ${#PHP_VERSION} -ne 3 ]; then
  # fallback to latest stable version
  PHP_VERSION=8.5
fi

# execute php-docker specifying version and passing through arguments
command php-docker "$PHP_VERSION" "$@"

And multiple links to the same script:

$ ls /usr/local/bin/php*
/usr/local/bin/php
/usr/local/bin/php-5.6 -> php
/usr/local/bin/php-7.4 -> php
/usr/local/bin/php-8.0 -> php
...
/usr/local/bin/php-8.5 -> php
/usr/local/bin/php-docker -> /opt/docker/php-fpm/bin/php-docker

That way, any php-* cli execution will run inside the Docker container of the specified PHP version.

$ php -v
PHP 8.5.5 (cli) (built: Apr 18 2026 10:39:21) (ZTS)
Copyright (c) The PHP Group
Built by HDS Solutions
Zend Engine v4.5.5, Copyright (c) Zend Technologies
    with Xdebug v3.5.1, Copyright (c) 2002-2026, by Derick Rethans
    with Zend OPcache v8.5.5, Copyright (c), by Zend Technologies

$ php-7.4 -v
PHP 7.4.33 (cli) (built: Apr 18 2026 10:47:16) ( ZTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v3.1.6, Copyright (c) 2002-2022, by Derick Rethans

My composer command follows the same pattern, everything runs inside Docker.

/usr/local/bin/composer

#!/bin/bash

PHP_VERSION=${0##*-}
if [ ${#PHP_VERSION} -ne 3 ]; then
  PHP_VERSION=8.5
fi

# execute php-docker specifying version and passing through arguments to composer cli
command php-docker "$PHP_VERSION" /usr/bin/composer "$@"

Why did I set this up? Originally to support multiple PHP versions, have ZTS builds, and easily migrate when you buy a new laptop. But as I would discover, this architectural choice had an unintended security benefit.

3. What Docker Protected Me From

When the Laravel-Lang payload executes, it hunts for credentials in specific locations. Here's what my Docker setup blocked:

a) Home Directory Secrets: Fort Knox Style

The stealer targets:

• ~/.ssh/ - SSH private keys
• ~/.aws/credentials - AWS credentials
• ~/.config/gcloud/ - GCP credentials
• ~/.azure/ - Azure credentials
• .git-credentials, .netrc, .npmrc, .pypirc
• Browser data (Chrome, Firefox profiles)
• Password manager vaults (KeePass, 1Password)
• Crypto wallets

Result: None of these exist in the container. The container's home directory is "empty". The attacker finds nothing.

/opt/docker/php-fpm/docker-compose.yml

services:
    php-fpm-8.5:
        container_name: php-fpm-zts-8.5
        domainname: php-fpm-8.5.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.5
            context: ./docker
            dockerfile: common/Dockerfile
        volumes:
            - ./docker/common/php/00-php.ini:/usr/local/etc/php/conf.d/00-php.ini:ro
            - ./docker/common/php-fpm/www.conf:/usr/local/etc/php-fpm.d/www-docker.conf:ro
            - ./docker/8.5/home/.composer/cache:/home/http/.composer/cache:rw
            - ./docker/8.5/home/.composer/vendor:/home/http/.composer/vendor:rw

    php-fpm-8.4:
        container_name: php-fpm-zts-8.4
        domainname: php-fpm-8.4.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.4
            context: ./docker
            dockerfile: common/Dockerfile
        ...

    php-fpm-8.3:
        container_name: php-fpm-zts-8.3
        ...

    ...

b) System-Level Secrets: Isolated

The payload also scans:

• /etc/kubernetes/admin.conf - Kubernetes configs
• /var/run/secrets/ - CI/CD secrets
• System credential managers

Result: The container doesn't have access to host system directories. These are isolated.

c) Browser and Password Data: Nonexistent

The stealer looks for browser databases, password manager vaults, and crypto wallets.

Result: No browser, no password manager, no wallets in the container. Just PHP and your code.

4. What Docker Didn't Protect

Or why I'm not throwing a victory parade just yet

My Docker setup added a significant security layer, but it's not perfect. Here's what remains vulnerable:

a) Project Directory Secrets: The Open Door

The container mounts your project directory. If your .env file contains secrets, the stealer can read it:

.env

AWS_ACCESS_KEY_ID=1U0o...pzdZ
AWS_SECRET_ACCESS_KEY=KKaY...aKEd
REDIS_PASSWORD=XSFK...y4XV

Mitigation: Use local-only services (I'll explain in a moment).

b) External API Keys: Still at Risk

Your .env might contain external API keys:

• Google Maps API keys
• reCAPTCHA keys
• Third-party service tokens

These get exfiltrated if the payload runs.

Mitigation: Rotate these keys if you ran composer during the attack window.

5. My Defense Strategy: Local-Everything

To minimize what the stealer could steal, I use local-only services for development (all of them also dockerized):

# .env configuration
DB_CONNECTION=dynamodb
DYNAMODB_ENDPOINT=http://localhost:8000  # Local DynamoDB

BROADCAST_CONNECTION=pusher
PUSHER_HOST=soketi.vanilla  # Local Soketi instance

REDIS_HOST=redis-8.6.vanilla  # Local Redis
REDIS_PASSWORD=a3BM...6nys

AWS_ENDPOINT=https://minio.vanilla  # Local MinIO
AWS_ACCESS_KEY_ID=0onp...ZHjn
AWS_SECRET_ACCESS_KEY=fzfK...Aear

Why this works: Even if these credentials get stolen, they're useless to an attacker. They only work against localhost or my local network domains (*.vanilla). The attacker can't reach my local development infrastructure.

What I keep external: Google Maps API key, reCAPTCHA keys. These are the weak points, but they're low-risk compared to cloud provider credentials.

6. The Verdict: Docker as Security Layer

My Docker setup wasn't designed for security, it was designed for consistency across PHP versions and easy laptop migration. But that architectural choice provided significant protection against this supply chain attack, completely by accident.

When I first discovered my version was compromised, I felt that familiar cold sweat. I checked my SSH keys, my AWS credentials, my browser data—everything was there. My heart rate slowly returned to normal as I realized: the payload had run, but it had nowhere to look.

If I had been running PHP directly on my host machine, the story would have been very different. The stealer would have found my SSH keys, my cloud credentials, my browser passwords, maybe even my crypto wallet. That's not just a security breach—that's identity theft waiting to happen.

What Docker gave me:

• Isolation from home directory secrets—my SSH keys, AWS credentials, and browser data live outside the container
• No access to system-level credentials—Kubernetes configs, CI/CD secrets, and system credential managers are unreachable
• No browser or password manager data—there's no Chrome, Firefox, or KeePass inside the container
• Containerized execution that limits what the payload can see—the attacker gets a sterile environment with nothing valuable

What Docker didn't give me:

• Protection against .env file secrets in project directory—if I had production credentials there, they'd be gone
• Protection against environment variable leaks—secrets passed to the container are still accessible
• Protection against external API key theft—Google Maps and reCAPTCHA keys would still be exfiltrated

The bottom line: Docker reduced my attack surface significantly. Instead of losing SSH keys, cloud credentials, browser data, and crypto wallets, the worst-case scenario would be losing local development credentials and a few API keys. That's the difference between "my weekend is ruined" and "my life is ruined".

7. How to sleep better at night: Harden Your Setup

If you're not running PHP/Composer in Docker, consider it. The consistency benefits alone are worth it, and the security upside is a nice bonus. If you are already using Docker, here's how to make it even more secure:

a) Never Mount Home Directory

Obvious, but critical. Your home directory contains the crown jewels: SSH keys, cloud credentials, browser data, password managers. If you mount it, you're inviting the attacker into your house.

b) Use Local-Only Services for Development

Don't use production cloud credentials in development. Run local instances of everything:

• Databases (MySQL, PostgreSQL, DynamoDB Local)—Docker Compose makes this trivial
• Redis—spin up a container, never touch a real Redis instance
• Object storage (MinIO for S3-compatible)—mocks AWS S3 behavior locally
• Message queues—local RabbitMQ or equivalent

The goal: if credentials leak, they're useless because they only work against localhost.

c) Separate .env Files

Keep .env out of version control (obviously). Use different .env files for local, staging, and production. Never, ever commit your secrets. If you do by accident, rotate them immediately.

Git history is forever.

d) Don't Pass Secrets via Environment Variables

For development, use local services. For production, use secret management systems (e.g., AWS Secrets Manager). Passing secrets via environment variables is convenient, but it's also leaky-process lists, debugging tools, and logging frameworks can expose them.

e) Monitor for IOCs

If you want to know if you were affected, look for:

• Network traffic to flipboxstudio[.]info—if you have traffic logging (e.g., I use Pi-Hole ³)
• Files in /tmp/.laravel_locale/—the dropper writes infection markers here
• Suspicious PHP processes—orphaned PHP processes with no parent are a red flag

f) Lock Your Dependencies

Use composer.lock and verify commit SHAs. The attack rewrote tags, locked commit SHAs from before the attack window are safe. When you pull dependencies, check the commit SHA matches what you expect.

Also, a good practice is to run composer outdated, manually go through the CHANGELOG of each package, and after reviewing the changes, update the package to the latest version. If the changes don't add any needed features, or fix any security vulnerabilities, you can safely ignore the update.

8. What's Next?

Docker isn't a silver bullet, but it's a powerful layer in your security strategy. The Laravel-Lang attack showed us that supply chain attacks are real, sophisticated, and increasingly common.

In my case, a decision made for development consistency became a security feature. I set up Docker to manage multiple PHP versions and ZTS builds, but I accidentally built a security bunker.

Sometimes the best security is the kind you didn't know you had.

But here's the thing: Docker is just one piece of the puzzle. You also need dependency locking, secret management, network monitoring, and a healthy dose of paranoia. Security isn't a destination, it's a journey, and supply chain attacks are just one hazard along the way.

The next time you're setting up a development environment, think about the security implications of your choices. Docker, local services, isolated networks, these aren't just conveniences. They're armor.

And if you're still running PHP directly on your host machine? Well, maybe it's time to put it in a box. Your future self might thank you.

Question for you: Do you run your development tools in Docker or directly on your host? Have you ever considered the security implications of that choice? Share below, I'm curious how others handle this.

1. https://www.aikido.dev/blog/supply-chain-attack-targets-laravel-lang-packages-with-credential-stealer ↩

2. https://x.com/AikidoSecurity/status/2057959626692526098 ↩

3. https://pi-hole.net/ ↩