Manipulating RPKI (and more) with marquees in TLS certificates (and more)#

Sasha Romijn, Reliably Coded (IRRD, IRRexplorer, internet.nl)

• Why: A year-long, systematic XSS campaign against the tooling layer around routing infrastructure — culminating in a chain that modifies RPKI ROAs from a single clicked link. Directly relevant to network security and to anyone building tools that render protocol-derived strings.
• What: The author injected marquee/XSS payloads into every protocol field he controls — TLS certificate SANs, DNS version.bind/NSID/TXT, RIPE Database objects, HTTP Server headers, DHCP hostnames, wifi SSIDs, LoRa node names — and catalogued where downstream tools execute them. Findings span two RIRs, hosting providers (WHMCS on the main domain → one click adds an admin to a customer account), router firmware, and wirelessly rootable OpenWRT boxes. Most seriously: multiple paths through the RIPE NCC single sign-on session mean one click on a real ripe.net link can silently change your ROAs and take over your Database objects — you'd only notice when packets start dropping.
• How: The recurring pattern: tools treat protocol fields as safe data, and some of those tools share a trust boundary with critical systems. The punchline: "RPKI has HSMs and key ceremonies, but the thing that actually changes your ROAs is a web app authenticated by a cookie."
• Where applicable: Universal for anyone operating RPKI/IRR portals or writing tooling that displays untrusted fields; concrete guidance on what to watch for in your own tools.