CVE-2026-55969: Apache Thrift 0.24.0 Fixes DoS

Microsoft’s Security Update Guide published its entry for CVE-2026-55969 on August 11, describing the outcome as a serious availability loss. But the vulnerability is neither new nor waiting on a vendor patch. Apache merged the principal C++ and C/GLib fix on June 13, Apache Thrift 0.24.0 shipped on July 11, and Apache’s public advisory followed on July 24. NIST’s National Vulnerability Database added its record on July 27.

For administrators, the practical conclusion is straightforward: this is a dependency update problem, not a Windows Update problem. Inventory Thrift runtimes bundled into services, containers, and application builds, especially where an untrusted client can send Thrift protocol traffic directly or through a gateway.

The overflow sits in a network-facing size guard​

Apache Thrift is an RPC framework whose wire protocols encode collections such as lists, sets, and maps with a supplied element count. Before allocating or reading the contents, a receiving implementation can calculate a minimum required byte count and compare it with a configured maximum message size. That is the protection CVE-2026-55969 concerns.

The Apache Thrift pull request that became the C++ and C/GLib fix documents the flaw plainly: a wire-controlled element count was multiplied by the minimum serialized size of each element using 32-bit arithmetic. A sufficiently large declared count could cause the result to wrap down to a small number, or zero, allowing the container header to pass the

guard even though the real declared payload was much larger.

That does not turn every oversized Thrift message into an exploit. A service must use an affected language binding, accept attacker-controlled Thrift data, and reach one of the affected read paths. It does, however, defeat a control many teams treat as their first line of protection against abusive messages. Once the check is bypassed, the service may continue reading, allocating, or doing parser work against a container whose stated size should have been rejected immediately.

NIST scores the issue 7.5 under CVSS 3.1, with network access, low attack complexity, no privileges, no user interaction, and high availability impact. Apache’s CVSS 4.0 assessment is 8.7 High and likewise assigns the technical impact solely to availability. CISA’s SSVC enrichment lists exploitation as “none” and says the technical impact is partial; that is not a contradiction of the CVSS availability score. It means the available records do not describe loss of confidentiality or integrity, and there is no indication of exploitation in the wild.

The Windows-specific failure was found before the release​

The initial C++ patch attempted to widen the calculation by casting it to

. That would have been sufficient on many 64-bit Unix-like platforms, where the LP64 convention makes

64 bits. It would not have fixed the flaw on 64-bit Windows.

Windows uses the LLP64 model for MSVC:

remains 32 bits even in 64-bit processes. Apache’s review called this out directly. The reviewer noted that the proposed multiplication would continue to overflow on Windows because it had merely moved from one 32-bit type to another.

Apache then amended the work to use

in the C++ protocols and

in the C/GLib readers. Crucially, the project also widened the

parameter in the C++ transport interface and the C/GLib transport vtable. Without that second change, a wider intermediate result would still have been truncated when passed into the check.

This is the material detail absent from Microsoft’s availability-only wording: Windows did not merely inherit the same generic integer-overflow bug as other platforms. It was specifically at risk of retaining the defect if Apache had shipped the first proposed code. The final merged change prevents that outcome and adds regression coverage for the C++ binary, compact, and JSON protocol implementations.

For Windows teams that build Thrift from source with Visual Studio, the distinction is worth checking in internal forks. A local backport that uses

,

, or a platform-sized assumption rather than a fixed 64-bit type has not reproduced Apache’s final correction.

The affected-binding list is wider than Apache’s short advisory​

Apache’s July 24 disclosure on the oss-security list names the C++ and C/GLib bindings. NIST’s CVE record, which reproduces Apache Software Foundation CNA data, identifies a larger affected set: C++, C/GLib, Go, .NET Standard, Delphi, and Haxe, all before version 0.24.0.

Apache’s THRIFT-6091 issue record reconciles the difference. Its scope was to widen container-size prechecks across C++, C/GLib, Go, .NET Standard, Delphi, and Haxe. The initial GitHub pull request addressed C++ and C/GLib; a subsequent pull request covered Go, while the broader issue tracked the remaining language implementations.

That omission matters most for Windows estates. The .NET Standard runtime is distributed as the

package on NuGet, and NIST’s affected-product data explicitly lists that package as vulnerable before 0.24.0. A Windows inventory focused only on native C++ services could therefore miss managed Thrift services, including internal APIs that use generated clients and servers without calling the library “Thrift” in the product name.

The CVE record does not list Java, Python, Ruby, PHP, Rust, or JavaScript bindings among those affected by this specific flaw. Do not infer exposure merely from the presence of a

dependency in a software bill of materials. Confirm both the binding and the version. Conversely, do not dismiss a .NET application because it has no native DLL: the affected .NET Standard package belongs in the remediation scope.

Version 0.24.0 was already available before the CVE listing reached Microsoft​

Apache Thrift 0.24.0 was released on July 11, according to the project’s release artifacts and PyPI publication history. Apache’s own advisory says every release before 0.24.0 is affected and recommends upgrading to 0.24.0. There is no announced supported patch line for older Thrift versions in the advisory or the NVD record.

That release timing creates a common operational trap. A scanner that keys remediation work to Microsoft’s August 11 publication date may classify this as newly disclosed and wait for a vendor package response, even though the upstream fixed version has been available for a month. The CVE itself was entered into NVD on July 27. Microsoft’s entry is useful as a risk signal, but it is not evidence of a Microsoft-produced patch or an affected Microsoft product.

The public records also do not name a known proof of concept, an exploitation campaign, or a separate workaround that preserves safety on pre-0.24.0 versions. Reducing the configured maximum message size may limit the worst-case resource demand, but it cannot be treated as a complete mitigation when the arithmetic guarding that limit can wrap.

What to change in Windows environments​

Begin by finding the runtime rather than assuming the application’s top-level product version answers the question. Check lockfiles, NuGet package references, Go module manifests, container images, embedded source trees, and static native binaries that may include Apache Thrift code.

• Upgrade affected Apache Thrift bindings to version 0.24.0 or later, including the ApacheThrift NuGet package for .NET Standard applications.
• Treat internally maintained C++ or C/GLib backports with caution unless they use fixed-width 64-bit arithmetic end to end, including the transport check function’s parameter type.
• Prioritize services that accept Thrift Binary, Compact, or JSON protocol messages from external tenants, partner networks, user-controlled proxies, or lower-trust internal segments.
• Validate the deployed artifact after rebuilding; updating a package reference does not correct a Windows service that still ships an older native Thrift DLL or a statically linked runtime.

CVE-2026-55969 is an availability flaw with a mature upstream fix, not a reason to panic-patch every application that happens to generate Thrift code. But the disclosure trail leaves a meaningful lesson for Windows operators: a nominally “widened” integer calculation can remain 32-bit on MSVC. The safe baseline is Apache Thrift 0.24.0, and any older local patch needs to be checked against Apache’s final fixed-width implementation rather than its first draft.