Swift security issues

Despite Swift’s safety guarantees, no language or ecosystem is completely immune to security issues. Far fewer are related to memory corruption compared to languages like C/C++.

Vulnerabilities in Swift language/compiler/runtime

There have been only a few reported issues in the Swift compiler and standard libraries in recent years, and none (publicly known) that allow for arbitrary code execution on macOS. One example is CVE-2020-9861, a stack overflow in Swift’s JSON parsing (part of Swift’s core libraries) when running on Linux. Feeding extremely deeply nested JSON could bypass the parser’s nesting limits and cause a crash (denial of service). Apple fixed this by adding input validation to avoid the overflow.

Another issue, CVE-2022-1642, involved Swift’s JSONDecoder on non-Apple platforms where a maliciously crafted JSON payload with mismatched number types could trigger a deterministic process crash. This was essentially a denial-of-service vulnerability in server contexts using Swift’s foundation JSON on Linux/Windows, and it was patched in Swift 5.6.2. (Notably, Apple stated that Darwin platforms; i.e., macOS/iOS - were not affected by this issue, since they use a different underlying JSON implementation). These vulnerabilities show that while Swift’s memory safety prevents things like buffer overruns, logic issues in parsing or integer handling can still lead to crashes. In terms of the Swift compiler or toolchain, there have been no major CVEs in 2023-2025 indicating that building Swift code can produce vulnerable binaries beyond those logic bugs. Apple’s security bulletins for Xcode have occasionally mentioned Swift (for instance, an acknowledgment in Xcode 16’s security notes for a researcher who likely found a Swift-related issue), but details are sparse. Overall, exploits “in Swift itself” are rare; the language’s design and the fact that Swift isn’t usually directly exposed to untrusted input (except in sandboxed app contexts or server use) means we haven’t seen things like “remote code execution in Swift runtime” in the wild. The issues that have come up tend to be denial-of-service (crashes) in specific library functionality or developer tools, rather than critical vulnerabilities.

Security issues in Swift applications and libraries

As Swift gains adoption in back-end and cross-platform development, vulnerabilities can emerge in Swift packages or app-specific code, often similar to those in other languages (injection flaws, logic errors, etc.). A notable example is the Vapor web framework (a popular server-side Swift framework). In late 2023, an issue (tracked as CVE-2024-21631) was discovered in Vapor’s URL parser where using a 16-bit index for string parsing led to an integer overflow on long URLs. An attacker could exploit this by padding parts of a URL to overflow the index and potentially spoof the URL host (bypassing expected validation). This could be used for phishing or redirecting server requests in unintended ways. The fix was to use a larger integer type and better validation.

Another set of issues came from swift-nio, the Swift networking library used in many server projects. Several CVEs in 2022 (e.g., CVE-2022-24666, CVE-2022-24667, CVE-2022-24668) were reported where a malicious HTTP/2 client could send specially crafted frames to crash a SwiftNIO-based server. For instance, CVE-2022-24666 describes how a HEADERS frame with priority info and no data could confuse the parser and trigger an assert, immediately crashing the process. These are denial-of-service attacks; trivial to launch (just send a bad HTTP/2 packet) and would reliably knock out an affected server, though importantly they do not lead to memory corruption or data leakage (the crashes were in “memory-safe code”, essentially triggered by logic traps). SwiftNIO fixed these by hardening the parser logic.

Similarly, CVE-2022-3215 was a SwiftNIO HTTP/1.1 issue where injecting newlines into header values wasn’t properly checked, allowing HTTP Response Splitting/Injection attacks (attackers could inject fake headers or even responses in some cases). This is akin to input sanitization issues seen in any web framework and was mitigated by stricter validation (disallowing newline characters in headers).

Another example is CVE-2023-0040, which affected the Swift AsyncHTTPClient library (used for making HTTP requests). It lacked validation on HTTP header fields and allowed CRLF injection - meaning an attacker who could feed untrusted data into a header (say, a user-supplied string in an HTTP request header) could insert newline characters to add malicious headers or even create a fake response downstream. This could be leveraged for various attacks like response splitting or cache poisoning if the client interacts with certain servers. The issue was fixed in AsyncHTTPClient 1.13.2.

Outside of networking, there was a significant bug in the Swift ZIP library (ZIP Foundation): CVE-2023-39135 details a classic path traversal vulnerability. The library did not sanitize paths in ZIP entries, so a crafted ZIP file with entries like ../../evil.dll could escape the intended extraction directory and overwrite files elsewhere on the file system. Exploiting this could allow an attacker to write files to arbitrary locations if a Swift app simply extracts a malicious ZIP (for example, an app importing user-supplied zip archives could inadvertently drop malware or modify application files). This issue, analogous to the well-known “Zip Slip” vulnerability, was assigned a High severity (CVSS 7.8). It could even lead to code execution in some scenarios (e.g., overwriting a binary that later gets executed). The mitigation was to update the library to perform path validation, ensuring extraction stays in a safe directory.

