CVE-2026-108260

Tina is a headless content management system. Prior to 0.2.1, the tina-markdown element in packages/@tinacms/web-components/src/tina-markdown.js assigns a rich-text node.url value directly to an anchor href without validating the URL scheme. A content author can store a link using a script-capable scheme, and a visitor who clicks the rendered link executes attacker-controlled script in the site's origin. The script can access same-origin application data and, when the visitor is an editor or administrator, may expose credentials stored by the TinaCMS admin on that origin. This issue is fixed in version 0.2.1.

Tina is a headless content management system. Prior to 0.2.1, the tina-markdown element in packages/@tinacms/web-components/src/tina-markdown.js assigns a rich-text node.url value directly to an anchor href without validating the URL scheme. A content author can store a link using a script-capable scheme, and a visitor who clicks the rendered link executes attacker-controlled script in the site's origin. The script can access same-origin application data and, when the visitor is an editor or administrator, may expose credentials stored by the TinaCMS admin on that origin. This issue is fixed in version 0.2.1.

Summary

<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…

Tina is a headless content management system. Prior to 0.2.1, the tina-markdown element in packages/@tinacms/web-components/src/tina-markdown.js assigns a rich-text node.url value directly to an anchor href without validating the URL scheme. A content author can store a link using a script-capable scheme, and a visitor who clicks the rendered link executes attacker-controlled script in the site's origin. The script can access same-origin application data and, when the visitor is an editor or administrator, may expose credentials stored by the TinaCMS admin on that origin. This issue is fixed in version 0.2.1.

Tina is a headless content management system. Prior to 0.2.1, the tina-markdown element in packages/@tinacms/web-components/src/tina-markdown.js assigns a rich-text node.url value directly to an anchor href without validating the URL scheme. A content author can store a link using a script-capable scheme, and a visitor who clicks the rendered link executes attacker-controlled script in the site's origin. The script can access same-origin application data and, when the visitor is an editor or administrator, may expose credentials stored by the TinaCMS admin on that origin. This issue is fixed in version 0.2.1.

Summary

<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…