Alerta de seguridad PHP: qué significa para tu web y qué hacer

Si tu web funciona con PHP (WordPress, PrestaShop, Matomo, Mautic y la mayoría de desarrollos a medida), desde el 21 de octubre está expuesta a un fallo crítico que permite tomar el control del servidor sin contraseña. La solución es tener PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12 o superior; todo lo demás es ganar tiempo. Si tienes mantenimiento contratado con nosotros, ya estamos en ello. Si no, aquí tienes qué hacer en tres pasos y qué preguntar a tu hosting.

Qué ha pasado y a quién afecta

El 21 de octubre de 2026 PHP, el lenguaje con el que funcionan la mayoría de las webs de empresa, publicó un parche de urgencia para dos fallos críticos: CVE-2026-109618 y CVE-2026-109619, bautizados como “PHP2Shell”. INCIBE los ha calificado con la máxima gravedad (5 – Crítica) y CERT-EU pide parchear de inmediato. Permiten a un atacante ejecutar lo que quiera en tu servidor sin usuario ni contraseña, con una sola petición, antes incluso de que arranque tu web.

La analogía que lo explica. Antes, explotar un fallo así exigía un especialista. Hoy, con la IA, cualquiera es un hacker en potencia: un chaval con un portátil puede pedir a una IA que le prepare el ataque y lanzarlo contra miles de webs a la vez. Una web sin parchear es una casa con la puerta abierta y la dirección publicada en internet. Y ya hay gente probando puertas: CERT-EU confirma que circulan pruebas de concepto y da por probable que ya se esté explotando.

Si tu web funciona con PHP, está afectada. El fallo está en el propio PHP, por debajo del CMS: da igual lo actualizados que tengas WordPress, sus plugins o los módulos de PrestaShop. Afecta a cualquier instalación de PHP que sirva páginas, en cualquier tipo de hosting.

• Webs corporativas y blogs: WordPress, Drupal, Joomla, TYPO3.
• Tiendas online: WooCommerce, PrestaShop, Magento / Adobe Commerce, OpenCart.
• Marketing y analítica: Matomo, Mautic.
• Intranets y herramientas internas: Moodle, Nextcloud, phpMyAdmin, SuiteCRM, GLPI, Dolibarr.
• Desarrollos a medida en Laravel, Symfony o CodeIgniter, y productos comerciales que llevan PHP dentro (ver la lista de software afectado que mantiene el NCSC-NL).

Versiones que corrigen el fallo. Solo existe parche oficial para las ramas con soporte. Si tu web usa PHP 8.1 o anterior, no hay versión corregida: depende de que tu hosting haya aplicado un parche retroportado, y la única solución completa es actualizar.

Fuente de las versiones: CERT-EU, aviso 2026-018.

Qué puede pasar si no se actúa

Con control total del servidor, el atacante puede leer, modificar o borrar lo que quiera, sin tu contraseña y sin que recibas ningún aviso. Estas son las consecuencias más habituales en una pyme, de más a menos frecuente.

¿Afecta al correo electrónico? Sí, en tres situaciones.

1. Correo alojado en el mismo hosting que la web (lo habitual en hosting compartido): el atacante puede leer buzones y enviar spam desde tu dominio. La IP del servidor entra en listas negras y tus correos legítimos dejan de llegar.
2. Correo en Google Workspace o Microsoft 365: la web guarda un usuario y una contraseña de correo para enviar notificaciones (plugins SMTP de WordPress, Mautic, PrestaShop). Con esas credenciales, el atacante envía phishing desde tu cuenta real.
3. En cualquier caso: si tu dominio acaba en listas negras por alojar phishing, los correos que enlazan a tu web se marcan como spam.

A quién hay que avisar si se confirma un ataque.

• AEPD: obligatorio si hay datos personales afectados, en un máximo de 72 h desde que se detecta (art. 33 RGPD), y a las personas afectadas si el riesgo es alto (art. 34). No tener medidas de seguridad adecuadas (art. 32) es sancionable por sí mismo.
• INCIBE-CERT: cualquier empresa puede reportar el incidente y pedir ayuda gratuita; también en el teléfono 017. Es obligatorio para operadores de servicios esenciales y proveedores de servicios digitales regulados.
• Tu banco o pasarela de pago, si la tienda procesa tarjetas.
• Tu seguro, si tienes póliza de ciberriesgo: muchas exigen aviso inmediato y tener los sistemas parcheados.

