August's patch broke printing in WPF apps: the three ways out, with the maths done

Windows says Calibri does not conform to the expected file format. It says this about a font it installs itself, in C:\WINDOWS\FONTS, and it started saying it on 11 August.

The literal error, as pasted by whoever opened the issue in the WPF repository, is this:

It shows up when printing or exporting to PDF/XPS from a WPF desktop application. Not all of them: the ones using Calibri, Cambria, Constantia or Corbel. In other words, the ones using the fonts Windows ships by default and that half the corporate templates out there still drag around. Microsoft acknowledged it in writing on 24 August, thirteen days after shipping the patch that causes it, and so far all it offers is a stopgap.

The dates, which matter here

Microsoft's monthly cycle shipped on 11 August. How many flaws it fixes depends who you ask: BleepingComputer counts 400 and explicitly notes it only counts what was released that day, leaving out what had already been fixed earlier in the month across Mariner, Teams, Azure, Entra, Office and Power Apps; SecurityWeek counts 421. The fine-grained breakdown comes from BleepingComputer alone: 42 critical, 37 of them remote code execution, and three zero-days, two publicly disclosed and one already exploited. On that last one they do agree: CVE-2026-68820, in the WinSock driver. That not even the count of what ships on a Tuesday is a clean number says plenty about the scale of the thing, and we already wrote about that in July, when the cycle hit 622 patches.

That batch included the .NET Framework cumulative updates: KB5120708 for Windows 11 25H2, KB5120710 for 24H2, KB5120713 for 23H2, KB5120705 and KB5121650 for Windows Server 2022, KB5120698 and KB5120703 for Windows 10 1809 and Server 2019. The list of affected platforms Microsoft publishes runs from Windows 10 and 11 to Windows Server from 2012 through 2025. This is not a corner case.

On the 12th — the very next day — someone opened an issue in the public WPF repository with the error dump and the list of fonts: four families and fifteen faces — all four of Calibri, Constantia and Corbel, and three of Cambria, whose regular escapes. On the 24th, Microsoft added the problem to the known issues section of the KB articles. In between, twelve days in which the person carrying it was the technician handling the "it hasn't printed since yesterday" ticket with no official note to back them up.

What the switch actually turns off

Microsoft's interim workaround is adding this to the application's configuration file:

The switch's name is, for once, honest: it disables the overflow protection in the cmap and sbit tables of TtfDelta, the native component WPF uses to subset a TrueType font down to just the glyphs a document needs. And that protection is, word for word, what the August patch was there to add.

That same KB5120708 lists the six vulnerabilities it fixes: CVE-2026-65810 and CVE-2026-62872, elevation of privilege; CVE-2026-62886, CVE-2026-62897 and CVE-2026-70354, remote code execution; and CVE-2026-62902, information disclosure. Microsoft titles the second of those three with its usual terseness — ".NET Remote Code Execution Vulnerability" — and describes it as an integer overflow that "allows an unauthorized attacker to execute code locally". Where it actually lives comes from third-party analysis rather than the advisory: the same native font-subsetting component, and the hardening that closes it is pull request 11642 in the WPF repository, merged on 18 May, which rewrote thirteen files in the TtfDelta directory. The scenario is what you would expect: a crafted TrueType font inside an XPS document or XAML content overflows the arithmetic, the runtime allocates a smaller buffer than it should, and the write lands outside it.

Microsoft stops at a generic warning — the switch "may increase exposure to the vulnerabilities addressed by that update", and it recommends using it "only as a temporary measure and only when required". We would put it less diplomatically: the switch's name and the change that fixes the CVE point at the same overflow in the same component. This is not turning off a minor check. It is going back, in that application, to the pre-patch state on the exact path someone took the trouble to find.

The offending data sits in a table nobody needs

The WPF repository issue includes an analysis of why it breaks, written by the person who opened it and not by Microsoft, so read it with that label attached. According to that analysis, those four families carry a legacy kerning table — the one defining how close two letters sit — with a 16-bit length field that has wrapped around. The bounds check the patch adds rejects the whole font rather than skipping that table, which is optional and which the glyph subsetter doesn't even need to do its job.

The correlation it publishes is clean, and it is what gives the analysis its weight: the fifteen fonts whose kern table exceeds 65,535 bytes fail, and the ten that stay under it work. In calibrib.ttf, the directory declares 160,164 bytes and the 16-bit field lands on 29,088 — exactly what is left over after dividing by 65,536. The hardening that triggers all this shipped in May, in a change that rewrote thirteen files of that component; it took three months to reach people's machines.

If that is right — and it fits everything else — the conclusion is uncomfortable for both sides: the Windows font has carried a malformed field for years that nobody looked at, and the fix overshot by rejecting the entire file. This is not a case of "security versus convenience". It is a bounds check that is too broad, which is why there is a fix pending rather than a permanent dilemma.

The three ways out, with the maths done

Until the permanent fix lands there are three ways out and none of them is free. What changes between them is what you put the price on.

1. Set the switch

The first thing to understand is the blast radius. In the KB, Microsoft documents one route only: the configuration file of a single application, where the switch affects that program and nothing else. It is worth knowing there is another, because it is the one that will tempt someone: the .NET Framework AppContext documentation lets you set any of these switches in the registry, under HKLM\SOFTWARE\Microsoft\.NETFramework\AppContext — and Wow6432Node on 64-bit systems — and there the scope is machine-wide: it "affects every application running on the machine", in Microsoft's own words. Which means it can be pushed by group policy to three hundred machines in ten minutes. Don't. That reopens the path for everything running on .NET on those machines, including whatever opens files from outside. If you set the switch, set it in the configuration file of the program you choose.

