Vulnerabilidades críticas de PHP: qué revisar si tienes una tienda online

Si tu tienda utiliza PHP, pide a tu proveedor de hosting que confirme si ha aplicado las correcciones para CVE-2026-109618 y CVE-2026-109619. El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones para dos vulnerabilidades críticas que pueden permitir ejecutar código en un servidor sin disponer de una cuenta de usuario. Comunicado de PHP Foundation.

Para el responsable de un ecommerce, la tarea consiste en obtener tres respuestas: qué PHP ejecuta la tienda, qué corrección está instalada y quién ha comprobado que la compra sigue funcionando. Al final encontrarás una checklist y un mensaje para solicitar esa información al hosting.

Qué ha pasado y por qué importa para un ecommerce

Los dos fallos se encuentran en el propio motor de PHP, el software que ejecuta las aplicaciones escritas en este lenguaje. Uno afecta al manejo de errores por falta de memoria; el otro, a datos internos que pueden permanecer entre peticiones cuando deberían haberse limpiado. Los avisos técnicos originales describen ambas vulnerabilidades: CVE-2026-109618 y CVE-2026-109619.

El alcance depende de la instalación. PHP considera en riesgo las instalaciones que atienden peticiones web, incluidas PHP-FPM y Apache con mod_php, y señala esta última como la configuración de mayor riesgo. Utilizar PHP-FPM no permite dar la revisión por cerrada. Aviso oficial de PHP.

Tener una instalación afectada no demuestra que alguien haya entrado en ella. Tampoco basta con que la portada cargue o sigan llegando pedidos para confirmar que el parche está aplicado. La exposición técnica y el funcionamiento comercial son comprobaciones diferentes.

Cómo saber si tu tienda depende de PHP

En una tienda WooCommerce, el entorno de servidor incluye PHP. PrestaShop también lo necesita y establece compatibilidades según la versión de la plataforma. Puedes consultar los requisitos de WooCommerce y la matriz de compatibilidad de PrestaShop 8.

Actualizar WordPress, WooCommerce o un módulo no sustituye la corrección del PHP del servidor. Pide al alojamiento una confirmación específica sobre estos dos fallos, aunque tengas al día las actualizaciones de la tienda.

Si no conoces la infraestructura, empieza por el proveedor que administra el alojamiento. Envíale el dominio y solicita que identifique el PHP que atiende las peticiones de esa web.

Puedes reunir información desde estas herramientas:

• WordPress: Herramientas → Salud del sitio → Información → Servidor. Esa sección reúne datos del entorno. Documentación de WordPress.
• cPanel: MultiPHP Manager permite consultar la versión asignada a cada dominio. Una cuenta puede utilizar versiones distintas para webs diferentes. Documentación de cPanel.
• Otros alojamientos: pide al soporte la versión, el paquete instalado y el aviso de seguridad que acredita la corrección de ambos CVE.

Incluye los subdominios y entornos de pruebas que sigan accesibles. Por ejemplo, si conservas una tienda antigua en old.tudominio.com, añade ese dominio a la consulta. Esta es una comprobación de inventario: el proveedor debe confirmar cuáles de esos servicios ejecutan PHP y requieren actuación.

Qué versiones corrigen estas vulnerabilidades

Las versiones correctoras publicadas por el proyecto PHP el 21 de octubre son:

Fuente: avisos de seguridad del proyecto PHP. Esta tabla identifica los lanzamientos que corrigen estos dos fallos; no es una recomendación para cambiar cualquier tienda a PHP 8.5.

Un número antiguo puede corresponder a un paquete corregido

Las distribuciones y algunos proveedores incorporan correcciones a sus propios paquetes sin adoptar el número de versión del lanzamiento original. Este procedimiento se conoce como backport.

Por ejemplo, el aviso oficial de Ubuntu para estas vulnerabilidades identifica 8.3.6-0ubuntu0.24.04.13 como paquete corregido de PHP 8.3 para Ubuntu 24.04 LTS. Ese dato solo es aplicable a la distribución y al paquete indicados. No permite considerar seguro cualquier servidor que muestre «PHP 8.3.6». Ubuntu USN-8948-1.

Por eso, si el panel sigue mostrando el mismo número, solicita la revisión completa del paquete o compilación y la referencia del proveedor que confirma ambos parches. Una captura con «PHP 8.3» deja esa pregunta sin resolver.

Qué hacer con PHP 8.1 y versiones anteriores

Estas ramas han terminado su soporte ordinario en el proyecto PHP. Algunos proveedores y distribuciones ofrecen correcciones adaptadas; además, PHP ha publicado parches mínimos de código fuente para determinadas ramas antiguas ante la gravedad de este caso. Hay que comprobar qué cobertura recibe tu instalación concreta. Recomendaciones de CERT-EU.

La compatibilidad también importa. La matriz de PrestaShop 8, por ejemplo, no admite PHP 8.2 o superior para las versiones de PrestaShop que recoge. Cambiar la rama desde el panel sin revisar plataforma, módulos y personalizaciones puede causar una incidencia. Pide una solución corregida compatible y acuerda por separado cómo abandonar el entorno antiguo.

Checklist para coordinar la revisión con el hosting

Esta checklist organiza la respuesta entre negocio, alojamiento y mantenimiento. Es una propuesta de trabajo; no acredita por sí misma el estado de ninguna tienda.