Paso 1 – Averigua en qué situación está cada web

Si tienes mantenimiento contratado con nosotros, este paso ya está hecho: estamos revisando y parcheando todos los proyectos afectados.

Si no, necesitas tres datos por cada web: qué versión de PHP usa, quién la gestiona y si el hosting ya ha aplicado el parche.

1. Haz inventario de todo lo que funcione con PHP, no solo de la web principal. Landings de campañas, microsites, blogs antiguos, la tienda B2B, la intranet, Matomo, Mautic, copias de pruebas y webs de marcas o eventos que ya nadie usa. Las webs olvidadas son el punto de entrada más habitual: siguen online, nadie las actualiza y comparten servidor con las demás.

2. Mira la versión de PHP. No hace falta ser técnico; está a dos clics en cualquiera de estos sitios.

3. Interpreta el resultado.

4. Pregunta al hosting por escrito y guarda la respuesta. Los proveedores gestionados suelen aplicar estos parches solos, pero no lo des por hecho. Si algún día tienes que justificar diligencia ante la AEPD o tu aseguradora, esa respuesta es tu prueba. Las preguntas exactas están en la checklist del final.

Paso 2 – Actualiza a PHP 8.2 o superior

La única solución completa es ejecutar una versión parcheada, y solo las ramas 8.2 a 8.5 la tienen. PHP 8.2 deja de recibir parches de seguridad el 31/12/2026, así que si vas a hacer el esfuerzo, apunta a 8.3 u 8.4 (WordPress recomienda 8.3 o superior).

Antes de tocar nada, comprueba que tu plataforma lo admite. Esta tabla explica por qué muchas tiendas no pueden “simplemente cambiar la versión”.

Si tu plataforma no admite PHP 8.2 o superior, la actualización pasa por migrar la propia plataforma (PrestaShop 1.7 u 8 → 9, Mautic 4 → 5 o superior). Eso es un proyecto de días o semanas, no de una tarde, así que mientras tanto aplica el paso 3.

Plan de actualización y verificación.

Es el que seguimos nosotros; en hosting compartido el cambio de versión es reversible en segundos, así que el riesgo real está en no probar.

1. Copia de seguridad completa (archivos y base de datos) guardada fuera del servidor, y comprobación de que se puede restaurar.
2. Actualiza antes el CMS, el tema y los plugins o módulos a su última versión: muchos errores con PHP nuevo vienen de extensiones sin mantener. En WordPress, revisa el campo “Requiere PHP” de cada plugin.
3. Si tu hosting ofrece una copia de pruebas (staging), haz el cambio ahí primero. Si no, hazlo en una franja de poco tráfico.
4. Cambia la versión de PHP en el panel del hosting o pídeselo al proveedor.
5. Pasa esta lista de pruebas; cualquier fallo se ve en el registro de errores y suele ser de un plugin o módulo concreto.

• Portada y páginas principales cargan sin errores, también en móvil
• Formularios de contacto, presupuesto y newsletter: se envían y llega el correo
• Acceso al panel de administración y edición de una página o producto
• Buscador, filtros y fichas de producto
• Carrito, checkout y cada pasarela de pago (Redsys, PayPal, Stripe, Bizum) con un pedido de prueba
• Correos automáticos: confirmación de pedido, recuperación de contraseña
• Facturas en PDF, cálculo de envío e impuestos
• Integraciones: ERP o CRM, feeds de Google Shopping, formularios de Mautic
• Analítica (GA4, Matomo) y banner de cookies siguen funcionando
• Tareas programadas: campañas de Mautic, archivado de Matomo, copias de seguridad
• Subida de imágenes y documentos desde el administrador
• Idiomas y multitienda, si los hay

6. Vigila el registro de errores durante 48 horas y ten a mano la vuelta atrás.
7. Pide al hosting la versión exacta instalada (8.x.y) y guarda la confirmación.

Si algo falla y no se puede arreglar en el momento, vuelve a la versión anterior y pasa al paso 3: una web rota no es una web segura, pero una web vulnerable tampoco.

Paso 3 – Si no puedes actualizar: plan de mitigación

