CWE-749 applies when a product offers an API or similar interface to outside actors, and that interface includes a dangerous method that is not properly restricted. It can apply to ActiveX controls, Java functions, IOCTLs and more.
Anyone building a service, plugin host, browser control or driver interface can end up here.
How it happens
MITRE gives two routes. The method was never meant to be exposed to outsiders at all, or it was meant for a limited set of actors, such as one website, and the limit was not enforced.
The record lists CVE-2007-6382, arbitrary Java code execution via an exposed method, and CVE-2007-1112, a security tool whose ActiveX control allowed download or upload of files.
// Vulnerable: a maintenance helper mounted on the public router
app.post("/admin/run", (req, res) => {
res.send(require("child_process").execSync(req.body.cmd));
});
What an attacker gains
Exposing critical functionality gives the attacker the privilege level of that function. The record lists integrity, confidentiality, availability and access control impact, including executing unauthorized code or commands and gaining privileges.
How to find it
MITRE notes static analysis can find some cases by modeling data flow. Add an inventory step: list every route, exported method and registered handler, and mark which ones are dangerous. Compare the list with what you intended to expose.
Click through it at your own pace, or open it full screen.
How to fix it
- Identify all exposed functionality and write down what must be exposed, to whom.
- Sort each item into one of three groups: open to all users, limited to a small privileged set, or never directly reachable.
- Make the code match, using access modifiers such as private and protected where they apply, and not marking ActiveX controls safe for scripting.
- If you must expose a dangerous method, validate every argument, limit it to authorized parties, and defend against the vulnerabilities it could cause.
Why exposure creeps in
Exposure rarely arrives as one bad decision. A debugging endpoint is added for a launch and stays. A method meant to be called by a sibling service sits on a router that outside clients can also reach. A browser control is written for one website and marked safe for scripting, so every website can drive it.
Each of these started with a reasonable purpose, which is why MITRE separates the two cases. In the first, the function was never meant to reach outsiders. In the second, it was meant for a limited set, and the limit was never enforced. Different causes, same result: the caller inherits the power of the function.
Treat the list of exposed functionality as a living document. Review it when routes, exported methods or registered handlers change, and make removing an entry as ordinary as adding one. Anything dangerous that must stay should have authentication, authorization and argument validation of its own, because the network boundary alone will not hold forever.
Quick check
What is the first step before restricting anything?
Inventory. You cannot restrict methods you have not found, so list all exposed functionality first.
