El parche de agosto rompe la impresión en apps WPF: las tres salidas, con la cuenta hecha

Windows dice que Calibri no cumple la especificación de formato. Lo dice de una fuente que instala él mismo, en C:\WINDOWS\FONTS, y lo empezó a decir el 11 de agosto.

El error literal, tal y como lo pegó quien abrió la incidencia en el repositorio de WPF, es este:

Aparece al imprimir o al exportar a PDF/XPS desde una aplicación de escritorio WPF. No en todas: en las que usan Calibri, Cambria, Constantia o Corbel. Es decir, en las que usan las tipografías que trae Windows de serie y que arrastran las plantillas corporativas de media España. Microsoft lo reconoció por escrito el 24 de agosto, trece días después de publicar el parche que lo provoca, y de momento lo único que ofrece es un apaño.

Las fechas, que aquí importan

El 11 de agosto salió el ciclo mensual de Microsoft. Cuántos fallos corrige depende de a quién le preguntes: BleepingComputer cuenta 400 y avisa expresamente de que solo cuenta lo publicado ese día, dejando fuera lo que ya se había corregido antes de agosto en Mariner, Teams, Azure, Entra, Office y Power Apps; SecurityWeek cuenta 421. El desglose fino lo da solo BleepingComputer: 42 críticos, 37 de ellos de ejecución remota de código, y tres fallos de día cero, dos divulgados públicamente y uno ya explotado. En ese último sí coinciden los dos: CVE-2026-68820, en el driver de WinSock. Que ni siquiera el recuento de lo que se publica un martes sea un número limpio ya dice bastante de la escala del problema, y de eso ya escribimos en julio, cuando el ciclo llegó a 622 parches.

Dentro de ese lote iban los acumulativos de .NET Framework: KB5120708 para Windows 11 25H2, KB5120710 para 24H2, KB5120713 para 23H2, KB5120705 y KB5121650 para Windows Server 2022, KB5120698 y KB5120703 para Windows 10 1809 y Server 2019. La lista de plataformas afectadas que publica Microsoft va de Windows 10 y 11 a Windows Server desde 2012 hasta 2025. No es un rincón.

El día 12, es decir al día siguiente, alguien abrió la incidencia en el repositorio público de WPF con el volcado del error y la lista de tipografías: cuatro familias y quince variantes —las cuatro de Calibri, Constantia y Corbel, y tres de Cambria, cuya redonda se salva—. El día 24, Microsoft añadió el problema a la sección de incidencias conocidas de los KB. Entre una cosa y otra, doce días en los que el que se comió el marrón fue el técnico que atendía el ticket de «no me imprime desde ayer» sin ninguna nota oficial que lo respaldara.

Qué apaga exactamente el interruptor

La solución provisional de Microsoft es añadir esto al fichero de configuración de la aplicación:

El nombre del interruptor es, para variar, honesto: desactiva la protección contra desbordamiento en las tablas cmap y sbit de TtfDelta, el componente nativo que WPF usa para recortar una fuente TrueType y quedarse solo con los glifos que el documento necesita. Y esa protección es, palabra por palabra, lo que el parche de agosto venía a poner.

El propio KB5120708 lista las seis vulnerabilidades que corrige: CVE-2026-65810 y CVE-2026-62872 de elevación de privilegios, CVE-2026-62886, CVE-2026-62897 y CVE-2026-70354 de ejecución remota de código, y CVE-2026-62902 de divulgación de información. Microsoft titula la segunda de esas tres con su parquedad habitual —«.NET Remote Code Execution Vulnerability»— y la describe como un desbordamiento de enteros que «permite a un atacante no autorizado ejecutar código localmente». Dónde vive exactamente lo cuenta el análisis de terceros y no el aviso: en el mismo componente nativo de recorte de fuentes, y el endurecimiento que lo tapa es el del pull request 11642 del repositorio de WPF, fusionado el 18 de mayo, que reescribió trece ficheros del directorio de TtfDelta. El escenario es el que cabe esperar: una fuente TrueType manipulada dentro de un documento XPS o de contenido XAML desborda la aritmética, el sistema reserva un búfer más pequeño de lo que toca y se escribe fuera de él.

Microsoft se queda en un aviso genérico —el interruptor «puede aumentar la exposición a las vulnerabilidades corregidas por esa actualización», y recomienda usarlo «solo como medida temporal y solo cuando sea necesario»—. Nosotros lo diríamos con menos diplomacia: el nombre del interruptor y el cambio que corrige la CVE apuntan al mismo desbordamiento en el mismo componente. Esto no es apagar una comprobación menor. Es volver, en esa aplicación, al estado previo al parche en el camino concreto que alguien se molestó en encontrar.

