CVE-2026-8320: jshERP SSRF Vulnerability

CVE-2026-8320 Overview

CVE-2026-8320 is a Server-Side Request Forgery (SSRF) vulnerability affecting jishenghua jshERP through version 3.6. The flaw resides in the getUserByWeixinCode function located in jshERP-boot/src/main/java/com/jsh/erp/service/UserService.java, reachable through the updatePlatformConfigByKey endpoint. Attackers manipulate the weixinUrl argument to coerce the server into issuing arbitrary outbound HTTP requests. The issue is classified under CWE-918: Server-Side Request Forgery.

Critical Impact

Authenticated remote attackers can leverage the jshERP server to reach internal services, scan internal networks, or interact with cloud metadata endpoints. The exploit has been publicly disclosed, and the project has not yet responded to the issue report.

Affected Products

• jishenghua jshERP versions up to and including 3.6
• UserService.java component handling WeChat (weixin) integration
• updatePlatformConfigByKey API endpoint accepting the weixinUrl parameter

Discovery Timeline

• 2026-05-11 - CVE-2026-8320 published to NVD
• 2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-8320

Vulnerability Analysis

The vulnerability stems from unsafe handling of a user-controlled URL inside the WeChat authentication flow. The getUserByWeixinCode function consumes the weixinUrl argument and uses it to perform a server-side HTTP request without validating the destination. Because the destination is fully attacker-controlled, the jshERP backend acts as a proxy on behalf of the requester.

SSRF in this position is particularly impactful for enterprise resource planning deployments. The jshERP server typically runs inside corporate networks with access to internal databases, administrative interfaces, and cloud provider metadata services. An attacker can pivot through the server to reach systems that are not directly exposed to the internet.

The issue requires authentication, which limits opportunistic exploitation. However, low-privilege accounts are sufficient to reach the endpoint, and the public exploit disclosure increases the likelihood of weaponization against unpatched deployments.

Root Cause

The root cause is missing validation of the weixinUrl parameter inside UserService.java. The function trusts caller-supplied input and forwards it directly to an HTTP client. There is no allowlist of permitted hosts, no scheme restriction, and no filtering of internal IP ranges such as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or cloud metadata addresses like 169.254.169.254.

Attack Vector

An authenticated attacker sends a crafted request to the updatePlatformConfigByKey endpoint, setting weixinUrl to a target of their choice. The jshERP server then issues a request to that destination, returning response data or exposing internal connectivity through timing and error differentials. The attack is fully remote and requires no user interaction. Technical details are available in GitHub Issue #152 on jshERP and VulDB Vulnerability #362607.

No verified proof-of-concept code is reproduced here. Refer to the upstream issue tracker for technical details on the request flow.

Detection Methods for CVE-2026-8320

Indicators of Compromise

• Outbound HTTP requests from jshERP application servers to internal RFC1918 addresses or 169.254.169.254 cloud metadata endpoints
• POST or GET requests to updatePlatformConfigByKey containing weixinUrl parameters pointing to non-WeChat domains
• Unexpected HTTP client traffic originating from the Java process hosting jshERP

Detection Strategies

• Inspect web access logs for requests targeting updatePlatformConfigByKey and capture the weixinUrl value for review against an allowlist of legitimate WeChat API hosts
• Correlate jshERP application logs with egress firewall logs to identify backend HTTP requests to internal subnets or cloud metadata services
• Deploy network detection rules that alert on jshERP host connections to non-WeChat domains during platform configuration updates

Monitoring Recommendations

• Forward jshERP application and access logs to a centralized SIEM and retain them for at least 90 days for retrospective hunts
• Monitor outbound connection patterns from ERP servers and baseline normal destinations to surface anomalies
• Alert on authentication events for accounts that subsequently call the updatePlatformConfigByKey endpoint with unusual parameters

How to Mitigate CVE-2026-8320

Immediate Actions Required

• Restrict network egress from jshERP servers using a host-based or perimeter firewall, blocking access to internal subnets and cloud metadata endpoints
• Limit access to the updatePlatformConfigByKey endpoint to administrative users only through reverse proxy access controls
• Audit existing accounts and rotate credentials for any user that should not have configuration update privileges

Patch Information

No official patch is available at the time of publication. According to the disclosure, the project was informed through an issue report but has not yet responded. Monitor the jshERP GitHub repository and GitHub Issue #152 for upstream fixes.

Workarounds

• Deploy a web application firewall rule that rejects requests to updatePlatformConfigByKey containing weixinUrl values pointing to private IP ranges, localhost, or non-HTTPS schemes
• Place the jshERP server inside a network segment with strict egress filtering that permits only the official WeChat API endpoints
• Disable or remove the WeChat integration feature if it is not used in your deployment

# Example egress restriction using iptables to block SSRF targets
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP