CVE-2026-7084
Server-Side Request Forgery in Toonflow-app getCodeByLink Endpoint
Publication date: 2026-04-27
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| hba-ltd | toonflow | to 1.1.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-7084 is a Server-Side Request Forgery (SSRF) vulnerability in the Toonflow-app version 1.1.1, specifically in the /api/setting/vendorConfig/getCodeByLink endpoint. This endpoint accepts a 'link' parameter that is only validated as a string without any restrictions on URL format, protocol, hostname, or IP address range.
The server uses Node.js's fetch() function to retrieve content from the provided URL and returns the full HTTP response body to the requester. Because of the lack of proper validation, an attacker can supply arbitrary URLs, including internal IP addresses or private ranges, causing the server to perform HTTP requests on their behalf.
This allows attackers to access internal services not normally exposed externally, read cloud instance metadata endpoints to obtain sensitive credentials, and chain attacks to exfiltrate administrator plaintext passwords. The root cause is the absence of strict URL validation and unrestricted use of fetch() on attacker-controlled URLs.
How can this vulnerability impact me? :
This vulnerability can have severe impacts including unauthorized access to internal network services and sensitive data. An attacker can use it to bypass network restrictions and perform port scanning or network boundary bypass.
In cloud environments, attackers can access metadata services to obtain IAM credentials, leading to potential full system compromise.
Additionally, by chaining this SSRF with internal APIs, attackers can retrieve administrator plaintext passwords, enabling further unauthorized access and control over the system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing the `/api/setting/vendorConfig/getCodeByLink` endpoint for Server-Side Request Forgery (SSRF) by sending crafted requests with the `link` parameter pointing to internal or sensitive URLs.
A typical detection approach involves obtaining a valid JWT token (default credentials: admin/admin123), then sending a POST request to the vulnerable endpoint with the `link` parameter set to an internal service URL such as `http://127.0.0.1:10588/api/login/login`.
If the server returns the response body from the internal URL, SSRF is confirmed.
Example commands using curl:
- 1. Obtain JWT token (example using default credentials): ```bash curl -X POST https://<target>/api/login -d '{"username":"admin","password":"admin123"}' -H 'Content-Type: application/json' ``` Extract the token from the response.
- 2. Test SSRF by sending a POST request with the token: ```bash curl -X POST https://<target>/api/setting/vendorConfig/getCodeByLink \ -H 'Authorization: Bearer <JWT_TOKEN>' \ -H 'Content-Type: application/json' \ -d '{"link":"http://127.0.0.1:10588/api/login/login"}' ```
If the response contains data from the internal service, the vulnerability is present.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Strictly validate the `link` parameter as a proper URL using URL validation methods (e.g., `z.string().url()` in the code).
- Restrict allowed protocols to HTTPS only to prevent requests to insecure or internal services.
- Block requests to private, loopback, link-local, and cloud metadata IP ranges and hostnames by implementing regex patterns and DNS resolution checks to prevent DNS rebinding attacks.
- Implement a domain allowlist to restrict URLs to known and trusted vendor domains.
- Modify internal APIs such as `/api/setting/loginConfig/getUser` to exclude sensitive information like plaintext passwords.
- Hash stored passwords using strong algorithms like bcrypt or argon2 to prevent plaintext password exposure.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows attackers to bypass network restrictions and access internal services, including exfiltrating sensitive credentials such as administrator plaintext passwords. This exposure of sensitive data can lead to unauthorized access and full system compromise.
Such unauthorized access and data exposure could negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive personal and organizational data. The ability to access internal services and credentials may result in breaches of confidentiality and data integrity obligations mandated by these regulations.
However, the provided information does not explicitly mention compliance impacts or specific regulatory considerations.