El dato que ofende está en una tabla que nadie necesita

La incidencia del repositorio de WPF incluye un análisis de por qué se rompe, firmado por quien la abrió y no por Microsoft, así que léelo con esa etiqueta puesta. Según ese análisis, esas cuatro familias arrastran una tabla heredada de kerning —la que define cuánto se acercan entre sí dos letras— con un campo de longitud de 16 bits que se ha dado la vuelta. La comprobación de límites que añade el parche rechaza la fuente entera en lugar de saltarse esa tabla, que es opcional y que el recortador de glifos ni siquiera necesita para hacer su trabajo.

La correlación que publica es limpia, y es lo que da peso al análisis: fallan las quince fuentes cuya tabla kern pasa de 65.535 bytes, y funcionan las diez que no llegan. En calibrib.ttf, el directorio declara 160.164 bytes y el campo de 16 bits se queda en 29.088, que es exactamente lo que sobra al dividir entre 65.536. El endurecimiento que dispara todo esto llegó en mayo, en un cambio que reescribió trece ficheros de ese componente; ha tardado tres meses en llegar a las máquinas de la gente.

Si eso es así, y encaja con todo lo demás, la conclusión es incómoda para las dos partes: la fuente de Windows lleva años con un campo mal formado que nadie miraba, y el arreglo se pasó de frenada rechazando el fichero completo. No es un caso de «seguridad contra comodidad». Es una comprobación demasiado amplia, y por eso hay arreglo pendiente en vez de un dilema permanente.

Las tres salidas, con la cuenta hecha

Mientras llega el arreglo definitivo hay tres formas de salir del paso y ninguna es gratis. Lo que cambia entre ellas es a qué le pones el precio.

1. Poner el interruptor

Lo primero que hay que entender es el alcance. En el KB, Microsoft documenta una sola vía: el fichero de configuración de una aplicación, donde el interruptor afecta a ese programa y a ninguno más. Conviene saber que existe otra, porque es la que va a tentar a alguien: la documentación de AppContext del .NET Framework permite fijar cualquiera de estos interruptores en el registro, bajo HKLM\SOFTWARE\Microsoft\.NETFramework\AppContext —y en Wow6432Node en sistemas de 64 bits—, y ahí el alcance es de máquina: «afecta a todas las aplicaciones que se ejecutan en la máquina», dice Microsoft con esas palabras. Es decir, se puede repartir por directiva de grupo a trescientos equipos en diez minutos. No lo hagas. Eso reabre el camino en todo lo que corra sobre .NET en esas máquinas, incluido lo que abre ficheros que vienen de fuera. Si pones el interruptor, ponlo en el fichero de configuración del programa que tú decidas.

Con eso, la pregunta se vuelve contestable: ¿esa aplicación concreta abre fuentes que vienen de fuera? El programa de gestión que imprime albaranes con las tipografías de Windows sobre datos de tu base de datos no está en la misma situación que un visor que abre documentos XPS que llegan por correo. La primera puede convivir con el interruptor unas semanas; la segunda es exactamente el escenario de ataque de la CVE. Microsoft no puede responder esto por ti porque depende de qué hace tu programa, y ahí es donde alguien tiene que pensar en vez de aplicar una receta.

2. Quitar el acumulativo de .NET

Aquí hay un matiz que se pierde en casi toda la cobertura y que cambia la decisión: el paquete que rompe la impresión es el acumulativo de .NET Framework, que es un KB distinto del acumulativo de Windows. Este mes, además, ha habido regresiones en los dos: la de impresión va por el lado de .NET, y la de los juegos que se cierran solos —la que Microsoft ha acabado atribuyendo a los drivers de bajo nivel que instalan algunos periféricos con luces RGB— va por el acumulativo de Windows, otro paquete.

La consecuencia práctica: quitar el acumulativo de .NET no te deja el día cero de WinSock sin parchear, porque ese va en el otro paquete. Lo que pierdes son las seis CVE de .NET, tres de ellas de ejecución remota. Es una salida más amplia que el interruptor —afecta a todo lo que corra sobre .NET en esa máquina, no a una aplicación— y bastante más estrecha que dejar el ciclo de agosto sin aplicar. Tiene sentido en una máquina concreta que solo hace una cosa y que no puede dejar de hacerla mientras preparas otra salida; no lo tiene como política general.

3. Cambiar la tipografía

La tercera salida, y en muchos sitios la barata. Si lo que se rompe es el recorte de esas cuatro familias, un documento maquetado con otra tipografía no pasa por el camino roto. Tocas la plantilla, no el sistema; no aceptas ningún riesgo de seguridad, y cuando llegue el arreglo no hay nada que revertir.

