CVE-2026-43871: Upgrade Apache Thrift Runtimes to 0.24.0

The affected code is Apache Thrift’s

varint reader in the Python, Go, PHP, and Java bindings. Apache’s advisory says every Thrift version before 0.24.0 is affected and recommends upgrading to 0.24.0. The vulnerability is categorized as CWE-835, an infinite loop with an unreachable exit condition, and the published CVSS 4.0 score is 8.7, rated High.

The practical risk is simple: a peer able to send Compact Protocol traffic to a Thrift service can supply a malformed variable-length integer whose continuation bit never terminates. In the affected implementations, the decoder continued reading rather than enforcing the maximum length valid for the integer representation. That can leave a request-processing path reading indefinitely, consuming a worker, CPU time, or a connection slot until the connection is interrupted or the service becomes unable to keep up.

The fix rejects malformed varints instead of continuing to read​

Apache’s THRIFT-6084 issue records the root cause plainly:

had no upper bound on continuation bytes, allowing an unterminated varint to force an unbounded read loop. A valid 64-bit varint requires no more than 10 bytes; a 32-bit variant has a five-byte maximum.

The upstream change introduces those bounds. In Python, Go, PHP, and Java, overlong values now result in an invalid-data protocol exception instead of allowing the decoder to keep consuming input. Apache’s development record shows that the Java implementation distinguishes five-byte 32-bit and 10-byte 64-bit paths, while several other implementations apply a 10-byte limit to their generic reader.

This is an input-validation fix at the wire-protocol boundary. It does not depend on a malformed schema, a deserialization gadget, or a client being authenticated. If an external or semi-trusted party can reach a Thrift endpoint configured for Compact Protocol, malformed traffic can reach the vulnerable reader before application-level request validation has a chance to run.

The important operational qualification is that the attacker must be able to speak to the Thrift service and cause it to select

. A Thrift deployment restricted to an internal network is not immune, but its exposure is materially different from a directly internet-facing listener. The issue is also not automatically relevant to every product that happens to ship a

compiler binary; it is relevant where the vulnerable runtime bindings parse Compact Protocol data.

Apache names four affected runtimes, despite broader hardening in the changelog​

Apache’s July security advisory specifically identifies Python, Go, PHP, and Java bindings as affected. Its Jira issue lists the same four components and says the fix was merged on April 23 before being released in version 0.24.0.

That scope needs to remain the basis for prioritization. Apache’s 0.24.0 changelog also associates THRIFT-6084 with a broader collection of language libraries, including Dart, Erlang, Lua, .NET Standard, Ruby, and Rust. The project’s pull-request discussion confirms that maintainers extended byte-count checks into additional implementations, including Ruby’s pure implementation and C extension.

But broader code hardening is not the same thing as Apache expanding the CVE’s affected-product statement. The public advisory and the tracked security issue identify the vulnerable set as Python, Go, PHP, and Java. Administrators should avoid marking every Thrift language binding vulnerable solely because the changelog names the same issue across multiple runtime sections; at the same time, teams maintaining custom builds or forks of non-listed bindings should compare their local

reader with the 0.24.0 source changes.

That is a useful distinction for enterprise vulnerability management. A scanner that reports every

artifact as equally exposed may overstate immediate risk in some deployments, while an inventory process that only searches Java Maven dependencies could miss Python, Go, or PHP services using the same vulnerable protocol implementation.

The MSRC publication date obscures the remediation timeline​

The supplied MSRC record was published on August 11, 2026. Apache’s own download page lists Thrift 0.24.0 as the current stable release, released on July 11, and its security announcement is dated July 24. The public CVE ecosystem listed the vulnerability on July 27.

In other words, the patch was available for roughly a month before the MSRC entry appeared. That timing is consequential for patch reporting: an organization that waits for a Microsoft catalog appearance before acting on third-party component alerts would have had an avoidable exposure window.

Microsoft’s availability-impact wording accurately describes the class of outcome—denial of service—but it is generic language and leaves out the key deployment condition. This is a protocol-reader flaw, so the urgent cases are services that accept untrusted Compact Protocol input, particularly public APIs, partner-facing RPC endpoints, and shared internal services where one tenant or client can consume resources needed by others.

The MSRC entry also should not be interpreted as an indication that a Microsoft product is affected. The authoritative Apache advisory identifies Apache Thrift package coordinates and repository names:

,

,

, and the Maven artifact

. No Windows build number, Microsoft KB article, or Windows servicing release is associated with CVE-2026-43871.

Upgrading the compiler alone may leave production services exposed​

Apache provides a Windows

compiler download, but the vulnerability is in the language runtime that reads Compact Protocol traffic. For most deployed services, upgrading only the IDL compiler on a Windows build workstation will not change the Java JAR, Python package, Go module, or PHP library installed on the server.

That is the central remediation trap here. Teams should locate the Thrift runtime included in the deployed application image or package, confirm it is 0.24.0 or later, rebuild the service, and redeploy it. Regenerating client or server stubs is not inherently required to obtain this decoder fix; replacing the vulnerable runtime library is.

A practical response should include:

• Identify services using Apache Thrift and determine whether they accept TCompactProtocol traffic.
• Prioritize Java, Python, Go, and PHP services running a Thrift version earlier than 0.24.0.
• Update the deployed runtime dependency to Apache Thrift 0.24.0 or a downstream vendor package that explicitly backports the fix.
• Verify the version inside containers, application bundles, and shaded Java artifacts rather than relying on a developer workstation’s compiler version.
• Apply connection limits, request deadlines, and upstream rate controls where patch rollout will take time, because those controls can reduce the blast radius of a worker or connection starvation attack.

For Java teams, the direct dependency is commonly

; it must resolve to 0.24.0 in the actual build output, not merely in a parent dependency-management file. For Go, Python, and PHP, the equivalent check belongs in the locked module, package, or deployment manifest and then in the shipped service image.

Two Apache records disagree on who reported the flaw​

There is one small but telling discrepancy in the public record. Apache’s oss-security announcement credits Yu Bao of PayPal as the finder. The THRIFT-6084 Jira ticket instead says the issue was reported by “August829” through Apache’s security address.

Neither record changes the mitigation, and there is no indication of competing technical descriptions: both point to the same CVE, same affected Python, Go, PHP, and Java Compact Protocol readers, and the same 0.24.0 fix. Still, the mismatch is worth documenting rather than silently choosing one attribution, especially for organizations that track researcher credits or use disclosure records for incident intelligence.

The remediation conclusion is uncomplicated: services parsing Apache Thrift Compact Protocol with Python, Go, PHP, or Java bindings earlier than 0.24.0 should be upgraded now. The MSRC listing arrived after Apache made the corrected release available; it does not come with a Windows patch, and a compiler-only update is insufficient unless the vulnerable runtime delivered with the service is upgraded as well.