Tornar al Blog

El pedaç d'agost trenca la impressió en apps WPF: les tres sortides, amb el compte fet

Impressora làser d'oficina amb la safata de paper oberta i fulls a mig sortir

Windows diu que Calibri no compleix l'especificació de format. Ho diu d'una tipografia que instal·la ell mateix, a C:\WINDOWS\FONTS, i ho va començar a dir l'11 d'agost.

L'error literal, tal com el va enganxar qui va obrir la incidència al repositori de WPF, és aquest:

System.IO.FileFormatException: 'file:///C:/WINDOWS/FONTS/CALIBRIB.TTF' file does not conform to the expected file format specification.

Apareix en imprimir o en exportar a PDF/XPS des d'una aplicació d'escriptori WPF. No en totes: en les que fan servir Calibri, Cambria, Constantia o Corbel. És a dir, en les que fan servir les tipografies que porta Windows de sèrie i que arrosseguen les plantilles corporatives de mig país. Microsoft ho va reconèixer per escrit el 24 d'agost, tretze dies després de publicar el pedaç que ho provoca, i de moment l'únic que ofereix és un apanyo.

Les dates, que aquí importen

L'11 d'agost va sortir el cicle mensual de Microsoft. Quants errors corregeix depèn de a qui li preguntis: BleepingComputer en compta 400 i avisa expressament que només compta el que es va publicar aquell dia, deixant fora el que ja s'havia corregit abans d'agost a Mariner, Teams, Azure, Entra, Office i Power Apps; SecurityWeek en compta 421. El desglossament fi el dóna només BleepingComputer: 42 de crítics, 37 dels quals d'execució remota de codi, i tres errors de dia zero, dos de divulgats públicament i un ja explotat. En aquest últim sí que coincideixen tots dos: CVE-2026-68820, al driver de WinSock. Que ni tan sols el recompte del que es publica un dimarts sigui un número net ja diu prou de l'escala del problema, i d'això ja en vam escriure al juliol, quan el cicle va arribar a 622 pedaços.

Dins d'aquell lot hi anaven els acumulatius de .NET Framework: KB5120708 per a Windows 11 25H2, KB5120710 per a 24H2, KB5120713 per a 23H2, KB5120705 i KB5121650 per a Windows Server 2022, KB5120698 i KB5120703 per a Windows 10 1809 i Server 2019. La llista de plataformes afectades que publica Microsoft va de Windows 10 i 11 a Windows Server des del 2012 fins al 2025. No és cap racó.

El dia 12, és a dir l'endemà, algú va obrir la incidència al repositori públic de WPF amb el bolcat de l'error i la llista de tipografies: quatre famílies i quinze variants —les quatre de Calibri, Constantia i Corbel, i tres de Cambria, que se'n salva la rodona—. El dia 24, Microsoft va afegir el problema a la secció d'incidències conegudes dels KB. Entre una cosa i l'altra, dotze dies en què qui es va menjar el marró va ser el tècnic que atenia el tiquet de «no m'imprimeix des d'ahir» sense cap nota oficial que el recolzés.

Què apaga exactament l'interruptor

La solució provisional de Microsoft és afegir això al fitxer de configuració de l'aplicació:

<AppContextSwitchOverrides value="Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true"/>

El nom de l'interruptor és, per variar, honest: desactiva la protecció contra desbordament a les taules cmap i sbit de TtfDelta, el component natiu que WPF fa servir per retallar una tipografia TrueType i quedar-se només amb els glifs que el document necessita. I aquesta protecció és, paraula per paraula, el que el pedaç d'agost venia a posar.

El mateix KB5120708 llista les sis vulnerabilitats que corregeix: CVE-2026-65810 i CVE-2026-62872 d'elevació de privilegis, CVE-2026-62886, CVE-2026-62897 i CVE-2026-70354 d'execució remota de codi, i CVE-2026-62902 de divulgació d'informació. Microsoft titula la segona d'aquestes tres amb la seva parquedat habitual —«.NET Remote Code Execution Vulnerability»— i la descriu com un desbordament d'enters que «permet a un atacant no autoritzat executar codi localment». On viu exactament ho explica l'anàlisi de tercers i no l'avís: al mateix component natiu de retall de tipografies, i l'enduriment que ho tapa és el del pull request 11642 del repositori de WPF, fusionat el 18 de maig, que va reescriure tretze fitxers del directori de TtfDelta. L'escenari és el que es pot esperar: una tipografia TrueType manipulada dins d'un document XPS o de contingut XAML desborda l'aritmètica, el sistema reserva un búfer més petit del que toca i s'hi escriu a fora.

