Cybersecurity glossary

What is Code Injection?

Learn what code injection is, how untrusted input becomes executable application logic, how it differs from command and SQL injection, and how to prevent eval-style and dynamic-code risks.

Application securityUpdated August 11, 2026
Also known asDynamic code executionEval injectionScript injection (server-side)

Definition

Code Injection is a vulnerability in which untrusted input is interpreted or compiled as executable application code—via eval, dynamic imports, template engines, expression languages, or similar mechanisms—allowing attackers to run logic with the privileges of the hosting process.

Why code injection matters

Modern applications embed mini-languages everywhere: templates, pricing rules, workflow conditions, search filters, and plugin hooks. When those engines accept raw user strings and execute them, Code Injection turns a configuration feature into remote code execution.

Unlike SQL injection—which speaks to a database—code injection speaks to the application runtime itself. That usually means immediate access to memory, files, environment secrets, and outbound network calls.

How code injection works

1

Find a dynamic execution sink

Locate eval, exec, Function(), expression languages, or templates that compile user input.

2

Supply attacker-controlled logic

Payloads look like formulas, filters, or 'advanced search' syntax the product intentionally exposes.

3

Runtime evaluates the payload

The interpreter cannot distinguish developer code from injected statements.

4

Attacker gains process capability

Read secrets, write files, spawn processes, or pivot deeper into the environment.

Common code injection surfaces

Eval / exec APIs

Direct evaluation of strings built from query params, cookies, or stored rules.

Template engines

Server-side templates that allow expressions or includes from untrusted content.

Expression languages

EL, SpEL, OGNL, MVEL, and similar engines used in filters and access rules.

Dynamic loading

User-influenced class names, module paths, or script URLs loaded and run.

Prevention that works

ControlNotes
Eliminate eval sinksReplace dynamic code with declarative data and fixed handlers
Sandbox or disable code in templatesUse logic-less or strictly sandboxed template modes
Allowlist expressionsIf a formula language is required, parse AST and permit only safe nodes
Separate privilegesRun interpreters in locked-down workers with no secret access
Avoid user-controlled importsNever resolve module/class names from request input
Detect dangerous APIs in CILint and SAST rules for eval, Function, Runtime.exec wrappers
  • Search the codebase for eval, exec, Function(, compile(, and expression-language evaluators.
  • Disable code execution features in templates unless there is a proven business need.
  • If formulas are required, implement an allowlisted AST interpreter—not string eval.
  • Keep rule engines on a separate trust boundary with minimal credentials.
  • Reject stored 'scripts' from end users unless reviewed and signed.
  • Add regression tests that attempt classic RCE payloads on formula and filter fields.
  • Monitor for unexpected child processes spawned by the application runtime.
  • Treat confirmed code injection as critical until containment is verified.

The practical takeaway

Code injection happens when user data becomes application source code. Remove eval-style sinks, sandbox what you cannot remove, and never expose a general-purpose language to untrusted callers.

If a feature needs “custom logic,” ship a constrained DSL—not the host language.

Related security terms

Frequently asked questions

What is code injection in simple terms?

The application takes data from a user and accidentally treats it as source code—so the attacker can make the program run their instructions instead of only processing their data.

How is code injection different from command injection?

Code injection targets the application language or an embedded expression engine (JavaScript eval, Python exec, EL, OGNL). Command injection targets the OS shell or process execution APIs.

Where do code injection bugs usually appear?

Eval of user strings, dynamic require/import paths, unsafe deserialization into executable types, expression-language filters, rule engines, and template features that allow code blocks.

Is XSS a form of code injection?

Cross-site scripting injects code into a browser context. Teams often reserve 'code injection' for server-side or application-runtime execution, but both are injection into an interpreter.

What is the primary defense?

Do not evaluate untrusted strings as code. Use data-only formats, sandboxed expression subsets with allowlists, and safe template modes that disable code execution.

Can a WAF stop code injection?

Signatures may catch obvious payloads, but novel encodings and language-specific tricks bypass filters. Remove the dangerous sink.

Why is this usually critical?

Successful code injection often equals remote code execution with the app’s privileges—secrets access, lateral movement, and full host compromise.

References

Explore authoritative guidance and frameworks related to code injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary