Imagine comprar um processador e, ao trocar de placa-mãe, descobrir que ele “subiu de categoria” sozinho. Foi o que relatou um usuário no fórum Chiphell ao instalar seu Intel Core Ultra 5 250K Plus em uma placa GIGABYTE B860I AORUS PRO ICE. O sistema passou a identificar o chip como um Core Ultra 7 270K Plus, um modelo teoricamente mais potente e caro.
O CPU-Z, o AIDA64, o HWMonitor e o próprio Windows repetiram o mesmo nome errado, mesmo com a estrutura interna do processador expondo claramente os 18 núcleos reais do modelo mais barato.
O Core Ultra 5 250K Plus tem configuração de 6 núcleos de desempenho e 12 núcleos de eficiência, totalizando 18 núcleos, boost de 5,3 GHz. O Core Ultra 7 270K Plus sobe para 24 núcleos (8P + 16E), clock de 5,5 GHz e patamar de preço maior. Ou seja, o sistema não apenas mostrava um nome trocado, exibia uma identidade que não batia nem na contagem de núcleos visível.
Por que a BIOS consegue confundir o sistema todo
A identificação de um processador no Windows depende de duas fontes distintas: os registros internos do próprio chip (lidos pela instrução CPUID, que retorna família, modelo e stepping) e a string de nome legível por humanos, que a BIOS escreve via tabela SMBIOS e repassa ao sistema operacional. Se esses dois caminhos entram em conflito, ferramentas como CPU-Z e AIDA64 tendem a priorizar a string de texto vinda da BIOS ao exibir o nome comercial, enquanto os dados brutos de CPUID continuam mostrando os valores físicos corretos. O resultado é exatamente o que o usuário do Chiphell viu: o nome exibido aponta para um modelo, mas o número de núcleos e a frequência denunciam outro.
O processador era identificado corretamente na placa Colorful que o usuário usava antes. A migração para a GIGABYTE B860I AORUS PRO ICE foi o gatilho. A hipótese mais coerente é que a BIOS dessa placa contenha uma entrada SMBIOS com a string de nome do 270K Plus associada ao CPUID do 250K Plus — um erro de mapeamento que se propaga por toda a cadeia de software. A GIGABYTE não emitiu comunicado sobre o caso até a publicação desta reportagem, e a página de suporte da B860I AORUS PRO ICE não lista nenhuma atualização de BIOS com correção relacionada à identificação de processador entre os drivers disponibilizados em abril de 2026.
O contexto do CPU-Z e o ataque de 9 de abril
O caso viralizou porque o CPU-Z estava no centro de um incidente de segurança ocorrido entre 9 e 10 de abril de 2026, praticamente ao mesmo tempo em que o relato do Chiphell circulou. Invasores comprometeram uma API secundária do site da CPUID por cerca de seis horas, redirecionando os links de download do CPU-Z, do HWMonitor Pro, do PerfMonitor e do PowerMAX para arquivos infectados hospedados em buckets do Cloudflare R2. O malware distribuído foi identificado como STX RAT, um trojan de acesso remoto.
Samuel Demeulemeester, contribuidor da CPUID, confirmou em nota publicada no X que os binários originais assinados digitalmente não foram adulterados, o ataque substituiu apenas os links de download, não os arquivos armazenados nos servidores da empresa. O pesquisador de segurança Giuseppe Massaro foi quem identificou que os pacotes servidos durante o período do ataque eram trojanizados, e que os redirecionamentos apontavam para URLs externas, não para o servidor legítimo da CPUID. O incidente foi corrigido horas depois da detecção.
O erro de identificação do Core Ultra 5 250K Plus não tem relação com esse ataque. Quem reproduz o bug vê o mesmo comportamento mesmo com versões assinadas e verificadas das ferramentas, porque o problema está na string que a própria BIOS da GIGABYTE entrega ao sistema, não no software de monitoramento.
Esta postagem foi modificada pela última vez em 13/04/2026 20:00