Four security reminders appeared on the Swift Forums on October 12, covering SwiftNIO, Swift Crypto, SwiftNIO SSL and SwiftNIO HTTP/2. Each points to a fix that has been available since June or July. The notices are a useful prompt to check what a deployed application actually includes, particularly where it accepts WebSocket traffic, parses RSA keys or forwards HTTP requests.
The underlying GitHub advisories were published in July. Developers who already incorporated the relevant fixes have no additional patch to apply for these four issues.
Where the failures occur
SwiftNIO versions through 2.100.0 contain a WebSocket decoder bug that can terminate a server process when it receives a malformed frame after a completed handshake. The failure happens before the configured frame-size limit is checked, so changing that limit does not address it. The advisory rates the issue High. SwiftNIO 2.101.0, released June 8, contains the fix; the advisory followed on July 9.
Swift Crypto 3.2.0 through 4.5.0 has a different failure path. An error while decoding a malformed RSA public key from DER or PEM can free the same underlying object twice, potentially causing a later crash. The affected applications are those parsing untrusted keys through _RSA.Signing.PublicKey, _RSA.Encryption.PublicKey or _RSA.BlindSigning.PublicKey. The Critical-rated advisory and the patched 4.5.1 release both date to July 16.
Two important limits
The SwiftNIO SSL advisory is also rated Critical, but its affected usage is specific. Versions 2.18.0 through 2.37.1 can read outside the intended memory buffer when callers directly access certificate subject alternative name bytes through the underscored _subjectAlternativeNames() API without checking the name’s type.
The advisory explicitly says NIOSSL’s own internal uses are unaffected because they check the type first. Treating this as a blanket flaw in every NIOSSL TLS connection would overstate the finding. The fix shipped in 2.37.2 on July 15, the same day as the advisory.
SwiftNIO HTTP/2 versions below 1.45.0 have incomplete inbound header validation that can enable request smuggling or response splitting when certain pipelines forward traffic to an HTTP/1.1 backend. The stock pipeline already rejects the problematic values through outbound header validation, enabled by default. Exposure concerns pipelines that skip that validation or forward header values elsewhere while assuming they were checked.
That advisory is rated Moderate. Version 1.45.0 shipped July 22; the advisory was published July 23.
What to check
Start with the resolved dependencies for the application you actually build and deploy. Swift Package Manager records resolved versions in Package.resolved. Check the application’s dependency graph, including packages brought in by another dependency, against the affected ranges above. A library’s own Package.resolved does not determine the versions selected by an application that consumes it. SwiftPM’s dependency-resolution documentation explains that distinction.
Then check whether the affected APIs or traffic paths are reachable. A package name in the dependency graph alone cannot establish every exposure described here. Give particular attention to externally reachable WebSocket services, untrusted RSA-key parsing, custom certificate inspection and HTTP forwarding code.
For affected deployments, move to compatible releases containing the fixes, test the application and verify the rebuilt version reaches production. Swift Crypto deserves an extra look: a dependency constrained to 3.x cannot resolve to the advisory’s listed patched version, 4.5.1, without changing that constraint. SwiftPM’s version-constraint documentation describes how eligible versions are selected.
These version numbers identify fixes for these particular advisories. A complete dependency review should also account for later releases and other advisories. The practical outcome is a verified deployed dependency set, with the application’s actual exposure understood.
