ISPConfig 3.3.2: Ubuntu 26.04, DMARC e correções de segurança

O ISPConfig 3.3.2 saiu em 18 de setembro de 2026 e, três dias depois, ganhou o patch 3.3.2p1. É uma atualização que vale fazer logo: além do suporte ao Ubuntu 26.04 e de novidades no e-mail, ela corrige uma injeção de SQL na API remota, uma escalada de privilégio no Fetchmail e uma série de falhas encontradas em uma auditoria de código. Este guia resume o que mudou, o que conferir depois do update e como atualizar sem sustos.

Se você é novo no painel, vale ler antes a história do ISPConfig e o nosso guia de hospedagem de sites com ISPConfig.

Segurança: por que atualizar agora

O anúncio oficial não cita números de CVE, apenas as issues do projeto e quem reportou cada falha. As duas mais graves:

• Injeção de SQL na API remota (#7051). O ID do registro passado às funções de update e delete da API ia para a consulta SQL sem validação. Um usuário da API com permissão para uma dessas funções podia alterar ou apagar registros fora da sua permissão e ler dados de outras tabelas. Agora o ID precisa ser um inteiro positivo e as consultas usam placeholders. Reportada por Nguyen Chi Quang, do MBBank.
• Escalada de privilégio no Fetchmail (#7052). Os campos de uma conta Fetchmail eram gravados no arquivo de configuração do getmail sem validação: com quebras de linha, um cliente conseguia injetar seções extras. Quebras de linha e bytes nulos agora são removidos, o destino precisa ser um e-mail válido e o plugin se recusa a escrever em links simbólicos ou fora do diretório do getmail. Reportada por Arvin Shivram, da Brutecat Security.

Também entraram correções de uma auditoria de código feita pela siteguardian.io (#7044):

• o link de redefinição de senha era montado a partir do cabeçalho Host da requisição, o que permitia enviar ao usuário um link apontando para um servidor do atacante;
• tokens CSRF passam a ser exigidos em backups, importação de zona DNS, gestão de extensões e importação do vpopmail;
• a verificação TLS volta a valer no download de extensões e pacotes APS;
• o ID de sessão é regenerado no login;
• hashes e tokens são comparados em tempo constante;
• cabeçalhos de e-mail ficam protegidos contra injeção de CRLF;
• argumentos de shell passam a ser escapados nos comandos de DNSSEC do PowerDNS, do certbot e de tamanho do PostgreSQL;
• a extração de pacotes APS rejeita path traversal;
• unserialize() não aceita mais objetos;
• o arquivo antigo interface/web/remote/monitor.php é removido.

Dois bugs com efeito de segurança completam a lista. O campo de cliente dos formulários voltava ao primeiro item depois de um erro de validação, e com isso um registro podia passar para o revendedor, ou um site mudar de diretório (#7048). E uma cota de tráfego igual a 0 não era aplicada, o que permitia contornar o limite de tráfego do cliente (#7024).

O ciclo anterior também teve correções de segurança: o ISPConfig 3.3.1, de janeiro de 2026, fechou três falhas de escalada de privilégio em temas, restauração e download de backups. Quem ainda está em 3.3.0 tem ainda mais motivo para atualizar.

O que há de novo

Ubuntu 26.04 LTS

O ISPConfig 3.3.2 suporta o Ubuntu 26.04 LTS, incluindo a sintaxe de configuração do Dovecot 2.4 usada por essa versão (#6996). A lista oficial de distribuições suportadas ficou assim:

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

DMARC na entrada de e-mail

Uma nova opção faz o rspamd aplicar a política DMARC publicada pelo domínio remetente: a mensagem que falhar é rejeitada ou vai para quarentena, conforme a política do domínio, p=reject ou p=quarantine (#6995).

Remetente separado para e-mails do sistema

O e-mail do administrador servia ao mesmo tempo como remetente e destinatário das mensagens do sistema. Quando a caixa do administrador fica em outro provedor, isso quebrava o SPF: o servidor ISPConfig enviava usando um domínio que não hospeda. Em System > Main Config > Mail agora existem dois campos (#7028):

• Administrator’s contact e-mail (admin_mail): recebe as notificações e é o endereço de resposta;
• Server sender e-mail address (server_sender_mail): o remetente das mensagens do sistema, como avisos de tráfego e cota, monitoramento, OTP, redefinição de senha e boas-vindas.

A atualização copia o e-mail atual do administrador para o novo campo, então nada muda até você configurar outro remetente. Vale aproveitar e usar um endereço de um domínio hospedado no próprio servidor. Templates personalizados em conf-custom/mail/ que definem o próprio remetente não são alterados.

Backup de banco sem travar tabelas

O mysqldump trava todas as tabelas do banco durante o dump, e o site pode ficar sem responder enquanto o backup roda. Em System > Server Config > Server há uma nova opção para usar --single-transaction (#7049):

• Automatic (padrão): usa --single-transaction só quando todas as tabelas usam um engine transacional como o InnoDB. Bancos com tabelas MyISAM ou MEMORY continuam com trava, porque sem ela o dump dessas tabelas não fica consistente.
• Yes: nunca trava. É a escolha para bancos mistos em que a disponibilidade importa mais que a consistência das tabelas não transacionais.
• No: mantém o comportamento antigo.

Outras mudanças

• Limites extensíveis (#7019): extensões podem registrar limites próprios de cliente e revendedor sem alterar arquivos do núcleo.
• Lista de CAs para registros CAA atualizada (#7017).
• Páginas de erro personalizadas desativadas por padrão em sites novos; os existentes não mudam (#7021).
• ispconfig_update.sh ganhou opção de linha de comando para atualizar a partir de um branch específico.
• Melhorias no acme.sh para endereços de loopback, com log melhor no instalador e download via curl como alternativa.
• O override de diretório temporário do systemd também passa a valer para a unit do Apache.

Entre as correções: backslashes sumindo de valores de configuração, como a senha SMTP (#7042); cron interno que nunca mais rodava depois de uma execução abortada (#7034); falta de aviso de backup noturno com falha (#7002); .htaccess passando para root:root (#7035); DivisionByZeroError nas estatísticas de tráfego no PHP 8 (#7023); e BIND sem conseguir gravar zonas secundárias no Ubuntu 24.04 com AppArmor. A lista completa está na milestone 99 do GitLab do projeto.

O patch 3.3.2p1: regressões já corrigidas

Em 21 de setembro saiu o 3.3.2p1, que corrige problemas encontrados logo depois do lançamento. Se você já atualizou para a 3.3.2, confira se foi afetado:

• rspamd não subia depois da atualização com reconfiguração de serviços (#7054). O update renomeava /etc/rspamd/local.d/users.conf, mas a diretiva de include ficava em /etc/rspamd/rspamd.conf quando não terminava com quebra de linha. O p1 remove a diretiva e repara servidores já afetados.
• Cron do ISPConfig abortando com Unsupported operand types: string + string no PHP 8, por leitura errada da saída do repquota (#7053).
• MySQL e MariaDB antigos: a coluna pid não era criada em sys_cron no MySQL e no MariaDB anterior ao 10.0.2 (#7055). E usuários de banco não eram criados no MariaDB anterior ao 10.1.3 e no MySQL anterior ao 5.7.8 (#7056).
• Caixas de e-mail criadas no servidor errado quando o mesmo domínio existe em mais de um servidor de e-mail (#7057).

Na prática: atualize direto para a 3.3.2p1. O canal stable já entrega essa versão.

Antes de atualizar

1. Backup. O próprio updater oferece criar um backup em /var/backup/. Aceite, e tenha também um snapshot da VM ou um backup externo do banco dbispconfig e de /usr/local/ispconfig.
2. Versão atual. Confira de onde você está saindo:

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

3. Multiservidor. Ative o modo de manutenção, atualize primeiro o servidor master, depois os slaves, e só então desative a manutenção. É a ordem que o próprio script de update recomenda.

Como atualizar

O caminho mais simples é o script já instalado no servidor, apontando para o canal estável. Rode como root:

ispconfig_update.sh --update-source=stable

Sem a opção, o script pergunta a origem; escolha stable. Os canais nightly e git-develop são para ambientes de desenvolvimento e não devem ser usados em servidores com sites em produção.

A alternativa é o pacote manual. O anúncio oficial mostra os comandos com o arquivo ISPConfig-3.3.2.tar.gz; para já incluir as correções do patch, use o 3.3.2p1, publicado no mesmo diretório de downloads:

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

O updater faz algumas perguntas. Os padrões atendem à maioria dos casos:

• Shall the script create a ISPConfig backup in /var/backup/ now? yes.
• Reconfigure Permissions in master database? no em servidor único; em multiservidor, só se você mudou algo nas permissões.
• Reconfigure Services? yes, para aplicar as mudanças de Dovecot, rspamd, Apache ou nginx. Use selected se quiser escolher serviço a serviço.
• Create new ISPConfig SSL certificate: no, a não ser que queira trocar o certificado do painel.
• Reconfigure Crontab? yes.

Depois de atualizar: checklist

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

• Link de redefinição de senha: se o painel é acessado por um nome diferente do hostname do servidor, defina interface_base_url em /usr/local/ispconfig/interface/lib/config.inc.php. Sem isso, o link sai com o hostname do servidor.
• Whitelist do IDS: o escopo das entradas (any, user, admin) agora é respeitado. Se você tem security/ids.whitelist.custom, confira que campos editáveis por revendedores usam o escopo user.
• Remetente do sistema: ajuste o Server sender e-mail address se o e-mail do administrador fica fora do servidor.
• Backup sem travas: revise a nova opção em Server Config se seus bancos misturam InnoDB e MyISAM.
• DMARC: ligue a aplicação da política na entrada com calma, acompanhando a quarentena nos primeiros dias.

Problemas conhecidos

O projeto mantém a lista de bugs abertos no GitLab. Consulte antes de atualizar servidores críticos, e registre falhas novas no rastreador de issues. Até aqui, as regressões confirmadas pelo próprio projeto são as cinco corrigidas no 3.3.2p1. O GitLab do ISPConfig fica atrás de uma verificação do Cloudflare, então abra os links no navegador; ferramentas de linha de comando costumam ser bloqueadas.

Resumo

A 3.3.2 é uma atualização de segurança disfarçada de release de recursos. Ubuntu 26.04, DMARC e backup sem travas são bem-vindos, mas o motivo para agendar a janela esta semana é a injeção de SQL na API remota e o Fetchmail, principalmente em servidores com revendedores ou clientes que usam a API. Atualize direto para a 3.3.2p1, faça o backup e passe pelo checklist. Para quem monta o servidor do zero, o guia de ISPConfig no Debian mostra o caminho clássico, e o de Nginx com várias versões de PHP ajuda a entender o que o painel configura por baixo.