We are using libssh 0.9.6 in a proxy application that sits between an SFTP client and an SSH server. The proxy decrypts and inspects traffic, validates packets, and then re-encrypts and forwards them to the next hop. The client and backend server both use OpenSSH 8.9p1.

Version Details:
Proxy library: libssh 0.9.6
Client version: OpenSSH_8.9p1 Ubuntu-3ubuntu0.13
Server version: OpenSSH_8.9p1

Proxy role: decrypt → validate → encrypt (acts as SSH-to-SSH proxy)

Summary of Observed Issue:
We observe a reliable failure in SFTP file transfers under the following conditions:

1. File transfer fails after ~80% completion.
2. Failure occurs only for large files (>800MB).
3. Transfers succeed if:
   a. File size is ≤800MB, or
   b. We throttle the transfer speed using sftp -l 5 (e.g., limit to 5Mbps).
   When the SSH proxy is disabled and the client connects directly to the backend OpenSSH server, no failure occurs—regardless of file size or transfer speed.

Packet-Level Analysis:
We collected decrypted traffic from both the client and server side of the proxy for a failing file transfer.
During analysis of SSH traffic captured from both the client (after decryption) and the server (before encryption), we observed a critical misalignment in the packet stream caused by a 9-byte data injection on the server side Specifically, when the client sends an SSH_MSG_CHANNEL_WINDOW_ADJUST message, we noticed the following behaviour:

1. In the client-side decrypted capture, the SSH_MSG_CHANNEL_WINDOW_ADJUST message is correctly framed and transmitted as a standalone packet (a 9-byte SSH packet).
2. However, in the server-side pre-encryption capture, those same 9 bytes (5d 00 00 00 00 00 01 80 03) appear embedded in the middle of the previous packet, starting at offset 0x18a0(in packet capture) where they do not belong.

Ex:
part of data in clientside
00001880: 6f e7 0c 6b 3b a6 8d a6 0c 29 3d 19 08 dd d8 ca |o..k;....)=.....|
00001890: 39 21 73 9f d5 db 9c b1 43 cc 5c c1 81 83 6c 2e |9!s.....C....l.|
000018a0: 04 d7 00 03 fc 19 06 00 00 0d b4 00 00 00 04 00 |................|
000018b0: 00 00 00 00 00 00 00 36 85 44 00 00 03 fc 00 9f |.......6.D......|
000018c0: 29 3e 9f 82 88 73 6c 44 16 b1 fb 2f a4 70 66 e3 |)>...slD.../.pf.|
000018d0: bf 51 dd a9 d7 1f 7e da a8 9d 20 ab 83 bc 56 af |.Q....... ...V.|

same part of data in server side:
00001880: 6f e7 0c 6b 3b a6 8d a6 0c 29 3d 19 08 dd d8 ca |o..k;....)=.....|
00001890: 39 21 73 9f d5 db 9c b1 43 cc 5c c1 81 83 6c 2e |9!s.....C....l.|
000018a0: 04 d7 5d 00 00 00 00 00 01 80 03 00 03 fc 19 06 |..].............|
000018b0: 00 00 0d b4 00 00 00 04 00 00 00 00 00 00 00 00 |................|
000018c0: 36 85 44 00 00 03 fc 00 9f 29 3e 9f 82 88 73 6c |6.D......)>...sl|
000018d0: 44 16 b1 fb 2f a4 70 66 e3 bf 51 dd a9 d7 1f 7e |D.../.pf..Q....|

This unexpected 9-byte injection results in:

1. A misalignment of subsequent data: the last 9 bytes(6d 11 8c 65 3f 23 ff 76 66) of the client-side packet (which should appear at the end of the packet) are instead pushed to the beginning of the next packet on the server side. We updated the same and also attached collected data in a case.
   Ex:
   clientside(end of the packet data):
   00007ff0: f8 3d 0a 5f 4c 81 09 d7 9c df 72 c8 ab 8a c1 f2 |.=._L.....r.....|
   00008000: 6d 11 8c 65 3f 23 ff 76 66 |m..e?#.vf|

server side:
=== PACKET #193 (SERVER-SIDE BEFORE ENCRYPTION) ===
Length: 32777 bytes
00000000: 6d 11 8c 65 3f 23 ff 76 66 5e 00 00 00 00 00 00 |m..e?#.vf^......|
00000010: 80 00 ff f9 ea 1b 19 07 a4 e7 dd 95 51 66 99 40 |............Qf.@|

2. A ripple effect: the misalignment causes a persistent 9-byte offset between the client and server packet streams until the next standalone control packet (also 9 bytes) appears on both ends, which realigns the streams temporarily, but by then connection has been terminated.

Is this a known issue in libssh 0.9.6? Has this been addressed in a later version of libssh?
Is there a known workaround or patch for this type of stream misalignment?
Are there recommended changes in buffering/queueing logic when libssh is used in proxy mode?