CVE-2026-10241
Server-Side Request Forgery in Jeecgboot
Publication date: 2026-06-01
Last updated on: 2026-06-01
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| jeecgboot | jeecgboot | to 3.9.1 (inc) |
| jeecgboot | jeecgboot | 3.9.2 |
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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability is a Server-Side Request Forgery (SSRF) that allows authenticated attackers to make unauthorized requests to internal services or cloud metadata endpoints. This could potentially lead to unauthorized access to sensitive internal resources or data.
Such unauthorized access risks could impact compliance with standards and regulations like GDPR or HIPAA, which require protection of personal and sensitive data from unauthorized access or disclosure.
However, the provided information does not explicitly state the direct impact on compliance with these regulations.
Can you explain this vulnerability to me?
This vulnerability is a Server-Side Request Forgery (SSRF) flaw found in JeecgBoot versions up to 3.9.1, specifically in the /airag/app/debug endpoint.
An authenticated attacker can send a specially crafted POST request containing a files parameter with arbitrary URLs. The server processes these URLs using the FileDownloadUtils.download2DiskFromNet function without properly validating the host or IP address.
As a result, the attacker can force the server to make outbound HTTP requests to internal services, local ports, or cloud metadata endpoints, potentially accessing sensitive internal resources.
The vulnerability bypasses extension whitelists by appending allowed file extensions (like .pdf) to the URL path. This issue is fixed in JeecgBoot version 3.9.2.
How can this vulnerability impact me? :
This SSRF vulnerability can allow an attacker with authentication to make the server send unauthorized requests to internal or external systems.
Such unauthorized requests can lead to exposure of sensitive internal services, access to cloud metadata endpoints, or interaction with local network resources that are normally protected.
This can result in information disclosure, unauthorized data access, or further exploitation of internal systems behind firewalls.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for suspicious POST requests to the /airag/app/debug endpoint containing a JSON body with a files parameter that includes URLs targeting internal or cloud metadata endpoints.
Specifically, look for POST requests where the files array contains URLs pointing to internal IP addresses (e.g., 169.254.169.254) or other internal services.
Example command to detect such requests in web server logs (assuming logs contain request method, URL, and body):
- grep -i 'POST /airag/app/debug' /var/log/nginx/access.log | grep 'files'
To detect outgoing requests made by the server to internal or suspicious URLs, you can monitor network traffic with tools like tcpdump or Wireshark filtering for HTTP requests to internal IP ranges.
- sudo tcpdump -i any tcp port 80 or port 443 and host 169.254.169.254
Additionally, reviewing application logs for calls to FileDownloadUtils.download2DiskFromNet or AiragChatServiceImpl with suspicious URLs may help identify exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended mitigation is to upgrade JeecgBoot to version 3.9.2 or later, where the vulnerability has been fixed by implementing input validation to reject loopback and link-local addresses.
Until the upgrade can be performed, restrict access to the /airag/app/debug endpoint to trusted authenticated users only, as the attack requires authentication.
Additionally, consider implementing network-level controls to block outbound HTTP requests from the server to internal IP ranges such as 169.254.169.254 to prevent SSRF exploitation.