Skip to content

🐛 [Bounty] - Misconfiguration in Swagger UI Config #17

@aaboyle878

Description

@aaboyle878

Context

This report was received via our security email channel.

Summary:

A Resource Injection vulnerability exists in the Swagger UI implementation at:

https://administration.info.intersectmbo.org/docs/

The API definition input field (via the "Explore" functionality) allows loading arbitrary external Swagger/OpenAPI definitions, including malicious ones hosted on third-party domains.

This behavior enables attackers to render phishing interfaces directly inside trusted domain (administration.info.intersectmbo.org), which could be used to deceive users into submitting sensitive information (e.g., credentials).

Steps to Reproduce

1 - Open Swagger UI

Visit:

https://administration.info.intersectmbo.org/docs/

2 - Inject Malicious Swagger Definition (Fake Login Page)

In the Swagger UI input field, enter:

https://raw.githubusercontent.com/Rivek619/R-Payloads-101/refs/heads/main/SwaggerUI/rlogin1.yaml

Click "Explore"

3 - Observe Result

A fake login page is rendered inside Swagger UI

Contains:

  • Username field

  • Password field

  • Social engineering content

4 - Phishing Variant

Input:

https://raw.githubusercontent.com/Rivek619/R-Payloads-101/refs/heads/main/SwaggerUI/ylogin.yaml

Click Explore

5 - Observe Result

A phishing message appears:

Login to continue services below or go to https://evil.com/

Includes attacker-controlled external link

Actual behavior

Proof of Concept: (Also see attached screenshots)

The Swagger UI dynamically renders content from attacker-controlled YAML files, allowing:

  • Injection of arbitrary HTML-like UI elements

  • Rendering of phishing forms

  • Redirection links to malicious domains

Root Cause:

  • Swagger UI allows unrestricted loading of external API definitions

  • No validation or allowlist is enforced on the url input

  • External YAML/JSON files are trusted and rendered directly inside DOM

Security Analysis

This is a Client-Side Injection / UI Redressing issue, not traditional XSS.

However, it is still impactful because:

Impact:

  • Phishing via trusted domain (administration.info.intersectmbo.org)

  • User credential harvesting risk

  • Trust abuse (UI redressing / spoofed interfaces)

  • Potential brand damage and user compromise

Although no direct XSS was achieved, the ability to load an attacker-controlled UI inside Swagger significantly increases phishing risk.

Attempted Exploitation (Not Successful)

  • Tried DOM XSS via:

https://administration.info.intersectmbo.org/docs/?ConfigUrl=https://jumpy-floor.surge.sh/test.json

No JavaScript execution observed

  • Also no direct URL Exploitation :-

https://administration.info.intersectmbo.org/docs/?ConfigUrl=https://raw.githubusercontent.com/Rivek619/R-Payloads-101/refs/heads/main/SwaggerUI/ylogin.yaml

Only current attack is :-

Inject Malicious Swagger Definition (Fake Login Page)

In the Swagger UI input field, enter:

https://raw.githubusercontent.com/Rivek619/R-Payloads-101/refs/heads/main/SwaggerUI/rlogin1.yaml

Click "Explore"

But this doesn't mean no impact because the Swagger UI implementation allows attacker-controlled resource injection, enabling phishing content to be rendered within a trusted administration.info.intersectmbo.org domain

Expected behavior

Recommended Fix:

Option 1: Disable External URL Loading

Remove or restrict the "Explore" input functionality in production

Option 2: Allowlist Trusted Sources

Only allow API definitions from:

  • Internal domains

  • Trusted endpoints

Option 3: Content Validation

  • Sanitize and validate Swagger definitions before rendering

Option 4: Security Warning / Isolation

  • Render external definitions in a sandboxed iframe

  • Display clear warnings when loading external sources

Severity Assessment

Suggested Severity: Medium

Reasoning:

  • No direct XSS or account takeover

  • But enables realistic phishing inside trusted domain

  • may lead to credential theft in real-world scenarios

Conclusion:

The Swagger UI implementation allows attacker-controlled resource injection, enabling phishing content to be rendered within a trusted administration.info.intersectmbo.org domain.

This significantly increases the risk of social engineering attacks against users, even without traditional script execution.

Disclosure Compliance:

  • No data was accessed or modified

  • No exploitation beyond proof-of-concept rendering

  • All testing adhered to responsible disclosure policy

Image Image

Security Control Comparison

While Swagger UI supports external definition loading by design, secure production deployments (e.g., CloudBees) enforce CORS restrictions and Content Security Policy (CSP) to prevent loading untrusted external resources.

The affected Intersectmbo endpoints lack these protections, allowing arbitrary third-party definitions to be rendered — significantly increasing phishing risk.

During testing, I compared the behavior with other production Swagger UI deployments:

https://subscriptionservices.cloudbees.com/docs/

https://uds.cloudbees.com/docs/

When attempting to load the same malicious Swagger definition:

https://raw.githubusercontent.com/.../ylogin.yaml
The request was blocked due to security controls, including:

CORS enforcement

Content Security Policy (CSP):

default-src 'self'
connect-src restricted

Result:

External resource loading is prevented

Malicious Swagger definitions cannot be rendered

Security Gap

In contrast, Intersectmbo Swagger UI:

Allows unrestricted external resource loading

Does not enforce CSP restrictions

Does not block cross-origin Swagger definitions

This demonstrates a clear security control gap, increasing exposure to phishing attacks.

Image Image

References:

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions