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:
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)
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
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
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.
References:
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:
Content is rendered under: https://administration.info.intersectmbo.org/docs/
Users may trust the domain and interact with malicious UI
This is effectively a self-service phishing framework inside application
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)
https://administration.info.intersectmbo.org/docs/?ConfigUrl=https://jumpy-floor.surge.sh/test.json
No JavaScript execution observed
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
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
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.
References: