Preact's Identity Crisis: When JSON Becomes Code via CVE-2026-22028

In the modern web ecosystem, we've largely outsourced our DOM manipulation anxiety to frameworks like React and Preact. We trust them to take our messy state and efficiently paint the screen. We assume that when we write <div>{userInput}</div>, the framework will treat userInput as exactly that: text. Maybe a number. But certainly not executable code.

Preact, the lightweight cousin of React, operates on Virtual DOM (VNode) objects. These are lightweight JavaScript objects that describe what the UI should look like. To prevent chaos, Preact (and React) historically rely on a mechanism to distinguish a "blessed" VNode created by the framework from a random JSON object sent by an API.

Usually, this is done via Symbols or non-enumerable properties—things that JSON.stringify() destroys and JSON.parse() cannot recreate. It is the digital equivalent of a holographic watermark on a banknote. If the watermark isn't there, it's just monopoly money.

But in CVE-2026-22028, Preact stopped checking for the watermark. It started accepting the monopoly money. And unfortunately for us, the attackers are printing cash.

The vulnerability is a classic Type Confusion bug, specifically CWE-843. The core issue lies in how Preact decides if a JavaScript object is a valid VNode that should be rendered as an element, or just a plain object that should be stringified or ignored.

Prior to version 10.26.5, Preact enforced strict checks. It looked for specific internal markers—often Symbols or specific integer constants—that an attacker cannot inject via a standard JSON payload because JSON doesn't support them. You can't put Symbol('react.element') in a JSON file. It just doesn't parse.

However, a regression introduced in 10.26.5 "softened" these checks. The developers likely tried to optimize the hot path of the renderer or support a specific edge case for serialization. In doing so, they inadvertently allowed "Duck Typing" on VNodes.

If it looks like a VNode (has a props property, has a type property) and quacks like a VNode (has a __v property set to 0 or null), Preact says, "Come on in!" This allows an attacker to construct a JSON object that satisfies these loose constraints, effectively forging a VNode without ever calling createElement.

Let's look at the logic. In a secure implementation, the check often involves a Symbol. Since JSON.parse returns "Plain Old JavaScript Objects" (POJOs), a secure check fails immediately against network data.

The Secure Pattern (Conceptual):

// Inside Preact's render loop
if (child && child.$$typeof === REACT_ELEMENT_SYMBOL) {
  // It's a real VNode, render it.
  renderVNode(child);
} else {
  // It's just data. Escape it and show text.
  document.createTextNode(String(child));
}

The Vulnerable Pattern (Regression):

Around version 10.26.5, the logic shifted to something that looks dangerously like this:

// The check became looser to support some internal optimization
if (child && (child.__v === 0 || child.constructor === undefined)) {
   // "Looks legit to me!"
   renderVNode(child);
}

The critical failure here is that __v: 0 is perfectly valid JSON. An attacker doesn't need to bypass a memory protection or guess a randomization seed; they just need to send { "__v": 0 } in their payload. The framework creates a VNode instance from this raw data, essentially letting the attacker define the type (HTML tag) and props (attributes) of the rendered element.

How does a hacker turn this into a weapon? Imagine a user profile page that fetches data from an API. The frontend code looks innocent enough:

// Vulnerable component
const Profile = ({ userBio }) => {
  // userBio comes directly from JSON.parse(apiResponse)
  return <div>{userBio}</div>;
};

Normally, if userBio is a string, it renders text. If userBio is an object, React/Preact usually warns you or stringifies it to [object Object]. But thanks to the type confusion, we can feed it a structure that Preact interprets as a command to render an image tag with an XSS payload.

The Payload:

{
  "type": "img",
  "props": {
    "src": "invalid_url_to_trigger_error",
    "onerror": "alert('System Compromised via Preact!');"
  },
  "__v": 0
}

When the application processes this:

1. The API returns the JSON.
2. The application passes the object into the JSX {userBio} expression.
3. Preact inspects the object.
4. It sees __v: 0 and assumes this is a valid VNode.
5. It reads type: "img" and creates an <img> DOM element.
6. It applies the props. src fails to load, triggering onerror.
7. Boom. Arbitrary JavaScript execution in the victim's session.

This isn't just an alert box. It's cookie theft, session hijacking, or forcing the user to perform actions (CSRF) on the platform.

This vulnerability is particularly nasty because it turns standard data handling into a remote code execution vector (in the browser context). Developers are taught to sanitize HTML strings, but they are rarely taught to sanitize JSON objects passed to the render tree because the framework is supposed to handle that isolation.

If you are using Preact 10.26.5 through 10.28.1, any endpoint where a user can store a JSON object that gets rendered into a view is a potential XSS vector. This includes:

• User Profiles: Bio fields, custom statuses.
• Comments: If the comment body is stored as JSON.
• Config Dashboards: Where settings might be rendered dynamically.

The CVSS score is 7.2 (High), but in the right application—say, a chat app or a dashboard with high privileges—the impact is critical. It bypasses standard XSS filters that look for <script> tags because the payload is just a JSON object.

The Preact team responded quickly (and correctly) by reverting the loose check and restoring strict type validation. The patch essentially ensures that VNodes must be created by the framework's internal factory methods, which stamp them with symbols or non-serializable properties that cannot be spoofed via JSON.

Remediation Steps:

1. Update Immediately: Move to 10.26.10, 10.27.3, or 10.28.2 depending on your branch.
2. Audit Your Renders: Search your codebase for usage of {variable} where variable comes directly from an API response without validation.
3. Defensive Coding: Even after patching, avoid passing raw objects to the render tree. Cast them explicitly:

// Do this:
<div>{String(userBio)}</div>
 
// Or this (if you expect an object structure):
<div>{userBio.text}</div>

This is a stark reminder: libraries are code, and code has bugs. Trust, but verify. And maybe don't trust JSON quite so much.