Fix out-of-bounds read in JS highlighter on trailing backslash in ${}

[robobun]

Fixes #31434

Repro

Launching the REPL and typing `${\ verbatim (backtick, $, {, trailing backslash) dumps garbage from adjacent memory and segfaults on 1.3.14, and panics on 1.4.0-canary:

panic: range end index 5 out of range for slice of length 4

Node and Deno handle the same input without crashing.

Cause

The QuickAndDirtyJavaScriptSyntaxHighlighter (src/bun_core/fmt.rs) — used by the REPL to highlight the current line — scans the contents of a ${...} interpolation with this loop:

while i < text.len() && text[i] != b'}' {
    if text[i] == b'\\' {
        i += 1;   // when '\' is the LAST byte, i becomes text.len()
    }
    i += 1;       // ...then this bumps i to text.len() + 1
}

When the backslash is the final byte, the skip runs the cursor past the end, and the subsequent slice &text[curly_start + 2..i] (fmt.rs:1970) is out of range. For `${\ the bytes are ['', '$', '{', '\'](len 4) andi` ends at 5.

The old Zig build had no bounds check and read adjacent memory (the "garbage text" in the report) before segfaulting; the Rust port turns the over-read into a panic. Same root cause, both behaviors.

The sibling string-scan loop a few lines below already guards its backslash skip with i + 1 < text.len() — the ${...} loop was missing that guard.

Fix

Add the same i + 1 < text.len() guard to the ${...} inner loop so the backslash skip can't push the cursor past the end. When the backslash is the last byte it's no longer skipped, the loop exits with i == text.len(), and the slice stays in range. All other inputs (backslash followed by more content, \}, \\) are unchanged. Mirrored into the .zig porting reference.

Verification

Regression cases added to test/js/bun/util/highlighter.test.ts, exercising the highlighter via highlightJavaScript from bun:internal-for-testing (same options the REPL uses).

• USE_SYSTEM_BUN=1 bun test test/js/bun/util/highlighter.test.ts → crashes (exit 132, range end index 5 out of range for slice of length 4 — matches the issue's crash report).
• bun bd test test/js/bun/util/highlighter.test.ts → 5 pass, 0 fail.

[robobun]

^{Updated 8:22 AM PT - May 26th, 2026}

✅ @robobun, your commit a42896e8cac3e5d3d7d011d41ce90999063b9175 passed in Build #58235! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 31435

That installs a local version of the PR into your bun-31435 executable, so you can run:

bun-31435 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2121238a-62eb-4dc0-97ce-a9d1ff21fd88

📥 Commits

Reviewing files that changed from the base of the PR and between 4c954ab and a42896e.

📒 Files selected for processing (3)

• src/bun_core/fmt.rs
• src/bun_core/fmt.zig
• test/js/bun/util/highlighter.test.ts

---

Walkthrough

The PR fixes an out-of-bounds read bug in the JavaScript syntax highlighter's template-literal scanning logic. Both Rust (fmt.rs) and Zig (fmt.zig) implementations now guard backslash-escape checks with a bounds condition before evaluating the escape character. New test cases verify the highlighter safely handles unterminated ${ interpolations with trailing backslashes.

Changes

Highlighter out-of-bounds read fix

Layer / File(s)	Summary
Bounds check in template-literal backslash handling src/bun_core/fmt.rs, src/bun_core/fmt.zig	Both implementations now check i + 1 < text.len before evaluating text[i] == '\\' in template-literal ${...} parsing, preventing index out-of-bounds when the escape occurs at the end of input.
Edge case test coverage test/js/bun/util/highlighter.test.ts	Parameterized test suite verifies the highlighter returns a string and does not crash or read past input bounds for multiple unterminated ${ template-literal cases containing trailing backslashes.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main fix: addressing an out-of-bounds read in the JS highlighter when a trailing backslash appears in ${} template literals.
Description check	✅ Passed	The description comprehensively covers the issue (including reproduction steps), root cause analysis, the fix applied, and verification method, exceeding the template requirements.
Linked Issues check	✅ Passed	The PR successfully addresses issue #31434: adds bounds checking to prevent out-of-bounds reads when trailing backslashes occur in ${} interpolations, matches the root cause analysis, and includes regression tests.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to fixing the out-of-bounds read in the highlighter and adding regression tests; no unrelated modifications are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

LGTM — minimal bounds-check fix mirroring the existing guard a few lines below, with regression tests.

Extended reasoning...

Overview

This PR fixes an out-of-bounds read in QuickAndDirtyJavaScriptSyntaxHighlighter when a backslash is the final byte inside an unterminated ${...} template-literal interpolation. The change is a single added condition (i + 1 < text.len()) in the inner backslash-skip branch, applied identically to src/bun_core/fmt.rs and the src/bun_core/fmt.zig porting reference, plus four regression cases in test/js/bun/util/highlighter.test.ts.

Security risks

None introduced. The change strictly tightens a bounds check, eliminating an OOB read/panic. The highlighter is a display-only formatter (REPL line coloring); no auth, crypto, or permission logic is involved.

Level of scrutiny

Low. This is a one-line guard that exactly mirrors the pre-existing pattern in the sibling string-scan loop a few lines below (fmt.rs:1999, fmt.zig same). The fix is mechanical and the reasoning is straightforward: when \ is the last byte, the double-increment pushed i to len+1, breaking the subsequent slice. With the guard, the loop exits at i == len and the slice stays in range. Behavior for all other inputs (backslash followed by content, \\}, \\\\) is unchanged since the guard only suppresses the skip when there's nothing after the backslash.

Other factors

• Regression tests added that crash on the unpatched build and pass on the patched build (verified per PR description).
• No CODEOWNERS entries cover these files.
• No outstanding reviewer comments.
• Bug-hunting system found no issues.