Microsoft es queda en un avís genèric —l'interruptor «pot augmentar l'exposició a les vulnerabilitats corregides per aquesta actualització», i recomana fer-lo servir «només com a mesura temporal i només quan sigui necessari»—. Nosaltres ho diríem amb menys diplomàcia: el nom de l'interruptor i el canvi que corregeix la CVE apunten al mateix desbordament al mateix component. Això no és apagar una comprovació menor. És tornar, en aquella aplicació, a l'estat previ al pedaç en el camí concret que algú es va molestar a trobar.

La dada que ofèn és en una taula que ningú no necessita

La incidència del repositori de WPF inclou una anàlisi de per què es trenca, signada per qui la va obrir i no per Microsoft, així que llegeix-la amb aquesta etiqueta posada. Segons aquesta anàlisi, aquestes quatre famílies arrosseguen una taula heretada de kerning —la que defineix quant s'acosten entre si dues lletres— amb un camp de longitud de 16 bits que ha donat la volta. La comprovació de límits que afegeix el pedaç rebutja la tipografia sencera en lloc de saltar-se aquella taula, que és opcional i que el retallador de glifs ni tan sols necessita per fer la seva feina.

La correlació que publica és neta, i és el que dóna pes a l'anàlisi: fallen les quinze tipografies amb una taula kern de més de 65.535 bytes, i funcionen les deu que no hi arriben. A calibrib.ttf, el directori declara 160.164 bytes i el camp de 16 bits es queda en 29.088, que és exactament el que sobra en dividir entre 65.536. L'enduriment que dispara tot això va arribar al maig, en un canvi que va reescriure tretze fitxers d'aquell component; ha trigat tres mesos a arribar a les màquines de la gent.

Si això és així, i encaixa amb tota la resta, la conclusió és incòmoda per a totes dues parts: la tipografia de Windows fa anys que porta un camp mal format que ningú no mirava, i l'arranjament es va passar de frenada rebutjant el fitxer sencer. No és un cas de «seguretat contra comoditat». És una comprovació massa àmplia, i per això hi ha arranjament pendent en comptes d'un dilema permanent.

Les tres sortides, amb el compte fet

Mentre arriba l'arranjament definitiu hi ha tres maneres de sortir-se'n i cap no és de franc. El que canvia entre elles és a què li poses el preu.

1. Posar l'interruptor

El primer que cal entendre és l'abast. Al KB, Microsoft documenta una sola via: el fitxer de configuració d'una aplicació, on l'interruptor afecta aquell programa i cap més. Convé saber que n'hi ha una altra, perquè és la que temptarà algú: la documentació d'AppContext del .NET Framework permet fixar qualsevol d'aquests interruptors al registre, sota HKLM\SOFTWARE\Microsoft\.NETFramework\AppContext —i a Wow6432Node en sistemes de 64 bits—, i allà l'abast és de màquina: «afecta totes les aplicacions que s'executen a la màquina», diu Microsoft amb aquestes paraules. És a dir, es pot repartir per directiva de grup a tres-cents equips en deu minuts. No ho facis. Això reobre el camí a tot el que corri sobre .NET en aquelles màquines, inclòs el que obre fitxers que vénen de fora. Si poses l'interruptor, posa'l al fitxer de configuració del programa que tu decideixis.

Amb això, la pregunta es torna contestable: aquella aplicació concreta obre tipografies que vénen de fora? El programa de gestió que imprimeix albarans amb les tipografies de Windows sobre dades de la teva base de dades no es troba en la mateixa situació que un visor que obre documents XPS que arriben per correu. El primer pot conviure amb l'interruptor unes setmanes; el segon és exactament l'escenari d'atac de la CVE. Microsoft no pot respondre això per tu perquè depèn de què fa el teu programa, i aquí és on algú ha de pensar en comptes d'aplicar una recepta.

