What is Process Control (CWE-114)?

TL;DR: Process Control lets an attacker get an application to load a malicious library or execute an untrusted command by controlling the path/identifier used to locate it; the fix is loading only from fixed, trusted, allowlisted locations.

What is Process Control?

Process Control (CWE-114) is a type of injection vulnerability that occurs when executing commands or loading libraries from an untrusted source or in an untrusted environment causes an application to execute malicious commands (and payloads) on behalf of an attacker. As defined by the MITRE Corporation under CWE-114, and classified by the OWASP Foundation under A05:2025 - Injection, this weakness is a direct child of External Control of File Name or Path (CWE-73) and Improper Input Validation (CWE-20).

Quick Summary

Process Control covers a broader and often subtler attack surface than classic command-string injection: instead of manipulating syntax inside a fixed command, the attacker manipulates which library or executable gets loaded and run in the first place. If a path, filename, or plugin identifier used to locate that code comes from external input, an attacker who can influence it points the application at code they control — no shell metacharacters required.

Jump to: Quick Summary · Process Control Overview · How Process Control Works · Business Impact of Process Control · Process Control Attack Scenario · How to Detect Process Control · How to Fix Process Control · Framework-Specific Fixes for Process Control · How to Ask AI to Check Your Code for Process Control · Process Control Best Practices Checklist · Process Control FAQ · Vulnerabilities Related to Process Control · References · Scan Your Own Site

Process Control Overview

What: External input influences which library or executable an application loads and runs, letting an attacker substitute one they control.

Why it matters: The substituted code runs with the application’s own privileges the moment it’s loaded — this is a direct path to code execution.

Where it occurs: Plugin-loading systems, dynamic library loading, and any feature that executes a command or loads code based on a path or identifier from external input.

Who is affected: Applications that determine what to load or execute using external input without validating it against a trusted, fixed set of options.

Who is NOT affected: Applications that only load libraries or execute commands from fixed, trusted, hardcoded or allowlisted locations.

How Process Control Works

Root Cause

The application determines which library to load or command to execute using external input, without validating that input against a trusted, fixed set of options.

Attack Flow

1. The attacker identifies a feature where external input influences which library or executable gets loaded (e.g. a plugin name, a library path).
2. The attacker places a malicious library or executable at a location the application will search, using the expected name or identifier.
3. The application, trusting the external input, loads and runs that attacker-supplied code.
4. The attacker’s code executes with the application’s own privileges.

Prerequisites to Exploit

• External input influences the path or identifier used to load a library or execute a command.
• The attacker can place a malicious library/executable at a location the application will search or load from.
• The application does not validate the load target against a trusted, fixed allowlist.

Vulnerable Code

import importlib

def load_plugin(plugin_name):
    module = importlib.import_module(f"plugins.{plugin_name}")
    return module.run()

plugin_name comes directly from external input with no validation, so an attacker who can place a file matching an unexpected module path (or exploit Python’s import path resolution) can get arbitrary code loaded and executed.

Secure Code

import importlib

ALLOWED_PLUGINS = {"reporting", "export", "notifications"}

def load_plugin(plugin_name):
    if plugin_name not in ALLOWED_PLUGINS:
        raise ValueError("Unknown plugin")
    module = importlib.import_module(f"plugins.{plugin_name}")
    return module.run()

Only plugin names from a fixed, trusted allowlist can be loaded, so external input can select among known-safe options but can never point the loader at an arbitrary, attacker-supplied module.

Business Impact of Process Control

Confidentiality: Attacker-supplied code loaded via this weakness can read any data reachable by the application process.

Integrity: Attacker-supplied code can modify application data or state once running.

Availability: Attacker-supplied code can crash or disrupt the application, or use it as a foothold for further attacks.

• Full code execution with the application’s own privileges, one of the most severe outcomes any vulnerability can have
• Difficult forensic trail, since the malicious code runs as a normal, trusted part of the application

Process Control Attack Scenario

