Swift Apple Swift

Do you want an email whenever new security vulnerabilities are reported in Apple Swift?

Recent Apple Swift Security Advisories

Advisory Title Published
HT210647 Swift 5.1.1 for Ubuntu Security Content October 11, 2019
HT210772 SwiftNIO SSL 2.4.1 Security Content October 4, 2019
HT210436 SwiftNIO HTTP/2 1.5.0 Security Content August 13, 2019
HT208921 SwiftNIO 1.8.0 Security Content June 27, 2018
HT208804 Security Update 2018-001 Swift 4.1.1 for Ubuntu 14.04 Security Content May 4, 2018

By the Year

In 2024 there have been 0 vulnerabilities in Apple Swift . Last year Swift had 2 security vulnerabilities published. Right now, Swift is on track to have less security vulnerabilities in 2024 than it did last year.

Year Vulnerabilities Average Score
2024 0 0.00
2023 2 8.15
2022 7 7.50
2021 0 0.00
2020 2 7.50
2019 2 9.80
2018 1 8.80

It may take a day or so for new Swift vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.

Recent Apple Swift Security Vulnerabilities

The HTTP/2 protocol

CVE-2023-44487 7.5 - High - October 10, 2023

The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

Resource Exhaustion

A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF ( ) injection in URLRequest headers

CVE-2022-3918 8.8 - High - January 20, 2023

A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF ( ) injection in URLRequest headers. In this vulnerability, a client can insert one or several CRLF sequences into a URLRequest header value. When that request is sent via URLSession to an HTTP server, the server may interpret the content after the CRLF as extra headers, or even a second request. For example, consider a URLRequest to http://example.com/ with the GET method. Suppose we set the URLRequest header "Foo" to the value "Bar Extra-Header: Added GET /other HTTP/1.1". When this request is sent, it will appear to the server as two requests: GET / HTTP/1.1 Foo: Bar Extra-Header: Added GET /other HTTP/1.1 In this manner, the client is able to inject extra headers and craft an entirely new request to a separate path, despite only making one API call in URLSession. If a developer has total control over the request and its headers, this vulnerability may not pose a threat. However, this vulnerability escalates if un-sanitized user input is placed in header values. If so, a malicious user could inject new headers or requests to an intermediary or backend server. Developers should be especially careful to sanitize user input in this case, or upgrade their version of swift-corelibs-foundation to include the patch below.

Injection

NIOHTTP1 and projects using it for generating HTTP responses can be subject to a HTTP Response Injection attack

CVE-2022-3215 7.5 - High - September 28, 2022

NIOHTTP1 and projects using it for generating HTTP responses can be subject to a HTTP Response Injection attack. This occurs when a HTTP/1.1 server accepts user generated input from an incoming request and reflects it into a HTTP/1.1 response header in some form. A malicious user can add newlines to their input (usually in encoded form) and "inject" those newlines into the returned HTTP response. This capability allows users to work around security headers and HTTP/1.1 framing headers by injecting entirely false responses or other new headers. The injected false responses may also be treated as the response to subsequent requests, which can lead to XSS, cache poisoning, and a number of other flaws. This issue was resolved by adding validation to the HTTPHeaders type, ensuring that there's no whitespace incorrectly present in the HTTP headers provided by users. As the existing API surface is non-failable, all invalid characters are replaced by linear whitespace.

Injection

Improper detection of complete HTTP body decompression SwiftNIO Extras provides a pair of helpers for transparently decompressing received HTTP request or response bodies

CVE-2022-3252 7.5 - High - September 21, 2022