2. Treure l'acumulatiu de .NET

Aquí hi ha un matís que es perd a gairebé tota la cobertura i que canvia la decisió: el paquet que trenca la impressió és l'acumulatiu de .NET Framework, que és un KB diferent de l'acumulatiu de Windows. Aquest mes, a més, hi ha hagut regressions als dos: la d'impressió va pel costat de .NET, i la dels jocs que es tanquen sols —la que Microsoft ha acabat atribuint als drivers de baix nivell que instal·len alguns perifèrics amb llums RGB— va per l'acumulatiu de Windows, un altre paquet.

La conseqüència pràctica: treure l'acumulatiu de .NET no et deixa el dia zero de WinSock sense pedaç, perquè aquell va a l'altre paquet. El que perds són les sis CVE de .NET, tres d'elles d'execució remota. És una sortida més àmplia que l'interruptor —afecta tot el que corri sobre .NET en aquella màquina, no una aplicació— i força més estreta que deixar el cicle d'agost sense aplicar. Té sentit en una màquina concreta que només fa una cosa i que no pot deixar de fer-la mentre prepares una altra sortida; no en té com a política general.

3. Canviar la tipografia

La tercera sortida, i en molts llocs la barata. Si el que es trenca és el retall d'aquelles quatre famílies, un document maquetat amb una altra tipografia no passa pel camí trencat. Toques la plantilla, no el sistema; no acceptes cap risc de seguretat, i quan arribi l'arranjament no hi ha res a revertir.

Amb dos advertiments honestos. El primer: no sempre es pot. Un certificat, un diploma o un contracte amb la tipografia corporativa no es canvia per decret d'un tècnic un dimarts a la tarda. El segon, i aquest sí que és important: no ho hem comprovat a totes les aplicacions, i si el programa incrusta la tipografia pel seu compte, o el document la porta a dins, canviar el que veus a la pantalla pot no canviar el que arriba al retallador. Abans de reescriure cinquanta plantilles, prova-ho amb una.

La decisió no hauria de ser del parc: és de cada aplicació

Posada així, la comparació es fa sola. Si comptes màquines, en tens tres-centes, i qualsevol decisió que prenguis sobre tres-centes màquines és cara i lenta. Si comptes aplicacions d'escriptori WPF que imprimeixen o exporten a PDF, a la majoria d'empreses amb què treballem no passen d'un grapat. Aquí la decisió és barata, i a més és diferent per a cadascuna: l'interruptor per a la de gestió, la tipografia per a les plantilles de l'oficina, i treure l'acumulatiu només en aquell equip rar que fa deu anys que fa una sola cosa.

La part difícil no és decidir: és saber a qui li passa. Ningú no té un inventari de «quins programes del meu parc estan fets en WPF i exporten a PDF». Això no surt a cap panell i no ho sap ni el fabricant del programa la meitat de les vegades. El que sí que pots fer aquesta tarda és buscar FileFormatException als tiquets de les dues últimes setmanes. Si l'error ja hi era i ningú no l'havia relacionat amb el pedaç, ja tens l'inventari fet, i de franc.

Això és, literalment, en què consisteix el manteniment: no a aplicar el pedaç —això ho fa una tasca programada—, sinó a saber què tens, en quin ordre es toca i com es torna enrere. Ja ho vam escriure a propòsit d'un pla de tornada enrere en una migració: la part que decideix si una intervenció es pot fer un dimarts és la que ningú no ensenya a la demo.

