MAL-BINARY Committed Native Binaries and Executable Blobs
Source-reading scanners silently skip any file that is not valid UTF-8, which makes a committed executable a real blind spot. The xz-utils backdoor (CVE-2024-3094) rode in as exactly this shape: an opaque binary blob committed into a source tree under the cover of a test fixture, where no source-reading tool would look at it.
What Vulkro detects
MAL-BINARY-001 (Medium) reads bytes rather than text. It opens each file, reads only the leading header window, and matches the magic bytes of executable and code-loadable formats: ELF (\x7fELF), Mach-O (0xFEEDFACE / 0xFEEDFACF, either endian), a Mach-O fat / universal binary (0xCAFEBABE), PE or DOS (MZ), and WebAssembly (\x00asm). It also flags by extension the native module formats a runtime will load directly: .node, .so, .dylib, and .dll.
False-positive discipline: it fires only on executable or code-loadable formats. Images, fonts, archives, and other benign binary assets are not flagged, because many repositories legitimately vendor a .png or a .woff.
Severity is Medium, not High, because repositories do legitimately vendor binaries. The finding says an opaque executable exists where the source scanners cannot see it, and nothing about what the blob contains: the detector never certifies a blob safe.
Remediation. Establish where the binary came from and whether it can be rebuilt from source in this repository. Prefer a build step or a checksum-pinned release artifact over a committed executable, and treat an unexplained binary in a source package as a reason not to run the build.
See also
- Confidence model - what
High,Medium, andLowmean for findings in this category. - Safety - what Vulkro does and does not access on your machine.
References
This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.