Skip to main content

Aviso de seguridad: actualización obligatoria de PHP

Importante

El 21 de octubre de 2026 el proyecto PHP publicó parches para dos vulnerabilidades críticas (CVE-2026-109618 y CVE-2026-109619, puntuación CVSS 9.2) que permiten ejecutar código de forma remota, sin usuario ni contraseña, en cualquier servidor PHP que atienda peticiones web. Afectan a todas las versiones de PHP y no existe una mitigación completa: la única solución es actualizar.

Toda instalación propia del API debe actualizarse cuanto antes. Si su API está alojada por FacturaLatam, nosotros nos encargamos y no tiene que hacer nada.

Qué pasó​

Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Las vulnerabilidades están en el propio motor de PHP y afectan a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP demostró un ataque completo contra Apache con mod_php que se dispara antes de que corra una sola línea de la aplicación. PHP 8.1 y anteriores ya no reciben versiones del proyecto.

Referencias oficiales: aviso del proyecto PHP y aviso del NCSC del Reino Unido.

Qué cambia en el API​

  • La imagen Docker pasa a la imagen oficial php:8.3.36-fpm-bookworm. La anterior era una imagen de terceros con PHP 8.2.5 de 2023 que no recibía actualizaciones. Se eligió PHP 8.3 porque 8.2 deja de recibir parches el 31 de diciembre de 2026.
  • La imagen nueva conserva las mismas extensiones, Composer y los límites de PHP del API, y activa la compatibilidad con los certificados .p12 de la DIAN en OpenSSL 3.
  • Ningún endpoint, campo ni respuesta cambia. Sus integraciones siguen funcionando igual.
  • No hace falta reinstalar las dependencias: todas cumplen con PHP 8.3.

Cómo actualizar, según su instalación​

Docker (instalación 2026)​

Hay que actualizar el código y reconstruir la imagen; un pull de imágenes no sirve porque la imagen se construye en su servidor.

cd /ruta/del/api            # carpeta del código del API (donde está artisan y el .env)
git pull origin master
cd /ruta/del/compose        # carpeta donde está el docker-compose.yml (ver más abajo)
docker compose build --no-cache php_api scheduling_api
docker compose up -d php_api scheduling_api
docker restart nginx_api
docker compose exec php_api php artisan migrate      # cambios de base de datos que trajo el git pull
docker compose exec php_api php artisan config:cache
docker compose exec php_api php -v
docker compose exec php_api php-fpm -i | grep -E '^(memory_limit|max_execution_time|pcre.backtrack_limit) '

El php -v debe mostrar PHP 8.3.36 y la última línea, 4000M, 800 y 5000000: son los límites de PHP que necesita el API, que la imagen fija en docker/php-api.ini. Si en cambio sale 128M, 30 y 1000000, la imagen se construyó sin ese archivo y fallarán los PDF largos, la nómina y los reportes con Allowed memory size exhausted o muriendo a los 30 segundos: reconstruya con el código al día. El build descarga unos 500 MB y compila extensiones: cuente con tres a cinco minutos.

Ubique primero su docker-compose.yml

Los comandos docker compose leen el archivo de la carpeta desde la que se ejecutan. El git pull se hace en la carpeta del API, pero el docker-compose.yml con el que se levantó el API puede estar dentro de esa misma carpeta o fuera de ella (por ejemplo en la carpeta padre, con el API en una subcarpeta, o en otra ruta del servidor), según cómo se instaló. Ubíquelo y ejecute los comandos docker compose desde allí.

Si no recuerda dónde quedó, pregúnteselo a Docker (reemplace php_api por el nombre de su contenedor PHP si es distinto):

docker compose ls      # columna CONFIG FILES: ruta del .yml de cada proyecto levantado (solo Compose v2)
docker inspect php_api --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'

También puede indicar el archivo en cada comando en vez de cambiar de carpeta: docker compose -f /ruta/docker-compose.yml build --no-cache php_api scheduling_api. Si en su servidor hay más de un docker-compose.yml (por ejemplo el del proxy o el de PostgreSQL), el que hay que usar es el que define el servicio PHP del API.

Compruebe los nombres de sus contenedores

Los comandos de arriba usan los nombres del compose de ejemplo (php_api, scheduling_api, nginx_api). En su instalación pueden llamarse distinto, por ejemplo con el dominio como sufijo (php_api_api_midominio_com). Antes de ejecutarlos, vea los suyos con docker compose ps (o docker-compose ps, con guion, si su instalación usa esa versión) y reemplace los nombres en los comandos: el contenedor PHP del API, el del scheduler y el de nginx.

El docker restart de nginx evita un 502 Bad Gateway que aparece cuando el contenedor PHP cambia de IP interna al recrearse.

No omita el php artisan migrate. El git pull trae el código nuevo, pero las tablas y los catálogos nuevos solo se aplican con ese comando, que se ejecuta dentro del contenedor PHP y no en el servidor. Si no hay nada pendiente responde Nothing to migrate y no toca nada; si pide confirmación por estar en producción, responda yes.

Si su instalación estaba muy atrasada y el git pull modificó composer.lock, ejecute además docker compose exec php_api composer install antes del php artisan migrate. Para este cambio de PHP en sí no hace falta: vendor/ ya cumple con PHP 8.3. La rutina completa de actualización está en Actualización.

Ubuntu 22.04 con Apache y mod_php (instalador LAMP)​

