English version here.

¡Por fin es viernes! Sales del trabajo y vas a casa a trabajar en tu proyecto personal (sí, ese soy yo). Abres tu computadora y empiezas a trabajar ejecutando composer update porque quieres mantener tus dependencias actualizadas.

A la mañana siguiente, te despiertas con la noticia de que un paquete popular de Laravel que usas ha sido comprometido. Los atacantes inyectaron un robo de credenciales en 233 versiones, listo para exfiltrar tus claves SSH, credenciales de la nube, datos del navegador, billeteras de criptomonedas—toda la ensalada digital ¹. El pánico se instala. Revisas tu composer.lock. Tu corazón se detiene un segundo. Tienes la versión 15.29.3 de laravel-lang/lang, una de las versiones comprometidas ².

¿Te ha pasado? A mí me pasó el 22 de mayo de 2026.

Pero aquí está el giro inesperado: cuando profundicé más, me di cuenta de que mi configuración de PHP en Docker acababa de convertirse en mi guardaespaldas inesperado. Déjame contarte cómo ejecutar PHP a través de contenedores Docker añadió una capa de seguridad que nunca planeé, y por qué tú también deberías considerarlo.

1. El Ataque: Cuando composer update Se Vuelve Rebelde

El 22 de mayo de 2026, los atacantes comprometieron la organización Laravel-Lang en GitHub. No solo publicaron una versión maliciosa—reescribieron cada etiqueta git en cuatro paquetes populares para apuntar a sus propios commits. ¿El payload? Un robo de credenciales disfrazado como un archivo de ayuda inofensivo que se ejecuta automáticamente a través del autoloader de Composer.

Lo que roba es una pesadilla:

• Credenciales de la nube (AWS, GCP, Azure)
• Claves privadas SSH
• Contraseñas y cookies del navegador
• Bóvedas de gestores de contraseñas
• Billeteras de criptomonedas
• Archivos .env con secretos
• Y básicamente cualquier otra cosa que parezca valiosa

El ataque golpeó durante una ventana de 15 minutos y comprometió 233 versiones en cuatro paquetes. Si ejecutastecomposer update entre las 22:32 UTC y la medianoche del 22 de mayo, podrías haber invitado a un ladrón digital a tu máquina.

2. Mi Configuración: PHP en una Caja

Así es como ejecuto PHP y Composer en mi máquina local:

El script php-docker inicia un contenedor Docker y ejecuta PHP dentro de él:

• Obtiene el directorio de trabajo actual desde donde se está ejecutando el comando (ej: ~/Projects/my-awesome-project)
• Monta el directorio de trabajo actual como un volumen en el contenedor y cambia a él
• NO monta ningún otro directorio, como /tmp, /home, /root, etc.

/usr/local/bin/php-docker

#!/bin/bash

# obtener la versión especificada y eliminarla de los argumentos
PHP_VERSION=$1
shift

# obtener el directorio de trabajo actual desde donde se ejecuta el comando
ORIGIN_PWD="$PWD"
# moverse al directorio del proyecto php dockerizado
cd "/opt/docker/php-fpm/" || exit

# ejecutar el contenedor de la versión php especificada
command docker compose run --rm --remove-orphans --quiet --quiet-build --quiet-pull \
  --interactive \
  # montar el directorio de ejecución original y cd a él
  --volume "${ORIGIN_PWD}":"${ORIGIN_PWD}" \
  --workdir "${ORIGIN_PWD}" \
  php-fpm-"$PHP_VERSION" php "$@"

# volver al directorio original
cd "$ORIGIN_PWD" || exit

En lugar del binario php, tengo un pequeño script que ejecuta el script php-docker con la versión de PHP especificada (obtenida del nombre del archivo):

/usr/local/bin/php

#!/bin/bash

