Gems 1.0.2 and 1.0.3 bundle DOMPurify 3.3.0 instead of 3.4.17, bringing back 20 fixed advisories #1325

The lexxy 1.0.2 and 1.0.3 gems on RubyGems bundle DOMPurify 3.3.0, not the 3.4.17 that both tags' package.json and yarn.lock pin (#1315). The 1.0.1 gem bundled 3.4.13, so anyone who updates the gem past 1.0.1 gets an older sanitizer. That brings back 20 DOMPurify advisories that were already fixed, one of them rated high. The npm packages declare dompurify: ^3.4.17 as a dependency and are fine. Only the JS built into the gem is affected.

The same thing happened with 0.9.33.

Evidence

for v in 1.0.1 1.0.2 1.0.3; do gem fetch lexxy -v $v && gem unpack lexxy-$v.gem; done
grep -o '@license DOMPurify [0-9.]*' lexxy-1.0.1/app/assets/javascript/lexxy.js   # @license DOMPurify 3.4.13
grep -o '@license DOMPurify [0-9.]*' lexxy-1.0.2/app/assets/javascript/lexxy.js   # @license DOMPurify 3.3.0
grep -o '@license DOMPurify [0-9.]*' lexxy-1.0.3/app/assets/javascript/lexxy.js   # @license DOMPurify 3.3.0
grep -o "DOMPurify.version = '[0-9.]*'" lexxy-1.0.3/app/assets/javascript/lexxy.js # DOMPurify.version = '3.3.0'

lexxy.min.js in both gems has the same banner, and the 1.0.2 source map resolves node_modules/dompurify/dist/purify.es.mjs. The 1.0.3 gem we checked matches the SHA-256 that RubyGems publishes (2af129e6…221928).

Advisories 3.3.0 reintroduces

These are fixed in 3.4.13, which 1.0.1 shipped, and are back in 1.0.2 and 1.0.3:

Five more are fixed in 3.4.16 and 3.4.17, the version #1315 moved to: GHSA-6688-9rhm-gjv2, GHSA-p98j-92pf-mc4p, GHSA-c6gr-qvv4-5v3f, GHSA-cg2g-xh64-v4q7 and GHSA-mrv2-3pqr-j5jr. Compared with what v1.0.2's lockfile intends, the gem is missing 25 fixes.

Lexxy calls sanitize() on strings rather than with IN_PLACE, so the IN_PLACE-only advisories shouldn't apply. We haven't audited whether the others can be reached through Lexxy's hooks and per-editor allowlists. That includes the high-severity GHSA-87xg-pxx2-7hvx and the mXSS one, GHSA-h8r8-wccr-v5f2.

It also breaks Lexxy's own Trusted Types opt-out

trustedTypesPolicy() hands DOMPurify an explicit TRUSTED_TYPES_POLICY: null when Lexxy has no policy of its own. The comment above that code says the explicit null exists so that DOMPurify never falls back to creating a dompurify policy. DOMPurify 3.3.0 has no null branch: a falsy value lands in the else branch and creates the dompurify policy anyway (around line 5487 of the 1.0.2 lexxy.js). With 3.4.13 the opt-out works.

Likely cause

app/assets/javascript/ is gitignored, and the gem's JS is built at release time. The Rakefile hooks yarn build into rake build without running yarn install, and none of the workflows in .github/workflows publishes the gem. So the gem bundles whatever is in the node_modules of the machine that runs rake release. DOMPurify 3.3.0 was the locked version until #1229, which moved to 3.4.13 and shipped in 0.9.31. The node_modules used for 0.9.33, 1.0.2 and 1.0.3 must predate that change. The Rakefile at v1.0.3 is unchanged, so nothing in the release process stops it from happening again.

Suggested fix

#1326 implements the build changes below.

• Publish a new release from a clean install.
• Run yarn install --frozen-lockfile in the yarn_build task before yarn build, so a release can't pick up stale dependencies.
• Optionally, fail the build when the bundled @license DOMPurify version doesn't match yarn.lock.

We found this while updating an app from 1.0.1 to 1.0.2, and checked 1.0.3 when it came out. We're staying on 1.0.1 until a fixed gem is out.