TinyWeb Log Injection via Control Characters in Request URI

Technical Details

Root Cause

TinyWeb writes user-controlled request fields directly into its access, referer, and agent log files. The request line (method, URI, and protocol) is recorded in the access log wrapped in double quotes, and the User-Agent and referer headers are recorded in their respective logs. None of these values were neutralized before being written, so any control character present in the field was emitted verbatim into the log stream.

Mechanism

An attacker sends a request whose percent-decoded URI path contains control bytes: NUL (0x00), CR (0x0D), LF (0x0A), other C0 control characters, DEL (0x7F), or HTAB (0x09). Because the path is percent-decoded before it is logged, an encoded sequence such as %0d%0a becomes a real CR/LF pair in the log line.

• Log forging: An embedded CR/LF splits one logged request into what appears to be two log records, letting the attacker inject fabricated entries that mislead operators or log analysis tooling.
• Parser and terminal corruption: Raw control bytes can corrupt downstream log parsers, or trigger terminal escape sequences when an operator views the log in a console.
• Quoted-field breakout: Because the access log wraps the request line in double quotes, an unescaped " in the URI could break out of the quoted field and confuse parsers that split on quotes.

Proof of Concept

A request with a percent-encoded CRLF in the URI path forges an extra log line once decoded:

GET /page%0d%0a127.0.0.1+-+-+[injected]+"GET+/admin+HTTP/1.1" HTTP/1.1
Host: 127.0.0.1

After percent-decoding, the CR/LF terminates the genuine log record early and starts an attacker-controlled second line that mimics a legitimate request entry.

Fix Applied in Version 2.05

The problem has been patched in version 2.05. Decoded URI paths containing control characters (NUL, CR, LF, other C0 controls, DEL, HTAB) are now rejected with 400 Bad Request, and a new EscapeForLog helper encodes bytes 0..31, 127, #, ", and \ as #NN (two uppercase hex digits) for every user-controlled field written to the logs. The encoding is self-delimiting and uniquely decodable, so no attacker-supplied byte can forge or corrupt a log record.

• Fix commit: 06efa04
• Fix pull request: PR #5

Workarounds

If upgrading to v2.05 is not immediately possible, consider the following mitigations:

• Treat TinyWeb log files as untrusted input.
• View the logs with tools that render control bytes inertly rather than interpreting terminal escape sequences.
• Do not feed the logs unfiltered into log processors that interpret CR/LF as record separators.

Timeline

Other TinyWeb CVEs