# Unencoded client metadata in render paths

Client-supplied metadata reaching HTML, JS, URI or SMTP sinks without context-aware encoding

_Area: Web injection and code execution. Seen in 3 disclosed reports; one confirmed bounty: $150; latest 2024-10-01. Updated 2026-10-24._

## How it works
A field supplied by the client or an import format is treated as inert data but consumed as markup, script, URI, or mail content. The broken assumption is that metadata is safe to pass through: parsers and renderers hand values like calendar DESCRIPTION, ATTENDEE/ATTACH, ID3 titles, or post embeds straight to an HTML sink, a JavaScript string, a mail header, or a URI/iframe loader without encoding matched to that context. A second write path makes it worse: validation applied when saving to the database is skipped when the same object is broadcast over websockets [E3](https://bugbountylibrary.com/r/h1%3A2541027.md).

## Where it shows up
- Calendar/import parsers handling RFC 5545 fields and undocumented X- properties, including deprecated ones still parsed [E1](https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-exploiting-icalendar-properties-enterprise-applications.md)
- Media metadata (ID3 tags, RTMP servername) stringified into JavaScript through a bridge like ExternalInterface [E2](https://bugbountylibrary.com/r/h1%3A29360.md)
- Post/embed metadata accepted from the client and broadcast verbatim over websockets [E3](https://bugbountylibrary.com/r/h1%3A2541027.md)
- Fields like ATTACH, ATTENDEE/ORGANIZER, or X-GOOGLE-CALENDAR-CONTENT-* passed to SMTP header or URI/iframe handlers [E1](https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-exploiting-icalendar-properties-enterprise-applications.md)

## How to review
Trace each metadata field from input to every sink. The invariant: each sink applies encoding matched to its context (HTML, JS string, URI, mail header), and all write paths share one sanitizer. Check that deprecated/proprietary fields are rejected or encoded, and that the broadcast path runs the same validation as persistence. Confirm sanitization happens server-side, not only in client rendering.

## Variants seen
- Stored XSS via calendar DESCRIPTION and legacy X- properties, plus SMTP header injection and arbitrary URI/iframe loading [E1](https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-exploiting-icalendar-properties-enterprise-applications.md)
- XSS through media metadata breaking out of a JS string context [E2](https://bugbountylibrary.com/r/h1%3A29360.md)
- Forged embeds and client crash from unsanitized websocket post metadata [E3](https://bugbountylibrary.com/r/h1%3A2541027.md)

## Why fixes fail
Sanitizing only the persistence path leaves the websocket broadcast path open [E3](https://bugbountylibrary.com/r/h1%3A2541027.md). Deprecating a property does not stop parsers from still consuming it [E1](https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-exploiting-icalendar-properties-enterprise-applications.md).

## Impact and severity
Stored XSS on high-value domains, SMTP header injection, and client crashes. Severity rises with trusted origin, cross-user persistence, and reach into mail or URI handlers. Adjacent but distinct: server-side fetching of remote metadata sources can also yield SSRF, a separate root cause from encoding.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Aspaceraccoon-dev-exploiting-icalendar-properties-enterprise-applications.md
- E2: https://bugbountylibrary.com/r/h1%3A29360.md
- E3: https://bugbountylibrary.com/r/h1%3A2541027.md