Produtos SCADAPack x70 da Schneider Electric enfrentam alerta de credenciais em todas as versões
A Schneider Electric divulgou uma vulnerabilidade de credenciais que afeta sete famílias SCADAPack em todas as versões, embora o Secure Lock tenha sido projetado para proteger funções sensíveis de RTUs. O alerta coloca os Produtos SCADAPack x70 da Schneider Electric sob escrutínio porque os operadores não podem resolver o problema por meio de um patch de firmware convencional.
O CVE-2026-81861 envolve o Secure Lock, um mecanismo legado de senha usado para restringir o acesso a funções de unidades terminais remotas. A Schneider recomenda substituir esse mecanismo por controle de acesso baseado em funções, quando houver suporte. Modelos mais antigos exigem proteções de rede em seu lugar.
Essa diferença é importante. O problema central não é simplesmente se um operador instalou a versão mais recente. É se um controlador implantado ainda depende de um método de proteção cujas credenciais podem ser expostas.
Os equipamentos afetados operam em ambientes industriais distribuídos, incluindo energia, manufatura, água e locais de infraestrutura remota. Esses controladores frequentemente permanecem em operação por anos, tornando uma migração de controle de acesso mais complexa do que a atualização de softwares empresariais comuns.
Produtos SCADAPack x70 da Schneider Electric são afetados em todas as versões
O escopo excepcionalmente amplo transforma uma vulnerabilidade de produto em um problema de descoberta de ativos e configuração.
A CISA publicou seu aviso sobre SCADAPack em 15 de setembro de 2026. Ele identifica o CVE-2026-81861 como uma vulnerabilidade de credenciais insuficientemente protegidas que afeta unidades terminais remotas SCADAPack da Schneider Electric.
Os produtos listados são:
SCADAPack 47x, todas as versões
SCADAPack 47xi, todas as versões
SCADAPack 47xd, todas as versões
SCADAPack 470R, todas as versões
SCADAPack 57x, todas as versões
SCADAPack 3xx, todas as versões
SCADAPack 32, todas as versões
Uma unidade terminal remota, ou RTU, conecta equipamentos de campo a sistemas que monitoram e controlam operações distribuídas geograficamente. Uma RTU pode coletar medições, encaminhar alarmes, executar lógica configurada e receber comandos de uma plataforma de supervisão.
A Schneider publicou sua notificação de segurança inicial em 8 de setembro. A empresa afirmou que não aplicar suas mitigações aumenta o risco de acesso não autorizado por meio do Secure Lock, potencialmente expondo informações confidenciais de configuração da RTU.
O registro CVE classifica o problema como CWE-522, ou credenciais insuficientemente protegidas. Essa categoria abrange informações de autenticação que um sistema armazena ou transmite sem proteção adequada contra recuperação ou uso indevido.
A vulnerabilidade recebeu uma pontuação-base CVSS 4.0 de 5,9, classificada como severidade média. O vetor descreve um ataque pela rede, de baixa complexidade, sem privilégios prévios, com interação ativa do usuário e requisitos adicionais de ataque. Seu impacto técnico avaliado é uma alta perda de confidencialidade, sem impacto direto na integridade ou disponibilidade na pontuação-base.
O aviso da CISA apresenta uma pontuação CVSS v3 de 6,5. Esses números usam versões diferentes de pontuação, portanto os leitores não devem tratar a diferença como uma contradição. Ambas as avaliações descrevem um problema relevante de exposição de credenciais, e não uma falha de execução remota de código sem autenticação.
A vulnerabilidade não constava no catálogo de Vulnerabilidades Conhecidamente Exploradas da CISA quando o aviso foi publicado. Os dados de decisão associados da CISA também relataram que não havia exploração conhecida e classificaram o ataque como não facilmente automatizável.
Esses detalhes reduzem o alarme imediato, mas não eliminam o risco operacional. Uma pontuação-base média não considera a arquitetura, a conectividade remota, a criticidade do processo ou as limitações de recuperação de cada implantação.
A designação de “todas as versões” também exige interpretação cuidadosa. Ela significa que o registro de produtos afetados do fornecedor não identifica uma versão segura dentro dessas famílias de produtos. Não significa que cada controlador instalado apresente exposição idêntica.
A exposição real depende do modo de controle de acesso, do caminho de rede, do modelo do dispositivo e dos controles compensatórios disponíveis. Um controlador isolado que usa controles baseados em funções mais robustos apresenta um risco diferente de um dispositivo gerenciado remotamente que ainda usa Secure Lock.
Essa distinção deve orientar a triagem. Os operadores precisam identificar quais modelos possuem, qual método de controle de acesso cada unidade usa e quais sistemas podem observar ou alcançar seu tráfego de gerenciamento.
Isso vai além de uma descoberta de scanner. Scanners de vulnerabilidades podem reconhecer uma família de produtos ou uma versão de firmware, mas talvez não determinem se o Secure Lock permanece ativo ou se a RTU está protegida por segmentação eficaz.
O Secure Lock protegeu a mensagem, mas não o segredo
A falha questiona o modelo de confiança do Secure Lock, e não os algoritmos criptográficos mencionados em seu projeto.
O pesquisador independente Abhinav Agarwal relatou que a implementação testada protege mensagens do Secure Lock com encapsulamento de chaves AES-128 e um código de autenticação de mensagens HMAC-SHA256. O encapsulamento de chaves AES protege o material de chave, enquanto o HMAC verifica se uma mensagem não foi alterada sem o conhecimento de um segredo.
Segundo a análise técnica do pesquisador, a implementação deriva ambas as proteções de constantes incorporadas ao componente de configuração do Windows e ao firmware da RTU. Seus testes constataram que as chaves resultantes eram idênticas nesses dois componentes.
A consequência é mais específica do que um bypass de autenticação sem senha. Um invasor que capture uma troca relevante do Secure Lock pode, segundo o relato, recuperar a senha off-line. A recuperação off-line significa que o invasor analisa o tráfego registrado sem consultar repetidamente o dispositivo-alvo.
O pesquisador testou mensagens de definição, alteração e desbloqueio de senha. Ele relatou que a troca protegida não tinha uma entrada por dispositivo ou por sessão, deixando as instalações testadas dependentes de material criptográfico compartilhado.
Um valor por dispositivo faria a chave derivada de uma unidade ser diferente da chave de outra unidade. Um valor por sessão tornaria o material capturado menos reutilizável em trocas separadas. O pesquisador não encontrou nenhuma dessas propriedades no caminho testado.
O mecanismo divulgado, portanto, cria uma inversão desconfortável. O Secure Lock criptografa e autentica suas mensagens, mas a confiança depositada em segredos incorporados e compartilhados enfraquece essas proteções.
Algoritmos robustos não podem compensar uma chave que é efetivamente comum a várias instalações. Se um adversário puder derivar as mesmas chaves de encapsulamento e autenticação, o envelope criptográfico deixa de fornecer a separação esperada.
A senha testada controla funções importantes. O pesquisador afirma que essas funções incluem gravações de configuração, execução de comandos, atualizações de firmware, alterações de segurança e acesso a determinados serviços de transferência de arquivos ou terminal.
No entanto, recuperar uma senha não equivale a controlar imediatamente uma RTU. Um invasor ainda precisa observar uma troca qualificadora do Secure Lock e ter um caminho de rede para acesso posterior.
O vetor CVSS divulgado reflete essas condições por meio de “requisitos de ataque presentes” e “interação do usuário ativa”. Um administrador legítimo precisa executar uma ação afetada, como definir ou usar a senha, antes que um observador passivo possa obter tráfego útil.
O invasor também precisa ter visibilidade dessa troca. Essa visibilidade pode decorrer de uma intrusão prévia na rede, de acesso a um caminho de comunicação segmentado de forma inadequada ou de monitoramento a partir de outra posição dentro da rede operacional.
O pesquisador testou explicitamente um suposto caminho de desbloqueio sem senha e relatou que ele não funcionou. Esse resultado limita a alegação. O CVE-2026-81861 envolve exposição de credenciais e uso não autorizado subsequente, não um bypass universal de um único pacote.
Seus testes públicos também cobriram artefatos específicos de software e firmware. Ele identificou o SCADAPack x70 Device DTM versão 2.0.18103.4 do RemoteConnect R3.5.5 e uma imagem específica de firmware 47x.
Um gerenciador de tipo de dispositivo, ou DTM, é um componente de software que permite a uma ferramenta de engenharia configurar e comunicar-se com um dispositivo industrial específico. Neste caso, o DTM testado participa do fluxo de trabalho do Secure Lock.
A declaração de produtos afetados da Schneider é mais ampla do que os testes diretos do pesquisador. O fornecedor lista sete famílias de produtos e todas as versões, incluindo dispositivos SCADAPack 3xx e 32 mais antigos.
Esse escopo mais amplo é determinante para o planejamento de remediação, mas a diferença deve permanecer visível. O pesquisador estabeleceu o mecanismo em artefatos de teste definidos, enquanto a Schneider ampliou o status de afetado por todo o seu portfólio de produtos.
Portanto, os operadores devem evitar dois erros opostos. Não devem restringir a remediação à compilação exata testada, mas também não devem afirmar que todos os dispositivos foram demonstrados de forma independente em todas as configurações possíveis.
A migração para RBAC substitui a correção de firmware ausente
A resposta principal da Schneider altera a arquitetura de controle de acesso em vez de reparar o Secure Lock no local.
Para dispositivos SCADAPack 47x e 470R compatíveis, a Schneider recomenda implementar o controle de acesso baseado em funções, ou RBAC. O RBAC atribui permissões a funções e usuários definidos, em vez de depender de uma senha compartilhada de bloqueio do dispositivo.
A empresa orienta os administradores a consultar sua documentação de segurança, incluindo as seções que abordam orientações para administradores e a operação do RBAC. Seu guia mais amplo de cibersegurança descreve gerenciamento de contas, zoneamento de rede, firewalls, comunicações seguras e práticas de auditoria para implantações SCADAPack.
A Schneider caracteriza o Secure Lock como uma funcionalidade legada mantida para compatibilidade retroativa. Ela recomenda o RBAC como o mecanismo preferencial de controle de acesso para produtos compatíveis.
Essa orientação significa que a resposta imediata não é “instale a versão X”. A Schneider não identificou uma versão de firmware corrigida que preserve o Secure Lock e elimine o CVE-2026-81861.
Para controladores mais novos e compatíveis, a migração exige mais do que selecionar uma senha mais forte. Os administradores precisam migrar de um fluxo de bloqueio compartilhado para usuários nomeados, funções atribuídas e permissões gerenciadas.
Essa transição pode melhorar a responsabilização. Uma senha compartilhada informa a um operador se alguém conhecia o segredo, mas não identifica de forma confiável quem executou uma ação. Contas nomeadas e funções podem restringir privilégios e fortalecer a auditoria.
A migração também introduz trabalho. Os operadores devem definir funções administrativas, provisionar contas, testar o acesso a partir de ferramentas de engenharia, atualizar procedimentos e confirmar que a manutenção de emergência permaneça possível.
Organizações que usam diretórios centralizados talvez precisem validar dependências entre o ambiente da RTU e a infraestrutura de identidade. Também devem considerar como os locais remotos se comportam quando serviços de diretório ou conexões de longa distância não estão disponíveis.
Mudanças em controles industriais exigem testes cuidadosos porque um erro de autenticação pode bloquear o acesso de engenharia autorizado. Uma migração apressada pode criar um problema operacional mesmo enquanto reduz o risco cibernético.
Por esse motivo, os operadores devem documentar os caminhos de acesso atuais antes de alterá-los. O registro deve incluir estações de trabalho de engenharia, conexões de suporte remoto, contas de serviço, procedimentos locais de recuperação e opções de acesso físico.
As famílias SCADAPack 57x, 3xx e 32 mais antigas representam um caso mais difícil. As orientações de mitigação da Schneider enfatizam a segmentação de rede e o firewall da RTU porque esses dispositivos não oferecem o mesmo caminho de migração para RBAC.
A segmentação de rede separa os sistemas em zonas controladas e restringe a comunicação entre elas. Um firewall de RTU aplica regras que limitam quais hosts, protocolos ou serviços podem alcançar o controlador.
Esses controles não corrigem o mecanismo de proteção de credenciais. Eles reduzem o número de sistemas capazes de observar uma troca Secure Lock ou reutilizar credenciais expostas.
Os operadores devem limitar o tráfego de gerenciamento a estações de engenharia aprovadas e caminhos confiáveis de administração. Também devem eliminar a exposição direta à internet e impedir que endpoints corporativos comuns alcancem os serviços de gerenciamento da RTU.
As orientações sobre exposição da CISA recomendam identificar ativos industriais acessíveis pela internet, remover exposições desnecessárias, usar hosts de salto monitorados e adicionar autenticação multifator sempre que possível.
Um host de salto é um intermediário controlado que os administradores devem usar antes de acessar dispositivos sensíveis. Ele pode concentrar registros, autenticação e restrições de acesso em um ponto onde equipamentos de campo mais antigos não possuem esses recursos.
Redes privadas virtuais podem proteger o tráfego que atravessa infraestrutura não confiável. No entanto, uma VPN não deve criar acesso irrestrito de um laptop remoto a toda uma rede de controle.
A abordagem mais restrita é melhor. Usuários remotos devem se autenticar em um serviço de acesso monitorado, alcançar somente os ativos necessários e receber apenas as permissões exigidas para uma tarefa definida.
O monitoramento de tráfego também importa porque a exposição de credenciais depende da observação de uma troca. Os operadores devem investigar tráfego inesperado de Terminal Virtual DNP3, atividade incomum de desbloqueio, acessos repetidos à configuração ou novas comunicações entre zonas de engenharia e sites remotos.
DNP3 é um protocolo amplamente usado para comunicação entre centros de controle e dispositivos de campo. Sua função de Terminal Virtual fornece um canal que as aplicações podem usar para interações orientadas a dispositivos, incluindo as mensagens Secure Lock descritas pelo pesquisador.
Alterar apenas uma senha Secure Lock não é uma resposta duradoura. Se a senha substituta posteriormente trafegar pelo mesmo mecanismo vulnerável, um observador capaz poderá recuperar o novo segredo a partir de outra troca capturada.
O objetivo prático é deixar de depender do fluxo de trabalho afetado. Onde a migração não estiver disponível, os operadores devem tornar a observação e a reutilização substancialmente mais difíceis por meio de controles de rede em camadas.
Uma Pontuação Média Pode Ocultar uma Remediação Difícil de OT
O impacto direto limitado da vulnerabilidade não mede o esforço necessário para proteger implantações de campo de longa duração.
CVE-2026-81861 não tem o perfil de um comprometimento imediato de sistema de segurança. Seu vetor-base não atribui impacto direto à integridade ou à disponibilidade, e não havia evidências públicas de exploração ativa no momento da divulgação.
Essas limitações importam. As equipes de segurança não devem descrever o problema como manipulação comprovada de processos, interrupção automática de instalações ou execução de código sem autenticação.
O impacto identificado é a perda de confidencialidade envolvendo informações de autenticação. O acesso não autorizado à RTU pode ocorrer em seguida, mas a exploração ainda depende das condições de rede e da atividade dos administradores.
Ao mesmo tempo, uma classificação de severidade média pode subestimar a complexidade operacional. Os Produtos Schneider Electric SCADAPack x70 são projetados para monitoramento e controle remotos, frequentemente em locais com equipe local limitada.
Uma aplicação corporativa muitas vezes pode receber correções de forma centralizada. Controladores de campo podem exigir acesso agendado, aprovação operacional, testes especializados e coordenação com as equipes responsáveis pelos processos físicos.
A lista de produtos afetados também abrange equipamentos atuais e legados. Algumas unidades podem adotar RBAC. Outras precisam depender de segmentação, filtragem e arquitetura de acesso remoto seguro.
Isso divide o programa de remediação em trilhas diferentes. Um único ticket de vulnerabilidade não consegue representar com precisão o trabalho em todos os modelos e sites.
A primeira trilha abrange implantações compatíveis das séries 47x e 470R. As equipes devem confirmar o uso de Secure Lock, projetar funções RBAC, testar fluxos de trabalho administrativos e descontinuar o modo legado.
A segunda abrange implantações das séries 57x, 3xx e 32. As equipes devem validar regras de firewall, reduzir serviços acessíveis, isolar caminhos de gerenciamento e monitorar o tráfego porque a substituição preferida de controle de acesso não está disponível.
Uma terceira trilha pode ser necessária para dispositivos que não conseguem atender ao limite de risco residual da organização. Essas unidades podem exigir planejamento de substituição, especialmente quando sua posição na rede não pode ser suficientemente restringida.
A qualidade do inventário de ativos torna-se decisiva. Uma organização não pode migrar ou isolar controladores que não identificou, e os rótulos de produtos nos registros de manutenção podem não corresponder à nomenclatura usada no aviso.
As equipes devem reconciliar bancos de dados de engenharia, observações de rede, registros de compras e documentação dos sites. Devem registrar o modelo exato, firmware, modo de acesso configurado, caminho de comunicação e responsável designado.
A configuração importa tanto quanto a versão. Como todas as versões listadas são afetadas, um scanner baseado apenas em versão pode produzir um grande conjunto de resultados sem identificar quais sistemas realmente usam Secure Lock.
Isso não torna o escaneamento inútil. Significa que a saída do scanner deve iniciar uma investigação, em vez de concluí-la.
A prova de conceito pública também merece tratamento equilibrado. O pesquisador divulgou um verificador sanitizado que demonstra a derivação de chaves sem publicar os segredos completos recuperados.
Essa contenção reduz o uso indevido imediato, mas o detalhe técnico público ainda altera o cronograma defensivo. Outros pesquisadores ou invasores podem examinar o método e tentar reproduzi-lo de forma independente.
O status de “nenhuma exploração conhecida” da CISA é um retrato momentâneo, não uma previsão. Os defensores devem monitorar alterações no registro CVE, no catálogo da CISA, na notificação da Schneider e na inteligência de ameaças voltada a redes industriais.
A ausência de uma correção também altera o significado de encerramento. Uma plataforma de gerenciamento de vulnerabilidades pode continuar sinalizando todas as versões afetadas mesmo depois que um operador implementa RBAC ou segmentação eficaz.
As organizações precisam de exceções baseadas em evidências ou registros de controles compensatórios. Caso contrário, os painéis de segurança podem mostrar achados não resolvidos sem diferenciar implantações expostas de Secure Lock de sistemas migrados.
Esses registros não devem se tornar substitutos permanentes de burocracia. Cada exceção precisa de um responsável pelo controle definido, método de validação, data de revisão e gatilho de substituição.
A questão também ilustra por que o CVSS não pode ser o único método de priorização em tecnologia operacional. O CVSS mede a severidade intrínseca da vulnerabilidade, enquanto os operadores precisam acrescentar criticidade do processo, exposição de rede, capacidade de recuperação e possíveis consequências físicas.
Uma vulnerabilidade média em um controlador de teste isolado pode ficar abaixo de uma falha crítica em uma aplicação corporativa. A mesma vulnerabilidade em uma RTU administrada remotamente com segmentação fraca pode exigir ação mais rápida.
As equipes de risco devem, portanto, combinar a pontuação publicada com evidências específicas do site. Perguntas úteis incluem se o tráfego de gerenciamento atravessa redes compartilhadas, se a captura de pacotes é plausível e se o dispositivo controla um processo crítico.
Também devem perguntar se um invasor que recuperasse a senha conseguiria alcançar a interface normal de desbloqueio. A divulgação de credenciais só cria valor quando essa credencial pode ser usada.
Três Sinais Mostrarão se o Risco Está Contido
A próxima fase depende de evidências de migração, atualizações do fornecedor e sinais de que invasores estão passando da pesquisa ao uso operacional.
O primeiro sinal é o ritmo com que os operadores identificam e desativam Secure Lock. As organizações afetadas devem conseguir informar quantos dispositivos usam RBAC, quantos dependem do bloqueio legado e quantas unidades mais antigas dependem de controles compensatórios.
Uma taxa crescente de migração para RBAC sustentaria a estratégia de mitigação da Schneider. A incerteza persistente sobre os modos de acesso implantados enfraqueceria a confiança, mesmo que nenhum ataque apareça publicamente.
A métrica operacional mais útil não é simplesmente o número de ativos afetados. É a porcentagem com um estado de controle de acesso verificado e remediação testada.
Para dispositivos compatíveis com RBAC, a verificação deve confirmar que Secure Lock deixou de ser a fronteira efetiva de segurança. Também deve mostrar que as funções administrativas operam corretamente e que os procedimentos de emergência permanecem disponíveis.
Para unidades legadas, a verificação deve testar os caminhos de rede permitidos. Uma política de segmentação escrita tem valor limitado se uma estação de trabalho comum ainda consegue se conectar aos serviços de gerenciamento da RTU.
O segundo sinal é se a Schneider emite orientações revisadas, detalhes técnicos ampliados ou uma atualização de produto. A resposta inicial depende de mitigação arquitetural, em vez de uma implementação corrigida de Secure Lock.
Uma alteração posterior de firmware ou ferramentas mudaria o cenário de remediação. Ela poderia fornecer um auxílio à migração, remover o comportamento vulnerável, melhorar os registros ou restringir as configurações afetadas.
Por outro lado, a dependência contínua de controles compensatórios confirmaria que os operadores devem tratar isso como uma questão arquitetural de longo prazo. Isso aumentaria a pressão para substituir dispositivos legados que não conseguem suportar controles de acesso mais fortes.
As equipes de segurança devem monitorar a notificação do fornecedor em vez de depender apenas de resumos copiados do aviso. Os avisos de produtos podem mudar à medida que os testes se ampliam ou que as etapas de mitigação se tornam mais precisas.
O terceiro sinal é evidência de exploração ou reprodução mais ampla. Na divulgação, a CISA informou que não havia exploração conhecida, e CVE-2026-81861 estava ausente do catálogo de Vulnerabilidades Conhecidas Exploradas.
Essa posição mudaria materialmente se os defensores encontrassem atividade de recuperação de credenciais, tentativas não autorizadas de desbloqueio ou ferramentas que automatizam a análise de tráfego. A inclusão no catálogo forneceria outro forte sinal de escalonamento.
A reprodução pública por si só não provaria ataques contra instalações em operação. Ainda assim, reduziria a incerteza técnica enfrentada por um adversário e aumentaria o valor do tráfego Secure Lock capturado.
Os operadores devem preservar agora os registros relevantes e a telemetria de rede. Esperar por um relatório de exploração pode deixar os investigadores sem os dados históricos necessários para determinar se trocas sensíveis foram observadas anteriormente.
O monitoramento deve se concentrar na atividade de administração, não apenas em alarmes de processo. Acesso à configuração, alterações de senha, operações de desbloqueio, novos hosts de engenharia e sessões remotas incomuns podem revelar um problema de controle de acesso antes que as operações físicas mudem.
Os Produtos Schneider Electric SCADAPack x70 continuam sendo plataformas de campo úteis, e o aviso não estabelece que sites implantados foram comprometidos. Ele estabelece que cada versão listada exige uma revisão no nível da configuração.
A pergunta imediata para os proprietários dos ativos é concreta: a organização consegue provar quais controladores ainda usam Secure Lock, quem pode observar seu tráfego de gerenciamento e qual controle agora existe entre uma senha exposta e o acesso à RTU?
Comece com esse inventário e, em seguida, migre os dispositivos compatíveis para RBAC. Isole os modelos que não podem migrar, teste suas regras de firewall e monitore todos os caminhos aprovados de administração. A vulnerabilidade não pode ser gerenciada apenas pela verificação de versões.
