GHSA-87FV-VQQR-M4JR

Vulnerability from github – Published: 2026-08-11 15:58 – Updated: 2026-08-11 15:58
VLAI
Summary
SeaweedFS: Unauthenticated SSRF with response read-back via VolumeServer.FetchAndWriteNeedle
Details

Impact

VolumeServer.FetchAndWriteNeedle fetches a caller-supplied remote endpoint and writes the response into a needle. Before 4.24 this RPC performed no authentication and no validation of the target, so anyone able to reach a volume server's gRPC port could coerce the server into issuing requests to arbitrary hosts — including loopback, link-local, RFC 1918, and cloud metadata endpoints such as 169.254.169.254 — and read the response back. On cloud deployments this discloses instance metadata and IAM credentials, and can be used to reach otherwise-unexposed internal services (SSRF with response read-back).

The volume server gRPC plane is unauthenticated on a default deployment, so no credentials are required. Configuring the documented JWT signing keys does not close it, because that hardening does not apply to this RPC.

Affected component

  • weed/server/volume_grpc_remote.go (FetchAndWriteNeedle)
  • weed/remote_storage/s3/s3_storage_client.go

Patches

Fixed in 4.24. FetchAndWriteNeedle now requires admin authorization and refuses loopback / link-local / RFC 1918 / IMDS destinations through a guarded dialer that resolves the host itself and pins the resolved address for the duration of the request, defeating DNS-rebinding. The Rust volume server carries the equivalent endpoint validation.

Workarounds

Restrict volume server gRPC ports to trusted hosts via firewall / network policy, and enable mTLS via security.toml.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/seaweedfs/seaweedfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260512171120-69da20bdaec9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-11T15:58:23Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n`VolumeServer.FetchAndWriteNeedle` fetches a caller-supplied remote endpoint and writes the response into a needle. Before 4.24 this RPC performed no authentication and no validation of the target, so anyone able to reach a volume server\u0027s gRPC port could coerce the server into issuing requests to arbitrary hosts \u2014 including loopback, link-local, RFC 1918, and cloud metadata endpoints such as `169.254.169.254` \u2014 and read the response back. On cloud deployments this discloses instance metadata and IAM credentials, and can be used to reach otherwise-unexposed internal services (SSRF with response read-back).\n\nThe volume server gRPC plane is unauthenticated on a default deployment, so no credentials are required. Configuring the documented JWT signing keys does not close it, because that hardening does not apply to this RPC.\n\n### Affected component\n- `weed/server/volume_grpc_remote.go` (`FetchAndWriteNeedle`)\n- `weed/remote_storage/s3/s3_storage_client.go`\n\n### Patches\nFixed in **4.24**. `FetchAndWriteNeedle` now requires admin authorization and refuses loopback / link-local / RFC 1918 / IMDS destinations through a guarded dialer that resolves the host itself and pins the resolved address for the duration of the request, defeating DNS-rebinding. The Rust volume server carries the equivalent endpoint validation.\n\n### Workarounds\nRestrict volume server gRPC ports to trusted hosts via firewall / network policy, and enable mTLS via `security.toml`.",
  "id": "GHSA-87fv-vqqr-m4jr",
  "modified": "2026-08-11T15:58:23Z",
  "published": "2026-08-11T15:58:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/security/advisories/GHSA-87fv-vqqr-m4jr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/pull/9441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/commit/69da20bdaec923e5a43d8aa71bf3c0a2051fc019"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/seaweedfs/seaweedfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/releases/tag/4.24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SeaweedFS: Unauthenticated SSRF with response read-back via VolumeServer.FetchAndWriteNeedle"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…