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) gets corrupted by concurrent access. One thread calls decode() while another resets the decoder mid-operation. The results:

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

This isn't theoretical. Real-world 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, its internal state machine (RESET → CODING → END) gets violated by concurrent access. The following diagram illustrates the race condition:

Component: java.nio.charset.CharsetDecoder

Vulnerability: Internal state machine corruption when accessed concurrently (RESET → CODING → END states violated).

Manifestation:

IllegalStateException
Corrupted character decoding
Potential buffer overflows

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 thread-unsafe components like CharsetDecoder are shared in high-concurrency services, attackers — or even legitimate users during traffic spikes — can cause widespread failure by overwhelming the system.

Practicality Note: While deliberate exploitation typically requires service endpoints that expose these vulnerabilities, accidental concurrency surges in high-traffic systems can lead to identical degradation.

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 → 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 — the fix is complete.

This is the pattern recommended by the JDK documentation and security-focused static analysis tools like 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

We ran identical concurrent load tests against both decoder modes. The load runner sent 500 HTTP requests using 50 concurrent threads, each carrying a valid UTF-8 string through the /logs/decode endpoint.

Vulnerable mode results:

The downstream.data.corrupted counter shows how many decoded responses didn't match their original input — data that would have been silently corrupted in a real system
Exceptions and 500 errors appear in the failure count when the decoder's state machine threw IllegalStateException

Hardened mode results:

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

The numbers speak for themselves. The same application, the same requests, the same load — the only difference is one line of code.

Vulnerable Mode

Total Requests 500

Success Count 479

95.8%

Failure Count 3

0.6%

Corrupted Data 478

95.6%

Valid Data 1

Hardened Mode

Total Requests 500

Success Count 500

100.0%

Failure Count 0

0.0%

Corrupted Data 0

0.0%

Valid Data 500

What Corruption Looks Like

When the vulnerable decoder corrupts data, it manifests in two ways:

Exceptions in the logs — IllegalStateException and MalformedInputException stack traces from the decoder's broken state machine. These are the loud failures — they crash 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. No exception is thrown. The corrupted data flows downstream to databases, APIs, and consumers without anyone noticing.

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

Error Logs (Vulnerable Mode)

2026-04-19 02:41:36.769 [ERROR] [http-nio-8080-exec-9] com.logging.ApiExceptionHandler - 500 at POST /logs/decode traceId=null -> jakarta.servlet.ServletException: Handler dispatch failed: java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException

Caused by: java.nio.charset.CoderMalfunctionError: java.nio.BufferUnderflowException

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