El que no faríem

  • Posar l'interruptor «per si de cas» a tot el que arrenqui. Converteix una regressió de quatre tipografies en una excepció de seguretat permanent que ningú no recordarà treure el dia que arribi l'arranjament. I arribarà: Microsoft diu que continua investigant i que busca una solució definitiva.
  • Endarrerir el cicle sencer d'agost per això. És la reacció instintiva i és la més cara: pagues amb les 42 crítiques i amb un dia zero que ja s'estava explotant per estalviar-te un problema que és a un altre paquet i que es pot acotar per aplicació.
  • Donar per fet que el fabricant del programa ja ho sap. Moltes aplicacions de gestió petites les manté un equip de tres persones que se n'assabenta per tu. Escriu-los amb el nom de l'excepció i el de l'interruptor: els estalvies la tarda que tu ja has perdut, i de passada sabràs si pensen treure versió o esperar Microsoft.
  • Activar l'interruptor sense deixar-ho per escrit. Si acceptes aquell risc, acceptar-lo és una decisió legítima; no anotar-la no ho és. Data, aplicació, qui ho va decidir i quan es revisa. Una excepció sense data de caducitat deixa de ser una excepció i passa a ser la teva configuració.

Quan això no va amb tu

Si a la teva empresa no hi ha aplicacions d'escriptori fetes en WPF que imprimeixin o exportin a PDF —i hi ha moltes empreses que viuen al navegador i a l'Office—, això és soroll de fons. El camí que es trenca és el del retallador de tipografies de WPF; ningú no ha publicat que el Word ni un navegador hi passin. Pots tancar aquesta pestanya.

I un advertiment en sentit contrari, per no vendre-te-la: la majoria dels tiquets d'impressió d'aquest agost no són això. Continuen sent el driver, la cua encallada i l'equip que ha canviat de subxarxa. Si l'error que veus no diu FileFormatException, no és aquest problema, i culpar el pedaç et costarà una tarda.

Totes dues coses són veritat alhora

El pedaç va fer la seva feina: va tancar tres forats d'execució remota en un component que processa fitxers que poden venir de qualsevol lloc. I va trencar imprimir amb les tipografies de tota la vida. Discutir si «cal pedaçar o no» a partir d'aquí no porta enlloc, perquè la resposta és que sí i ja ho sabem; també quan la pressa la marca un termini de tres dies i no un dimarts qualsevol.

La pregunta útil és més petita i força més incòmoda: quines aplicacions teves imprimeixen, i qui decideix per quina de les tres sortides va cadascuna? Si aquesta pregunta no té amo avui, la contestarà d'aquí a tres setmanes qui agafi el telèfon quan algú no pugui treure una factura.

Fonts: incidència coneguda, text del workaround, l'interruptor Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection i la llista de les sis CVE corregides — KB5120708, Microsoft Support, 11-ag.-2026; reconeixement del 24 d'agost, llista de plataformes afectades de Windows 10/11 i Server 2012 a 2025 i advertiment sobre l'exposició — BleepingComputer, 24-ag.-2026 i BetaNews; bolcat de l'error, les quatre famílies amb les seves quinze variants i l'anàlisi de la taula kern —signada per qui va obrir la incidència, no per Microsoft— dotnet/wpf, incidència 11834, oberta el 12-ag.-2026; recompte del cicle (400 amb la seva metodologia declarada, 42 crítiques, tres dies zero i CVE-2026-68820 explotat) — BleepingComputer, 11-ag.-2026 i el recompte alternatiu de 421 CVE de SecurityWeek; regressió dels jocs atribuïda a drivers de perifèrics RGB — BleepingComputer; abast de màquina dels interruptors d'AppContext fixats al registre — documentació de System.AppContext, Microsoft Learn; títol i descripció de CVE-2026-62897GitHub Advisory GHSA-fx4q-gjrx-2jw6, i la seva ubicació al component de retall de tipografies — SecureLayer7 Labs; el canvi que va introduir l'enduriment — dotnet/wpf, pull request 11642.

Saps quines aplicacions teves imprimeixen?

A everyWAN el manteniment informàtic inclou la part avorrida: saber què corre a cada màquina, en quin ordre es pedaça i com es torna enrere. I quan toca acceptar un risc temporal, ho deixem escrit amb data i amo, que és del que va el compliment i la continuïtat. Si el que ja tens muntat funciona, t'ho direm.

Parlar amb everyWAN

Etiquetes:

Compartir:

Subscriu-te al nostre butlletí

Per rebre històries del món IT, novetats d'everyWAN i ofertes exclusives per a subscriptors, dona't d'alta a la nostra llista de correu

everyWAN
everyWAN