Vulnerability Database

328,409

Total vulnerabilities in the database

Server side request forgery in SwaggerUI

SwaggerUI supports displaying remote OpenAPI definitions through the ?url parameter. This enables robust demonstration capabilities on sites like petstore.swagger.io, editor.swagger.io, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.

However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.

An example scenario abusing this functionality could take the following form:

  • https://example.com/api-docs hosts a version of SwaggerUI with ?url= query parameter enabled.
  • Users will trust the domain https://example.com and the contents of the OpenAPI definition.
  • A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at https://evildomain.
  • Users mistakenly click a phishing URL like https://example.com/api-docs?url=https://evildomain/fakeapi.yaml and enters sensitive data via the "Try-it-out" feature.

We do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is not possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.

Resolution

We've made the decision to disable query parameters (#4872) by default starting with SwaggerUI version 4.1.3. Please update to this version when it becomes available (ETA: 2021 December). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.

Workaround

If you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:

SwaggerUI({ // ...other configuration options, plugins: [function UrlParamDisablePlugin() { return { statePlugins: { spec: { wrapActions: { // Remove the ?url parameter from loading an external OpenAPI definition. updateUrl: (oriAction) => (payload) => { const url = new URL(window.location.href) if (url.searchParams.has('url')) { url.searchParams.delete('url') window.location.replace(url.toString()) } return oriAction(payload) } } } } } }], })

Future UX work

Through the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the "Execute" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.

Reflected XSS attack

Warning in versions < 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.

No technical information available.

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.