As notícias de cibersegurança de setembro de 2026 foram dominadas por tokens forjados, sessões reproduzidas e chaves de API divulgadas que continuaram a funcionar depois de a palavra-passe ter sido alterada, ou que nunca a exigiram. Duas vulnerabilidades constam já do catálogo Known Exploited Vulnerabilities da CISA e uma chave de fornecedor divulgada colocou em risco mais de 100 000 sites.
- Cisco ISE: CVE-2026-76460, um contorno de autenticação com exploração ativa confirmada (Cisco).
- EvilTokens: a Microsoft desarticulou um serviço de phishing por código de dispositivo associado a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações (Microsoft).
- Brevo e Cloudflare: uma chave de API comprometida colocou mais de 100 000 sites em risco potencial (Sansec).
- JFrog Artifactory: uma falha explorada em honeypots para gerar tokens de administrador (SecurityWeek).
- Cleo Harmony: um exploit público para uma falha nos tokens de atualização JWT (SecurityWeek).
- CyberArk: 10 boletins de segurança em quatro datas, incluindo um crítico (CyberArk).
- Chaves de GitHub App: a GitGuardian verificou que 474 de 4802 chaves privadas divulgadas continuavam válidas e se autenticavam como 440 aplicações (GitGuardian).
- NIST IR 8587: orientações finais sobre a proteção de tokens e asserções, publicadas a 15 de setembro (NIST).
Cada caso abaixo mostra uma forma diferente de uma credencial continuar a funcionar quando já deveria ter deixado de o fazer: forjada, reproduzida, divulgada ou gerada a pedido. Seguem-se os detalhes, as versões afetadas e as correções, com uma breve lista de ações ao nível da equipa no final.
Exploração ativa de um contorno de autenticação no Cisco Identity Services Engine (CVE-2026-76460)
A Cisco publicou, a 16 de setembro de 2026, um aviso sobre o CVE-2026-76460, uma vulnerabilidade crítica de contorno de autenticação, explorável sem autenticação, numa API do Identity Services Engine (ISE). A Cisco classifica-a com CVSS 3.1 Base 10,0 (crítica) e confirmou a exploração ativa. A CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities no mesmo dia.
O que aconteceu: Um pedido especialmente construído para o endpoint da API afetado permite a um atacante contornar a interface de gestão web do ISE e obter acesso não autorizado a um dispositivo ISE ou ISE-PIC afetado, sem credenciais válidas. O PSIRT da Cisco confirmou ter conhecimento de ataques em ambiente real. A data exata em que a exploração começou não foi divulgada.
Porque isto importa: O ISE é uma plataforma de políticas de acesso à rede. O acesso não autorizado pode criar um risco grave, dependente de cada implementação, para as operações de administração e de políticas, mas as fontes disponíveis não demonstram que as decisões de RBAC ou de MFA a jusante de todos os clientes tenham sido alteradas. O impacto depende da forma como cada organização implementou o ISE.
A lição defensiva: A Cisco indica que nenhuma solução alternativa resolve a falha. A atualização para uma versão corrigida é a correção completa. Como mitigação temporária, a Cisco recomenda listas de controlo de acesso de infraestrutura (iACL) que permitam apenas o tráfego de gestão e de plano de controlo necessário para o dispositivo afetado. Reveja o access.log de cada nó em busca de nomes de utilizador suspeitos e cruze os registos de rede e de firewall fora do próprio equipamento. Estes passos são de deteção e resposta e não substituem a aplicação da correção.
A Microsoft desarticula o EvilTokens, um serviço de phishing por código de dispositivo OAuth
A 22 de setembro de 2026, a Digital Crimes Unit da Microsoft, em colaboração com parceiros, desarticulou a infraestrutura do EvilTokens, uma plataforma de phishing como serviço associada a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações em todo o mundo.
O que aconteceu: O EvilTokens abusou dos fluxos de autorização de dispositivos do OAuth 2.0, o mecanismo concebido para dispositivos sem navegador, como televisores inteligentes ou ferramentas CLI, para levar os utilizadores a aprovar um início de sessão em nome do atacante. Separadamente, a Microsoft divulgou atividade de engenharia social com o tema das passkeys, observada desde maio de 2026. Numa das sequências investigadas, uma isca com passkeys conduziu a phishing por código de dispositivo. Noutros padrões investigados, os atacantes recorreram a pretextos de apoio técnico ou registaram métodos de autenticação controlados pelo atacante. Os relatórios da Microsoft não demonstram que todas as sequências tenham combinado todos estes passos numa única cadeia de ataque.
Porque isto importa: O phishing por código de dispositivo contorna as partes da autenticação que recebem mais atenção defensiva. Não há uma página de início de sessão falsa para identificar nem uma palavra-passe introduzida num site do atacante. A vítima aprova o início de sessão na página legítima da própria Microsoft, convencida de que trata de um procedimento de rotina. Ainda assim, uma vítima sem sessão Microsoft ativa pode continuar a ser solicitada a introduzir uma palavra-passe real e a responder a um desafio de MFA, pelo que esta técnica não elimina, em todos os casos, cada etapa de autenticação.
A lição defensiva: Desative os fluxos de autenticação por código de dispositivo para os utilizadores que não precisam deles do ponto de vista operacional e monitorize o volume anómalo de inícios de sessão por código de dispositivo como sinal de deteção. Quando o fluxo for genuinamente necessário, condicione-o a uma política de acesso condicional.
Fontes: Microsoft; Microsoft (atividade com o tema das passkeys)
Uma única chave de API da Cloudflare com privilégios excessivos colocou em risco mais de 100 000 sites
A 14 de setembro de 2026, atacantes utilizaram uma chave de API da Cloudflare comprometida e com privilégios amplos, pertencente à Brevo, uma plataforma de e-mail e marketing, para implementar um Cloudflare Worker malicioso que alterou recursos incorporados da Brevo em sites de clientes.
O que aconteceu: A telemetria da Sansec registou o Worker malicioso a servir conteúdo das 16:05 às 20:13 UTC de 14 de setembro, cerca de quatro horas. O relatório do incidente da Brevo descreve o Worker como ativo durante cerca de cinco horas e meia, uma janela mais longa do que a observada diretamente pela Sansec. A Sansec estimou que mais de 100 000 sites que utilizam componentes da Brevo afetados poderão ter estado expostos a conteúdo malicioso durante esse período.
Porque isto importa: Uma única chave de API da Cloudflare, de longa duração e com permissões totais, associada a um fornecedor de automatização de marketing, tornou-se um canal de distribuição de código malicioso por um grande número de sites de terceiros. As chaves de API de nuvem com âmbitos amplos e sem expiração são precisamente o tipo de credencial que a política tradicional de palavras-passe não abrange.
A lição defensiva: Limite as chaves de API ao conjunto mínimo de permissões de que uma integração realmente necessita, defina prazos de expiração mesmo para chaves ao nível do serviço e execute uma análise contínua de segredos nos repositórios e nos pipelines de implementação, e não apenas nos cofres de palavras-passe dos colaboradores. A monitorização de implementações inesperadas de Workers ou de alterações de encaminhamento teria provavelmente permitido detetar o problema mais depressa do que uma auditoria manual.
Falha do JFrog Artifactory utilizada para gerar tokens de administrador (CVE-2026-82329)
A JFrog publicou uma correção para o CVE-2026-82329 a 28 de agosto de 2026. A 1 de setembro, a WatchTowr reportou atividade em honeypots compatível com a exploração da falha por atacantes para gerar tokens de administrador.
O que aconteceu: Os honeypots da WatchTowr captaram tentativas de exploração a partir de um pequeno número de IPs de origem, algumas das quais pareciam ser apenas atividade de verificação e não ataques de seguimento. Isto é prova de que a vulnerabilidade é explorável e está a ser sondada. Não demonstra um varrimento generalizado da internet nem a exploração em massa confirmada de instâncias de clientes.
Porque isto importa: Os repositórios de artefactos situam-se perto do centro da cadeia de fornecimento de software. Mantêm relações de confiança de federação com outros repositórios e transportam com frequência credenciais incorporadas para sistemas a jusante. Um atacante que consiga gerar um token de administrador não precisa de o roubar: cria acesso válido a pedido.
A lição defensiva: No caso do Artifactory self-hosted, atualize para a versão corrigida do respetivo ramo: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 ou 7.161.20. A JFrog afirma que os ambientes de nuvem afetados já foram reforçados. Se os registos mostrarem exploração ou emissão suspeita de tokens, revogue e volte a emitir os tokens de administrador potencialmente expostos e audite as configurações de federação. Os relatórios disponíveis sustentam a exploração observada em honeypots, e não o comprometimento confirmado de instâncias de clientes.
Fontes: JFrog; SecurityWeek
Exploit público para uma falha nos tokens de atualização JWT do Cleo Harmony (CVE-2026-84115)
Foi reportado um exploit público para o CVE-2026-84115 a 2 de setembro de 2026, pouco depois de o registo do CVE ter sido publicado, a 1 de setembro.
O que aconteceu: A falha afeta as versões do Cleo Harmony até à 5.8.1.10, inclusive, e está corrigida no Harmony 5.8.1.11. O registo do CVE descreve um problema explorável remotamente no JWT Refresh Token Handler de /api/connections: a manipulação do argumento Bearer resulta numa gestão indevida de privilégios. A SecurityWeek descreve o mesmo problema como uma falha que permite contornar a autenticação e elevar privilégios. Os relatórios disponíveis estabelecem a possibilidade de exploração pública e a reprodução por investigadores. Não demonstram a exploração confirmada de sistemas de clientes, nem que um token manipulado persista para além da expiração da sessão original.
Porque isto importa: Os tokens de atualização destinam-se a prolongar uma sessão de forma discreta, sem obrigar a um novo início de sessão. Uma falha na forma como um deles é validado transforma essa funcionalidade de conveniência num potencial risco de persistência, o que é motivo suficiente para aplicar a correção mesmo sem exploração confirmada.
A lição defensiva: Atualize para o Harmony 5.8.1.11 com brevidade. Se houver suspeita de exposição, siga as orientações atuais da Cleo, reveja as alterações de autenticação e de privilégios do período em causa e revogue os tokens de atualização pendentes quando a implementação for compatível com esse controlo. A existência de um exploit público não confirma, por si só, comprometimento nem acesso persistente.
Fontes: NVD; SecurityWeek
A CyberArk publica dez boletins de segurança em toda a sua linha de produtos PAM
A CyberArk publicou 10 boletins de segurança em setembro de 2026, em quatro lotes datados.
O que aconteceu: A CyberArk publicou 10 boletins de segurança em quatro lotes durante setembro de 2026, que tratam problemas de gravidade alta em agentes de gestão de privilégios em endpoints, componentes self-hosted de gateway e de cofre, análise de acessos privilegiados e gestão de credenciais de bases de dados, bem como um problema crítico (CA26-44) que afeta determinadas versões self-hosted do Password Vault Web Access (PVWA).
Porque isto importa: Os sistemas de gestão de acessos privilegiados (PAM) gerem ou dão acesso, com frequência, a credenciais privilegiadas e a infraestrutura sensível. Um conjunto concentrado de atualizações de segurança é um lembrete de que estes ambientes exigem uma gestão contínua de correções, uma governação de acessos clara e uma auditabilidade fiável. Os avisos não indicam, por si só, exploração ativa.
A lição defensiva: As organizações que utilizam os produtos afetados devem rever os avisos e dar prioridade à correção de acordo com a gravidade, a exposição e o impacto potencial nos sistemas relacionados com credenciais. De um modo mais geral, as equipas de segurança devem manter visibilidade sobre quem pode aceder a credenciais sensíveis e ser capazes de rever esse acesso quando necessário.
Fonte: CyberArk; quadro de boletins da CyberIAM
As chaves privadas de GitHub App divulgadas continuam a funcionar muito tempo depois da exposição
A GitGuardian testou 4802 chaves privadas de GitHub App divulgadas, encontradas em fontes públicas, e verificou que 474 continuavam a autenticar-se como 440 aplicações ativas distintas.
O que aconteceu: Uma chave privada de GitHub App não tem expiração automática e pode permanecer utilizável até ser revogada ou eliminada manualmente. Das 474 chaves ainda válidas testadas pela GitGuardian, 207 tinham permissão de escrita no conteúdo de repositórios, 40 podiam administrar runners self-hosted, 98 podiam controlar workflows e 44 detinham privilégios de administração da organização. Uma chave incluída num commit há anos pode continuar a autenticar-se se não tiver sido revogada ou eliminada.
Um padrão relacionado surgiu numa falha na gestão de APIs da WSO2, o CVE-2026-5430. O aviso data de maio de 2026 e o CVE foi publicado em agosto. A notícia de setembro foi a divulgação de exploração, e não uma nova divulgação da falha. Um atacante pode construir um JWT com um algoritmo de assinatura não admitido e explorar a validação defeituosa da WSO2 para contornar a autenticação. O serviço não precisa de emitir ele próprio um token. O honeypot da WatchTowr captou, a 13 de setembro, JWT forjados com privilégios de administrador contra o serviço, e a CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities a 24 de setembro. As credenciais de back-end, as chaves de consumidor ou os segredos foram reportados como potencialmente acessíveis, e não como roubados de forma confirmada.
Porque isto importa: Uma fuga pública cria um acesso potencialmente persistente até a chave ser revogada ou eliminada. Por si só, não prova que a chave tenha sido utilizada nem que os dados tenham sido acedidos. O caso da WSO2 mostra um padrão relacionado uma camada abaixo na pilha: um atacante não precisa de forma alguma de uma chave divulgada se a própria lógica de validação puder ser enganada para aceitar uma chave forjada.
A lição defensiva: Mantenha um responsável e um processo documentado de rotação e revogação para cada chave de GitHub App. Se a exposição for suspeita ou confirmada, gere uma chave de substituição e revogue ou elimine prontamente a antiga; a rotação periódica reduz o tempo de exposição, embora o GitHub não prescreva um calendário universal. Nas implementações da WSO2, aplique a correção do fabricante, reveja os registos do período de exploração de setembro e faça a rotação das credenciais a que a camada de gestão de APIs tinha acesso.
Fontes: GitGuardian; documentação do GitHub; aviso da WSO2; The Hacker News
O NIST e a CISA finalizam orientações sobre a proteção de tokens de identidade e de acesso
O NIST e a CISA finalizaram o IR 8587 a 15 de setembro de 2026, após um rascunho público inicial de 22 de dezembro de 2025.
O que aconteceu: As orientações de implementação destinam-se principalmente às agências federais e aos fornecedores de serviços de nuvem que estas utilizam, e abrangem tokens de identidade, tokens de acesso e asserções em cenários de SSO, federação e acesso a APIs. As suas recomendações resumem práticas de gestão de chaves, verificação de tokens, ciclo de vida (incluindo duração e revogação) e monitorização contínua, com as responsabilidades repartidas entre fornecedores, agências consumidoras e consumidores de nuvem.
Porque isto importa: Várias das falhas descritas acima (JWT forjados, tokens de administrador gerados através de falhas de validação, chaves de API sem expiração) enquadram-se nas categorias abordadas por este relatório: lacunas de verificação, falta de controlos de ciclo de vida e responsabilidade pouco clara entre fornecedor e cliente quanto à revogação. Essa sobreposição é útil mesmo para organizações fora do setor federal.
A lição defensiva: Utilize o NIST IR 8587 como lista de verificação de trabalho face às práticas atuais: confirme que a duração dos tokens é limitada, que os percursos de revogação são testados e não apenas documentados, e que o registo de sessões capta detalhe suficiente para reconstituir, a posteriori, um incidente baseado em tokens.
A CloudSEK detalha o BigBear 2.0, um serviço de atacante intermediário (adversary-in-the-middle) que reproduz sessões do Microsoft 365 após a MFA
A CloudSEK publicou a sua investigação sobre o BigBear 2.0 a 7 de setembro de 2026. A equipa TRIAD descobriu a operação em junho, o que não permite determinar quando começou toda a atividade da campanha.
O que aconteceu: O serviço de atacante intermediário baseado no Evilginx2 retransmitia inícios de sessão do Microsoft 365. Capturava as credenciais e o cookie de sessão emitido pela Microsoft depois de as vítimas concluírem a MFA, e depois permitia aos atacantes reproduzir as sessões autenticadas. O painel da CloudSEK continha 4148 registos de cookies de sessão e 474 autenticações concluídas com a MFA contornada. A BleepingComputer reportou que 258 organizações distintas tinham pelo menos um desses comprometimentos concluídos, enquanto 461 organizações constavam do conjunto de dados de alvos mais alargado. O valor de 4148 é uma contagem de registos de cookies e não uma contagem confirmada de vítimas únicas. (CloudSEK; BleepingComputer)
Porque isto importa: A MFA que a vítima conclui numa página retransmitida através de um proxy não protege nada depois de o cookie de sessão ser roubado. O atacante herda uma sessão já autenticada. Os códigos e as aprovações por notificação push não travam este padrão.
A lição defensiva: Dê prioridade a métodos resistentes a phishing, como as passkeys e as chaves de segurança FIDO2, para os administradores e os utilizadores de alto risco. Reveja as políticas de acesso condicional que associam as sessões a dispositivos em conformidade. Crie alertas para inícios de sessão em que o endereço IP ou o dispositivo da sessão mude pouco depois da MFA.
Fontes: CloudSEK; BleepingComputer
A Okta analisa um dump de infostealer com 44 791 JWT únicos e 1843 tokens ainda válidos na data de divulgação
A Okta publicou, a 9 de setembro de 2026, uma investigação sobre um dump de infostealer de 7 GB publicado no Telegram a 2 de agosto.
O que aconteceu: O dump continha dados de 5871 máquinas infetadas. A Okta identificou 44 791 JWT únicos, incluindo 555 provavelmente relacionados com a autenticação em serviços de IA, além de 2937 JWE relacionados com autenticação. À data da divulgação do dump, 1843 JWT e JWE ainda não tinham expirado. A Okta afirmou que os segredos de sessão não expirados poderiam, potencialmente, ser reproduzidos para contornar a autenticação baseada em credenciais. A investigação não reportou nenhuma reprodução bem-sucedida nem nenhuma tomada de controlo de conta confirmada. O êxito da reprodução depende do serviço e de controlos como o token binding ou as listas de IPs autorizados. (Okta)
Porque isto importa: Os infostealers levam tudo o que se encontra no endpoint, e os tokens fazem parte desse saque. A duração de um token determina durante quanto tempo um segredo roubado continua útil. Os tokens de serviços de IA no conjunto mostram que a exposição abrange agora ferramentas mais recentes, que as equipas adotam muitas vezes fora da gestão central de identidades.
A lição defensiva: Reduza a duração dos tokens sempre que o serviço o permita e associe os tokens a um dispositivo ou a uma rede quando tal for possível. Após uma infeção por infostealer, revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe. Inclua as contas de serviços de IA no inventário de tokens e de chaves de API.
Fonte: Okta
A extensão JeetBot para a Twitch reencaminhava tokens OAuth através de proxies controlados pelo operador
A extensão maliciosa de navegador para a Twitch JeetBot tinha cerca de 30 500 instalações nas lojas, entre o Chrome e o Firefox (uma estimativa de instalações e não uma contagem confirmada de comprometimentos).
O que aconteceu: A Socket verificou que a extensão captava tokens OAuth da Twitch associados à conta e reencaminhava-os num parâmetro de consulta &auth= através de proxies controlados pelo operador. Os relatórios não demonstram que os tokens tenham sido utilizados para atividade não autorizada. A versão 85.8.7 do Firefox (16 de setembro) e a versão 85.8.9 do Chrome (reportada a 25 de setembro) pararam o reencaminhamento. O operador contestou a classificação da extensão como maliciosa, mas reconheceu problemas de segurança e de divulgação. (Socket)
A lição defensiva: Audite as extensões de navegador instaladas e trate como exposto qualquer token que tenha aparecido num URL. Os utilizadores do JeetBot devem revogar o acesso da aplicação à respetiva conta da Twitch.
Fonte: Socket
O Microsoft Entra começa a ativar automaticamente as passkeys antes da retirada da MFA por SMS e por chamada de voz
O Microsoft Entra começou a ativar automaticamente as passkeys a 1 de setembro de 2026 para os utilizadores da nuvem pública já ativados para MFA por SMS ou por chamada de voz na Entra Authentication Methods Policy ou nas definições legadas.
O que aconteceu: Quando estes utilizadores iniciarem sessão da próxima vez e concluírem a MFA, são incentivados a registar uma passkey. Este incentivo pode, em regra, ser adiado, e está disponível uma exclusão temporária ao nível do tenant até 1 de fevereiro de 2027. A entrega de SMS e de chamadas de voz fornecida pela Microsoft termina a 1 de fevereiro de 2027 para a maioria dos utilizadores e a 1 de julho de 2027 para os Global Administrators e os utilizadores externos. As organizações com uma necessidade legítima podem continuar a utilizar SMS ou chamadas de voz através de um fornecedor de telefonia compatível. Essa opção de configuração está prevista para 30 de outubro de 2026.
Porque isto importa: A alteração afasta a predefinição dos fatores baseados no telefone, o tipo que a campanha BigBear 2.0 acima mostra poder ser retransmitido. Os tenants que não façam nada verão agora pedidos de registo e perderão em 2027 a entrega de SMS e de chamadas de voz fornecida pela Microsoft.
A lição defensiva: Inventarie os utilizadores e os processos de serviço que ainda dependem de SMS ou de chamadas de voz. Comece o registo de passkeys pelos administradores e pelos utilizadores externos, cujo prazo é o mais próximo. Decida antes de 1 de fevereiro de 2027 se é necessário um fornecedor de telefonia ou se estes métodos podem ser totalmente retirados.
Fonte: Microsoft Learn
O que isto significa para a equipa
A maioria dos casos deste mês resume-se a credenciais que continuaram a funcionar quando já deveriam ter deixado de o fazer. Seis passos que a equipa pode seguir para evitar problemas semelhantes:
- Inventariar as credenciais não humanas. Liste as chaves de API, os tokens de contas de serviço, as chaves privadas de GitHub App e os segredos de CI/CD tal como se listam as contas de utilizador. Atribua a cada uma um responsável identificado e um plano documentado de expiração ou rotação. Os casos da Brevo e das GitHub Apps envolveram chaves que ninguém acompanhava.
- Limitar o âmbito e definir a expiração. Atribua a cada chave apenas as permissões de que a integração necessita e defina uma expiração sempre que o fornecedor a permita. Quando não o permita, agende a rotação manual.
- Testar a revogação antes de ser necessária. Para cada fornecedor, confirme o que a revogação de uma sessão, de um JWT, de uma concessão OAuth ou de um token de atualização faz realmente. Após um incidente, execute o percurso de revogação de ponta a ponta, em vez de confiar na documentação. Revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe.
- Fechar as lacunas de OAuth e de sessão. Desative os fluxos de código de dispositivo para os utilizadores que não precisam deles e passe os administradores para passkeys ou chaves FIDO2 antes da retirada do SMS e das chamadas de voz pela Microsoft em 2027. Sempre que for possível, associe as sessões a dispositivos.
- Corrigir primeiro a infraestrutura de identidade exposta. O Cisco ISE, o JFrog Artifactory, o Cleo Harmony e a WSO2 emitem ou validam o acesso a tudo o que está por trás deles. Trate as respetivas atualizações como prioridade em relação à aplicação rotineira de correções.
- Registar o suficiente para reconstituir um incidente. Mantenha registos de sessão e de tokens suficientemente detalhados para mostrar quem se autenticou, a partir de onde e com que token. O NIST IR 8587 é uma lista de verificação utilizável para este ponto e para os anteriores.
Para leitura complementar, recomendam-se os guias sobre o ciclo de vida da rotação de segredos e sobre os segredos hardcoded.
Passwork Team
Passwork Team
Alex Muntyan
Índice de conteúdos
- Exploração ativa de um contorno de autenticação no Cisco Identity Services Engine (CVE-2026-76460)
- A Microsoft desarticula o EvilTokens, um serviço de phishing por código de dispositivo OAuth
- Uma única chave de API da Cloudflare com privilégios excessivos colocou em risco mais de 100 000 sites
- Falha do JFrog Artifactory utilizada para gerar tokens de administrador (CVE-2026-82329)
- Exploit público para uma falha nos tokens de atualização JWT do Cleo Harmony (CVE-2026-84115)
- A CyberArk publica dez boletins de segurança em toda a sua linha de produtos PAM
- As chaves privadas de GitHub App divulgadas continuam a funcionar muito tempo depois da exposição
- O NIST e a CISA finalizam orientações sobre a proteção de tokens de identidade e de acesso
- A CloudSEK detalha o BigBear 2.0, um serviço de atacante intermediário (adversary-in-the-middle) que reproduz sessões do Microsoft 365 após a MFA
- A Okta analisa um dump de infostealer com 44 791 JWT únicos e 1843 tokens ainda válidos na data de divulgação
- A extensão JeetBot para a Twitch reencaminhava tokens OAuth através de proxies controlados pelo operador
- O Microsoft Entra começa a ativar automaticamente as passkeys antes da retirada da MFA por SMS e por chamada de voz
- O que isto significa para a equipa
Índice de conteúdos
- Exploração ativa de um contorno de autenticação no Cisco Identity Services Engine (CVE-2026-76460)
- A Microsoft desarticula o EvilTokens, um serviço de phishing por código de dispositivo OAuth
- Uma única chave de API da Cloudflare com privilégios excessivos colocou em risco mais de 100 000 sites
- Falha do JFrog Artifactory utilizada para gerar tokens de administrador (CVE-2026-82329)
- Exploit público para uma falha nos tokens de atualização JWT do Cleo Harmony (CVE-2026-84115)
- A CyberArk publica dez boletins de segurança em toda a sua linha de produtos PAM
- As chaves privadas de GitHub App divulgadas continuam a funcionar muito tempo depois da exposição
- O NIST e a CISA finalizam orientações sobre a proteção de tokens de identidade e de acesso
- A CloudSEK detalha o BigBear 2.0, um serviço de atacante intermediário (adversary-in-the-middle) que reproduz sessões do Microsoft 365 após a MFA
- A Okta analisa um dump de infostealer com 44 791 JWT únicos e 1843 tokens ainda válidos na data de divulgação
- A extensão JeetBot para a Twitch reencaminhava tokens OAuth através de proxies controlados pelo operador
- O Microsoft Entra começa a ativar automaticamente as passkeys antes da retirada da MFA por SMS e por chamada de voz
- O que isto significa para a equipa
Gestor de palavras-passe autoalojado para empresas
A Passwork oferece a vantagem de um trabalho em equipa eficaz com palavras-passe corporativas num ambiente totalmente seguro. A encriptação dupla e a arquitetura de conhecimento zero garantem que as suas palavras-passe nunca saem da sua infraestrutura.
Saber mais