CVE-2026-58371: SeaweedFS Reflected XSS in JSON Callback – Cluster Information Disclosure

Technical summary

SeaweedFS's writeJson helper function (weed/server/common.go) performs unsafe reflection of the callback query parameter into HTTP response bodies served with Content-Type: application/javascript. The vulnerability affects all JSON endpoints utilizing this helper—including unauthenticated master endpoints (/dir/status, /dir/lookup, /cluster/status), volume server /status, and filer directory listing—which are bound to 0.0.0.0 by default. The response lacks X-Content-Type-Options: nosniff headers and CORS allow-listing. An attacker can load these endpoints via HTML script tags from a cross-origin context, causing the browser to execute the reflected callback string. MIME-sniffing behaviors in certain clients may further interpret the reflected content as HTML, expanding attack surface.

Business impact

An attacker can leverage this vulnerability to passively discover your SeaweedFS cluster architecture, including the number and location of volume servers, their gRPC ports, file object identifiers, and directory structure—information valuable for follow-up attacks or competitive reconnaissance. If SeaweedFS stores sensitive data, exposure of file identifiers and directory listings could aid in targeted data theft or unauthorized access attempts. The vulnerability requires user interaction (visiting a malicious web page) and only affects organizations where users with network visibility to SeaweedFS nodes browse untrusted websites, but the default-open network posture of SeaweedFS increases risk in environments with permissive network segmentation.

Affected systems

All SeaweedFS deployments version 4.29 and earlier are affected. The vulnerability is present by default because SeaweedFS typically listens on 0.0.0.0 without mandatory whiteList configuration or security.toml enforcement. Clusters with default network bindings are at highest risk. Deployments that have restricted network access via firewall rules or reverse-proxy whitelisting (e.g., only allowing internal IPs to reach SeaweedFS endpoints) face reduced risk from the cross-origin attack vector, though the underlying unsafe reflection persists.

Exploitability

Exploitation requires that a user with network access to the affected SeaweedFS instance visits a malicious third-party web page controlled by the attacker. The attacker's page can silently fetch cluster information via JSONP-style script tag injection. No authentication is required because the vulnerable endpoints (/dir/status, /dir/lookup, /cluster/status, /status) are unauthenticated by default. The CVSS score of 3.1 (LOW) reflects the requirement for user interaction and the confidentiality-only impact; however, the ease of crafting a proof-of-concept and the default-open posture warrant careful consideration in network-exposed environments.

Remediation

Upgrade SeaweedFS to version 4.30 or later, which addresses the unsafe callback reflection. In the interim, restrict network access to SeaweedFS endpoints via firewall rules, virtual private networks, or reverse proxies that enforce authentication and validate request origins. Additionally, configure SeaweedFS with a security.toml file and use the -whiteList flag to restrict which IP ranges can access administrative and status endpoints. Educate users not to visit untrusted websites from systems with network access to SeaweedFS, though this is not a reliable long-term control.

Patch guidance

Apply the upgrade to SeaweedFS 4.30 or later as soon as feasible. Review your release notes and deployment procedures to ensure the upgrade does not disrupt ongoing operations. Verify after patching that all JSON endpoints no longer reflect the callback parameter in response bodies and that responses include X-Content-Type-Options: nosniff headers. If you cannot upgrade immediately, implement network-level access controls to restrict who can reach SeaweedFS endpoints and validate that your security.toml and -whiteList configurations are in place and tested.

Detection guidance

Monitor HTTP access logs for requests to SeaweedFS JSON endpoints (/dir/status, /dir/lookup, /cluster/status, /status) that include a 'callback' parameter in the query string. Look for patterns where the callback value appears verbatim in the response body. Check for requests originating from unexpected external sources or user-agents consistent with automated reconnaissance. Review browser security logs and web proxy logs for cross-origin script requests to your SeaweedFS servers. Implement WAF or reverse-proxy rules to block or alert on requests with callback parameters to these endpoints.

Why prioritize this

Although this vulnerability carries a LOW CVSS score due to the user-interaction requirement and confidentiality-only impact, it should be prioritized for remediation in environments where SeaweedFS is network-exposed and cluster topology is sensitive. The attack is trivial to execute (a simple HTML page with script tags) and requires no authentication. If you have not restricted network access to SeaweedFS or have users browsing untrusted web content from systems that can reach your cluster, patch promptly. Organizations with strict network segmentation or internal-only SeaweedFS deployments can prioritize this as a lower-urgency update, though the underlying design flaw warrants correction.

Risk score, explained

The CVSS 3.1 score of 3.1 (LOW) is justified by the Unauthenticated network vector (AV:N), High attack complexity due to the user-interaction requirement (AC:H), and the restriction to Confidentiality impact (C:L, I:N, A:N). However, this score underweights the practical risk in default-open SeaweedFS deployments serving internal or shared infrastructure. Real-world risk depends heavily on network topology: clusters accessible only to trusted internal users or behind authentication layers face minimal risk, while internet-facing or lightly-segmented deployments face elevated risk. Treat the CVSS as a lower bound and adjust prioritization based on your network exposure and data sensitivity.

Frequently asked questions