Fallos críticos de PHP: web, NAS y programas que revisar

Vulnerabilidad crítica de PHP: dónde la tiene un negocio pequeño

Una tienda online de cerámica de Talavera vende con WooCommerce, guarda las facturas en un NAS de QNAP y gestiona las reservas de sus talleres con un pequeño programa que le hizo un informático hace años. Las tres cosas funcionan con PHP. La dueña no actualiza ninguna de ellas por sí misma, y las tres pueden estar afectadas.

PHP es un lenguaje que se ejecuta en el servidor cada vez que alguien abre una página. Por eso un fallo en PHP no depende de que tu web tenga un plugin descuidado: está debajo de todo lo demás.

Qué ha pasado

El 21 de octubre de 2026, el equipo de PHP publicó un aviso con un título que no deja dudas: actualizar ya. Los dos fallos pueden permitir que alguien sin cuenta ejecute código en el servidor. PHP considera en riesgo todas las instalaciones que atienden peticiones web, y el riesgo más alto lo sitúa en Apache con mod_php, donde demostró un ataque que funciona antes de que se ejecute el código de la propia aplicación.

INCIBE-CERT califica el aviso como crítico (puntuación CVSS 9,2 en ambos fallos) y recoge que se comunicaron ataques contra servidores PHP antes de que existieran los parches. El 26 de octubre, la CISA los incorporó a su catálogo de vulnerabilidades explotadas y dio a las agencias federales de Estados Unidos hasta el 29 de octubre para corregirlos.

1. La web de tu negocio

Si tu web está en un hosting, no eres tú quien instala PHP: lo hace el proveedor. Tú sí puedes comprobar qué rama usa tu web y, en muchos paneles de hosting, elegirla.

• En WordPress, la versión aparece en Herramientas > Salud del sitio > Información, en el apartado del servidor. WordPress recomienda PHP 8.3 o superior y advierte de que las versiones antiguas que todavía funcionan, desde la 7.4, ya están fuera de soporte y pueden exponer la web.
• Si tu web usa PHP 8.1 o anterior, el proyecto ya no la corrige. Pregunta a tu proveedor si aplica algún parche propio y planifica el cambio a una rama con soporte, probando antes que la plantilla y los plugins funcionan con ella.

Este es un mensaje que puedes copiar y enviar al soporte de tu hosting:

Hola: tengo alojada la web [dominio]. ¿Está ya actualizado el PHP de mi web para corregir las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, publicadas el 21 de octubre? ¿Qué versión exacta de PHP usa ahora? Si está en PHP 8.1 o anterior, ¿qué opción hay para pasar a una rama con soporte? Gracias.

2. El NAS de la oficina o de casa

Synology ha publicado versiones corregidas de los paquetes de PHP que se instalan desde el Centro de paquetes, y de Mail Station y Synology Calendar. Según INCIBE-CERT, son estas o posteriores:

PHP 7.3 también está afectado y no tendrá corrección: hay que sustituirlo por una rama con soporte. Synology considera muy bajo el riesgo del PHP integrado en el propio sistema operativo, porque no queda expuesto desde fuera.

QNAP ha corregido sus sistemas con compilaciones del 23 de octubre: QTS 6.1.0.3656 y 5.2.11.3661, QuTS hero h6.1.0.3656, h6.0.2.3656 y h5.2.11.3661, y QuTScloud c5.2.9.3661. Siguen pendientes Note Station 3, QNE (ADRA), QVR Surveillance en modelos ARM32 y TVR OS, y QuMagie no tiene todavía versión corregida indicada. QNAP aclara que sus actualizaciones no cubren el PHP de los contenedores de Container Station ni el de aplicaciones de terceros. Mientras tanto, recomienda:

• Retirar la exposición directa a internet y desactivar las redirecciones de puertos y el UPnP del router.
• Entrar al NAS desde fuera por VPN y limitar la administración a redes de confianza.
• Detener las aplicaciones afectadas y los servicios que no uses.
• Revisar QuLog Center y pasar Security Center y Malware Remover actualizados.

Son las mismas medidas que repetimos con el ataque a Plex de la semana pasada: un NAS no debería responder directamente a internet. En nuestra guía sobre el acceso remoto al NAS comparamos las alternativas.

3. Los programas que alguien instaló para ti

Una intranet, un programa de reservas, una tienda en tu propio servidor o una integración entre tu CRM y la web: todo lo que funciona con PHP en una máquina tuya depende de quien la mantiene. El caso de Sage CRM lo ilustra bien: según INCIBE-CERT, su arquitectura estándar no usa PHP, pero sí pueden estar afectadas las integraciones de terceros conectadas a él que lo usen, y una integración comprometida podría exponer credenciales y datos del CRM. Para esos casos no hace falta un parche de Sage, sino actualizar el PHP de la integración y revisar permisos y credenciales.

Si un sistema expuesto a internet no se puede actualizar, INCIBE-CERT es tajante: hay que aislarlo de las redes públicas hasta aplicar una versión corregida.

Si administras el servidor

Actualizar es la única solución completa. PHP indica que las distribuciones de Linux recibieron los parches por adelantado, así que basta con instalar los paquetes de tu distribución. Si no puedes hacerlo de inmediato, el aviso de PHP enumera medidas temporales que reducen algunas vías de ataque sin eliminarlas: fijar memory_limit=-1 de forma administrativa, mantener post_max_size bajo (8 MB sin subida de archivos, 32 MB con ella), desactivar session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces, reiniciando todos los procesos. El 23 de octubre, PHP añadió un posible tercer fallo (CVE-2026-115560), solo explotable con una configuración poco habitual, y recomendó mantener session.upload_progress.enabled=0 hasta la próxima versión.

Lista para esta semana

1. Comprueba qué versión de PHP usa tu web.
2. Envía el mensaje a tu hosting y guarda la respuesta.
3. Si la web está en PHP 8.1 o anterior, pide una fecha para pasar a 8.3 o superior.
4. Actualiza los paquetes de PHP del NAS Synology o el sistema del NAS QNAP.
5. Cierra en el router cualquier puerto abierto hacia el NAS.
6. Pregunta a quien mantiene tus programas propios si usan PHP y si ya están actualizados.