What is the CVSS score of EUVD-2026-48288?

EUVD-2026-48288 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Which versions of swift-crypto are affected by EUVD-2026-48288?

Swift-crypto before version 4.5.1 contains a denial-of-service vulnerability allowing remote attackers to crash applications processing RSA key operations.. A patch is available.

How to fix or mitigate EUVD-2026-48288?

Within 24 hours, inventory all systems and applications running swift-crypto and assess their operational criticality; notify incident response and DevOps teams. Within 7 days, deploy swift-crypto version 4.5.1 to non-production environments (staging, development, testing) and execute complete application test suites to validate functionality. Within 30 days, complete production deployment of swift-crypto 4.5.1 across all affected systems and verify via availability monitoring that no unexpected application crashes occur post-deployment.

swift-crypto EUVD-2026-48288

| CVE-2026-43823 HIGH

Double Free (CWE-415)

2026-07-23 apple

Denial Of Service Apple Swift Crypto

7.5

CVSS 3.1 · Vendor: apple

Severity by source

Vendor (apple) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Red Hat

6.2 MEDIUM

qualitative

Primary rating from Vendor (apple).

CVSS VectorVendor: apple

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 23, 2026 - 19:24 vuln.today

CVSS changed

Jul 23, 2026 - 19:23 NVD

7.5 (HIGH)

Patch available

Jul 23, 2026 - 16:03 EUVD

CVE Published

Jul 23, 2026 - 14:33 cve.org

UNKNOWN (no severity yet)

CVE Published

Jul 23, 2026 - 14:33 cve.org

HIGH 7.5

DescriptionCVE.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.