Uma vulnerabilidade grave no OxygenOS, sistema baseado em Android usado nos smartphones da OnePlus, pode permitir que um aplicativo malicioso instalado no aparelho consiga acesso root sem solicitar permissões especiais. O problema foi descoberto pelo pesquisador de segurança Rasmus Moorats, que conseguiu encadear duas falhas em componentes proprietários da OnePlus para assumir o controle de um OnePlus 15 com a versão mais recente do sistema testada.
O cenário é particularmente preocupante porque o ataque não depende de bootloader desbloqueado, root previamente habilitado ou firmware modificado. O aplicativo precisa ser instalado no smartphone, mas, depois disso, a cadeia de exploração não exige uma nova autorização do usuário. A OnePlus também informou ao pesquisador que as falhas atingem outros aparelhos da marca e dispositivos da OPPO, embora não tenha divulgado publicamente uma lista completa de modelos afetados.
A descoberta também provocou um debate sobre divulgação responsável de vulnerabilidades. Moorats afirma ter comunicado os problemas à OnePlus em abril de 2026 e aguardado meses por uma correção. Durante o processo, a fabricante teria reivindicado controle sobre a divulgação e alertado para possíveis consequências legais caso os detalhes fossem publicados sem autorização. A pesquisa acabou sendo divulgada em 24 de setembro, quando ainda não havia um patch público específico para essas falhas.
Como funciona a cadeia da falha de segurança no OxygenOS
A exploração combina duas vulnerabilidades diferentes em serviços próprios da OnePlus: AtlasService e olc2. Isoladamente, cada problema representa uma quebra de uma camada de segurança. Quando utilizados em sequência, porém, eles permitem passar de um aplicativo Android comum para um contexto com privilégios de root.
O primeiro estágio explora uma falha de autorização no AtlasService. Depois que esse acesso privilegiado é obtido, o atacante utiliza o segundo componente para chegar a um contexto ainda mais poderoso, capaz de executar operações de baixo nível no sistema Linux.
Essa arquitetura demonstra um problema importante no modelo de segurança dos smartphones modernos: mesmo quando o Android mantém corretamente o isolamento entre aplicativos, serviços adicionais criados pelo fabricante podem introduzir novas interfaces privilegiadas que precisam ser protegidas com o mesmo rigor.
O papel do AtlasService e a falta de validação
O AtlasService é um serviço proprietário da OnePlus utilizado para coletar informações de depuração. Segundo a análise de Moorats, ele é executado com privilégios elevados e aceita chamadas de aplicativos sem verificar adequadamente quem está fazendo a solicitação.
Essa ausência de validação cria o primeiro ponto de entrada. Um aplicativo instalado normalmente pode preparar uma chamada específica para o serviço e fornecer dados controlados pelo próprio atacante.
O problema fica mais sério porque uma dessas operações encaminha o conteúdo recebido para uma ferramenta de diagnóstico do sistema. A entrada fornecida pelo aplicativo acaba sendo incorporada a um comando executado pelo sistema sem a devida proteção contra injeção de comandos.
Nesse momento, o aplicativo consegue executar código com privilégios de root, mas ainda existe uma limitação relevante. O acesso acontece dentro de um contexto restrito associado ao dumpstate, utilizado pelo Android para coleta de informações de diagnóstico.
Portanto, o primeiro estágio não representa sozinho o domínio completo do aparelho. Ele funciona como uma ponte para chegar ao segundo componente da cadeia.
A escalada final de privilégios com o olc2
O segundo estágio explora o olc2, um serviço auxiliar relacionado ao hardware presente no software da OnePlus. O componente disponibiliza uma função capaz de executar comandos de shell fornecidos pelo solicitante.
Existe uma verificação de segurança para impedir que aplicativos comuns utilizem essa funcionalidade: o chamador precisa possuir privilégios de root. O problema é que a primeira vulnerabilidade já permite satisfazer essa condição.
A cadeia, portanto, funciona como uma sequência de privilégios:
aplicativo comum → AtlasService → root restrito no dumpstate → olc2 → privilégios de baixo nível.
A segunda etapa executa os comandos em um contexto com acesso aos recursos de baixo nível do Linux, incluindo a capacidade de carregar código no kernel. Isso representa uma diferença fundamental em relação a simplesmente obter acesso administrativo a arquivos ou configurações do Android.
Com controle desse nível, um invasor pode interferir em componentes fundamentais do sistema operacional, modificar comportamentos de segurança e potencialmente obter persistência muito mais difícil de detectar ou remover.
O impasse entre divulgação responsável e ameaça legal
A parte técnica da falha de segurança OnePlus é acompanhada por uma disputa incomum sobre o processo de divulgação.
Moorats afirma que comunicou as duas vulnerabilidades à OnePlus em 18 de abril de 2026. A fabricante confirmou os problemas em maio e informou que trabalharia em uma correção. Entretanto, segundo a correspondência divulgada pelo pesquisador, a empresa também afirmou possuir o direito exclusivo de decidir quando e como as vulnerabilidades seriam divulgadas.
A OnePlus também teria alertado que a publicação dos detalhes sem autorização poderia resultar em consequências legais, citando sua interpretação das obrigações estabelecidas por normas europeias de segurança cibernética. A posição apresentada pela empresa foi a de que essas regras estabelecem responsabilidades para fabricantes no tratamento de vulnerabilidades, mas não dariam ao pesquisador liberdade automática para publicar informações técnicas sem consentimento.
Moorats, por outro lado, manteve o processo de divulgação e aguardou os prazos discutidos com a fabricante. Depois de meses sem uma correção pública, decidiu divulgar a pesquisa em 24 de setembro de 2026. Naquele momento, segundo as informações disponíveis, não havia patch público, número CVE ou comunicado de segurança específico relacionado às duas falhas.
É importante separar os fatos técnicos das questões jurídicas. A existência de uma ameaça de medidas legais não determina, por si só, quem possui razão perante a legislação aplicável. Essa avaliação depende dos contratos, das circunstâncias da pesquisa e das normas efetivamente aplicáveis ao caso.
O episódio, entretanto, evidencia uma tensão conhecida na segurança da informação: o fabricante precisa de tempo para corrigir uma vulnerabilidade, enquanto o pesquisador precisa decidir quanto tempo é razoável manter uma falha em sigilo quando os usuários continuam expostos.
O problema do código proprietário no Android
A descoberta também precisa ser analisada dentro de um contexto maior. O Android utiliza mecanismos como sandbox de aplicativos, permissões, isolamento de processos e SELinux para impedir que um aplicativo comum controle partes sensíveis do sistema.
Porém, fabricantes acrescentam grandes quantidades de código próprio ao sistema operacional. São serviços, drivers, ferramentas de diagnóstico e componentes responsáveis pela integração com hardware e recursos específicos.
Essas extensões fazem parte de interfaces como OxygenOS, ColorOS, One UI e HyperOS. Quando um desses componentes executa com privilégios elevados, qualquer erro de autorização pode criar uma superfície de ataque que não existe no Android puro.
Uma pesquisa publicada em agosto de 2026 pela empresa Calif, conduzida pelo pesquisador Lukas Maar, mostrou um problema relacionado. A pesquisa OEMpocalypse descreveu uma estratégia capaz de levar um aplicativo Android sem privilégios até root em aparelhos Samsung, Xiaomi e no grupo formado por OPPO, OnePlus e Realme.
Nesse trabalho, Maar explorou falhas em drivers específicos dos fabricantes e utilizou escapes do sandbox quando necessários. Os testes incluíram aparelhos com bootloader bloqueado e firmware de fábrica, entre eles Galaxy S26, Xiaomi 17, OPPO Find X9 Ultra e OnePlus Ace 6 Ultra.
Há uma diferença técnica importante entre os dois trabalhos. A pesquisa de Moorats explora principalmente serviços proprietários do espaço de usuário, enquanto a investigação da Calif concentra-se em uma estratégia envolvendo drivers de kernel desenvolvidos pelos fabricantes. Ainda assim, ambas apontam para a mesma área de atenção: código adicional com privilégios elevados pode introduzir caminhos de escalada que ultrapassam as proteções tradicionais do Android.
Isso não significa que componentes proprietários sejam necessariamente inseguros. O ponto é que eles ampliam a superfície que precisa ser auditada, atualizada e submetida a testes de segurança independentes.
Conclusão e como se proteger
A falha de segurança OnePlus descrita por Moorats representa uma vulnerabilidade de escalação local de privilégios, e essa distinção é fundamental. Não se trata de uma falha que permita simplesmente invadir qualquer OnePlus pela internet.
O atacante precisa primeiro conseguir fazer com que um aplicativo malicioso seja instalado e executado no dispositivo. A partir desse ponto, porém, a aplicação não precisa solicitar permissões especiais para iniciar a cadeia descrita na pesquisa.
Até a publicação da pesquisa, não havia evidências públicas apresentadas de que essas vulnerabilidades estivessem sendo exploradas em ataques reais. A OnePlus também não havia publicado uma correção específica para os problemas descritos por Moorats.
Para reduzir o risco enquanto não existe uma correção específica, usuários devem evitar instalar APKs de fontes desconhecidas, desconfiar de aplicativos distribuídos fora de canais confiáveis e remover softwares que não reconheçam ou não utilizem. Manter o Android e o OxygenOS atualizados também continua sendo uma medida essencial.
É importante, porém, não confundir essas precauções com uma correção definitiva. Somente uma atualização de segurança da fabricante pode eliminar as vulnerabilidades nos componentes afetados.
A responsabilidade final envolve revisar as verificações de autorização do AtlasService, corrigir o mecanismo explorado no olc2, auditar serviços semelhantes e comunicar claramente aos usuários quais aparelhos e versões estão vulneráveis.
O episódio também deixa uma questão relevante para a comunidade de segurança: qual deve ser o equilíbrio entre o tempo necessário para uma fabricante corrigir uma vulnerabilidade e a necessidade de informar usuários quando uma falha permanece sem solução?
Esse debate ganha ainda mais importância à medida que fabricantes adicionam novas camadas proprietárias ao Android. Quanto maior o número de serviços privilegiados executados no smartphone, maior é a necessidade de auditorias independentes e de processos transparentes para receber, corrigir e divulgar vulnerabilidades.
