CVE-2026-10240
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 |
|---|---|---|
| jeecg | jeecgboot | to 3.9.2 (inc) |
| jeecgboot | jeecgboot | to 3.9.2 (exc) |
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?
This vulnerability is a Server-Side Request Forgery (SSRF) found in JeecgBoot versions up to 3.9.2, specifically in the `/airag/airagModel/test` endpoint.
An authenticated attacker can manipulate the `baseUrl` argument in a request, which the application forwards without validation or sanitization to the langchain4j framework.
This allows the attacker to make the server send requests to internal network services or sensitive cloud metadata endpoints, such as AWS or GCP metadata services.
The vulnerability exists because the malicious `baseUrl` is stored in the database and the endpoint lacks proper permission restrictions, enabling any authenticated user to exploit it.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows authenticated attackers to perform server-side request forgery (SSRF), potentially accessing internal network services and sensitive cloud metadata. Such unauthorized access to internal or sensitive data could lead to violations of data protection regulations like GDPR or HIPAA, which mandate strict controls over personal and sensitive information.
Since the vulnerability enables attackers to probe internal services and access sensitive metadata without proper validation or permission restrictions, it increases the risk of data breaches or unauthorized data exposure, which are critical compliance concerns under these regulations.
Therefore, until the planned fix is applied, organizations using affected versions of JeecgBoot may face challenges in maintaining compliance with standards requiring strong access controls and data protection.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to probe internal network services and perform port scanning from the vulnerable server.
Attackers can also access sensitive cloud metadata endpoints, potentially exposing confidential information such as credentials or configuration data.
Since the exploit requires only authenticated access and the endpoint lacks proper permission restrictions, it increases the risk of insider threats or compromised accounts being used to exploit the system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crafted POST requests to the `/airag/airagModel/test` endpoint that include a malicious `baseUrl` parameter in the request body. Such requests may attempt to access internal network services or cloud metadata endpoints.
To detect exploitation attempts, you can search your web server logs or use network monitoring tools to identify POST requests to `/airag/airagModel/test` with suspicious `baseUrl` values.
- Example command to search web server logs for suspicious requests (assuming Apache logs): `grep '/airag/airagModel/test' /var/log/apache2/access.log | grep POST`
- Use a network monitoring tool like tcpdump or Wireshark to filter HTTP POST requests to the vulnerable endpoint: `tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep '/airag/airagModel/test'`
- If you have access to the application database, check for stored `baseUrl` values that point to internal or cloud metadata IP addresses (e.g., 169.254.169.254 for AWS).
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the `/airag/airagModel/test` endpoint to only trusted and authorized users, as the vulnerability requires authentication but lacks proper permission restrictions.
Additionally, monitor and block suspicious requests that contain malicious `baseUrl` parameters targeting internal or cloud metadata services.
If possible, temporarily disable or restrict the vulnerable endpoint until a patch or fix is released.
Apply input validation and sanitization on the `baseUrl` parameter to prevent SSRF attacks once you can update the application.