# composer audit: revisar vulnerabilidades en las dependencias > Con composer audit revisa las dependencias PHP en busca de vulnerabilidades. Comandos, integración en CI y despliegue, y por qué PHP se parchea aparte. Fuente: https://phpsos.de/es/ratgeber/composer-abhaengigkeiten-pruefen/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** `composer audit` contrasta los paquetes de su proyecto PHP con los avisos de seguridad conocidos y muestra las versiones afectadas. Ejecute el comando en cada compilación y, de forma periódica, sobre el estado de producción. Importante tras PHP2Shell: la revisión abarca bibliotecas, no el propio intérprete de PHP. ## Por qué las dependencias necesitan atención justo ahora Las aplicaciones PHP modernas se componen en su mayor parte de código ajeno. Una tienda basada en Symfony o un portal con Laravel incorpora enseguida de varias decenas a cientos de paquetes, muchos de ellos de forma indirecta a través de otros paquetes. Cualquiera de esas bibliotecas puede contener una vulnerabilidad. Por eso, el OWASP Top 10 recoge los componentes obsoletos y vulnerables como una categoría de riesgo propia. En octubre de 2026, PHP2Shell ha mostrado la rapidez con que una vulnerabilidad crítica se generaliza. Las dos vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan a PHP en sí y no a paquetes de Composer. Sin embargo, muchos equipos revisaron esos días toda su cadena y comprobaron que no conocían con exactitud el estado de sus dependencias. Esta laguna en la visión de conjunto se cierra con poco esfuerzo. Composer incluye ya la herramienta adecuada en las versiones actuales. ## Qué revisa composer audit y qué no El comando lee los paquetes instalados o el archivo de bloqueo y consulta los avisos de seguridad conocidos sobre esos paquetes. Por cada coincidencia muestra el paquete, el rango de versiones afectado, la gravedad, el identificador del aviso y un enlace a la descripción. | Nivel | ¿Lo revisa composer audit? | Cómo revisarlo en su lugar | |---|---|---| | Paquetes de Composer del proyecto | sí | composer audit | | Intérprete de PHP (p. ej. PHP2Shell) | no | Estado de los paquetes, confirmación del hosting | | Extensiones de PHP del sistema | no | Gestor de paquetes de la distribución | | Paquetes de JavaScript del frontend | no | Herramienta del gestor de paquetes correspondiente | | Código propio de la aplicación | no | Revisión de código, auditoría de seguridad | El comando tiene en cuenta también las dependencias indirectas, es decir, paquetes que usted nunca pidió pero que llegan con otros paquetes. Justo ahí las vulnerabilidades pasan a menudo inadvertidas, porque nadie del equipo conoce esos paquetes. Las versiones más recientes de Composer avisan además de los paquetes que sus autores han marcado como abandonados. Esos paquetes, por lo general, ya no reciben correcciones y deberían sustituirse. Un resultado limpio solo significa, por tanto, que no hay ningún aviso conocido para las versiones de paquetes instaladas. La herramienta no encuentra vulnerabilidades desconocidas ni errores en el código propio. Cómo comprobar usted mismo la versión de PHP lo describe el artículo [Cómo comprobar bien la versión de PHP y el estado del parche](https://phpsos.de/es/php2shell/php-version-pruefen/). ## Ejecutar composer audit e interpretar los resultados En el directorio del proyecto basta un comando. Las variantes se diferencian en qué se revisa y cómo se muestra el resultado. ```bash # Revisar los paquetes instalados composer audit # Revisar solo el archivo de bloqueo, p. ej. en la compilación sin paquetes instalados composer audit --locked # Omitir las dependencias de desarrollo (estado igual al del servidor) composer audit --no-dev # Salida legible por máquina para su análisis o para el sistema de tickets composer audit --format=json > audit-$(date +%F).json ``` Si el comando encuentra vulnerabilidades, termina con un código de error. Es lo deseado, porque así se interrumpe una compilación automatizada. Valore cada coincidencia: ¿el paquete está en uso en el servidor?, ¿se utiliza la función afectada?, ¿existe una versión corregida? ```bash # ¿Qué dependencias directas están desactualizadas? composer outdated --direct # ¿Por qué está instalado un paquete concreto? composer why vendor/paket # Actualizar de forma específica, con dependencias composer update vendor/paket --with-dependencies ``` Pruebe cada actualización en un entorno de preproducción. Las actualizaciones de seguridad dentro de la misma versión principal suelen ser poco problemáticas; una nueva versión principal, en cambio, puede requerir ajustes en el código. ## Automatizar la revisión Una única llamada sirve de poco, porque constantemente se conocen vulnerabilidades nuevas. Integre por eso `composer audit` en dos puntos: en el pipeline de compilación con cada cambio y en una revisión periódica del estado de producción, aunque el código no cambie. Un script sencillo para una ejecución diaria en el servidor de compilación o de revisión puede ser así: ```bash #!/bin/sh # Auditoría diaria del estado entregado (adapte la ruta) cd /srv/build/meine-anwendung || exit 1 if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log" fi ``` Reenvíe el aviso del registro del sistema a su monitorización, a su buzón interno o a su sistema de tickets. Lo importante es que alguien sea responsable de valorar los avisos. Una auditoría cuyas advertencias nadie lee no protege. > **Consejo:** > Fije en `composer.json`, en `config.platform.php`, la versión de PHP que se ejecuta en el servidor. Entonces Composer solo resuelve paquetes que encajan con ese estado, y `composer check-platform-reqs` muestra las discrepancias. ## Entregar con limpieza: despliegue sin efectos secundarios También el camino hacia el servidor influye en la seguridad. Algunas reglas básicas han dado buen resultado: - Incluir `composer.lock` en el repositorio y ejecutar en el servidor solo `composer install`, nunca `composer update`. - Instalar con `--no-dev`, para que las herramientas de prueba y depuración no acaben en el servidor de producción. - Mantener la carpeta `vendor/` fuera del directorio raíz web, de modo que no sea accesible directamente mediante una URL. - Ejecutar `composer validate` en la compilación para detectar pronto datos erróneos o contradictorios. ```bash composer validate --strict composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction ``` Preste atención también al soporte de la propia versión de PHP. Las bibliotecas exigen cada vez más ramas actuales de PHP. Quien sigue anclado en PHP 8.1 o anterior ya no recibe actualizaciones oficiales para PHP y, a menudo, no puede instalar versiones más recientes de paquetes con correcciones de seguridad. La planificación al respecto la describe la guía [Fin de vida de PHP: riesgos de las versiones obsoletas](https://phpsos.de/es/ratgeber/php-end-of-life-risiken/). Encontrará indicaciones específicas de frameworks en [Proteger aplicaciones Laravel](https://phpsos.de/es/plattformen/laravel/). ## ¿Cómo ayuda PHP SOS en concreto? - Registramos el estado de todas las dependencias y valoramos las coincidencias según su uso real. - Configuramos revisiones automatizadas en la compilación y en la operación, con responsabilidad clara sobre los hallazgos. - Planificamos y probamos las actualizaciones, también cuando las nuevas versiones principales exigen ajustes. - Si lo desea, revisamos también el código propio y la configuración, allí donde ninguna herramienta automática mira. Una revisión por terceros la describe el servicio [Auditoría de seguridad y prueba de penetración](https://phpsos.de/es/leistungen/sicherheitsaudit-penetrationstest/). ## Preguntas frecuentes **¿Encuentra composer audit también PHP2Shell?** No. composer audit revisa los paquetes de su proyecto, no el intérprete de PHP del servidor. PHP2Shell está en el propio PHP y solo se corrige actualizando PHP y reiniciando todos los procesos de PHP. **¿Debe composer.lock estar en el repositorio?** En las aplicaciones, sí. El archivo de bloqueo fija exactamente qué versiones están instaladas. Solo así composer audit revisa el estado que realmente se ejecuta en el servidor, y cada despliegue instala las mismas versiones. **¿Qué hacer si no existe actualización para un paquete afectado?** Compruebe si su proyecto utiliza siquiera la función afectada y documente la valoración. Si no hay corrección, se plantean un paquete sustituto, un parche propio o una protección transitoria a nivel de servidor. **¿Con qué frecuencia debo ejecutar composer audit?** En cada compilación y, además, de forma periódica, por ejemplo a diario, incluso sin cambios en el código. Constantemente se comunican vulnerabilidades nuevas, y un estado que ayer estaba limpio puede estar hoy afectado. ## Fuentes - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) - [php.net: avisos de seguridad](https://www.php.net/) - [php.net: versiones con soporte](https://www.php.net/supported-versions.php)