Preface: App Groups provide the legal doorway for shared access, while libxpc’s path handling acts as the security guard ensuring no one sneaks a forbidden object through that door while it’s open.

Background: Libxpc is a closed-source system library in Apple iOS (and macOS) that powers the XPC (Cross Process Communication) framework. It enables secure, lightweight communication between different applications and system services, allowing processes to share data and perform tasks on behalf of one another. It is critical for app sandboxing, stability, and system security.

In Apple’s iOS, path handling within the libxpc library is a critical mechanism for ensuring that file paths are securely and accurately managed during communication between different processes.

The primary purposes and functions include: Security & Sandbox Enforcement, Privilege Isolation, Safe Resource Sharing, Service Discovery and Vulnerability Mitigation.

Remark: In system operations, CFNetwork frequently utilizes libxpc to execute specific tasks:

• WebKit Networking: When browsers like Safari load pages, they use the com.apple.WebKit.Networking.xpc component to request resources. This involves CFNetwork communicating via XPC.
• Background Transfers: For background downloads or syncs, CFNetwork interacts with system network daemons through XPC connections to maintain the session while the app is suspended.

Vulnerability detail: A path handling issue was addressed with improved logic. This issue is fixed in macOS Tahoe 26.3, macOS Sonoma 14.8.4, iOS 18.7.5 and iPadOS 18.7.5, visionOS 26.3, iOS 26.3 and iPadOS 26.3, Safari 26.3. A remote user may be able to write arbitrary files.

NVD Published Date: 02/11/2026
NVD Last Modified: 02/13/2026

Official announcement: Please refer to the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2026-20660

Preface: V8 is Google’s open-source, high-performance JavaScript and WebAssembly engine, written in C++, that powers Chrome and Node.js by translating JavaScript directly into native machine code. It implements all ECMA-262 ECMAScript standards, including data types, operators, objects, and functions, while optimizing execution via the V8 Ignition interpreter and V8 TurboFan compiler.

Background: In the V8 JavaScript engine, dictionary mode (also known as “slow mode”) is an internal representation for objects where properties are stored and accessed using a hash map-like structure. This mode is less optimized for property access compared to the “fast mode” (where objects are treated like fixed C-style structs) but offers better performance for objects that have their shape (set of properties) change frequently at runtime.

The Assumption: V8 believes the object is still in the “Fast Mode” layout (fixed offset) as seen in your code.

The Reality: Through a specific trick (like adding too many properties or a specific transition), the object has been forced into Dictionary Mode.

The Crash: If V8 fails to “de-optimize” and continues to use the fixed-offset logic on a Dictionary-layout object, it accesses the wrong memory address, leading to Out-of-Bounds (OOB) Access.

Vulnerability details: Inappropriate implementation in V8 in Google Chrome prior to 145.0.7632.159 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)

Official announcement: Please refer to the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2026-3543

Preface: 5G Timing Advance (TA) invocation is a mechanism where the base station (gNB) instructs user equipment (UE) to advance its uplink transmission timing to compensate for signal propagation delays. This synchronization ensures that signals from UEs at different distances arrive at the gNB within the same time slot, preventing interference.

Background: In the 5G NR (New Radio) 4-step RACH (Random Access Channel) procedure, TA (Timing Advance) is a critical parameter provided within Msg2, also known as the Random Access Response (RAR). For NR Random Access Response (Msg2):

RAR payload = exactly 7 bytes (56 bits)

• 12-bit Timing Advance Command
• 27-bit Uplink Grant
• 16-bit Temporary C-RNTI

Plus 1 byte MAC subheader (RAPID)

Total bytes read by UE MAC = 8 bytes per RAR

This is fixed by spec. There is no variable-length TA field in Msg2. The TA length is always 12 bits in RAR

Vulnerability details: CVE-2025-47373. This is a classic case of Type Confusion or an Improper Bounds Check within the firmware’s protocol stack. In the context of Qualcomm modem components (like those in the Snapdragon 8 Gen 3), when the firmware confuses these two differently-sized TA fields, it creates a significant security vulnerability.

Why this constitutes a CVE Vulnerability? If the firmware reuses the same handler or buffer without validating the context (RAR vs. MAC CE), it leads to:

• Integer Overflow/Truncation: Forcing a 12-bit RAR TA (up to 3846) into a logic path or variable expected to be 6-bit (0-63) causes data corruption in the accumulator.
• Buffer Overflow: If the 12-bit data is written into a memory structure (like a bit-field or a small array) designed only for 6-bit values, it will overwrite adjacent memory.
• Out-of-bounds (OOB) Write: In the Snapdragon scheduling logic, TA values are often used to calculate offsets in timing tables. An unvalidated 12-bit value can cause a pointer to point outside the intended buffer.

Official announcement: Please refer to the link for details –

https://docs.qualcomm.com/securitybulletin/march-2026-bulletin.html

Preface: Qualcomm’s pVM (Protected Virtual Machine) refers to the secure, isolated virtual machine environment supported by the Gunyah hypervisor. PVMFW (pVM Firmware) is the specific binary code (pvmfw.bin) executed first within a pVM to bootstrap secure boot, validate the environment, and derive unique secrets for that specific guest. In short, pVM is the container, while pvmfw is the secure bootloader for that container.

Background: To “read the memory” of a Microdroid pVM from the host, you cannot bypass the hypervisor’s isolation. Instead, you must use Binder RPC (over virtio-vsock) to request data from a service running inside the pVM. Qualcomm’s sensitive keys (such as encryption keys and passwords) are typically stored in its Trusted Execution Environment (TEE) or a dedicated RPMB (Replay Protected Memory Block) partition. The RPMB is a hardware partition on the storage chip. It is managed and “owned” by the TEE (Secure World), while the EL1 Kernel and EL2 Hypervisor serve only as communication bridges for data transit.

