# GHSA-qrmm-w75w-3wpx: Server side request forgery in SwaggerUI

> Attackers can trick users into visiting malicious OpenAPI definitions via URL parameters, enabling phishing attacks on self-hosted SwaggerUI instances.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 9 Dec 2021

## What is GHSA-qrmm-w75w-3wpx?

GHSA-qrmm-w75w-3wpx is a server-side request forgery vulnerability in Swashbuckle.AspNetCore.SwaggerUI, published on 9 Dec 2021. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.

### Official description

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)](https://github.com/swagger-api/swagger-ui/issues/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:

```js
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.

## Which versions are affected by GHSA-qrmm-w75w-3wpx?

8 open source packages ship an affected version, including Swashbuckle.AspNetCore.SwaggerUI, swagger-ui and swagger-ui-dist.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `Swashbuckle.AspNetCore.SwaggerUI` | NuGet | All versions | 6.3.0 |
| `Swashbuckle.AspNetCore.SwaggerUI` | NuGet | All versions | 6.3.0 |
| `swagger-ui` | npm | All versions | 4.1.3 |
| `swagger-ui` | npm | All versions | 4.1.3 |
| `swagger-ui-dist` | npm | All versions | 4.1.3 |
| `swagger-ui-dist` | npm | All versions | 4.1.3 |
| `swagger-ui-react` | npm | All versions | 4.1.3 |
| `swagger-ui-react` | npm | All versions | 4.1.3 |

## How do I fix GHSA-qrmm-w75w-3wpx?

Upgrade Swashbuckle.AspNetCore.SwaggerUI to 6.3.0 or later.

## Is GHSA-qrmm-w75w-3wpx being exploited?

There is no known exploitation of GHSA-qrmm-w75w-3wpx in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-qrmm-w75w-3wpx and fix it if it is affected.

What it is: GHSA-qrmm-w75w-3wpx is a server-side request forgery vulnerability in Swashbuckle.AspNetCore.SwaggerUI, published on 9 Dec 2021. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-qrmm-w75w-3wpx in the wild and no public exploit code.

Affected packages and fixed versions:
- Swashbuckle.AspNetCore.SwaggerUI (NuGet): affected all versions; fixed in 6.3.0
- Swashbuckle.AspNetCore.SwaggerUI (NuGet): affected all versions; fixed in 6.3.0
- swagger-ui (npm): affected all versions; fixed in 4.1.3
- swagger-ui (npm): affected all versions; fixed in 4.1.3
- swagger-ui-dist (npm): affected all versions; fixed in 4.1.3
- swagger-ui-dist (npm): affected all versions; fixed in 4.1.3
- swagger-ui-react (npm): affected all versions; fixed in 4.1.3
- swagger-ui-react (npm): affected all versions; fixed in 4.1.3

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-qrmm-w75w-3wpx/ (Markdown: https://insights.sbomify.com/GHSA-qrmm-w75w-3wpx/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-qrmm-w75w-3wpx

---
From sbomify Insights: https://insights.sbomify.com/GHSA-qrmm-w75w-3wpx/
Summaries are generated and may contain mistakes; the official description above is the record.