/python-code-injection

name: python-code-injection
description: >
  Exploit Python eval(), exec(), and compile() injection in web applications.
  Distinct from OS command injection (shell operators) and SSTI (template
  engines) — this targets direct Python code evaluation of user input.
keywords:
  - python eval injection
  - eval() exploit
  - exec() injection
  - python code injection
  - expression injection
  - Searchor exploit
  - python sandbox escape
  - __import__ injection
  - __subclasses__ exploit
  - __builtins__ bypass
  - compile() injection
  - python RCE
tools:
  - burpsuite
  - curl
opsec: medium

Python Code Injection

You are helping a penetration tester exploit Python code injection via eval(), exec(), or compile(). The target application passes user-controlled input to a Python code evaluation function without proper sanitization. The goal is to execute arbitrary Python code and escalate to OS command execution. All testing is under explicit written authorization.

**This is NOT OS command injection.** Shell operators (`;`, `|`, `&&`) do not work because the injection context is a Python interpreter, not a shell. You must write valid Python expressions or statements.

**This is NOT SSTI.** Template injection targets Jinja2/Twig/Freemarker rendering engines. This skill targets direct eval()/exec() calls in application code. If `{{7*7}}` returns `49`, route to **ssti-jinja2** or **ssti-twig** instead. If `{{7*7}}` returns literally but `7*7` evaluates, you're in the right place.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[python-code-injection] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

Scope Boundary

This skill covers Python code injection through eval(), exec(), and compile() — from confirming the injection through achieving OS command execution. When you reach the boundary of this scope — whether through completing your methodology or discovering findings outside your domain — **STOP**.

Do not load or execute another skill. Do not continue past your scope boundary. Instead, return to the orchestrator with:

• What was found (vulns, credentials, access gained)
• Context to pass (injection point, target, working payloads, etc.)

The orchestrator decides what runs next. Your job is to execute this skill thoroughly and return clean findings.

**Stay in methodology.** Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise attacks, write custom exploit code, or apply techniques from other domains. The orchestrator will provide specific guidance or route to a different skill.

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• A parameter that gets passed to Python eval(), exec(), or compile()
• Common vulnerable patterns: search engines (Searchor), calculators, query

builders, dynamic filters, format string handlers, custom DSLs backed by eval

• Knowledge of the injection context (string argument, numeric, f-string, etc.)

Step 1: Assess

If not already provided, determine:

1. **Injection function** — eval() (expressions only) vs exec() (statements) vs compile() (either) 2. **Injection context** — is input placed inside a string literal, as a bare argument, in an f-string, or concatenated into code? 3. **Visible or blind** — is the return value of eval() reflected in the response, or is this blind (side-channel only)? 4. **Sanitization** — are any characters filtered? (quotes, parens, underscores, dots, brackets)

Distinguishing eval() from exec()

| Feature | eval() | exec() | |---------|--------|--------| | Accepts | Expressions only | Statements and expressions | | Returns | Expression result | None | | `import os` | SyntaxError | Works | | Multi-line | No (single expression) | Yes | | Assignment (`x=1`) | SyntaxError | Works |

If you can execute `__import__('os')` but not `import os`, it's likely eval(). If both work, it's likely exec() or compile().

Common Vulnerable Patterns

**Pattern 1: String interpolation into eval** (most common)

# Application code:
result = eval(f"func('{user_input}')")
# Injection: break out of the string, inject code, comment out remainder

**Pattern 2: Direct eval of parameter**

# Application code:
result = eval(request.args.get('expr'))
# Injection: any Python expression works directly

**Pattern 3: exec() with string building**

# Application code:
exec(f"variable = '{user_input}'")
# Injection: break out of string, inject statements

**Pattern 4: eval() in ORM/filter context**

# Application code:
query = eval(f"Model.objects.filter({user_input})")
# Injection: close the filter, chain arbitrary code

Skip assessment if context was already provided by web-discovery or the orchestrator.

Step 2: Confirm Injection

Quick Confirmation Probes

Test these in order — the first one that returns an evaluated result (not a literal echo) confirms eval() injection:

# Arithmetic — most universal
7*7
str(7*7)

# String operations
'A'*3
str(type(1))

# Python builtins
str(True)
str(len('test'))

**Expected responses for