Um aviso recente com uma lista concreta de versões

Em 25 de setembro de 2026, o Centro Canadiano para a Cibersegurança publicou o aviso AV26-963 sobre vulnerabilidades na ServiceNow AI Platform. O seu âmbito prático é claro: os administradores e as equipas de segurança devem identificar a versão da respetiva instância e compará-la com os níveis corrigidos indicados pelo fornecedor. O aviso do organismo canadiano refere informações atualizadas a 24 de setembro. Por si só, não confirma que uma instância específica esteja exposta ou tenha sido comprometida.

O alerta é útil precisamente porque distingue o nome comercial da plataforma das ramificações de versão afetadas. Não basta saber que uma organização utiliza a ServiceNow, nem que o seu ambiente pertence a uma família recente: é necessário verificar a ramificação e a correção aplicada. A decisão operacional depende dessa comparação; as organizações com ambientes alojados, autogeridos ou administrados por terceiros devem confirmar quem aplica a atualização e como a sua instalação é comprovada. Designações de versão semelhantes podem corresponder a percursos de manutenção diferentes, pelo que a comparação deve considerar a ramificação e o hot fix exatos da instância. Também importa ter presente a data do aviso: este descreve o que era conhecido então, não todos os desenvolvimentos posteriores.

Que ramificações devem ser comparadas com as correções

O aviso enumera versões anteriores a três níveis Australia: Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3 e Patch 5. Para Yokohama, define como limite Yokohama Patch 13 Hot Fix 5a. Para Zurich, apresenta três referências distintas: Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32 e Patch 11 Hot Fix 3. A expressão «anteriores a» significa que os administradores têm de comparar a versão exata com o limite correspondente, sem presumir que todas as instalações da mesma família estão corrigidas.

Há uma ressalva importante: o aviso não indica um único número de correção aplicável a todas as ramificações. Além disso, Zurich inclui vários percursos de atualização, pelo que convém não transformar a lista numa regra simplificada como «instalar a correção mais elevada». A versão de origem, o calendário de manutenção e o modelo de serviço podem determinar o percurso adequado. Se o inventário interno não permitir identificar com segurança a ramificação e o hot fix, solicite confirmação ao administrador responsável ou ao suporte do fornecedor. Registe o limite aplicável a cada ambiente e os elementos que fundamentam essa conclusão; a designação genérica de uma família do produto não substitui esta verificação.

Cinco identificadores CVE, mas não cinco descrições técnicas completas

O alerta do CSIRT italiano da Toscana, que remete para o boletim da ServiceNow, enumera cinco identificadores: CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860 e CVE-2026-13016. Também caracteriza o conjunto como composto por duas falhas críticas e três de gravidade elevada. Esta descrição ajuda a perceber que a lista de versões está relacionada com várias vulnerabilidades, mas não substitui a consulta do aviso técnico de cada CVE nem determina, por si só, a exposição de uma configuração específica.

Entre os registos acessíveis durante esta verificação, CVE-2026-86857 é descrita como um problema de autorização que poderia permitir a uma pessoa autenticada aceder a dados da AI Platform para os quais não tem autorização. CVE-2026-86859 é descrita como um problema de autorização que poderá permitir o acesso não autenticado a dados. Estes casos demonstram por que razão o controlo de acesso e a exposição de informação são relevantes; não justificam, contudo, atribuir os mesmos detalhes aos outros três identificadores. Não deduza técnicas, condições ou consequências específicas para cada CVE a partir da lista agregada do aviso. O resumo de gravidade e os identificadores são referências úteis, mas não substituem a descrição técnica e os critérios de aplicabilidade de cada vulnerabilidade.

O que se sabe sobre exploração e âmbito

Na descrição do registo CVE-2026-86857, a ServiceNow afirma ter implementado uma atualização nas instâncias alojadas e tê-la disponibilizado a parceiros e clientes autogeridos. O mesmo texto diz que, no momento da publicação do registo, a empresa não tinha conhecimento de exploração maliciosa contra instâncias da ServiceNow. Esta formulação deve manter o seu âmbito temporal: descreve o que o fornecedor sabia naquele momento, não prova que nunca tenha existido exploração nem garante que não surjam informações posteriores.

O aviso canadiano enumera o produto e as versões, mas não relata incidentes específicos em organizações utilizadoras nem permite estimar quantas instâncias poderão estar afetadas. «Vulnerabilidade publicada» não deve ser confundida com «intrusão confirmada». Para avaliar um caso específico são necessários dados da própria instância, registos e confirmação do fornecedor; as fontes analisadas não permitem afirmar que estas falhas estejam a ser exploradas ativamente. Assim, as organizações não devem interpretar a ausência de incidentes comunicados nem um aviso geral sobre o produto como uma avaliação conclusiva do seu próprio ambiente.

Lista de verificação para operações e segurança

Primeiro, identifique o modelo de serviço e quem é responsável pela sua manutenção. Se a instância estiver alojada pela ServiceNow, solicite confirmação de que a atualização correspondente foi aplicada nesse ambiente e registe a resposta e a data. Se a instalação for autogerida ou mantida por um parceiro, compare a ramificação e o nível de correção exatos com a lista do aviso e coordene a atualização segundo as instruções da ServiceNow. O aviso público recomenda que sejam consultadas as ligações indicadas e aplicadas as atualizações necessárias; não fornece um procedimento universal de consola que se possa considerar válido para todas as implementações.

Em seguida, documente as provas de conclusão: ramificação, correção ou hot fix, data de aplicação e responsável pela validação. Se a organização mantiver vários ambientes — produção, testes ou instâncias separadas por unidade, por exemplo — verifique cada um, em vez de extrapolar o estado de uma instalação para as restantes. Trate qualquer versão que pareça anterior aos limites pertinentes como uma questão pendente até o suporte confirmar o percurso de mitigação. Se a versão já atingir o nível indicado, guarde prova da comparação; não a interprete automaticamente como uma avaliação completa de outros riscos ou configurações. Um registo datado também facilita revisões posteriores se mudarem a responsabilidade de manutenção ou o modelo de alojamento.

O dado essencial é a versão exata, não uma suposição

A conclusão verificável em 26 de setembro de 2026 é limitada: o Centro Canadiano para a Cibersegurança publicou um alerta sobre a ServiceNow AI Platform com ramificações e níveis de correção concretos; um resumo do CSIRT enumera cinco CVE; e os registos consultados descrevem duas delas como problemas de autorização e acesso a dados. Para um administrador, a ação razoável consiste em comparar o nível exato de cada instância com a lista, confirmar a cobertura com a ServiceNow quando apropriado e aplicar as atualizações pertinentes de acordo com o boletim do fornecedor.

Há limites informativos. O aviso, por si só, não detalha os componentes técnicos das cinco CVE, o efeito de cada uma individualmente nem o estado de exploração observado em todas as instâncias. A ausência desses detalhes no aviso público não prova que não existam; simplesmente impede que sejam afirmados aqui. Até que o fornecedor ou os registos técnicos forneçam informações adicionais, a prioridade não é especular sobre incidentes, mas verificar o estado das correções em cada implementação e registar a confirmação. Separe esclarecimentos posteriores do fornecedor dos factos estabelecidos por este aviso e reavalie os ambientes afetados se os limites ou as orientações de manutenção forem alterados.