Remark: Refer to the attached diagram, the AIDL code design follows the standard RPC (Remote Procedure Call) pattern. The fundamental “design limitation” here is that the Guest (Microdroid) must trust the Hypervisor (EL2) to enforce the boundaries.

If CVE-2025-47378 is present:

1.Your readData function is “truthful” and only returns 1024 bytes.

2.However, the Host app uses the Hypervisor flaw to read the other memory in your pVM where your actual secrets (keys, sensitive processing) might be stored.

Vulnerability details: Cryptographic Issue when a shared VM reference allows HLOS to boot loader and access cert chain.

Official announcement: Please refer to the link for details – https://docs.qualcomm.com/product/publicresources/securitybulletin/march-2026-bulletin.html

Preface: In iOS development, CVE-2026-20674 relates to a security vulnerability where sensitive information could potentially be accessed through Accessibility services while the device is locked.

Background: UIApplication.shared.isProtectedDataAvailable

impacts the iOS lockscreen because it directly reflects whether user-encrypted data (Keychain, files) is accessible based on the device’s lock status. When locked, this returns false, causing apps launched in the background (e.g., via notifications or prewarming) to fail to read sensitive data, potentially leading to incorrect states or user logouts. 

Key reasons for the impact:

• Encrypted Data Lock: Files protected with NSDataWritingFileProtectionComplete or NSDataWritingFileProtectionCompleteUnlessOpen are inaccessible until the user unlocks the device.
• Background Launch Failures: If an app is launched in the background (e.g., notification, Live Activity) while the screen is locked, attempts to read credentials from the Keychain or files will return nil, potentially causing the user to be signed out.
• State Corruption: Initializing data or reading from UserDefaults while the device is locked might read empty/default values, allowing the app to incorrectly overwrite existing secure data. 

Vulnerability details: A privacy issue was addressed by removing sensitive data. This issue is fixed in iOS 26.3 and iPadOS 26.3. An attacker with physical access to a locked device may be able to view sensitive user information.

Official announcement: Please refer to the link for details.

https://nvd.nist.gov/vuln/detail/CVE-2026-20674

Preface: SPD (Serial Presence Detect) metadata is not used by CPU or GPU manufacturers for the processors themselves, but it is an industry-standard requirement for the memory modules (RAM) that these processors depend on.

Background: DIMM Serial Presence Detect (SPD) protects Ring 0 by ensuring the BIOS/UEFI correctly identifies memory characteristics (timings, voltage, size) during POST. By providing accurate data, it prevents misconfiguration that could lead to memory corruption, stability issues, or exploitation of low-level system management mode (SMM). Properly locked SPD protects against malicious tampering that could bypass memory protections.

Ref: AMD EPYC “Genoa” is the codename for AMD’s 4th generation server processors, built on the Zen 4 microarchitecture and using a 5nm manufacturing process. Compared to its predecessor, Milan, Genoa increases the maximum core count to 96 and is the first to introduce DDR5 memory and PCIe 5.0 support, targeting the data center, cloud computing, and high-performance computing (HPC) markets.

Vulnerability details: CVE-2024-36354 Improper input validation for DIMM serial presence detect (SPD) metadata could allow an attacker with physical access, ring0 access on a system with a non-compliant DIMM, or control over the Root of Trust for BIOS update, to bypass SMM isolation potentially resulting in arbitrary code execution at the SMM level.

Additional: This is not a substitute for the vendor fix. If the vulnerable code is inside proprietary AGESA/PI binaries, you still need the patched package. So the core issue is validation logic inside the firmware boot flow handling SPD data.

Official announcement: Please refer to the link for more details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3014.html

Preface: AMD EPYC processors (including the latest 9005 Series) fully incorporate an I/O Memory Management Unit (IOMMU). In AMD’s architecture, this technology is known as AMD-Vi (AMD I/O Virtualization). It serves as a foundational component for the hardware-level security and isolation.

Background: In a virtualized environment, the IOMMU (AMD-Vi) acts as the essential bridge between “physical hardware” and the Guest VM. When you enable hardware passthrough, the IOMMU functions as both a hardware-level “translator” and a “security guard.” The following details how IOMMU participates in the operation of guest virtual machines:

About Memory Address Mapping (DMA Remapping)

This is the most critical function of the IOMMU.

• The Problem: A Guest VM operates using Guest Physical Addresses (GPA), which are virtualized. However, a physical device (like a NIC or GPU) requires Host Physical Addresses (HPA) to function.
• The Solution: When a driver inside the Guest VM commands a device to perform a Direct Memory Access (DMA), the IOMMU intercepts the request. It uses a translation table (provided by the hypervisor) to instantly map the GPA to the HPA. This allows the Guest VM to interact with hardware at full speed without knowing the host’s actual memory layout.

Vulnerability details: CVE-2023-31364  Improper handling of direct memory writes in the input-output memory management unit could allow a malicious guest virtual machine (VM) to flood a host with writes, potentially causing a fatal machine check error resulting in denial of service.

The above details and VFIO code demonstrate (refer to attached diagram) the mechanism allowing a virtual machine to directly access hardware via IOMMU mapping, which is essential for launching the CVE-2023-31364 attack. The vulnerability occurs when a guest utilizes this direct path to send malicious, high-volume write requests, causing a flawed IOMMU to trigger a fatal Machine Check Error (MCE) and crash the host.

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7059.html