# obtener la versión del nombre del archivo
PHP_VERSION=${0##*-}
# validar el formato de la versión
if [ ${#PHP_VERSION} -ne 3 ]; then
  # fallback a la última versión estable
  PHP_VERSION=8.5
fi

# ejecutar php-docker especificando la versión y pasando los argumentos
command php-docker "$PHP_VERSION" "$@"

Y múltiples enlaces al mismo 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

De esa manera, cualquier ejecución cli php-* se ejecutará dentro del contenedor Docker de la versión de PHP especificada.

$ 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

Mi comando composer sigue el mismo patrón, todo se ejecuta dentro de Docker.

/usr/local/bin/composer

#!/bin/bash

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

# ejecutar php-docker especificando la versión y pasando los argumentos al cli de composer
command php-docker "$PHP_VERSION" /usr/bin/composer "$@"

¿Por qué configuré esto? Originalmente para soportar múltiples versiones de PHP, tener builds ZTS, y migrar fácilmente cuando compras una nueva laptop. Pero como lo descubriría más adelante, esta elección arquitectónica tuvo un beneficio de seguridad que no fue intencional.

3. Qué Me Protegió Docker

Cuando el payload de Laravel-Lang se ejecuta, busca credenciales en ubicaciones específicas. Así es como mi configuración de Docker lo bloqueó:

a) Secretos del Directorio Home: Estilo Fort Knox

El robo apunta a:

• ~/.ssh/ - Claves privadas SSH
• ~/.aws/credentials - Credenciales de AWS
• ~/.config/gcloud/ - Credenciales de GCP
• ~/.azure/ - Credenciales de Azure
• .git-credentials, .netrc, .npmrc, .pypirc
• Datos del navegador (perfiles Chrome, Firefox)
• Bóvedas de gestores de contraseñas (KeePass, 1Password)
• Billeteras de criptomonedas

Resultado: Ninguno de estos existe en el contenedor. El directorio home del contenedor está "vacío". El atacante no encuentra nada.

/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) Secretos a Nivel de Sistema: Aislados

El payload también escanea:

• /etc/kubernetes/admin.conf - Configuraciones de Kubernetes
• /var/run/secrets/ - Secretos de CI/CD
• Gestores de credenciales del sistema

Resultado: El contenedor no tiene acceso a los directorios del sistema host. Estos están aislados.

c) Datos del Navegador y Contraseñas: Inexistentes

El robo busca bases de datos del navegador, bóvedas de gestores de contraseñas, y billeteras de criptomonedas.

Resultado: No hay navegador, no hay gestor de contraseñas, no hay billeteras en el contenedor. Solo PHP y tu código.

4. Qué No Me Protegió Docker

O por qué no estoy lanzando un desfile de victoria todavía

Mi configuración de Docker añadió una capa de seguridad significativa, pero no es perfecta. Así es lo que sigue siendo vulnerable:

a) Secretos del Directorio del Proyecto: La Puerta Abierta

El contenedor monta tu directorio del proyecto. Si tu archivo .env contiene secretos, el robo puede leerlo:

.env

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

Mitigación: Usa servicios solo locales (explicaré en un momento).

b) Claves de API Externas: Todavía en Riesgo

Tu archivo .env podría contener claves de API externas:

• Claves de API de Google Maps
• Claves de reCAPTCHA
• Tokens de servicios de terceros

Estas se exfiltran si el payload se ejecuta.

Mitigación: Rota estas claves si ejecutaste composer durante la ventana del ataque.

5. Mi Estrategia de Defensa: Todo Local

Para minimizar lo que el robo podría robar, uso servicios solo locales para desarrollo (todos ellos también dockerizados):

# configuración .env
DB_CONNECTION=dynamodb
DYNAMODB_ENDPOINT=http://localhost:8000  # DynamoDB Local

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

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

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

Por qué funciona: Incluso si estas credenciales se roban, son inútiles para un atacante. Solo funcionan contralocalhost o mis dominios de red local (*.vanilla). El atacante no puede alcanzar mi infraestructura de desarrollo local.

Qué mantengo externo: Clave de API de Google Maps, claves de reCAPTCHA. Estos son los puntos débiles, pero son de bajo riesgo comparado con las credenciales de proveedores de la nube.

6. El Veredicto: Docker como Capa de Seguridad

Mi configuración de Docker no fue diseñada para seguridad, fue diseñada para consistencia entre versiones de PHP y cambiarme fácilmente de laptop. Pero esa elección arquitectónica proporcionó protección significativa contra este ataque, completamente por accidente.

Cuando descubrí por primera vez que mi versión estaba comprometida, sentí ese sudor frío. Verifiqué mis claves SSH, mis credenciales de AWS, mis datos del navegador, todo estaba ahí. Mi ritmo cardíaco volvió lentamente a la normalidad mientras me daba cuenta: el payload había corrido, pero no tenía dónde buscar.

Si hubiera estado ejecutando PHP directamente en mi máquina host, la historia habría sido muy diferente. El robo habría encontrado mis claves SSH, mis credenciales de la nube, mis contraseñas del navegador, quizás incluso mi billetera de criptomonedas. Eso no es solo una brecha de seguridad, es robo de identidad esperando a suceder.

Lo que Docker me dio:

• Aislamiento de secretos del directorio home—mis claves SSH, credenciales de AWS, y datos del navegador viven fuera del contenedor
• Sin acceso a credenciales a nivel de sistema—configuraciones de Kubernetes, secretos de CI/CD, y gestores de credenciales del sistema son inalcanzables
• Sin datos de navegador o gestor de contraseñas—no hay Chrome, Firefox, o KeePass dentro del contenedor
• Ejecución en contenedor que limita lo que el payload puede ver—el atacante obtiene un ambiente estéril con nada valioso

Lo que Docker no me dio:

