CWE-695, Use of Low-Level Functionality, applies when a product uses low-level functionality that the framework or specification it runs under explicitly prohibits. MITRE's extended description says this can violate the specification in unexpected ways, effectively disabling built-in protection mechanisms, introducing exploitable inconsistencies, or exposing the functionality to attack.
The idea is simple. A framework makes promises, such as managed memory, enforced permissions or controlled lifecycles, on the condition that you stay inside its rules. Step outside and the promises stop.
How it happens
A developer reaches below the framework for speed or convenience. They call a raw interface where a managed one exists, or work around the container that was supposed to supervise the operation. The code works in testing, because nothing visibly breaks. The protection that was silently removed shows up later, as a bypass.
The MITRE record lists no observed CVEs and is not language or technology specific, so the examples here are conceptual only.
What an attacker gains
MITRE's consequence entry is open ended. The impact is whatever the bypassed protection was providing.
How to find it
MITRE notes that static analysis can find some instances by analyzing source or compiled code and modelling data flow and control flow. The practical version is to write down what your framework prohibits and search for those calls. Many frameworks publish such rules, and some analyzers ship rule sets for them. Add the check to CI so the prohibited call fails the build.
How to fix it
Use the framework's supported interface instead. If you truly need the low-level behavior, isolate it in one reviewed module, document why, and test it against the protections it skips. Treat any exception to the rules as a security decision, not a convenience.
Quick check
Why is this weakness hard to notice?
Because the code usually works. What is lost is a protection, and the loss only matters when someone attacks.
