Android: o que comprova a correção de novembro?
Um aparelho pode mostrar novembro em campos que representam correções diferentes. Relacione o nível de segurança, o sistema Google Play e o build antes de encerrar a manutenção.
Read in EnglishPor Pentesty
Separe os dois níveis de patch de novembro
O boletim oficial foi publicado em 2 de novembro de 2026 e atualizado em 6 de novembro. O nível 2026-11-01 cobre os problemas associados a esse nível. O nível 2026-11-05, ou posterior, inclui todos os patches aplicáveis deste boletim e dos anteriores. A avaliação da empresa precisa relacionar o nível observado ao conjunto de correções aplicável.
As três falhas críticas de execução remota, CVE-2026-58868, CVE-2026-58876 e CVE-2026-58936, já pertencem ao conjunto de 1º de novembro. Os registros do Google descrevem exploração sem interação do usuário nem privilégios prévios. Isso exige atenção, mas não comprova um incidente, uma cadeia completa de ataque ou a exploração de determinado aparelho.
Registre o sistema Google Play em um campo próprio
A CVE-2026-58876 também aparece na tabela de componentes Mainline, em Media Codecs. O boletim informa que alguns aparelhos com Android 10 ou posterior podem receber atualizações do sistema Google Play. Essa informação não garante disponibilidade uniforme para todos os modelos, nem transforma a data desse sistema em prova do nível completo 2026-11-05.
A orientação do Google distingue versão do Android, atualização de segurança, atualização do sistema Google Play e número do build. Preserve esses campos separadamente. Se a ferramenta de gestão não fornecer algum deles, documente a lacuna e uma forma autorizada de confirmação. Um único indicador verde não deve substituir um valor que a equipe ainda não observou.
Por exemplo, se o inventário informa 2026-11-01 e o campo Google Play também mostra novembro, isso não documenta 2026-11-05. Abra uma pendência para o nível solicitado, identifique a atualização correspondente ao modelo e combine a próxima coleta. O exemplo representa uma divergência de aceite, sem concluir que aquelas três RCEs continuam presentes.
Vincule a evidência ao aparelho e ao canal de entrega
Escolha uma amostra autorizada que represente fabricantes, modelos e perfis de trabalho usados pela empresa. Para cada aparelho, relacione identificador corporativo, modelo, build, datas completas, horário da coleta e origem da informação. A evidência precisa permitir reencontrar o mesmo equipamento sem reunir fotos, mensagens ou outros dados pessoais desnecessários.
Confirme com o fabricante ou responsável pelo suporte qual atualização está disponível para aquele modelo e canal. O Google informa que os calendários variam por aparelho, fabricante e operadora. A lista de versões AOSP corrigidas não é uma confirmação de entrega na frota. Registre separadamente atualização disponível, distribuição solicitada, instalação e verificação posterior.
Aceite a instalação depois de verificar o estado ativo
Combine uma janela com suporte e usuários antes de mudanças que interrompam o trabalho. Nos Pixel, o Google informa que atualizações baixadas entram em vigor após reiniciar; outros aparelhos seguem seu processo de instalação. Recolha os valores depois da conclusão exigida pelo equipamento. Evite encerrar o chamado apenas porque houve download ou porque a tarefa de distribuição terminou.
Em uma operação corporativa autorizada, verifique também a continuidade de uma atividade simples com conta e dados de teste. O resultado demonstra o funcionamento daquele fluxo, não ausência de todas as vulnerabilidades. Vincule o registro anterior e o posterior, o critério esperado e quem aceita o resultado. Se houver divergência, mantenha o aparelho como pendência identificada.
Dê às exceções um responsável e uma decisão
Quando não houver atualização ou evidência suficiente, registre a limitação real, o impacto para o trabalho e o responsável por decidir o tratamento. Defina um prazo de revisão conforme a política da empresa e o suporte do produto. Consulte o prazo de suporte do modelo, considerando mais do que a versão principal do sistema. A decisão sobre manter o acesso deve considerar os dados corporativos envolvidos e as alternativas de trabalho.
O aceite pode reunir estes pontos verificáveis:
- Cobertura: nível completo exigido, modelo e orientação aplicável do fornecedor.
- Observação: build, datas independentes, origem e horário da evidência.
- Resultado: instalação ativa, fluxo autorizado verificado e exceções abertas.
- Continuidade: responsável e próximo acompanhamento. Nossa análise do Paint também separa canais de atualização; a do Authenticator no Android trata do aceite de um aplicativo e de suas integrações.
Perguntas frequentes
2026-11-01 deixa as três RCEs sem correção?
Não. As três constam no conjunto de 1º de novembro. O nível 2026-11-05 amplia o compromisso para todos os patches aplicáveis do boletim e dos anteriores.
A data do sistema Google Play substitui o patch de segurança?
Não. Registre os dois campos. A tabela Mainline cobre componentes específicos; uma data do Google Play não demonstra sozinha o nível completo de segurança do aparelho.
O boletim comprova que a empresa foi atacada?
Não. Ele descreve vulnerabilidades e correções. Concluir que houve exploração na empresa exige evidências próprias e investigação do caso.
Como tratar um modelo sem atualização disponível?
Confirme a situação com o fornecedor, documente a lacuna e encaminhe uma decisão ao responsável. Estabeleça tratamento e revisão conforme a política aprovada.
Fontes e referências
- Google: boletim Android de novembro de 2026, publicado em 2 e atualizado em 6 de novembro
- Google CNA: CVE-2026-58868 no Framework Android
- Google CNA: CVE-2026-58876 no Android
- Google CNA: CVE-2026-58936 no Android
- Google: conferir versão, patch de segurança, sistema Google Play e build
Análise original da Pentesty, publicada em 8 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.