The unofficial Swift Development Environment extension before 2.12.1 for Visual Studio Code allows remote attackers to execute arbitrary code by constructing a malicious workspace with a crafted sourcekit-lsp.serverPath, swift.languageServerPath, swift.path.sourcekite, swift.path.sourcekiteDockerMode, swift.path.swift_driver_bin, or swift.path.shell configuration value that triggers execution upon opening the workspace.

The unofficial SwiftFormat extension before 1.3.7 for Visual Studio Code allows remote attackers to execute arbitrary code by constructing a malicious workspace with a crafted swiftformat.path configuration value that triggers execution upon opening the workspace.

The unofficial SwiftLint extension before 1.4.5 for Visual Studio Code allows remote attackers to execute arbitrary code by constructing a malicious workspace with a crafted swiftlint.path configuration value that triggers execution upon opening the workspace.

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.

This issue was addresses by updating incorrect URLSession file descriptors management logic to match Swift 5.0. This issue is fixed in Swift 5.1.1 for Ubuntu. Incorrect management of file descriptors in URLSession could lead to inadvertent data disclosure.

In APNSwift 1.0.0, calling APNSwiftSigner.sign(digest:) is likely to result in a heap buffer overflow. This has been fixed in 1.0.1.

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.

Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

Some HTTP/2 implementations are vulnerable to ping floods, potentially leading to a denial of service. The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

Some HTTP/2 implementations are vulnerable to a header leak, potentially leading to a denial of service. The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory.