Guía para propietarios · PHP

Cómo comprobar tu versión de PHP y actualizar de forma segura

Guía para propietarios: comprueba PHP en WordPress, hosting o SSH, haz un respaldo completo y aplica las correcciones de octubre de 2026 según tu entorno.

Por qué conviene actualizar

El 21 de octubre de 2026, PHP publicó correcciones para CVE-2026-109618 y CVE-2026-109619. Estas fallas del runtime pueden permitir ejecución remota de código sin autenticación en instalaciones que atienden solicitudes web. Actualiza la rama que utiliza tu sitio a su versión corregida o a una revisión del proveedor que incluya ambas correcciones.

Rama de PHPVersión corregida de PHP.net
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

PHP 8.1 y anteriores ya no reciben versiones oficiales de PHP.net: confirma un backport con tu proveedor de distribución/LTS o migra a una rama con soporte. PHP 8.2 llega al fin de soporte el 31 de diciembre de 2026; programa también esa migración.

Fuentes oficiales: PHP.net · 2026

1. Antes de cambiar nada: respaldo completo

  1. Guarda archivos, base de datos y configuración

    Haz un respaldo completo del sitio y del servidor o servicio correspondiente. Incluye archivos subidos, configuración de PHP y del servidor web. Guarda una copia fuera del servidor y comprueba que puedes restaurarla.

  2. Prepara una prueba y una ventana de mantenimiento

    Anota la versión actual, extensiones, dominios y pools que utiliza cada sitio. Prueba la actualización en una copia de staging cuando sea posible y define cómo restaurar el servicio si hay incompatibilidades. Si necesitas volver a un runtime vulnerable, mantén el sitio fuera de línea hasta corregirlo.

2. Comprueba el PHP que realmente usa tu sitio

  1. WordPress

    En el administrador abre Herramientas → Salud del sitio → Información → Servidor (Tools → Site Health → Info → Server). Anota la versión de PHP. Este dato corresponde al sitio web; si usas paquetes de una distribución, pide también la revisión completa al hosting.

  2. cPanel o Plesk

    En cPanel abre Software → MultiPHP Manager y revisa cada dominio. En Plesk abre Sitios web y dominios → tu dominio → Configuración de PHP (PHP Settings). Anota la versión y el controlador activos; distintos dominios pueden usar distintos PHP.

  3. SSH: consola y PHP-FPM

    En tu propio servidor, consulta ambas versiones. El PHP de consola puede ser distinto al que atiende la web. Si no existe php-fpm sin versión, usa el binario de tu rama, por ejemplo php8.3-fpm -v. En Apache con mod_php confirma también el módulo y el paquete activos.

    php -v
php-fpm -v

  4. Ubuntu/Debian: revisa el paquete completo

    Ejemplo para PHP 8.3 con FPM: adapta los nombres a tu instalación. apt policy muestra la versión instalada, la candidata y el repositorio; dpkg -l permite revisar PHP, extensiones y el módulo de Apache.

    php8.3-fpm -v
apt policy php8.3-fpm php8.3-cli php8.3-common
dpkg -l 'php*' 'libapache2-mod-php*'

Las distribuciones incorporan parches sin cambiar toda la numeración de PHP. Por eso 8.3.6 en Ubuntu puede estar corregido: compara la revisión completa del paquete y su origen con el aviso de tu distribución, no solo php -v. Estas son revisiones corregidas publicadas; una revisión posterior debe estar confirmada por el mismo proveedor.

Sistema y paqueteRevisión corregida
Ubuntu 22.04 · php8.18.1.2-1ubuntu2.28
Ubuntu 24.04 · php8.38.3.6-0ubuntu0.24.04.13
Ubuntu 26.04 · php8.58.5.4-0ubuntu1.5
Ubuntu 26.10 · php8.58.5.9-0ubuntu2.1
Debian bookworm · php8.2 · DLA-4848-18.2.35-1~deb12u1
Debian trixie · php8.4 · DSA-6574-18.4.27-1~deb13u1

Ubuntu: USN-8948-1; versiones antiguas pueden necesitar Ubuntu Pro. Debian: DSA-6574-1 para trixie y DLA-4848-1 para bookworm. El tracker de Debian señala sid como pendiente en el corte de esta guía. No uses revisiones de otra distribución o versión del sistema.

Fuentes oficiales: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1

3. Actualiza según tu entorno

Empieza siempre por el respaldo completo del paso 1. Sigue únicamente la opción que corresponda a tu sitio y vuelve a comprobar la web después de reiniciar o desplegar.

Hosting compartido: cPanel / Plesk

  1. Respalda y pide el parche al proveedor

    Conserva el respaldo completo antes de cambiar PHP. Si solo tienes acceso de cliente, pide al hosting que instale la revisión corregida; elegir “8.3” o “8.4” por sí solo no demuestra que esté aplicada.

  2. cPanel: actualiza EasyApache y selecciona el dominio

    El administrador debe actualizar los paquetes de EasyApache 4 en WHM. Las versiones corregidas son ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36 y ea-php82 8.2.35. Después selecciona el dominio en MultiPHP Manager y aplica una rama compatible ya corregida.

  3. Plesk: actualiza el runtime y su configuración

    El administrador debe instalar las actualizaciones de PHP mediante el instalador de Plesk y seleccionar el runtime en PHP Settings del dominio. El aviso indica 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 para Linux; no presupongas lo mismo en Windows o PHP 7.4–8.1: consulta al proveedor.

  4. Confirma el reinicio y prueba cada dominio

    Pide que reinicien los workers de PHP-FPM o Apache que atienden el sitio. Revisa de nuevo la versión real y prueba inicio de sesión, formularios y cargas habituales.

Fuentes oficiales: cPanel · EasyApache 4 · Plesk · PHP

Ubuntu / Debian y PPA de Ondřej: apt

  1. Respalda e identifica la rama y el repositorio

    Con el respaldo completo listo, compara apt policy con USN-8948-1 o el aviso de Debian. Si el servidor Ubuntu ya usa ppa:ondrej/php, verifica los paquetes corregidos 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 publicados para jammy y noble el 21 de octubre. No añadas un PPA de Ubuntu a Debian ni mezcles repositorios para seguir este ejemplo.

  2. Actualiza los paquetes de la rama instalada

    Ejemplo para PHP 8.3 con FPM. Sustituye 8.3 por tu rama y agrega a la actualización las extensiones instaladas que utiliza la aplicación. Con mod_php, actualiza también el paquete libapache2-mod-php de tu rama. Si no aparece una candidata corregida, resuelve el repositorio con el proveedor antes de continuar.

    sudo apt update
apt policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

  3. Reinicia PHP-FPM si tu sitio lo utiliza

    Usa el servicio de la rama que realmente atiende la web; repite en cada pool, servicio o servidor correspondiente. Este ejemplo es para PHP 8.3.

    sudo systemctl restart php8.3-fpm

  4. Reinicia Apache si tu sitio lo utiliza

    Para Apache con mod_php, este reinicio es necesario para cargar el parche. Si Apache usa FPM, reinicia también el FPM correspondiente. Después revisa apt policy, la web y los registros.

    sudo systemctl restart apache2

Fuentes oficiales: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1 · Ondřej Surý · Launchpad

Docker: imágenes oficiales de PHP

  1. Respalda también los datos persistentes

    Antes de reconstruir, respalda base de datos, archivos subidos, volúmenes y configuración. Una imagen de contenedor no es un respaldo de esos datos.

  2. Fija una etiqueta corregida

    Usa php:8.5.12, php:8.4.27, php:8.3.36 o php:8.2.35 con la variante adecuada, por ejemplo -fpm o -apache. Conserva la variante de sistema y las extensiones que requiere tu aplicación. Ejemplo de Dockerfile:

    FROM php:8.4.27-fpm

  3. Reconstruye y vuelve a desplegar

    Ejemplo para Docker Compose con servicios que se construyen desde un Dockerfile: descarga la base actualizada y reconstruye sin caché. En otro orquestador, publica y despliega la nueva imagen por su flujo habitual. Si Compose solo usa image:, cambia la etiqueta y descarga la imagen corregida antes de recrear el servicio.

    docker compose build --pull --no-cache
docker compose up -d

  4. Verifica todas las réplicas

    Comprueba PHP dentro de los contenedores nuevos y el runtime que atiende la web. Confirma que ninguna réplica anterior siga recibiendo tráfico y prueba la aplicación.

Fuentes oficiales: Docker · Official Images / PHP · PHP.net · 2026

Laravel Forge

  1. Respalda servidor y aplicación

    Guarda el respaldo completo antes de aplicar cambios. El aviso de Laravel del 21 de octubre, actualizado a las 17:12 UTC, distingue el método según la rama.

  2. PHP 8.5: Update PHP

    Abre tu servidor en el panel de Forge y pulsa Update PHP. Confirma que termina con una revisión corregida y que los servicios se reinician.

  3. PHP 8.2–8.4: SSH y apt

    Según ese aviso, usa SSH y el procedimiento apt de esta guía, con los paquetes y el servicio de tu rama. Reinicia PHP-FPM y Apache cuando corresponda; revisa también otros procesos persistentes de la aplicación.

  4. Si no puedes actualizar

    Laravel recomienda apagar el servidor hasta poder aplicar la actualización. Conserva primero tu respaldo. Si usas Vapor, el aviso indica volver a desplegar para incorporar el runtime actualizado.

