Validate CVE-2026-44990 is introduced in 2.17.3 and not versions affected <=2.17.3

[ocljlayton]

Hi,

In assessing CVE-2026-44990 alerted here - GHSA-rpr9-rxv7-x643 we think the issue might have been introduced in 2.17.3 specifically, and versions below it are not affected subsequently. Please confirm. The aforementioned URL details <= 2.17.3 and not = 2.17.3.

Kind regards

Jamie

[Matsuuu]

From my local testing, it seems that the vulnerability was introduced in version 2.17.3

[Matsuuu]

I think this is the only commit targeting that timeframe 49d0bb7

Seems like it's already fixed here but there's just no release yet.

[kroleg]

Also caught it. Can verify with

  for v in 2.13.0 2.13.1 2.14.0 2.15.0 2.16.0 2.17.0 2.17.1 2.17.2 2.17.3; do
    mkdir t-$v && cd t-$v
    npm i sanitize-html@$v --silent
    node -e "const s=require('sanitize-html');
             console.log(JSON.stringify(s('<xmp><script>alert(1)</script></xmp>')));"
    cd ..
  done

Results:

• 2.13.0 → 2.17.1: output "" (xmp content fully stripped)
• 2.17.2: output "<script>alert(1)</script>" (escaped — safe)
• 2.17.3: output "<script>alert(1)</script>" (raw HTML — the bypass)

[Yuniac]

Any chance to approve the PR before monday?

[BoDonkey]

The fix cited above has already been released in 2.17.4.

[Dipanshusinghh]

@BoDonkey The testing results shared above make things much clearer.

From what i can see, versions before 2.17.3 dont seem to expose the same behavior, while 2.17.3 is where the raw html passthrough actually starts happening. So it does look more like the issue was introduced there specifically instead of affecting all versions <=2.17.3.

Pointing that out in the advisory would probably help avoid confusion for people checking whether older deployments are actually impacted or not.

[ocljlayton]

Marking as resolved subsequently. My primar aim was to get clarification and have the advisory corrected, to save others time in their assessment.

[Loki-Afro]

@BoDonkey while i see that there is a version 2.17.4 on npmjs https://www.npmjs.com/package/sanitize-html/v/2.17.4 i don't see a tag in this repo?

[Dipanshusinghh]

@BoDonkey @ocljlayton @Matsuuu @mhassan1 while the affected version range now seems clarified, I think one part of the underlying change may still deserve a closer look.
The behavior introduced in 49d0bb7 doesn’t only affect the demonstrated <xmp> payload — it also changes how text from raw-text style elements is forwarded:

result += text;

Previously those paths ultimately went through escaping logic, but this branch now bypasses that for certain parser states.
The current advisory discussion mostly validates the specific <xmp><script> case and the affected versions (2.17.3 → fixed in 2.17.4), but I’m not sure whether other raw-text edge cases were exhaustively reviewed as part of the fix validation.

For example:

• parser state transitions involving malformed raw-text tags
• interactions with recursiveEscape / escape
• behavior differences across other raw-text elements (noembed, noframes, etc.)

Not saying there is another confirmed bypass yet — just that the scope of the introduced parsing change appears broader than the currently documented payload.

If there’s interest, I’d be happy to help test additional edge cases around the raw-text handling paths as well.

[BoDonkey]

@Dipanshusinghh - Do you know if the cases you mentioned are in the existing test suite?

[Dipanshusinghh]

@BoDonkey I haven't audited the repository's full test suite locally yet, but standard suites generally focus on well-formed tags and the primary target elements reported in the advisory (like <xmp>).

The core concern here is that since 49d0bb7 introduced the lower-level parser state bypass (result += text;), the structural risk applies to the entire state machine's handling of raw-text and CDATA-style elements. The specific areas that might lack coverage include:

1. Sibling raw-text elements (such as <noembed>, <noframes>, or <noscript>) to ensure they don't accidentally inherit or transition into that same unescaped branch.
2. Malformed or unclosed raw-text tag sequences that could disrupt state transitions and leave the parser stuck in a raw passthrough state.
   If the current test suite only validates the specific <xmp><script> payload, these broader parsing paths might remain untested against the new logic.
   If these edge cases aren't currently mapped in the suite, please let me know or assign this to me—I'd be glad to look into the test specs, verify the state transitions, and help expand the test coverage via a PR.

[BoDonkey]

@Dipanshusinghh We don't assign tasks because people have a history of walking away without finishing, leaving an issue in limbo. We would be thankful for either an audit and update of the tests, or if you think there is a better approach than result += text that would address these other concerns, that would also be welcome.

[Dipanshusinghh]

Thanks for the clarity, @BoDonkey! Totally understand the policy. I’ll go ahead with auditing the current test suite locally and work on a PR to cover those raw-text edge cases
thanks!🙏🏼