PHP2Shell en Synology: Cómo parcheamos seis sitios en un solo día.

PHP2Shell es el nombre que la industria eligió para CVE-2026-109618 y CVE-2026-109619, un par de fallos críticos en el propio motor PHP que permiten la ejecución remota de código sin autenticación. Los detalles se filtraron el 20 de octubre de 2026, un día antes de la divulgación coordinada, y el proyecto PHP lanzó versiones de emergencia el 21 de octubre. Dado que el error reside en el intérprete y no en ninguna aplicación, parchear WordPress, Joomla o MediaWiki no tiene ningún efecto. La única solución real es una nueva compilación de PHP. Ejecutamos seis sitios públicos de WordPress en hardware Synology, y PHP2Shell hizo que cada uno de ellos tuviera que reconstruirse en la misma semana. Esta guía cubre en qué consiste el error, cómo parchearlo en DSM a través del Centro de paquetes, cómo manejarlo cuando su sitio se ejecuta en un contenedor y la incómoda comparación entre lo que lanzó Synology y lo que otros proveedores de NAS han logrado hasta ahora.

Punto SynoPower Club:Nuestros seis sitios se actualizaron en un día hábil tras la publicación del aviso de PHP2Shell, y esto no se debió a ninguna hazaña, sino a que Synology publicó paquetes corregidos el mismo día. El Synology-SA-26:14 se publicó el 22 de octubre con el estado "Resuelto" y una tabla completa de versiones corregidas hasta PHP 7.4. Ese mismo día, QNAP publicó QSA-26-18 con el estado "Corrigiendo" y la leyenda "Por anunciar" en cada celda de versión corregida, y ASUSTOR respondió eliminando el PHP antiguo de App Central en lugar de actualizarlo. Si usted aloja un sitio web público en un NAS, esta diferencia no es un detalle de marketing. Es la diferencia entre actualizar un paquete y dejar su sitio fuera de internet mientras espera.

¿Qué es PHP2Shell y por qué es diferente?

PHP2Shell no es un solo error, sino un conjunto de fallos relacionados con la seguridad de la memoria en la forma en que PHP limpia después de una solicitud que se quedó sin memoria. PHP utiliza salto largo() Para evitar errores fatales, incluidos los de falta de memoria, este salto omite el código de limpieza que normalmente devolvería el motor a un estado conocido. Parte de ese estado es global y se conserva en la siguiente solicitud gestionada por el mismo proceso de trabajo.

CVE-2026-109618 se refiere al problema de falta de memoria. Una solicitud HTTP manipulada agota el límite de memoria mientras los datos de la solicitud solo se han inicializado parcialmente, por lo que la rutina de limpieza accede a estructuras que nunca se terminaron de completar. CVE-2026-109619 se refiere al problema de uso de memoria liberada: una solicitud posterior en el mismo proceso puede leer el estado global que apunta a la memoria liberada de la solicitud, lo que provoca que el error se convierta en ejecución de código o divulgación de memoria.

Dos características hacen que PHP2Shell sea peor que las advertencias habituales de PHP. Primero, es una vulnerabilidad previa a la autenticación. Ambas fallas se activan antes de que se ejecute cualquier autenticación a nivel de aplicación, por lo que un muro de inicio de sesión, un complemento de membresía o una contraseña de administrador no protegen nada. Segundo, la variante de divulgación de memoria filtra la memoria del proceso de trabajo, y un proceso de trabajo de PHP en un sitio de WordPress almacena credenciales de base de datos, tokens de API y claves de pago. Una lectura exitosa no necesita llegar a la ejecución del código para arruinarte la semana.

Las dos vulnerabilidades CVE de PHP2Shell obtuvieron una puntuación de 9.2 en CVSS v4.0 por parte del equipo de seguridad de PHP. Synology les otorgó una puntuación de 9.8 en CVSS v3.1 en su propio informe. Diferentes escalas, misma conclusión. Los informes de explotación son contradictorios: watchTowr afirma haber detectado intentos contra su red honeypot, mientras que Bitdefender no reportó nada en su telemetría al momento de redactar este informe, y QNAP declara no haber recibido informes de explotación dirigidos específicamente a sus productos.

PHP2Shell frente a un exploit normal de WordPress

