Share
## https://sploitus.com/exploit?id=5F680821-4270-503D-B3F1-8522B687B7FE
# vuln-chain-spring-boot โ€” a Trivy "green but owned" demo

An interactive terminal demo of **vulnerability chaining**: a container image
that scans **completely clean in Trivy (zero HIGH/CRITICAL)** is still
exploitable, because an attacker chains one *medium*-severity Spring CVE with a
benign-looking *container* misconfiguration. The fix is a **Spring Boot
upgrade**, applied with the **Spring Application Advisor**.

> The point: a green scan is not the same as "safe." You don't need a HIGH CVE
> on the board to be breached โ€” two cheap mediums/misconfigs and a little
> creativity (the kind an AI assistant supplies for free) are enough.

This repo is modeled on
[`saa-cves-2-6-trivy-demo`](../../dashaun-tanzu/saa-cves-2-6-trivy-demo): a
[demo-magic](https://github.com/paxtonhare/demo-magic) `demo.sh` that "types"
each command live.

## The chain

| # | Layer | Weakness | Severity |
|---|-------|----------|----------|
| 1 | **App** | **CVE-2026-22737** โ€” `ScriptTemplateView` (Spring Framework 6.2.16) resolves a user-supplied view name to a file path with no normalization โ‡’ arbitrary file read. | MEDIUM (5.9) |
| 2 | **Container** | Image **runs as root** and **bakes a production secret**. | hardening (not a scanner finding) |

Neither is HIGH. Chained, link 1 reads the file link 2 left on disk โ†’
remote disclosure of `PROD_DB_PASSWORD` / `AWS_SECRET_ACCESS_KEY`, on an image
`trivy image` and `trivy sbom` both call clean.

The vulnerable app lives in its own repo,
[`dashaun/hello-spring-boot-3-4-14`](https://github.com/dashaun/hello-spring-boot-3-4-14);
`demo.sh` clones it.

## What the demo does

1. **Build & scan** the image โ†’ Trivy shows **zero HIGH/CRITICAL** (image *and* SBOM).
2. **Run & exploit** โ†’ `exploit/exploit.py` discloses the baked secret.
3. **Advisor** โ†’ `advisor build-config get` + `advisor upgrade-plan get` diagnose the upgrade.
4. **Upgrade** with `advisor upgrade-plan apply` (no `--squash` โ†’ just the first step, Spring Boot 3.4.x โ†’ 3.5.x), rebuild.
5. **Re-scan & re-exploit** โ†’ scan **still green**, but the exploit now reports **CHAIN BROKEN**.

## Prerequisites

`trivy`, `docker`, `vendir`, `git`, `jq`, `httpie`, `python3`, and the
**Spring Application Advisor** CLI; Java 21 via SDKMAN. Building Spring Boot
3.4.x LTS requires **Spring Enterprise repository** access (usually proxied
through your internal Nexus/Artifactory in `~/.m2/settings.xml`).

```bash
./setup-env.sh   # verify/install prerequisites, vendir sync
```

## Run it

```bash
# direnv auto-loads .envrc; otherwise: source .envrc
./demo.sh
```

Offline / pre-push (clone the app from your local checkout instead of GitHub):

```bash
export APP_GIT_URL="file://$HOME/fun/dashaun/hello-spring-boot-3-4-14"
./demo.sh
```

## Configuration

Knobs at the top of `demo.sh`: `APP_GIT_URL`, `IMAGE`, `CONTAINER`, `PORT`,
`WORKDIR` (the upgrade target is whatever `advisor upgrade-plan apply` lands
on for its first step). `ADVISOR_VERSION` is in `.envrc`; Java/Maven versions
in `.sdkmanrc`.

## Recording

```bash
asciinema rec demo.cast -c ./demo.sh
agg demo.cast demo.gif
```

See `AGENTS.md` for architecture notes and why the upgrade step is pinned.