ISPConfig 3.3.2: Ubuntu 26.04, DMARC y correcciones de seguridad

O ISPConfig 3.3.2 salió el 18 de septiembre de 2026 y, tres días después, recibió el parche 3.3.2p1. Es una actualización que merece la pena aplicar cuanto antes: además del soporte para Ubuntu 26.04 y de novedades en el correo, corrige una inyección SQL en la API remota, una escalada de privilegios en Fetchmail y una serie de fallos detectados en una auditoría de código. Esta guía resume qué ha cambiado, qué comprobar tras la actualización y cómo actualizar sin sobresaltos.

Si eres nuevo en el panel, merece la pena leer antes la historia de ISPConfig y nuestra guía de alojamiento de sitios web con ISPConfig.

Seguridad: por qué actualizar ahora

El anuncio oficial no cita números de CVE, solo las issues del proyecto y quién reportó cada fallo. Las dos más graves:

• Inyección de SQL en la API remota (#7051). El ID de registro pasado a las funciones de update e delete de la API iba a la consulta SQL sin validación. Un usuario de la API con permiso para una de esas funciones podía modificar o eliminar registros fuera de su permiso y leer datos de otras tablas. Ahora el ID debe ser un entero positivo y las consultas usan placeholders. Reportado por Nguyen Chi Quang, de MBBank.
• Escalada de privilegios en Fetchmail (#7052). Los campos de una cuenta Fetchmail se escribían en el archivo de configuración de getmail sin validación: con saltos de línea, un cliente lograba inyectar secciones extra. Los saltos de línea y los bytes nulos ahora se eliminan, el destino debe ser un correo electrónico válido y el complemento se niega a escribir en enlaces simbólicos o fuera del directorio de getmail. Reportado por Arvin Shivram, de Brutecat Security.

También entraron correcciones de una auditoría de código realizada por siteguardian.io (#7044):

• el enlace de restablecimiento de contraseña se construía a partir del encabezado Host de la petición, lo que permitía enviar al usuario un enlace apuntando a un servidor del atacante;
• los tokens CSRF pasan a ser obligatorios en las copias de seguridad, la importación de zonas DNS, la gestión de extensiones y la importación de vpopmail;
• la comprobación TLS vuelve a aplicarse en la descarga de extensiones y paquetes APS;
• el ID de sesión se regenera al iniciar sesión;
• los hashes y tokens se comparan en tiempo constante;
• las cabeceras de correo electrónico quedan protegidas contra la inyección de CRLF;
• los argumentos de shell pasan a escaparse en los comandos de DNSSEC de PowerDNS, certbot y de tamaño de PostgreSQL;
• la extracción de paquetes APS rechaza path traversal;
• unserialize() ya no acepta objetos;
• el archivo antiguo interface/web/remote/monitor.php se elimina.

Dos errores con efecto de seguridad completan la lista. El campo de cliente de los formularios volvía al primer elemento tras un error de validación, y con ello un registro podía pasar al revendedor, o un sitio cambiar de directorio (#7048). Y una cuota de tráfico igual a 0 no se aplicaba, lo que permitía saltarse el límite de tráfico del cliente (#7024).

El ciclo anterior también incluyó correcciones de seguridad: el ISPConfig 3.3.1, de enero de 2026, corrigió tres fallos de escalada de privilegios en temas, restauración y descarga de copias de seguridad. Quienes aún estén en 3.3.0 tienen aún más motivos para actualizar.

Qué hay de nuevo

Ubuntu 26.04 LTS

ISPConfig 3.3.2 es compatible con Ubuntu 26.04 LTS, incluida la sintaxis de configuración de Dovecot 2.4 utilizada por esa versión (#6996). La lista oficial de distribuciones compatibles queda así:

• Debian 11 a 13 (recomendado) y Debian testing;
• Ubuntu 22.04 LTS a 26.04 LTS (recomendado);
• AlmaLinux 8 a 10 y Rocky Linux 8 a 10;
• CentOS 8.

DMARC en la entrada de correo

Una nueva opción hace que rspamd aplique la política DMARC publicada por el dominio remitente: el mensaje que la incumpla será rechazado o enviado a cuarentena, según la política del dominio, p=reject o p=quarantine (#6995).

Remitente independiente para correos del sistema

El correo del administrador servía al mismo tiempo como remitente y destinatario de los mensajes del sistema. Cuando el buzón del administrador está en otro proveedor, esto rompía el SPF: el servidor de ISPConfig enviaba usando un dominio que no aloja. En Sistema > Configuración Principal > Correo ahora existen dos campos (#7028):

• Correo electrónico de contacto del administrador (admin_mail: recibe las notificaciones y es la dirección de respuesta;
• Dirección de correo del remitente del servidor (server_sender_mail: el remitente de los mensajes del sistema, como avisos de tráfico y cuota, monitorización, OTP, restablecimiento de contraseña y bienvenida.

La actualización copia el correo actual del administrador al nuevo campo, así que nada cambia hasta que configures otro remitente. Vale la pena aprovechar y usar una dirección de un dominio alojado en el propio servidor. Las plantillas personalizadas en conf-custom/mail/ que definen su propio remitente no se modifican.

Copia de seguridad de la base de datos sin bloquear tablas

O mysqldump bloquea todas las tablas de la base de datos durante el volcado, y el sitio puede quedarse sin responder mientras la copia de seguridad se ejecuta. En Sistema > Configuración del Servidor > Servidor hay una nueva opción para usar --single-transaction (#7049):

• Automatic (por defecto): utiliza --single-transaction solo cuando todas las tablas usan un motor transaccional como InnoDB. Las bases de datos con tablas MyISAM o MEMORY siguen con bloqueo, porque sin él el volcado de esas tablas no queda consistente.
• Yes: nunca bloquea. Es la opción para bases de datos mixtas en las que la disponibilidad importa más que la coherencia de las tablas no transaccionales.
• En el: mantiene el comportamiento antiguo.

Otros cambios

• Límites extensibles (#7019): las extensiones pueden registrar límites propios de cliente y revendedor sin modificar archivos del núcleo.
• Lista de CAs para registros CAA actualizada (#7017).
• Páginas de error personalizadas desactivadas por defecto en sitios nuevos; los existentes no cambian (#7021).
• ispconfig_update.sh obtuvo una opción de línea de comandos para actualizar desde una rama específica.
• Mejoras en acme.sh para direcciones de loopback, con mejor registro en el instalador y descarga mediante curl como alternativa.
• El override del directorio temporal de systemd también pasa a aplicarse a la unit de Apache.

Entre las correcciones: barras invertidas que desaparecen de valores de configuración, como la contraseña SMTP (#7042); cron interno que nunca más se ejecutaba tras una ejecución abortada (#7034); falta de aviso de copia de seguridad nocturna con error (#7002); .htaccess cambiando a root:root (#7035); DivisionByZeroError en las estadísticas de tráfico en PHP 8 (#7023); y BIND sin poder escribir zonas secundarias en Ubuntu 24.04 con AppArmor. La lista completa está en el hito 99 del GitLab del proyecto.

El parche 3.3.2p1: regresiones ya corregidas

El 21 de septiembre salió el 3.3.2p1, que corrige problemas encontrados justo después del lanzamiento. Si ya actualizaste a la 3.3.2, comprueba si te afectó:

• rspamd no arrancaba tras la actualización con reconfiguración de servicios (#7054). La actualización renombraba /etc/rspamd/local.d/users.conf, , pero la directiva de inclusión se quedaba en /etc/rspamd/rspamd.conf cuando no terminaba con salto de línea. El p1 elimina la directiva y repara servidores ya afectados.
• Cron del ISPConfig abortando con Unsupported operand types: string + string en PHP 8, por lectura errónea de la salida del repquota (#7053).
• MySQL y MariaDB antiguos: la columna pid no se creaba en sys_cron en MySQL y en MariaDB anterior a 10.0.2 (#7055). Y los usuarios de base de datos no se creaban en MariaDB anterior a 10.1.3 y en MySQL anterior a 5.7.8 (#7056).
• Buzones de correo creados en el servidor equivocado cuando el mismo dominio existe en más de un servidor de correo (#7057).

En la práctica: actualice directamente a 3.3.2p1. El canal stable ya entrega esta versión.

Antes de actualizar

1. Backup. El propio actualizador ofrece crear un backup en /var/backup/. Acepte, y tenga también un snapshot de la VM o un backup externo de la base de datos dbispconfig y de /usr/local/ispconfig.
2. Versión actual. Compruebe desde dónde sale:

   grep ISPC_APP_VERSION /usr/local/ispconfig/server/lib/config.inc.php

3. Multiservidor. Active el modo de mantenimiento, actualice primero el servidor master, después los slaves, y solo entonces desactive el mantenimiento. Es el orden que el propio script de update recomienda.

Cómo actualizar

El camino más simple es el script ya instalado en el servidor, apuntando al canal estable. Ejecute como root:

ispconfig_update.sh --update-source=stable

Sin la opción, el script pregunta el origen; elija stable. Los canales nightly e git-develop son para entornos de desarrollo y no deben usarse en servidores con sitios en producción.

La alternativa es el paquete manual. El anuncio oficial muestra los comandos con el archivo ISPConfig-3.3.2.tar.gz; para ya incluir las correcciones del parche, usa el 3.3.2p1, publicado en el mismo directorio de descargas:

cd /tmp
wget https://www.ispconfig.org/downloads/ISPConfig-3.3.2p1.tar.gz
tar xvfz ISPConfig-3.3.2p1.tar.gz
cd ispconfig3_install/install
php -q update.php

El updater hace algunas preguntas. Los valores predeterminados se ajustan a la mayoría de los casos:

• Shall the script create a ISPConfig backup in /var/backup/ now? yes.
• Reconfigure Permissions in master database? no en servidor único; en multiservidor, solo si has cambiado algo en los permisos.
• Reconfigure Services? yes, para aplicar los cambios de Dovecot, rspamd, Apache o nginx. Utiliza selected si quieres elegir servicio por servicio.
• Create new ISPConfig SSL certificate: no, a menos que desee cambiar el certificado del panel.
• ¿Reconfigurar Crontab? yes.

Después de actualizar: lista de comprobación

grep ISPC_APP_VERSION /usr/local/ispconfig/server/lib/config.inc.php   # 3.3.2p1
systemctl status rspamd dovecot postfix --no-pager
tail -n 50 /var/log/ispconfig/cron.log

• Enlace de restablecimiento de contraseña: si se accede al panel mediante un nombre diferente al nombre de host del servidor, defina interface_base_url en /usr/local/ispconfig/interface/lib/config.inc.php. Sin esto, el enlace sale con el nombre de host del servidor.
• Lista blanca del IDS: el alcance de las entradas (any, user, admin) ahora se respeta. Si tiene security/ids.whitelist.custom, verifique que los campos editables por revendedores usen el alcance user.
• Remitente del sistema: ajuste el Dirección de correo del remitente del servidor si el correo del administrador queda fuera del servidor.
• Copia de seguridad sin bloqueos: revisa la nueva opción en Server Config si tus bases de datos mezclan InnoDB y MyISAM.
• DMARC: activa la aplicación de la política en la entrada con calma, vigilando la cuarentena durante los primeros días.

Problemas conocidos

El proyecto mantiene la lista de bugs abiertos en GitLab. Consúltala antes de actualizar servidores críticos y registra nuevas incidencias en el seguimiento de issues. Hasta ahora, las regresiones confirmadas por el propio proyecto son las cinco corregidas en 3.3.2p1. El GitLab de ISPConfig está detrás de una verificación de Cloudflare, así que abre los enlaces en el navegador; las herramientas de línea de comando suelen ser bloqueadas.

Resumen

La 3.3.2 es una actualización de seguridad disfrazada de release de funcionalidades. Ubuntu 26.04, DMARC y copia de seguridad sin bloqueos son bienvenidos, pero el motivo para programar la ventana esta semana es la inyección de SQL en la API remota y Fetchmail, especialmente en servidores con revendedores o clientes que usan la API. Actualiza directamente a 3.3.2p1, haz la copia de seguridad y pasa el checklist. Para quien monta el servidor desde cero, la guía de ISPConfig en Debian muestra la ruta clásica, y la de Nginx con varias versiones de PHP ayuda a entender lo que el panel configura por debajo.