La mayoría de los problemas que afectan a un sitio WordPress público se deben a vulnerabilidades en los plugins. El patrón es conocido: un plugin incluye un endpoint REST defectuoso, un escáner lo detecta, se actualiza el plugin y la vulnerabilidad se soluciona. PHP2Shell rompe con este patrón por completo, y auditar los plugins de forma automática resulta un esfuerzo inútil en este caso.

Aspecto	CVE de complemento típico	PHP2Shell
Donde vive el insecto	Código de la aplicación (plugin o tema)	El intérprete de PHP en sí mismo
¿Quién puede desencadenarlo?	A menudo se necesita un rol de suscriptor o administrador.	Nadie. Preautenticación, antes de que se ejecute la lógica de la aplicación.
¿Actualizar WordPress ayuda?	Normalmente sí	No. Las actualizaciones del núcleo y de los complementos son irrelevantes.
¿Lo impide una WAF?	Por lo general, una vez que existe una regla	En parte. Las reglas de forma de solicitud no contemplan la ruta de OOM.
¿Qué es lo que realmente lo soluciona?	Actualización del plugin	Una nueva compilación de PHP, nada más.
Radio de explosión	Un sitio, una función	Todos los sitios PHP en el servidor, todos a la vez.

Esa última fila explica por qué PHP2Shell se convirtió en una jornada laboral completa en lugar de una tarde. Un único paquete PHP compartido en un NAS puede estar detrás de una docena de hosts virtuales de Web Station, y una sola imagen de contenedor puede servir de base para varios sitios. La aplicación de parches no es por sitio, sino por entorno de ejecución, y es necesario enumerar los entornos de ejecución antes de poder afirmar que se ha realizado algún trabajo.

Cómo saber si tu NAS está expuesto

Para determinar la vulnerabilidad de PHP2Shell, primero hay que diferenciar dos preguntas clave: ¿El sistema contiene una compilación PHP vulnerable y es accesible desde internet? Synology hace esta distinción explícitamente: DSM incluye un componente PHP interno utilizado por el sistema operativo, y Synology afirma que no tiene módulos accesibles externamente y, por lo tanto, no presenta ninguna superficie de ataque expuesta. El riesgo que asigna a este componente es mínimo, y el parche está programado para una versión posterior de DSM, de modo que los análisis de vulnerabilidades dejen de detectarlo.

Los paquetes relevantes para PHP2Shell son aquellos que proporcionan PHP a la web. Synology enumera Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station y WordPress. Si tiene alguno de estos instalado y accesible, entra dentro del alcance de Synology.

Comprueba las versiones directamente en lugar de confiar en un panel de control. En el Centro de paquetes, los paquetes PHP instalados muestran su versión en el mosaico, y el aviso de actualización indica la compilación de destino. Desde la consola, consulta directamente al entorno de ejecución:

# Synology Paquete PHP (ajuste la ruta a la versión que ejecuta) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Un sitio en contenedor docker exec php -v

La razón para insistir en php -v Al auditar PHP2Shell, se observa que casi todas las demás señales son engañosas. La salida de la compilación puede reportar éxito mientras se reutiliza una capa en caché, un panel de control puede mostrar un paquete como actualizado cuando el proceso en ejecución no lo está, y una CDN puede eliminar el encabezado de respuesta HTTP antes de que usted lo vea. Dos de nuestros seis sitios web fueron reportados como saludables por sus pantallas de administración a pesar de seguir ejecutando un intérprete sin parchear.

Cómo aplicar un parche a PHP2Shell en Synology en 4 pasos

Para un sitio Web Station en DSM, la solución completa para PHP2Shell consiste en una actualización del Centro de Paquetes. Synology publica actualizaciones de seguridad de PHP para DSM 7.4, 7.3 y 7.2, y tras la actualización del paquete PHP, los paquetes dependientes se reinician automáticamente, lo que resuelve el problema. Mail Station es la excepción documentada y requiere una actualización manual.

La captura de pantalla anterior corresponde a una de nuestras máquinas, tomada la mañana después del aviso de PHP2Shell. Observe que el panel "Novedades" indica directamente la versión original, lo que permite comparar el sufijo de compilación Synology con la versión de PHP sin tener que adivinar. Synology Calendar aparece en la misma lista de actualizaciones con la versión 3.0.4-21435, que es precisamente la versión recomendada en el aviso.

