parser: Does not support HTML-like Comments (ECMAScript Annex B)

[timokoessler]

Description

We use the parser in a security library to detect code injections. A bug bounty hunter found a bypass using HTML-like comments, which are supported by Node.js (V8), but cannot be parsed by OXC.

If Annex B is not implemented intentionally, please close this issue.

Expected Behavior

OXC should parse the following code:

<!-- Test -->
console.log("Hello, world!");

<!-- Test
console.log("Hello, world!");

Links

• ECMAScript Annex B1.1 HTML-like Comments

[Boshen]

It seems that you offer a serious product. Would you be able to sponsor at a higher level to receive faster fixes?

[claude]

Analysis Summary

I've analyzed this issue and confirmed it can be fixed. The Oxc parser has partial support for HTML-like comments (ECMAScript Annex B), but there's a bug in the condition that checks when to enable this support.

Current Behavior

The parser currently fails to parse:

<!-- Test -->
console.log("Hello, world!");

Error: "Unexpected token" at the < character.

Root Cause

Location: crates/oxc_parser/src/lexer/punctuation.rs:32-34

The HTML comment detection code only activates when source_type.is_script() returns true:

Some(b'!') if self.source_type.is_script() && self.remaining().starts_with("!--") => {
    None
}

However, .js files are marked as ModuleKind::Unambiguous (not ModuleKind::Script), so is_script() returns false, and HTML comments are not recognized.

According to ECMAScript Annex B.1.3, HTML-like comments should be supported in non-strict mode code, which includes:

• Explicit script files
• Files with ambiguous module status (like .js files before parsing determines if they contain ESM syntax)

The same issue exists for --> comments in read_minus() at line 44-46.

Relevant Files

• crates/oxc_parser/src/lexer/punctuation.rs:18-59 - HTML comment detection logic
• crates/oxc_parser/src/lexer/byte_handlers.rs:288-291, 347-350 - Byte handlers that route to comment detection
• crates/oxc_span/src/source_type.rs - SourceType and ModuleKind definitions

Implementation Plan

Step 1: Add a helper method to SourceType

Add a method to check if HTML comments should be allowed:

// In crates/oxc_span/src/source_type.rs
pub fn allows_html_comments(self) -> bool {
    // HTML comments are allowed in script mode and unambiguous files
    // They are NOT allowed in explicit modules (.mjs) or strict mode
    matches!(self.module_kind, ModuleKind::Script | ModuleKind::Unambiguous | ModuleKind::CommonJS)
}

Step 2: Update the lexer checks

Update both HTML comment checks in crates/oxc_parser/src/lexer/punctuation.rs:

Line 32 (for <!--):

Some(b'!') if self.source_type.allows_html_comments() && self.remaining().starts_with("!--") => {
    None
}

Line 44-46 (for -->):

if self.token.is_on_new_line()
    && self.source_type.allows_html_comments()
    && self.next_ascii_byte_eq(b'>')
{
    None
}

Step 3: Add comprehensive tests

Add test cases in tasks/coverage/misc/pass/ to verify:

• <!-- at start of line
• <!-- mid-statement (should work)
• --> at start of line after newline
• --> in middle of line (should NOT work as HTML comment)
• Tests in both .js and .cjs files
• Verify .mjs files reject HTML comments (strict module mode)

Step 4: Run conformance tests

Ensure the changes pass:

just test
cargo coverage -- parser

Potential Concerns

1. Module vs Script semantics: Need to verify that .mjs files (explicit modules) correctly reject HTML comments, as they operate in strict mode
2. Backward compatibility: This change makes the parser more permissive, which should be safe
3. Performance: No performance impact - just changes the conditional check

Complexity Estimate

Low complexity - This is a straightforward bug fix:

• 1 new helper method (~5 lines)
• 2 condition changes (~2 lines each)
• Test cases (~50 lines)

Would you like me to proceed with implementing this fix?

[Boshen]

@timokoessler can you point me to your call site? Or show me how you are configuring your source type, and which version of Oxc you are using. The latest version of Oxc changed how .js extensions are intepreted.

[timokoessler]

It seems that you offer a serious product. Would you be able to sponsor at a higher level to receive faster fixes?

I will forward this internally. I personally really like the oxc toolchain.

[timokoessler]

@timokoessler can you point me to your call site? Or show me how you are configuring your source type, and which version of Oxc you are using. The latest version of Oxc changed how .js extensions are intepreted.

I pushed the failing tests here: AikidoSec/zen-internals#125. We were indeed using an old version of OXC for that part of the project before, but I tested it using the latest version. The parser is called here.

[overlookmotel]

When source type is Unambiguous, I think parser would need to do what it does for top-level await - store a potential error, and turn it into a real error if ESM syntax is found later in the file.

Either that, or we take the presence of an HTML comment as indicating "this file is definitely a script" (simpler).

Maybe it doesn't much matter which - either way you get an error if there's both an HTML comment and ESM syntax in the same file, and HTML comments are a real edge case.

Workaround for now is to pass a script SourceType to parser (if you're able to determine this).

[timokoessler]

Thanks for your response! For now we should be able to pass the source type in most cases.