Open the
evidence.

Unauthenticated code execution in the template handler

Illustrative report for the fictional application app.example. The requests and server observations demonstrate the evidence format.

Description and preconditions

POST /api/render/preview is reachable without a session and passes an untrusted template to an unsafe handler. In this scenario, the handler interprets input as executable instructions and performs a controlled action with app-service privileges. The weakness is CWE-94, improper control of code generation. This example is CRITICAL because authentication is not required to reach the application execution context.

Symbolic request

POST /api/render/preview HTTP/1.1
Host: app.example
Content-Type: application/json
X-Demo-Request: RCE/014-A

{
  "template": "[controlled demonstration action]",
  "proofPath": "/tmp/tibex-proof-7f2a",
  "proofToken": "TX-7F2A"
}

# No Authorization header or session cookie.
# Symbolic fixture request; the placeholder is not an exploit payload.

The payload is represented by [controlled demonstration action]. The proofPath and proofToken fields link the request to its proof file.

Application response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "preview_ready",
  "request_id": "RCE/014-A"
}

# This response alone does not establish code execution.

HTTP 200 and status: preview_ready only show that the handler responded. Execution is established by a separate server-side observation of the file and token, not by the response itself.

Independent observation

INDEPENDENT SERVER OBSERVATION
SIMULATED, ISOLATED FIXTURE

Request reference: RCE/014-A
Observer: server-side fixture observer
Execution identity: app-service
Before request: proof file absent
After request: /tmp/tibex-proof-7f2a
Observed file contents: TX-7F2A

The observer reads the file independently of the HTTP response.
This is illustrative evidence, not a live system measurement.

Fresh-session replay

FRESH REPLAY / RCE/014-B
SIMULATED, ISOLATED FIXTURE

Session: new; no cookies or Authorization
Endpoint: POST /api/render/preview

{
  "template": "[controlled demonstration action]",
  "proofPath": "/tmp/tibex-proof-9c31",
  "proofToken": "TX-9C31"
}

INDEPENDENT SERVER OBSERVATION
Execution identity: app-service
Before replay: new proof file absent
After replay: /tmp/tibex-proof-9c31
Observed file contents: TX-9C31

A distinct file and token separate this replay from the first run.
The placeholder is not an exploit payload; no live request was made.

Reproduction steps

1. In the isolated demo environment, start a session without cookies or Authorization. Independently confirm that /tmp/tibex-proof-7f2a is absent.
2. Simulate POST /api/render/preview with the controlled proof-file action. The symbolic placeholder in the published request is not executable by itself.
3. Use a separate server-side observer to record /tmp/tibex-proof-7f2a, contents TX-7F2A and the app-service context. Do not use the HTTP response as evidence of execution.
4. Open a separate fresh unauthenticated session. Replay using the previously absent /tmp/tibex-proof-9c31 and new token TX-9C31; independently confirm their appearance.
5. Preserve the correlated requests and observations, then remove the demonstration proof files from the demo environment.

Confirmed impact and limits

Within this example, an external visitor controls an action performed by app-service: creating the selected proof file with a chosen token. This demonstrates code execution in the application context. Root privileges, container escape, whole-host control, access to other services and data exfiltration are not established and are excluded from the confirmed impact.

Remediation

1. Remove eval, dynamic compilation and other paths that execute untrusted input. Do not pass user-controlled strings into an executable context.
2. Use a safe renderer with a restricted declarative template format, an explicit input schema and permitted operations. Do not expose filesystem, process or network access to templates.
3. Restrict preview access according to the product’s access model. Authorization supplements removal of code execution; it does not replace it.
4. Isolate the renderer, run it with least privilege and limit filesystem, network and resource permissions. Do not grant it unnecessary secrets or main-service privileges.

Retest criteria

1. Neither the original scenario nor a replay with a fresh path and token causes execution: the independent observer finds no proof files or other actions.
2. Untrusted executable constructs are rejected or safely treated as data. Repeat this check for authenticated users who are permitted to preview templates.
3. Normal permitted templates still render correctly. Required access checks and renderer isolation remain effective.

Status: illustrative scenario. No remediation or retest of a live product is claimed.