Fix crash when a server sends an x-hex-message header#1180
Merged
Conversation
Response headers are decoded to binaries, but handle_hex_message/1 ran :binary.list_to_bin/1 on the value, which requires a charlist and raised "not an iodata term", failing the request. Use IO.iodata_to_binary/1, which accepts both binaries and charlists.
Member
|
I think this bug was a blessing in disguise. This would also be called for untrusted servers, right? There's quite a lot of terminal escape sequences that could potentially be problematic. We should add some escaping. |
Member
|
Something along those lines: defmodule TerminalSafe do
@bidi_controls [
0x061C,
0x202A,
0x202B,
0x202C,
0x202D,
0x202E,
0x2066,
0x2067,
0x2068,
0x2069
]
def escape(binary) when is_binary(binary) do
binary
|> String.to_charlist()
|> Enum.map_join(fn
cp when cp in @bidi_controls ->
"\\u{" <> Integer.to_string(cp, 16) <> "}"
?\n ->
"\n"
?\t ->
"\t"
# Important terminal controls
?\e ->
"\\e"
?\r ->
"\\r"
?\b ->
"\\b"
?\a ->
"\\a"
# Other C0 controls
cp when cp < 0x20 ->
hex =
cp
|> Integer.to_string(16)
|> String.upcase()
|> String.pad_leading(2, "0")
"\\x" <> hex
# DEL
0x7F ->
"\\x7F"
# C1 controls
cp when cp >= 0x80 and cp <= 0x9F ->
"\\u{" <> Integer.to_string(cp, 16) <> "}"
# Normal printable codepoint
cp ->
<<cp::utf8>>
end)
end
end |
23a9dc8 to
d3770a4
Compare
Server-provided x-hex-message values are printed to the terminal, so an untrusted server could embed ANSI escapes or bidirectional overrides. Escape control characters before printing while keeping printable text, newlines and tabs intact.
maennchen
approved these changes
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hex.HTTP.handle_hex_message/1is meant to surfacex-hex-messageheaders from the server (e.g. deprecation notices) asAPI warning:/API error:output. It runs:binary.list_to_bin/1on the header value, which requires a charlist — butdecode_header/1converts every response header value to a binary viaList.to_string/1. So any realx-hex-messageheader raisesArgumentError: not an iodata terminside the HTTP task and fails the request (e.g.mix deps.get).No hex.pm endpoint currently sends
x-hex-message, so the bug has been latent — the existing test only exercised the function with charlists. This switches toIO.iodata_to_binary/1, which accepts both binaries (the real path) and charlists (the existing test path), and adds a binary regression case.