Improper detection of complete HTTP body decompression SwiftNIO Extras provides a pair of helpers for transparently decompressing received HTTP request or response bodies. These two objects (HTTPRequestDecompressor and HTTPResponseDecompressor) both failed to detect when the decompressed body was considered complete. If trailing junk data was appended to the HTTP message body, the code would repeatedly attempt to decompress this data and fail. This would lead to an infinite loop making no forward progress, leading to livelock of the system and denial-of-service. This issue can be triggered by any attacker capable of sending a compressed HTTP message. Most commonly this is HTTP servers, as compressed HTTP messages cannot be negotiated for HTTP requests, but it is possible that users have configured decompression for HTTP requests as well. The attack is low effort, and likely to be reached without requiring any privilege or system access. The impact on availability is high: the process immediately becomes unavailable but does not immediately crash, meaning that it is possible for the process to remain in this state until an administrator intervenes or an automated circuit breaker fires. If left unchecked this issue will very slowly exhaust memory resources due to repeated buffer allocation, but the buffers are not written to and so it is possible that the processes will not terminate for quite some time. This risk can be mitigated by removing transparent HTTP message decompression. The issue is fixed by correctly detecting the termination of the compressed body as reported by zlib and refusing to decompress further data. The issue was found by Vojtech Rylko (https://github.com/vojtarylko) and reported publicly on GitHub.

Infinite Loop

A program using swift-corelibs-foundation is vulnerable to a denial of service attack caused by a potentially malicious source producing a JSON document containing a type mismatch

CVE-2022-1642 7.5 - High - June 16, 2022

A program using swift-corelibs-foundation is vulnerable to a denial of service attack caused by a potentially malicious source producing a JSON document containing a type mismatch. This vulnerability is caused by the interaction between a deserialization mechanism offered by the Swift standard library, the Codable protocol; and the JSONDecoder class offered by swift-corelibs-foundation, which can deserialize types that adopt the Codable protocol based on the content of a provided JSON document. When a type that adopts Codable requests the initialization of a field with an integer value, the JSONDecoder class uses a type-erased container with different accessor methods to attempt and coerce a corresponding JSON value and produce an integer. In the case the JSON value was a numeric literal with a floating-point portion, JSONDecoder used different type-eraser methods during validation than it did during the final casting of the value. The checked casting produces a deterministic crash due to this mismatch. The JSONDecoder class is often wrapped by popular Swift-based web frameworks to parse the body of HTTP requests and perform basic type validation. This makes the attack low-effort: sending a specifically crafted JSON document during a request to these endpoints will cause them to crash. The attack does not have any confidentiality or integrity risks in and of itself; the crash is produced deterministically by an abort function that ensures that execution does not continue in the face of this violation of assumptions. However, unexpected crashes can lead to violations of invariants in services, so it's possible that this attack can be used to trigger error conditions that escalate the risk. Producing a denial of service may also be the goal of an attacker in itself. This issue is solved in Swift 5.6.2 for Linux and Windows. This issue was solved by ensuring that the same methods are invoked both when validating and during casting, so that no type mismatch occurs. Swift for Linux and Windows versions are not ABI-interchangeable. To upgrade a service, its owner must update to this version of the Swift toolchain, then recompile and redeploy their software. The new version of Swift includes an updated swift-corelibs-foundation package. Versions of Swift running on Darwin-based operating systems are not affected.

Incorrect Type Conversion or Cast

A program using swift-nio-http2 is vulnerable to a denial of service attack

CVE-2022-0618 7.5 - High - March 10, 2022

A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HTTP/2 frame. This vulnerability is caused by a logical error when parsing a HTTP/2 HEADERS or HTTP/2 PUSH_PROMISE frame where the frame contains padding information without any other data. This logical error caused confusion about the size of the frame, leading to a parsing error. This parsing error immediately crashes the entire process. Sending a HEADERS frame or PUSH_PROMISE frame with HTTP/2 padding information does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted frame. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the frame in memory-safe code, so the crash is safe. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.

A program using swift-nio-http2 is vulnerable to a denial of service attack caused by a network peer sending ALTSVC or ORIGIN frames

CVE-2022-24668 7.5 - High - February 09, 2022

A program using swift-nio-http2 is vulnerable to a denial of service attack caused by a network peer sending ALTSVC or ORIGIN frames. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. This vulnerability is caused by a logical error after frame parsing but before frame handling. ORIGIN and ALTSVC frames are not currently supported by swift-nio-http2, and should be ignored. However, one code path that encounters them has a deliberate trap instead. This was left behind from the original development process and was never removed. Sending an ALTSVC or ORIGIN frame does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send one of these frames. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send these frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself. This is a controlled, intentional crash. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.

A program using swift-nio-http2 is vulnerable to a denial of service attack

CVE-2022-24667 7.5 - High - February 09, 2022

A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HPACK-encoded header block. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. There are a number of implementation errors in the parsing of HPACK-encoded header blocks that allow maliciously crafted HPACK header blocks to cause crashes in processes using swift-nio-http2. Each of these crashes is triggered instead of an integer overflow. A malicious HPACK header block could be sent on any of the HPACK-carrying frames in a HTTP/2 connection (HEADERS and PUSH_PROMISE), at any position. Sending a HPACK header block does not require any special permission, so any HTTP/2 connection peer may send one. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted field block. The impact on availability is high: receiving a frame carrying this field block immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted field blocks, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the field block in memory-safe code and the crash is triggered instead of an integer overflow. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle all conditions in the function. The principal issue was found by automated fuzzing by oss-fuzz, but several associated bugs in the same code were found by code audit and fixed at the same time

Integer Overflow or Wraparound

A program using swift-nio-http2 is vulnerable to a denial of service attack

CVE-2022-24666 7.5 - High - February 09, 2022

A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HTTP/2 frame. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. This vulnerability is caused by a logical error when parsing a HTTP/2 HEADERS frame where the frame contains priority information without any other data. This logical error caused confusion about the size of the frame, leading to a parsing error. This parsing error immediately crashes the entire process. Sending a HEADERS frame with HTTP/2 priority information does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted frame. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the frame in memory-safe code, so the crash is safe. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.

A stack overflow issue existed in Swift for Linux

CVE-2020-9861 7.5 - High - November 02, 2020

A stack overflow issue existed in Swift for Linux. The issue was addressed with improved input validation for dealing with deeply nested malicious JSON input.

Memory Corruption

In SwiftNIO Extras before 1.4.1

CVE-2020-9840 7.5 - High - May 11, 2020

In SwiftNIO Extras before 1.4.1, a logic issue was addressed with improved restrictions.

The issue was addressed by signaling that an executable stack is not required

CVE-2019-8849 9.8 - Critical - December 18, 2019

The issue was addressed by signaling that an executable stack is not required. This issue is fixed in SwiftNIO SSL 2.4.1. A SwiftNIO application using TLS may be able to execute arbitrary code.

In SwiftNIO before 1.8.0

CVE-2018-4281 9.8 - Critical - January 11, 2019

In SwiftNIO before 1.8.0, a buffer overflow was addressed with improved size validation.

Buffer Overflow

An issue was discovered in certain Apple products

CVE-2018-4220 8.8 - High - June 08, 2018

An issue was discovered in certain Apple products. Swift before 4.1.1 Security Update 2018-001 is affected. The issue involves the "Swift for Ubuntu" component. It allows attackers to execute arbitrary code in a privileged context because write and execute permissions are enabled during library loading.

Incorrect Permission Assignment for Critical Resource

Stay on top of Security Vulnerabilities

Want an email whenever new vulnerabilities are published for Apple Swift or by Apple? Click the Watch button to subscribe.

Apple
Vendor

Apple Swift
Product

subscribe