# REPRO-2026-00066: Skipper Lua Filter Arbitrary Code Execution

## Summary
Status: published
Severity: high
Type: security
Confidence: Unknown

## Identifiers
REPRO ID: REPRO-2026-00066
GHSA: GHSA-cc8m-98fm-rc9g


## Package
Name: github.com/zalando/skipper
Ecosystem: go
Affected: Unknown
Fixed: Unknown

## Root Cause
## Summary
Skipper releases prior to v0.23.0 enable inline Lua filters by default (`-lua-sources=inline,file`). Any user able to submit a Lua filter (for example through an Ingress resource) can run arbitrary Lua code inside the Skipper process and access the local filesystem. Our reproduction shows that a crafted inline Lua script can read `/etc/hostname` and leak its contents through Skipper’s logs.

## Impact
- **Component:** `github.com/zalando/skipper` proxy binary
- **Affected Versions:** all versions before v0.23.0 (where Lua is enabled by default)
- **Risk:** High (CVSS 8.8) – attackers can execute arbitrary Lua code, read sensitive files (tokens, secrets), and exfiltrate data via logs or upstream responses. If the Skipper process holds credentials or tokens, they can be stolen.

## Root Cause
Skipper allowed inline Lua scripts to be embedded directly into route definitions and executed without sandboxing. When `-lua-sources` includes `inline` (default before v0.23.0), user-controlled Lua scripts run in the Skipper process with access to the standard Lua IO library. This enables arbitrary file reads/writes and system interaction. The issue was mitigated in v0.23.0 by disabling Lua filters by default (commit `0b52894570773b29e2f3c571b94b4211ef8fa714`).

## Reproduction Steps
1. Run `repro/reproduction_steps.sh` from the workspace root.
2. The script downloads Skipper v0.22.0, writes a malicious inline Lua route that reads `/etc/hostname`, starts Skipper with the route, and triggers it via `curl`.
3. Successful reproduction is evidenced by the Skipper log entry containing `[EXFIL] <hostname>` and the summary message printed by the script. Logs are stored under `logs/`.

## Evidence
- **Logs:**
  - `logs/reproduction.log` – full script run output
  - `logs/skipper_inline.log` – Skipper process logs
  - `logs/exfiltration.txt` – filtered `[EXFIL]` line showing leaked hostname
  - `logs/request.log` – HTTP status (404) from trigger request
- **Key Excerpt:** `logs/exfiltration.txt` contains `Error calling request ... [EXFIL] <hostname>` proving filesystem data leakage.
- **Environment:** `uname -a` → `Linux runsc 4.4.0 ... x86_64 GNU/Linux`

## Recommendations / Next Steps
- Upgrade Skipper to v0.23.0 or later, where Lua filters are disabled by default.
- If Lua scripts are required, explicitly limit `-lua-sources=file` and ensure only trusted scripts are deployed on the filesystem.
- Harden Lua execution by removing IO modules or running in a restricted sandbox, and add automated tests to ensure inline Lua stays disabled unless explicitly allowed.

## Additional Notes
- The reproduction script is idempotent: it reuses downloaded artifacts, stops Skipper between runs, and was executed successfully twice in a row.
- The exploit demonstrates read access; write/execute primitives are also possible via Lua IO APIs under the same configuration.


## Reproduction Details
Reproduced: 2026-01-17T14:24:32.441Z
Duration: 545 seconds
Tool calls: 73
Turns: Unknown
Handoffs: 2

## Timeline (Key Moments)
1. [env_setup] Downloaded vulnerable version (repro)
   The vulnerable version of the software was downloaded for setup and testing.
2. [env_setup] Extracted vulnerable package (repro)
   The downloaded vulnerable package was extracted to prepare the environment.
3. [poc_created] Created exploit payload (repro)
   The exploit code (PoC) was written and saved to trigger the vulnerability.
4. [vuln_triggered] Executed exploit script (repro)
   The exploit script was executed to trigger the vulnerability in the environment.
5. [confirmation] Verified data exfiltration (repro)
   The presence of exfiltrated data in logs confirmed successful exploitation.

## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00066
    pruva-verify GHSA-cc8m-98fm-rc9g


Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00066&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00066/artifacts/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References
- GitHub Advisory: https://github.com/advisories/GHSA-cc8m-98fm-rc9g



## Artifacts
- repro/rca_report.md (analysis, 2909 bytes)
- repro/reproduction_steps.sh (reproduction_script, 4223 bytes)
- bundle/ticket.md (ticket, 2160 bytes)
- logs/exfiltration.txt (other, 425 bytes)
- logs/reproduction.log (log, 1402 bytes)
- logs/request.log (log, 3 bytes)
- logs/skipper_inline.log (log, 2132 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00066
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00066/artifacts/repro/reproduction_steps.sh
- Web: https://pruva.dev/r/REPRO-2026-00066

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://pruva.dev