• Identificar el alcance. Anotar tienda, subdominios, entornos de pruebas y otros servicios web que el proveedor confirme que ejecutan PHP.
• Asignar responsables. Confirmar quién aplica la actualización del servidor y quién valida la tienda después.
• Obtener la referencia técnica. Guardar versión, revisión del paquete o compilación y aviso que confirma la corrección de los dos CVE.
• Preparar la recuperación. Confirmar una copia reciente de archivos y base de datos, y quién puede restaurarla. Acordar cómo proteger los pedidos recibidos durante la intervención.
• Revisar compatibilidad. Si cambia la rama de PHP, comprobar antes los requisitos de la plataforma y de sus módulos. Utilizar una copia de pruebas cuando sea posible, coordinando con el proveedor la protección del servicio mientras tanto.
• Confirmar la aplicación efectiva. Solicitar fecha y hora del cambio y confirmación de que los procesos PHP que atienden la web utilizan el código corregido, con el reinicio o reemplazo de procesos que corresponda.
• Validar el recorrido de compra. Documentar las comprobaciones de catálogo, carrito, checkout, pago y recepción del pedido.
• Cerrar o escalar. Registrar lo que queda pendiente, su responsable y la próxima actualización del ticket.

La preparación de copias y las pruebas de funcionamiento siguen el enfoque de la guía oficial de actualización de WooCommerce, adaptado aquí a una intervención sobre el entorno de servidor.

Cómo comprobar que la tienda funciona después

Pide a quien mantiene el ecommerce que compruebe sus operaciones reales. Como punto de partida, proponemos este recorrido:

Coordina la prueba para evitar cobros o expediciones involuntarios. No cambies la pasarela de toda la tienda a modo de pruebas mientras los clientes compran. Guarda también la hora de la revisión y los errores detectados: una captura de la portada no cubre el checkout.

La guía de WooCommerce recomienda comprobar productos, carrito, pedido, pagos, envío, impuestos y correos tras una actualización. Las integraciones adicionales dependen de cada negocio y requieren su propia comprobación.

Mensaje para enviar al proveedor de hosting

Sustituye los campos entre corchetes y envíalo a través del canal de soporte habitual.

Asunto: Confirmación de parches PHP para [dominio] — CVE-2026-109618 y CVE-2026-109619

Hola,

Gestionamos la tienda [dominio], alojada en [servicio o identificador de cuenta]. Necesitamos confirmar su situación ante las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619, cuyos parches se publicaron el 21 de octubre de 2026.

¿Podéis revisar y confirmar lo siguiente?

1. Qué versión y revisión completa del paquete o compilación de PHP atiende las peticiones web de este dominio.
2. Si están aplicadas las correcciones de ambos CVE. Si utilizáis parches adaptados por el proveedor, indicad el aviso o referencia que lo acredita.
3. Cuándo se aplicaron y si los procesos que sirven la web ya ejecutan el código corregido, tras el reinicio o reemplazo que corresponda.
4. Si la revisión cubre también [subdominios o entornos adicionales; eliminar si no aplica].
5. Si queda alguna actuación pendiente, quién la realizará, cuándo estará resuelta y qué protección proponéis mientras tanto.

Si hace falta cambiar de rama de PHP, interrumpir el servicio o asumir algún coste adicional, enviadnos el alcance, la compatibilidad prevista, la copia de seguridad disponible y el plan de recuperación antes de efectuar esos cambios. Coordinaremos con mantenimiento la comprobación del recorrido de compra.

Aviso oficial de referencia: https://www.php.net/archive/2026.php#2026-10-21-5

Gracias,

[Nombre] [Empresa]

Una respuesta que confirme versión o paquete, cobertura de ambos fallos y aplicación efectiva permite documentar el cambio. Si solo responde «tenéis la última versión», pide esos detalles antes de cerrar el ticket.

Qué hacer si el proveedor no puede aplicar el parche

Escala el ticket al equipo que administra el servidor. PHP indica que las mitigaciones parciales no sustituyen la actualización. CERT-EU recomienda considerar el aislamiento de las aplicaciones expuestas a Internet cuando no sea posible corregirlas, hasta aplicar y verificar la solución. Aviso de PHP y recomendación de CERT-EU.

Acuerda con el proveedor qué restricción resulta efectiva y cómo afecta a las ventas. No des por hecho que una página de mantenimiento o una regla del cortafuegos impide todas las vías de ataque.

Si aparecen indicios de acceso no autorizado, solicita además una revisión de incidente. Aplicar el parche corrige estas vulnerabilidades, pero no demuestra que se hayan eliminado cambios maliciosos previos. Tampoco atribuyas automáticamente cualquier error de la tienda a estos fallos.

¿Esta incidencia obliga a migrar de plataforma?

Una vulnerabilidad que puede corregirse no justifica, por sí sola, cambiar de plataforma. Primero hay que resolver la exposición y comprobar el servicio.

Después, si el proveedor no mantiene el entorno o las incompatibilidades impiden actualizarlo, conviene revisar las opciones de mantenimiento y evolución con datos: soporte disponible, dependencias, coste y continuidad del negocio. Si estás valorando ese cambio, la guía de migración de PrestaShop a Shopify explica qué preparar en catálogo, datos y SEO. La decisión debe responder al análisis de tu tienda.

Si necesitas valorar cómo coordinar esa revisión, cuéntanos el caso de tu ecommerce. Indica la plataforma, el dominio y la respuesta del hosting para que podamos valorar el alcance y quién debe intervenir. No incluyas contraseñas ni datos de clientes en la consulta inicial.