Exposed Dangerous Method or Function

An API or interface exposes a method or function that performs a dangerous operation (arbitrary file access, code execution, direct database queries) to callers who shouldn't have access to it - often left reachable from earlier development or debugging convenience and never locked down for production. Distinct from a specific injection bug: the function itself, called exactly as designed, is the danger.

Confirming a specific method is "dangerous" requires understanding what that particular function actually does once reached - a judgment call about impact that needs the application's specific API surface to be read and understood, not a generic payload.

API surface review - reading available methods/endpoints (including those discovered via API introspection like GraphQL introspection, or client-side JS analysis) and assessing which ones perform sensitive operations that shouldn't be reachable by the calling context.

Tip: This is typically found through installer/updater-specific review — checking exactly how the program resolves library paths, temp file names, and update sources — since the vulnerable behavior is in resolution logic that doesn't show up in normal application testing at all.

Real-World Impact

This family covers a subtle but recurring pattern: a program resolving a name, path, or reference to an actual resource, a file, a library, a function, a URL, in a way an attacker can influence, causing it to load or execute something other than what was intended. Untrusted search-path issues (DLL/library hijacking) let an attacker place a malicious library somewhere earlier in the search order than the legitimate one. Insecure temporary files created predictably or world-writably can be swapped out from under the program that created them. Downloading code without verifying its integrity trusts the delivery channel completely, with no check that what arrived is what was actually published.

The severity ceiling across this family is typically code execution, since the end result of each pattern is the program loading and running something the attacker chose rather than what the developer intended.

These bugs are especially common in installers, updaters, and plugin/extension-loading systems specifically because those components inherently need to resolve and load external code as part of their normal function — which is exactly the operation this whole family exploits.

Prevention and Secure Design

Preventing Exposed Dangerous Method or Function takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Use absolute paths and explicit references, never rely on search-path resolution for anything security-relevant. Load libraries, executables, and includes by fully-qualified path rather than trusting a search order that could be manipulated.

Verify integrity before executing or loading anything obtained externally. A cryptographic signature check on downloaded code, plugins, or updates ensures what arrived is actually what was published, closing off tampering during delivery.

Create temporary files securely. Use the platform's secure temp-file API (which handles unpredictable naming and correct permissions) rather than a predictable name in a world-writable location.

Restrict what a plugin/extension-loading system will load. An explicit allowlist of trusted sources or signed packages prevents the loading mechanism from being pointed at an attacker-supplied alternative.

Audit installers and updaters specifically for this pattern. These components are disproportionately likely to contain this bug family because resolving and loading external code is their core function — review them with that specific risk in mind.