CVE-2023-3635

What it actually does

This flaw is an unauthenticated denial-of-service condition in Okio's GzipSource handling of malformed gzip data. When an application uses GzipSource to parse a crafted gzip buffer or archive, an exception can be raised during gzip header/body parsing and may not be handled safely by the affected Okio code path. In vulnerable applications, this can terminate the current parsing operation, crash a worker thread, fail a request, or destabilize the process if the exception propagates to application-level control flow. The issue does not provide confidentiality or integrity impact, but it can cause high availability impact for services, clients, or background jobs that process attacker-controlled gzip content.

Why it matters to the business

Applications that accept, fetch, or process gzip-compressed data using vulnerable Okio versions may be made unreliable or unavailable by malformed compressed input. This can cause failed API calls, service errors, processing backlogs, mobile/client crashes, degraded customer experience, and operational noise from repeated restarts or incident response. The vulnerability has a network-accessible, low-complexity attack profile and public exploit information is available, but it is not currently listed in CISA KEV and the provided EPSS score is low, so prioritization should be highest for internet-facing or externally integrated systems that process untrusted gzip content.

How an attack unfolds

An attacker identifies an application or client workflow that uses Okio GzipSource to decompress gzip data from an untrusted source, such as an uploaded archive, HTTP request body, HTTP response, proxy-fed payload, file import, or message attachment. The attacker then supplies a specially malformed gzip buffer that violates expected gzip structure or metadata. When the vulnerable application passes that buffer to GzipSource, the parser raises an exception during processing. Because the affected implementation does not safely handle the exception in that path, the exception may escape to higher-level application code, causing the request handler, worker, job, or client process to fail. Repeating the malformed input can keep the affected component in a degraded or unavailable state.

How to fix it

Upgrade Okio to a version that includes the upstream fix. For source-based consumers of square/okio, ensure the codebase includes commit 81bce1a30af244550b0324597720e4799281da7b or a later release containing that change. Remove duplicate or transitive vulnerable Okio versions from dependency graphs so the patched implementation is the one actually loaded at runtime. Where immediate upgrade is not possible, reduce exposure by rejecting malformed or unexpected compressed inputs before decompression, enforcing strict request and archive size limits, wrapping gzip parsing in robust exception handling, isolating decompression in failure-contained workers, disabling gzip processing for untrusted sources where feasible, and rate-limiting endpoints that accept compressed content. These mitigations reduce impact but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm remediation by checking dependency manifests, lockfiles, build outputs, and runtime dependency trees for Okio versions or source revisions that include commit 81bce1a30af244550b0324597720e4799281da7b or later. For JVM builds, inspect Gradle or Maven dependency resolution output to ensure no vulnerable transitive Okio artifact remains. For source-based or vendored copies, verify the patched GzipSource implementation is present. Perform a negative test by feeding malformed gzip buffers to application paths that use GzipSource and confirm the application returns a controlled error without crashing, restarting, leaking unhandled exceptions, or leaving worker threads unhealthy. Validate observability by confirming malformed gzip attempts produce expected application errors, metrics, or security events without availability impact.

Typical attack path

1. Find an application, API, job, or client feature that accepts or retrieves gzip-compressed content and processes it with Okio GzipSource.
2. Craft a malformed gzip buffer or archive designed to trigger an exception during GzipSource parsing.
3. Deliver the payload through an exposed upload, import, API request, message, or attacker-controlled HTTP response consumed by the application.
4. Trigger decompression of the malformed gzip content in the vulnerable Okio code path.
5. Cause the parsing exception to propagate, resulting in failed requests, crashed workers, application errors, or client instability.
6. Repeat delivery of the crafted gzip payload to sustain service degradation or denial of service.

How to detect it

To assess possible prior exploitation, review application logs, API gateway logs, reverse proxy logs, crash reports, job-runner logs, mobile/client telemetry, and container or process supervisor events for repeated failures correlated with gzip processing. Look for stack traces or exceptions containing Okio GzipSource frames, malformed gzip parsing messages, unexpected EOF errors during decompression, and bursts of failed requests or worker restarts after compressed payloads are received. In network and access logs, correlate 4xx/5xx spikes with requests containing gzip-related headers such as Content-Encoding: gzip, uploads with gzip file signatures, unusually small or malformed compressed bodies, or repeated attempts from the same source. For client-side use cases, review outbound HTTP telemetry for attacker-controlled or unusual servers returning gzip-encoded content shortly before client crashes. Because this is a denial-of-service flaw rather than a code-execution issue, evidence will usually appear as crashes, unhandled exceptions, failed jobs, service restarts, and availability anomalies rather than persistent files or post-exploitation artifacts.

• okio.GzipSource
• okio.GzipSource.read
• okio.GzipSource.consumeHeader
• okio.GzipSource.consumeTrailer
• java.io.EOFException
• java.io.IOException: ID1ID2
• Content-Encoding: gzip
• Accept-Encoding: gzip
• malformed gzip
• unexpected end of stream
• Exception while parsing gzip
• GzipSource

What your security team should do

• Inventory applications, services, clients, and batch jobs that use square/okio and process gzip content from users, partners, external APIs, message queues, or file imports.
• Prioritize patching internet-facing systems and high-volume ingestion paths first, especially where unauthenticated users can submit compressed data.
• Upgrade to an Okio release or source revision containing commit 81bce1a30af244550b0324597720e4799281da7b, and verify transitive dependencies do not reintroduce a vulnerable version.
• Add or verify defensive exception handling around gzip decompression so malformed content fails closed with a controlled error rather than destabilizing the process.
• Apply request-size, decompressed-size, timeout, and rate limits to gzip-processing endpoints and workers.
• Search historical logs for repeated GzipSource-related exceptions, malformed gzip parsing errors, spikes in 5xx responses, worker crashes, or process restarts around compressed-content processing paths.
• Add regression tests with malformed gzip samples to prevent future dependency or parser changes from reintroducing unhandled decompression failures.