1. An attacker discovers a plugin system that loads modules by name from external configuration.
2. They gain write access to the plugin directory (via a separate, unrelated upload feature) and place a malicious module named to match an expected plugin identifier.
3. They trigger the application to load that plugin name, and the malicious module executes with the application’s full privileges.
4. The attacker’s code establishes a persistent backdoor disguised as a legitimate plugin.

How to Detect Process Control

Manual Testing

• Identify every place external input influences which library, module, or executable is loaded.
• Confirm whether that input is validated against a fixed, trusted allowlist.
• Test whether an unexpected identifier can cause the application to attempt loading an unintended target.

Automated Scanners (SAST / DAST)

Static analysis can flag dynamic import/library-loading calls built from external input directly in source, while dynamic testing confirms whether an unexpected load target is actually reachable at runtime.

PenScan Detection

PenScan’s scanner engines test inputs that influence library-loading or command-execution paths to confirm whether untrusted sources can be substituted for the intended one.

False Positive Guidance

An application that validates the load identifier against a fixed allowlist before ever constructing the load path is not vulnerable even if it superficially resembles a dynamic-loading sink — confirm the actual validation logic in place before treating it as a real finding.

How to Fix Process Control

• Load libraries and execute commands only from fixed, trusted locations.
• Validate any external input that influences a load target against a hardcoded or allowlisted set of known-safe options.
• Verify code signatures/checksums for loaded libraries as defense-in-depth, layered on top of (not instead of) controlling the load path.
• Apply least-privilege to the process performing dynamic loading, limiting the impact of any successful substitution.

Framework-Specific Fixes for Process Control

• Java: validate class/plugin names against a fixed allowlist before any Class.forName() or ServiceLoader dynamic loading.
• Python: validate module names against a fixed allowlist before any importlib.import_module() call, as shown above.
• Node.js: validate module identifiers against a fixed allowlist before any dynamic require()/import() call.
• .NET: validate assembly names against a fixed allowlist before any Assembly.Load() call, and verify assembly signatures where possible.

How to Ask AI to Check Your Code for Process Control

Process Control Best Practices Checklist

✅ Load libraries and execute commands only from fixed, trusted locations ✅ Validate externally-influenced load identifiers against a hardcoded allowlist ✅ Verify code signatures/checksums for loaded libraries as defense-in-depth ✅ Apply least-privilege to processes performing dynamic loading

Process Control FAQ

How does Process Control let an attacker execute code?

If external input controls which library gets loaded or which command gets executed — for example, a filename or path used to locate a plugin — an attacker can point that input at a malicious library or executable they control, and the application will load and run it directly.

How is Process Control different from OS Command Injection?

OS Command Injection (CWE-78) injects extra syntax into an otherwise-fixed command string; Process Control is broader and covers the application choosing to load an entirely untrusted library or executable in the first place, often via a path or identifier the attacker influences, with no shell syntax injection required at all.

How could this manifest as a plugin-loading vulnerability?

An application that loads plugins by name from a user-writable or externally-influenced directory can be tricked into loading an attacker-supplied library with the expected plugin name, executing its code with the application’s own privileges the moment it loads.

How do I detect this in my own application?

Identify every place external input influences which library, executable, or plugin gets loaded, and confirm whether that input is validated against a trusted, fixed set of options.

How do I fix this correctly?

Load libraries and execute commands only from a fixed, trusted location using a hardcoded or allowlisted identifier — never let external input directly determine the path or name of what gets loaded.

How does code signing help mitigate this risk?

Verifying a library’s digital signature against a trusted publisher before loading it adds a check that an attacker-supplied malicious library, even if it lands in the expected location, would fail — though this should be layered on top of, not instead of, controlling the load path itself.

How can PenScan help find Process Control issues?

PenScan tests inputs that influence library-loading or command-execution paths to confirm whether untrusted sources can be substituted for the intended one.

Vulnerabilities Related to Process Control

References

• MITRE - CWE-114
• OWASP A05:2025 - Injection
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Process Control risks and other issues before an attacker does.