Unauthenticated out-of-bounds stack write via oversized ECDSA signature in swift-nio-ssh
CriticalCVE-2026-43798 · Published Jul 17, 2026
## Summary SwiftNIO SSH has a security vulnerability where an unauthenticated attacker can write data out of bounds on the stack. This happens because the system does not check the length of incoming ECDSA signature integers before copying them, allowing oversized values to overwrite memory prior to cryptographic verification. ## Impact A single crafted SSH message gives an unauthenticated network attacker an out-of-bounds stack write of attacker-controlled length and content against any application built on swift-nio-ssh: - **Server side:** any peer that completes the SSH version/KEXINIT handshake (no credentials) can send a publickey SSH_MSG_USERAUTH_REQUEST with crafted signature blob. The signature is decoded while parsing the message — before the public key or signature is ever verified — triggering the write. - **Client side:** a malicious or man-in-the-middle server triggers the same path via the ECDSA signature in its key-exchange reply. ## Fix Fixed in https://github.com/apple/swift-nio-ssh/commit/31cdc3c3391a10460dedf1170530cf651d2ca496 ## Mitigation - Upgrade to 0.14.1 as soon as possible for the only complete fix. - Partial mitigation: Restrict network exposure ...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| swift-nio-ssh Product | < 0.14.1 | 0.14.1 |
Details and references
## Summary SwiftNIO SSH has a security vulnerability where an unauthenticated attacker can write data out of bounds on the stack. This happens because the system does not check the length of incoming ECDSA signature integers before copying them, allowing oversized values to overwrite memory prior to cryptographic verification. ## Impact A single crafted SSH message gives an unauthenticated network attacker an out-of-bounds stack write of attacker-controlled length and content against any application built on swift-nio-ssh: - **Server side:** any peer that completes the SSH version/KEXINIT handshake (no credentials) can send a publickey SSH_MSG_USERAUTH_REQUEST with crafted signature blob. The signature is decoded while parsing the message — before the public key or signature is ever verified — triggering the write. - **Client side:** a malicious or man-in-the-middle server triggers the same path via the ECDSA signature in its key-exchange reply. ## Fix Fixed in https://github.com/apple/swift-nio-ssh/commit/31cdc3c3391a10460dedf1170530cf651d2ca496 ## Mitigation - Upgrade to 0.14.1 as soon as possible for the only complete fix. - Partial mitigation: Restrict network exposure to only allow-listed trusted peers. - Partial mitigation: Client side, only connect to trusted servers. - Partial mitigation: Run services as a supervised/sandboxed process with auto-restart, reducing crashes to a contained denial of service. This attack is based on the signature type in an attacker's message, not on the configuration of any specific accepted algorithm. Algorithm restrictions do **not** help. Found by @Yanchon918s
More Apple advisories
All Apple| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Jul 23 | Missing CR/LF/NUL validation in header values | Medium | 1.45.0 |
| Jul 16 | Double-free when parsing RSA public key fails | Critical | 4.5.1 |
| Jul 15 | Accessing bytes of non-string SAN can lead to out-of-bounds memory read | Critical | 2.37.2 |
| Jul 9 | Apple FileMaker Server: code execution | Medium4.9 | 26.0.1 |
| Jul 9 | DoS via WebSocket frame with oversize 64-bit payload length field (Int trap in WebSocketFrameDecoder) | High7.5 | 2.101.0 |
| Jul 8 | Packages can be read/written outside the configured cache directory | Medium | 0.32.0 |