• Protección contra secretos de archivo .env en el directorio del proyecto—si tuviera credenciales de producción ahí, se habrían ido
• Protección contra fugas de variables de entorno—los secretos pasados al contenedor siguen siendo accesibles
• Protección contra robo de claves de API externas—las claves de Google Maps y reCAPTCHA todavía se habrían exfiltrado

En resumen: Docker redujo mi superficie de ataque significativamente. En lugar de perder claves SSH, credenciales de la nube, datos del navegador, y billeteras de criptomonedas, el peor escenario sería perder credenciales de desarrollo local y algunas claves de API. Esa es la diferencia entre "mi fin de semana está arruinado" y "mi vida está arruinada".

7. Cómo Dormir Mejor por la Noche: Endurece Tu Configuración

Si no estás ejecutando PHP/Composer en Docker, considéralo. Los beneficios de consistencia por sí solos valen la pena, y el beneficio de seguridad es un bono agradable. Si ya estás usando Docker, así es cómo hacerlo aún más seguro:

a) Nunca Montes el Directorio Home

Obvio, pero crítico. Tu directorio home contiene las joyas de la corona: claves SSH, credenciales de la nube, datos del navegador, gestores de contraseñas. Si lo montas, estás invitando al atacante a tu casa.

b) Usa Servicios Solo Locales para Desarrollo

No uses credenciales de la nube de producción en desarrollo. Ejecuta instancias locales de todo:

• Bases de datos (MySQL, PostgreSQL, DynamoDB Local)—Docker Compose hace esto trivial
• Redis—inicia un contenedor, nunca toques una instancia real de Redis
• Almacenamiento de objetos (MinIO compatible con S3)—simula el comportamiento de AWS S3 localmente
• Colas de mensajes—RabbitMQ local o equivalente

El objetivo: si las credenciales se filtran, son inútiles porque solo funcionan contra localhost.

c) Separa Archivos .env

Mantén .env fuera del control de versiones (obviamente). Usa diferentes archivos .env para local, staging, y producción. Nunca, nunca lleves secretos en tus commits. Si lo haces por accidente, rótalos inmediatamente.

El historial de Git es para siempre.

d) No Pases Secretos Variables de Entorno

Para desarrollo, usa servicios locales. Para producción, usa sistemas de gestión de secretos (ej: AWS Secrets Manager). Pasar secretos vía variables de entorno es conveniente, pero también es filtrable—listas de procesos, herramientas de depuración, y frameworks de logging pueden exponerlos.

e) Monitorea IOCs

Si quieres saber si fuiste afectado, busca:

• Tráfico de red a flipboxstudio[.]info—si tienes logging de tráfico (ej: uso Pi-Hole ³)
• Archivos en /tmp/.laravel_locale/—el dropper escribe marcadores de infección aquí
• Procesos PHP sospechosos—procesos PHP huérfanos sin padre son una bandera roja

f) Bloquea Tus Dependencias

Usa composer.lock y verifica los SHAs de commit. El ataque reescribió etiquetas, los SHAs de commit bloqueados de antes de la ventana del ataque son seguros. Cuando descargas dependencias, verifica que el SHA de commit coincida con lo que esperas.

También, una buena práctica es ejecutar composer outdated, revisar manualmente el CHANGELOG de cada paquete, y después de revisar los cambios, actualizar el paquete a la última versión. Si los cambios no añaden ninguna característica necesaria, o corrigen vulnerabilidades de seguridad, puedes ignorar el update de forma segura.

8. ¿Qué Sigue?

Docker no es una bala de plata, pero es una capa poderosa en tu estrategia de seguridad. El ataque de Laravel-Lang nos mostró que los ataques Supply Chain son reales, sofisticados, y cada vez más comunes.

En mi caso, una decisión tomada por consistencia de desarrollo se convirtió en una característica de seguridad. Configuré Docker para gestionar múltiples versiones de PHP y builds ZTS, pero accidentalmente construí un búnker de seguridad.

A veces la mejor seguridad es la que no sabías que tenías.

Pero aquí está el tema: Docker es solo una pieza del rompecabezas. También necesitas bloqueo de dependencias, gestión de secretos, monitoreo de red, y una dosis saludable de paranoia. La seguridad no es un destino, es un viaje, y los ataques Supply Chain son solo un peligro en el camino.

La próxima vez que configures un ambiente de desarrollo, piensa en las implicaciones de seguridad de tus elecciones. Docker, servicios locales, redes aisladas, estos no son solo conveniencias. Son armadura.

¿Y si todavía estás ejecutando PHP directamente en tu máquina host? Bueno, quizás sea hora de ponerlo en una caja. Tu futuro yo podría agradecértelo.

Pregunta para ti: ¿Ejecutas tus herramientas de desarrollo en Docker o directamente en tu host? ¿Alguna vez has considerado las implicaciones de seguridad de esa elección? Comenta abajo, tengo curiosidad sobre cómo otros manejan esto.

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/ ↩