JSONP Callback Reflection in SeaweedFS

Executive Summary

CVE-2026-58371 is a vulnerability in SeaweedFS versions before 4.30 where the system reflects the callback query parameter directly into JSONP responses without validation. This occurs in the shared writeJson helper function, which serves responses with Content-Type application/javascript but does not validate the callback name, lacks the X-Content-Type-Options: nosniff header, and has no CORS allow-list.

Because of this, unauthenticated endpoints such as /dir/status, /dir/lookup, /cluster/status, /status, and filer directory listings can be accessed cross-origin via a script tag with a chosen callback. This allows a third-party web page to read sensitive information like cluster topology, volume server URLs, gRPC ports, file identifiers, and directory listings. Additionally, the missing nosniff header means MIME-sniffing clients might interpret the response as HTML, increasing exploitation risk.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to cross-origin information disclosure, allowing attackers to access sensitive internal details of the SeaweedFS cluster without authentication. Attackers can retrieve cluster topology, volume server URLs, gRPC ports, file identifiers, and directory listings by exploiting the unvalidated JSONP callback parameter.

Such exposure can facilitate further attacks, including data exfiltration or cross-site scripting (XSS) attacks, by injecting arbitrary JavaScript through the callback parameter. The lack of security headers and CORS restrictions increases the risk of these attacks succeeding.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if your SeaweedFS deployment is running a version prior to 4.30 and if the JSONP callback parameter is reflected in responses from certain unauthenticated endpoints.

You can test the vulnerable endpoints such as /dir/status, /dir/lookup, /cluster/status, /status, and filer directory listings by sending HTTP requests with a callback query parameter and observing if the callback value is reflected verbatim in the response served with Content-Type application/javascript.

For example, you can use curl commands like the following to detect the vulnerability:

• curl -i 'http://<seaweedfs-host>:<port>/dir/status?callback=alert'
• curl -i 'http://<seaweedfs-host>:<port>/dir/lookup?callback=alert'
• curl -i 'http://<seaweedfs-host>:<port>/cluster/status?callback=alert'
• curl -i 'http://<seaweedfs-host>:<port>/status?callback=alert'
• curl -i 'http://<seaweedfs-host>:<port>/filer/directory/listing?callback=alert'

If the response body starts with the callback parameter value (e.g., alert) and the Content-Type is application/javascript without the X-Content-Type-Options: nosniff header, your system is likely vulnerable.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade SeaweedFS to version 4.30 or later, where the vulnerability has been fixed by removing JSONP support and adding the X-Content-Type-Options: nosniff header.

If upgrading immediately is not possible, you should restrict access to the vulnerable endpoints by implementing network-level controls such as firewall rules or IP whitelisting to prevent untrusted cross-origin requests.

Additionally, configuring SeaweedFS with a security.toml file or using the -whiteList option to limit accessible hosts can reduce exposure.

Monitoring and blocking suspicious cross-origin script tag requests targeting the affected endpoints can also help mitigate exploitation.

Useful 0 Not Useful 0