[hitesh-shetty-cstk]

What the vulnerability was

Snyk SCA flagged dompurify@3.4.13/3.4.14 as vulnerable to a Cross-site Scripting (XSS) advisory. dompurify is a direct runtime dependency here.

Note: an earlier open PR (#634, dependabot) bumps dompurify to 3.4.13, which does not reach the fixed version — this PR supersedes that with a sufficient bump.

What the fix does

Bumps dompurify from ^3.4.13 to ^3.4.16 in package.json, and updates the corresponding node_modules/dompurify entry (version/resolved/integrity) plus the root package's declared range in package-lock.json to match.

How it was verified

• Confirmed dompurify is a direct dependency in package.json.
• Confirmed 3.4.16 satisfies the package's existing semver usage.
• No overrides/resolutions block added — direct version bump only.
• No build/test run, per the minimal-fix policy for this pass.

---

🤖 Generated with Claude Code

---

Generated by Claude Code

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[Copilot]

Copilot review overview

🟢 Approval recommended

The dependency declaration and lockfile metadata are consistent, with no unresolved issues found.

Review effort: Balanced
Findings: None

What changed in this PR

Updates the direct DOMPurify runtime dependency to a version containing the XSS security fix.

Changes:

• Bumps DOMPurify from ^3.4.13 to ^3.4.16.
• Synchronizes resolved package and integrity metadata.

File	Description
package.json	Updates the dependency range.
package-lock.json	Locks DOMPurify 3.4.16 and updates metadata.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	68.51%	2583 / 3770
🔵	Statements	67.4%	2626 / 3896
🔵	Functions	66%	466 / 706
🔵	Branches	62.76%	1554 / 2476

File Coverage

No changed files found.

Generated in workflow #944 for commit 01fd725 by the Vitest Coverage Report Action

[hitesh-shetty-cstk]

Automated review

What this changes: Raises the dompurify range in package.json from ^3.4.13 to ^3.4.16 and updates the one matching entry in package-lock.json (version, resolved URL, integrity). No source file changes. The single call site, sanitizeData in src/visualBuilder/utils/collabUtils.ts, is untouched.

I checked the lockfile edit against the npm registry rather than taking it on trust:

• dompurify@3.4.16 exists and is the current latest.
• The integrity hash in the lockfile matches the registry's published hash for 3.4.16 exactly, as does the resolved tarball URL. This is the check that matters most on a hand-edited lockfile.
• There is one dompurify entry in the lockfile, now at 3.4.16, and packages[""].dependencies agrees with package.json. A partial bump leaving a second entry on the old version is the usual failure mode here and it is not present.
• lockfileVersion is 3, so no legacy dependencies block needs a parallel edit.

One note on what the manifest bump actually buys, because it is easy to read it as doing more or less than it does. ^3.4.13 already permitted 3.4.16, so a fresh install was resolving to a patched version regardless. What this adds is a floor, so a consumer cannot land on 3.4.13 or 3.4.14 from a stale lockfile, a pinned resolution, or an offline cache. That is the right lever for this repo: tsup.config.js sets no noExternal, and tsup leaves dependencies external by default, so dompurify stays an import in dist and each consumer resolves it from the declared range.

Business impact: None identified. The change does reach customers through the published package's dependency range, so it is fair to treat as customer-facing, but a patch-level dompurify bump carries no expected behavior change. The only call site passes USE_PROFILES: { html: true } and strips remaining tags before using the result.

Security: Remediation rather than a new finding. Snyk and the org security workflow both report clean on this head, and I found nothing they miss. The supply-chain question specific to an edited lockfile, whether the integrity hash matches the real published artifact, I verified directly against the registry.

Flow

No flow change. A dependency bump with no altered control flow or message path.

Findings: 0 blocker, 1 should fix, 1 nit. The should-fix is inline on package.json. The nit is here, because it concerns a different pull request and has no honest line to anchor to.

Nit: #634 is still open. It is lockfile-only and moves dompurify from 3.4.12 to 3.4.13, below the floor this sets. It edits the same lockfile lines, so it cannot merge quietly after this one, and Dependabot normally closes its own pull request once the dependency moves past its target. Worth closing by hand if it does not.

Reviewer candidates: @kirtesh-cstk authored 8 of the last 30 commits on package.json. @csAyushDubey authored 6.

Not covered: I did not run the build, the unit tests, or an install. The test check was still in progress when I read it; the other checks on this head had passed. I could not independently confirm the advisory's affected range or its first patched version, because both advisory databases I tried were unreachable from this run. That part rests on Snyk's clean result for this head rather than on my own reading of the advisory record.

Automated review by Claude Code. A human review is still required.

---

Generated by Claude Code

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[hitesh-shetty-cstk]

Automated review

Re-review after new commits (pass 2 of 4).

What this changes: nothing new since the last pass. The only commit added is a merge of develop_v4 into the branch. Measured against its base, this pull request is still the same two files it was: dompurify moves from ^3.4.13 to ^3.4.16 in package.json, and package-lock.json is updated to match.

Business impact: none identified. dompurify has a single call site in the SDK, sanitizeData in src/visualBuilder/utils/collabUtils.ts, which builds the body of a Collab thread comment. 3.4.14 to 3.4.16 is a patch bump, so no behaviour change is expected on that path.

Security: nothing beyond what the scanners cover. Snyk ran against this head and reported no open source, license or code issues. I checked the bump holds up independently of that result: package-lock.json carries one dompurify entry and it is at 3.4.16, its integrity hash matches what the npm registry publishes for 3.4.16, the root dependency range in the lock agrees with package.json, and the lockfile is version 3, so there is no legacy dependencies mirror left behind on the old version.

Flow

No flow change. This is a dependency version bump with no control flow to draw.

Findings: 0 blocker, 1 should fix, 0 nit. The finding is in this body rather than inline, because it concerns a different pull request and has no line here to anchor to.

Should fix. #634 is still open. It bumps dompurify from 3.4.12 to 3.4.13 and targets main. The description here says this change supersedes it, but while #634 stays open it can still be merged later and move the declared range back down to ^3.4.13, one of the versions this change is moving away from. Closing #634 removes that path.

Merge check: the merge pulled in seven source files from the base branch, including the entries-in-page notification work from #662. None of them belongs to this pull request. The base-to-head diff is still only package.json and package-lock.json, which shows the merge took the base side without edits of its own. I did not re-review that code here; it was reviewed on #662.

Reviewer candidates: none, and no reviewer is requested on a re-review. The incremental diff for this pass is entirely base-branch content, so it carries no ownership signal for this change, and the change itself touches only dependency manifests.

Not covered: I did not run the build, the test suite, or the app. The test check was still in progress on this head while I reviewed. I did not inspect the contents of the published 3.4.16 tarball beyond its registry integrity hash, and I did not confirm which advisory identifier the scanner matched.

Automated review by Claude Code. A human review is still required.

---

Generated by Claude Code

[kirtesh-cstk]

LGTM