Summary
The regex pattern @"[^]+"at line 210 in GitHubIssueReporter.cs uses a naive non-greedy negated character class that fails on nested backticks, escaped backticks in template literals, or code containing backticks as values (e.g., markdown examples withconst x = `template`` strings). This leaves code-like content in submitted GitHub issues when backticks appear inside the matched span.
Where
src/CodeIndex/Cli/GitHubIssueReporter.cs:208-211tests/CodeIndex.Tests/GitHubIssueReporterTests.cs:89-103 (no test for nested/escaped backticks)
Suggested approach
- Add unit tests that verify ScrubInlineCode correctly handles: escaped backticks, nested templates, backticks as code values
- Define what "correct" scrubbing means — is it safe to preserve outer backticks if inner content is stripped?
- Audit the description text for other code block patterns that bypass the single-backtick regex (triple-backtick blocks, HTML tags)
- Consider switching to a more defensive regex or a multi-pass sanitization that handles multiple escaping layers
- Document the scrubbing policy explicitly: what survives, what gets replaced, and why
- Add regression tests to prevent re-introduction of this vulnerability in future refactors
Summary
The regex pattern
@"[^]+"at line 210 in GitHubIssueReporter.cs uses a naive non-greedy negated character class that fails on nested backticks, escaped backticks in template literals, or code containing backticks as values (e.g., markdown examples withconst x = `template`` strings). This leaves code-like content in submitted GitHub issues when backticks appear inside the matched span.Where
src/CodeIndex/Cli/GitHubIssueReporter.cs:208-211tests/CodeIndex.Tests/GitHubIssueReporterTests.cs:89-103(no test for nested/escaped backticks)Suggested approach