Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Composer: el gestor de paquetes de PHP

Composer descarga y gestiona las bibliotecas en las que se basan los proyectos PHP modernos. Quien entiende composer.json, composer.lock y el autoloader despliega de forma reproducible y más segura.

Actualizado 5 min de lecturaConocimiento de PHP

En resumen: Composer es el gestor de paquetes de PHP. Lee del archivo composer.json qué bibliotecas necesita un proyecto, las descarga en la carpeta vendor, registra las versiones exactas en composer.lock y genera un autoloader que encuentra las clases automáticamente. Así, Composer gestiona el código de su aplicación, no el propio intérprete de PHP: una actualización de Composer no cierra ninguna vulnerabilidad de PHP como PHP2Shell.

¿Qué es Composer y para qué se necesita?

Hoy casi ninguna aplicación PHP consta solo de código propio. Frameworks, bibliotecas de correo, generación de PDF o conexiones de pago se añaden como paquetes ya hechos. Composer, el gestor de paquetes de PHP, se encarga de que estos paquetes se reúnan en versiones compatibles y de que cada dependencia traiga consigo sus propias dependencias.

Para quienes toman decisiones esto significa: una gran parte del código que se ejecuta en su servidor procede de terceros. Es eficiente, pero exige mantenimiento. Para administradores y desarrolladores significa: quien usa Composer con orden puede saber en todo momento qué versión de qué biblioteca se ejecuta en producción.

Según la documentación de Composer, la fuente estándar de paquetes es Packagist.org. Otras fuentes, por ejemplo repositorios internos de una agencia, pueden registrarse en composer.json bajo repositories.

composer.json, composer.lock y vendor: los tres componentes

Composer trabaja con tres elementos que conviene conocer antes de hacerse cargo de un servidor o de encargar un trabajo a una agencia.

Componente Contenido ¿Va al repositorio?
composer.json paquetes deseados con rangos de versiones (require, require-dev), reglas de autoload, ajustes sí
composer.lock versiones exactas resueltas de todos los paquetes, también de los indirectos sí, expresamente según la documentación de Composer
vendor/ código descargado de los paquetes y el autoloader generado no, se genera durante la instalación

Bajo require figuran los paquetes que la aplicación necesita en funcionamiento. Bajo require-dev figuran herramientas para el desarrollo y las pruebas, como frameworks de pruebas o análisis estático. Esta separación es importante, porque las herramientas de desarrollo no tienen sitio en un servidor de producción.

{
    "require": {
        "php": ">=8.3",
        "monolog/monolog": "^3.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

Las versiones del ejemplo se han elegido solo a modo ilustrativo. Qué versiones necesita su proyecto se deduce de sus requisitos.

install o update: la diferencia en la operación

Los dos comandos suenan parecido, pero tienen consecuencias muy distintas.

  • composer install lee el composer.lock e instala exactamente las versiones registradas allí. Es reproducible y pertenece al despliegue.
  • composer update resuelve de nuevo todas las dependencias, obtiene las últimas versiones compatibles y reescribe el composer.lock. Pertenece al desarrollo, con pruebas posteriores.

Según la documentación de Composer, update ejecuta además tras escribir el archivo lock una comprobación de seguridad (audit), salvo que se desactive con --no-audit. install no la realiza por defecto; para eso existe la opción --audit.

Autoloading: cómo encuentra Composer las clases

Composer genera el archivo vendor/autoload.php. Una vez incluido, PHP carga cada clase solo cuando se necesita. Para el código propio, la sección autoload establece qué espacio de nombres está en qué carpeta. Se recomienda PSR-4, un estándar de PHP-FIG. Cómo funciona exactamente lo explica la página Espacios de nombres y autoloading; un resumen de todos los estándares ofrece la página Estándares PSR.

<?php
require __DIR__ . '/../vendor/autoload.php';

$log = new Monolog\Logger('app');   // se carga automáticamente cuando hace falta

Composer en producción: desplegar con orden

Para el despliegue se ha impuesto un orden fijo. Lo mejor es ejecutarlo en un pipeline de compilación y no a mano en el servidor.

  1. Comprobar el archivo lock: composer validate garantiza que composer.json es válido y que composer.lock está actualizado.
  2. Instalar sin paquetes de desarrollo: composer install --no-dev omite require-dev.
  3. Optimizar el autoloader: --optimize-autoloader (abreviado -o) convierte las reglas en una lista de clases. Con --classmap-authoritative, PHP carga las clases exclusivamente desde esa lista.
  4. Comprobación de seguridad: composer audit --locked contrasta las versiones del archivo lock con los avisos de seguridad conocidos e informa de los paquetes abandonados.
  5. vendor fuera de la raíz web: solo la carpeta pública con el script de entrada debería ser accesible mediante URL.
composer validate
composer install --no-dev --optimize-autoloader
composer audit --locked --no-dev

composer outdated muestra además qué paquetes instalados tienen versiones más recientes. Es la base para actualizaciones planificadas en lugar de acciones aisladas y apresuradas.

Composer, seguridad y PHP2Shell

Composer y PHP2Shell afectan a dos niveles distintos. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están en el propio intérprete de PHP. Están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y después deben reiniciarse todos los procesos de PHP. Ningún composer update ni ningún paquete en vendor cambia nada de eso.

Aun así, Composer forma parte de toda revisión tras un incidente. Quien introduce código malicioso en un servidor también puede modificar archivos en vendor, y vendor/autoload.php se carga en cada petición. Por eso, un composer install nuevo a partir del archivo lock verificado en un directorio vacío es un buen método para restablecer el conjunto de paquetes. Cómo comprobar periódicamente las dependencias en busca de vulnerabilidades conocidas lo describe la guía composer audit.

Importante

Un composer audit en verde no dice nada sobre el estado de los parches de PHP. Compruebe el entorno de ejecución de PHP por separado, por ejemplo con nuestro servicio de parcheo de PHP.

¿Cómo ayuda PHP SOS en concreto?

  • Inventariamos para cada aplicación la versión de PHP, los paquetes de Composer y el estado del archivo lock, separando con claridad el intérprete y las bibliotecas.
  • Comprobamos si vendor y el archivo lock concuerdan y si hay paquetes de desarrollo o archivos modificados en producción.
  • Establecemos un despliegue reproducible con install --no-dev, autoloader optimizado y audit.
  • Tras un incidente, restablecemos el conjunto de paquetes a partir del archivo lock verificado y documentamos el resultado.

Preguntas frecuentes

¿Debe estar composer.lock en el repositorio Git?

Sí. La documentación de Composer recomienda expresamente confirmar (commit) el composer.lock. Solo así el desarrollo, la CI y la producción instalan exactamente las mismas versiones de los paquetes.

¿Cuál es la diferencia entre composer install y composer update?

install instala las versiones registradas en composer.lock. update resuelve de nuevo las dependencias, obtiene versiones más recientes compatibles y reescribe composer.lock. En el servidor de producción solo corresponde install.

¿Cierra una actualización de Composer la vulnerabilidad PHP2Shell?

No. Composer gestiona las bibliotecas de su aplicación, no el intérprete de PHP. PHP2Shell solo se cierra con la actualización del entorno de ejecución de PHP a una versión corregida y el reinicio de todos los procesos de PHP.

¿Dónde debe estar la carpeta vendor?

Idealmente fuera del directorio web accesible públicamente. Muchos frameworks colocan en la raíz web solo una carpeta public, mientras que vendor queda un nivel por encima.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata