CVE-2026-100413: 
Wolfi vulnerability analysis and mitigation

CVE-2026-100413 is a hard-coded cryptographic key vulnerability (CWE-321) in the SeaweedFS distributed storage system's SFTP Helm chart. Versions 4.0.388 through 4.40 embedded a fixed, unencrypted Ed25519 private host key (SHA256:0afw5vH6NIGPGe3H+d9x8M3QoVZyGZZem58XuawSMj0) in k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml as stringData.seaweedfs_sftp_ssh_private_key. Because this key was committed to the public repository, any attacker with network interception capability could use it to impersonate a legitimate SFTP endpoint. The vulnerability was disclosed on October 14, 2026, and carries a CVSS v4.0 base score of 7.0 (High) (GitHub Advisory, Feedly).

The root cause is CWE-321 (Use of Hard-coded Cryptographic Key): the Helm chart template statically embedded a single Ed25519 OpenSSH private key shared across all installations that did not override it. The vulnerability is only triggered under a specific combination of conditions: sftp.enabled and sftp.enableAuth are both true, sftp.existingConfigSecret is unset (causing the chart-managed *-sftp-secret to be mounted at /etc/sw), sftp.sshPrivateKey retains its default path (/etc/sw/seaweedfs_sftp_ssh_private_key), a valid config-ssh Secret allows pod startup, and hostKeysFolder does not supply a later Ed25519 signer that would override the bundled key. An attacker who can redirect or intercept network traffic can operate a rogue SFTP server using the publicly known private key; clients that accepted this key via trust-on-first-use cannot distinguish the rogue endpoint through host-key validation. The fix, merged in PR #10390, generates a unique Ed25519 key per Helm install and replaces the previously bundled key on upgrade (GitHub Advisory, Fix PR).

A successful man-in-the-middle attack against an affected SFTP endpoint can expose SFTP password credentials and all data transmitted to the rogue endpoint, resulting in high confidentiality impact. Integrity impact is limited — public-key authentication signatures are session-bound and cannot be replayed upstream, but the attacker can accept and inspect any data the client sends. Availability is not directly affected. The scope is limited to deployments that actually present the bundled key; installations using sftp.existingConfigSecret, a custom sftp.sshPrivateKey, or a replacement Ed25519 key via hostKeysFolder are not affected (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0 and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to be positioned to redirect or intercept network traffic between SFTP clients and the server (network-level prerequisite), and the target deployment must satisfy all six configuration conditions described in the advisory. The bundled key fingerprint (SHA256:0afw5vH6NIGPGe3H+d9x8M3QoVZyGZZem58XuawSMj0) is publicly documented, lowering the barrier for any attacker who achieves the required network position (GitHub Advisory, Feedly).

1. Identify affected deployments: Scan for Kubernetes clusters running SeaweedFS Helm chart versions 4.0.388–4.40 with SFTP enabled. Use ssh-keyscan -p 2022 -t ed25519 <target> 2>/dev/null | ssh-keygen -lf - -E sha256 and check for the fingerprint SHA256:0afw5vH6NIGPGe3H+d9x8M3QoVZyGZZem58XuawSMj0.
2. Obtain the bundled private key: Retrieve the hard-coded Ed25519 private key from the public SeaweedFS repository at k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml (versions prior to 4.41).
3. Achieve network interception: Position to intercept or redirect SFTP client traffic to the target endpoint via ARP spoofing, DNS poisoning, BGP hijacking, or a compromised network path.
4. Stand up a rogue SFTP server: Configure an SFTP server (e.g., OpenSSH) using the extracted Ed25519 private key as the host key, so it presents the same known host identity.
5. Harvest credentials and data: Clients that previously accepted or pinned the bundled host key will connect to the rogue server without a host-key warning, transmitting SFTP passwords and file data to the attacker (GitHub Advisory).

• Network: SFTP endpoint (default port 2022) presenting host key fingerprint SHA256:0afw5vH6NIGPGe3H+d9x8M3QoVZyGZZem58XuawSMj0 — detectable via ssh-keyscan -p 2022 -t ed25519 <host> | ssh-keygen -lf - -E sha256; unexpected SFTP connections to IP addresses not matching the legitimate SeaweedFS pod.
• Kubernetes / File System: Presence of the literal string H4McwcDphteXVullu6q7ephEN1N60z in any Kubernetes Secret (e.g., kubectl get secret <release>-seaweedfs-sftp-secret -o yaml | grep H4McwcDphteXVullu6q7ephEN1N60z), indicating the bundled key has not been rotated.
• Logs: SFTP server startup logs referencing /etc/sw/seaweedfs_sftp_ssh_private_key as the loaded host key path on SeaweedFS versions prior to 4.41; authentication log entries showing successful logins from unexpected source IPs or at unusual times (GitHub Advisory).

Upgrade the SeaweedFS Helm chart to version 4.41, which generates a unique Ed25519 host key per installation and automatically replaces the previously bundled key on the next helm upgrade (Release 4.41). As an immediate workaround for operators who cannot upgrade, supply a custom host key via sftp.existingConfigSecret or sftp.existingSshConfigSecret, or place a replacement Ed25519 key in hostKeysFolder to override the bundled signer. After upgrading, operators should verify that the exposed fingerprint (SHA256:0afw5vH6NIGPGe3H+d9x8M3QoVZyGZZem58XuawSMj0) is no longer presented by any SFTP endpoint; if it was served and password authentication was in use with a plausible interception risk, rotate all associated SFTP passwords (GitHub Advisory).