Ninguna de estas medidas cierra el fallo; CERT-EU y el propio equipo de PHP lo dicen con claridad. Sirven para ganar tiempo y reducir el daño mientras preparas la actualización o la migración. Van de más a menos efectiva.

1. Pide al hosting el parche retroportado. El equipo de PHP ha publicado parches mínimos para 7.4, 8.0 y 8.1, y las distribuciones Linux y los paneles de hosting los están incorporando. Si tu proveedor lo ha aplicado, la web antigua queda protegida sin cambiar de versión. Pídelo por escrito y guarda la respuesta.

2. Aplica las mitigaciones oficiales. Las hace quien administra el servidor; pásale esta lista tal cual. Son las que recomiendan PHP y CERT-EU y solo cubren las vías de ataque conocidas:

• memory_limit=-1 fijado a nivel de servidor (sin que la aplicación pueda cambiarlo), con un límite de memoria por contenedor o cgroup como red de seguridad.
• post_max_size bajo: 8M si la web no sube archivos, 32M si los sube, con upload_max_filesize por debajo.
• Límites de tamaño de petición, número de campos y partes en el servidor web o proxy.
• session.upload_progress.enabled=0 en php.ini o en la configuración del servidor, y reinicio de todos los procesos PHP.
• En PHP 8.5, además fatal_error_backtraces=0.
• Corregir los errores fatales y tiempos de espera que un visitante pueda provocar.

3. Retira de internet lo que no sea imprescindible. CERT-EU recomienda aislar de la red pública las aplicaciones que no se puedan parchear. Ojo: un plugin de “modo mantenimiento” en WordPress o PrestaShop sigue ejecutando PHP en cada visita, así que sigue siendo vulnerable. Lo seguro es una página estática servida por el servidor web o el CDN con PHP desactivado para ese dominio, o cortar el tráfico en el firewall. Matomo, Mautic y las intranets solo las usa tu equipo: ponlas detrás de la VPN o limita el acceso a la IP de la oficina.

4. Si la web tiene que seguir online, ponla detrás de un CDN con WAF. Cloudflare y otros proveedores han publicado reglas para los patrones de ataque conocidos. Dos condiciones para que sirva: el servidor de origen no debe ser accesible directamente por su IP (si no, el atacante se salta el WAF), y hay que asumir que las reglas paran lo conocido, no las variantes que vayan apareciendo.

5. Restringe el acceso al administrador por IP y activa el doble factor. /wp-admin, la carpeta de administración de PrestaShop, Matomo y Mautic solo deberían abrirse desde las IP de la empresa o de la agencia. No bloquea este fallo concreto, que se dispara antes de llegar a la aplicación, pero limita lo que se puede hacer con una contraseña robada y frena los ataques de fuerza bruta.

6. Aísla accesos y permisos por proyecto. Si varias webs comparten hosting con el mismo usuario FTP, el mismo usuario de base de datos o la misma contraseña, una landing olvidada es la puerta de entrada a la tienda principal. Lo que hay que separar:

• Una cuenta de hosting o contenedor por proyecto, no todas las webs bajo la misma cuenta.
• Un usuario de base de datos por proyecto, con permisos solo sobre su base de datos.
• Un usuario SFTP o SSH por proyecto y por persona; nada de claves genéricas compartidas por correo.
• Baja de los accesos de antiguos empleados y proveedores; un gestor de contraseñas para el resto.
• En el CMS, cada persona con el rol mínimo: quien edita contenidos no necesita ser administrador.

7. Cambia credenciales y busca señales de intrusión. Una vez parcheado, o ante cualquier duda, cambia contraseñas de administrador, base de datos, SFTP, correo SMTP, claves de API y de pasarela de pago: todas están guardadas en el servidor. Revisa usuarios administrador nuevos, archivos modificados en los últimos días, tareas programadas desconocidas y peticiones extrañas en los registros desde el 20 de octubre, y pasa el antivirus del hosting. Si encuentras algo, no lo borres: aísla la web, conserva los registros y pide ayuda (tu proveedor, o INCIBE en el 017).

8. Pon fecha a la migración. La mitigación compra semanas, no años. PrestaShop 1.7 y 8 pasan a 9, Mautic 4 a 6 o 7, y los desarrollos antiguos se modernizan o se retiran. Y apaga lo que nadie usa: la web más segura es la que ya no existe.

