Um fornecedor alemão de alojamento web foi comprometido através da interface que permitia aos clientes ligar assistentes de inteligência artificial ao painel de gestão. A Mittwald CM Service, empresa de alojamento para agências web sediada na Renânia do Norte-Vestefália, revelou num artigo de blogue publicado no sábado que atacantes comprometeram 56 projetos de clientes depois de permanecerem oito dias sem serem detetados nos seus sistemas. A porta de entrada foi um servidor MCP (Model Context Protocol), e a empresa afirma que a velocidade do intruso sugere o recurso a ferramentas de IA, embora não tenha apresentado outras provas dessa hipótese.
Resposta rápida: A Mittwald sofreu uma intrusão através de uma falha no seu servidor MCP, a ponte entre assistentes de IA e a plataforma de gestão mStudio. O atacante extraiu tokens de sessão de utilizadores dessa interface a 27 de outubro e só foi detetado a 4 de novembro; 56 projetos foram comprometidos e todos os tokens foram revogados. Quem usou o servidor MCP deve mudar a palavra-passe do mStudio, ativar a autenticação de dois fatores e rever chaves de API, tokens de projeto e chaves SSH. O caso é um aviso para qualquer organização que esteja a expor painéis de administração a agentes de IA.
O que aconteceu
Segundo o relato publicado pela Mittwald, assinado pelo fundador e diretor-geral Robert Meyer, o ponto de entrada foi o servidor MCP da empresa. A Mittwald disponibilizava um servidor MCP através do qual os clientes podiam ligar um assistente de IA ao mStudio, a interface onde são geridos sítios web, bases de dados e acessos. O MCP é um protocolo aberto que permite a modelos de linguagem invocar ferramentas e aceder a dados de sistemas externos; neste caso, dava a um assistente a capacidade de executar ações administrativas em nome do cliente.
O alvo do atacante não foram as palavras-passe, mas os tokens de sessão. No centro do incidente estão tokens de sessão, não as palavras-passe dos clientes. Estes tokens servem para permitir acessos já autenticados, pelo que um atacante não precisa necessariamente de conhecer a palavra-passe associada. Na prática, um token roubado herda as permissões do utilizador a que pertence, abrindo acesso a todos os projetos que esse utilizador podia gerir. A falha estava no próprio servidor MCP; a Mittwald retirou-o da rede e afirma ter corrigido a vulnerabilidade. Não é claro se a falha residia em código da própria empresa ou em bibliotecas MCP de código aberto. Não foi atribuído, até ao momento, qualquer identificador CVE à vulnerabilidade.
Cronologia do ataque
A cronologia divulgada pela empresa mostra uma preparação cuidadosa, iniciada precisamente no dia em que a comunidade técnica mundial estava concentrada noutro problema. Na noite de 21 de outubro, todo o mundo da TI estava ocupado com o PHP2Shell. Exatamente nessa altura, o atacante testou pela primeira vez uma vulnerabilidade no servidor MCP. A partir de 23 de outubro, movimentou-se como utilizador regular na plataforma, registando contas de teste, utilizando extensões e realizando tentativas simples de injeção. A 27 de outubro, às 14:58, registou mais uma conta, com a qual às 15:03 explorou de forma dirigida a falha encontrada no servidor MCP.
| Data | Evento (segundo a Mittwald) |
|---|---|
| 20–21 out. 2026 | Divulgação pública do PHP2Shell; primeiro teste da falha no servidor MCP na noite de 21 |
| 23 out. 2026 | Atacante atua como utilizador normal: contas de teste, extensões, tentativas de injeção |
| 27 out. 2026 | Exploração dirigida da falha (15:03) e extração de tokens de sessão de utilizadores do MCP |
| 4 nov. 2026 | Monitorização deteta comportamento anómalo; primeira conta do atacante bloqueada; servidor MCP desligado |
| 5 nov. 2026 | Bloqueio preventivo do login no mStudio, de ligações SSH, extensões e encomendas |
| 6 nov. 2026 | Análise forense de 56 projetos comprometidos e do servidor MCP; endurecimento |
| 7 nov. 2026 | mStudio e SSH restabelecidos; sítios suspeitos continuam bloqueados; servidor MCP mantém-se offline |
A 4 de novembro, a monitorização da empresa reconheceu comportamento invulgar e às 11:11 foi bloqueada a primeira conta dos atacantes. As medidas vieram em várias fases: a 5 de novembro, às 11:34, a Mittwald desativou o login no mStudio, terminou todas as ligações SSH e desligou as extensões. De acordo com a página de perguntas frequentes da empresa, o atacante camuflou os preparativos com ações semelhantes a comportamento normal de utilizador, razão pela qual o acesso só foi notado cerca de uma semana depois.
A 7 de novembro, a empresa anunciou o regresso parcial à normalidade. O mStudio voltou a estar acessível e utilizável, os acessos SSH foram igualmente reativados, mas os sítios bloqueados preventivamente continuam, por agora, indisponíveis. Após a avaliação forense dos 56 projetos comprometidos e várias análises aos seus próprios sistemas, a empresa indicou que, à data de sexta-feira, não detetava atividade adicional do atacante. Meyer afirmou ainda que as autoridades competentes foram informadas. O servidor MCP permanece offline até nova indicação e a Mittwald ainda não decidiu se voltará a oferecê-lo, remetendo entretanto os clientes para a sua ferramenta de linha de comandos. Para a semana seguinte, a empresa anunciou uma descrição técnica mais aprofundada do ataque.
IA ou simples automatização? A dúvida que fica
O ponto mais mediático do incidente é a alegação de que o atacante foi auxiliado por inteligência artificial. Nos registos, a empresa diz conseguir reconstituir que o intruso se movimentou de forma extremamente rápida pelo sistema, o que, na sua leitura, aponta para a utilização de ferramentas de IA. Meyer explicou que, em alguns casos, passaram apenas segundos entre passos que demorariam significativamente mais a um atacante humano.
Esta conclusão merece cautela. A Mittwald não forneceu outras provas de envolvimento de IA e não respondeu de imediato quando questionada sobre como distingue a deteção de ferramentas de IA de scripts convencionais, que também permitem a atacantes agir mais depressa do que um operador humano sem apoio. Velocidade entre passos é um indicador fraco: a automatização clássica produz o mesmo efeito nos registos. Até à publicação do relatório técnico prometido, a atribuição a ferramentas de IA deve ser tratada como hipótese da empresa, não como facto estabelecido.
O contexto PHP2Shell
A escolha do momento não parece ter sido casual. Segundo um responsável da empresa, os atacantes escolheram deliberadamente o dia em que a falha foi divulgada. O PHP2Shell designa duas vulnerabilidades críticas no interpretador PHP, CVE-2026-109618 e CVE-2026-109619. Ambas permitem execução remota de código sem autenticação com os privilégios da conta do servidor web e têm classificação CVSS v4.0 de 9.2 (crítica). A 20 de outubro de 2026, os detalhes vazaram nas redes sociais antes da data de divulgação planeada, 22 de outubro. A 21 de outubro, o PHP publicou as versões corrigidas 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Segundo a watchTowr, a exploração ativa foi observada desde 21 de outubro de 2026 através da sua rede global de honeypots, e a 26 de outubro a CISA adicionou a CVE-2026-109618 ao seu catálogo de vulnerabilidades exploradas conhecidas.
Importa sublinhar que o PHP2Shell não foi o vetor do ataque à Mittwald. Serviu antes de cortina de fumo: enquanto as equipas de operações corriam a aplicar correções ao PHP, os primeiros testes à falha do servidor MCP passaram despercebidos. É um padrão que convém reter: dias de crise generalizada são também janelas de oportunidade para ataques a sistemas periféricos.
O que devem fazer os clientes afetados
Segundo a Mittwald, são afetados exclusivamente os clientes que utilizaram o servidor MCP para ligar as suas aplicações mStudio. Cada cliente afetado recebe um e-mail pessoal da empresa. A empresa recorda que nunca pede palavras-passe ou dados de acesso. As recomendações publicadas para quem usou a interface MCP são as seguintes:
- Alterar a palavra-passe do
mStudio, acedendo diretamente ao sítio da Mittwald no navegador e não através de ligações recebidas por e-mail. - Ativar a autenticação de dois fatores; com o regresso do mStudio, passou também a ser possível configurar uma passkey.
- Rever chaves de API, tokens de projeto e chaves SSH, eliminando tudo o que ninguém tenha criado conscientemente, sobretudo utilizadores SSH desconhecidos.
- Renovar credenciais de outros serviços guardadas no projeto, como bases de dados, e-mail ou interfaces externas.
- Informar os restantes utilizadores do projeto e, em caso de reposição de cópias de segurança, registar que alterações desde 27 de outubro têm de ser reaplicadas; a Mittwald só repõe backups após consulta prévia.
Os restantes clientes, segundo o estado atual da investigação, não precisam de fazer nada, embora a empresa recomende a ativação da autenticação de dois fatores. Até ao momento, a empresa não divulgou indicadores de comprometimento técnicos (endereços IP, hashes ou assinaturas), pelo que a deteção por parte dos clientes passa sobretudo pela auditoria de contas, chaves e registos de acesso.
Porque importa em Portugal
A Mittwald tem poucos clientes diretos em Portugal, mas o problema que o incidente expõe é universal. Fornecedores de alojamento, plataformas SaaS e ferramentas internas estão a adicionar servidores MCP e outras integrações com agentes de IA a um ritmo acelerado. Cada uma destas interfaces é uma nova superfície de ataque que, por desenho, recebe instruções em linguagem natural e as traduz em ações privilegiadas. Um token de sessão com permissões amplas, exposto através de uma ponte destas, pode valer tanto como uma palavra-passe de administrador.
Para as PME e agências portuguesas que gerem sítios de clientes em plataformas de terceiros, a lição prática é dupla: inventariar que integrações de IA estão ativas em cada painel de gestão e aplicar a esses acessos o mesmo rigor que se exige a credenciais humanas, com tokens de curta duração, permissões mínimas e autenticação de dois fatores. Para quem desenvolve ou expõe servidores MCP, o caso reforça a necessidade de testes de segurança específicos antes de os colocar em produção.
No plano regulatório, um fornecedor de serviços de alojamento ou de centro de dados a operar em Portugal cai no âmbito do Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), com obrigações de gestão de risco, incluindo a segurança da cadeia de fornecimento, e de notificação de incidentes significativos ao CNCS/CERT.PT em prazos apertados. Um incidente desta natureza, com acesso indevido a projetos de clientes durante oito dias, enquadra-se claramente nesse dever. Além disso, quando os tokens roubados dão acesso a bases de dados ou caixas de correio com dados pessoais, o RGPD impõe a avaliação do risco para os titulares e, se for caso disso, a notificação à CNPD no prazo de 72 horas, tanto pelo fornecedor como subcontratante como pelos clientes enquanto responsáveis pelo tratamento.
Perguntas frequentes
O que é um servidor MCP e porque é que foi explorado?
O Model Context Protocol é um protocolo aberto que permite a assistentes de IA invocar ferramentas e aceder a dados de sistemas externos. Na Mittwald, o servidor MCP dava aos assistentes acesso ao painel de gestão mStudio. Uma falha nessa interface permitiu ao atacante extrair tokens de sessão de outros utilizadores.
As palavras-passe dos clientes foram roubadas?
Segundo a Mittwald, não. O atacante obteve tokens de sessão, que funcionam como passes de acesso já autenticados. Todos os tokens foram revogados, mas a empresa recomenda na mesma a mudança de palavra-passe e a ativação da autenticação de dois fatores a quem usou o servidor MCP.
Está provado que o ataque foi feito com inteligência artificial?
Não. A empresa baseia essa hipótese na velocidade entre passos registada nos logs, mas não apresentou outras provas nem explicou como distingue IA de scripts automatizados convencionais. Um relatório técnico mais detalhado foi prometido para os dias seguintes.
Que relação tem este caso com o PHP2Shell?
O PHP2Shell (CVE-2026-109618 e CVE-2026-109619) não foi o vetor de entrada. Os primeiros testes à falha do servidor MCP ocorreram na noite de 21 de outubro, quando as equipas técnicas estavam concentradas em corrigir o PHP, o que ajudou a que a atividade passasse despercebida.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Mittwald (artigo de blogue) e na sua página de estado, pela watchTowr, pela Sophos e por The Record.