Concurrency Risks in Java: Thread-Unsafe CharsetDecoder

Java's CharsetDecoder is a critical component for text processing. The JDK documentation (JDK 9–21) explicitly states it is not thread-safe. Despite this, a common mistake persists in production systems: reusing a static or singleton CharsetDecoder instance across multiple threads without synchronization.

When this happens, the decoder's internal state machine (RESET → CODING → END → FLUSHED) breaks under concurrent access. One thread calls decode() while another resets the decoder mid-operation. The results:

IllegalStateException thrown mid-decode
Corrupted character output where the decoded string no longer matches the input
Silent data corruption passed downstream to consumers, databases, and APIs

This is not theoretical. Documented production incidents include:

Apache Hive (HIVE-22898): Data corruption in ETL pipelines
IBM WebSphere (APAR IJ15284): Application failures during concurrent text processing

This demo application reproduces the vulnerability in a controlled Spring Boot service, then demonstrates the fix.

Interactive Demo Available: Click ▶ Demo in the nav to watch the vulnerability unfold live, then see the fix applied in real time.

Race Condition in Shared CharsetDecoder

When a CharsetDecoder is shared across threads without synchronization, concurrent access corrupts its internal state machine (RESET → CODING → END → FLUSHED). The following diagram illustrates the race condition:

Component: java.nio.charset.CharsetDecoder

Vulnerability: Concurrent access corrupts the internal state machine (RESET → CODING → END → FLUSHED).

Manifestation:

IllegalStateException
Corrupted character decoding
Potential buffer underflow or overflow during decode

Common Mistake: Reusing a static or injected singleton instance of CharsetDecoder across multiple threads without synchronization.

Thread Execution Timeline

Attack Vector: Concurrency-Flood Denial of Service (DoS)

When high-concurrency services share thread-unsafe components like CharsetDecoder, attackers, or even legitimate traffic spikes, can trigger cascading failures by saturating the thread pool with concurrent decode operations.

Practicality Note: Deliberate exploitation requires an attacker to reach endpoints backed by shared decoder instances. However, legitimate traffic spikes in high-throughput systems produce identical failures without any malicious intent.

Concurrency-Flood Attack Timeline

The Code: Vulnerable vs Hardened

The Vulnerability: Shared Static CharsetDecoder

The vulnerable implementation stores a single CharsetDecoder as a static final field. Every thread in the application shares this one instance:

private static final CharsetDecoder sharedDecoder = StandardCharsets.UTF_8.newDecoder();

When decode() is called, the decoder transitions through internal states (RESET → CODING → END → FLUSHED). Under concurrent access, Thread A may be mid-decode while Thread B calls decode() on the same instance, corrupting the state machine. The decoder either throws an exception or, worse, silently produces garbled output.

The Fix: ThreadLocal CharsetDecoder

The hardened implementation uses ThreadLocal<CharsetDecoder> to give each thread its own independent decoder instance:

private static final ThreadLocal<CharsetDecoder> DECODER =
    ThreadLocal.withInitial(() -> StandardCharsets.UTF_8.newDecoder());

Each thread gets a fresh decoder on first access. The reset() call before each decode ensures clean state. No shared mutable state means no race condition.

This is the pattern recommended by the JDK documentation and static analysis tools such as SonarQube (Rule S2885).

Vulnerable (LogDecoder.java)

              package com.logging;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.StandardCharsets;
import org.springframework.stereotype.Component;
@Component("vulnerableDecoder")
public class LogDecoder implements Decoder {
    private static final CharsetDecoder sharedDecoder = StandardCharsets.UTF_8.newDecoder();
    // Both buffers are shared across threads — a common "optimisation" that
    // compounds the CharsetDecoder sharing mistake.
    //
    // The 1-arg decode(ByteBuffer) convenience method creates a local CharBuffer
    // per call, so only the decoder's `state` int field is shared — the JIT can
    // cache that in a CPU register, making the race nearly invisible.
    //
    // By also sharing the OUTPUT CharBuffer and using the 3-arg form, concurrent
    // threads write characters into the same char[] heap array simultaneously.
    // Heap writes are NOT register-cached, so races produce garbled character
    // sequences, BufferOverflowException, or IllegalStateException — all caught
    // and surfaced as HTTP 500 failures.
    private static final ByteBuffer sharedByteBuffer = ByteBuffer.allocateDirect(200_000);
    private static final CharBuffer sharedCharBuffer = CharBuffer.allocate(200_000);
    @Override
    public String decode(byte[] input) {
        try {
            sharedByteBuffer.clear();
            sharedByteBuffer.put(input);
            sharedByteBuffer.flip();
            sharedCharBuffer.clear();
            sharedDecoder.reset();
            sharedDecoder.decode(sharedByteBuffer, sharedCharBuffer, true);
            sharedDecoder.flush(sharedCharBuffer);
            sharedCharBuffer.flip();
            return sharedCharBuffer.toString();
        } catch (Exception e) {
            throw new RuntimeException("Decoder failed (likely concurrency issue)", e);
        }
    }
}

            

Hardened (HardenedLogDecoder.java)

              package com.logging;
import java.nio.ByteBuffer;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.StandardCharsets;
import org.springframework.stereotype.Component;
@Component("hardenedDecoder")
public class HardenedLogDecoder implements Decoder {
    private static final ThreadLocal<CharsetDecoder> DECODER =
        ThreadLocal.withInitial(() -> StandardCharsets.UTF_8.newDecoder());
    @Override
    public String decode(byte[] input) {
        CharsetDecoder decoder = DECODER.get();
        decoder.reset();
        try {
            return decoder.decode(ByteBuffer.wrap(input)).toString();
        } catch (Exception e) {
            throw new RuntimeException("Decoder failed", e);
        }
    }
}

            

Load Test Results: Vulnerable vs Hardened

Identical concurrent load tests hit both decoder modes. 1000 HTTP requests across 1000 concurrent threads, each sending a valid UTF-8 string to the /logs/decode endpoint.

Vulnerable mode results:

The downstream.data.corrupted counter tracks decoded responses that diverged from their original input, data a real system would silently pass downstream
The decoder's corrupted state machine threw IllegalStateException, producing the exceptions and 500 errors reflected in the failure count

Hardened mode results:

Zero corrupted responses
Zero failures
Every decoded output matched its original input exactly

The results are unambiguous. Same application, same requests, same load. The only difference is one line of code.

Vulnerable Mode

Total Requests 1000

Corrupted 950

950

Failed 9

Valid 1

Hardened Mode

Total Requests 1000

Corrupted 0

Failed 0

Valid 1000

1000

What Corruption Looks Like

The vulnerable decoder corrupts data in two ways:

Exceptions in the logs: IllegalStateException and MalformedInputException stack traces from the decoder's broken state machine. These are the visible failures. They terminate the request and return HTTP 500.
Silent corruption: The decoder returns a string, but it's wrong. The original input was "hello" but the decoded output is "h�llo" or some other garbled result. The HTTP response is 200 OK. The decoder throws no exception. Corrupted data flows downstream to databases, APIs, and consumers undetected.

Silent corruption is the more dangerous failure mode. It passes all error checks and propagates bad data through the system uncaught.

Error Logs (Vulnerable Mode)

2026-03-13 09:14:40.251 [ERROR] [http-nio-8080-exec-6] com.logging.ApiExceptionHandler - 500 at POST /logs/decode traceId=null -> java.lang.RuntimeException: Decoder failed (likely concurrency issue)

at com.logging.LogDecoder.decode(LogDecoder.java:42)