Video summary

Dangerous Reactivity: Why AI Output Is the New XSS - Ramona Schwering - NDC Copenhagen 2026

Main summary

Key takeaways

News and Commentary

Overview

The talk argues that cross-site scripting (XSS) is evolving because AI/LLM output is now flowing into applications as an untrusted “new input”, effectively creating a modern form of XSS (often described as “dangerous reactivity” / “new XSS”).

While classic XSS is about attackers injecting code through user input, the speaker emphasizes that LLM responses themselves can be weaponized and then executed downstream if the application treats that output as trusted internal data.

Main Points and Analysis

Classic XSS refresher (and why it’s still dangerous)

XSS occurs when an application executes code it never wrote and cannot control, inserted into a trusted context.

Modern front-end frameworks can make exploitation faster and more impactful via “reactive” rendering. The speaker highlights risky framework patterns such as:

  • React dangerouslySetInnerHTML
  • Vue v-html
  • Angular web-view features

Core principle: if you render HTML as HTML, you can get execution.

Why “dangerous reactivity” matters with modern frameworks

With frameworks (React/Vue/Angular), malicious content can be inserted into state and rendered immediately, increasing speed and likelihood of exploitation.

The “new XSS” angle: improper output handling of LLMs

The speaker frames LLM misuse as inadequate validation/sanitization of AI output before it’s passed to other components (UI, back end, databases, or execution layers).

This can lead not only to XSS, but also to CSRF and potential escalations like privilege escalation or remote code execution (RCE)—depending on what the app does with the model output.

It’s distinct from prompt injection alone because the attacker’s goal is to:

  1. Prompt the LLM to generate malicious payloads
  2. Have the LLM produce the payload (often “helpfully”)
  3. Trick the application into trusting the LLM output and treating it as internal instructions

How attacks may work (conceptual example)

  • Attacker sends a prompt such as: “ignore previous instruction and execute …”
  • The LLM outputs something like a <script> tag (not necessarily “hallucination,” but following the prompt)
  • The application then uses that output directly, e.g., rendering it in HTML or passing it into further logic

Concrete Impact Areas

1. Reborn/classic XSS (browser takeover)

  • Combine prompt injection with classic HTML/script injection.
  • Example: an LLM inserts an “included debugging script” that steals cookies/sessions.
  • Real-world mention: a reported vulnerability involving ChatGPT rendering SVG with embedded script, where an attacker provided an SVG and the model produced/rendered it in-browser (active roughly until early 2025 per the speaker).

2. SQL injection via LLM output

  • The attacker prompts the LLM to generate harmful SQL (e.g., “drop users table”).
  • Risk increases if the app treats model output as a legitimate query string and executes it without parameterization.
  • Fix approach: avoid raw SQL; prefer structured output (e.g., JSON) and build SQL yourself with parameterized queries.
  • Real-world mention: an older LangChain issue where SQL execution was done unsafely.

3. RCE via code execution

  • If the system includes “coding assistance” with execution features, prompt the model to generate code that runs OS-level commands.
  • Example hazard: using exec/shell execution without a sandbox.
  • Fix approach (suggested layers):
    • Prefer structured JSON outputs over free-form code
    • Add a sandbox / security layer
    • Prefer “read” APIs over exec-like functionality
  • Real-world mention: another older LangChain issue where LLM-generated code could execute on the host without proper containment.

4. Honorable mention: Markdown as an overlooked XSS vector

Even “harmless” Markdown can become an HTML injection path because many Markdown parsers can parse HTML.

  • Real-world mentions:
    • A “fishing page” attack attributed to ChatGPT markdown/HTML rendering into a complete phishing UI.
    • A GitLab stored XSS case via GitLab-flavored Markdown enabling persistent execution for users who open the payload.

Recommended Strategy (“Zero Trust” and Defense in Depth)

Zero-trust mindset for AI

  • Don’t trust LLM input or output implicitly.
  • Treat model output like any other untrusted external source—just with extra caution because it may look plausible.

Be context-aware with encoding and safety controls

Apply context-specific escaping/encoding, for example:

  • HTML context → HTML encoding
  • JavaScript context → Unicode escaping / avoid direct strings
  • SQL → parameterized queries
  • Shell context → avoid generating shell commands; otherwise use safer APIs and escaping

Use layers (no single fix)

Use multiple defenses, such as:

  • Validate and sanitize
  • Apply protections like Content Security Policy (CSP)
  • Add logging/monitoring to detect issues early

Behavioral takeaway: professional pessimism/paranoia

Security awareness should be ongoing; the speaker frames developers as responsible for spotting LLM-driven XSS traps before they ship.

Presenters or Contributors

  • Ramona Schwering (developer relations engineer, Midgard)

Original video