Update libssh2 to fix CVE-2026-55200

[Manishearth]

This PR updates the libssh2 submodule to a backported version of 1.11.1 that addresses multiple recent security vulnerabilities and includes a critical follow-up bugfix:

Patched Vulnerabilities:

1. CVE-2026-55200 (Critical): Heap-based buffer overflow in ssh2_transport_read() due to missing bounds check on packet_length in the chacha20-poly1305 path.
   • Backported from upstream commit: 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
2. CVE-2026-55199 (High): Pre-authentication infinite loop in EXT_INFO handler in packet.c due to unchecked return value of _libssh2_get_string().
   • Backported from upstream commit: 17626857d20b3c9a1addfa45979dadcee1cd84a4
3. CVE-2025-15661 (Medium): Out-of-bounds read in SFTP symlink code in sftp.c.
   • Backported from upstream commit: 2dae3024897e1898d389835151f4e9606227721d

Additional Fixes:

• SFTP Symlink Bugfix: Moves advancing past packet ID before reading the FXP_STATUS response in sftp_symlink. This fixes a critical bug introduced by the CVE-2025-15661 patch which caused the request ID to be incorrectly interpreted as the status code.
  • Backported from upstream commit: 4ed26f5740bdd409269ed9fb48a28bf8f565b681

The submodule commit is updated to 090f23d1852a0b62e081bd12c4d05adc1c4af47a, which resides in Manishearth/libssh2 (branch backport-cve-2026-55200).

Note

For upstream CI to pass, these commits will need to be made available in the main libssh2/libssh2 repository, as the .gitmodules still points there. However, this is fully ready for packaging/release since libssh2-sys bundles the C source code on cargo publish. We have temporarily updated .gitmodules to point to the fork to ensure CI runs green on this PR in the meantime.

Changes:

• Update libssh2 submodule to patched 1.11.1 (090f23d1).
• Bump libssh2-sys version to 0.3.2.
• Bump ssh2 version to 0.9.6 and update its dependency on libssh2-sys to 0.3.2.
• Temporarily point submodule URL to Manishearth/libssh2 fork to make CI green.

[alexcrichton]

@yodaldevoid 👋 would you be up for reviewing this? I'm realizing that I sort of transferred ownership/maintenance of this crate to others a few years back and never actually got around to transferring the github repo here out of my personal account. I see you've been the one mantaining and/or committing to this repo for the past few years hence my ask.

If not, do you know of others that are still available to maintain this crate? If you'd rather hand off maintenance that's also totally fine and I can try to enlist other folks for this.

Also, for some background, this affects Cargo and so the upstream Rust project would like to get some form of these fixes published to crates.io in the near future for the Rust 1.97 release next week. I can probably help out here as a one-time thing if you're otherwise busy and/or would like to hand off maintainership, though.

[Manishearth]

Given that this is security relevant for Cargo, I'm happy to have this be moved under rust-lang for Cargo, with @yodaldevoid having maintainer rights, maybe also the Cargo team, and the security WG having access for dealing with this type of issue.

[yodaldevoid]

I see nothing inherently wrong with the PR. I would have taken care of this over the weekend, including the once again broken CI, but I was away all weekend. I can get a release out later today.

As for maintenance, I would be more than happy to see it moved under the rust-lang organization. I've felt for a while that I have been doing less than the bare minimum that this crate really needs.

[Manishearth]

@yodaldevoid great, thanks! I'm not sure what's going on with CI, I assume it's already broken

[alexcrichton]

I'm happy to do that if you're happy, but I'd caution in the sense that I don't think it would procure more maintainers out of thin air, it's more that folks would feel empowered to land stuff Cargo-impacting without feeling blocked on a repo that lives elsewhere.

There's two other folks who have write access to this repo right now, too, as @wez and @crisidev. Would y'all still like to be maintainers of this repository/crate? If so we can make sure you're still on the list of write-approved folks after the repo transfers, but if not y'all can be removed during the transition. (thanks for the historical help regardless!)

[Manishearth]

I'd caution in the sense that I don't think it would procure more maintainers out of thin air, it's more that folks would feel empowered to land stuff Cargo-impacting without feeling blocked on a repo that lives elsewhere.

Correct. Though I personally do want to try and update this crate to a newer libssh2 so I hope to be doing that work regardless. And I'll probably stay subscribed to the repo and try to help out where I can.

[crisidev]

I don't have a lot of time for maintaining this package unfortunately and I have been neglecting it recently. I am sorry 😞

[yodaldevoid]

So, looking into the CI failure it is definitely caused by the PR.

OpenSSH only implements up to SFTP v3 which doesn't support the "file is write protected" error that is seen here. It looks like the fix for CVE-2025-15661 has broken error parsing from the symlink command. This bug seems to be a part of the original patch and was fixed in libssh2/libssh2@4ed26f5.

I will merge this and make a release as soon as I see that patch included in your backport.

[Manishearth]

Done.

[yodaldevoid]

Releases of both crates have been published and tags have been made. Sorry for the delay.