El curiós de CVE-2026-40372 és d’on va sortir. No va ser un error amagat durant anys, sinó una cosa que Microsoft va introduir en el seu propi pedaç del Patch Tuesday d’abril. L’actualització .NET 10.0.6 del 14 d’abril va ficar una regressió al component de xifratge d’ASP.NET Core, i una setmana després l’empresa va haver de publicar la 10.0.7 fora de banda per arreglar el destrossa.
Què falla exactament
ASP.NET Core Data Protection és la peça que xifra i signa dades sensibles en una aplicació web: cookies d’autenticació, tokens antiforgery, estat d’OIDC, TempData i similars. La seva feina és assegurar que un client no pugui manipular aquests valors sense que el servidor se n’adoni.
A partir de la versió 10.0.6 del paquet NuGet Microsoft.AspNetCore.DataProtection, el xifrador autenticat va començar a calcular l’HMAC de validació sobre els bytes equivocats del payload i, en determinats casos, descartava directament el hash calculat. La comprovació d’integritat va deixar de servir per a res. Un atacant podia construir un payload falsificat que passava com a autèntic, perquè la rutina de validació ja no comparava el que havia de comparar. Els payloads falsos generats durant la finestra vulnerable portaven bytes d’HMAC tots a zero, un detall que després va servir perquè la versió corregida els rebutgés.
A qui afecta i amb quina gravetat
Afecta les versions 10.0.0 a 10.0.6 del paquet Microsoft.AspNetCore.DataProtection, tot i que la regressió que trenca la validació es va introduir a la 10.0.6. Qualsevol aplicació ASP.NET Core amb .NET 10 que faci servir Data Protection i exposi endpoints a la xarxa entra dins l’abast.
La puntuació és CVSS 9.1, crítica. Amb la validació trencada, un atacant no autenticat pot falsificar cookies d’autenticació i fer-se passar per qualsevol usuari, inclòs un amb privilegis de nivell SYSTEM. A més pot desxifrar payloads protegits prèviament, cosa que obre la porta a llegir tokens de sessió, estat OIDC i altres dades que es donaven per xifrades. No hi ha impacte en la disponibilitat: el problema és de confidencialitat i integritat, que en aquest context és el més car.
Mitigació: actualitzar no n’hi ha prou
Microsoft va publicar la 10.0.7 el 21 d’abril com a actualització fora de banda. Però apedaçar i desplegar només tanca la ferida; no neteja el que hi pugui haver entrat.
Si la teva aplicació va estar exposada a internet durant la finestra vulnerable, cal rotar el key ring de Data Protection. Això invalida qualsevol token que un atacant hagués pogut falsificar, més qualsevol token legítim que l’aplicació hagués emès durant aquell període i que ara no puguis distingir d’un de fraudulent. Sense la rotació, un token falsificat continuaria sent vàlid encara que el codi ja estigui corregit.
El resum pràctic: pujar Microsoft.AspNetCore.DataProtection a 10.0.7 o posterior, tornar a desplegar i rotar les claus. Com més aviat millor, sobretot si l’aplicació és de cara al públic.