Andre Bellafronte

Como o ISPConfig 3.3.2 Corrige Falhas e Muda os Backups

Quem administra servidor com ISPConfig sabe que atualização de painel raramente é só recurso novo. A versão 3.3.2, publicada em 18 de setembro de 2026, corrige duas falhas exploráveis e altera o comportamento padrão do backup de banco de dados.

Duas vulnerabilidades corrigidas

A primeira falha estava na função Fetchmail do módulo de Email, onde os valores de uma conta iam para o arquivo de configuração do getmail sem validação. Isso permitia que um cliente injetasse seções extras de configuração por meio de quebras de linha nos campos da conta, como descrito no anúncio de release da 3.3.2. A correção remove quebras de linha e null bytes dos valores e faz o plugin recusar escrever arquivo que seja symlink ou aponte para fora do diretório do getmail.

A segunda é uma SQL injection nas funções de update e delete da API remota, que deixava um usuário da API modificar ou apagar registros além da própria permissão e ler dados de outras tabelas. O ID do registro agora precisa ser inteiro positivo e as consultas afetadas passam a usar placeholders de parâmetro. Arvin Shivram, da Brutecat Security, reportou a primeira; Nguyen Chi Quang, do MBBank, reportou a segunda.

Ubuntu 26.04 e DMARC de entrada

A versão 3.3.2 adiciona suporte ao Ubuntu 26.04 LTS, incluindo a sintaxe de configuração do Dovecot 2.4 usada nessa distribuição (#6996). Também entra uma opção para forçar regras de DMARC de entrada no rspamd, rejeitando ou colocando em quarentena a mensagem conforme a política publicada pelo domínio remetente (#6995).

Remetente separado nos mails do sistema

Até a 3.3.1p1, o endereço do administrador era remetente e destinatário das notificações ao mesmo tempo, o que gerava problema de SPF quando a caixa dele ficava em outro servidor. O ajuste dividiu a configuração em System > Main Config > Mail: admin_mail recebe as notificações e vira reply, e server_sender_mail é o endereço de envio.

A atualização preenche o campo novo com o e-mail atual do administrador, então instalações existentes só mudam de comportamento quando alguém define outro remetente (#7028). Modelos de mail customizados em conf-custom/mail/ que trazem remetente próprio não são alterados.

Backup sem lock e padrões alterados

O mysqldump trava todas as tabelas enquanto despeja o banco, o que pode deixar um site sem resposta durante toda a execução do backup. A nova opção em System > Server Config > Server, citada nas notas da versão 3.3.2, decide se o dump usa –single-transaction. O padrão Automatic examina os engines e dispensa lock quando todas as tabelas usam engine transacional, como InnoDB, mantendo o lock em bases com MyISAM ou MEMORY (#7049).

Páginas de erro customizadas agora vêm desabilitadas por padrão em sites novos, sem alterar sites existentes (#7021). O link de reset de senha deixou de ser montado a partir do Host header da requisição e passa a usar interface_base_url de interface/lib/config.inc.php (#7044).

Na auditoria de código, CSRF passou a ser exigido em backup, importação de zona DNS e instalação de extensões, a verificação de certificado TLS voltou ao baixar extensões e o session ID é regenerado no login. O escopo user, any ou admin das entradas do whitelist do IDS, que era ignorado, agora é aplicado.

Ainda na lista: quota de tráfego com valor 0 deixou de burlar o limite do cliente (#7024), o DivisionByZeroError nas estatísticas em PHP 8 foi tratado (#7023), a coluna ssh_rsa virou text (#7074) e eu confesso que o backslash sumindo a cada abas salvas (#7042) já deve ter incomodado bastante gente.

Conclusão

A 3.3.2 é uma atualização de correção antes de ser de recurso, com duas vulnerabilidades fechadas e mudança de padrão em backup de banco e endereço de envio. Quem mantém painel exposto deve tratar as duas falhas como prioridade e revisar depois o campo server_sender_mail. Detalhes adicionais estão no changelog publicado pelo projeto.

Fonte: https://www.ispconfig.org/blog/ispconfig-3-3-2-released/
Publicado originalmente em ISPConfig.

Sair da versão mobile