How Docker containers block supply chain attacks in PHP projects

A supply chain attack that compromised 233 versions of popular Laravel packages on May 22, 2026, highlighted a critical vulnerability for PHP developers. Attackers rewrote Git tags to inject a credential stealer disguised as a harmless helper file, targeting sensitive data like SSH keys, cloud credentials, and browser passwords. While many developers faced panic after running composer update, one developer’s unconventional setup provided an unexpected layer of protection.

Why the Laravel-Lang attack was so dangerous

The attackers behind the Laravel-Lang compromise didn’t just publish a single malicious version. They altered Git tags across four packages, redirecting them to attacker-controlled commits during a 90-minute window. The payload activated via Composer’s autoloader, executing automatically when dependencies were updated.

The stolen data included:

• Cloud provider credentials (AWS, GCP, Azure)
• SSH private keys and .env files
• Browser passwords, cookies, and vaults from password managers
• Cryptocurrency wallet backups
• Any file containing secrets in the project directory

Developers who ran composer update between 22:32 UTC and midnight that night unknowingly invited malware into their systems. The attack exploited trust in popular open-source packages, a growing trend in supply chain threats.

How Docker containers became an unexpected security shield

Instead of running PHP and Composer directly on the host machine, this developer’s setup executed all commands inside Docker containers. The configuration isolated project files, dependencies, and scripts from the host system’s sensitive directories.

The core of the setup relied on three custom scripts:

• `php-docker` – A Bash script that launches a Docker container with a specified PHP version, mounts only the current project directory, and executes commands inside the container.

#!/bin/bash
# Extract PHP version from command arguments
PHP_VERSION=$1
shift

# Capture the original working directory
ORIGIN_PWD="$PWD"

# Navigate to the Dockerized PHP project directory
cd "/opt/docker/php-fpm/" || exit

# Run the command in a Docker container
docker compose run --rm --remove-orphans \
  --quiet --quiet-build --quiet-pull \
  --interactive \
  --volume "${ORIGIN_PWD}:${ORIGIN_PWD}" \
  --workdir "${ORIGIN_PWD}" \
  php-fpm-"$PHP_VERSION" \
  php "$@"

# Return to the original directory
cd "$ORIGIN_PWD" || exit

• `php` – A symbolic link-based wrapper that routes PHP commands to the appropriate Docker container based on version.

#!/bin/bash
# Extract version from filename (e.g., php-8.5)
PHP_VERSION=${0##*-}

# Validate version format
if [ ${#PHP_VERSION} -ne 3 ]; then
  PHP_VERSION=8.5  # Fallback to latest stable
fi

# Execute the command inside the container
command php-docker "$PHP_VERSION" "$@"

• `composer` – A similar wrapper that ensures all Composer commands run within the isolated container environment.

The setup allowed seamless switching between PHP versions (5.6, 7.4, 8.0, 8.5, etc.) while keeping project files and dependencies contained. Originally designed for multi-version support and easier laptop migrations, the Docker-based approach inadvertently prevented the credential stealer from accessing critical host directories.

What the Docker setup blocked

The malicious payload was programmed to search specific locations on the host system for credentials, including:

• Home directory paths (~/.ssh/, ~/.aws/credentials, ~/.config/gcloud/)
• Browser profiles and password manager vaults
• .git-credentials, .npmrc, .pypirc, and .env files
• Cryptocurrency wallet backups

Because the Docker container’s home directory was empty and project files were isolated, the attacker found no accessible secrets. The container’s filesystem contained only the mounted project directory, leaving the host’s sensitive data untouched. Even if the payload executed, it had no way to exfiltrate credentials stored outside the container.

Should you Dockerize your PHP workflow?

For developers working with PHP, Docker offers more than version flexibility—it provides a lightweight isolation layer that can mitigate supply chain risks. While not a complete security solution, running commands inside containers limits the blast radius of compromised dependencies.

Key benefits of this approach include:

• Isolation of project files – Only explicitly mounted directories are accessible inside the container.
• No host system contamination – Malicious scripts cannot traverse beyond the container’s filesystem.
• Consistent environments – Avoids "it works on my machine" issues and dependency conflicts.

The Laravel-Lang attack serves as a reminder that supply chain threats aren’t limited to obscure packages. Even widely used tools can become vectors for breaches. Dockerizing development workflows may seem like an overkill for some, but in an era of increasingly sophisticated attacks, it’s a practice worth considering.

As open-source ecosystems grow, developers must adopt layered defenses. While Docker alone won’t stop every threat, it’s a practical step toward reducing exposure without sacrificing productivity.