Con dos advertencias honestas. La primera: no siempre se puede. Un certificado, un diploma o un contrato con la tipografía corporativa no se cambia por decreto de un técnico un martes por la tarde. La segunda, y esta es de verdad importante: no lo hemos comprobado en todas las aplicaciones, y si el programa incrusta la fuente por su cuenta, o el documento la trae dentro, cambiar lo que ves en pantalla puede no cambiar lo que llega al recortador. Antes de reescribir cincuenta plantillas, pruébalo con una.

La decisión no debería ser del parque: es de cada aplicación

Puesta así, la comparación se hace sola. Si cuentas máquinas, tienes trescientas, y cualquier decisión que tomes sobre trescientas máquinas es cara y lenta. Si cuentas aplicaciones de escritorio WPF que imprimen o exportan a PDF, en la mayoría de empresas con las que trabajamos no pasan de un puñado. Ahí la decisión es barata, y además es distinta para cada una: el interruptor para la de gestión, la tipografía para las plantillas de la oficina, y quitar el acumulativo solo en aquel equipo raro que lleva diez años haciendo una sola cosa.

La parte difícil no es decidir: es saber a quién le pasa. Nadie tiene un inventario de «qué programas de mi parque están hechos en WPF y exportan a PDF». Eso no sale en ningún panel y no lo sabe ni el fabricante del programa la mitad de las veces. Lo que sí puedes hacer esta tarde es buscar FileFormatException en los tickets de las dos últimas semanas. Si el fallo ya estaba y nadie lo había relacionado con el parche, ahí tienes el inventario hecho, y gratis.

Esto es, literalmente, en qué consiste el mantenimiento: no en aplicar el parche —eso lo hace una tarea programada—, sino en saber qué tienes, en qué orden se toca y cómo se vuelve atrás. Ya lo escribimos a propósito de un plan de vuelta atrás en una migración: la parte que decide si una intervención se puede hacer un martes es la que nadie enseña en la demo.

Lo que no haríamos

Cuándo esto no va contigo

Si en tu empresa no hay aplicaciones de escritorio hechas en WPF que impriman o exporten a PDF —y hay muchas empresas que viven en el navegador y en Office—, esto es ruido de fondo. El camino que se rompe es el del recortador de fuentes de WPF; nadie ha publicado que Word ni un navegador pasen por ahí. Puedes cerrar esta pestaña.

Y una advertencia en sentido contrario, para no vendértela: la mayoría de los tickets de impresión de este agosto no son esto. Siguen siendo el driver, la cola atascada y el equipo que ha cambiado de subred. Si el error que ves no dice FileFormatException, no es este problema, y culpar al parche te va a costar una tarde.

Las dos cosas son verdad a la vez

El parche hizo su trabajo: cerró tres agujeros de ejecución remota en un componente que procesa ficheros que pueden venir de cualquier sitio. Y rompió imprimir con las tipografías de toda la vida. Discutir si «hay que parchear o no» a partir de aquí no lleva a ningún sitio, porque la respuesta es que sí y ya lo sabemos; también cuando la prisa la marca un plazo de tres días y no un martes cualquiera.

La pregunta útil es más pequeña y bastante más incómoda: ¿qué aplicaciones tuyas imprimen, y quién decide por cuál de las tres salidas va cada una? Si esa pregunta no tiene dueño hoy, la va a contestar dentro de tres semanas quien coja el teléfono cuando alguien no pueda sacar una factura.

Fuentes: incidencia conocida, texto del workaround, el interruptor Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection y la lista de las seis CVE corregidas — KB5120708, Microsoft Support, 11-ago-2026; reconocimiento del 24 de agosto, lista de plataformas afectadas de Windows 10/11 y Server 2012 a 2025 y advertencia sobre la exposición — BleepingComputer, 24-ago-2026 y BetaNews; volcado del error, las cuatro familias con sus quince variantes y el análisis de la tabla kern —firmado por quien abrió la incidencia, no por Microsoft— dotnet/wpf, incidencia 11834, abierta el 12-ago-2026; recuento del ciclo (400 con su metodología declarada, 42 críticas, tres días cero y CVE-2026-68820 explotado) — BleepingComputer, 11-ago-2026 y el recuento alternativo de 421 CVE de SecurityWeek; regresión de los juegos atribuida a drivers de periféricos RGB — BleepingComputer; alcance de máquina de los interruptores de AppContext fijados en el registro — documentación de System.AppContext, Microsoft Learn; título y descripción de CVE-2026-62897 — GitHub Advisory GHSA-fx4q-gjrx-2jw6, y su ubicación en el componente de recorte de fuentes — SecureLayer7 Labs; el cambio que introdujo el endurecimiento — dotnet/wpf, pull request 11642.