CVE-2024-6580

Imagine your SFTP service is like a doorman who decides which “rooms” a person is allowed to enter. This bug means that, when loading a login’s SSH public key or certificate, the doorman may not properly verify it, and the system could be tricked into trying to use paths it shouldn’t.

For a business, that translates into a risk of attackers probing for unintended file access or reaching unintended network locations through the SFTP service—most likely only if your setup already lets attackers reach the key-loading logic without strong key validation.

This matters if your business uses /n software IPWorks SSH and specifically its SFTPServer component in a way that allows user access while not verifying the SSH public key or certificate. If you already validate keys/certificates correctly in the application that calls IPWorks SSH, the impact is much less likely.

Reachability depends on your configuration: it requires a scenario where the application grants user access without verifying the SSH public key/certificate. If that condition is not met, exploitation is not expected.

This is GREEN because the issue is not listed as a confirmed CISA KEV item and there is no public exploit code on record. However, the vulnerability is reachable through network access in the right setup, and it is specifically about insufficient verification of SSH keys or certificates.

If you use IPWorks SSH SFTPServer and your application’s SSH key/certificate validation is weak or missing, you should upgrade promptly. If your key/certificate validation is strong and enforced, treat this as a planned update rather than an emergency.

Confirm exposure

• Identify your deployment(s) using /n software IPWorks SSH SFTPServer and capture the exact IPWorks SSH SFTPServer version.
• If your system embeds or wraps IPWorks SSH, confirm the library/component version included in your build or installed package.

Determine whether you’re at risk

• The findings say exploitation depends on an application granting user access without verifying the SSH public key or certificate. So, review how your application handles SSH authentication materials:
  • Are you validating the presented SSH public key/certificate against an allowlist/expected identity?
  • Are you accepting arbitrary keys/certificates without verification?
  • Do you enforce key/certificate binding to the user/account you intended?

Upgrade to the fixed versions

• Patch versions reported as fixed:
  • IPWorks SSH SFTPServer → fixed in 22.0.8945
  • IPWorks SSH SFTPServer → fixed in 24.0.8945
• Upgrade your SFTPServer component to the appropriate fixed release for the version line you are using.

After upgrading (verification)

• Re-run your SFTP login tests, including attempts using unexpected/invalid SSH public keys or certificates (in a safe test environment).
• Check your SFTP/server logs for:
  • unusual or crafted key/certificate presentation attempts
  • any evidence of unintended filesystem or network path requests (if your environment logs such behavior)

Workaround if patching is delayed

• Until you can upgrade, the most practical mitigation (based on the stated precondition) is to ensure your calling application enforces strict verification of SSH public keys/certificates before allowing access.
• If you cannot enforce validation immediately, restrict who can reach the SFTP endpoint (for example, limit network exposure to trusted IP ranges) so attackers have fewer chances to reach the key-loading/authentication path.

What to monitor

• Ongoing monitoring for repeated failed logins or authentication attempts using unusual SSH keys/certificates.
• Any unexpected SFTP path access patterns by authenticated users.

KEV due date

• Not applicable here: CVE-2024-6580 is not listed in the CISA KEV.

Severity is rated as MEDIUM by the provided CVSS (6.5). The core issue is an insufficient access verification weakness (CWE-1390) combined with improper handling of resource/path related input (CWE-347): when the SFTPServer component loads a SSH public key or certificate, crafted inputs can lead to unintended filesystem or network path requests.

Mechanism and precondition: exploitation is described as requiring the calling application to grant user access without verifying the SSH public key or certificate. In other words, the security boundary depends on correct SSH key/certificate validation in the application integrating IPWorks SSH.

Fix availability: IPWorks SSH SFTPServer versions 22.0.8945 and 24.0.8945 were released to address this by blocking all filesystem and network path requests for SSH public keys or certificates.

Exploitation status: no public exploit code is on record, and CVE-2024-6580 is not listed in CISA KEV. EPSS is a prediction only (and is not reflected as confirmed exploitation).