Es el caso de mayor riesgo. El repositorio de ondrej ya tiene PHP 8.3.36. Actualice solo los paquetes de PHP 8.3 que ya tiene instalados:

sudo apt update
sudo apt install --only-upgrade -y $(dpkg -l '*php8.3*' | awk '/^ii/{print $2}')
sudo systemctl restart apache2               # o php8.3-fpm, si su servidor usa PHP-FPM
php -v
dpkg -l '*php8.3*' | awk '/^ii/{print $2, $3}'

php -v debe mostrar PHP 8.3.36 y la última línea debe listar todos los paquetes, incluido libapache2-mod-php8.3, en la versión 8.3.36.

Este parche no toca el código del API, así que no exige migraciones. Si aprovecha para actualizar también el código (git pull origin master en la carpeta del API), aplique allí mismo php artisan migrate y después php artisan config:cache.

No use comodines con apt upgrade

Un comando como apt upgrade 'php8.3*' no actualiza lo instalado: apt aplica el comodín a todos los paquetes del repositorio e intenta instalar decenas de extensiones que no tiene, varias de las cuales se excluyen entre sí, y termina en error después de Calculating upgrade.... Si prefiere actualizar todo el servidor, sudo apt upgrade -y sin argumentos también trae PHP 8.3.36; si después php -v sigue mostrando la versión anterior, use el comando de arriba.

Ubuntu 20.04, o imagen Docker antigua con PHP 7.2​

No existe parche: el repositorio de ondrej ya no publica para Ubuntu 20.04 y PHP 7.2 no tiene corrección. Hay que migrar, subiendo el servidor a Ubuntu 22.04 y reinstalando PHP 8.3, o pasando a la instalación Docker 2026. Mientras tanto, restrinja el acceso al API por IP en el firewall.

Hosting compartido (Hostinger y similares)​

En hosting compartido la versión de PHP la administra el proveedor y usted no puede instalar parches. En Hostinger no hay que ejecutar nada: según su página de estado, la corrección quedó instalada en todos los servidores de hosting administrado el 22 de octubre de 2026 y los planes Web, Agency y cPanel no requieren acción del cliente. Lo que sí debe hacer es comprobar que su sitio ya la tiene:

  1. En hPanel entre a Websites, pulse Dashboard junto al sitio donde corre el API y abra PHP Info en el menú lateral (puede escribirlo en el buscador del menú).
  2. Arriba aparecen la versión de PHP y el campo Build Date. Una fecha del 21 de octubre de 2026 o posterior significa que el parche está aplicado.
  3. Si el API está en una subcarpeta o en un subdominio, cree en esa carpeta un archivo phpinfo.php con el contenido <?php phpinfo(); ?>, ábralo en el navegador y revise los mismos datos. Bórrelo al terminar.
  4. Si la fecha es anterior al 21 de octubre de 2026, abra un chat con el soporte de Hostinger y pida la actualización citando php2shell (CVE-2026-109618 y CVE-2026-109619).
No se guíe por el número de versión

Hostinger incorporó la corrección a la versión que ya corría cada sitio, así que PHP Info puede seguir mostrando la versión anterior (su página de estado pone el ejemplo de 8.5.11 en vez de 8.5.12) y estar parcheada. Lo que cuenta es el Build Date. Tampoco sirve php -v por SSH: muestra la versión del plan, no la de la carpeta donde corre el API.

Aproveche para revisar la rama de PHP en PHP Configuration (mismo menú lateral): el API funciona en 8.3. hPanel ya no permite elegir 8.1 ni anteriores, y 8.2 deja de recibir parches el 31 de diciembre de 2026. El cambio aplica a todos los sitios del plan, tarda un par de minutos y no se puede deshacer fuera de la misma sesión; después emita un documento de prueba.

En otros proveedores de hosting compartido el procedimiento es equivalente: busque en su panel la página de información de PHP, verifique la fecha de compilación o la versión (8.3.36 / 8.2.35) y, si no está, pídale al proveedor que actualice. Los planes VPS de Hostinger no están cubiertos: ahí PHP lo administra usted y aplica la sección de Docker o la de Ubuntu 22.04.

Fuentes: estado de Hostinger, cómo comprobar la versión de PHP en Hostinger y Hostinger deploys protections against php2shell.

Windows local (Laragon)​

No está expuesto a internet, por lo que el riesgo es bajo. Cuando pueda, sustituya el zip de PHP por 8.2.35 o 8.3.36 desde windows.php.net.

Mientras no pueda actualizar​

El equipo de PHP indica dos mitigaciones parciales, que reducen la exposición pero no dejan la instalación segura: session.upload_progress.enabled = 0 y memory_limit = -1, fijadas en php.ini o con php_admin_value (nunca con ini_set() ni .user.ini) y reiniciando todos los procesos de PHP. Si no puede ni actualizar ni mitigar, el NCSC recomienda desconectar el sistema y revisarlo antes de volver a exponerlo.

Cómo verificar que quedó bien​

  1. php -v muestra 8.3.36 (o 8.2.35). En Hostinger, el Build Date de PHP Info es del 21 de octubre de 2026 o posterior.
  2. Emitir un documento de prueba y descargar su PDF.
  3. Enviar el correo de ese documento.

Si en Docker aparece Error al leer la fecha del certificado - datos corruptos al emitir, la imagen se construyó con un Dockerfile anterior al 21 de octubre de 2026: haga git pull y reconstruya.

Más detalle​