--- title: "PHP2Shell: de versiones vulnerables de PHP a un pull request revisable con Harbyn | Harbyn" description: "Sigue un escaneo público de Harbyn, de los hallazgos de PHP2Shell a un PR de actualización real, con pins exactos, tags flotantes y las decisiones que quedan para revisión." canonical: "https://harbyn.com/mx/blog/php2shell-production-runtime" last-updated: 2026-10-22 --- # PHP2Shell: de versiones vulnerables de PHP a un pull request revisable con Harbyn Publicado el 22 de octubre de 2026 por Harbyn. Etiquetas: php, security, php2shell, developer-tools. Cuando sale una actualización crítica de PHP, el anuncio es solo el principio. La siguiente pregunta es de tu proyecto: ¿dónde está declarada la versión afectada y qué tiene que cambiar? PHP2Shell nos dio un ejemplo concreto. Corrimos Harbyn sobre un repositorio público de demostración con varias formas de declarar la versión de PHP. El escaneo reportó seis hallazgos en once archivos, y Harbyn abrió un pull request que actualiza dos pins de versión exacta. Puedes revisar la [ejecución del escaneo](https://github.com/harbyn/php2shell-demo/actions/runs/39718957930) y el [pull request real](https://github.com/harbyn/php2shell-demo/pull/1). Esto es lo que pasó y cómo probar el mismo flujo en tu repositorio. ## Qué pasó con PHP2Shell El 21 de octubre de 2026, PHP publicó correcciones para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecución remota de código sin autenticación. Las versiones corregidas son **8.2.35, 8.3.36, 8.4.27 y 8.5.12**. Consulta el [anuncio oficial de seguridad de PHP](https://www.php.net/archive/2026.php#2026-10-21-5). Para un equipo de desarrollo, actuar sobre ese anuncio significa encontrar las declaraciones de PHP repartidas por el repositorio. El runtime puede estar fijado en un Dockerfile, referenciado en Compose, configurado en un workflow o representado en la configuración de Composer. Esas declaraciones no significan lo mismo, así que no deberían recibir la misma edición. ## La demostración: seis hallazgos, un PR revisable Nuestro [repositorio de demostración](https://github.com/harbyn/php2shell-demo) es una pequeña aplicación PHP ficticia creada para esta demostración. Incluye pins de versión exacta, versiones flotantes, un requisito de Composer y una imagen de PHP 8.1. Usando Harbyn, la GitHub Action escaneó once archivos y reportó seis líneas que requieren atención. Después Harbyn abrió un PR con las actualizaciones soportadas. Así hay un camino rastreable desde el anuncio de seguridad hasta las declaraciones del repositorio y los cambios propuestos. La evidencia está en el log de la ejecución y en el diff, no en una captura ilustrativa de terminal. ## Por qué los hallazgos llevaron a acciones distintas Los seis hallazgos no eran seis correcciones idénticas: | Declaración en la demo | Qué hacer | | --- | --- | | Dos pins de versión exacta de PHP | Actualizar a la versión corregida de la misma rama de PHP. | | Dos versiones flotantes | Reconstruir o actualizar el entorno y revisar el runtime que realmente se usa. | | Un requisito de PHP en Composer | Revisar los requisitos de compatibilidad por separado del intérprete instalado. | | Una imagen de PHP 8.1 | Evaluar el paso a una rama soportada, incluida la compatibilidad de la aplicación. | Un tag flotante como `php:8.3-fpm` puede quedarse igual mientras una imagen vieja sigue desplegada. Puede no haber ninguna versión que reemplazar en el Dockerfile; el trabajo está en obtener y desplegar una imagen corregida. Las ramas antiguas de PHP también piden otra decisión. Pasar una aplicación de PHP 8.1 a una rama soportada puede afectar la compatibilidad. Los paquetes de distribuciones o de soporte extendido pueden tener las correcciones por backport, así que revisa el aviso de seguridad de los paquetes que realmente usas. El [anuncio de PHP](https://www.php.net/archive/2026.php#2026-10-21-5) habla de esas opciones. ## Dentro del pull request El [PR generado](https://github.com/harbyn/php2shell-demo/pull/1) contiene dos cambios puntuales. En el `Dockerfile`, actualiza la imagen base de PHP: ```diff -FROM php:8.3.35-fpm +FROM php:8.3.36-fpm ``` En `composer.json`, actualiza `config.platform.php`: ```diff - "php": "8.3.35" + "php": "8.3.36" ``` El segundo cambio merece una explicación. La configuración de plataforma de Composer le dice a la resolución de dependencias qué versión de PHP suponer. No instala ni actualiza PHP. Actualizarla junto con el Dockerfile alinea esa suposición con el runtime previsto. Consulta la [documentación de Composer sobre dependencias de plataforma](https://getcomposer.org/doc/articles/composer-platform-dependencies.md). El PR reúne las ediciones propuestas para revisión. Después de revisarlas, el equipo todavía construye y despliega la imagen actualizada, reemplaza las instancias viejas y verifica el runtime que atiende las peticiones. Así es como el cambio del repositorio llega a la aplicación. ## Prueba Harbyn en tu repositorio Desde la carpeta de tu repositorio, ejecuta: ```sh npx harbyn scan ``` El escáner corre localmente, descarga el feed de cambios firmado de Harbyn y revisa las declaraciones soportadas sin subir tu código fuente. Revisa los archivos, las líneas y las fuentes reportados. Para configurar el flujo de PR, sigue la [documentación de Harbyn](https://harbyn.com/docs). PHP2Shell es un ejemplo del problema que Harbyn ayuda a resolver a los desarrolladores: un cambio externo se vuelve relevante para una línea específica de un repositorio. Harbyn conecta ese cambio con el código y, cuando hay una corrección soportada, prepara la actualización para revisión. [Escanea tu proyecto](https://harbyn.com), o revisa primero el [PR público de PHP2Shell](https://github.com/harbyn/php2shell-demo/pull/1).