Miércoles, 28 de octubre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

Plesk publica parches para las vulnerabilidades críticas PHP2Shell (CVE-2026-109618 y CVE-2026-109619)

Plesk ha publicado actualizaciones que corrigen dos vulnerabilidades críticas de PHP conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), que permiten ejecución remota. La empresa aconseja actualizar tanto los PHP usados por sitios alojados como el motor PHP que usa Plesk en la interfaz.

Por Equipo ehost3 min de lecturaFuente: Plesk
Plesk publica parches para las vulnerabilidades críticas PHP2Shell (CVE-2026-109618 y CVE-2026-109619)
Imagen ilustrativa generada con inteligencia artificial.

El 21 de octubre de 2026 el proyecto PHP lanzó actualizaciones de seguridad que corrigen dos fallos críticos —CVE-2026-109618 y CVE-2026-109619— apodados PHP2Shell, ambos con una puntuación CVSS de 9.2. Plesk, que distribuye paquetes de PHP para sitios web alojados y ejecuta su propia instancia de PHP para la interfaz del panel, confirma que las instalaciones de Plesk Obsidian permanecen vulnerables hasta aplicar las correcciones.

Qué sistemas afectan y qué debe actualizarse

Según Plesk, hay dos componentes que deben parchearse en cada servidor con Plesk:

  • Las versiones de PHP que usan los sitios de los clientes (por ejemplo, PHP gestionado por Plesk para dominios y hosting compartido).
  • El motor PHP que ejecuta la propia interfaz de Plesk (la instancia interna que sirve el panel y sus servicios).

Plesk ha publicado builds de PHP corregidos para Linux y ha lanzado actualizaciones de Plesk Obsidian (menciones a builds y actualizaciones concretas están disponibles en el aviso de seguridad de Plesk y en las notas de la versión). Es imprescindible aplicar tanto las actualizaciones de Plesk como los paquetes de PHP suministrados por Plesk para resolver completamente las vulnerabilidades.

Versiones y medidas complementarias

El proyecto PHP advierte que todas las instalaciones de PHP que atienden solicitudes web están en riesgo, y que las configuraciones con mod_php (PHP ejecutado como módulo de Apache) representan el mayor nivel de exposición. Plesk subraya además que, aunque algunas versiones antiguas conservan el mismo número de versión, la corrección se identifica por la fecha de compilación del paquete; por tanto, la única forma de asegurarse es instalar los builds publicados por Plesk.

Para PHP 7.4, 8.0 y 8.1 Plesk ha distribuido builds corregidos a pesar de que estas ramas han llegado a su fin de soporte por parte del proyecto PHP. Plesk recomienda, como medida a largo plazo, migrar los sitios a versiones de PHP con soporte oficial. Para ramas EOL más antiguas (por ejemplo, 5.6, 7.2, 7.3), Plesk recuerda que existen opciones de soporte extendido de terceros que proveen parches.

Qué deben hacer los administradores y dueños de sitios

  • Actualizar de inmediato: instale las actualizaciones de Plesk Obsidian y los builds de PHP publicados por Plesk para sus distribuciones.
  • Verificar ambas capas: confirme que tanto las versiones de PHP que sirven los sitios como la instancia interna de PHP de Plesk han quedado actualizadas.
  • Comprobar errores en la actualización: en Debian/Ubuntu, si aparece un error NO_PUBKEY 5B6AB2160B50DB96 al actualizar, siga las instrucciones de Plesk para añadir la clave pública y completar la actualización.
  • Migrar a versiones soportadas: planifique mover aplicaciones a versiones de PHP con mantenimiento oficial para reducir el riesgo futuro.
  • Tratar las mitigaciones como temporales: las medidas de reducción de exposición indicadas por el proyecto PHP son paliativas y no sustituyen a la actualización completa.

Comprobación y seguimiento

Plesk publica un aviso de seguridad con la lista completa de builds y versiones afectadas, así como enlaces a los registros de cambios de PHP y a las notas de las actualizaciones de Plesk Obsidian (por ejemplo, Update 4 de 18.0.81 y Update 11 de 18.0.80 se mencionan en el comunicado). Los administradores deben consultar ese aviso para confirmar qué paquetes concretos deben instalarse en su entorno.

En resumen: estas vulnerabilidades permiten ejecución remota y sólo se corrigen totalmente instalando los builds y actualizaciones oficiales; las mitigaciones reducen temporalmente el riesgo, pero no reemplazan la actualización completa.

Lee también:

Fuente: Plesk

Compartir