A newly disclosed memory-safety flaw in Apple’s modern Mach-O archive parser could allow a malicious static library to crash Xcode build tooling or cause limited memory disclosure through build logs.
The issue affects the parser used by Apple’s newer linker, ld-prime, as well as libtool, ranlib, and potentially dyldinfo in current Xcode and Command Line Tools installations.
SecureLayer7 researchers reported the bug to Apple Product Security on May 23, 2026, but said more than 90 days elapsed without a patch or acknowledgment that the flaw would be addressed.
Apple Xcode Mach-O Parser Flaw
The vulnerability resides in macho::Archive::Entry::name(), a routine that strips trailing spaces from the 16-byte ar_name field in Unix ar archive-member headers. Static libraries (.a files) use this archive format to package compiled object files.
The parser uses an unsigned size_t counter and repeatedly decrements it while bytes in the name field contain spaces. A crafted archive member with an all-space name field causes the counter to decrement past zero, wrap to SIZE_MAX, and continue reading backward beyond the beginning of the field.
Instead of rejecting the malformed name, the routine returns a std::string_view with a valid pointer but a nearly maximum-sized length. That corrupted length then propagates through the toolchain to downstream formatting and string-allocation operations.
Researchers demonstrated three outcomes from a small, data-only archive. The malicious library needs no executable code, user interaction, elevated privileges, or authentication; it only needs to be supplied as a build input.
| Affected tool | Observed impact |
|---|---|
ld-prime / ld | asprintf() can invoke strlen() on attacker-influenced data and read beyond the mapped archive, causing a SIGSEGV |
libtool | Construction of a C++ string using the poisoned length can request an impossible allocation and trigger an uncaught std::bad_alloc, terminating with SIGABRT |
ranlib | Because it shares libtool binary behavior, it can follow the same unsafe parsing path |
In a separate proof of concept, the out-of-bounds forward read crossed from the archive mapping into an adjacent executable mapping. The tool reportedly printed several foreign bytes to standard error, creating a limited information-disclosure condition.
SecureLayer7 noted that CI logs are especially sensitive because they are commonly retained, replicated, and made accessible to developers and third-party services. The practical attack vector is a poisoned third-party or transitive .a dependency.
Build systems routinely ingest precompiled static libraries from package registries, vendors, source repositories, and internal artifact stores. A compromised dependency could therefore disrupt local developer builds or unattended CI jobs.
The report identifies Apple’s legacy ld-classic linker as unaffected because it uses older cctools archive-parsing code. The exposure is concentrated in Apple’s newer toolchain, which became the default linker path for arm64, arm64e, and x86_64 builds beginning with Xcode 15.
Mitigations
Organizations should treat externally sourced static archives as untrusted build inputs:
- Pin and verify checksums for prebuilt
.adependencies. - Prefer reproducible builds from reviewed source where feasible.
- Isolate CI workers and limit access to sensitive credentials and production resources.
The flaw highlights how malformed data handled during compilation can become a software-supply-chain security issue, even when the library is never executed.
Detect 58% more threats with fresh intelligence from 16K+ organizations. Integrate TI Feeds in you SOC
