CWE-1105 describes code that uses machine-dependent functionality without sufficiently isolating it from the rest of the program. Think of byte-order assumptions, word-size assumptions, inline assembly, or calls that only exist on one operating system or chip.
MITRE marks this entry as a quality issue with no direct security implications, and prohibits mapping it to real-world vulnerabilities. It is worth knowing about anyway, because the indirect effect is real.
How it happens
A team writes for one platform. A quick call to a platform-specific API goes into a business logic function because it is convenient. Another one follows. Months later the machine-specific details are spread across dozens of files, with no single place that says what the code assumes about its host.
What an attacker gains
Nothing directly. MITRE's description of the impact is that the issue makes the product harder to port or maintain, which indirectly affects security by making it more difficult or time-consuming to find and fix vulnerabilities. It might also make it easier to introduce vulnerabilities, for instance when a port to a new platform silently breaks an assumption.
How to find it
MITRE notes that static analysis can find some instances. A manual check works too: search for platform-specific headers, conditional compilation blocks, intrinsics and OS-specific calls, and count how many different files contain them. If the answer is nearly all of them, the code is not encapsulated.
How to fix it
The record lists no formal mitigations. A common practice is to put machine-specific code behind a narrow interface in one module, so the rest of the program calls a portable function and only that module knows about the platform. Test that module on every platform you support.
Quick check
Does this weakness lead directly to an exploit?
No. MITRE treats it as a quality issue. Its security cost is indirect, through harder maintenance and review.
