UID2-7707: suppress CVE-2026-73650 in .trivyignore

[swibi-ttd]

Suppresses CVE-2026-73650 (HIGH, svgo) — present in the image but not reachable from this service. Expiry 2026-11-18 (3 months). No code fix.

Why: The advisory's attack vector requires an application to run SVGO's removeScripts (removeScriptElement) plugin as a sanitizer over untrusted SVG input and then serve the optimized result to other users. In uid2-examples the vulnerable package is present only as build-time tooling: svgo is pulled in transitively by create-react-app (@svgr/webpack, postcss-svgo) to optimize the demo apps' own bundled SVG assets during npm run build. No source code imports svgo or invokes optimize(), and the runtime (server.js) is a static express server that never feeds untrusted SVGs through svgo. The removeScripts plugin is off by default and not enabled anywhere. The vulnerable code path is therefore unreachable at runtime. Additionally the flagged svgo@1.3.2 copy is locked inside react-scripts@5's @svgr/webpack@5.5.0 with no in-major fix available. Verdict rests on direct grep/read evidence (lockfiles, absent src imports, Dockerfile/server.js build-vs-runtime split); the only inference is the standard CRA build behavior.

Evidence: svgo appears only in the two scanned react-client-side lockfiles (javascript-sdk & google-secure-signals): svgo@3.3.3 (@svgr/plugin-svgo dep), postcss-svgo's svgo@2.8.1, and svgo@1.3.2 bundled in react-scripts@5/@svgr/webpack@5.5.0. No src/ file imports svgo or calls optimize() (grep in both src trees returned nothing). Dockerfile runs npm run build (CRA) then npm start -> server.js is plain express serving the static build; svgo runs only at CRA build time on the app's own trusted SVG assets, never against untrusted request input. removeScripts/removeScriptElement plugin is disabled by default and not configured.

Reachability alone determines suppress-vs-fix — a fixed version existing upstream does not make an unreachable path exploitable. Change the expiry in review if you want a different window.

Full triage report

CVE-2026-73650 / GHSA-2p49-hgcm-8545 — svgo removeScripts plugin leaves some executable scripts intact

Severity: HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N)
Package: svgo — installed 1.3.2, fixed in 2.8.3 / 3.3.4 / 4.0.2
Flagged repo: uid2-examples

What the CVE is

SVGO's removeScripts plugin (named removeScriptElement in v1–3, and disabled by default) is sometimes used as an SVG sanitizer. In vulnerable versions it fails to strip namespaced/prefixed script elements (e.g. <svg:script>) and, in v3/v4, matches javascript: URIs case-sensitively. An app that runs this plugin over untrusted SVG input and serves the result can leak stored XSS to viewers.

How it maps to our code

The scanner flagged two lockfiles, both React demo apps:

• npm/web-integrations/javascript-sdk/react-client-side/package-lock.json
• npm/web-integrations/google-secure-signals/react-client-side/package-lock.json

In both, svgo is present only as build-time tooling pulled in transitively by create-react-app:

• svgo@3.3.3 via @svgr/plugin-svgo
• svgo@2.8.1 via postcss-svgo
• svgo@1.3.2 bundled inside react-scripts@5 → @svgr/webpack@5.5.0 (the installed=1.3.2 hit)

Evidence gathered:

• Grep for svgo / optimize( across both apps' src/ trees returned nothing — no application code imports or invokes svgo.
• The Dockerfile runs npm run build (CRA production build) then npm start; server.js is a plain express server that serves the static built index.html. svgo only executes at build time, optimizing the apps' own trusted SVG assets.
• The removeScripts/removeScriptElement sanitizer plugin is off by default and is not enabled or configured anywhere.

Decision

not_affected. The vulnerable code path requires running the removeScripts plugin over untrusted SVG at runtime and serving the output. Here svgo never runs against untrusted input and the plugin is disabled — the path is unreachable. This holds regardless of the available fixes; notably the svgo@1.3.2 copy is locked inside react-scripts@5 with no in-major fix, so an upgrade there would break the CRA build.

Recommended action: suppress (accept) in the repo-root .trivyignore until react-scripts is upgraded or removed. This matches the existing acceptance entry already present for GHSA-2p49-hgcm-8545.

---

Opened by uid2-vul-scan-agent (general_use_claude-opus-4-8), verdict confidence high. Please sanity-check the reachability argument before approving.