Un detalle importante a tener en cuenta para los usuarios de Web Station en PHP2Shell: una máquina DSM puede tener varias ramas de PHP instaladas simultáneamente, y cada host virtual está vinculado a un perfil. Actualizar el perfil predeterminado no soluciona el problema de un sitio web vinculado a una rama diferente. Primero, enumere los perfiles, actualícelos todos y, a continuación, compruebe la vinculación de cada sitio web en Web Service.

¿Qué paquetes de DSM se ven afectados?

La declaración Synology en PHP2Shell es más específica de lo que sugería el error. Solo se ven afectados los sistemas que ejecutan ciertos paquetes dependientes de PHP, y Synology Drive no es uno de ellos. IDrive está en la lista, pero es un software de terceros.

• De cara a la web y de máxima prioridad. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer y phpMyAdmin. Estos proporcionan PHP a cualquiera que pueda acceder a ellos.
• Correo y calendario. Mail Station necesita una actualización manual después del paquete PHP. Synology Calendar tiene su propia versión corregida en 3.0.4-21435.
• El componente interno de DSM. Presente pero no accesible externamente, el parche se pospuso para una versión posterior de DSM, el riesgo fue calificado como mínimo por Synology.
• Los contenedores no están cubiertos. El entorno de ejecución de PHP dentro de Container Manager es responsabilidad del usuario modificarlo. Ninguna actualización de paquete lo afectará, lo cual es la razón más común por la que un propietario de NAS cree que ya ha terminado cuando no es así.

Si aún utiliza una versión de DSM anterior a la 7.2, Synology recomienda deshabilitar temporalmente los paquetes afectados hasta que esté disponible una versión parcheada. En la declaración se indica que DSM 7.2 ha llegado al final de su ciclo de vida, a pesar de haber recibido estas actualizaciones de PHP.

El caso más difícil para PHP2Shell es PHP 7.3 y versiones anteriores. Synology no solucionará el problema de la versión 7.3 porque la rama ha llegado al final de su ciclo de vida, y el proyecto original no publicó nada para la versión 7.3 ni anteriores. Algunas distribuciones de Linux lanzaron versiones anteriores para ciertas ramas antiguas, pero un paquete PHP de Synology no es un paquete de distribución. Si un sitio web necesita la versión 7.3 o 5.6 para funcionar, no habrá parche y las opciones más viables son migrar el sitio a una rama compatible, protegerlo con un WAF o retirarlo de internet.

Cómo los propietarios de sitios de contenedores manejan PHP2Shell

Cinco de nuestros seis sitios web utilizan WordPress en Docker en lugar de Web Station, y ahí es donde PHP2Shell se vuelve interesante, ya que Package Center no ofrece ninguna solución. El entorno de ejecución depende del contenido de la imagen, y reconstruir una imagen no es lo mismo que actualizarla.

El fallo de PHP2Shell con el que nos topamos primero, y el que tiene más probabilidades de afectar a otras personas, es que una reconstrucción de una imagen personalizada reutiliza la capa base almacenada en caché. Una imagen no fijada DE La etiqueta no significa que sea nueva. Una de nuestras imágenes se había reconstruido cuatro días antes y aún contenía una compilación de PHP de julio de 2025, con más de un año de retraso en las correcciones de seguridad, porque nada había obligado a Docker a descargar de nuevo la base.

# Incorrecto: reutiliza silenciosamente cualquier capa base que esté en caché localmente docker build -t mysite . # Correcto: siempre vuelve a descargar la imagen base docker build --pull -t mysite . # Luego inicia solo el servicio que deseas, sin iniciar los hermanos inactivos docker compose up -d --no-deps wordpress # Y verifica lo que realmente importa docker exec wordpress php -v

El segundo fallo de PHP2Shell es más grave porque informa de éxito. Redirigir la salida de la compilación a través de cola oculta un fallo de compilación, ya que el código de salida de una canalización pertenece al último comando de la misma y establecer -e nunca se activa. El paso de composición luego recrea el contenedor a partir de la imagen antigua, imprime Started y te vas con un sitio sin parchear que parece recién implementado. Comprueba el resultado de la compilación por separado y verifícalo con php -v después.

