ghostonbutterbread/stored-xss
skills/stored-xss/SKILL.md
Use when attacker-controlled input is saved and rendered later in a profile, comment, title, notification, admin view, export, email, feed, upload metadata, or other stored render surface.
documentation
Updated Jun 6, 2026
$ install --global
skillsauthnpx skillsauth add ghostonbutterbread/bug-bounty-harness stored-xssInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 6, 2026, 2:27 AM51.0s1 file scanned
SKILL.md
- name:
- stored-xss
- description:
- Use when attacker-controlled input is saved and rendered later in a profile, comment, title, notification, admin view, export, email, feed, upload metadata, or other stored render surface.
Stored XSS
Use this lane when the interesting behavior is persistence plus later rendering.
Stored XSS work is two problems: finding the write primitive and finding the render context. Treat both as first-class evidence.
Load First
xsslive-testing-policyaccount-testing-policybefore creating accounts or mutating owned statewaf-live-policyif filtering or sanitizer behavior mattersskills/xss/references/payload-selection.md
Ownership And Blast Radius
Use owned, disposable, or explicitly approved resources.
Allowed examples:
- owned profile fields
- owned draft/private documents
- owned comments between owned accounts
- owned uploads
- owned notification/invite/comment flows where all recipients are owned
Ask before anything that can hit staff, moderation, support, marketplace/app review, real users, public feeds, email/SMS/push to non-owned recipients, or hard-to-clean state.
Discovery Targets
High-signal stored fields:
- title, name, display name, username
- profile bio/about fields
- comments, reviews, captions, descriptions
- file names and upload metadata
- notification title/body fields
- team/workspace/project names
- saved addresses, labels, tags
- chat/message content between owned accounts
- admin/support/moderation views
- exports, PDFs, emails, and receipts
Testing Loop
- Write an inert canary first.
- Verify persistence at the storage point.
- Find every render point that shows the canary.
- Classify each render context separately.
- Replace the canary with the smallest context-matched payload only when the resource, viewer, and cleanup path are owned/approved.
- Verify in the render location with browser or target-owned checker.
- Restore/delete/privatize the owned test state when possible.
Payload Strategy
Stored payloads should be deliberate. A noisy payload can affect future agents, public surfaces, notifications, or moderation queues.
Use a progression:
- inert canary
- context probe containing safe delimiters
- low-noise execution payload
- mutation/bypass families only after render context is known
Good stored XSS often comes from downstream consumers:
- safe-looking title becomes notification HTML
- escaped profile field becomes admin
innerHTML - filename becomes download page attribute
- markdown becomes sanitized HTML with a bypass
- JSON field becomes email/template HTML
- mobile and desktop render differently
Multi-Account Proof
For cross-account stored XSS:
- identify sender and recipient aliases
- confirm both are owned
- keep raw cookies/tokens out of notes
- record only account aliases and request metadata
- stop after minimum proof of execution or reachability
Cleanup
Record:
- object/resource ID or alias
- original value when relevant
- payload value class, not raw secrets
- cleanup action taken
- cleanup verification status
If cleanup fails, note it loudly in the run summary.
Report
Include:
- write endpoint and field
- render endpoint/view
- viewer role/account
- stored context
- payload and mutation family
- execution proof
- interaction needed
- blast-radius assessment
- cleanup status
Related Skills
ghostonbutterbread/reflected-xss
content-media
VerifiedTrustedCommunity
Use when attacker-controlled input appears in the immediate HTTP response or browser-rendered page and needs reflected XSS context classification, payload selection, mutation, and browser verification.
SKILL.mdUpdated Jun 6, 2026
ghostonbutterbread/pwnfox
data-ai
VerifiedTrustedCommunity
Use when inspecting proxy traffic from PwnFox-profiled browser sessions, filtering Caido/Burp/proxy history by X-PwnFox-Color, or interpreting user phrases like 'Red session' as a distinct browser/auth/profile lane.
SKILL.mdUpdated Jun 6, 2026
ghostonbutterbread/skills/lfi
tools
VerifiedTrustedCommunity
# LFI — Local File Inclusion Bypass ## What It Does Tests LFI bypass techniques: path traversal, null bytes, wrappers, log poisoning. Load `general-security-testing-policy`, `live-testing-policy`, and `injection-testing-policy` before live testing. For file/path sinks, absence of an immediate file read or response delta is not a stop reason by itself; use the policy to reason about path normalization, extension allowlists, wrappers, encoding, parser differences, and stack-specific proof ladder
SKILL.mdUpdated Jun 6, 2026
ghostonbutterbread/dom-xss
tools
VerifiedTrustedCommunity
Use when XSS depends on browser-side sources and sinks such as URL/query/hash, router state, local/session storage, cookies, postMessage, DOM parsing, framework render paths, or client-side sanitizer behavior.
SKILL.mdUpdated Jun 6, 2026