Checklist para el gerente: qué preguntar y qué guardar

No necesitas entender la respuesta técnica; necesitas que te contesten por escrito y a cada punto. Reenvía estos bloques tal cual a tu hosting y a quien mantenga tu web.

Para el proveedor de hosting

• ¿Qué versión exacta de PHP (x.y.z) ejecuta cada uno de mis dominios?
• ¿Habéis aplicado el parche de CVE-2026-109618 y CVE-2026-109619 (PHP2Shell) en mi servidor? ¿En qué fecha?
• Si alguna web usa PHP 8.1 o anterior, ¿tiene el parche retroportado o tengo que cambiar de versión?
• ¿Se han reiniciado los procesos de PHP y del servidor web tras el parche?
• ¿Tenéis WAF con reglas para este ataque y están activas en mi cuenta?
• ¿Habéis detectado actividad sospechosa en mi cuenta desde el 20 de octubre?
• ¿Mi correo está en el mismo servidor que la web?
• ¿Cuál es la última copia de seguridad válida y cómo se restaura?

Para quien mantiene la web (agencia, freelance o equipo interno)

• ¿Qué proyectos nuestros funcionan con PHP y en qué estado está cada uno?
• ¿Cuáles están ya parcheados, cuáles se pueden actualizar y cuáles necesitan migración?
• En los que no se pueden actualizar, ¿qué mitigaciones se han aplicado y hasta qué fecha?
• ¿Qué accesos comparten varios proyectos y cuándo se van a separar?
• ¿Se han cambiado las credenciales (administrador, base de datos, SMTP, pasarelas) después de parchear?
• ¿Cómo sabremos si nos han atacado? ¿Qué monitorización y escaneos hay?

Qué guardar. Las respuestas con su fecha, la confirmación de la versión instalada y el inventario de proyectos. Es tu expediente de diligencia: lo que enseñarás a la AEPD, a la aseguradora o a un cliente si algún día preguntan qué hiciste esta semana.

Qué estamos haciendo y cómo te ayudamos

Si tienes mantenimiento contratado con nosotros, no tienes que hacer nada. Desde que se publicó el aviso estamos revisando todos los proyectos afectados: inventario, versión de PHP, confirmación con el hosting, actualización donde es posible y mitigación donde no. Recibirás un resumen con el estado de cada proyecto y, si alguno necesita una migración, una propuesta con plazos.

Si tienes otros proyectos fuera del mantenimiento, dínoslo. Landings de campañas, microsites, una tienda antigua, un Matomo o un Mautic en otro servidor: cualquier cosa que funcione con PHP y que nadie esté mirando. Los revisamos y te decimos en qué situación están y qué haría falta para dejarlos seguros.

Para revisar un proyecto solo necesitamos tres cosas:

1. La dirección web.
2. Quién es el proveedor de hosting.
3. Quién tiene los accesos (panel de hosting y administrador de la web).

Escríbenos a [correo de contacto] o llámanos al [teléfono]. Si crees que ya te han atacado, no esperes al correo: llama.

Enlaces de interés

Avisos oficiales sobre la vulnerabilidad

• INCIBE-CERT: Múltiples vulnerabilidades en PHP (aviso del 21/10/2026, importancia 5 – Crítica)
• PHP: aviso de seguridad y versiones corregidas
• CERT-EU: Security Advisory 2026-018 (en inglés; incluye las mitigaciones oficiales)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC-NL: lista de productos y software que llevan PHP dentro

Si sospechas que te han atacado

• INCIBE: reporta tu incidente (empresas) y notificación de incidentes a INCIBE-CERT. Teléfono gratuito de ayuda: 017.
• AEPD: notificación de brechas de datos personales (72 horas; incluye la herramienta Asesora Brecha para saber si tienes que notificar)

Para prevenir de cara al futuro

• INCIBE: Protege tu web
• INCIBE: RGPD para pymes

Requisitos de PHP de cada plataforma

• PrestaShop 9, PrestaShop 8 y PrestaShop 1.7
• Mautic
• Matomo 6
• WordPress: versiones de PHP y cómo comprobarlas
• Guía práctica para propietarios de WordPress sobre esta alerta (en inglés)