Dos notas importantes. Etiquete la imagen antigua antes de reconstruirla, ya que conserva su etiqueta y ofrece un punto de reversión gratuito mucho más económico que una instantánea. Además, no espere que una actualización de imagen mejore la aplicación: el punto de entrada oficial de imágenes de WordPress copia los archivos principales solo cuando la raíz del documento está vacía, por lo que recrear un contenedor en una imagen más reciente deja la instalación existente exactamente donde estaba. Lo confirmamos en una copia de prueba antes de pasar a producción, y la versión de WordPress no cambió.

Por qué deshabilitar session.upload_progress solo soluciona la mitad del problema.

La solución de mitigación de PHP2Shell que circula para las máquinas que no se pueden parchear consiste en establecer session.upload_progress.enabled = 0, y en DSM, que se encuentra en Web Station, en Configuración del lenguaje de script, en la pestaña Núcleo del perfil PHP. Vale la pena hacerlo. No es una solución definitiva, y la diferencia es importante.

La ruta de progreso de carga de sesión es solo una de las vías de acceso. La variante de divulgación de memoria se alcanza mediante el manejo habitual de solicitudes multipart y no requiere la función de sesión en absoluto, por lo que desactivarla deja esa ruta abierta. El proyecto PHP ha declarado directamente que no existen mitigaciones completas y que la actualización es la única solución segura. Imunify360 informa que actualmente ninguna regla bloquea la ruta de falta de memoria de CVE-2026-109618, y Elastic señala que la configuración de progreso de carga cierra las rutas de sesión confirmadas, pero no todas las variantes.

También verás límite_memoria = -1 Se sugirió, basándose en la lógica de que el error se produce por falta de memoria. Considérese esto como una compensación, no como una ventaja. Eliminar el límite en un servidor web público cambia un modo de fallo por otro, y en un NAS con un presupuesto de memoria compartida, propicia que el grupo de trabajadores agote toda la máquina.

El filtrado de borde es la capa de PHP2Shell que realmente aporta algo, porque ve el tráfico descifrado y tu router no. Cloudflare ha implementado protección de reglas administradas para PHP2Shell, AWS agregó cobertura para CVE-2026-109619 en la versión 2.3 de su grupo de reglas administradas de PHP, y Azure Front Door lanzó la regla 99006001, que está deshabilitada por defecto. Existen reglas de la comunidad para Snort y Suricata en GitHub, pero los conjuntos de reglas oficiales de Snort y Emerging Threats no habían publicado nada al momento de escribir esto, por lo que una función de prevención de intrusiones de NAS no te salvará en este caso. De todos modos, no puede leer dentro de TLS.

¿Qué proveedor de NAS realmente lanzó una solución?

Esta es la parte de la historia de PHP2Shell que debería influir en tu decisión de compra. La versión principal de PHP se lanzó el 21 de octubre. Aquí te mostramos la situación de los cuatro principales proveedores de NAS para consumidores y profesionales al día siguiente, según sus propias páginas de avisos, no a través de la cobertura mediática.

Proveedor	Consultivo	Estado	Versiones corregidas publicadas
Sinología	Synology-SA-26:14, 22 oct. 2026	Resuelto	Sí. Todas las sucursales desde PHP 7.4 hasta 8.4, además de Calendario y Estación de correo.
QNAP	QSA-26-18, 22 de octubre de 2026	Fijación	No. Cada fila dice "Por anunciar"
ASUSTOR	Retirada de Legacy PHP, 22 de octubre de 2026	Jubilación, no un parche	No. PHP 7, 7.3, 7.4 y 8.1 eliminados de App Central.
UGREEN	No se encontró ninguno	Desconocido	No se encontró ningún aviso para UGOS Pro.

Synology publicó una tabla completa de versiones de PHP2Shell el mismo día que el aviso y lo marcó como resuelto. El propietario de DSM que lo leyó tuvo que realizar una acción esa misma tarde: abrir el Centro de paquetes, hacer clic en Actualizar y verificar. Ese es el proceso completo de solución, y por eso nuestras máquinas Web Station se terminaron en minutos en lugar de días.

