CVE-2026-83991: substituindo um arquivo que o chamador não pode excluir

Mantive estas linhas próximas umas das outras porque separá-las faz o bug parecer mais complicado do que é:

CreateFileW, GENERIC_WRITE             error 5
DeleteFileW                            error 5
CfCreatePlaceholders, SUPERSEDE        S_OK
per-entry Result                       S_OK

A abertura de escrita, a tentativa de exclusão e a chamada ao Cloud Files usam o mesmo pathname e o mesmo token de thread. Antes da última chamada, o nome pertence a um arquivo comum com uma DACL protegida e sem reparse point. Depois dela, FSCTL_GET_REPARSE_POINT retorna IO_REPARSE_TAG_CLOUD.

A Microsoft publicou esse resultado como CVE-2026-83991, a Vulnerabilidade de Adulteração do Driver de Minifiltro do Windows Cloud Files. Eu a havia descrito no relatório como autorização incorreta e sugerido CWE-863. A Microsoft atribuiu CWE-306 em vez disso.

O programa instala seu token de representação restrito antes de criar o diretório de teste, o arquivo, as DACLs ou o sync root. Não há uma configuração elevada seguida de uma troca de token apenas para a chamada interessante. Se a conta tiver um SID de Administrators, CreateRestrictedToken o torna deny-only; se o SID nunca esteve presente, o programa registra esse caso também. A integridade é definida como Medium.

O pai e a folha deliberadamente não têm DACLs correspondentes. O usuário atual recebe isto no diretório:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

O arquivo existente recebe FILE_GENERIC_READ, e sua DACL é protegida contra herança. SYSTEM e Administrators mantêm controle total. Como o SID de Administrators do token está ausente ou é deny-only, a ACE de permissão de Administrators não pode conceder acesso a esta thread.

O bit DELETE no pai parece suspeito até que o objeto ao qual ele se aplica seja explicitado. Ele permite a exclusão do próprio diretório. Excluir um de seus filhos é FILE_DELETE_CHILD, um bit diferente que a ACE do pai não contém. DeleteFileW aceita DELETE na folha ou permissão delete-child no pai. O teste não tem nenhum dos dois, e é por isso que o erro 5 é o resultado de controle esperado.

Deixei FILE_GENERIC_WRITE no pai. Seu bit FILE_WRITE_DATA é FILE_ADD_FILE quando o objeto é um diretório. O chamador pode criar um filho, e o pai, portanto, atende ao requisito documentado de WRITE_DATA ou WRITE_DAC para CfCreatePlaceholders. Sem esse direito, a API falha em sua verificação de diretório base antes de chegar ao caso que relatei.

O programa não registrará o sync root a menos que este bloco seja verdadeiro:

write open denied with ERROR_ACCESS_DENIED
DeleteFileW denied with ERROR_ACCESS_DENIED
read open succeeded
leaf DACL protected
starting object not a reparse point

Fiz com que ele parasse aí porque um S_OK mais adiante na execução seria inútil se a folha já fosse gravável, excluível ou um reparse point.

Após esses controles, o programa registra o pai como um sync root, conecta-o com uma tabela de callback contendo apenas a entrada de terminação e envia o nome de arquivo existente com a flag 0x4:

placeholder.RelativeFileName = leaf_name;
placeholder.FsMetadata.BasicInfo = basic_info;
placeholder.FsMetadata.FileSize = standard_info.EndOfFile;
placeholder.FileIdentity = &run_id;
placeholder.FileIdentityLength = sizeof(run_id);
placeholder.Flags = CF_CREATE_SUPERSEDE;

create_hr = cf.Create(root, &placeholder, 1, 0, &processed);

CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE está documentado como sobrescrevendo um placeholder existente. Este arquivo não é um. O PoC define FILE_ATTRIBUTE_NORMAL antes de aplicar a DACL da folha e confirma que o bit de reparse point está limpo antes de chamar o Cloud Files.

No sistema afetado, a chamada em lote e a entrada retornaram ambas S_OK, e CreateUsn era diferente de zero. O arquivo adquiriu o atributo de reparse point. Pedir ao sistema de arquivos os dados de reparse retornou a tag 0x9000001A, que é IO_REPARSE_TAG_CLOUD.

EntriesProcessed == 1 não prova sucesso porque a documentação da API conta entradas com falha também. A confirmação vem de ambos os HRESULTs, do USN de criação, do atributo de reparse e da tag Cloud.

FILE_ID_INFO permaneceu inalterado durante a chamada. O objeto de arquivo existente adquiriu estado do Cloud Files; outro arquivo não apenas apareceu sob o mesmo pathname.

A build afetada mais antiga listada pela MSRC é 17763.0, a geração do Windows 10 versão 1809 e Windows Server 2019. Isso coloca o rastro público em 2018, quase oito anos antes da correção de setembro de 2026.