Skip to content

Comments

Potential fix for code scanning alert no. 63: Inefficient regular expression#62

Draft
Tanker187 wants to merge 1 commit intomainfrom
alert-autofix-63
Draft

Potential fix for code scanning alert no. 63: Inefficient regular expression#62
Tanker187 wants to merge 1 commit intomainfrom
alert-autofix-63

Conversation

@Tanker187
Copy link
Owner

Potential fix for https://github.com/Tanker187/vite/security/code-scanning/63

In general, to fix inefficient regular expressions we need to remove or reduce the ambiguity inside quantified subpatterns so that the engine has a deterministic path and doesn’t need to explore exponentially many alternatives. Common techniques are: (1) making alternatives mutually exclusive (e.g., via more specific character classes), (2) replacing nested greedy quantifiers with a single, clearer one, and (3) restructuring the overall pattern to avoid “Kleene star over ambiguous alternation”.

Here, CodeQL flags [^\n]* in the branch //[^\n]*[$\n] of entirelyImportRE. The overall pattern is:

const entirelyImportRE =
  /^(?:import\s*(?:"[^"\n]*[^\\\n]"|'[^'\n]*[^\\\n]');*|\/\*[\s\S]*?\*\/|\/\/[^\n]*[$\n])*$/

Semantics: the whole string must be composed only of:

  • ESM import statements with string literals (side-effect imports),
  • block comments /* ... */, or
  • line comments // ... that end with either $ or a newline.

The problematic // branch is:

\/\/[^\n]*[$\n]

Within the big outer (?: ... )*, this branch is followed by other branches and repetition, and the [^\n]* part is greedy and can consume many $ and / characters that also participate in the outer structure; when the match ultimately fails at the end, the engine must backtrack in many ways. We can avoid this by tightening the line-comment branch so that it consumes characters only up to the first $ or newline, since the pattern anyway requires the comment to end with $ or newline. That is, instead of “any non-newline characters, then $ or newline”, we can use “any non-newline and non-$ characters, then a $, then the rest until newline/EOF”. This removes the ambiguity regarding where a $ inside the comment is consumed.

A precise, behavior-preserving rewrite is:

\/\/[^\n$]*\$(?:[^\n]*\n|[^\n]*$)

Explanation:

  • \/\/ – line comment start.
  • [^\n$]* – any number of characters that are not newline and not $, ensuring the first $ we encounter is special.
  • \$ – the required $ marking the end of the “special” part.
  • (?:[^\n]*\n|[^\n]*$) – the rest of the line until newline or (if this is the last line) end of string.

This still enforces that a // comment must contain at least one $ before the end-of-line or end-of-string, like the original //[^\n]*[$\n], but makes the quantifiers unambiguous: there is exactly one $ used as the “terminator” for the requirement, and [^\n$]* cannot also consume it.

We can now update entirelyImportRE to use this safer line-comment branch, leaving the other branches and anchors unchanged. No new imports or helper functions are required; we only change the regex literal in entirelyImportRE.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

…ression

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
@Tanker187 Tanker187 self-assigned this Feb 11, 2026
Repository owner locked and limited conversation to collaborators Feb 11, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant