A reflected XSS in Cisco Webex Meetings, and what a clean disclosure looks like
Notes on reporting CVE-2026-20233, an unauthenticated reflected cross-site scripting issue in the Webex Meetings web interface, and the process that turned it into a fixed product and a named credit.
This is a short write-up of CVE-2026-20233, a reflected cross-site scripting issue in the Cisco Webex Meetings web interface. Cisco fixed it on the server side and credited the report by name in its advisory. I am keeping the technical detail at the level the public advisory already covers, and focusing on the parts that transfer to other work: how the class of bug behaves, how I validated it without causing harm, and how the disclosure ran.
The shape of the bug
Reflected cross-site scripting happens when a web application takes input from a request and places it back into a response without encoding it for the context it lands in. If an unauthenticated attacker can craft a link that carries that input, they can get script to run in the browser of anyone who follows the link, in the security context of the affected origin.
Cisco rated this one CVSS 3.1 base 6.1. The vector that matters here is UI:R: it needs a user
to follow a crafted link. That is not a reason to dismiss it. Meeting links are shared constantly,
and users are trained to click them.
Validating without causing harm
On a production service you never reach for a payload that touches other users or persists anything. The goal is a single, self-contained proof that input reaches an executable context, observed only in my own browser. A benign marker that changes the rendered page for me alone is enough to confirm the finding and write it up. Anything beyond that adds risk without adding evidence.
The fix
The durable fix for reflected XSS is contextual output encoding, backed by a content security policy so that even a missed sink has a smaller blast radius. A response header like the one below turns “script ran” into “script was blocked and reported.”
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'; report-uri /csp-report
The disclosure
I reported through Cisco’s product security process, they reproduced it, fixed it in the cloud service so customers needed no action, and published an advisory that credits the report. That is the outcome worth optimizing for: the product is safer, and the record is public and verifiable.
The advisory is cisco-sa-webex-xss-jw3NeQzS.