In December 2022, Google disclosed a parsing inefficiency in its widely used Protocol Buffers (protobuf) Java library, tracked as CVE-2022-3510, that allows remote attackers to freeze Java services through excessive garbage collection. The vulnerability affects both protobuf-java and protobuf-javalite in all releases prior to versions 3.21.7, 3.20.3, 3.19.6, and 3.16.3. Exploitation requires no authentication—just the ability to send crafted messages to an endpoint that parses protobuf, making every public-facing gRPC service or custom RPC endpoint a potential target.

Inside the Flaw: How a Few Malformed Messages Freeze a Server

Protocol Buffers is a binary serialization format used extensively in distributed systems, microservices, and mobile applications. Its Java runtime employs builder patterns and immutable message objects to balance performance and memory safety. Under normal operation, the library parses wire-format data into mutable builders and then builds an immutable message—a lightweight, efficient process.

CVE-2022-3510 triggers a pathological deviation from this normal flow. When an attacker crafts a protobuf payload containing multiple non-repeated embedded messages that themselves include repeated or unknown fields, the parser enters a destructive cycle. It constructs temporary immutable instances, merges fields into existing objects, and then builds again—constantly toggling between mutable and immutable representations. Each conversion allocates fresh objects and buffers, generating enormous allocation pressure that forces the Java Virtual Machine (JVM) into prolonged garbage collection (GC) pauses.

Security trackers explicitly compare this bug to CVE-2022-3171, another protobuf parsing issue that caused memory exhaustion. However, where that earlier flaw required specific field interactions, CVE-2022-3510 is weaponized through message-type extensions—a feature many production schemas use. The result is a denial-of-service (DoS) that can render a server unresponsive for minutes at a time, effectively taking it offline. Microsoft’s Security Response Center assigns it a CVSS base score of 7.5 (High), with the vector highlighting low attack complexity and a network attack surface.

Your Exposure: Are You at Risk?

This vulnerability is not a threat to typical home users running Windows, but it is a critical concern for anyone responsible for Java-based services. If your organization uses Java and protobuf, the risk extends far beyond a simple library update.

For IT Administrators and DevOps Teams

Any Java service that parses raw protobuf messages from untrusted sources is vulnerable. This includes:

  • Public-facing gRPC endpoints – often the most exposed.
  • Message queue consumers that deserialize protobuf payloads (e.g., Kafka, RabbitMQ handlers).
  • API gateways and custom binary RPC servers that accept protobuf.
  • Internal backend services fed data from potentially compromised front-end servers.

The truly insidious risk, however, lies in shaded or embedded copies of protobuf inside third‑party products. Many enterprise applications, SDKs, and appliances bundle a specific version of protobuf Java inside their distribution artifact. If a vendor shipped an affected version, updating the operating system or your own project’s dependency won’t fix the problem—the vulnerable code persists inside the vendor’s binary until they release a rebuild.

For Developers

If your build system pulls in com.google.protobuf:protobuf-java or protobuf-javalite as a direct or transitive dependency, you need to verify the version immediately. Modern dependency scanners can flag known CVEs, but you must also search for shaded jars by inspecting your final artifact (e.g., using jar tf or automated SBOM analysis).

Quick Inventory Checklist

  1. Search artifact repositories for protobuf-java and protobuf-javalite and note every version in use.
  2. Unpack deployed JARs, WARs, and container images – look for com/google/protobuf class files inside to find shaded copies.
  3. Scan base images and layers with vulnerability scanners that include protobuf CVEs.
  4. Check service logs and JVM telemetry – unexplained full GC pauses, memory spikes during parsing calls, or OutOfMemoryError patterns can indicate active exploitation.

The Road to the Fix: From Discovery to Patches

Google’s upstream fix merged into the protobuf repository changes how the Java runtime handles message-type extensions during parsing. Instead of building temporary immutable instances and merging afterward, the code now merges directly from the wire format into mutable builders, eliminating the repetitive conversion cycle that caused the GC churn. This surgical change reduces allocations without altering the API or wire format, so services will parse legitimate messages identically.

The patched versions—3.21.7, 3.20.3, 3.19.6, and 3.16.3—were released in December 2022 shortly after public disclosure. Major Linux distributions (SUSE, Debian) and other vendors published advisories and, in many cases, backported the fix into their maintained protobuf packages. For Java developers, upgrading is a simple matter of changing a version number in their build configuration.

However, the operational challenge remains formidable. Products that statically link or shade protobuf must be rebuilt by the vendor—a process that can take weeks or months, especially for appliances or products on long-term support cycles. Until then, compensating controls are essential.

Immediate Steps to Shield Your Services

1. Patch the Library

Upgrade your project’s protobuf Java dependencies to a fixed version. The exact version depends on your current branch:

Current Branch Minimum Fixed Version
3.21.x 3.21.7
3.20.x 3.20.3
3.19.x 3.19.6
3.16.x 3.16.3

2. Rebuild Shaded or Embedded Artifacts

If your organization bundles protobuf inside its own products, rebuild and redeploy with the patched library. For third‑party products, contact the vendor and apply their updates as soon as available. In the interim, implement network‑level controls to limit exposure.

3. Apply Compensating Controls

  • Network restrictions: Place protobuf parsing endpoints behind firewalls, API gateways, or load balancers that can enforce authentication and rate limiting.
  • Input validation: Reject messages with an unusually high number of extensions or deeply nested repeated fields before they reach the parser.
  • JVM hardening: Set container memory limits (-Xmx), enable GC logging, and consider using a Garbage‑First (G1) GC with bounded pause time goals to reduce the impact of accidental triggers.

4. Monitor and Alert

Instrument your JVMs to track GC pause times and overall allocation rates. Sudden spikes in full GC frequency or duration during parsing operations should trigger alerts. Pair this with application‑level metrics to correlate with incoming request patterns.

5. Scan and Verify

Run binary scanners and Software Bill of Materials (SBOM) tools across your entire artifact inventory to ensure no vulnerable protobuf copies remain. Several open‑source and commercial scanners now detect the affected version ranges.

Beyond This Bug: Strengthening Your Defenses

CVE-2022-3510 is a stark reminder that parser design and memory allocation strategies are as critical as memory‑safety checks. Serialization libraries like protobuf are foundational components; a flaw in them cascades to every service that consumes encoded messages. The immediate fix is straightforward, but the broader lessons demand long‑term changes in how organizations manage their software supply chains.

Invest in reproducible builds and SBOMs so you can trace the exact dependency versions inside every deployed artifact. Apply fuzz testing to your parsers—the upstream protobuf project already uses fuzzing extensively, and your own edge‑case tests can catch similar inefficiencies before they become CVEs. Finally, treat all embedded third‑party code as a liability: a shaded jar is not “just a library”—it’s code you can’t patch independently, and it must be tracked with the same rigor as your own source.