CVE-2026-100413 in SeaweedFS
Summary
by MITRE • 10/14/2026
SeaweedFS is a distributed storage system for files and blobs. From 4.0.388 until 4.41, the SFTP Helm chart embedded one unencrypted Ed25519 private host key in k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml as stringData.seaweedfs_sftp_ssh_private_key. A standalone deployment presented that public key when sftp.enabled and sftp.enableAuth were true, sftp.existingConfigSecret was not supplied, the legacy sftp.sshPrivateKey path remained selected, a valid config-ssh Secret allowed startup, and hostKeysFolder did not provide a later Ed25519 signer. An attacker able to redirect or intercept client traffic could impersonate that SFTP endpoint to clients that trusted the published host identity, exposing password credentials or data sent to the rogue endpoint. Default all-in-one and non-authenticated standalone paths did not load the key. This issue is fixed in version 4.41.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
SeaweedFS, a distributed storage system designed for files and blobs, contained a significant security misconfiguration within its SFTP Helm chart between versions 4.0.388 and 4.41. The vulnerability stemmed from the inclusion of an unencrypted Ed25519 private host key directly in the Kubernetes Secret manifest located at k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml under the stringData field named seaweedfs_sftp_ssh_private_key. This practice violates fundamental security principles regarding the handling of cryptographic material, as private keys must never be stored in plaintext within configuration files or version-controlled repositories where they can be easily extracted by unauthorized parties. The vulnerability was specifically triggered when specific deployment conditions were met: SFTP functionality was enabled via sftp.enabled and sftp.enableAuth flags set to true, no existing custom configuration secret was provided through sftp.existingConfigSecret, the legacy path for sshPrivateKey remained selected in the configuration, a valid config-ssh Secret existed allowing startup, and the hostKeysFolder did not supply an alternative Ed25519 signer. Under these circumstances, the system would present this hardcoded public key to clients during the SSH handshake process.
The operational impact of this vulnerability is severe due to its direct facilitation of Man-in-the-Middle attacks. An attacker capable of intercepting or redirecting client traffic could exploit the predictable and static nature of the host identity presented by SeaweedFS. Since many SFTP clients are configured to automatically accept new hosts or trust known identities, an adversary impersonating the legitimate SFTP endpoint using this compromised key would cause clients to establish encrypted sessions with the rogue server without raising suspicion. Once the connection is established under false pretenses, the attacker can intercept sensitive data transmitted during the session and capture user credentials entered for authentication. This effectively nullifies the confidentiality and integrity guarantees provided by SSH encryption, as the client believes it is communicating securely with the legitimate SeaweedFS instance while actually exchanging information with an malicious intermediary.
This vulnerability aligns closely with CWE-321, which describes the use of a hard-coded cryptographic key, and CWE-798, concerning the use of hardcoded credentials. From an offensive security perspective, this scenario maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle (AitM), where attackers position themselves between two communicating parties to intercept or alter communications. The risk is further exacerbated by the fact that default all-in-one deployments and non-authenticated standalone paths did not load this key, meaning the vulnerability was context-dependent but still present in any production environment utilizing authenticated SFTP access with the specified configuration parameters.
To mitigate this issue, organizations must upgrade to SeaweedFS version 4.41 or later, where the hardcoded private host key has been removed from the Helm chart templates. For environments that cannot immediately upgrade, it is critical to ensure that sftp.existingConfigSecret is utilized to provide a securely generated and managed SSH host key pair rather than relying on the default embedded values. Additionally, administrators should audit their Kubernetes Secrets for any other instances of hardcoded private keys or sensitive credentials stored in plaintext stringData fields. Implementing strict secret management practices using external secrets operators or dedicated vault solutions can prevent similar misconfigurations in future deployments. Regular security audits and static analysis tools configured to detect hard-coded secrets are essential components of a robust defense-in-depth strategy against such configuration-based vulnerabilities.