CVE-2026-44405

What it actually does

Paramiko versions through 4.0.0 before commit a448945 permit the SHA-1-based RSA signature algorithm in rsakey.py. SHA-1 is cryptographically weakened and should not be used for new trust decisions because collision and downgrade-related risks can undermine signature integrity. In practical terms, exploitation would require an attacker to be positioned where they can influence or intercept SSH authentication or negotiation and successfully cause use of the weaker SHA-1 RSA path; the assigned CVSS indicates adjacent-network reachability, high attack complexity, no required privileges, no user interaction, and limited integrity impact.

Why it matters to the business

The primary risk is weakened trust in SSH-based automation, administration, deployment, and file-transfer workflows that rely on Paramiko. A successful attack could allow limited tampering with SSH trust decisions or authentication integrity under constrained conditions, but public exploitation is not currently indicated, EPSS is very low, and the issue is not listed in CISA KEV. Organizations with broad Python automation, CI/CD, orchestration, or network-management tooling using Paramiko should still remediate because cryptographic deprecation issues can become more serious as attack techniques improve and as weak algorithms are increasingly rejected by compliant environments.

How an attack unfolds

An attacker would first need network positioning suitable to observe, intercept, or influence SSH communication involving a vulnerable Paramiko client or server-side use case. The attacker would then attempt to steer the SSH exchange toward an RSA/SHA-1 code path that remains accepted by the vulnerable Paramiko version. If the attacker can satisfy the high-complexity cryptographic and protocol conditions, they may be able to affect the integrity of the SSH trust or authentication process. This is not a typical remote-code-execution scenario and does not directly disclose data or cause service outage; the security concern is acceptance of a deprecated and weakened signature algorithm in security-sensitive SSH operations.

How to fix it

Upgrade Paramiko to a version that includes the fix for commit a448945 or later than the vulnerable through-4.0.0 code line once a packaged release is available from the project or distribution vendor. If upgrading immediately is not possible, reduce exposure by disabling or rejecting SHA-1-based SSH RSA signatures where configurable, prefer modern algorithms such as rsa-sha2-256, rsa-sha2-512, Ed25519, or ECDSA, and ensure OpenSSH/SSH server policies do not allow legacy ssh-rsa/SHA-1 negotiation. Rebuild and redeploy applications, containers, virtual environments, and bundled Python packages that vendor or pin Paramiko. Review dependency lockfiles and base images because Paramiko is commonly embedded in automation, configuration management, network tooling, and file-transfer utilities.

How to confirm the fix worked

Confirm all deployed Python environments, containers, packaged applications, and dependency lockfiles no longer include vulnerable Paramiko versions through 4.0.0 before the fixing change. Use package inventory commands such as `python -m pip show paramiko`, `pip freeze`, software composition analysis, or container image scanning to verify the installed version or patched source revision. Validate SSH hardening by confirming SHA-1 RSA signatures are not accepted during negotiation and that stronger algorithms are preferred. Where feasible, enable Paramiko debug logging in a test environment and confirm connections use algorithms such as rsa-sha2-256, rsa-sha2-512, ssh-ed25519, or ECDSA rather than SHA-1-based `ssh-rsa`.

Typical attack path

1. Identify systems, applications, automation scripts, or services using vulnerable Paramiko versions through 4.0.0 before the fixing change.
2. Obtain adjacent or man-in-the-middle network positioning relative to SSH traffic handled by the vulnerable Paramiko-based component.
3. Influence SSH algorithm negotiation or signature validation so that RSA/SHA-1 remains in use instead of stronger algorithms.
4. Exploit the weakened cryptographic path under high-complexity conditions to affect the integrity of an SSH authentication or trust decision.
5. Use the resulting integrity weakness to support follow-on access, tampering, or lateral movement where the affected SSH workflow is security-relevant.

How to detect it

There are no known unique post-exploitation artifacts for this weakness, and exploitation is difficult to prove retrospectively unless detailed SSH negotiation logs, packet captures, or Paramiko debug logs were collected at the time. Review application logs, Paramiko debug output, SSH server logs, network security telemetry, and packet captures for evidence that affected Paramiko-based clients negotiated legacy `ssh-rsa` or SHA-1-based RSA signatures. Focus on administrative automation, CI/CD deployment jobs, SFTP workflows, and network-management tasks. Investigate any unexpected algorithm downgrades, repeated SSH authentication failures followed by success, unknown adjacent-network sources, or anomalous host-key changes around sensitive SSH workflows. Treat occurrences of `ssh-rsa`/SHA-1 negotiation as exposure indicators rather than definitive compromise indicators unless paired with suspicious network positioning, unauthorized access, or tampering evidence.

What your security team should do

• Inventory Paramiko usage across source repositories, lockfiles, containers, server images, CI/CD runners, automation hosts, and third-party Python applications.
• Prioritize remediation for systems that use Paramiko for privileged administration, deployment automation, network-device management, SFTP transfers, or production orchestration.
• Upgrade to a Paramiko build containing the a448945 fix or a vendor-provided fixed release, and rebuild all artifacts that bundle the dependency.
• Disable SHA-1-based SSH RSA algorithms in client and server SSH policy wherever operationally feasible.
• Add dependency-scanning policy to flag Paramiko versions through 4.0.0 before the fix and to alert on any reintroduction of SHA-1 SSH algorithms.
• Because EPSS is very low, there is no KEV listing, and no mature public exploit is reported, treat this as a cryptographic hygiene and integrity-hardening issue unless the affected workflow protects highly privileged access.
• Monitor SSH authentication and negotiation logs for unexpected use of legacy `ssh-rsa` or SHA-1 algorithms, especially on administrative or automation pathways.