SeaweedFS Helm Chart EUVD-2026-101519

Not a default-configuration flaw. ALL of the following must hold simultaneously in a standalone deployment: sftp.enabled=true AND sftp.enableAuth=true; sftp.existingConfigSecret (existingSshConfigSecret) NOT supplied; the legacy sftp.sshPrivateKey code path still selected; a valid config-ssh Secret present to allow startup; and hostKeysFolder NOT providing a later/overriding Ed25519 signer - only then is the bundled hard-coded key presented. Critically, default all-in-one deployments and non-authenticated standalone paths never load the key and are not affected. Beyond configuration, exploitation requires the attacker to hold a traffic redirect/interception (MITM) position AND requires the victim client to actively connect and trust the chart's published host identity. These network-position and user-interaction requirements, plus the non-default config chain, sharply limit realistic exploitation.

This is a genuine but conditional, lower-priority issue despite its 7.0 'High' CVSS 4.0 rating. The root flaw (CWE-321) is real and public: the SFTP Helm chart shipped one unencrypted Ed25519 private host key in sftp-secret.yaml from 4.0.388 to 4.41, so the corresponding private key is known to anyone who reads the chart, and the attack is server-impersonation rather than direct compromise. However, several signals point to limited real-world risk. The CVSS 4.0 vector itself is self-limiting - AC:H and AT:P (a specific attack requirement), plus UI:A (active user interaction), mean exploitation is not trivially automatable and depends on the victim client connecting. No EPSS score, KEV listing, or POC is present in the input, so this is no public exploit identified at time of analysis and there is no evidence of active exploitation. The effective priority is further reduced because exploitation requires the attacker to already hold a network man-in-the-middle position AND the target must run a narrow, non-default configuration chain (see exploitation_conditions); default all-in-one and non-authenticated standalone paths never loaded the vulnerable key. Note a nuance: the vector sets PR:N (attacker needs no privileges on the server), which is correct for an impersonation attack, but the real gating factor is the MITM prerequisite and the UI requirement, not privileges - raw CVSS understates how much the MITM positioning constrains exploitation.

An attacker extracts the hard-coded Ed25519 private host key from the public SeaweedFS Helm chart (versions 4.0.388-4.40) and positions themselves to intercept or redirect SFTP client traffic, e.g. via ARP/DNS spoofing or a compromised network path. When a client that pinned/trusted the chart's published host identity connects, the rogue endpoint presents the matching host key, the client accepts it, and the attacker captures submitted password credentials and any uploaded/downloaded data. No public exploit is identified at time of analysis, but the private key material is trivially recoverable from the chart source.