Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Malformed key bytes are network-supplied with low complexity and no auth or interaction, and a double-free crash affects only availability, so A:H with C:N/I:N.
Primary rating from Vendor (apple).
CVSS VectorVendor: apple
Lifecycle Timeline
5DescriptionCVE.org
When initializing an RSA public key from DER or PEM bytes throws an error, the EVP_PKEY* is double-freed: first in the catch block, then in the deinit. This can lead to a crash on future memory allocations. This double-free manifests when BoringSSL cannot decode the public key from the bytes provided. This vulnerability is addressed in swift-crypto version 4.5.1.
AnalysisAI
Denial of service in Apple's swift-crypto (all versions before 4.5.1) allows remote attackers to crash a process by supplying malformed RSA public key bytes. When BoringSSL fails to decode a DER- or PEM-encoded RSA public key, the underlying EVP_PKEY* is freed twice - once in the error catch block and again during deinitialization - corrupting the allocator and causing a crash on subsequent memory allocations. No public exploit identified at time of analysis; the flaw is memory-safety corruption limited to availability impact (CVSS 7.5).
Technical ContextAI
swift-crypto is Apple's open-source Swift cryptography library that mirrors the CryptoKit API and is backed by BoringSSL for its low-level primitives. The bug is a classic CWE-415 double-free: the RSA public-key initializer wraps BoringSSL's EVP_PKEY structure, and when key decoding fails the pointer is released in the thrown-error handling path but the object's deinitializer also releases the same pointer. Freeing the same heap allocation twice corrupts BoringSSL/allocator metadata, so a later, unrelated allocation trips over the corrupted free list and aborts the process. The trigger is entirely input-driven: any code path that constructs an RSA public key from attacker-influenced DER or PEM bytes that BoringSSL cannot decode.
RemediationAI
Vendor-released patch: swift-crypto 4.5.1 - upgrade the Package.swift dependency pin to 4.5.1 or later and rebuild, as this is the version that fixes the double-free per the advisory. Review the guidance in Apple's GitHub Security Advisory GHSA-8q93-f6xh-4f6f (https://github.com/apple/swift-crypto/security/advisories/GHSA-8q93-f6xh-4f6f). If you cannot upgrade immediately, the actionable compensating control is to validate or constrain RSA public-key input before it reaches swift-crypto - for example, reject or pre-parse untrusted DER/PEM at an application boundary so malformed encodings never hit the vulnerable initializer, or gate the affected endpoint behind authentication to reduce unauthenticated reachability; the trade-off is added parsing logic and the risk that your pre-validation does not catch exactly the malformed inputs BoringSSL rejects, so treat this as temporary until the library is updated.
Same weakness CWE-415 – Double Free
View allSame technique Denial Of Service
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-48288