Fuentes oficiales: Laravel · 2026-10-21

WordPress: el cambio está en el hosting

  1. Respalda WordPress completo

    Guarda archivos, subidas, base de datos y configuración; comprueba la restauración antes del cambio de runtime.

  2. Actualiza el PHP que ejecuta WordPress

    Sigue la opción de hosting, apt o Docker que use tu instalación. Actualizar WordPress, un tema o un plugin no corrige estas fallas del runtime de PHP. Pide al proveedor confirmación de ambas correcciones si gestiona el servidor.

  3. Vuelve a Salud del sitio

    Comprueba Herramientas → Salud del sitio → Información → Servidor y pide la revisión del paquete si hay backports. Prueba acceso al administrador, formularios, compras y cargas que utilice el sitio.

Fuentes oficiales: PHP.net · 2026

4. Confirma la actualización antes de cerrar

  1. Verifica el runtime web y los paquetes

    Confirma la versión corregida o el backport del proveedor, el reinicio de todos los workers y cada dominio, servidor o réplica. Una consola actualizada no prueba que el PHP de la web ya esté corregido.

  2. Prueba las funciones habituales

    Comprueba páginas, inicio de sesión, formularios, cargas y pagos según la aplicación. Revisa errores y conserva el respaldo y el registro de las versiones aplicadas.

Cloudflare: protección provisional mientras actualizas

  1. Confirma el proxy: nube naranja

    Cloudflare indica que sus reglas se desplegaron automáticamente desde el 21 de octubre de 2026 a las 03:02 UTC en todos los planes, incluido Free mediante Cloudflare Managed Free Ruleset. Comprueba que los nombres DNS que sirven la web estén proxied, con nube naranja.

  2. Pro, Business y Enterprise: confirma Block

    Comprueba que Cloudflare Managed Ruleset esté desplegado y que las reglas de protección estén en modo Block. Revisa Security → Security Analytics → Events para confirmar su actividad.

El WAF no es el parche. Solo protege el tráfico que pasa por Cloudflare y no corrige el runtime del servidor; completa la actualización aunque las reglas estén activas.

Fuentes oficiales: Cloudflare · WAF

Mitigaciones temporales de PHP.net: incompletas

Úsalas únicamente con el administrador mientras se prepara el parche, con respaldo completo antes de editar la configuración. No hacen que una instalación vulnerable sea segura.

  1. memory_limit=-1 a nivel administrativo

    PHP.net indica quitar el límite de memoria de PHP mediante php_admin_value, sin permitir que la aplicación lo reduzca de nuevo. Ejemplo de pool FPM; en Apache la sintaxis es php_admin_value memory_limit -1. Esto puede aumentar el consumo de memoria: el administrador debe vigilar la capacidad del servidor.

    php_admin_value[memory_limit] = -1

  2. Límites de POST y progreso de subida

    En php.ini o configuración del servidor, usa post_max_size=8M sin cargas o 32M si son necesarias, con upload_max_filesize por debajo. Configura session.upload_progress.enabled=0 antes del procesamiento de solicitudes; ini_set() y .user.ini no bastan. Adapta estos valores de ejemplo al sitio:

    post_max_size = 8M
upload_max_filesize = 2M
session.upload_progress.enabled = 0

  3. PHP 8.5: desactiva las trazas de errores fatales

    Solo en PHP 8.5, aplica también esta opción en la configuración del servidor.

    fatal_error_backtraces = 0

  4. Reinicia todos los workers

    Reinicia todos los servicios de PHP-FPM o Apache afectados y verifica la configuración efectiva de cada sitio. Estas medidas cubren solo parte del problema; sigue hasta instalar el parche.

No hay una mitigación completa que sustituya a la actualización. Si no puedes corregir el servidor, coordina con su propietario una interrupción temporal del servicio.

Fuentes oficiales: PHP.net · 2026

¿Necesitas ayuda? Contrátanos

Podemos ayudarte a identificar el runtime, preparar el respaldo, aplicar la actualización y comprobar que tu sitio siga funcionando.

Contratar ayuda para actualizar PHPEscribir a Humberto

Solo trabajamos en sitios que su propietario autoriza por escrito y siempre hacemos un respaldo completo antes de cambiar nada.