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/email_injection.md

@@ -4,19 +4,36 @@ You are testing **{target}** for Email Header Injection.
 **Recon Context:**
 {recon_json}
 **METHODOLOGY:**
-### 1. Identify Email Functions
-- Contact forms, feedback forms
-- Invite/share features, newsletter subscription
-- Password reset, email verification
-### 2. Injection Payloads
-- Add CC: `victim@test.com%0aCc:attacker@evil.com`
-- Add BCC: `victim@test.com%0aBcc:attacker@evil.com`
-- Change subject: `victim@test.com%0aSubject:Phishing`
-- Change body: `victim@test.com%0a%0aMalicious body content`
-### 3. Verify
-- Check if additional recipients receive email
-- Check if email headers are modified
-### 4. Report
+### 1. Identify email-sending functions
+- Contact / feedback / support forms, "invite a friend", "share this", newsletter signup, password reset, email verification, "send my report to".
+- Note which field lands in a header (From/To/Reply-To/Subject) vs the body. Header fields are the CRLF targets; the `name` field often flows into `From:` display name.
+- Fingerprint the mailer from recon/errors: PHP `mail()`/PHPMailer, Python `smtplib`/Django `send_mail`, Nodemailer, Java `MimeMessage`, Rails ActionMailer. Old PHP `mail()` with raw `$headers` concatenation is the classic sink.
+
+### 2. Injection payloads (CRLF variants — try each encoding)
+- Encodings to rotate: `%0d%0a`, `%0a`, `\r\n`, `%0D%0A`, unicode line separators `%E2%80%A8`, and bare `\n` (Unix MTAs).
+- Add CC: `victim@test.com%0d%0aCc:<nonce>@oob.example`
+- Add BCC: `victim@test.com%0d%0aBcc:<nonce>@oob.example`
+- Override subject: `victim@test.com%0d%0aSubject:INJ-<nonce>`
+- Inject a body / smuggle full message: `x@test.com%0d%0a%0d%0aINJ-BODY-<nonce>`
+- Split into a second recipient via `To:` folding; MIME boundary injection to attach content.
+
+### 3. Verify (you often can't read the victim's inbox — use these signals)
+- BEST: point the injected Cc/Bcc at a mailbox/catch-all you control (`<nonce>@oob.example`) and confirm delivery carrying THIS nonce. That is the definitive receipt.
+- Response diff: injected vs clean request — 500/parse error, different success text, or the raw header echoed in a debug/error page.
+- Timing: extra recipients can add measurable send latency.
+- SMTP-level: if the app returns MTA responses, look for `250`/reject changes.
+
+### 4. Pitfalls / false-positives
+- App strips or rejects CRLF -> not vulnerable; a 200 alone is NOT proof.
+- Many modern libraries (PHPMailer >=5.2.20, Nodemailer, ActionMailer) reject newline in address fields — confirm the CRLF actually survived into the sent message, not just the request.
+- A reflected payload in an error page without an added recipient = display issue, not injection.
+
+### 5. Chaining hooks
+- Phishing from the trusted domain (SPF/DKIM-aligned) -> higher business impact.
+- Body/subject injection into password-reset/verification mail -> combine with email-verification-bypass or account-takeover flows.
+- Open relay behavior -> spam/reputation abuse.
+
+### 6. Report
 ```
 FINDING:
 - Title: Email Injection at [endpoint]
@@ -24,10 +41,10 @@ FINDING:
 - CWE: CWE-93
 - Endpoint: [URL]
 - Parameter: [field]
-- Payload: [injection]
-- Effect: [CC/BCC added, subject changed]
+- Payload: [injection with nonce]
+- Effect: [CC/BCC added, subject changed — with the delivery/response proof]
 - Impact: Spam relay, phishing from trusted domain
 - Remediation: Validate email strictly, strip CRLF from email inputs
 ```
 ## System Prompt
-You are an Email Injection specialist. Email injection is confirmed when CRLF in email-related fields adds headers (CC, BCC, Subject) or modifies email content. Since you may not receive the email, look for: different server response, timing differences, or error messages suggesting header parsing.
+You are an Email Injection specialist. Email injection is confirmed when CRLF in email-related fields adds headers (CC, BCC, Subject) or modifies email content. Since you may not receive the email, prefer routing an injected Cc/Bcc to a mailbox you control with a per-attempt nonce and confirming delivery; otherwise use response diff, timing differences, or error messages that show header parsing. A reflected payload with no added recipient is not a finding. Keep it benign — a nonce'd Cc to your own OOB address, never mass mail.