mySCADA myPRO Manager Corrige Duas Falhas de Autenticação, Uma Classificada como Crítica
O mySCADA myPRO Manager enfrenta agora duas falhas de segurança divulgadas, incluindo uma com classificação 9,8, porque interfaces sensíveis aceitavam solicitações sem autenticação. As versões 2.1 e anteriores são afetadas. A versão 2.2 contém as correções do fornecedor.
A vulnerabilidade mais grave expõe funções privilegiadas de gerenciamento por meio da API de comandos do produto. A segunda expõe um endpoint HTTP capaz de enviar mensagens de texto arbitrárias por um modem GSM conectado. Nenhum dos dois caminhos exige uma conta autenticada antes de aceitar a solicitação relevante.
Isso cria um conflito evidente entre o gerenciamento industrial conveniente e o controle básico de acesso. O myPRO Manager ajuda operadores a configurar ambientes conectados, mas as interfaces vulneráveis não verificavam quem emitia comandos sensíveis. O problema vai além de uma aplicação web comum porque os produtos mySCADA parecem estar presentes em ambientes de tecnologia operacional no mundo todo.
A resposta imediata é clara. Os operadores precisam localizar instalações afetadas, atualizá-las e verificar quais redes conseguem acessar suas interfaces de gerenciamento. O trabalho mais difícil começa depois, especialmente em sistemas isolados, instalações não gerenciadas e ambientes em que o tempo de inatividade complica as atualizações.
O Que Mudou no mySCADA myPRO Manager
A divulgação identifica duas falhas de autorização distintas, mas a vulnerabilidade da API de comandos traz o maior risco operacional.
Em 15 de setembro de 2026, a CISA publicou um aviso industrial sobre o mySCADA myPRO Manager. Ele identifica CVE-2026-73807 e CVE-2026-82567 nas versões 2.1 e anteriores.
A versão 2.2 é listada como não afetada. A mySCADA Technologies afirma que essa versão corrige ambos os problemas e recomenda a atualização para a versão mais recente disponível.
A CVE-2026-73807 diz respeito à API de comandos, ou seja, à interface usada por componentes de software para emitir solicitações de gerenciamento. Segundo o registro oficial, a API não aplica adequadamente a autenticação para funções privilegiadas.
Um invasor não precisa de uma conta existente. Ele precisa de acesso de rede à interface afetada e então pode tentar invocar funções normalmente reservadas a um administrador autorizado.
O registro CVE atribui à falha uma pontuação CVSS 3.1 de 9,8, dentro da faixa crítica. Seu vetor descreve uma vulnerabilidade acessível pela rede, com baixa complexidade de ataque, sem privilégios necessários e sem interação do usuário.
O registro também atribui uma pontuação CVSS 4.0 de 9,3. Ambas as avaliações indicam alto impacto potencial sobre confidencialidade, integridade e disponibilidade no sistema vulnerável.
Essa pontuação não estabelece que todas as instalações estejam igualmente expostas. O CVSS mede a gravidade técnica sob premissas padronizadas. Ele não sabe se uma API de comandos específica está atrás de vários firewalls ou acessível por uma rede não confiável.
A CVE-2026-82567 afeta o gateway de notificações, que conecta o myPRO Manager à entrega de SMS por meio de um modem GSM. O endpoint HTTP vulnerável aceita um número de telefone e uma mensagem e então instrui o modem a enviar esse texto.
O endpoint não exige autenticação antes disso. Portanto, um invasor com acesso de rede adequado pode enviar destinatários e mensagens arbitrários pelo modem conectado.
Essa segunda vulnerabilidade tem uma pontuação CVSS 3.1 de 6,3, classificada como média. Seu vetor usa um caminho de ataque por rede adjacente, em vez do caminho de rede mais amplo atribuído à CVE-2026-73807.
Essa distinção importa. A falha de SMS geralmente exige que o invasor alcance a rede local ou adjacente relevante. A falha crítica da API de comandos tem uma classificação de ataque em rede mais ampla.
Ambos os problemas compartilham a mesma fraqueza subjacente, porém. Uma operação sensível aceita dados antes de estabelecer se o solicitante tem permissão para executá-la.
A CISA atribui as descobertas aos pesquisadores da SECNORA Rajivarnan R. e Shirshak. As vulnerabilidades foram descobertas externamente e coordenadas por meio do processo de divulgação de sistemas de controle industrial da agência.
O aviso inclui implantações afetadas em manufatura crítica, energia, alimentos e agricultura, transporte, água e águas residuais. Ele descreve a implantação como mundial e lista a sede do fornecedor na Tchéquia.
Esses rótulos de setor não comprovam que todas as instâncias afetadas controlem diretamente um processo físico. Eles mostram por que uma lacuna de autenticação nesse produto merece atenção cuidadosa das equipes de tecnologia operacional.
Por Que a Falta de Autenticação Importa Mais em Redes Industriais
Uma solicitação que chega a uma interface de gerenciamento industrial pode ter consequências muito além do processo de software que a recebe.
A autenticação responde a uma pergunta básica: quem está fazendo esta solicitação? A autorização responde à pergunta seguinte: o que essa identidade está autorizada a fazer?
A CVE-2026-73807 rompe essa fronteira em torno de funções privilegiadas de gerenciamento. A descrição oficial não enumera todas as funções expostas, portanto os defensores não devem presumir um resultado específico além do acesso documentado.
Ainda assim, “funções privilegiadas de gerenciamento” sinaliza uma falha significativa de confiança. Uma interface projetada para administração aceitava solicitações de rede sem aplicar o controle que deveria separar administradores de outros sistemas.
O vetor CVSS reflete essa preocupação. Ele presume ausência de privilégios, ausência de interação do usuário, baixa complexidade e potencial alto impacto sobre confidencialidade, integridade e disponibilidade.
Em um site corporativo, uma falha de controle de acesso pode expor dados ou configurações da aplicação. Em um ambiente de tecnologia operacional, o software de gerenciamento pode estar próximo de sistemas que monitoram equipamentos, coletam dados de processo, distribuem alarmes ou apoiam decisões de operadores.
A consequência exata depende de cada implantação. O desenho da rede, os equipamentos conectados, a configuração do produto e as funções expostas moldam o risco real.
Essa variabilidade torna o contexto dos ativos essencial. Uma instalação de laboratório desconectada não apresenta a mesma exposição que um gerenciador de produção acessível a partir de um segmento corporativo compartilhado.
Uma instalação exposta à internet representa um caso ainda mais urgente. Embora o aviso não publique uma contagem de sistemas expostos, qualquer acesso direto não confiável remove uma barreira defensiva importante.
A fraqueza de SMS apresenta um impacto mais restrito, mas ilustra o mesmo problema arquitetural. Os gateways de notificação frequentemente transportam alertas operacionais nos quais os usuários devem confiar.
Um invasor que envie mensagens arbitrárias por um modem conhecido poderia causar confusão, se passar por notificações rotineiras ou consumir capacidade de mensagens. O registro oficial não afirma que invasores possam ler mensagens existentes ou reconfigurar o modem.
Os defensores devem preservar essa distinção. A capacidade divulgada é a transmissão não autorizada de SMS, não o controle comprovado de todas as funções de notificação.
Ainda assim, mensagens arbitrárias podem importar durante um incidente. Os operadores podem depender de alertas de texto quando estão longe de uma sala de controle ou quando outro canal de comunicação falha.
Uma mensagem fraudulenta pode ser confundida com um alerta legítimo do sistema. Uma sequência de mensagens indesejadas também pode dificultar o reconhecimento de notificações reais.
Esses cenários são considerações razoáveis de risco, não relatos documentados de exploração. O aviso estabelece o caminho de envio não autorizado, enquanto cada organização deve avaliar suas consequências operacionais.
O ambiente industrial também muda a velocidade com que as equipes podem aplicar correções. Ambientes de produção podem exigir interrupções planejadas, testes de compatibilidade, coordenação com fornecedores ou revisão de segurança antes de alterar o software de gerenciamento.
Esses controles reduzem interrupções acidentais, mas podem ampliar o período em que o código vulnerável permanece instalado. Por isso, as restrições de rede importam antes, durante e após o processo de atualização.
Conveniência Colidiu Com o Controle de Acesso
O problema central não é uma cadeia avançada de exploração, mas uma funcionalidade sensível exposta sem uma verificação eficaz de identidade.
As APIs de gerenciamento existem porque a administração manual não escala. Elas permitem que componentes de software, consoles e serviços troquem comandos por meio de solicitações definidas.
Os gateways de notificação oferecem conveniência semelhante. Eles conectam eventos industriais a canais de comunicação, permitindo que o software entregue alertas por meio de um modem GSM.
Ambos os projetos podem ser úteis. Sua segurança depende de tratar toda solicitação recebida como não confiável até que o solicitante comprove uma identidade aceita e receba permissão explícita.
As falhas divulgadas mostram o que acontece quando essa sequência falha. Na API de comandos, um solicitante pode alcançar funcionalidades privilegiadas sem a aplicação esperada de autenticação.
No gateway de notificações, o endpoint HTTP aceita dados de destino e mensagem antes de verificar um usuário autorizado. Em seguida, ele repassa a mensagem solicitada ao modem conectado.
Nenhum dos caminhos documentados exige engenharia social. Nenhum administrador precisa abrir um arquivo malicioso ou aprovar uma solicitação.
Isso não torna a exploração automática. O invasor ainda precisa obter o alcance de rede necessário, identificar a interface e enviar uma solicitação que o serviço aceite.
Esses pré-requisitos explicam por que a arquitetura de rede continua importante. Um serviço vulnerável isolado em uma zona de gerenciamento rigidamente controlada oferece menos caminhos de ataque do que um exposto em amplas redes internas.
No entanto, a segmentação é um controle compensatório, não uma correção para a falta de autenticação. As redes mudam, regras de firewall se acumulam, caminhos de acesso remoto se expandem e dispositivos internos comprometidos podem contornar suposições sobre locais confiáveis.
O projeto mais seguro combina camadas. A aplicação autentica cada solicitação sensível, a autorização limita as ações disponíveis e a rede restringe quais sistemas podem alcançar a interface.
Os registros devem então registrar atividades aceitas e rejeitadas. O monitoramento deve identificar comandos incomuns, endereços de origem inesperados e destinos irregulares de SMS.
A CVE-2026-73807 e a CVE-2026-82567 importam porque enfraquecem a camada de aplicação desse modelo. A versão 2.2 restaura a correção de software compatível com o fornecedor, enquanto os controles de rede reduzem a exposição ao seu redor.
O contraste também explica a diferença de gravidade. O problema da API de comandos é pontuado por efeitos potencialmente altos nas três propriedades centrais de segurança do sistema vulnerável.
O endpoint de SMS recebe classificações de impacto mais baixas e uma classificação de rede adjacente. Seu resultado documentado se limita ao envio de mensagens arbitrárias por um modem conectado.
Tratar ambas as descobertas como idênticas obscureceria as prioridades de remediação. Ignorar o problema com pontuação mais baixa deixaria passar um caminho prático de abuso por um canal de notificação confiável.
As equipes devem, portanto, priorizar a exposição crítica da API de comandos enquanto resolvem ambas as vulnerabilidades por meio da mesma atualização. Um único limite de versão simplifica a decisão de software, mesmo que o trabalho de implantação permaneça complicado.
O fornecedor afirma que dispositivos conectados notificam os usuários no mySCADA Pro Manager quando uma nova versão está disponível. Ambientes offline exigem que os operadores obtenham a atualização separadamente na página de download do manager.
Os sistemas offline merecem atenção especial. Seu isolamento pode reduzir a exposição, mas também elimina notificações automáticas de atualização e pode ocultar softwares desatualizados das ferramentas centralizadas de inventário.
Um air gap nunca deve substituir a consciência sobre versões. Mídias portáteis, conexões temporárias de manutenção, laptops e roteamento mal configurado podem criar caminhos que não existiam no projeto original.
A Correção É Clara, mas o Risco de Implantação Permanece
A versão 2.2 elimina a lacuna de software documentada, mas as organizações ainda precisam de evidências de que cada instalação afetada alcançou o estado corrigido.
A correção do fornecedor é simples: atualize o mySCADA myPRO Manager para a versão 2.2 ou posterior. A faixa afetada termina na versão 2.1.
Essa clareza elimina uma fonte comum de confusão. As equipes não precisam comparar vários patches entre diferentes ramificações para essas duas CVEs.
O desafio operacional é o inventário. As organizações precisam identificar onde o produto é executado, qual versão cada instalação utiliza e quais interfaces são acessíveis em cada zona de rede.
Essa tarefa pode revelar lacunas não relacionadas ao novo alerta. Softwares industriais podem estar em estações de trabalho de engenharia, sistemas dedicados de gerenciamento, dispositivos temporários de comissionamento ou máquinas mantidas fora dos processos corporativos normais.
Um inventário confiável deve incluir a versão da aplicação, a identidade do host, a localização na rede, o responsável pelo sistema, a função operacional e os caminhos de comunicação permitidos. Também deve registrar se há um modem GSM conectado.
O detalhe sobre o modem determina se o caminho de SMS documentado existe em uma determinada implantação. Uma instalação sem esse componente não apresenta o mesmo cenário prático da CVE-2026-82567.
A API de comandos exige uma análise separada. As equipes devem identificar todas as origens autorizadas a acessá-la e verificar se algum caminho parte de redes de usuários, segmentos sem fio, sistemas de acesso de fornecedores ou da internet pública.
Uma regra de firewall, por si só, não comprova isolamento. Testes de fluxo de pacotes e revisão de configuração oferecem evidências mais robustas de que apenas os sistemas de gerenciamento pretendidos podem se conectar.
Antes da atualização, os operadores devem confirmar os procedimentos de backup e recuperação. Também devem compreender dependências que poderiam falhar caso o gerenciador mude de comportamento após a atualização.
Os testes devem se concentrar nas operações normais de gerenciamento, entrega de alertas, notificações por SMS, autenticação e conectividade com sistemas gerenciados. O objetivo é encontrar problemas de compatibilidade antes da implantação em produção.
As equipes devem então registrar a versão instalada após a mudança. Uma notificação de atualização ou um instalador baixado não prova que todos os hosts concluíram a atualização com sucesso.
Quando a aplicação imediata do patch for impossível, a redução da exposição se torna urgente. O acesso às interfaces de gerenciamento deve ser limitado a sistemas explicitamente autorizados por meio de firewalls e zonas de rede segmentadas.
A administração remota deve utilizar caminhos de acesso controlados, em vez de expor a aplicação diretamente. As orientações estabelecidas da CISA para ambientes industriais recomendam minimizar a exposição, separar redes de controle de redes corporativas e usar métodos seguros de acesso remoto.
Sua orientação de defesa em profundidade trata arquitetura de rede, controle de acesso, monitoramento e resposta a incidentes como salvaguardas complementares. Nenhuma delas deve ser considerada uma substituição permanente para o software corrigido.
Os controles temporários devem ter responsáveis e datas de expiração. Caso contrário, uma restrição emergencial de firewall pode silenciosamente se tornar a resposta de longo prazo enquanto a versão vulnerável continua instalada.
O monitoramento também precisa de sinais específicos para cada implantação. As equipes podem revisar conexões com a API de comandos, eventos de autenticação rejeitada após a atualização e solicitações incomuns aos endpoints de notificação.
Para sistemas habilitados para SMS, os operadores devem comparar a atividade do modem com os alertas esperados. Números de destino não reconhecidos, conteúdo incomum das mensagens e frequência anormal de envio merecem investigação.
Logs históricos podem ajudar a determinar se ocorreu atividade suspeita antes da correção. No entanto, a ausência de uma entrada de log não pode estabelecer que nenhuma tentativa ocorreu se o endpoint vulnerável não possuía registros adequados.
As equipes de resposta a incidentes devem preservar registros relevantes de rede, host, aplicação e modem. Se uma atividade parecer suspeita, devem seguir os procedimentos estabelecidos de escalonamento e comunicação.
O alerta não fornece uma narrativa pública de exploração. Isso limita o que os defensores podem concluir sobre o comportamento dos atacantes, suas ferramentas ou vítimas observadas.
Isso não reduz a gravidade técnica de um caminho de gerenciamento sem autenticação. A exposição e o impacto sobre a missão devem determinar a velocidade da resposta de cada organização.
mySCADA Já Enfrentou Descobertas Anteriores de Alta Gravidade
As novas falhas fazem parte de um padrão mais amplo no qual recursos de gerenciamento se tornam limites de segurança que os atacantes podem testar diretamente.
A CISA publicou alertas anteriores envolvendo produtos mySCADA. Esses casos não provam uma causa técnica compartilhada, mas fornecem contexto útil para os defensores.
Em 2022, a CISA descreveu uma vulnerabilidade de injeção de comandos no mySCADA myPRO versões 8.26.0 e anteriores. Um usuário autenticado podia modificar parâmetros e executar comandos do sistema operacional.
Esse problema anterior do myPRO recebeu uma pontuação CVSS 3 de 9.9. O fornecedor recomendou atualizar para a versão 8.27.0 ou posterior.
A falha da API de comandos de 2026 difere de forma crucial. Seu vetor publicado não exige privilégios, enquanto o problema de 2022 exigia um usuário autenticado.
Os produtos e esquemas de versionamento também diferem nos registros, portanto os operadores não devem inferir um caminho direto de atualização entre esses alertas. Cada instalação afetada deve ser comparada com as informações específicas de produto e versão.
Um alerta separado de 2025 abordou várias vulnerabilidades do myPRO Manager, incluindo injeção de comandos do sistema operacional. Esse histórico reforça a necessidade de tratar componentes de gerenciamento como ativos de alto valor.
A lição não é que um fornecedor seja singularmente vulnerável. Interfaces administrativas em produtos industriais regularmente concentram capacidades valorizadas por atacantes.
Elas expõem configurações, comunicações, credenciais, atualizações ou conexões com ambientes controlados. Portanto, a ausência de um único controle pode comprometer várias salvaguardas posteriores.
É por isso que a gestão de vulnerabilidades deve acompanhar produtos por função, e não apenas pela contagem de CVEs. Um servidor de gerenciamento merece prioridade porque sua função pode ampliar o impacto de uma invasão.
O mesmo raciocínio se aplica a dispositivos de acesso remoto, estações de trabalho de engenharia, historiadores de dados e gateways de notificação. Sua proximidade com as operações dá às falhas comuns de software uma importância maior e dependente do contexto.
As organizações também devem evitar depender inteiramente das pontuações em destaque. A CVE-2026-82567 tem pontuação média, mas sua exploração ainda poderia interromper o processo confiável de alertas de uma instalação.
Por outro lado, uma pontuação de 9.8 não prova que uma instância isolada possa ser atacada pela internet. Ela sinaliza características técnicas graves quando um atacante alcança o serviço vulnerável.
Uma priorização eficaz combina gravidade, exposição, explorabilidade, função operacional e dificuldade de recuperação. Também considera se há uma versão corrigida prontamente disponível.
Neste caso, a versão corrigida existe. Isso torna cada vez mais difícil justificar o uso prolongado da versão 2.1 ou anterior, a menos que uma limitação operacional impeça a implantação.
Se tal limitação existir, a gestão deve documentá-la. O registro deve nomear o responsável, explicar a dependência, listar os controles temporários e definir a próxima data de revisão.
Isso transforma o atraso na aplicação do patch em uma decisão de risco gerenciada. Sem esse processo, o atraso se torna um padrão invisível.
O Que os Operadores Devem Observar em Seguida
Os próximos sinais úteis são cobertura verificada de atualização, evidências de exploração e confirmação de que interfaces sensíveis não estão mais amplamente acessíveis.
Primeiro, as organizações devem medir a adoção da versão 2.2 ou posterior. A métrica interna mais importante não é se um patch foi baixado, mas se cada ativo afetado agora informa uma versão corrigida.
Essa medição deve incluir sistemas fora das ferramentas corporativas normais. Instalações offline, dispositivos gerenciados por contratados e ambientes de teste podem manter versões vulneráveis muito depois de as atualizações de produção serem concluídas.
Um resultado completo reforça a conclusão de que o risco imediato de software foi contido. Ativos não identificados ou inacessíveis enfraquecem essa conclusão.
Segundo, os defensores devem acompanhar fontes confiáveis em busca de mudanças no status de exploração. Novos códigos de prova de conceito, ataques confirmados ou inclusão em um catálogo governamental de exploração alterariam a urgência da resposta.
No momento da publicação, o material disponível do alerta descreve as vulnerabilidades e correções sem estabelecer uma campanha ativa de exploração. Os leitores devem distinguir essa ausência de evidências de que a exploração é impossível.
As informações sobre ameaças podem mudar rapidamente após a divulgação. Os atacantes obtêm um nome claro de produto, a faixa de versões afetadas, a categoria da falha e uma descrição da funcionalidade exposta.
Terceiro, os operadores devem validar a arquitetura ao redor. Atualizar a aplicação não deve encerrar a revisão da exposição das interfaces de gerenciamento.
Uma varredura a partir de zonas de rede apropriadas pode confirmar se a API de comandos e o gateway de notificações aceitam conexões apenas de fontes aprovadas. A revisão do firewall deve produzir a mesma resposta.
Se um segmento amplo ainda puder alcançar esses serviços, o ambiente continuará desnecessariamente exposto a falhas futuras. Um patch fecha vulnerabilidades conhecidas, enquanto a segmentação limita o raio de impacto da próxima vulnerabilidade desconhecida.
As equipes também devem verificar o comportamento da aplicação após a atualização. Comandos sensíveis devem exigir acesso autenticado e autorizado, e o endpoint de SMS deve rejeitar solicitações não autenticadas.
Esses testes devem utilizar procedimentos aprovados em um ambiente controlado. Testes em produção sem coordenação podem criar risco operacional.
As descobertas também justificam uma revisão do desenho de contas e acessos. As organizações devem identificar quem administra o gerenciador, quais contas de serviço interagem com ele e como as credenciais são protegidas.
O princípio do menor privilégio continua importante após a autenticação ser restabelecida. Uma conta válida deve receber apenas as funções necessárias para sua função.
Os registros merecem uma verificação final. As equipes de segurança precisam de detalhes suficientes para associar uma solicitação a uma origem, identidade, ação, resultado e horário.
Para notificações apoiadas por modem, os registros devem relacionar cada mensagem ao evento ou usuário que a iniciou. Isso ajuda a distinguir a automação legítima do uso não autorizado.
A resposta prática ao mySCADA myPRO Manager, portanto, é mais ampla do que instalar uma única versão. Primeiro aplique o patch; depois, verifique a acessibilidade, a imposição de controles de acesso, os registros e a cobertura dos ativos.
Se sua organização utiliza o myPRO Manager, ela consegue provar que cada instalação está na versão 2.2 ou posterior? Também consegue demonstrar que sistemas não confiáveis não podem alcançar interfaces privilegiadas?
Essas duas respostas definem o resultado de curto prazo. Uma atualização confirmada elimina as falhas documentadas. Acesso de rede restrito e autenticação testada reduzem a chance de que a próxima interface negligenciada se torne um incidente operacional.
