DigiD for macOS EUVD-2026-98312

Exploitation requires that the attacker ALREADY has local, user-level code execution on the same macOS host as the victim's DigiD installation (PR:L, AV:L) - this is a capability-escalation primitive, not an initial-access bug. The specific enabling condition is that the macOS DigiD app binary is NOT signed with the Hardened Runtime hardening flag, which allows the loader to honor the DYLD_INSERT_LIBRARIES environment variable and inject an attacker-controlled dylib into the process. Limiting factors: no remote vector, no privilege escalation beyond the app's own context (S:U), no availability impact, and the attacker must be able to launch or influence the launch environment of the DigiD process; a patched (Hardened-Runtime-signed) build from the vendor fully blocks the dylib-injection path.

This is a genuine but access-gated local privilege/capability escalation, not a mass-exploitation priority. The provided CVSS:3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 7.1 HIGH) is internally consistent with the description: exploitation is LOCAL (AV:L) and requires the attacker to ALREADY possess local user-level code execution (PR:L), so the missing Hardened Runtime flag is an escalation-of-capability primitive rather than an initial-access vector. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this is 'no public exploit identified at time of analysis' - exploitation would be targeted, not widespread. The high C:H/I:H reflects that a loaded dylib gains the DigiD process's identity data and cryptographic capabilities, which is serious for an identity app, but A:N (no availability impact) and the local-only vector keep real-world urgency moderate. Note a terminology conflict to verify: the input Tags list 'RCE' (Remote Code Execution), yet the CVSS vector and description are unambiguously LOCAL (AV:L, 'a local process', 'local user-level code execution') - this is NOT remotely exploitable, and that tag should not drive prioritization.

An attacker who already has unprivileged code execution on a macOS machine (e.g., via malware or a separate foothold) sets DYLD_INSERT_LIBRARIES to point at a malicious dylib and launches the DigiD app, which-lacking Hardened Runtime-loads the attacker's library into its address space. The injected code then runs with the app's identity, reading DigiD data and abusing its cryptographic capabilities. No public exploit code is identified at time of analysis, though the DYLD_INSERT_LIBRARIES technique is well-documented and trivial to implement.