These examples show that Swift apps can have vulnerabilities due to logic errors or incomplete validation, much like apps in any language. The critical difference is that many typical memory safety issues are off the table. For instance, none of these CVEs are buffer overruns or wild-pointer writes (they’re DoS, injection, or file overwrite issues). This means attackers often have to resort to more application-specific tricks rather than exploits like arbitrary code execution via memory corruption (which is a common vector in C/C++ programs).

Issues related to Swift’s memory management (ARC, Pointers, etc.)

Swift’s ARC-based memory model reduces the chance of classic memory exploits, but it can introduce other concerns.

Memory leaks

One such concern is memory leaks. While not an exploit per se, a leak can be abused for denial-of-service. For example, an attacker might repeatedly perform an operation that the app fails to free (due to a retain cycle or unmanaged growth), eventually exhausting memory. A deliberate scenario could be if an attacker finds that a certain user action causes a retain cycle (maybe a closure capturing self strongly in a loop). Over many iterations, memory usage could balloon and crash the app. Swift helps avoid this by encouraging use of weak references to break cycles (e.g., in delegate patterns or closures that capture self), but the onus is on developers to implement that.

A concrete memory-management issue from Swift’s server side was CVE-2022-3252, which wasn’t a leak exactly but a livelock in SwiftNIO’s HTTP decompression logic. If an attacker sent an HTTP response with a compressed body that had extra trailing bytes, the SwiftNIO HTTPResponseDecompressor would enter an infinite loop trying to decompress the “junk” data and never realizing the stream ended. This would peg CPU and could slowly consume memory, effectively a DoS (the process would stop responding but not crash). The fix was to properly detect the end of the compressed stream and not loop indefinitely. This highlights how even without memory corruption, logical flaws in memory management (in this case, not handling a buffer condition) can be exploitable.

Unsafe pointers

If a Swift developer misuses UnsafeMutablePointer or related constructs, they can indeed introduce memory corruption. For instance, if you allocate an UnsafeBufferPointer and then write out of bounds, you have a classic buffer overflow situation, which could be exploitable. The difference is that Swift confines such code to clearly marked “unsafe” blocks, and it should then be relatively rare in typical macOS app code. There haven’t been reports of an attacker leveraging a bug in Swift unsafe pointer usage to achieve an exploit on macOS from what I can tell… Most likely because such issues, if they exist, would be app-specific and not fundamental to Swift.

Unowned references

Another potential weak point is unowned references: if used incorrectly, an unowned reference can become a dangling pointer (pointing to memory after the object is freed) - accessing it triggers a runtime crash. While this crash isn’t exploitable for code execution (because Swift runtime will trap when it detects an unowned access to a deallocated object), it could be used in a denial-of-service sense if an attacker can consistently cause a code path that uses a now-freed unowned reference (this is a fairly contrived scenario, but possible if logic assumes object lifetimes that an attacker manages to break). In practice, these are edge cases; Swift’s memory model largely forces you into safe patterns, and where you step out (unowned, unsafe pointers), it’s usually deliberate and audited in critical software.

In summary, Swift security from 2023-2025 is characterized by logic and data-validation issues rather than memory safety issues. Swift’s design prevents the many dangerous bugs (buffer overflows, arbitrary code execution through memory corruption). Apple’s security teams have noted that the majority of serious vulnerabilities (on platforms like iOS/macOS) stem from memory-unsafe code (Objective-C, C, C++), not from Swift.

By using Swift, many of those avenues are closed; attackers don’t easily find use-after-free or overflow bugs to exploit in pure Swift code. However, Swift apps and frameworks are still susceptible to higher-level vulnerabilities: injection attacks (if inputs aren’t sanitized), denial-of-service through uncaught exceptions or infinite loops, logic mistakes in authentication or authorization, etc. The Swift community and Apple have been actively addressing these: for instance, Swift’s recent concurrency update (Swift 6’s data race checks) will help prevent a whole class of threading bugs that could have security implications (like race-condition related state confusion). And the ecosystem quickly patches identified issues (the Vapor and SwiftNIO vulnerabilities were publicly disclosed and fixed in updates). No major “Swift language” zero-day has hit macOS to date (3 July 2025), and it’s telling that even the HTTP/2 DoS issues in SwiftNIO were crashes in safe code (triggered by logical assertions). Of course, we must be vigilant; using Swift does not automatically make an app immune to all vulnerabilities, especially if one includes unsafe code or integrates C libraries. But overall, Swift’s memory management and safety features have raised the baseline security of macOS applications. The focus of exploits should tend to be higher-level logic flaws in Swift apps and attacking the remaining C/C++ components of the system.