Abandoned dependency: `cookieconsent@^3.1.1` (Insites cookieconsent)
`cookieconsent` (Insites/Osano cookieconsent v3) has not received maintenance for years; the upstream project was discontinued and the maintained replacement is `vanilla-cookieconsent` / Osano's commercial product.
"cookieconsent": "^3.1.1",The cookieconsent npm package (Insites cookieconsent v3.x) has been effectively unmaintained since ~2020. Open issues for XSS-via-content-config and CSP-incompatibility patterns have sat without fixes. Modern projects migrate to vanilla-cookieconsent (orestbida) or to a paid CMP. Continuing to ship the abandoned v3 line means no upstream channel for receiving security fixes if a new issue is reported.
- Check https://www.npmjs.com/package/cookieconsent — last publish year and
repository.url. - Compare with https://www.npmjs.com/package/vanilla-cookieconsent (active fork).
- Plan a migration; the API surface is small (banner config object).
All users of the consent banner see code from an unmaintained dependency. If a DOM-XSS or supply-chain issue is found, there is no upstream to release a patched version; the team must fork or migrate under pressure.
The "cookieconsent": "^3.1.1" entry is clearly present in frontend/package.json line 51. The Insites cookieconsent v3 package is factually abandoned (last meaningful release ~2020, repo archived, succeeded by vanilla-cookieconsent/Osano's commercial CMP). Per the scope rules, findings should be evaluated as if this were a real production app, so shipping an abandoned client-side dependency that renders HTML/text into the DOM is a legitimate supply-chain hygiene issue. No specific exploit chain is demonstrated here, but the dependency-abandonment claim itself is verifiable and accurate, so the finding stands as reported.
This is a maintenance-risk finding for cookieconsent@^3.1.1 in frontend/package.json — there is no concrete exploitable sink demonstrated in the code, only the fact that the upstream is abandoned and would not produce a patch if a future DOM-XSS were found. Worst-plausible code-visible exploitation would be a future DOM-XSS in the banner's content config delivered via a poisoned page or supply-chain publish, which requires a victim to load the page (UI:R) and presupposes a not-yet-discovered bug or chained pre-condition (AC:H). Any such DOM-XSS would execute in the frontend origin (S:U) and primarily allows tampering with page content/behaviour with limited attacker control (I:L), with no clear C or A impact from the abandonment itself. If a concrete CVE/sink is later identified, this should be re-scored against that specific issue.