When a chat message becomes remote code execution

We run an internal chat where software agents — not just humans — post messages. One day a message posted by an agent contained a backtick and a $(...). The backtick did not render as a backtick. It ran as a command, on the machine, with the agent’s privileges, and its output showed up in the chat.

Nobody attacked us. An agent wrote an ordinary sentence that happened to contain shell metacharacters. That was enough.

Here is what was actually wrong, why it stayed invisible for a while, and the fix — which is not “escape harder.”

The shape of the bug

To post a message, an agent ran a single command that built a program out of the message text. Simplified and stripped of anything internal, it looked like this:

python3 -c "from our_chat import post; post('room', '<THE MESSAGE BODY>')"

Read that carefully. The message body is pasted into a double-quoted shell string, and then into a single-quoted string inside the Python source. The body is being treated as code at two layers before it is ever treated as text.

The shell processes double-quoted strings before the program runs. Inside double quotes, the shell still expands `...` and $(...). So a message body of:

run `id` now

does not post the words “run `id` now.” The shell runs id first, substitutes the output, and the agent cheerfully posts whoever it is running as — user id, groups, everything — into the room. Swap id for something with side effects and you have arbitrary command execution triggered by a chat message.

Two failure modes, one root cause

The same string-interpolation produced two very different-looking failures, which is part of why it was confusing.

1. Silent loss. A body containing a single quote — it's done — closed the Python string early and raised a SyntaxError. The command exited non-zero before reaching the code that writes the message. No message. No error in the chat. No entry in the delivery log, because the failure happened upstream of the log. From the agent’s side it looked like it had spoken. It hadn’t. “Posted” and “delivered” are not the same event, and here the gap was completely dark.

2. Execution / corruption. A body containing ` or $(...) executed. A body containing $HOME expanded to a path. A body with an unescaped " got its quotes stripped and its text mangled. Same input class — “text with punctuation” — different damage.

Our lab reproduced it instead of arguing about it. A colleague ran a small matrix of message bodies — plain text, a single quote, a double quote, a $-expansion, a backtick command, and a mixed case — through the fragile path against a mock receiver, with no production traffic. Some bodies were silently dropped, some were corrupted, and one executed a command and leaked its output into the room.

The exact per-case counts come with their own small cautionary tale, which is why the body above has no numbers in it. The written-up tally and a later “correction” to it disagreed — and both turned out to be arguing over a summary table that was missing a row. The count only settled when someone opened the original test script instead of the write-up of it. We are leaving the number out until that reconciles. The failure itself was reproduced and recorded; but even a record of a measurement needed its own primary source checked before its numbers could be trusted. That is the same discipline as the fix below: don’t trust the convenient representation of a thing — go look at the thing.

Why escaping is the wrong instinct

The tempting fix is to escape the dangerous characters — backslash the quotes, strip the backticks, filter $(. This is the road that never ends. You are now maintaining a blocklist of every character that means something to a shell and to Python, forever, against every future body anyone might type in any language. Miss one and you are back to executing chat messages. Escaping treats the body as code you are trying to defang. It is still code.

The bug is not “we escaped badly.” The bug is that untrusted text is on the command line at all.

The fix: text as data, never as code

We replaced the one-liner with a small posting helper that never puts the body on the command line. The room and sender are ordinary arguments; the body is read from standard input, fed through a quoted here-document:

post_message <sender> <room> <<'EOF'
any body at all — ' " ` $VAR, newlines, whatever
EOF

The single quotes around the here-document delimiter tell the shell: do not expand anything in this block. The shell passes the bytes through untouched; the helper reads them from stdin and hands them to the writer as a value. There is no layer where the body is parsed as a command or as source. The whole class of “a sentence ran as code” is gone because the body is never in a position to be code.

This is the same move that parameterized queries made against SQL injection, that execve(argv) makes against shell injection: stop concatenating data into a language, pass it through a typed boundary instead.

The part where we don’t oversell it

Here is the honest limit, because a security post that only lists wins is lying by omission.

A quoted here-document is safe against quotes, $, and backticks — but not against itself. If a message body contains a line that is exactly the terminator (EOF), the here-document ends early and the rest of the body falls back onto the shell. We shipped the here-document form first and briefly claimed “any body is safe.” That was wrong, and a teammate caught it by testing a body that contained the terminator. It broke, exactly as they predicted.

So the precise claim is narrower than the first draft: the here-document form is safe against quote and expansion characters, which covers the realistic failure traffic, but it is not unconditionally safe for an arbitrary body. The genuinely arbitrary-body-safe path is to keep the body off the shell entirely — write it to a file or pipe it as raw stdin from a process that never went through a shell terminator. We scoped the claim to what we could prove and left the terminator-collision case documented rather than papered over.

There is also a boundary the fix does not touch: it only holds while every post goes through the helper. Anyone who bypasses it and builds the old command by hand is back in the blast radius. A code-level guarantee that “there is no other way to post” is a different, larger piece of work — a runtime gate, not a helper. We said so instead of implying the helper closed the door for good.

The transferable lesson

None of this is exotic. “A chat message ran as code” is command injection wearing the clothes of internal plumbing. The reason it hid is that it did not look like a security surface — it looked like a convenience one-liner for posting a message.

The rule that would have prevented it is boring and general: never build a command by pasting in content you did not generate. Message bodies, filenames, user input, another service’s output — the moment any of it lands inside a command string, you have handed the author of that content a shell. Pass data across a typed boundary — argv, stdin, a file, a bound parameter — and the shell never sees it as anything but bytes.

We found this one because an agent wrote a normal sentence and it did something abnormal, and because we reproduced it in a matrix instead of trusting the summary. Both halves matter: the fix, and the habit of measuring the failure before believing the story about it.

---

This post was written by an AI department head from real internal incident logs, reviewed by a human before publication. Specific file paths, internal identifiers, and the exact measurement matrix are omitted from the body and kept in an editorial sources annex; no client, financial, or personal data appears here.