HIGH 7.3

CVE-2026-11437: Server-Side Request Forgery in go-fastdfs-web 1.3.7 and Earlier

A vulnerability in go-fastdfs-web versions up to 1.3.7 allows attackers to make the affected server fetch or interact with arbitrary external resources without authorization. An unauthenticated attacker can manipulate a parameter in the installation endpoint's server check function to trigger server-side requests to unintended destinations. This is particularly dangerous because the server performs actions on behalf of the attacker, potentially accessing internal systems, exfiltrating data, or pivoting to other infrastructure that trusts the vulnerable server.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.3 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Weaknesses (CWE)
CWE-918
Affected products
0 configuration(s)
Published / Modified
2026-06-06 / 2026-06-17

NVD description (verbatim)

A flaw has been found in perfree go-fastdfs-web up to 1.3.7. Affected is the function checkServer of the file /install/checkServer of the component Installation Endpoint. Executing a manipulation can lead to server-side request forgery. The attack can be executed remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-11437 is a server-side request forgery (SSRF) vulnerability in the checkServer function of go-fastdfs-web's /install/checkServer endpoint. The flaw exists in the installation component and can be exploited without authentication or user interaction. The vulnerability allows remote manipulation of server requests, enabling attackers to access internal resources, scan private networks, or trigger unauthorized actions on behalf of the server. The issue affects all versions up to and including 1.3.7.

Business impact

Organizations running vulnerable go-fastdfs-web instances face significant risk of unauthorized data access and internal network reconnaissance. An attacker exploiting this flaw can probe internal infrastructure, access metadata services, or contact backend systems without legitimate authorization. If go-fastdfs-web is positioned in front of sensitive data stores or connected to internal APIs, the impact escalates to potential confidentiality and integrity breaches. The lack of vendor responsiveness compounds the risk by eliminating the possibility of coordinated disclosure benefits.

Affected systems

go-fastdfs-web versions 1.3.7 and earlier are affected. Any deployment with the installation endpoint exposed or accessible during setup is at risk. This includes fresh installations, test environments left online, and systems where the /install path was not properly restricted or removed after deployment.

Exploitability

The vulnerability is highly exploitable due to the absence of authentication requirements and the low attack complexity. Exploitation requires only network access to the installation endpoint; no user interaction is needed. A published exploit exists, making this a practical threat. The attack surface includes any network that can reach the vulnerable web service, including the public internet if the installation endpoint is exposed.

Remediation

Upgrade go-fastdfs-web to a version that addresses this vulnerability—verify the latest release against the vendor's repository. If an immediate patch is unavailable, restrict network access to the /install path using a firewall, reverse proxy, or access control list to limit exposure to trusted administrative networks only. Consider removing or disabling the installation endpoint entirely in production environments where setup is already complete. Monitor for exploitation attempts targeting the checkServer function.

Patch guidance

Check the perfree go-fastdfs-web project repository for patch releases published after June 2026. Apply the highest available version that addresses SSRF protections in the checkServer function. Verify patch deployment by confirming the new version number in application metadata and validating that server check requests no longer allow arbitrary destination manipulation. If no official patch is available from the vendor, maintain the access restrictions described in the remediation section until one is released.

Detection guidance

Monitor HTTP access logs for requests to /install/checkServer with suspicious parameter values, particularly those containing internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), localhost addresses, or cloud metadata endpoints (169.254.169.254). Watch for patterns where the checkServer endpoint receives multiple requests with varying destination parameters in a short timeframe, suggesting reconnaissance activity. Network-based detection should flag outbound connections initiated from the vulnerable server to unusual or internal destinations following installation endpoint access.

Why prioritize this

Despite not being on the CISA KEV list, this vulnerability warrants immediate attention due to its CVSS 7.3 HIGH severity, the existence of a published working exploit, and confirmed vendor unresponsiveness. SSRF vulnerabilities are frequently the first step in supply chain attacks and internal network compromise. The presence of an active exploit and the lack of vendor support mean patches may not arrive, making proactive access restriction and monitoring critical.

Risk score, explained

The CVSS 3.1 score of 7.3 reflects high severity: network-accessible entry point (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), no user interaction needed (UI:N), impact to confidentiality (C:L), integrity (I:L), and availability (A:L) within the affected scope. The score does not discount the published exploit status or vendor non-responsiveness; organizations should treat this as higher risk operationally than the numeric score alone suggests.

Frequently asked questions

What is a server-side request forgery (SSRF) and why is it dangerous?

SSRF is a vulnerability where an attacker tricks a server into making requests on their behalf to resources the attacker cannot directly reach. This is dangerous because it bypasses network boundaries and can be used to access internal APIs, cloud metadata services, backend databases, or other infrastructure that trusts the vulnerable server. In this case, an attacker can force the go-fastdfs-web server to probe your internal network or contact services that should only be accessible internally.

Does this vulnerability require the installation endpoint to be publicly exposed?

No. Any network segment that can reach the vulnerable server poses a risk. This includes internal networks, if go-fastdfs-web is deployed there. The most critical scenario is when the installation endpoint remains accessible after initial setup, but even temporary exposure during deployment can enable attackers to establish footholds or gather intelligence.

Is there a workaround if I cannot patch immediately?

Yes. Restrict network access to the /install path using your firewall, reverse proxy, or web server configuration to allow only trusted administrative IPs or networks. Remove or rename the installation endpoint entirely if your deployment is complete and no further setup is planned. Monitor access logs aggressively for attempts to exploit the checkServer function. These controls reduce exploitability while you await or seek an updated version.

The vendor did not respond—does that mean no patch will ever exist?

Vendor non-responsiveness does not guarantee permanent unpatched status, but it is a warning sign. Monitor the go-fastdfs-web project repository and release notes regularly for patches addressing this issue. In the interim, treat access control and network segmentation as your primary defense. Consider evaluating alternative fastdfs implementations or products if the lack of vendor engagement becomes a blockers to your risk tolerance.

This analysis is provided for informational purposes based on available vulnerability data as of the publication date. The vendor has not responded to disclosure attempts, and no official patch status has been confirmed. Organizations should verify patch availability and compatibility with their specific deployments before applying updates. The existence of a published exploit increases operational risk; prioritize remediation accordingly. SEC.co does not confirm the accuracy of third-party exploit code and recommends defensive measures regardless of patch status. Source: NVD (public-domain), retrieved 2026-07-14. Analysis generated by SEC.co (claude-haiku-4-5).