GNU Binutils CVE-2026-3442

Exploitation requires a victim to locally process a specially crafted malicious XCOFF object file with the BFD linker (ld) - for example linking it during a build. Concrete prerequisites: attacker-controlled object/archive input must reach the linker, and a user or automated process must invoke ld on it (CVSS UI:R, AV:L). Limiting factors: the attack is local-only (no network vector), needs user interaction, and is scoped to the XCOFF code path, so systems that never link XCOFF-format objects are not realistically reachable; no authentication is needed (PR:N) but the attacker cannot trigger it remotely or without the victim's action.

Signals are largely consistent and point to a low-to-moderate real-world priority. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H, base 7.1) describes a local, low-complexity, unauthenticated-but-user-interaction-dependent issue with high confidentiality and availability impact and no integrity impact - typical of a file-parsing memory-safety bug rather than a remotely reachable service flaw. EPSS is 0.01% (2nd percentile), and the vulnerability is not in CISA KEV, so there is no evidence of active or likely imminent exploitation. There is no POC referenced. Practically, the dangerous combination would be a build pipeline, CI runner, or developer linking untrusted object files - a narrower exposure than network-facing software. One note of caution: the CVSS labels C:H, but the description frames disclosure as possible ('may lead to'), so high-confidentiality impact is a conservative upper bound rather than a demonstrated leak. Overall this is a real bug to patch on a normal cadence, not an emergency.

An attacker distributes a malicious precompiled object or static-archive file (e.g., via a compromised dependency or a pull request adding a vendored .o/.a) and waits for a developer or CI runner to link it. When ld parses the crafted XCOFF structures, the out-of-bounds read leaks heap memory into build output or crashes the linker, aborting the build. No public exploit code is identified at time of analysis, and exploitation requires the victim to actively process the file (UI:R).