GHSA-qrmm-w75w-3wpx

What it actually does

The flaw allows a Swagger UI deployment to be abused as a request initiator by supplying attacker-controlled remote OpenAPI definition or configuration URLs. In vulnerable versions, parameters such as external spec/config locations are not sufficiently constrained, which can cause the application or associated Swagger UI workflow to request arbitrary URLs. Depending on deployment and network placement, this can expose internal-only HTTP services, cloud metadata endpoints, localhost-bound administrative interfaces, or other resources not directly reachable by the attacker.

Why it matters to the business

Publicly exposed API documentation endpoints may become a path for attackers to probe internal networks or reach services that were intended to be private. The main operational risk is information disclosure and internal service reconnaissance, with higher impact in cloud environments where metadata services or management APIs are reachable from the affected application. This issue is not listed in CISA KEV and no public exploit maturity is indicated, but it is long-published and should be remediated because Swagger UI is commonly embedded in application stacks and may remain unnoticed in production.

How an attack unfolds

An attacker first discovers a publicly accessible Swagger UI endpoint, often under paths such as /swagger, /swagger-ui, /api-docs, or similar documentation routes. The attacker then supplies a crafted URL or configuration parameter that points Swagger UI to an attacker-chosen destination. They may start with an external collaborator server to confirm that requests are being initiated, then pivot to internal targets such as localhost services, RFC1918 addresses, service discovery endpoints, or cloud instance metadata addresses. If responses or side effects are observable through the Swagger UI behavior, server logs, timing, error messages, or callbacks to attacker-controlled infrastructure, the attacker can map reachable internal services and potentially retrieve sensitive data exposed by those services.

How to fix it

Upgrade all affected packages to fixed versions or later: swagger-ui to 4.1.3 or later, swagger-ui-dist to 4.1.3 or later, swagger-ui-react to 4.1.3 or later, and Swashbuckle.AspNetCore.SwaggerUI to 6.3.0 or later. Remove or restrict public access to Swagger UI in production where it is not required. Disable loading of arbitrary remote OpenAPI definitions or configuration URLs unless explicitly needed. If remote loading is required, enforce an allowlist of trusted domains and schemes, block private IP ranges, localhost, link-local addresses, and cloud metadata endpoints, and prevent redirects to disallowed destinations. Add egress controls so application hosts cannot reach internal administrative services or metadata endpoints except where explicitly required.

How to confirm the fix worked

Confirm dependency versions in package-lock.json, yarn.lock, pnpm-lock.yaml, packages.config, .csproj, or NuGet lock files and verify that all Swagger UI-related packages meet or exceed the fixed versions. Inspect deployed Swagger UI assets and application middleware versions, not only source repositories, to ensure the running application was rebuilt and redeployed. Attempt a safe validation by requesting the Swagger UI with remote URL/config parameters pointing to a controlled benign test endpoint and confirm that arbitrary external or internal destinations are blocked or ignored. Review application routing to ensure Swagger UI is not exposed publicly unless intended. Validate network egress controls by confirming that requests from the application cannot reach 127.0.0.1, RFC1918-only services, or 169.254.169.254 unless explicitly allowed.

Typical attack path

1. Identify an exposed Swagger UI or embedded Swagger UI instance on a web application.
2. Determine whether the instance accepts remote specification or configuration URL parameters.
3. Send a crafted request that points the UI to an attacker-controlled URL to confirm outbound request behavior.
4. Change the target URL to internal addresses, localhost services, or cloud metadata endpoints.
5. Observe returned content, errors, timing differences, or outbound callbacks to infer reachable internal resources.
6. Use discovered internal services or leaked metadata to support follow-on attacks such as credential theft, service enumeration, or lateral movement.

How to detect it

Review web server, reverse proxy, CDN/WAF, and application logs for requests to Swagger UI routes that include attacker-supplied remote specification or configuration parameters. Focus on query strings containing url=, configUrl=, validatorUrl=, oauth2RedirectUrl=, or encoded variants pointing to http://, https://, localhost, private IP ranges, link-local addresses, or cloud metadata endpoints. Correlate these inbound requests with outbound proxy, firewall, DNS, VPC flow, Kubernetes network policy, and cloud metadata access logs from the same application host or container. Look for outbound requests to unusual domains controlled by unknown parties, interactsh/burpcollaborator-style callback domains, 169.254.169.254, 127.0.0.1, 0.0.0.0, ::1, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Investigate any Swagger UI request followed by internal HTTP 200/30x/40x responses, connection refusals, or timeout patterns that suggest internal port scanning. On hosts and containers, review application logs for failed OpenAPI document loads, remote configuration fetch errors, or unexpected HTTP client activity initiated by the Swagger UI integration.

• /swagger-ui/?url=http://
• /swagger-ui/?url=https://
• /swagger-ui/index.html?url=http://
• /swagger-ui/index.html?url=https://
• /swagger/index.html?url=http://
• /swagger/index.html?url=https://
• /api-docs?url=http://
• /api-docs?url=https://
• configUrl=http://
• configUrl=https://
• validatorUrl=http://
• validatorUrl=https://
• oauth2RedirectUrl=http://
• url=http%3A%2F%2F
• url=https%3A%2F%2F
• configUrl=http%3A%2F%2F
• configUrl=https%3A%2F%2F
• 169.254.169.254
• metadata.google.internal
• metadata/instance
• latest/meta-data
• 127.0.0.1
• localhost
• 0.0.0.0
• [::1]
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.
• swagger-ui-bundle.js
• swagger-ui-standalone-preset.js

What your security team should do

• Inventory externally exposed Swagger UI, swagger-ui-dist, swagger-ui-react, and Swashbuckle.AspNetCore.SwaggerUI deployments across applications.
• Prioritize upgrades to swagger-ui, swagger-ui-dist, and swagger-ui-react 4.1.3 or later, and Swashbuckle.AspNetCore.SwaggerUI 6.3.0 or later.
• Restrict Swagger UI access in production using authentication, network access controls, or removal of the documentation route where feasible.
• Disable arbitrary remote spec/config loading or enforce strict allowlists for approved OpenAPI document locations.
• Add outbound network controls blocking application-initiated access to localhost, private IP ranges, link-local addresses, and cloud metadata services unless business-required.
• Review historical web access logs for suspicious Swagger UI requests containing remote URL/config parameters, especially those targeting internal IP ranges or metadata endpoints.
• Monitor DNS, proxy, and firewall logs for unusual outbound requests from application hosts shortly after requests to Swagger UI endpoints.