fix(sanitize): preserve angle brackets inside code blocks and inline code

[blackwell-systems]

Description

bluemonday.StrictPolicy() treats angle brackets inside markdown code blocks and inline code spans as HTML tags and strips them. This causes content like mut_raw_ptr<int> in issue/PR bodies to become mut_raw_ptr when read through MCP endpoints.

Before

let ptr: mut_raw_ptr<int> = raw_new int;

Agent sees: let ptr: mut_raw_ptr = raw_new int;

After

Agent sees: let ptr: mut_raw_ptr<int> = raw_new int;

Root cause

FilterHTMLTags calls bluemonday.Sanitize() on the entire markdown body without distinguishing code from prose. Bluemonday treats <int>, <T>, <String>, etc. as unrecognized HTML tags and removes them.

Fix

Before HTML sanitization, replace < and > inside fenced code blocks (```) and inline code spans (`) with null-byte sentinels that bluemonday will not interpret as HTML. After sanitization, restore the sentinels to angle brackets.

This preserves XSS protection for angle brackets in prose (e.g. <script> is still stripped) while keeping angle brackets inside code intact.

Testing

Added 6 test cases covering:

• Fenced code blocks with angle brackets (the reported bug)
• Inline code with generic types (Vec<String>)
• Angle brackets outside code still sanitized (XSS protection preserved)
• Multiple inline code spans
• Fenced code with language info string

Fixes #2202

[jluocsa]

Thanks for picking up #2202 — generic-type angle brackets disappearing from code blocks is a long-standing irritation. The CommonMark-aware fence/inline detection is much better than a regex-based approximation.

Before merge, I think there's a security-sensitive issue worth addressing:

Sentinel collision can be used to bypass the HTML sanitizer.

The current sentinels are:

const (
    ltSentinel = "\x00LT\x00"
    gtSentinel = "\x00GT\x00"
)

Sanitize runs in this order:

cleaned   := FilterCodeFenceMetadata(FilterInvisibleCharacters(input))
protected := protectCodeAngleBrackets(cleaned)
sanitized := FilterHTMLTags(protected)
return restoreCodeAngleBrackets(sanitized)

FilterInvisibleCharacters strips a specific list of Unicode codepoints (see shouldRemoveRune in pkg/sanitize/sanitize.go — zero-width spaces, BiDi controls, tag characters, etc.) but does not strip \x00 (NUL is not in the list).

That means an attacker who controls input — e.g. an issue title, PR body, search-result snippet, etc. — can submit:

\x00LT\x00script\x00GT\x00alert(1)\x00LT\x00/script\x00GT\x00

…outside any code block. The flow is:

1. FilterInvisibleCharacters → passes through (NUL not stripped)
2. FilterCodeFenceMetadata → passes through (no fence)
3. protectCodeAngleBrackets → passes through (no backticks, the sentinel literal is treated as ordinary text)
4. FilterHTMLTags (bluemonday) → passes through (\x00LT\x00script... is not HTML)
5. restoreCodeAngleBrackets → substitutes back into <script>alert(1)</script>

The output now contains raw HTML/JS that should have been stripped, defeating the purpose of FilterHTMLTags.

A few mitigation options, in increasing order of robustness:

• Add \x00 to shouldRemoveRune. Cheapest fix; consistent with the existing "strip control / invisible chars" policy. Adding it before protectCodeAngleBrackets guarantees no pre-existing sentinels.
• Pre-scan for the literal sentinel and refuse / escape it. A bit more code, no change to filter semantics.
• Use a per-call randomized sentinel (generate two crypto-random byte sequences once per Sanitize invocation). Defeats collision by construction; only downside is a small allocation per call.

Option 1 seems most consistent with what FilterInvisibleCharacters is already doing, and the smallest possible change. A unit test mirroring TestSanitizePreservesAngleBracketsInCodeBlocks with input containing the literal sentinel would lock the behavior in.

Minor: closing-fence detection. protectCodeAngleBrackets treats any run of >= fenceLen backticks as a closing fence (anywhere on the line). CommonMark requires the closing fence to be on its own line and not have an info string. The current implementation is more permissive, which in practice means a stray ``` inside what was meant to be the fenced content will end protection early. This is a soft-fail (some < get stripped that shouldn't be) rather than a security issue, so probably acceptable, but worth a comment near the loop documenting the deviation.

Tests are nicely focused, the inline-vs-fenced split is handled, and [T comparable]-style generics outside code (where they really might be HTML-ish) are still cleaned. Once the sentinel exposure is closed, this is a great fix.