CVE-2026-7605: JeecgBoot SSRF Vulnerability

CVE-2026-7605 Overview

CVE-2026-7605 is a Server-Side Request Forgery (SSRF) vulnerability affecting JeecgBoot versions up to 3.9.1. The flaw resides in the CommonController.uploadImgByHttp method and the related HttpFileToMultipartFileUtil.httpFileToMultipartFile and HttpFileToMultipartFileUtil.downloadImageData functions inside CommonController.java. The vulnerable endpoint, uploadImgByHttp, accepts attacker-controlled URL input and fetches remote resources without sufficient validation. An authenticated remote attacker can manipulate this input to coerce the server into issuing arbitrary HTTP requests. Public exploit code has been released, and the vendor has confirmed the issue and committed to a fix in an upcoming release. The weakness is classified under CWE-918: Server-Side Request Forgery.

Critical Impact

Authenticated remote attackers can abuse the JeecgBoot image upload endpoint to make the server perform requests to internal or external hosts, exposing internal services and metadata endpoints.

Affected Products

• JeecgBoot versions up to and including 3.9.1
• The uploadImgByHttp endpoint exposed by CommonController.java
• HttpFileToMultipartFileUtil helper functions used for HTTP-based file retrieval

Discovery Timeline

• 2026-05-02 - CVE-2026-7605 published to NVD
• 2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-7605

Vulnerability Analysis

The vulnerability stems from JeecgBoot's image upload-by-URL feature. The uploadImgByHttp action takes a remote URL parameter and passes it through HttpFileToMultipartFileUtil.httpFileToMultipartFile, which in turn invokes downloadImageData to fetch the resource. The implementation does not enforce an allow-list of destinations, validate the URL scheme, or restrict requests to internal address ranges. As a result, the server acts as a proxy on behalf of the attacker.

An attacker can supply URLs targeting 127.0.0.1, RFC1918 ranges, link-local addresses such as 169.254.169.254, or internal service hostnames. The server processes these requests with its own network identity, bypassing perimeter controls. Public exploit details have been published through the project's GitHub issue tracker and VulDB.

Root Cause

The root cause is missing validation of user-supplied URLs before initiating an outbound HTTP request. The download routine trusts the input string and follows it, including potential redirects, without checking the destination host or protocol. This pattern is the canonical CWE-918 condition.

Attack Vector

The attack is performed remotely over the network and requires low privileges to reach the authenticated endpoint. An attacker submits a crafted request to the uploadImgByHttp route with a URL pointing at an internal target. The application returns the fetched content or behavioral side effects, allowing the attacker to map internal services, query cloud metadata APIs, or interact with non-public HTTP interfaces. See the GitHub issue tracking this flaw for technical specifics.

No verified proof-of-concept code is reproduced here. Refer to the VulDB entry #360562 and the project repository for additional technical details.

Detection Methods for CVE-2026-7605

Indicators of Compromise

• HTTP requests to the uploadImgByHttp endpoint containing URL parameters that reference internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or link-local addresses such as 169.254.169.254.
• Outbound connections originating from the JeecgBoot application server to cloud metadata endpoints or internal management interfaces shortly after upload-by-URL requests.
• Repeated uploadImgByHttp calls from a single authenticated session enumerating sequential hosts or ports.

Detection Strategies

• Inspect web server and application logs for POST or GET requests targeting the uploadImgByHttp route and parse the URL parameter for non-public destinations.
• Correlate authenticated user session activity with subsequent egress traffic from the JeecgBoot host to identify proxied requests.
• Apply Web Application Firewall (WAF) rules that block requests where the URL parameter resolves to private, loopback, or reserved address space.

Monitoring Recommendations

• Baseline normal outbound destinations for the JeecgBoot service account and alert on deviations such as connections to metadata IPs or unusual internal hosts.
• Forward application and network telemetry into a central analytics platform to enable cross-source correlation between request parameters and egress flows.
• Track and alert on HTTP 4xx/5xx response patterns from the upload endpoint that may indicate scanning or enumeration attempts.

How to Mitigate CVE-2026-7605

Immediate Actions Required

• Restrict access to the uploadImgByHttp endpoint at the reverse proxy or API gateway to trusted users and networks until a patched release is available.
• Implement egress filtering on the JeecgBoot host to deny outbound traffic to RFC1918, loopback, and cloud metadata addresses.
• Audit existing logs for prior exploitation attempts referencing internal IP ranges in the URL parameter.
• Rotate any credentials retrievable from instance metadata services if the application runs in a cloud environment.

Patch Information

The vendor has confirmed the issue and stated a fix will ship in an upcoming JeecgBoot release. Track the project GitHub repository and issue #9555 for the patched version. Upgrade to the fixed release as soon as it becomes available.

Workarounds

• Disable or remove the uploadImgByHttp route if the upload-by-URL feature is not required by the deployment.
• Add a server-side allow-list of approved external image hosts and reject all other URLs before invoking HttpFileToMultipartFileUtil.
• Validate URL schemes to permit only http and https, and resolve hostnames before fetching to block private and reserved IP destinations.
• Place the application behind a network proxy that enforces destination policies for outbound HTTP requests.

# Example egress restriction using iptables to block SSRF targets
iptables -A OUTPUT -m owner --uid-owner jeecg -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner jeecg -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner jeecg -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner jeecg -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner jeecg -d 169.254.0.0/16 -j REJECT