With that, the question becomes answerable: does that specific application open fonts that come from outside? The line-of-business app printing delivery notes with Windows fonts over your own database is not in the same position as a viewer opening XPS documents that arrive by email. The first can live with the switch for a few weeks; the second is precisely the CVE's attack scenario. Microsoft cannot answer this for you because it depends on what your program does, and that is where someone has to think rather than apply a recipe.

2. Remove the .NET cumulative update

There is a distinction here that gets lost in most of the coverage and that changes the decision: the package breaking printing is the .NET Framework cumulative update, a different KB from the Windows cumulative update. This month, on top of that, there have been regressions in both: the printing one sits on the .NET side, and the games-closing-themselves one — which Microsoft has ended up attributing to the low-level drivers some RGB-lit peripherals install — sits in the Windows cumulative update, a separate package.

The practical consequence: removing the .NET cumulative update does not leave the WinSock zero-day unpatched, because that one ships in the other package. What you lose are the six .NET CVEs, three of them RCE. It is a wider way out than the switch — it affects everything running on .NET on that machine, not one application — and considerably narrower than leaving the August cycle unapplied. It makes sense on one specific machine that does one thing and cannot stop doing it while you prepare another way out; it makes no sense as a general policy.

3. Change the font

The third way out, and in many places the cheap one. If what breaks is subsetting those four families, a document laid out in another font never goes down the broken path. You touch the template, not the system; you accept no security risk, and when the fix lands there is nothing to roll back.

With two honest caveats. First: it is not always possible. A certificate, a diploma or a contract in the corporate typeface does not get changed by a technician's decree on a Tuesday afternoon. Second, and this one genuinely matters: we have not tested this across every application, and if the program embeds the font itself, or the document carries it inside, changing what you see on screen may not change what reaches the subsetter. Before rewriting fifty templates, try it on one.

The decision shouldn't be about your fleet: it's about each application

Framed that way, the comparison makes itself. Count machines and you have three hundred, and any decision across three hundred machines is expensive and slow. Count WPF desktop applications that print or export to PDF and in most of the companies we work with you get a handful. There the decision is cheap, and it is different for each one: the switch for the line-of-business app, the font for the office templates, and removing the cumulative update only on that odd machine that has done one single thing for ten years.

The hard part is not deciding: it is knowing who it happens to. Nobody has an inventory of "which programs in my fleet are built on WPF and export to PDF". That shows up in no dashboard, and half the time the software vendor doesn't know either. What you can do this afternoon is search for FileFormatException across the last two weeks of tickets. If the failure was already there and nobody had connected it to the patch, you have your inventory, for free.

This is, literally, what maintenance is: not applying the patch — a scheduled task does that — but knowing what you have, in what order it gets touched, and how you go back. We already wrote about this in the context of a rollback plan for a migration: the part that decides whether an intervention can happen on a Tuesday is the part nobody shows in the demo.

What we would not do

When this isn't about you

If your company has no WPF desktop applications that print or export to PDF — and plenty of companies live in the browser and in Office — this is background noise. The path that breaks is WPF's font subsetter; nobody has published that Word or a browser goes through it. You can close this tab.

And a caveat in the other direction, so as not to oversell it: most printing tickets this August are not this. They are still the driver, the stuck queue and the machine that changed subnet. If the error you are looking at doesn't say FileFormatException, this isn't your problem, and blaming the patch will cost you an afternoon.

Both things are true at once

The patch did its job: it closed three remote code execution holes in a component that processes files which can come from anywhere. And it broke printing with the fonts everyone uses. Arguing about whether "you should patch or not" from here goes nowhere, because the answer is yes and we all know it; including when the hurry is set by a three-day deadline rather than by an ordinary Tuesday.

The useful question is smaller and rather more uncomfortable: which of your applications print, and who decides which of the three ways out each one takes? If that question has no owner today, it will be answered in three weeks by whoever picks up the phone when someone can't get an invoice out.

Sources: known issue, workaround text, the Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection switch and the list of the six CVEs fixed — KB5120708, Microsoft Support, 11 Aug 2026; the 24 August acknowledgement, the affected platform list from Windows 10/11 to Server 2012–2025 and the exposure warning — BleepingComputer, 24 Aug 2026 and BetaNews; the error dump, the four families with their fifteen faces and the kern table analysis — written by whoever opened the issue, not by Microsoft — dotnet/wpf, issue 11834, opened 12 Aug 2026; the cycle tally (400 with its stated methodology, 42 critical, three zero-days and CVE-2026-68820 exploited) — BleepingComputer, 11 Aug 2026 and the alternative 421-CVE count from SecurityWeek; the gaming regression attributed to RGB peripheral drivers — BleepingComputer; the machine-wide scope of AppContext switches set in the registry — System.AppContext documentation, Microsoft Learn; the title and description of CVE-2026-62897 — GitHub Advisory GHSA-fx4q-gjrx-2jw6, and its location in the font-subsetting component — SecureLayer7 Labs; the change that introduced the hardening — dotnet/wpf, pull request 11642.