QNAP publicó en la misma fecha una larga lista de productos afectados, que incluye QTS 6.1.0, QTS 5.2.11 y versiones anteriores, QuTS hero h6.1.0, h6.0.x y h5.2.11 y versiones anteriores, QuTScloud c5.2.9 y versiones anteriores, Note Station 3, QNE ADRA, QVR Surveillance en modelos ARM32 y TVR OS. Todos ellos muestran el estado "En reparación" sin una versión corregida. Dado que el entorno de ejecución de PHP forma parte de los componentes web de QTS, no hay ningún paquete que actualizar, por lo que la solución debe implementarse mediante una actualización de firmware.

Mientras tanto, QNAP ofrece a las víctimas de PHP2Shell una lista de medidas de mitigación, que conviene leer detenidamente por lo que solicita: deshabilitar el reenvío de puertos del router y UPnP, despublicar los servicios de myQNAPcloud, trasladar el acceso remoto a una VPN, restringir los puertos de administración a subredes de confianza, detener las aplicaciones basadas en PHP que no se necesiten, deshabilitar el servidor web integrado si no se utiliza y auditar QuLog Center en busca de indicios de compromiso. Se trata de un buen consejo para un equipo sin parchear. También implica, para quienes alojan un sitio web público, la necesidad de desactivarlo.

ASUSTOR optó por una tercera vía. Su aviso, fechado el 22 de octubre y titulado «Anuncio de retirada de PHP heredado», elimina PHP 7, PHP 7.3, PHP 7.4 y PHP 8.1 de App Central con efecto inmediato, recomienda realizar copias de seguridad de los datos importantes e indica a los usuarios que utilicen únicamente PHP 8.3 o 8.4 a partir de ahora. El razonamiento es defendible, ya que el proyecto original solo aplica parches a la versión 8.2 y posteriores. El efecto para un usuario que ejecuta una aplicación PHP antigua es que el entorno de ejecución desaparece de la tienda en lugar de corregirse, y ASUSTOR no indica que se haya publicado una versión parcheada de 8.3 o 8.4. Nótese el contraste con Synology, que sí publicó una versión corregida de 7.4 (7.4.33-0131) precisamente para los usuarios a los que ASUSTOR solicita la migración.

En el caso de UGREEN, no encontramos ningún aviso de seguridad de PHP2Shell para UGOS Pro. La ausencia de una declaración pública no prueba que un producto sea vulnerable, y es posible que UGOS Pro simplemente no incluya una aplicación web para PHP. Sin embargo, si usted es el propietario, el silencio no es una respuesta que le permita actuar, y eso representa una exposición.

Nada de esto convierte a Synology en una solución perfecta. No corrige PHP 7.3, marca DSM 7.2 como obsoleto y su propio componente interno de PHP sigue programado en lugar de parcheado. La cuestión es más específica y útil que un argumento de marca: el día en que se detectó un fallo de ejecución remota de código sin autenticación en el motor PHP, un proveedor convirtió la solución en un botón en el Centro de paquetes, mientras que los demás lo convirtieron en una mera espera.

Dónde encontrar más recursos oficiales

PHP2Shell tiene solo dos días de antigüedad al momento de escribir esto y la situación aún está en desarrollo, por lo que recomendamos consultar las fuentes originales en lugar de los resúmenes. Todavía no hay videos oficiales de ninguno de los proveedores, por lo que la siguiente lista contiene documentación, no tutoriales.

• Synology-SA-26:14 Esta es la tabla de versiones autorizada. Revísala de nuevo antes de aplicar el parche, ya que los avisos se actualizan.
• Declaración del PSIRT Synology Enumera los paquetes afectados y explica el componente interno de DSM y la excepción de la estación de correo.
• Los avisos de GitHub GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp, que se encuentran en la fuente original, están vinculados al aviso Synology y describen el comportamiento del motor en lugar del empaquetado del proveedor.
• QNAP QSA-26-18 Aquí es donde aparecerá una versión de firmware corregida si ejecutas QTS o QuTS hero. Es la página que debes consultar, no un artículo de noticias.
• Tu propio Centro de paquetes es la última palabra sobre lo que está instalado. El aviso te dice la compilación de destino, el mosaico te dice lo que realmente tienes y solo php -v Te indica qué está en funcionamiento.

