CVE-2024-7254

What it actually does

The flaw is an availability vulnerability in the Java Protobuf runtime, including full, lite, Kotlin, and JRuby usages that rely on the Java runtime. When an application parses a maliciously crafted Protocol Buffers message containing unknown fields, the parser can recurse until the JVM throws a StackOverflowError. In services that accept untrusted protobuf payloads from APIs, RPC frameworks, queues, files, or inter-service messages, this can crash the processing thread or the entire application process depending on error handling and runtime configuration. The issue does not by itself enable code execution, privilege escalation, or data disclosure; the primary technical impact is denial of service through process crash or repeated worker failure.

Why it matters to the business

Applications that rely on Java-based Protobuf parsing may be remotely crashable if they process attacker-controlled protobuf messages. Business consequences can include service outages, failed message processing, degraded API availability, queue backlogs, restart loops, customer-facing errors, and operational noise from autoscaling or crash recovery. The CVSS score is high for availability impact, but the current EPSS is low and it is not listed in CISA KEV, so remediation should be prioritized for internet-facing services, unauthenticated endpoints, and high-volume message-processing systems rather than treated as evidence of widespread exploitation.

How an attack unfolds

An attacker first identifies an application endpoint, RPC method, message broker topic, file import path, or other interface that accepts Protocol Buffers data and uses the Java Protobuf runtime or a dependent Kotlin/JRuby runtime. The attacker crafts a protobuf message with malformed or deeply nested unknown-field structures that trigger unbounded or excessive recursion during unknown-field parsing. When the vulnerable application deserializes the payload, the parser exhausts the Java thread stack and throws StackOverflowError. If the application does not isolate parsing failures, the request handler, worker, or JVM process may terminate. By repeatedly sending the payload, the attacker can keep the affected service unavailable, cause message-processing retries to fail, or trigger repeated restarts under process supervisors or orchestration platforms.

How to fix it

Upgrade all affected Java Protobuf runtime dependencies, including transitive usages through Kotlin and JRuby Protobuf packages, to a version that contains the upstream fix. For source builds of protocolbuffers/protobuf, ensure the code includes commit cc8b3483a5584b3301e3d43d17eb59704857ffaa or a later release containing that commit. Regenerate dependency lockfiles and rebuild artifacts so patched runtime libraries are actually packaged. Where immediate upgrade is not possible, reduce exposure by rejecting unauthenticated or oversized protobuf payloads, applying strict request size limits, isolating protobuf parsing in recoverable worker boundaries, validating message sources, rate-limiting untrusted clients, and ensuring process supervisors can recover safely without creating retry storms. Mitigations reduce denial-of-service risk but should not be considered a substitute for upgrading the runtime.

How to confirm the fix worked

Confirm exposure by reviewing SBOMs, Maven/Gradle dependency trees, shaded JAR contents, and container images for com.google.protobuf Java runtime artifacts used directly or transitively by Java, Kotlin, or JRuby code. Verify that deployed builds contain a protobuf runtime version or source revision including commit cc8b3483a5584b3301e3d43d17eb59704857ffaa or later. For Maven and Gradle projects, run dependency resolution commands and confirm no vulnerable protobuf-java, protobuf-javalite, protobuf-kotlin, or JRuby-backed protobuf runtime remains in the final artifact. Validate operationally by running regression tests against protobuf parsing paths with malformed unknown-field inputs and confirming the application rejects or handles them without StackOverflowError, process termination, or crash-loop behavior. Also confirm that production images and runtime classpaths do not contain older shaded copies of the Protobuf classes, as application-level dependency updates may not replace embedded copies in third-party JARs.

Typical attack path

1. Identify a service, API, RPC interface, queue consumer, or import workflow that accepts protobuf-encoded data.
2. Confirm or infer that the target uses the Java Protobuf full or lite runtime, or Kotlin/JRuby bindings backed by the Java runtime.
3. Construct a malicious protobuf message containing unknown fields designed to trigger recursive parsing behavior.
4. Submit the payload to the vulnerable parser through the exposed interface.
5. Cause the JVM to throw StackOverflowError during deserialization of the unknown fields.
6. Repeat delivery of the payload to sustain service crashes, worker failures, queue backlog, or degraded availability.

How to detect it

To determine whether this has already been exploited, review application logs, JVM stderr/stdout, centralized logging, APM error traces, container or orchestration events, service supervisor logs, message broker retry/dead-letter records, and API gateway or load balancer telemetry. Look for bursts of StackOverflowError exceptions with stack traces involving com.google.protobuf parsing classes, especially around unknown-field handling, followed by service restarts, pod CrashLoopBackOff events, worker exits, 5xx spikes, or repeated processing of the same inbound message. Correlate timestamps with external request sources, RPC methods, queue message identifiers, partner feeds, or uploaded files that reached protobuf parsing code shortly before the crash. Network indicators are application-specific because protobuf is binary and may be transported over HTTP, gRPC, queues, or files; focus on repeated payload delivery patterns, unusually high failure rates on protobuf endpoints, and malformed-message errors preceding JVM stack exhaustion. Absence of these indicators does not prove non-exploitation, because crashes may be logged only as generic process termination if StackOverflowError is not captured.

• java.lang.StackOverflowError
• StackOverflowError
• com.google.protobuf.UnknownFieldSet
• com.google.protobuf.UnknownFieldSetLite
• com.google.protobuf.CodedInputStream
• com.google.protobuf.CodedInputStreamReader
• com.google.protobuf.GeneratedMessageV3.parseUnknownField
• parseUnknownField
• UnknownFieldSet$Builder.mergeFieldFrom
• UnknownFieldSetLite.mergeFieldFrom
• Protocol message contained an invalid tag
• Protocol message tag had invalid wire type
• CrashLoopBackOff
• Back-off restarting failed container

What your security team should do

• Inventory all applications and services that parse protobuf data, especially internet-facing APIs, gRPC services, queue consumers, file ingestion systems, and partner integration endpoints.
• Prioritize patching Java, Kotlin, and JRuby applications that accept unauthenticated or externally supplied protobuf messages.
• Update Protobuf dependencies and source builds to versions containing commit cc8b3483a5584b3301e3d43d17eb59704857ffaa or later, then rebuild and redeploy affected artifacts.
• Search for shaded or bundled com.google.protobuf classes in application JARs and container images to catch transitive or embedded vulnerable runtimes.
• Add request size limits, rate limits, authentication requirements, and parsing isolation around protobuf ingestion points where feasible.
• Review application logs, JVM crash indicators, orchestrator restart events, and message-processing retry failures for StackOverflowError patterns involving com.google.protobuf parsing.
• Create monitoring for sudden increases in 5xx responses, JVM restarts, pod crash loops, dead-letter queue growth, or repeated parsing failures on protobuf endpoints.
• Because the vulnerability is not currently in KEV and has low EPSS, manage as a high-impact availability fix with risk-based prioritization rather than as confirmed active exploitation.