# Cómo actualizar la versión de PHP en Plesk, cPanel y PrestaShop
*Comprueba qué PHP utiliza tu web, pide el parche a tu alojamiento o aplícalo desde el panel. Estos son los pasos para Plesk y cPanel, las precauciones para PrestaShop y las comprobaciones antes de volver a trabajar.*
Por Carlos Sánchez, con ayuda de IA
Publicado el 21 de octubre de 2026, 23:49 · Revisado el 26 de octubre de 2026, 09:29
Para corregir los fallos PHP2Shell hay que actualizar el PHP del servidor. Actualizar WordPress, PrestaShop o sus plugins no basta. Si tu alojamiento se encarga del servidor, empieza por pedirle que confirme que ha instalado la corrección.
Esta guía explica cómo comprobar tu versión, actualizar desde Plesk o cPanel y revisar que la web sigue funcionando. Si buscas una explicación de los fallos, está en [la noticia sobre los dos problemas de seguridad de PHP](https://seomanal.es/software/php-parchea-dos-fallos-criticos-que-permiten-ejecutar-codigo-sin-login/).
## Comprobar qué versión de PHP usa tu web
Puedes consultarla sin entrar en la consola del servidor:
*Saber la versión de PHP en Wordpress*
- **WordPress:** Herramientas → Salud del sitio → Información → Servidor. Busca «Versión de PHP».
- **PrestaShop:** Parámetros avanzados → Información. La versión aparece en la información del servidor.\
Cuidado que no todas las versiones de prestashop soportan todas las versiones de PHP:
- - **PrestaShop 1.6:** Soporta **PHP 5.2 a 7.1** \[Debe actualizarse a una versión de prestashop segura o debe usar otras medidas como cloudflare o protección extra del hosting\]
- **PrestaShop 1.7:** Soporta **PHP 5.4 a 7.4** \[Debe actualizarse a una versión de prestashop segura o debe usar otras medidas como cloudflare o protección extra del hosting\]
- **PrestaShop 8 (8.1.x):** Soporta desde **PHP 7.2.5 hasta PHP 8.1** (con PHP 8.1 recomendado)
- **PrestaShop 9 (9.0 / 9.1):** Soporta desde **PHP 8.1 hasta PHP 8.3 / 8.5** (según subversión, con PHP 8.3 recomendado)
- **Plesk:** Sitios web y dominios → elige el dominio → PHP o Configuración de PHP.
- **cPanel:** Software → MultiPHP Manager. Algunos alojamientos usan «Select PHP Version» o «Seleccionar versión de PHP».
Comprueba cada dominio: dos webs del mismo alojamiento pueden utilizar versiones distintas. Si el panel solo muestra «8.3» o «8.4», pide al proveedor el número completo y la confirmación del parche.
El [aviso oficial de PHP](https://www.php.net/archive/2026.php#2026-10-21-5) recoge estas versiones, publicadas el 21 de octubre de 2026:
| Versión que utilizas | Versión con la corrección |
| --- | --- |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 o anterior | Sin nuevas versiones oficiales. Consulta si tu proveedor ofrece un paquete corregido para la que utilizas. |
Algunos proveedores incorporan la corrección sin cambiar el número principal que ves en el panel. Una versión inferior a la tabla necesita una comprobación con el alojamiento; por sí sola no demuestra que siga siendo vulnerable.
## Pedir la actualización al proveedor de alojamiento
Si tienes un hosting compartido o gestionado, normalmente el proveedor instala las actualizaciones de PHP. Tú puedes tener permiso para elegir una versión para tu web, pero eso no significa que puedas instalar el parche en el servidor.
Revisa sus avisos de seguridad. Si no hay una confirmación clara para tu cuenta, puedes enviar este mensaje al soporte:
> Hola. Necesito confirmar que mis webs están protegidas frente a los fallos CVE-2026-109618 y CVE-2026-109619 de PHP, conocidos como PHP2Shell.
>
> ¿Qué versión de PHP utiliza cada dominio? ¿Habéis instalado la corrección y reiniciado los servicios necesarios?
>
> Si alguna web utiliza una versión antigua, indicadme si tiene un parche del proveedor o qué cambio necesita. Antes de cambiarla a otra versión de PHP, necesito comprobar la compatibilidad de la web.
>
> Si hace falta una parada, os pido que sea breve y que el servidor devuelva un código 503, para indicar que es temporal. Gracias.
Guarda la respuesta. Si el proveedor ya ha aplicado la corrección, pasa a las comprobaciones del final de esta guía.
## Preparar la actualización de PHP
**Actualizar dentro de la misma versión y cambiar a otra son operaciones distintas.** Pasar de PHP 8.3.35 a 8.3.36 instala una corrección. Pasar de PHP 7.4 a 8.4 puede exigir cambios en la web, los temas o los módulos.
1. Comprueba que tienes una copia reciente de los archivos y de la base de datos, y que sabes cómo recuperarla.
2. Anota qué versión usa cada dominio.
3. Si vas a cambiar, por ejemplo, de PHP 8.1 a 8.4, revisa la compatibilidad y pruébalo primero en una copia de la web.
4. Haz el cambio cuando puedas comprobar el resultado y tengas disponible al soporte si algo falla.
Si la versión actual tiene una actualización corregida y compatible, no necesitas aprovechar esta intervención para cambiar también de versión de WordPress, PrestaShop o plantilla.
## Actualizar la versión de PHP en Plesk
En Plesk hay dos tareas: instalar las actualizaciones disponibles en el servidor y comprobar qué PHP utiliza cada dominio. La primera requiere permisos de administración. Si no ves «Herramientas y configuración», pide al alojamiento que la haga.
*Puedes elegir la configuración de PHP en tu plesk*
### Instalar la actualización en el servidor
1. Entra en **Herramientas y configuración → Actualizaciones**. Se abrirá el instalador de Plesk.
2. Abre **Actualizar componentes** o «Actualización de componentes del producto», según el idioma del panel.
3. Revisa las versiones de PHP con actualizaciones disponibles y pulsa **Continuar**.
4. Espera a que termine y comprueba que no haya errores. Revisa las versiones instaladas en **Herramientas y configuración → Componentes de Plesk**.
5. Confirma que los servicios de PHP que utilizan tus webs se han reiniciado. Si no sabes comprobarlo, pídelo al administrador.
*Actualización con plesk*
El recorrido está descrito en la [documentación de actualizaciones de Plesk](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-updates-and-upgrades.59215/). Que ha sido probado y ejecutado con éxito.
### Elegir la versión que utiliza cada dominio
1. Ve a **Sitios web y dominios** y selecciona la web.
2. Abre **PHP** o **Configuración de PHP**.
3. Comprueba la versión seleccionada. Si necesitas cambiarla, elige una que tenga la corrección y sea compatible con tu web.
4. Guarda el cambio y prueba la web. Repite la comprobación en los demás dominios.
Si falta la versión que necesitas, tendrá que instalarla el administrador. Puedes consultar el selector en la [ayuda de configuración de PHP de Plesk](https://docs.plesk.com/en-US/obsidian/customer-guide/websites-and-domains/hosting-settings/php-settings.70742/).
## Actualizar la versión de PHP en cPanel
**cPanel permite elegir la versión de una web; WHM permite administrar el servidor.** Si solo tienes cPanel, empieza por pedir al proveedor que confirme que las versiones disponibles incluyen la corrección.
### Cambiar la versión de un dominio desde cPanel
*PHP en Plesk*
1. Abre **Software → MultiPHP Manager**.
2. Selecciona el dominio que quieres revisar.
3. Si necesitas cambiarlo, elige una versión compatible que el proveedor haya confirmado como corregida.
4. Pulsa **Apply** o «Aplicar» y comprueba la web.
Estos pasos corresponden a [MultiPHP Manager](https://docs.cpanel.net/cpanel/software/multiphp-manager-for-cpanel/). Si tu panel muestra «Select PHP Version», utiliza las instrucciones de tu alojamiento: es un selector diferente.
### Instalar la actualización desde WHM
Este apartado es para quien administra el servidor.
1. Comprueba que el proveedor de los paquetes de PHP ya ha publicado la corrección.
2. Entra en **Software → System Update**. Esta herramienta [actualiza los paquetes del servidor](https://docs.cpanel.net/whm/software/system-update/), no solo PHP. Si necesitas actualizar únicamente PHP, el administrador debe hacerlo por la vía correspondiente a su sistema.
3. Tras instalarla, reinicia el servicio que ejecuta PHP. Si utilizas PHP-FPM, está en **Restart Services → PHP-FPM Service for Apache**, según la [documentación de cPanel](https://docs.cpanel.net/whm/restart-services/restart-services/). Otras configuraciones pueden requerir reiniciar Apache u otro servicio.
4. Revisa en **Software → MultiPHP Manager** qué versión usa cada dominio y confirma que todos utilizan paquetes corregidos.
Si el servidor usa CloudLinux y su selector de PHP, comprueba también las versiones gestionadas por ese selector. Actualizar una instalación de PHP no garantiza que las demás estén actualizadas.
## Actualizar PHP si tu tienda usa PrestaShop
PHP se actualiza desde el alojamiento o el servidor, no desde el panel de PrestaShop. Antes de cambiar de versión, comprueba que sea compatible con tu versión de la tienda, la plantilla y los módulos.
1. Consulta la versión actual en **Parámetros avanzados → Información**.
2. Pide al alojamiento que confirme si esa versión tiene la corrección.
3. Si necesitas pasar a otra versión de PHP, prueba primero una copia de la tienda.
4. Después del cambio, revisa el acceso al panel, las fichas de producto, el carrito y el proceso de compra.
Para tiendas antiguas, [PrestaShop recomienda preguntar por un paquete corregido para el PHP que ya utilizan](https://build.prestashop-project.org/news/2026/php-security-updates-october-2026/). Una migración completa de la tienda requiere su propia preparación; no conviene improvisarla como respuesta a esta urgencia.
## Cerrar temporalmente la web durante la actualización
Pregunta al administrador si hace falta cerrar. Si hay una parada, prepara un aviso de mantenimiento servido por el alojamiento o el CDN, sin depender de PHP. Activar un plugin de mantenimiento no bloquea estos ataques, porque pueden ocurrir antes de que se ejecute la aplicación.
Para una interrupción breve, [Google recomienda responder con un código 503](https://developers.google.com/search/docs/crawling-indexing/pause-online-business). Ese código indica que la web no está disponible temporalmente. No garantiza conservar las posiciones si el cierre se prolonga.
- **503 durante la parada:** no devuelvas un 404, que indica que la página no existe, ni un 200 con el mismo aviso en todas las páginas.
- **Retry-After:** esta cabecera permite indicar al rastreador cuándo puede volver a intentarlo. Es una indicación, no una cita garantizada.
- **robots.txt accesible:** conserva su respuesta normal y no añadas un bloqueo general para hacer el mantenimiento.
- **Una parada breve:** Google plantea el 503 para cierres de uno o dos días. Una interrupción más larga puede afectar a la indexación.
Si no administras el servidor, pasa estas indicaciones al alojamiento. No necesitas modificar archivos de configuración para pedir una parada bien hecha. Para ampliar, tienes los artículos sobre [códigos de respuesta y SEO](https://sanchezdonate.net/articulo/codigos-de-respuesta/) y [el uso de 503 y Retry-After](https://sanchezdonate.net/articulo/reducir-a-google-el-rastreo-por-nuestra-web/).
## Qué hacer si todavía no puedes actualizar
Pregunta al proveedor cómo va a proteger el servidor y cuándo tendrá disponible la corrección. Según el [equipo de PHP](https://www.php.net/archive/2026.php#2026-10-21-5), las medidas temporales solo bloquean algunas formas de ataque; la solución completa es instalar la actualización.
Cloudflare u otro cortafuegos web pueden añadir protección, pero no sustituyen el parche. Bloquear formularios o subidas también puede impedir pagos, altas de usuarios o importaciones: cualquier medida temporal debe revisarla quien administra el servidor. Si no puede mantenerlo protegido, tendrá que valorar aislarlo hasta actualizar.
*Ejemplo de como [Cloudflare ha sabido sacarle partido al error](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) para hacer un deploy en tiempo record*
## Comprobar la web después de actualizar PHP
1. **Confirma la versión y el parche.** Revisa cada dominio y pide al administrador que confirme el reinicio de los servicios necesarios.
2. **Prueba varias páginas.** Abre la portada, una categoría, una ficha o artículo y el panel de administración. Comprueba también formularios, subidas y, si hay tienda, una compra de prueba.
3. **Retira el mantenimiento.** Comprueba que las páginas vuelven a mostrar su contenido y a responder con normalidad. Elimina los bloqueos temporales que ya no hagan falta.
4. **Revisa Search Console.** En Ajustes → Estadísticas de rastreo, observa si persisten los errores del servidor. Los informes no se actualizan al instante.
5. **Pide una revisión de seguridad si hubo exposición.** Instalar el parche no elimina una intrusión anterior. Si aparecen archivos, usuarios o tareas desconocidos, pide al responsable técnico que investigue y conserve los registros.
## Referencias
1. (PrestaShop), K. P. (2026, 21 de octubre). *Critical PHP security updates: what PrestaShop users need to know*. build.prestashop-project.org. («Top priority for every merchant»; PS 9 = PHP 8.1–8.5; Parámetros avanzados › Información)
2. (SEJ), V. P. (2026, 21 de octubre). *Critical PHP Core Security Flaws Affect Websites, Including WordPress*. Search Engine Journal. (Salud del sitio en WordPress; webs públicas neerlandesas y finlandesas fuera)
3. Automattic (2026, 21 de octubre). *Your Sites Are Protected Against the PHP2Shell Vulnerabilities*. automattic.com. (WordPress.com, VIP, WP Cloud, Pressable y Tumblr ya protegidos; «nothing you need to do»; a los demás, pedir confirmación al proveedor)
4. Barry Schwartz (Search Engine Roundtable) (2026, 21 de octubre). *Google Advice On Taking Sites Down When Fixing PHP2Shell*. Search Engine Roundtable. (Recoge la publicación de John Mueller)
5. Central, G. S. (2011, 26 de enero). *How to deal with planned site downtime*. Google Search Central. (Enlazado por Mueller: 503 + Retry-After para paradas programadas)
6. Central, G. S. (2025, 10 de diciembre). *Pause or disable your online business*. Google Search Central. (Enlazado por Mueller: 503 solo días, Retry-After, nada de 404/410/403/noindex, portada estática con 200)
7. Central, G. S. (2026, 4 de febrero). *How HTTP status codes and network errors affect Google Search*. Google Search Central. (5xx: contenido ignorado, URL se mantienen y luego se retiran; 429 como sobrecarga; 4xx retiran; soft 404 con 200)
8. Central, G. S. (2026, 6 de octubre). *Reduce the Googlebot crawl rate*. Google Search Central. (Sección de emergencias: 500/503/429, Retry-After, 1-2 días como mucho; actualizada el 6-10-2026)
9. CISA (2026, 21 de octubre). *Critical Vulnerabilities in PHP Require Immediate Patching*. cisa.gov. (Parchear ya; sin parche o en 8.1 o menos, fuera de línea; WAF como capa; vigilar workers que lanzan shells)
10. Cloudflare (2026, 21 de octubre). *Cloudflare deploys protections against php2shell vulnerability*. Cloudflare. (Reglas desde las 03:02 UTC en todos los planes con WAF (Free incluido); comprobar modo bloqueo en planes de pago; sigue haciendo falta parchear)
11. CloudLinux (2026, 21 de octubre). *Imunify360 Ruleset 8.83 Blocks the Public Exploit Shape*. blog.cloudlinux.com. (ea-php y alt-php tras la versión oficial; ruleset 8.83)
12. cPanel (2026, 21 de octubre). *How to log in to your server or account*. docs.cpanel.net. (cPanel en el puerto 2083, WHM en el 2087, token cpsess en la URL)
13. cPanel (s. f.). *MultiPHP Manager for cPanel*. docs.cpanel.net. (Selección de la versión de PHP de un dominio.)
14. cPanel (s. f.). *Restart Services*. docs.cpanel.net. (Reinicio de PHP-FPM desde WHM.)
15. cPanel (s. f.). *System Update*. docs.cpanel.net. (Actualización de paquetes del servidor desde WHM.)
16. CybaVerse (2026, 21 de octubre). *PHP2Shell: Check Exposure and Hunt for Compromise*. cybaverse.co.uk. (Indicadores de compromiso por comportamiento)
17. de PHP, E. (2026, 21 de octubre). *Security advisory: Critical remote code execution vulnerabilities, update now*. PHP. (fuente principal)
18. Dive, C. (2026, 21 de octubre). *Critical PHP vulnerabilities expose most websites to potential compromise*. cybersecuritydive.com. (Talos: la mitad de las instancias expuestas en versiones sin parche; agencias piden apagar)
19. Escudero, D. (2026, 21 de octubre). *PHP2Shell: PrestaShop 1.6, 1.7 y 8, sin parche oficial*. davidescudero.com. (Tabla PrestaShop/PHP; fuente secundaria, no citada en el texto)
20. Geniar, M. (2026, 21 de octubre). *PHP CVE-2026-109618 and CVE-2026-109619: how to apply the patches*. ma.ttias.be. (Comandos apt/dnf, versiones de paquete por distro, comprobación de procesos viejos)
21. Huntress (2026, 21 de octubre). *Rapid Response: php2shell*. huntress.com. (Hora de publicación, causa raíz, indicadores de comportamiento)
22. Labs, M. (2026, 21 de octubre). *PHP2Shell: Why websites are going offline for emergency security updates*. malwarebytes.com. (Apagados preventivos, no indicio de brecha; consejos a propietarios y visitantes)
23. Mueller, J. (2026, 21 de octubre). *Publicación de John Mueller*. Bluesky. (503 en vez de timeouts/404/500, fuera de PHP)
24. NCSC-NL (2026, 21 de octubre). *php2shell operational information*. GitHub. (Mitigaciones y lectura adicional)
25. Patchstack (2026, 21 de octubre). *Major security alert: PHP vulnerable to critical RCE, attacks ongoing*. patchstack.com. (Cronología de explotación (07:34 UTC), webs neerlandesas apagadas vía NOS, consejos para WordPress)
26. PHP (2026, 21 de octubre). *CVE-2026-109618 (OOM corruption)*. GitHub. (Aviso del CVE)
27. PHP (2026, 21 de octubre). *CVE-2026-109619 (stale global state)*. GitHub. (Aviso del CVE)
28. PHP (2026, 21 de octubre). *Security advisory: Critical remote code execution vulnerabilities, update now*. php.net. (Fuente primaria: versiones corregidas, SAPI en riesgo, mod\_php, mitigaciones)
29. Plesk (2026, 21 de octubre). *How to log in to Plesk*. support.plesk.com. (Acceso por https://host:8443)
30. Plesk (2026, 21 de octubre). *Vulnerability CVE-2026-109618 and CVE-2026-109619: Remote code execution in PHP shipped with Plesk*. support.plesk.com. (Paquetes 8.2–8.5 publicados; 8.1/8.0/7.4 en desarrollo. Devolvió 403 al robot: leído por el resumen del buscador)
31. Plesk (s. f.). *PHP Settings*. docs.plesk.com. (Selección de PHP por dominio y compatibilidad.)
32. Plesk (s. f.). *Plesk Updates*. docs.plesk.com. (Instalación de actualizaciones desde Herramientas y configuración.)
33. Record, T. (2026, 21 de octubre). *Hundreds of websites taken offline as concern grows over two PHP vulnerabilities*. therecord.media. (Nintendo, Charité, OBS, Finlandia; avisos de agencias)
34. Register, T. (2026, 21 de octubre). *PHP devs publish critical bug fix as site owners warned*. theregister.com. (CERT-EU: aislar lo expuesto; noyb, Parlamento neerlandés, Finlandia)
35. Sánchez, C. (2026, 2 de marzo). *Códigos de respuesta desde el servidor en el SEO*. sanchezdonate.net. (Referencia enlazada: códigos por familia y cómo los lee Google)
36. Sánchez, C. (2026, 8 de octubre). *Reducir a Google el rastreo por nuestra web*. sanchezdonate.net. (Referencia enlazada: 503/429 y Retry-After, cómo se envía en Apache, LiteSpeed y nginx)
37. Sansec (2026, 21 de octubre). *PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)*. sansec.io. (Vector multipart/form-data, mitigaciones nginx/Apache, apps confirmadas)
38. Tenable (2026, 21 de octubre). *php2shell FAQ*. tenable.com. (Cloudflare ve los primeros ataques; «ini settings won’t save you»)
39. Unit 42 (Palo Alto Networks) (2026, 21 de octubre). *CVE-2026-109618 and CVE-2026-109619*. unit42.paloaltonetworks.com. (Más de 22,6 millones de instancias expuestas (telemetría propia, sin metodología))
40. W3Techs (2026, 21 de octubre). *Usage statistics and market share of PHP for websites*. w3techs.com. (69,3 % de las webs con lenguaje de servidor conocido; v8 65,2 %, v7 27 %, v5 7,7 %)
41. WooCommerce (s. f.). *How to update your PHP version*. woocommerce.com. (Consulta de la versión de PHP desde Salud del sitio de WordPress.)