Para obtener información general sobre cómo ejecutar sitios públicos en máquinas virtuales Synology, consulte nuestro tutorial sobre Trasladar una pila Docker entre invitados VDSM Describe los hábitos de instantáneas y reversión que hicieron posible sobrevivir a esta emergencia.

Límites y notas de seguridad de PHP2Shell

Modificar PHP2Shell es sencillo en DSM y complicado en otros entornos, por lo que conviene aclarar algunas limitaciones antes de dar por finalizado el trabajo.

Una actualización del paquete PHP2Shell no constituye una auditoría del sitio. Actualizar PHP soluciona el problema a partir de ese momento, pero si el servidor era accesible desde internet entre el 20 y el 22 de octubre, lo era mientras existía un exploit activo. Revise los registros en busca de un volumen inesperado de solicitudes POST, busque archivos que hayan aparecido en directorios con permisos de escritura y rote cualquier credencial que un proceso PHP pudiera haber tenido. La variante de divulgación de memoria hace que el rote de credenciales sea una precaución razonable, no una medida paranoica.

La verificación de PHP2Shell debe apuntar al intérprete en ejecución. Los paneles, los registros de compilación y los encabezados de respuesta nos fallaron al menos una vez durante esta ronda. Una CDN puede eliminar el encabezado que habría indicado la versión, una compilación puede informar éxito mientras reutiliza una capa en caché y un mosaico de paquete puede mostrar la versión actual mientras un trabajador antiguo todavía está sirviendo. Solo php -v Dentro de lo que atiende las solicitudes lo resuelve.

Los contenedores no están cubiertos por ninguna advertencia de PHP2Shell del proveedor. Es importante recalcarlo, ya que es la falsa sensación de seguridad más común en un NAS. Si su sitio web se ejecuta en Container Manager, el Centro de paquetes que informa que todo está actualizado no le proporciona ninguna información sobre su sitio. Lo mismo se aplica a cualquier aplicación de terceros que incluya su propio entorno de ejecución.

Las medidas de mitigación de configuración son parciales por diseño. Deshabilitar el progreso de carga de sesión ayuda, eliminar el límite de memoria cambia un riesgo por otro, y una función de prevención de intrusiones del enrutador no puede inspeccionar el tráfico TLS que termina en otro lugar. Considere todo esto como tiempo ganado mientras implementa una solución definitiva, no como un sustituto de la misma.

Las versiones obsoletas de PHP2Shell no tienen ninguna ruta de compatibilidad. PHP 7.3 y versiones anteriores no recibieron ninguna actualización ni de la rama principal ni de Synology. Si un sitio web realmente necesita una rama sin soporte, la decisión que debe tomar es migrar, aislar o retirarse de internet. No hay una cuarta opción, y pretender lo contrario es la forma en que un sitio antiguo se convierte en la puerta de entrada a todo lo demás en el mismo servidor.

Finalmente, preste atención al aviso en lugar de a las noticias. Synology marcó SA-26:14 como resuelto y lo revisó una vez a los seis minutos de su publicación. QNAP ha indicado que QSA-26-18 se actualizará a medida que estén disponibles las versiones corregidas. Ambas páginas cambiarán, y los números de versión en este artículo corresponden a las publicadas el 22 de octubre de 2026.

Referencias

• Synology-SA-26:14 Aviso de seguridad de PHP2Shell, publicado el 22 de octubre de 2026, estado Resuelto, con versiones corregidas para PHP 7.4 a 8.4.
• Declaración Synology sobre vulnerabilidades de PHP2Shell, la nota de PSIRT que enumera los paquetes afectados y la cobertura de DSM.
• QNAP QSA-26-18, Estado: En reparación. Productos afectados listados con versiones corregidas. Se anunciarán próximamente.
• Anuncio de retirada del soporte PHP heredado de ASUSTOR, eliminando PHP 7, 7.3, 7.4 y 8.1 de App Central.
• Ayuda a Net Security en las versiones upstream de PHP2Shell, que abarca PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y las retrocompatibilidades solo de código fuente para ramas más antiguas.

Preguntas frecuentes