Ghost Bits exposes a long-underestimated low-level risk in the Java ecosystem: upper-layer validation sees characters, but lower-layer execution may operate on truncated bytes. This can lead to upload bypass, path traversal, SMTP injection, and similar issues. Keywords: Java Security, Ghost Bits, Cast Attack.
The technical snapshot defines the problem space
| Parameter | Details |
|---|---|
| Primary language | Java |
| Risk type | Character-semantic and byte-semantic mismatch |
| Typical protocols | HTTP, SMTP, Redis, file systems |
| Related components | Tomcat, Jetty, Spring, Fastjson, Jackson, Jakarta Mail |
| Core dependencies / interfaces | OutputStream.write(int), writeBytes(), URL decoding, path normalization |
| Star count | N/A (research topic, not a single open-source project) |
Ghost Bits is fundamentally a silent low-byte truncation issue
Ghost Bits is not a single CVE. It is a class of processing-chain mismatches. The core behavior is simple: security checks operate on strings, while actual execution may happen on a different byte representation.
In Java, a char is 16 bits, while a byte is only 8 bits. If code directly casts a character to a byte, Java drops the high 8 bits and keeps only the low 8 bits. This is not encoding conversion. It is truncation.
char ch = '陪';
byte b = (byte) ch; // Force a 16-bit character into an 8-bit byte by truncation
System.out.println((int) b); // Print the truncated low-byte valueThis example shows the core issue clearly: the application layer sees 陪, but the lower layer may receive ASCII j.
Low-byte folding explains why a “safe string” can become dangerous bytes
For example, the Unicode code point for 陪 is U+966A, or 0x966A in hexadecimal. When (byte) ch runs, only 0x6A remains, which is the character j.
Likewise, 阮 can fold into ., 瘍 can fold into \r, and 瘊 can fold into \n. The risk does not come from Chinese characters themselves. It comes from different layers interpreting the same input in different semantic spaces.
陪 -> 0x966A -> low 8 bits 0x6A -> 'j'
阮 -> 0x962E -> low 8 bits 0x2E -> '.'
瘍 -> 0x760D -> low 8 bits 0x0D -> '\r'
瘊 -> 0x760A -> low 8 bits 0x0A -> '\n'These mappings show that the attacker is not submitting random garbled text. They are precisely crafting the protocol bytes that will eventually execute.
The vulnerability exists when validation and execution split semantically
A Ghost Bits attack chain usually follows a consistent pattern: input passes through a WAF or business-layer validation first, then a framework, container, or low-level library decodes, folds, or reconstructs it into dangerous bytes.
Unicode input
-> upper-layer character validation
-> validation passes
-> lower layer performs char -> byte truncation
-> low 8 bits recover dangerous ASCII
-> real vulnerability triggersThis closely resembles classic TOCTOU, except the “time gap” becomes a “semantic gap.” Validation checks characters; execution consumes bytes.
File upload bypass is the most intuitive exploitation scenario
Suppose an attacker uploads a file named 1.陪sp. The upper layer may determine that it is not a .jsp file. But if the lower layer performs dangerous truncation during the write phase, 陪 folds into j, and the final file on disk becomes 1.jsp.
String filename = "1.陪sp";
byte[] raw = new byte[filename.length()];
for (int i = 0; i < filename.length(); i++) {
raw[i] = (byte) filename.charAt(i); // Dangerous point: directly truncates the high bits of each character
}
System.out.println(new String(raw));This example demonstrates the root cause behind mismatches between upload validation and the final persisted filename.
Several Java APIs naturally amplify Ghost Bits risk
The highest-risk areas often do not involve obviously dangerous functions. They are usually hidden in ordinary infrastructure code that seems too routine to question. Two patterns appear repeatedly: directly writing characters as bytes, or preserving only the low 8 bits for further processing.
These patterns deserve priority during code audits
(byte) chch & 0xff/ch & 255OutputStream.write(int)DataOutputStream.writeBytes(String)RandomAccessFile.writeBytes()StringBufferInputStreamURLDecoder.decode()orString(byte[])when they rely on the default charset
out.write((byte) c); // Directly truncates a character into a single byte
baos.write(ch); // If ch exceeds 0xFF, the low byte may still be the only one preserved
new DataOutputStream(out)
.writeBytes(value); // Legacy API that writes only the low byte of each characterThe shared problem across these APIs is that they quietly degrade text processing into byte folding.
Representative exploitation chains already span web, JSON, paths, and email protocols
Tomcat upload bypasses, Jetty path parsing issues, Fastjson and Jackson decoding discrepancies, and Jakarta Mail SMTP injection all show that this is not a theoretical edge case. It is a systemic risk shared across multiple components.
Tomcat and path parsing issues show why containers are high-risk amplifiers
In Tomcat-related scenarios, some code paths perform logic similar to out.write((byte) c), which disconnects character-based filtering from the semantics of the file eventually written to disk. In Jetty, URL decoding or hexadecimal conversion may further reconstruct apparently harmless characters back into . or ...
int d = ((c & 0x1f) + ((c >> 6) * 0x19) - 0x10); // Specific bitwise logic may map unexpected characters into hexadecimal valuesThis kind of code shows that path traversal does not always begin with a literal ../. It may also emerge after multiple restoration steps such as .%u002e -> ...
JSON and deserialization risks arise because parsers can interpret input more loosely
Some JSON parsing paths use APIs such as Character.digit(). These APIs do not only accept ASCII digits. They may also accept certain Unicode numeric characters. As a result, a WAF may miss a sensitive key while the parser later reconstructs its actual meaning.
{
"\u꘠๐๔੦type": "..."
}This example is not about a clever JSON syntax trick. It illustrates a semantic mismatch between layers over whether the “same character” is equivalent to a digit or hexadecimal symbol.
Once protocol boundaries are reconstructed, the issue escalates into a protocol-level vulnerability
The most dangerous aspect of Ghost Bits is that it can recover boundary characters such as \r, \n, ., /, and %. At that point, the problem is no longer a simple input-validation bypass. It becomes protocol injection.
SMTP injection and request smuggling are the two outcomes that deserve the most attention
In email scenarios, if a lower layer performs logic such as bytes[i] = (byte) chars[i++], an attacker can use 瘍瘊 to recover \r\n and inject new SMTP command boundaries.
RCPT TO:<[email protected]>
DATA
Subject: PWNED
I LOVE YOU!
.
QUITThis protocol fragment shows why newline control is so dangerous: once the attacker controls message boundaries, they may send credible malicious email under the system’s trusted identity.
The same principle applies to HTTP. Recovered \r\n bytes can inject headers and, when combined with proxy or gateway parsing inconsistencies, may lead to Request Smuggling.
Effective defense starts by unifying final semantics before validation
You cannot solve this class of issue with blacklists alone. The core principle is straightforward: every security decision must rely on the exact data representation that will ultimately execute, not on an intermediate string seen by one layer of the stack.
Practical defenses must cover code, frameworks, and audit workflows together
First, eliminate any implicit char -> byte truncation. Second, use explicit character-set encoding consistently. Third, apply strict allowlists to protocol-boundary fields. Finally, make sure logs record the final effective representation.
byte[] bytes = value.getBytes(StandardCharsets.UTF_8); // Explicitly encode the full string as UTF-8
out.write(bytes); // Write the actual encoded bytes, not truncated low-byte valuesThe key difference in this safer alternative is encoding, not truncation. The two have completely different semantics.
It makes sense to ban a set of legacy high-risk APIs outright
In coding standards, SAST rules, or code review checklists, strongly restrict these patterns: writeBytes(), StringBufferInputStream, default-charset URLDecoder.decode(), String(byte[]), and any manual & 0xff folding logic.
// Mark these as high risk during static analysis
DataOutputStream.writeBytes(value);
RandomAccessFile.writeBytes(value);
URLDecoder.decode(value); // Legacy default-charset behavior
new String(bytes); // Default charset, unstable semanticsThese rules can significantly reduce the chance that Ghost Bits enters a production execution path.
FAQ
Q1: Is Ghost Bits a Java-only vulnerability?
A: No. At its core, this is a mismatch problem involving characters, bytes, encoding, and protocol boundaries. Java tends to amplify it because of legacy APIs, container processing chains, and Unicode handling behavior.
Q2: Can standardizing on UTF-8 fully solve it?
A: No. UTF-8 helps with explicit encoding, but it does not automatically fix multiple decoding passes, path-normalization differences, protocol reconstruction, or truncation in legacy APIs. You still need a unified parsing order and final-state validation.
Q3: Where should auditors look first?
A: Start with (byte) ch, writeBytes(), OutputStream.write(int), default-charset conversions, URL decoding, path normalization, and protocol-boundary fields such as email content, headers, filenames, and JSON keys.
Core takeaway: This article systematically explains the root cause, exploitation chains, and defensive strategies behind Ghost Bits and Cast Attack in Java. It shows why low-byte truncation from char to byte creates a semantic split between validation and execution, which can further trigger protocol-level risks such as file upload bypass, path traversal, SMTP injection, and request smuggling.