O provisionamento de email reúne dois avisos sobre senhas inseridas em arquivos executados pelo shell. O terceiro descreve uma falha de autorização que permite a membros de uma organização alterar configurações compartilhadas pela instância. Para conferir seu ambiente, compare a versão instalada com a faixa de cada ficha e examine o comportamento específico do recurso afetado.
AplicativoOpenship
Data do compilado
Vulnerabilidades3
As revisões dos mantenedores de 25/09/2026 informam que as três falhas foram corrigidas na branch main, no código examinado do commit a43be96c9c99677c803889cbe183ee9879c785e9. A API mantém os campos patched_versions vazios, portanto as fichas registram a versão de correção como não informada. Essa revisão não confirma que sua instalação recebeu as mudanças.
Gravidade altaCVSS: 8,3/10Correção não informada
Membro da organização consegue alterar configurações globais da instância
A rota PATCH /api/system/settings exige settings:write, uma permissão concedida ao papel member pela autorização descrita no aviso. A escrita, porém, altera o registro compartilhado instance_settings. Essa combinação permite a um membro modificar configurações fora da sua organização, inclusive authMode, que controla a autenticação da instância. O teste publicado confirmou a alteração global de defaultBuildMode usando uma sessão de membro comum.
Casos de uso afetados
Você administra o Openship 0.4.0 com organizações que incluem membros sem autoridade administrativa sobre a instância. A sessão de um desses membros pode alterar configurações compartilhadas por todas as organizações.
Você usa authMode para definir a autenticação do ambiente. A autorização vulnerável permite modificar esse campo por uma rota que verifica uma permissão de configurações da organização.
Confira na sua instância
Examine a autorização de PATCH /api/system/settings na revisão instalada e confirme que a escrita exige o papel administrativo da instância armazenado pelo sistema. Em homologação, execute os testes de instance-admin, instance-global-route e stale-session citados pelos mantenedores. Confira especificamente que uma sessão member recebe recusa de escrita e que instance_settings permanece inalterado. Os testes também devem distinguir a propriedade de uma organização pessoal da administração da instância e recusar tokens administrativos limitados à organização.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
openship (npm)
0.4.0
Não informadas
Os mantenedores informam que o código revisado exige autoridade administrativa da instância nas chamadas HTTP e nativas. A API não informa a versão que inclui essa correção.
Gravidade altaCVSS: 7,4/10Correção não informada
Senha e valores predefinidos permitem executar comandos como root no iRedMail
O instalador recebe o campo config.adminPassword e também valores de config.prefillSecrets, que o Openship insere em atribuições de shell sem escapar as aspas simples. Essas linhas ficam em /root/iRedMail-engine/config. Quando o iRedMail carrega o arquivo com Bash durante a instalação, uma entrada preparada para encerrar a string permite executar comandos como root no servidor de email. Um membro autorizado a configurar email pode, assim, ler mensagens e credenciais ou alterar arquivos do servidor.
Casos de uso afetados
Você mantém uma instalação própria do Openship na faixa <= 0.2.1 e usa o provisionamento antigo do iRedMail. Um membro da organização com mail_server:write no servidor de destino consegue alcançar o campo de senha usado pelo instalador.
Você fornece segredos predefinidos por config.prefillSecrets nesse mesmo fluxo. O aviso confirma que seus valores também chegam às atribuições sem escape, ampliando a conferência para além de adminPassword.
Confira na sua instância
No código correspondente à sua instalação, acompanhe o caminho de config.adminPassword e config.prefillSecrets até stepRunInstaller, em apps/api/src/modules/mail/mail.service.ts. Confira se os valores ainda são interpolados em linhas export e se o instalador carrega /root/iRedMail-engine/config como Bash. Para verificar a implementação descrita pelos mantenedores, examine a escrita do arquivo de ambiente do provisionamento por containers e os testes de mail password-validation e container-mail: os nomes de variáveis devem ser validados, as quebras de linha devem ser recusadas e a pontuação da senha deve permanecer texto, sem avaliação pelo shell.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
oblien/openship
<= 0.2.1
Não informadas
O comunicado exclui o Openship hospedado em CLOUD_MODE, pois o controlador recusa esse provisionamento com resposta 404. A revisão de setembro informa a substituição do caminho vulnerável, mas não identifica uma versão corrigida na API.
Gravidade moderadaCVSS: 5,3/10Correção não informada
Provisionamento de email aceita uma senha que injeta comandos no servidor remoto
A chamada POST /api/mail/setup recebe config.adminPassword sem validação e usa seu conteúdo para gerar DOMAIN_ADMIN_PASSWD_PLAIN no arquivo de configuração do iRedMail. Uma aspa simples pode encerrar a atribuição e introduzir comandos que Bash executa como root ao carregar esse arquivo. A execução acontece no servidor remoto de email, permitindo acesso às mensagens armazenadas e às chaves privadas de TLS, além de alterações que podem interromper o serviço.
Casos de uso afetados
Você utiliza uma versão na faixa < 0.3.1 e permite provisionar servidores de email por POST /api/mail/setup. A exploração descrita exige autenticação e mail_server:write para um servidor da mesma organização.
Durante a instalação do iRedMail, você envia a senha administrativa pelo campo config.adminPassword. No caminho vulnerável, o instalador interpreta o arquivo gerado como código de shell no servidor de destino.
Confira na sua instância
Confira se o provisionamento instalado ainda grava atribuições executáveis em /root/iRedMail-engine/config e inicia o iRedMail com AUTO_USE_EXISTING_CONFIG_FILE=y. Na implementação revisada pelos mantenedores, examine packages/platform/src/engine/modules/mail/mail-engine.ts e packages/adapters/src/system/mail/ensure-container-mail.ts: os segredos devem ser gravados por uma operação de arquivo em um arquivo de ambiente do Docker com permissões 0600. Execute os testes de container-mail para conferir a recusa de valores com múltiplas linhas e de nomes de variáveis inválidos, sem acionar o provisionamento vulnerável em produção.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
oblien/openship
< 0.3.1
Não informadas
Este aviso descreve o mesmo caminho de provisionamento abordado no GHSA-2857-63rf-v9rh, mas declara outra faixa afetada. A classificação moderada e a pontuação 5.3 reproduzem a API, embora a descrição relate execução como root por um membro autenticado. A revisão de setembro informa a correção na main, sem preencher patched_versions.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
