{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/es\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell en Synology: C\u00f3mo parcheamos seis sitios en un solo d\u00eda."},"content":{"rendered":"

PHP2Shell<\/strong> es el nombre que la industria eligi\u00f3 para CVE-2026-109618 y CVE-2026-109619, un par de fallos cr\u00edticos en el propio motor PHP que permiten la ejecuci\u00f3n remota de c\u00f3digo sin autenticaci\u00f3n. Los detalles se filtraron el 20 de octubre de 2026, un d\u00eda antes de la divulgaci\u00f3n coordinada, y el proyecto PHP lanz\u00f3 versiones de emergencia el 21 de octubre. Dado que el error reside en el int\u00e9rprete y no en ninguna aplicaci\u00f3n, parchear WordPress, Joomla o MediaWiki no tiene ning\u00fan efecto. La \u00fanica soluci\u00f3n real es una nueva compilaci\u00f3n de PHP. Ejecutamos seis sitios p\u00fablicos de WordPress en hardware Synology, y PHP2Shell hizo que cada uno de ellos tuviera que reconstruirse en la misma semana. Esta gu\u00eda cubre en qu\u00e9 consiste el error, c\u00f3mo parchearlo en DSM a trav\u00e9s del Centro de paquetes, c\u00f3mo manejarlo cuando su sitio se ejecuta en un contenedor y la inc\u00f3moda comparaci\u00f3n entre lo que lanz\u00f3 Synology y lo que otros proveedores de NAS han logrado hasta ahora.<\/p>\n\n\n\n

\n

Punto SynoPower Club:<\/strong>Nuestros seis sitios se actualizaron en un d\u00eda h\u00e1bil tras la publicaci\u00f3n del aviso de PHP2Shell, y esto no se debi\u00f3 a ninguna haza\u00f1a, sino a que Synology public\u00f3 paquetes corregidos el mismo d\u00eda. El Synology-SA-26:14 se public\u00f3 el 22 de octubre con el estado "Resuelto" y una tabla completa de versiones corregidas hasta PHP 7.4. Ese mismo d\u00eda, QNAP public\u00f3 QSA-26-18 con el estado "Corrigiendo" y la leyenda "Por anunciar" en cada celda de versi\u00f3n corregida, y ASUSTOR respondi\u00f3 eliminando el PHP antiguo de App Central en lugar de actualizarlo. Si usted aloja un sitio web p\u00fablico 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.<\/p>\n<\/blockquote>\n\n\n\n

\u00bfQu\u00e9 es PHP2Shell y por qu\u00e9 es diferente?<\/h2>\n\n\n\n

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\u00e9s de una solicitud que se qued\u00f3 sin memoria. PHP utiliza salto largo()<\/code> Para evitar errores fatales, incluidos los de falta de memoria, este salto omite el c\u00f3digo de limpieza que normalmente devolver\u00eda 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.<\/p>\n\n\n\n

CVE-2026-109618 se refiere al problema de falta de memoria. Una solicitud HTTP manipulada agota el l\u00edmite 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\u00f3n de c\u00f3digo o divulgaci\u00f3n de memoria.<\/p>\n\n\n\n

Dos caracter\u00edsticas hacen que PHP2Shell sea peor que las advertencias habituales de PHP. Primero, es una vulnerabilidad previa a la autenticaci\u00f3n. Ambas fallas se activan antes de que se ejecute cualquier autenticaci\u00f3n a nivel de aplicaci\u00f3n, por lo que un muro de inicio de sesi\u00f3n, un complemento de membres\u00eda o una contrase\u00f1a de administrador no protegen nada. Segundo, la variante de divulgaci\u00f3n 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\u00f3n del c\u00f3digo para arruinarte la semana.<\/p>\n\n\n\n

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

\"Synology-SA-26:14
Synology-SA-26:14, publicado el 22 de octubre de 2026 a las 19:45 UTC+8 con estado Resuelto.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell frente a un exploit normal de WordPress<\/h2>\n\n\n\n

La mayor\u00eda de los problemas que afectan a un sitio WordPress p\u00fablico se deben a vulnerabilidades en los plugins. El patr\u00f3n es conocido: un plugin incluye un endpoint REST defectuoso, un esc\u00e1ner lo detecta, se actualiza el plugin y la vulnerabilidad se soluciona. PHP2Shell rompe con este patr\u00f3n por completo, y auditar los plugins de forma autom\u00e1tica resulta un esfuerzo in\u00fatil en este caso.<\/p>\n\n\n\n

Aspecto<\/th>CVE de complemento t\u00edpico<\/th>PHP2Shell<\/th><\/tr><\/thead>
Donde vive el insecto<\/td>C\u00f3digo de la aplicaci\u00f3n (plugin o tema)<\/td>El int\u00e9rprete de PHP en s\u00ed mismo<\/td><\/tr>
\u00bfQui\u00e9n puede desencadenarlo?<\/td>A menudo se necesita un rol de suscriptor o administrador.<\/td>Nadie. Preautenticaci\u00f3n, antes de que se ejecute la l\u00f3gica de la aplicaci\u00f3n.<\/td><\/tr>
\u00bfActualizar WordPress ayuda?<\/td>Normalmente s\u00ed<\/td>No. Las actualizaciones del n\u00facleo y de los complementos son irrelevantes.<\/td><\/tr>
\u00bfLo impide una WAF?<\/td>Por lo general, una vez que existe una regla<\/td>En parte. Las reglas de forma de solicitud no contemplan la ruta de OOM.<\/td><\/tr>
\u00bfQu\u00e9 es lo que realmente lo soluciona?<\/td>Actualizaci\u00f3n del plugin<\/td>Una nueva compilaci\u00f3n de PHP, nada m\u00e1s.<\/td><\/tr>
Radio de explosi\u00f3n<\/td>Un sitio, una funci\u00f3n<\/td>Todos los sitios PHP en el servidor, todos a la vez.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esa \u00faltima fila explica por qu\u00e9 PHP2Shell se convirti\u00f3 en una jornada laboral completa en lugar de una tarde. Un \u00fanico paquete PHP compartido en un NAS puede estar detr\u00e1s de una docena de hosts virtuales de Web Station, y una sola imagen de contenedor puede servir de base para varios sitios. La aplicaci\u00f3n de parches no es por sitio, sino por entorno de ejecuci\u00f3n, y es necesario enumerar los entornos de ejecuci\u00f3n antes de poder afirmar que se ha realizado alg\u00fan trabajo.<\/p>\n\n\n\n

C\u00f3mo saber si tu NAS est\u00e1 expuesto<\/h2>\n\n\n\n

Para determinar la vulnerabilidad de PHP2Shell, primero hay que diferenciar dos preguntas clave: \u00bfEl sistema contiene una compilaci\u00f3n PHP vulnerable y es accesible desde internet? Synology hace esta distinci\u00f3n expl\u00edcitamente: DSM incluye un componente PHP interno utilizado por el sistema operativo, y Synology afirma que no tiene m\u00f3dulos accesibles externamente y, por lo tanto, no presenta ninguna superficie de ataque expuesta. El riesgo que asigna a este componente es m\u00ednimo, y el parche est\u00e1 programado para una versi\u00f3n posterior de DSM, de modo que los an\u00e1lisis de vulnerabilidades dejen de detectarlo.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\u00f3n en el mosaico, y el aviso de actualizaci\u00f3n indica la compilaci\u00f3n de destino. Desde la consola, consulta directamente al entorno de ejecuci\u00f3n:<\/p>\n\n\n\n

# Synology Paquete PHP (ajuste la ruta a la versi\u00f3n que ejecuta) \/volume1\/@appstore\/PHP8.2\/usr\/local\/bin\/php -v # Un sitio en contenedor docker exec php -v<\/code><\/pre>\n\n\n\n
La raz\u00f3n para insistir en php -v<\/code> Al auditar PHP2Shell, se observa que casi todas las dem\u00e1s se\u00f1ales son enga\u00f1osas. La salida de la compilaci\u00f3n puede reportar \u00e9xito mientras se reutiliza una capa en cach\u00e9, un panel de control puede mostrar un paquete como actualizado cuando el proceso en ejecuci\u00f3n no lo est\u00e1, 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\u00f3n a pesar de seguir ejecutando un int\u00e9rprete sin parchear.<\/p>\n\n\n\n
C\u00f3mo aplicar un parche a PHP2Shell en Synology en 4 pasos<\/h2>\n\n\n\n
Para un sitio Web Station en DSM, la soluci\u00f3n completa para PHP2Shell consiste en una actualizaci\u00f3n del Centro de Paquetes. Synology publica actualizaciones de seguridad de PHP para DSM 7.4, 7.3 y 7.2, y tras la actualizaci\u00f3n del paquete PHP, los paquetes dependientes se reinician autom\u00e1ticamente, lo que resuelve el problema. Mail Station es la excepci\u00f3n documentada y requiere una actualizaci\u00f3n manual.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Consulte el aviso<\/h3>\n
Abra Synology-SA-26:14 y observe la versi\u00f3n corregida para cada rama de PHP que tenga instalada. Las versiones objetivo son 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 y 8.4.27-0051. PHP 7.3 no tiene correcci\u00f3n porque ha llegado al final de su ciclo de vida.<\/p>\n<\/div>\n<\/div>\n
\n
Actualizar a trav\u00e9s del Centro de Paquetes<\/h3>\n
En DSM, abre el Centro de paquetes y consulta la secci\u00f3n Instalados. Cada paquete PHP vulnerable muestra "Actualizaci\u00f3n disponible" con la nueva versi\u00f3n en l\u00ednea. Haz clic en "Actualizar" en cada rama de PHP que aparezca en la lista y actualiza Synology Calendar y Mail Station si los tienes instalados.<\/p>\n<\/div>\n<\/div>\n
\n
Deje que los dependientes vuelvan a empezar<\/h3>\n
Los paquetes que dependen de PHP se reinician autom\u00e1ticamente una vez que el paquete PHP finaliza su actualizaci\u00f3n, y ese reinicio es lo que aplica la correcci\u00f3n. Mail Station es la excepci\u00f3n y debe actualizarse manualmente desde el Centro de paquetes.<\/p>\n<\/div>\n<\/div>\n
\n
Verifique el int\u00e9rprete en ejecuci\u00f3n.<\/h3>\n
No conf\u00edes en el panel de control. Ejecuta `php -v` en la ruta del paquete o dentro del contenedor y confirma que el n\u00famero de compilaci\u00f3n coincide con el aviso. Luego, verifica que cada host virtual de Web Station est\u00e9 vinculado a un perfil que hayas actualizado.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"El
El Centro de Paquetes ofrece PHP 8.2.35-0171, la compilaci\u00f3n mencionada en el aviso.<\/figcaption><\/figure>\n\n\n\n
La captura de pantalla anterior corresponde a una de nuestras m\u00e1quinas, tomada la ma\u00f1ana despu\u00e9s del aviso de PHP2Shell. Observe que el panel "Novedades" indica directamente la versi\u00f3n original, lo que permite comparar el sufijo de compilaci\u00f3n Synology con la versi\u00f3n de PHP sin tener que adivinar. Synology Calendar aparece en la misma lista de actualizaciones con la versi\u00f3n 3.0.4-21435, que es precisamente la versi\u00f3n recomendada en el aviso.<\/p>\n\n\n\n
\"Synology
El cuadro de di\u00e1logo de actualizaci\u00f3n que menciona PHP 8.2.35-0171, publicado por Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Un detalle importante a tener en cuenta para los usuarios de Web Station en PHP2Shell: una m\u00e1quina DSM puede tener varias ramas de PHP instaladas simult\u00e1neamente, y cada host virtual est\u00e1 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\u00edcelos todos y, a continuaci\u00f3n, compruebe la vinculaci\u00f3n de cada sitio web en Web Service.<\/p>\n\n\n\n
\u00bfQu\u00e9 paquetes de DSM se ven afectados?<\/h2>\n\n\n\n
La declaraci\u00f3n Synology en PHP2Shell es m\u00e1s espec\u00edfica de lo que suger\u00eda 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\u00e1 en la lista, pero es un software de terceros.<\/p>\n\n\n\n