# Bug Bounty Field Manual

Reviewed 14 September 2026. Internal references lead to the corresponding chapter below; use the website for section-level navigation.

<a id="page-start"></a>

# Bug Bounty Field Manual

Bug bounty work is a sequence of decisions: establish permission, choose a reachable security boundary, construct a test, prove the impact, and make the finding reproducible. Tools support that sequence. A large asset list or scanner output is an input to research, not evidence that a vulnerability exists.

This manual covers the major program models and technical scope families: OSS repositories, self-hosted products, web applications, APIs, network services, mobile, desktop and extensions, cloud and containers, AI systems, smart contracts, and embedded devices. Individual programs can define unusual combinations; their exact written policy takes precedence over any generic category here.

## Choose your entry point

| Need | Open | Result to produce |
|---|---|---|
| Decide what to learn and in what order | [Roadmap](#page-roadmap) | A realistic rotation of lab work and live research |
| Find an eligible program | [Platforms and participation](#page-platforms) | A shortlist with permission, reward, and access checked separately |
| Interpret a repo, wildcard, app ID, chain address, or hardware scope | [Scope model](#page-scope) | A recorded authorization decision for each asset and action |
| Start a hunt | [Operating playbook](#page-operations) | A mapped boundary, test hypothesis, and evidence trail |
| Review code or reproduce a product bug locally | [OSS and self-hosted](#page-oss) | A versioned, reachable, reproducible finding |
| Investigate an application or API | [Web and API](#page-web-api) | A controlled comparison of expected and actual behavior |
| Review network services and appliances | [Network services](#page-network) | A service-level finding with exact transport, identity and impact |
| Test device applications | [Mobile](#page-mobile) / [Desktop and extensions](#page-desktop) | A release-relevant crossing of an OS, process, or account boundary |
| Examine infrastructure or agent systems | [Cloud](#page-cloud) / [AI and MCP](#page-ai) | A demonstrated identity, tenant, resource, or tool-authority failure |
| Investigate a protocol or physical product | [Web3](#page-web3) / [Hardware and firmware](#page-hardware) | An invariant or trust-boundary failure in a reproducible local setup |
| Run preflight or prepare a submission | [Master checklist](#page-checklist) | A reviewed, minimal, policy-compliant report |
| Recall commands and evidence requirements | [Cheat sheet](#page-cheat-sheet) | The next bounded action, with prerequisites |
| Reuse working records | [Templates](#page-templates) | Scope, hypotheses, coverage, and report records |

## Four distinct working aids

| Artifact | Question it answers | How to use it |
|---|---|---|
| Roadmap | What capability should I build next? | Follow milestone gates; extend a phase if its output is not reproducible |
| Playbook | How do I investigate this kind of target? | Follow decisions and branch on findings; do not run every tool blindly |
| Checklist | What must I verify or explicitly mark inapplicable? | Record pass, finding, blocked, untested, or not applicable with a reason |
| Cheat sheet | What syntax, evidence, or distinction do I need now? | Use alongside the relevant scope and playbook, never as independent authorization |

## A productive first session

1. Shortlist three programs through their official policy pages. Record whether each is open to you, currently accepting submissions, and paying for your chosen asset type.
2. Choose one exact asset or repository release. Save the policy reference, relevant scope text, exclusions, and the time you checked it.
3. Establish the permitted environment. Prepare your own accounts, tenants, device, local fork, or isolated product deployment as appropriate.
4. Map one valuable workflow from entry point to stored data or privileged operation. Write three specific hypotheses about its trust boundaries.
5. Test one hypothesis with a baseline and a negative control. Save enough evidence to reproduce it; end the session with the next concrete action.

This is an operating recommendation, not a claim that a first session should produce a paid finding. A disproved hypothesis with a clear reason is useful progress.

## Current changes that affect target selection

- **Huntr:** its 2026 transition changed the traditional OSS submission route. Use the dated status discussion in [Platforms](#page-platforms), not an old list of eligible Python projects. [Huntr 2.0 FAQ](https://blog.huntr.com/huntr-2-0-faq).
- **Internet Bug Bounty:** Node.js’s official notice confirms the IBB funding pause and continuing Node.js security intake without bounties. The direct IBB policy could not be reverified on 14 September 2026; check it before planning new work. [Node.js notice](https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties).
- **Rules are layered:** target permission, cloud-provider acceptable testing rules, platform terms, disclosure restrictions, and reward eligibility can all apply to one investigation. A program's safe harbor does not bind third parties. [HackerOne Gold Standard Safe Harbor](https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement).

## Evidence standard

Every candidate should answer: **who can do what to which resource, across which boundary, under what preconditions, on which version?** A claim of impact should be demonstrated with synthetic data or owned resources when possible, and clearly distinguished from additional consequences inferred from the root cause.

An outdated dependency is a lead until affected code and exploit conditions are established. A prompt that changes an assistant's tone is not automatically an AI security vulnerability. A crash, exposed debug string, permissive header, or code pattern needs a relevant security consequence and eligible scope. The technical chapters give the evidence threshold for each case.

## Research basis and limits

The [14 September review](#page-review) adds missing procedures and corrects selected technical and policy claims; it does not redate every original reference. The original policy and technical chapters were checked on **11 September 2026**; the expanded testing modules, vulnerability catalog, and ATT&CK mappings were researched on **12 September 2026**. Each chapter links claims to primary documentation and records source context; the [Sources](#page-sources) index gathers those references. Dynamic eligibility, invitation rules, supported releases, reward ranges, and provider policies must be rechecked before a new engagement. This manual does not promise earnings or a complete inventory of every currently running program.

The uploaded **all.txt** was inspected as a local text input: **5,520 nonempty, unique hostname-like rows**. It has no policy URLs, timestamps, environment restrictions, or authorization evidence. It was not probed, resolved, scanned, or treated as an approved target list. The scope chapter shows how to turn such an inventory into a review queue. Source: uploaded all.txt; supplied local copy, no public URL.

The roadmaps, prioritization weights, operating gates, example records, and test designs are original analytical recommendations informed by the linked technical standards. They are not platform requirements unless a platform rule is explicitly cited. CLI examples were checked against documentation; they were not executed against live targets and must be matched to the installed tool version.


## Reusable reference tools

- [Reusable test modules](#page-modules)
- [Vulnerability catalog](#page-vulnerabilities)
- [Command workbench](#page-commands)
- [Coverage & reuse map](#page-coverage)
- [MITRE ATT&CK mapping](#page-attack)
- [Review & updates](#page-review)


---

<a id="page-roadmap"></a>

# Roadmap

Use one core operating method across all scopes, then develop each platform's security model. Equal coverage in a reference manual does not mean investigating eleven target families simultaneously. The proposed schedule is a **24-week breadth cycle at roughly 8–12 focused hours per week**, followed by a specialization cycle. It is a planning estimate, not a mastery or income forecast; stretch device and native-code phases when their prerequisites require it.

## Common prerequisites

For an experienced engineer, test these prerequisites through tasks instead of restarting generic programming courses. You should be able to inspect raw HTTP and TLS behavior, trace a request across middleware and a datastore, explain authentication versus authorization, use Git and a debugger, read unfamiliar code with a hypothesis, and reproduce a failure in an isolated environment. Native-code work adds memory layout and debugging; cloud adds IAM evaluation; Web3 adds transaction semantics and financial invariants; hardware adds electronics and physical access constraints.

| Capability | Demonstration | If blocked |
|---|---|---|
| HTTP and sessions | Explain each request, token, redirect, cookie, and origin in a login workflow | Work through authentication and access-control labs |
| Source reasoning | Trace one attacker-controlled value to a privileged operation and identify all guards | Review a small open-source handler and its tests in a local copy |
| Evidence handling | Reproduce a bug after a clean reset using written steps alone | Replace screenshots-only notes with inputs, versions, and expected/actual results |
| Boundary thinking | Write an actor × action × resource × state matrix | Draw the data ownership model before selecting payloads |
| Scope handling | Distinguish an owned app from its external identity provider and hosting infrastructure | Complete the scope record before sending test traffic |

PortSwigger offers interactive web security labs; OWASP Juice Shop and crAPI provide intentionally vulnerable application environments. Use their published practice environments or your own isolated deployment, and do not infer permission for unrelated demo services. [Web Security Academy](https://portswigger.net/web-security), [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/), [OWASP crAPI](https://owasp.org/www-project-crapi/).

## The 24-week cycle

| Weeks | Focus | Concrete work | Exit gate |
|---|---|---|---|
| 1–2 | Scope, lab, evidence, reporting | Complete two policy reviews; create isolated working environments; write a report from a lab finding | Another person could reproduce the lab report without a call |
| 3–4 | OSS and self-hosted applications | Build an eligible release; map routes and jobs; follow three source-to-sink hypotheses; reproduce one historical fixed bug locally | Explain the root cause, required deployment conditions, vulnerable range, and fix |
| 5–6 | Web, API and network | Map a permitted application; use two accounts and tenants; compare REST/GraphQL/WebSocket paths and relevant service configuration | Finish a coverage matrix that distinguishes tested, blocked, and untested behavior |
| 7–8 | Mobile | Analyze Android and iOS artifacts; map deep links, IPC, storage, network trust, and backend dependencies | Demonstrate one local boundary failure or a well-supported negative result on a release-relevant setup |
| 9–10 | Desktop and browser extensions | Map privileged helpers, IPC, updater trust, extension messages, and untrusted documents | Separate user-level behavior from a genuine cross-process or privilege boundary |
| 11–12 | Cloud and containers | Use a dedicated lab account; model IAM and tenant identities; inspect storage, workload identity, and Kubernetes authorization | Prove what each principal can access and identify the exact policy or application decision responsible |
| 13–14 | AI, agents and MCP | Build a synthetic multi-tenant RAG/tool scenario; map content trust and tool authority; pin protocol versions | Show a prohibited data or action boundary with complete traces and controls |
| 15–16 | Web3 | Learn the chosen chain/toolchain; run a local fork; write accounting, access, and signature invariants | Produce a deterministic local test with exact block/address/source alignment |
| 17–18 | Hardware, firmware and embedded | Use an owned device or permitted firmware artifact; map boot/update/data paths and physical assumptions | Reproduce a trust failure without changing unrelated devices or production services |
| 19–20 | Supply chain and cross-surface chains | Trace source→build→package→runtime; connect a client input to its backend authorization; analyze one patch | Explain each boundary in a chain without silently extending scope |
| 21–22 | Live investigation sprint | Pick one eligible primary program plus one fallback; pursue the highest-value bounded hypotheses | Submit only if evidence clears the reporting gate; otherwise preserve disproven hypotheses and blockers |
| 23–24 | Triage, retest and specialization | Respond to questions, reproduce fixes where invited, review research efficiency, select the next deep branch | A sustainable backlog and a decision to continue, rotate, or pause each target |

Do not treat completing a lab exploit as permission to try the same procedure against production. A lab proves a technique can work under known conditions; a bounty finding must establish applicable conditions on the eligible asset.

## Scope-specific learning ladders

| Branch | Foundation | Intermediate | Advanced research | Durable output |
|---|---|---|---|---|
| OSS/self-hosted | Build system, versions, security policy | Data flow, auth gates, parsers, config | Variant analysis, cross-package reachability, fuzz harnesses | Reproducible source-linked PoC |
| Web/API/network | HTTP, DNS, TLS, identity | Object/property/function authorization, workflows | Cross-protocol state, cache boundaries, parsing discrepancies | Auth matrix and minimal request sequence |
| Mobile | Package identity, sandbox, lifecycle | Exported components, deep links, storage, trust | Native surfaces, cross-app chains, platform-version differences | Artifact hashes and device reproduction |
| Desktop/extensions | Process identity, files, ACLs | IPC, helpers, extension messages, updates | Sandbox escapes, unsafe document parsing, trust transitions | Lower-privilege-to-higher-privilege evidence |
| Cloud/containers | IAM and resource hierarchy | Cross-account/tenant policies, workload identity | Delegation chains, controller trust, isolation | Principal/action/resource decision record |
| AI/MCP | Model, retrieval, tools, identities | Direct/indirect injection, connector authorization | Multi-step authority confusion, model artifacts, state boundaries | Synthetic canary and tool trace |
| Web3 | Chain execution, Solidity or ecosystem language | Invariants, math, signatures, proxies | Economic state interactions, bridges, upgrade safety | Forked test and before/after balances |
| Hardware/firmware | Electronics, firmware layout, serial interfaces | Boot/update/auth/storage and protocol state | Trust chain failure, native parsing, cross-device boundaries | Revision-specific non-destructive reproduction |

This ladder is a capability model. Hardware, browser engines, operating-system kernels, cryptographic implementations, industrial control, vehicles, and distributed consensus can require much longer specialist preparation. Scope breadth is not a reason to skip those prerequisites.

## A weekly operating rhythm

Use approximately two 90-minute learning/reproduction sessions, two 2-hour target sessions, one 90-minute evidence and report session, and a short weekly review. Adjust hours to fit capacity. Keep one written next action so each session resumes at a code location or hypothesis rather than restarting reconnaissance.

During the first cycle, preserve one continuing target while rotating lab topics. During specialization, a reasonable starting allocation is 60% hypothesis-driven target work, 20% source reading or lab reproduction, and 20% evidence, reports, and retests. Change the allocation when a specific blocker emerges; these percentages are planning suggestions.

## A target sprint

**Day 1: admission.** Check eligibility and current policy. Build the scope record, obtain permitted accounts, and list blocked prerequisites. If the essential test cannot be performed under the policy, move the candidate to a blocked queue.

**Days 2–3: model.** Read product documentation and observe normal use. Identify valuable resources, roles, trust boundaries, asynchronous jobs, import/export paths, and integrations. Prioritize hypotheses rather than endpoint counts.

**Days 4–7: investigate.** Start from one high-value workflow. Compare roles, identities, object owners, resource states, and alternate protocols. Use source review where available, bounded dynamic tests where permitted, and control observations throughout.

**Days 8–10: resolve.** Minimize promising findings, eliminate false positives, draft a report, and record negative evidence. Continue only when an unresolved hypothesis has a specific next test. A time-box prevents indefinite collection without analysis; it does not require abandoning a productive target on day ten.

## Progress toward private programs

Build a record of reproducible, valid reports in a narrow surface area. Explain impact clearly, answer triage questions efficiently, follow disclosure restrictions, and retest when requested. A small number of technically strong reports can be a better portfolio than large volumes of low-confidence submissions. Invitations remain platform/program decisions; no number of reports, CVEs, points, or hours guarantees admission.

Before accepting an invitation, check the permitted collaboration rules, confidentiality obligations, testing windows, credential issuance, and whether the new program actually fits your skills. A private program can still have mature coverage, duplicates, narrow scope, or no accessible account path. The [platform chapter](#page-platforms) describes the current participation routes.

## Metrics that improve decisions

| Metric | Definition | Interpretation |
|---|---|---|
| Hypothesis resolution | Confirmed or disproved hypotheses divided by hypotheses attempted | A research throughput measure; do not optimize by choosing only trivial tests |
| Evidence completeness | Candidates with version, preconditions, controls, impact, and repeatable steps | Readiness for review |
| Accepted validity | Reports the program accepts as valid divided by resolved reports | Report quality; a duplicate may still be technically valid |
| Duplicate share | Duplicates divided by technically valid resolved reports | Helps assess target overlap and differentiation |
| Blocked time | Hours lost to inaccessible labs/accounts/unclear scope | Signals when to ask the program or rotate |
| Coverage confidence | Boundary cells supported by recorded tests, with scope restrictions visible | A bounded coverage claim, never proof of absence |
| Return on effort | Rewards actually received divided by recorded research hours | A retrospective personal measure, not a forecast |

Avoid raw hostname, payload, request, or alert counts as success targets. They measure activity, and can rise while the quality of investigation falls. Keep a separate learning log so a month without rewards can still show whether your method improved.

## Rotation and exit rules

Continue when there is a reachable boundary, a fresh lead, and a testable next step. Rotate when the same blockers persist, all prioritized hypotheses have been resolved, or the required environment is unavailable. Pause immediately when scope changes, permission expires, service health degrades, or you encounter data you do not need to establish the issue. Record why you stopped and what would justify resuming.

## References

- PortSwigger. [Web Security Academy](https://portswigger.net/web-security). Live training catalog; undated; accessed 11 September 2026. Used for the lab resource recommendation.
- OWASP Foundation. [Juice Shop](https://owasp.org/www-project-juice-shop/). Live project documentation; accessed 11 September 2026. Used for intentionally vulnerable application practice.
- OWASP Foundation. [crAPI](https://owasp.org/www-project-crapi/). Undated project documentation; accessed 11 September 2026. Used for API-specific practice.


---

<a id="page-platforms"></a>

# Participation routes, program selection, and disclosure

Program existence is not a promise that every asset is currently open, every researcher is eligible, or every accepted report earns money. Facts below come from official program pages and documentation. Recommendations and the selection model are editorial judgments.

## The distinctions that determine whether your work pays

Treat **access, target scope, testing permission, finding eligibility, payment, and disclosure** as six separate decisions. A public program may require registration, identity verification, geographic eligibility, or a minimum reputation. An asset can accept reports without offering rewards. A legitimate vulnerability can be outside the program's accepted threat model. A private program can be unpaid. A public repository can have a private reporting channel. None of those terms are interchangeable.

| Dimension | Record before choosing a target |
|---|---|
| Participation | Public, registered-only, application, invitation, vetted specialist, event registration |
| Program model | Ongoing bounty, unpaid VDP, discretionary reward, audit contest, paid assessment, patch incentive |
| Technical scope | Exact domains/paths, API endpoints, mobile IDs, repositories/branches, packages, versions, cloud services, contracts/chains, hardware |
| Environment | Production, sandbox, researcher tenant, self-hosted lab, supplied appliance, local chain fork |
| Eligible behavior | Explicitly permitted tests, rate limits, prohibited actions, proof requirements, stopping conditions |
| Reward | Eligible asset tier, vulnerability classes, severity model, duplicates, caps, contest sharing, payout prerequisites |
| Confidentiality | Program existence, code access, findings, collaborators, permitted AI processing, publication rules |

GitHub's private vulnerability reporting routes reports to repository maintainers; it is not a blanket GitHub-funded bounty. A `security.txt` file tells you where to find the reporting policy. RFC 9116 expressly says its presence does not imply permission to test, and the file does not automatically cover parent domains or subdomains. [GitHub private reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately), [RFC 9116, sections 3.1 and 5.5](https://www.rfc-editor.org/rfc/rfc9116.html).

## Platform and participation comparison

The table covers 26 useful routes, including some that must now be treated as unavailable for new paid OSS research. Links point to official entry or policy pages. Re-read the exact brief before allocating time.

| # | Platform or route | Access and reward model | Best fit and decisive limitation |
|---|---|---|---|
| 1 | [HackerOne](https://www.hackerone.com/bug-bounty-programs) | Public and private BBPs/VDPs; invitations and qualifying private opportunities | Broad web/API/mobile/product work. Distinguish bounty programs from response-only listings; private access is conditional and confidential. [Invitation rules](https://docs.hackerone.com/en/articles/8470802-invitations). |
| 2 | [Bugcrowd](https://docs.bugcrowd.com/researchers/participating-in-program/finding-program/) | Public programs and selected private engagements; BBPs, VDPs, other engagement models | Broad scopes and specialist matching. Read the engagement brief, identity/geography requirements, status and disclosure terms. A private invitation is not proof of payment. |
| 3 | [Intigriti](https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels) | Public, registered, application, invite-only; BBPs and VDPs | Useful application-based route to restricted programs. Registered is different from invited; participation restrictions and payout ID verification can apply. [Settings](https://kb.intigriti.com/en/articles/5928505-program-settings). |
| 4 | [YesWeHack](https://helpcenter.yeswehack.io/en/collections/875314-programs) | Public/private programs, grey-box credentials, possible VPN access | Web/API and product programs with documented scope/reward grids. Invitations depend on skills, activity, geography and customer requirements. [Selection](https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program). |
| 5 | [Huntr](https://blog.huntr.com/huntr-2-0-faq) | **Now challenge-based AI competitions**; traditional OSS intake closed | OSS submissions stopped **30 June 2026**; all OSS submissions froze **31 July 2026**. Model File Format submissions were still open when this FAQ was published; independently confirm that specific route now. Do not plan ordinary repository bounties from old huntr lists. |
| 6 | [Google OSS VRP](https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules) | Funded rewards for qualifying Google OSS research | Check project tiers, dependency criteria and evidence conditions in the current policy. The official [2026 rule-update page](https://bughunters.google.com/blog/ossvrp-rule-updates-2026) exists, but its body and the live policy body were unavailable to this review on **14 September 2026**. Detailed eligibility, amounts and the update date are not reverified; do not substitute launch-era tables. |
| 7 | [Google Patch Rewards](https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules) | Security-hardening patch incentive | A separate security-hardening route from reporting a newly discovered vulnerability. The official page body was unavailable to this review on **14 September 2026**; verify that the intended project and patch are currently accepted before committing work. |
| 8 | [Internet Bug Bounty](https://hackerone.com/ibb) | **Funding pause confirmed by Node.js; live intake status needs direct recheck** | The official [Node.js notice, updated 2 April 2026](https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties), confirms IBB paused and Node.js stopped paying while continuing security intake. IBB’s direct page returned a JavaScript shell on **14 September 2026**; its exact pause date and current submission controls were not independently reverified. |
| 9 | [Repository private vulnerability reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately) | Maintainer disclosure channel; no inherent bounty | Excellent for OSS advisories, coordination and fixes. Available when enabled; otherwise follow repository security policy. GitHub hosting alone creates no bounty entitlement. |
| 10 | [GitHub product bounty](https://bounty.github.com/) | Public and invite-only VIP tiers | GitHub platform/products listed in its policy, not every GitHub-hosted repository. [Restructured effective 27 July 2026](https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/); public signal requirements and limited initial submissions apply. |
| 11 | [GitLab product/self-managed research](https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/) | Product bounty through current HackerOne policy | Strong source-to-runtime route using your own installation. January 2026 policy separates valid scenarios by environment and threat model; do not infer permission over customers' deployments. |
| 12 | [Wordfence](https://www.wordfence.com/threat-intel/bug-bounty-program) | WordPress ecosystem bounty; researcher tiers | Plugins/themes suit local PHP review. Installation thresholds, threat classes, researcher tier and outstanding-report limits affect eligibility. “A plugin bug” is insufficient. |
| 13 | [Patchstack](https://patchstack.com/articles/bug-bounty-guidelines-rules/) | WordPress monthly competition pool plus eligible individual zero-day rewards | Rules updated **1 September 2026**. Latest release, distribution, active-install count, attacker role and impact matter. Managed VDP acceptance can be broader than reward eligibility. |
| 14 | [Microsoft MSRC](https://www.microsoft.com/en-us/msrc/bounty) | Product/service bounty families and coordinated disclosure | Cloud, identity, endpoint, developer tooling. The [December 2025 expansion](https://www.microsoft.com/en-us/msrc/blog/2025/12/in-scope-by-default) covers critical flaws with direct demonstrable impact on Microsoft online services, including relevant third-party code; it is not blanket authorization over unrelated infrastructure. |
| 15 | [Apple Security Bounty](https://security.apple.com/bounty/guidelines/) | Direct product/security rewards | OS, device, sandbox and eligible service research. Reward depends on actionable evidence and current categories; Target Flags can demonstrate exploitability. [Research-device access](https://security.apple.com/research-device/) is a separate application process. |
| 16 | [Mozilla](https://www.mozilla.org/en-US/security/bug-bounty/) | Client and other product/service bounty routes | Browser/client code plus separately scoped web assets. [Client rules](https://www.mozilla.org/en-US/security/client-bug-bounty/) distinguish supported configurations, third-party code, mitigation bypasses and report requirements. Full exploit development is not always required. |
| 17 | [Immunefi](https://immunefi.com/bug-bounty/) | Web3 bug bounties and audit competitions | Smart contracts, protocols and explicitly listed web/infrastructure assets. Exact asset addresses, chains, impact lists and program-specific proof rules decide eligibility; use local forks for impact reproduction where required. |
| 18 | [HackenProof](https://hackenproof.com/) | Public/private bounties and crowdsourced audits | Web3 protocols, exchanges, wallets and listed web assets. Inspect each bounty's scope and reward conditions; platform marketing is not an asset authorization list. |
| 19 | [Cantina](https://cantina.xyz/opportunities) | Bounties, competitions and other security engagements | Onchain and other explicitly offered research opportunities. Check which engagement model you joined, its repository/commit or deployed scope, and judging/payment terms, including any deposit. Its current documentation uses the cantina.security domain. |
| 20 | [Code4rena](https://docs.code4rena.com/) | Competitive audits and separate ongoing bounties | Smart-contract source review. [Bounties](https://docs.code4rena.com/bounties) currently require runnable coded PoCs and generally High/Critical findings; the documented **25 USDC submission deposit** is a real participation cost. Contest terms are different. |
| 21 | [Sherlock](https://docs.sherlock.xyz/audits) | Audit contests, collaborative audits and post-launch bounties | Onchain economics, invariants and protocol logic. Contest finding validity, duplication and payout rules must be learned separately from ordinary web-bounty severity. |
| 22 | [Zero Day Initiative](https://www.zerodayinitiative.com/about/) | Vendor-agnostic vulnerability acquisition and coordination | Product/binary/appliance research. Acquisition is selective and terms-specific; a report is not automatically purchased. Its coordinated-disclosure process differs from reporting straight to a vendor. |
| 23 | [Pwn2Own](https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html) | Registered, time-bounded exploit competition | Advanced product, virtualization, browser, device and specified AI categories. Berlin 2026 is a completed example; choose a currently announced event, exact target/version/configuration and entry rules. |
| 24 | [Direct vendor PSIRT / security.txt](https://www.rfc-editor.org/rfc/rfc9116.html) | Direct disclosure, sometimes a separate reward program | Reach vendors outside platforms through the official policy/contact route. A security inbox, hall of fame or published source is not a promise of authorization or money. |
| 25 | [Government and institutional VDPs](https://www.cpsc.gov/vulnerability-disclosure-policy) | Usually disclosure and recognition unless a bounty is explicit | A route for useful real-world research. Each institution defines covered systems and stopping conditions. The example policy requires stopping upon confirming the issue or encountering sensitive data. |
| 26 | [Google product and service VRPs](https://bughunters.google.com/report/vrp) | Direct vendor reporting route, separate from the OSS and Patch Rewards entries | Google’s official indexed intake description covers its standard VRP and product families including Android, Cloud, Chrome and ChromeOS. Select the matching program and read its specific rules; the rendered intake body was unavailable on 14 September 2026, so detailed participation and payout conditions are not reverified here. |

**Do not confuse a funded discovery route with a funded remediation route.** OSS-Fuzz infrastructure, advisory databases, CNA status, GitHub Sponsors and a project's grant funding do not by themselves promise payment for your report. Read the specific offer. For example, curl's maintainers explicitly ended its bounty on 31 January 2026 while continuing to value valid reports. [curl bounty policy](https://github.com/curl/curl/blob/master/docs/BUG-BOUNTY.md), [maintainer announcement](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/).

## Submission rules that change the next action

A common [report template](#page-templates) keeps evidence consistent. These program-specific gates still need their own check; the examples below were reviewed on **14 September 2026**.

| Route | Practical requirement or limitation | What to prepare |
|---|---|---|
| Apple | Reward priority belongs to the first **complete and actionable** report, which need not be the first message received. Some categories require Target Flags; early publication can remove reward eligibility. | A reproducible package and required target proof before submission; record the permitted publication point. [Apple guidelines](https://security.apple.com/bounty/guidelines/) |
| Code4rena bounties | The 25 USDC deposit is paid through the application; manual transfers are not accepted. Valid or `wontfix` reports receive a refund, invalid/spam reports do not. Bounty submissions cannot be edited after submission. | Review the runnable PoC and exact scope before finalizing; account for the documented deposit and gas. These are bounty rules, not universal contest rules. [Code4rena rules](https://docs.code4rena.com/bounties) |
| Wordfence | Program scope excludes vendor web services not run locally and generally excludes plugins/themes with their own bounty. Its FAQ no longer offers an unrestricted out-of-scope CVE-only route. | Verify the actual component, attacker role, vulnerability class, installation threshold and researcher tier. Use the vendor’s designated route where applicable. [Wordfence policy](https://www.wordfence.com/threat-intel/bug-bounty-program) |
| Immunefi | The directory distinguishes KYC, PoC, paid-submission and primacy-of-impact settings. A program’s settings are not platform-wide defaults. | Record the selected program’s asset/impact rules, submission cost, identity requirements and proof format in the scope record. [Immunefi directory](https://immunefi.com/bug-bounty/) |

If two parts of an official policy appear inconsistent, preserve both references and ask the designated program channel about the specific planned action. Do not choose the most permissive sentence or silently convert a vulnerability taxonomy entry into reward eligibility.

## Preserve research when a reporting route closes

Huntr’s FAQ also discusses access to historical reports, with August and October 2026 milestones and no guarantee of continuing access. If you have prior Huntr submissions, preserve any copies you are permitted to retain while access is available. Record report IDs, affected/fixed versions, advisory links, original evidence and coordination history; keep private material private. The FAQ does not establish that an unresolved frozen report can now be published. [Huntr transition FAQ](https://blog.huntr.com/huntr-2-0-faq).

For any closed route, find the product’s current security policy before reporting a new issue. A platform closure, loss of bounty funding and closure of the underlying vendor’s security intake are different events.

## Self-hosted research: eligibility checks that prevent wasted effort

Self-hosted describes the **test environment**, not a bounty category. Three different cases need different reporting paths:

| Case | Evidence and routing |
|---|---|
| Upstream product flaw reproduced locally | Pin the supported version/commit, use a supported installation, document configuration, show the actual attacker starting privilege and violated boundary; report to the product's designated route. |
| Customer deployment misconfiguration | The customer is the affected operator. The vendor's product bounty might exclude this; verify that customer's scope and authorization separately. |
| SaaS-only flaw in a source-available product | Local source reasoning can suggest the flaw, but local success does not establish the SaaS configuration or reachability. Prove only within permitted SaaS accounts/environment. |

Before committing to a self-hosted target, record: free versus enterprise edition; license or research-license availability; affected maintained branches; default versus optional features; required integrations; tenant model; whether administrator-to-code-execution is expected; and whether the program requires proof on its hosted service. A vulnerability that exists only after you disable authentication or install your own unsafe plugin may have no upstream security impact. Conversely, a low-privilege user crossing a product-promised sandbox or tenant boundary can be meaningful even if the PoC runs locally. These are case-specific judgments; GitLab's January 2026 update is a useful concrete example of explicit environment and threat-model rules. [GitLab policy update](https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/).

Keep source audit and operational testing permissions separate. A public repository does not authorize triggering its CI with attacker content, publishing a lookalike dependency, using found credentials, probing its production deployment or testing an unrelated customer. Reproduce build pipelines with your own repository, fake tokens and isolated runners whenever possible; seek clarification on any remaining real-system action through the designated program channel.

## Private-program progression

Choose one primary platform and one technical specialty for the first research cycle. For a senior backend engineer, source-assisted authorization, multi-tenant APIs, asynchronous job permissions, import/export processing and integrations are credible specialties. Build evidence of depth through a small number of reproducible reports; uploading scanner output to accumulate activity undermines the quality metrics that matter.

1. **Complete the account correctly:** specialist skills, languages/frameworks, region, permitted contact details, required verification, 2FA and invitation preferences. Use only reports/advisories you are allowed to publicize as portfolio evidence.
2. **Build relevant valid-report history:** take one or two public paid programs with accessible accounts and enough application depth. An unpaid VDP can be worthwhile for learning, impact or platform reputation, but set an explicit time budget.
3. **Use supported access mechanisms:** invitations, application programs and available private opportunities. Accept terms before testing and understand when the engagement actually opens.
4. **Maintain trust:** respond clearly to triage, deliver requested evidence promptly, keep credentials isolated and respect program confidentiality. Track scope changes rather than treating access as permanent.
5. **Reassess invitations commercially:** private access can reduce competition, but slow triage, tiny scope, inaccessible roles or narrow exclusions can still make the program a poor fit. There is no guaranteed invitation schedule.

Platform mechanics differ. HackerOne cites reputation, non-negative signal and a clean conduct record; its documentation also describes available private opportunities. It explicitly prohibits contacting a private program to solicit an invitation. Bugcrowd's newer engagement documentation emphasizes skill match, recent quality submissions, historical performance and customer requirements; older program pages give numerical qualifications, so do not turn those into a universal guarantee. Intigriti includes application programs; YesWeHack describes curated invitations using skills, ranking, location and activity. [HackerOne invitations](https://docs.hackerone.com/en/articles/8470802-invitations), [private opportunities](https://docs.hackerone.com/en/articles/10485859-private-opportunities), [Bugcrowd engagement selection](https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/), [Intigriti confidentiality](https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels), [YesWeHack invitations](https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program).

## Select targets using evidence, not maximum advertised bounty

The following scoring model is a planning heuristic, not measured payout prediction. First apply three hard gates: permission is sufficiently clear; participation/access requirements are satisfied; a currently open reporting route accepts the relevant asset and finding type. For a money-focused sprint, add a fourth gate: an explicit funded reward route exists.

Score each surviving candidate from 0–5, then multiply by weight/5:

| Criterion | Weight | Evidence that earns a high score |
|---|---:|---|
| Your technical advantage | 25 | Familiar language/framework; ability to explain the security boundary; domain knowledge competitors need time to acquire |
| Useful feature/role access | 20 | Two controllable tenants, several roles, enterprise/research features or a fully reproducible local deployment |
| Unexplored surface or recent change | 15 | Recent release, new integration, changed authorization, new API/version or credible under-reviewed component |
| Policy and reward fit | 15 | Your likely findings explicitly accepted, practical proof requirements, clear asset tiers and exclusions |
| Triage and remediation evidence | 15 | Recent legitimate disclosures, maintained release process, public response metrics or your own prior experience |
| Setup and competition cost | 10 | Affordable lab, attainable accounts, bounded setup effort, plausible differentiated angle |

Use **70/100** as an initial active-work threshold and **50–69** as a reserve list; these thresholds are adjustable judgments. Keep only two active targets: a primary deep-research target and a fallback while blocked. For each, write three hypotheses before scanning: “A user removed from a tenant can still export through an asynchronous job,” for example. Each hypothesis needs a starting privilege, reachable feature, expected boundary and a safe observable result.

Timebox setup to one or two sessions initially. Park a target when required roles cannot be obtained, the lab cannot reproduce a supported configuration, policy excludes the research angle, or repeated sessions produce no new reachable surface. Continue when each session resolves uncertainty and opens a plausible boundary violation. Endpoint count, GitHub stars and advertised maximum rewards are weak proxies for expected value.

Track valid/invalid/duplicate outcomes, hours per accepted report, setup time, triage delay, payment delay and recurring root causes. Separate unpaid research goals from income goals. A high CVSS number, CVE assignment, accepted report and cash payment are distinct outcomes; the program's severity and reward policy decides the last one.

## Report-to-disclosure workflow

1. **Validate locally or within the authorized environment.** Use two owned identities/tenants and seeded data where possible. Capture exact versions, requests and preconditions. Add a control case proving that the result depends on the suspected flaw.
2. **Check eligibility and known issues again.** Re-read current scope, exclusions, advisory history, release notes and platform-specific duplicate rules. Distinguish one root cause across endpoints from separate independent vulnerabilities.
3. **Submit one reproducible report through the designated route.** Lead with attacker capability and victim impact; include asset, version/commit, starting role, configuration, numbered reproduction, expected/actual behavior, minimal evidence and cleanup. Provide runnable proof where required. Do not fabricate affected versions, exploit chains or CVSS assumptions.
4. **Coordinate privately.** Answer requests within the program's window. If triage disputes validity or severity, address the specific assumption with evidence, then use the platform's supported mediation/appeal path. Do not threaten publication or route a confidential finding to multiple reward programs to pressure payment.
5. **Support repair and retest.** Agree on the allowed environment; verify the original proof fails for the right reason, the authorized control still works, and a closely related variant is covered. A maintainer-private fork can support an OSS fix without exposing the issue.
6. **Separate payment from publication.** Record the report ID, decision, payout requirements and agreed disclosure date. Follow the applicable policy and coordinated disclosure agreement; neither a fix nor a CVE automatically grants permission to disclose a private program's existence.
7. **Publish only the permitted material.** Remove live tokens, personal data and private-program details. Include root cause, affected/fixed versions, advisory/CVE links and mitigation. Retain a sanitized case study and update your own hypotheses/checklist.

GitHub supports private advisory collaboration and temporary private forks, while Apple, Mozilla, Code4rena and Patchstack have materially different evidence and submission requirements. The common report structure above is a starting template, not a replacement for those rules. [GitHub private reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately), [Apple guidelines](https://security.apple.com/bounty/guidelines/), [Mozilla client rules](https://www.mozilla.org/en-US/security/client-bug-bounty/), [Code4rena bounty rules](https://docs.code4rena.com/bounties), [Patchstack rules](https://patchstack.com/articles/bug-bounty-guidelines-rules/).

## Source registry

Original registry accessed **2026-09-11**. A selective follow-up review on **2026-09-14** rechecked the participation mechanics and policy-sensitive claims described above. “Undated/current” records the original retrieval context; it does not certify every program’s present intake. Google’s dynamic policy bodies and the direct IBB policy body could not be reverified. Search-index information is labeled where used, and no inaccessible page is treated as proof that a program closed or reopened.

| Source title | Publisher | Publication/update date | Exact URL | Claim used |
|---|---|---|---|---|
| Bug Bounty Programs | HackerOne | Undated/current | https://www.hackerone.com/bug-bounty-programs | Program discovery route |
| Invitations | HackerOne | 2025-10-15 | https://docs.hackerone.com/en/articles/8470802-invitations | Reputation, signal, conduct, solicitation prohibition |
| Private Opportunities | HackerOne | 2025-01-29 | https://docs.hackerone.com/en/articles/10485859-private-opportunities | Eligible researchers can claim listed opportunities; limited availability |
| Finding a Program | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/finding-program/ | Public/private access, brief and special requirements |
| Viewing and Accepting Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/ | Newer engagement matching criteria |
| Viewing and Accepting Program Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/viewing-invitations/ | Older numerical criteria differ from newer engagement language |
| Program confidentiality levels | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels | Four participation modes |
| Program settings | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/5928505-program-settings | Identity, geography, 2FA and payout restrictions |
| Programs | YesWeHack | Undated/current | https://helpcenter.yeswehack.io/en/collections/875314-programs | Scope grids, grey-box credentials, VPN |
| Invite new hunters on a program | YesWeHack | Relative update label only on 2026-09-14; exact date unverified | https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program | Curated invitation criteria |
| Huntr 2.0 FAQ | Huntr / Palo Alto Networks | 2026; retrieved page had no exact date | https://blog.huntr.com/huntr-2-0-faq | OSS intake closure/freeze; challenge pivot; provisional model-format route |
| Google OSS VRP Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules | Current OSS policy route; dynamic body incomplete |
| Streamlining Google's OSS VRP: Key Rule Updates | Google | 2026 title; exact update date not reverified 2026-09-14 | https://bughunters.google.com/blog/ossvrp-rule-updates-2026 | 2026 rule update exists; do not reuse launch-era rules |
| Patch Rewards Program Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules | Separate patch incentive |
| Internet Bug Bounty policy | HackerOne / IBB | Direct policy body unavailable 2026-09-14 | https://hackerone.com/ibb | Previous policy reference; current intake controls and exact pause date not reverified |
| Security Bug Bounty Program Paused Due to Loss of Funding | Node.js | Updated 2026-04-02 | https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties | IBB loss pauses Node.js payments while intake continues |
| Privately reporting a security vulnerability | GitHub | Undated/current | https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately | Repository private reporting and private forks |
| Next chapter: Restructuring GitHub's bug bounty program | GitHub | 2026-07-22; effective 2026-07-27 | https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/ | Public/VIP restructuring and signal gate |
| GitHub Security | GitHub | Undated/current | https://bounty.github.com/ | Product program entry point |
| GitLab Bug Bounty Program policy updates | GitLab | 2026-01-20 | https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/ | Self-managed versus hosted testing and scope |
| Bug Bounty Program | Wordfence | Undated/current | https://www.wordfence.com/threat-intel/bug-bounty-program | Tiers and eligibility conditions |
| Bug Bounty Guidelines & Rules (2026 edition) | Patchstack | Published 2022-07-10; update effective 2026-09-01 | https://patchstack.com/articles/bug-bounty-guidelines-rules/ | Pool/individual reward distinction and recent conditions |
| Microsoft Bounty Programs | Microsoft | Undated/current | https://www.microsoft.com/en-us/msrc/bounty | Program families |
| In scope by default | Microsoft MSRC | 2025-12-11 | https://www.microsoft.com/en-us/msrc/blog/2025/12/in-scope-by-default | Critical online-service impact expansion |
| Guidelines | Apple Security Research | Undated/current | https://security.apple.com/bounty/guidelines/ | Actionable evidence and reward eligibility |
| Security Research Device Program | Apple | Undated/current | https://security.apple.com/research-device/ | Separate research-device program |
| Security Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/bug-bounty/ | Mozilla program entry |
| Client Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/client-bug-bounty/ | Supported client configurations, proof requirements, mitigation scope |
| Bug Bounty Programs | Immunefi | Current directory | https://immunefi.com/bug-bounty/ | Web3 bounty directory |
| Bug bounty and crowdsourced audit platform | HackenProof | Current homepage | https://hackenproof.com/ | Live platform/route types |
| Opportunities | Cantina | Current directory | https://cantina.xyz/opportunities | Bounties, competitions and deposit indicators |
| Welcome to Cantina | Cantina | Current documentation | https://docs.cantina.security/introduction | Current documentation/domain |
| Competitions | Code4rena | Current documentation | https://docs.code4rena.com/ | Competitive audit route |
| Bounties | Code4rena | Current documentation; indexed 2026-03-25 | https://docs.code4rena.com/bounties | Runnable proof, severity and 25 USDC deposit |
| Audits | Sherlock | Current documentation | https://docs.sherlock.xyz/audits | Contest process and judging/payout documentation |
| About Us | TrendAI Zero Day Initiative | Undated/current | https://www.zerodayinitiative.com/about/ | Vendor-agnostic acquisition and coordination |
| Pwn2Own Berlin 2026 Rules | ZDI | 2026 event rules | https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html | Fixed event, registration and technical target conditions |
| RFC 9116 | IETF / RFC Editor | 2022-04 | https://www.rfc-editor.org/rfc/rfc9116.html | Contact/policy discovery; no implied test authorization |
| Vulnerability Disclosure Policy | US Consumer Product Safety Commission | Undated/current | https://www.cpsc.gov/vulnerability-disclosure-policy | Institutional VDP and stopping conditions |
| BUG-BOUNTY.md | curl project | Current repository policy | https://github.com/curl/curl/blob/master/docs/BUG-BOUNTY.md | End of curl bounty in January 2026 |
| The end of the curl bug-bounty | Daniel Stenberg, curl maintainer | 2026-01-26 | https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ | Closure effective 2026-01-31 |
| Google-owned product vulnerability intake | Google | Undated; official index checked 2026-09-14 | https://bughunters.google.com/report/vrp | Broader Google product/service reporting route; dynamic body unavailable |


---

<a id="page-scope"></a>

# Scope model

A usable scope is an intersection of **asset identity, environment, researcher access, permitted action, data boundary, and time**. Payment eligibility is a separate decision. An asset can accept vulnerability reports without authorizing active testing, or permit testing without offering a bounty.

## Program and access dimensions

| Dimension | Values | Consequence |
|---|---|---|
| Visibility | Public, unlisted, invite-only/private | Knowing a private program exists does not enroll you |
| Reward model | Paid bounty, discretionary reward, unpaid VDP, contest prize, contracted assessment | Each uses different eligibility and duplicate/judging rules |
| Knowledge | Black box, gray box, white box | Source or credentials improve visibility; neither expands asset scope |
| Deployment | Vendor SaaS, provided sandbox, own self-hosted instance, customer deployment, offline artifact | The same codebase can have different authorized environments |
| Identity | Unauthenticated, self-registered user, issued researcher account, tenant admin, device owner, local low-privilege user | The starting privilege is part of the finding |
| Lifecycle | Supported release, prerelease/beta, exact commit, version range, fixed contest snapshot | Record exact versions and exclusions |
| Timing | Ongoing, limited campaign, live event, private window, paused, closed | Permission can expire even while a queue or old policy remains visible |
| Disclosure | Confidential, coordinated release, platform-approved disclosure, public advisory | Report submission is not permission to publish |

## Asset taxonomy

| Scope type | Identity to record | Do not infer | Primary test boundary |
|---|---|---|---|
| Exact URL or path | Scheme, hostname, effective port, path and stated matching rules | Other paths, ports, redirected hosts or API origins | Server-side handling of the permitted resource |
| Exact hostname | Canonical hostname and permitted protocols/ports | Sibling hosts, parent domain, origin IP, all ports | Application/service on that named asset |
| Wildcard domain | Literal expression, apex rule, depth rule, exclusions | Apex inclusion, acquired domains, third-party service takeover | Included hostname with ownership and policy confirmed |
| Apex/root domain | Literal root hostname; separate wildcard if provided | Every descendant host | Listed root service |
| IP/CIDR | Exact IPv4/IPv6 prefix, protocols, ports, allocation date | Every virtual host, tenant, or CDN customer on that IP | Authorized network listener or service |
| API | Base URL, version, paths, methods, authentication context | Mobile or partner backend because it uses similar tokens | Object/property/function and tenant authorization |
| Repository | Owner/repo, branch, commit, paths, submodules, releases | Git host infrastructure, all organization repos, deployments | Product code and relevant build/runtime behavior |
| Package/library/SDK | Ecosystem, exact package identity, version, artifact digest | Similar package names, downstream users, registry infrastructure | Caller/input privileges and vulnerable execution path |
| Self-hosted product | Product edition, release/image digest, supported configuration | Every publicly reachable installation | Reachable product flaw in a permitted deployment |
| Mobile application | Store URL, package/bundle ID, version/build, platform | All network endpoints contacted by the application | App/OS/user boundary plus separately scoped backend |
| Desktop/native application | Product, platform, version, architecture, signed artifact hash | Every helper, plug-in, online service or OS bug | Process, privilege, document, update or sandbox boundary |
| Browser extension | Extension ID, store, release, browser/version | Other extensions or arbitrary websites | Message origin, permissions and privileged APIs |
| Cloud resource | Account/project/subscription, region, resource ID, principal | Provider control plane or neighboring tenants | IAM/application authorization on permitted resources |
| Container/Kubernetes | Image digest, cluster, namespace, workload, identity | Host, adjacent namespaces, registry or nodes unless included | Workload/controller/host trust as explicitly scoped |
| AI/LLM/agent | Product/model/build, endpoint, tools, tenant, model artifact hash | All model behavior or all connected SaaS services | Data access, tool authority, action and isolation |
| Smart contract/protocol | Chain ID, address, proxy and implementation, block, source commit | Same-name deployments, all chains, every dependency | Listed impact and contract state invariant |
| Hardware/IoT | Model, board revision, firmware/build, interfaces, physical access assumptions | Cloud companion services or other hardware revisions | Boot, update, interface, identity and data trust |
| Firmware/binary artifact | Download provenance, digest, architecture, version | Permission to flash or test any deployed physical system | Artifact parser/runtime or trust mechanism |
| Organization-wide scope | Explicit ownership wording, acquisition exceptions, third-party clauses | Brand/name/certificate similarity proving ownership | Only assets that meet the program's actual definition |

These are common families, not a universal platform enumeration. A program might separately list browser engines, kernels, databases, cryptographic implementations, telecom equipment, vehicles, industrial systems, identity services, or AI model files. Map each to its precise artifact and execution boundary rather than forcing it into a domain-only scanner.

## Wildcards and URL matching

Treat wildcard semantics as a policy question. A program may define `*.example.com` to cover descendants broadly, while another may enumerate exclusions or interpret depth differently. Do not import TLS certificate wildcard semantics into bounty scope. If the apex is not explicitly covered or the policy is ambiguous, mark it for clarification instead of silently including it.

For your own approved hostname matcher, normalize case and a trailing dot, handle IDNA deliberately, and compare DNS label boundaries. The suffix `example.com` must not match `notexample.com` or `example.com.attacker.invalid`. Exclusions override the broad inclusion rule in your queue. Record the original source string alongside the normalized value.

For URL scopes, parse scheme, host, effective port, and path as separate fields. Do not use an unanchored regex or raw `startswith` comparison as the authorization engine. Encoded separators, normalization by proxies, path-segment boundaries, alternate ports, and redirect destinations require explicit handling. Even same-host redirects can leave a permitted path or port. A URL appearing in an archived page does not mean it still belongs to the organization.

## Third-party boundaries

An application may be in scope while its payment processor, email provider, identity provider, CDN management API, analytics service, or customer-hosted deployment is not. Test the application's handling of integration data where allowed; do not transfer the program's permission to the provider. HackerOne's safe-harbor text explicitly notes that organizations cannot authorize research on third-party infrastructure and that those parties are not bound by the statement. [Gold Standard Safe Harbor](https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement).

Similarly, a DNS record pointing to a service is evidence of a dependency, not a license to claim the corresponding bucket, project, tenant, app name, or email domain. Some providers prohibit takeover testing independently of the target program. Use the current provider rules and a non-destructive proof path in the cloud chapter.

## Permission to disclose versus permission to test

`security.txt` identifies disclosure information. Its presence does not itself authorize testing; the RFC also says the file's domain/IP scope does not automatically extend to parents or subdomains. Follow its policy link and verify currency and provenance. [RFC 9116, sections 3.1 and 5.5](https://www.rfc-editor.org/rfc/rfc9116.html).

Public source code allows reading and use under its license; it does not grant permission to attack vendor infrastructure or customer installations. A self-hosted lab provides an environment you control, but a reward still depends on the program's accepted products, versions, configurations, attack assumptions, and reporting rules. An unrestricted source review is not necessarily an unrestricted bounty.

## Actions are part of scope

| Action class | Decision before use | Bounded alternative when unclear |
|---|---|---|
| Public source/documentation review | Applicable license, confidentiality, retrieval terms | Read official published artifacts |
| Third-party passive discovery | Provider terms and data handling | Keep candidates outside the active queue |
| DNS/HTTP/service probing | Approved destination, method, rate and testing window | Validate scope first; review existing evidence |
| Authenticated state changes | Owned accounts/data and allowed workflows | Synthetic records in issued test tenants |
| Out-of-band callbacks | Callback service approval and data controls | Owned callback with a non-sensitive unique marker |
| Concurrency, load, fuzzing | Explicit limits and service-impact tolerance | Local harness or small program-approved sequence |
| Credential/secret validation | Specific program rule and ownership | Report location and redacted structure without using it |
| Resource or subdomain takeover | Target and provider authorization | DNS/configuration evidence without claiming resources |
| Social engineering, physical entry, radio tests | Explicit applicable authorization | Do not run a generic bounty workflow against these surfaces |
| Destructive data, fund movement, persistence, pivoting | Usually restricted; exact program permission necessary | Local reproduction and minimum proof of the initial boundary |

Do not invent a default traffic allowance. An internal conservative request limit controls your own tools; it does not replace program permission. Handle `429`, health degradation, or unexpected real user data as reasons to stop and reassess.

## Turning all.txt into a scoped review queue

The supplied file contains 5,520 unique nonempty hostname-like entries, predominantly associated by name with a single brand and related domains. This observation is a local string analysis. It establishes neither ownership nor active program status, and no network activity was performed against it.

1. Preserve the original file and its hash. Normalize into a separate candidate table without discarding the original value.
2. Add discovery source, discovery time, policy URL, policy review time, matching rule, exclusions, environment, allowed techniques, and decision reason. Unknown values stay unknown.
3. Resolve the program policy through official sources. Compare exact rules to each candidate. Do not use a third-party scope aggregator as the final authority.
4. Assign one status: `candidate`, `needs clarification`, `approved for specified actions`, `excluded`, or `stale`. Approval includes a specific policy snapshot and expiry/review trigger.
5. Export only the approved subset required for the next action. Keep candidate discovery output separate from the tool input.
6. Recheck policy and relevant ownership before a later session. Scope drift should invalidate queued actions, not merely update a dashboard label.

| Candidate example | Known from list | Missing | Decision |
|---|---|---|---|
| A hostname containing `stage` | A string suggesting an environment | Actual ownership, service, permission, excluded environments | Candidate only |
| An `api` subdomain | A name that might serve an API | API base paths, accounts, allowed test methods | Candidate only |
| A `mail` or `vpn` hostname | A service-like label | Whether network service testing is allowed | Candidate only |
| A regional brand domain | Similar naming | Legal/technical ownership and explicit inclusion | Candidate only |

The inventory is not embedded into this website as a clickable attack queue. The reusable scope template supports working on an approved subset when permission is established.

## Admission checklist

- [ ] Program is currently accepting the intended report type.
- [ ] Researcher eligibility and private-program enrollment are satisfied.
- [ ] Asset identifier, version, environment, and ownership match the policy.
- [ ] Exclusions and third-party dependencies have been reviewed.
- [ ] Intended techniques, rate, concurrency, and test window are permitted.
- [ ] Authentication identity and data used for proof are controlled or issued for testing.
- [ ] Safe harbor and disclosure terms have been read without assuming they bind third parties.
- [ ] Reward eligibility is recorded separately from permission to test.
- [ ] A stop condition and reporting route are recorded.
- [ ] Policy changes invalidate pending actions until re-reviewed.

## Recheck policy changes before resuming work

Keep a dated policy snapshot and a small decision log alongside the [scope template](#page-templates). Recheck at the start of an active session, before a materially different technique, and before submission or retesting. The sequence below is an operational recommendation; the specific program determines when permission starts or ends.

| What changed | What to suspend or re-evaluate | What can remain in your notes |
|---|---|---|
| Asset removed, engagement paused, invitation revoked, or testing window closed | Pending probes and new interactions with the affected asset; confirm the applicable reporting route for existing evidence | Earlier evidence, its collection time and the policy that applied then |
| New exclusion, lower rate allowance, or narrower allowed method | Jobs using that method and shared worker budgets until their configuration matches the reviewed rule | Passive observations and hypotheses, labeled with their review status |
| Repository branch, product edition, deployment or contract implementation changes | Assumptions about affected versions, reachability and the proof environment | The original pinned reproduction; do not silently relabel it as the new version |
| Reward table, submission cap, deposit, KYC or proof requirements change | Commercial selection and submission readiness; read any transition/grandfathering language | Testing permission, only if the relevant policy still grants it independently |
| Policy cannot be loaded or two official instructions conflict | Actions whose permission depends on the missing or contradictory information | A `needs clarification` decision; absence of a readable page is not evidence of permission |

For example, Bugcrowd distinguishes an invitation received while an engagement is launching from an engagement that is in progress. GitHub’s July 2026 bounty announcement explicitly distinguished reports before and after its effective date. Treat such timing rules as program-specific evidence, rather than assuming every policy update retroactively changes earlier reports. [Bugcrowd invitation and engagement timing](https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/), [GitHub transition terms](https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/).

- [ ] The decision records policy URL, retrieval time, effective date when stated, asset/environment and planned action.
- [ ] A relevant change suspends affected queued jobs until reviewed.
- [ ] Previously collected evidence retains its original version and timestamp.
- [ ] Testing permission, open reporting intake and funded reward status are updated independently.
- [ ] Any unresolved question names the exact rule or action that needs clarification.

## References

- Foudil, E., and Y. Shafranovich / IETF. [RFC 9116: A File Format to Aid in Security Vulnerability Disclosure](https://www.rfc-editor.org/rfc/rfc9116.html). April 2022; accessed 11 September 2026. Used for security.txt location, scope and lack of implied testing permission.
- HackerOne. [Gold Standard Safe Harbor Statement](https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement). 11 August 2025; accessed 11 September 2026. Used for third-party and policy-compliance limits.
- Uploaded all.txt. Local supplied copy; accessed 11 September 2026. Used only for line-level inventory analysis; no public URL or authorization evidence.


---

<a id="page-operations"></a>

# Operating playbook

The workflow below applies to a repository, a private SaaS account, a mobile artifact, a local chain fork, or a device. Branch-specific techniques come after the common admission and evidence gates. The gates and time-boxes are recommended research practices; the target's policy supplies the actual authorization requirements.

## Stage gates

| Stage | Inputs | Actions | Output | Exit gate |
|---|---|---|---|---|
| 0. Admit | Official program policy and asset | Check eligibility, scope, techniques, disclosures and rewards | Scope record | No unresolved permission question for the intended action |
| 1. Prepare | Approved asset, identity, artifact | Pin versions; isolate lab; prepare synthetic data; record tool configuration | Reproducible environment | Clean reset and normal baseline work |
| 2. Model | Product docs, source, traffic, architecture | Identify actors, resources, state machines, trust boundaries and dependencies | Attack-surface and ownership map | Each prioritized boundary has a concrete entry point |
| 3. Hypothesize | Boundary map and observations | Write condition→action→violation→impact hypotheses; prioritize | Hypothesis backlog | Each hypothesis has a control and a stop condition |
| 4. Test | One hypothesis, allowed actions | Observe baseline; change one factor; compare; check side effects | Evidence and result | Confirmed, disproved, blocked, or needs a specific next test |
| 5. Validate | Candidate evidence | Reset, minimize, reproduce, inspect prerequisites, assess impact | Minimal PoC | Claimed boundary and affected asset are supported |
| 6. Report | Reproduction and policy | Write exact steps, evidence, impact, severity rationale, disclosure notes | Submitted report | Program can reproduce without guessing |
| 7. Follow through | Triage questions or fix | Answer, clarify, retest when authorized, coordinate disclosure | Resolution and learning | Cleanup and records completed |

## Model actors, resources, and state

Start with **actor → entry point → authorization decision → operation → resource → consequence**. Source review can expose the authorization decision directly; black-box testing uses controlled comparisons to infer behavior. Background jobs, exports, callbacks and notifications deserve their own rows because they may act under different identities.

For a multi-tenant application, prepare two tenants you control, an owner and restricted member in one tenant, and at least one account in the second tenant when allowed. Mark where roles are not available instead of pretending full coverage. Use synthetic documents, messages, payments in sandbox mode, and other reversible fixtures.

| Actor / state | Own resource | Same-tenant restricted resource | Other controlled tenant | Deleted/revoked/shared resource |
|---|---|---|---|---|
| Anonymous | As designed | Denied unless intentionally public | Denied unless intentionally public | Check intended public semantics |
| Restricted member | Only permitted operations | Role-limited | Denied | Recheck every state transition |
| Tenant owner | Tenant-scoped management | Tenant-scoped management | Denied | No restoration of revoked authority |
| Background job / service identity | Explicit delegated authority | Explicit delegated authority | No implicit cross-tenant access | Current permission or documented snapshot semantics |

The table is a starting model, not a universal expected result. A sharing product can intentionally allow cross-tenant access. Record the intended business rule before labeling the observation a vulnerability.

## Write useful hypotheses

Weak: “Check IDOR.” Useful: “A member of tenant B can retrieve tenant A's private export by replacing the export ID after it is created, because the download handler may validate the signed URL but omit tenant ownership.” Test only with tenant A and B under your control, using the real intended sharing rules as the baseline.

Weak: “This parser is dangerous.” Useful: “An unauthenticated import reaches a parser that accepts external resource references before the import permission check; a local callback should distinguish actual resource retrieval from a syntax error.” The callback must be permitted and contain no sensitive data.

Weak: “The model ignores instructions.” Useful: “A retrieved document controlled by a lower-privilege user can cause an agent to invoke a tool using another user's authority without the required confirmation.” A trace showing the prohibited action and the applicable authorization expectation is necessary.

## Prioritize by expected research value

Score each candidate from 0–3 for boundary importance, attacker reachability, evidence of a missing guard, novelty, and reproducibility. Subtract 0–3 for access/setup cost and duplicate likelihood. This original heuristic is useful for ordering work; it is not a probability model and should not replace judgment.

Start with high-value ownership, privileged workflow, import/export, identity recovery, integration, update, and trust-transition paths. Use scanner leads when they point to those boundaries. Defer expensive broad fuzzing until the scope, parser, harness and expected security consequence are clear.

## Define coverage before selecting tools

Create one row per **security-relevant operation**, not just one row per URL. Record its entry points, actors, object owners, lifecycle states, and downstream consumers. A single endpoint can contain several security decisions; several endpoints can share one decision. An absent UI button does not establish that an API action is forbidden.

Use this completion rule: each prioritized boundary has a successful control, a negative control or a documented reason it cannot be performed, a result, and an evidence reference. For deferred work, record the exact prerequisite or next test. Do not convert a checklist tick, a scanner's zero findings, or the manual's coverage chart into an assertion that an entire feature is secure.

| Coverage dimension | Questions to include | Typical missed variant |
|---|---|---|
| Identity lifecycle | Before enrollment, after recovery, after suspension, after revocation | Existing API key or refresh token survives deprovisioning |
| Resource lifecycle | Draft, published, shared, moved, archived, deleted | An export or cache preserves an earlier permission decision |
| Execution time | At request, enqueue, execution, delivery, and later retrieval | A worker checks a different object or obsolete authority |
| Input representation | URL, JSON, form, batch, protocol, normalization | Two parsers disagree on the effective parameter |
| External interaction | Incoming event, outbound call, retry, reconciliation | A valid webhook belongs to a different tenant |
| Resource budget | Per request, actor, tenant, recipient, and background job | A small batch triggers work beyond a request-rate limit |

The [shared-module matrix](#page-coverage) helps choose procedures. Use the [coverage record](#page-templates) to store actual outcomes. For cost, availability, and sensitive workflow abuse, use the [resource-budget procedure](#page-modules-resource-budget-controls); keep these tests in a bounded local fixture unless the program expressly permits the proposed production experiment.

## Testing controls

Use a successful legitimate baseline, a prohibited baseline, and the proposed bypass. Keep identity, resource, configuration, version, and time recorded. An HTTP `200` does not prove successful access; inspect the returned synthetic marker or changed state. A `403` does not prove no side effect; verify the controlled resource if a state change might have occurred.

For asynchronous operations, record task IDs, callbacks, polling observations, and the identity under which processing occurs. For races, reproduce deterministically in a local harness first where possible; live concurrency needs program permission and a small bounded test. For crashes, distinguish invalid input handling, process termination, recoverability, and exploitable memory or isolation consequences.

## Automation architecture

Automate repeatable collection and bookkeeping first. Keep candidate discovery, authorization review, execution, evidence storage, and human validation as separate transitions. A target extracted from source, a redirect, a package dependency, or a model response must not enter the active queue automatically.

| Component | Responsibility | Required constraint |
|---|---|---|
| Policy record | Store exact policy and approved action set | Versioned, reviewed, and invalidated by changes |
| Candidate collector | Gather hostnames, routes, files, artifacts, dependencies | Discovery output remains unapproved |
| Scope evaluator | Normalize and match asset + action + environment | Deny unresolved or excluded cases; never guess ownership |
| Planner | Choose approved probes and explicit test hypotheses | Bound rate, concurrency, retries, time and destination |
| Executor | Run pinned tools in isolated contexts | No scope expansion through redirects, DNS changes, callbacks or generated commands |
| Evidence store | Preserve raw results, versions, timestamps and hashes | Access control, redaction, retention and separation of program data |
| Normalizer | Convert tool-specific results into common records | Preserve original evidence and avoid merging distinct vulnerabilities |
| Validator | Confirm reachability, controls, eligibility and impact | Human review before report submission |

Maintain an explicit status vocabulary: `candidate`, `approved`, `queued`, `running`, `needs-validation`, `confirmed`, `false-positive`, `duplicate-lead`, `blocked`, `reported`, `resolved`. Failed tools and untested paths must not become “clean” results. Rate budgets apply across workers, not independently per process; retries must consume the same budget.

AI can summarize source, suggest hypotheses, map routes, and draft reports, but its claims need evidence. Treat repository text, issue content, target pages, tool descriptions, and scan output as untrusted input. Do not let such content rewrite the scope policy, choose new destinations, disclose credentials, or publish findings. Keep private-program data out of external services unless the applicable rules permit that processing.

## Report structure

Lead with a specific title: **“Tenant member can download another controlled tenant's private export through missing ownership check.”** Follow with affected asset/version, starting privilege, expected behavior, actual behavior, reproducible steps, evidence, and concrete impact. Include the smallest PoC that proves the boundary; distinguish demonstrated consequences from possible follow-on impact.

Use the platform's required severity rubric. If submitting CVSS, provide the version and vector as well as the score, and explain assumptions. CVSS Base describes intrinsic vulnerability severity, not a complete organizational risk estimate or guaranteed payout. [FIRST CVSS v4.0 specification](https://www.first.org/cvss/v4.0/specification-document), [CVSS v4.0 user guide](https://www.first.org/cvss/v4.0/user-guide).

Check public advisories, prior disclosed reports, supported versions, and program exclusions before submission. A public fix does not automatically make a new variant a duplicate, and a different endpoint does not automatically make the same root cause a new issue. Explain the distinction and let the program apply its duplicate policy.

## Triage and disclosure

Answer questions with evidence and concrete reproduction changes. If a result depends on a non-default option, paid edition, proxy configuration, physical access, privileged starting account, or obsolete release, state that early. If severity is disputed, clarify the attacker capability and observed impact instead of repeating a score.

For an OSS finding, use the project's private security reporting route or coordinated disclosure channel. Discuss affected ranges, a fix, advisory ownership and CVE assignment with the maintainer or applicable CNA. CVE identifies a vulnerability record; it does not guarantee a reward or determine program acceptance. The CVE Program maintains the CNA operational rules. [CNA Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules).

Do not infer a universal disclosure deadline. Follow the program terms and explicit coordination. If there is no response, use the stated escalation process or a suitable coordinator without publishing exploit details by default. Keep private invitations, target names, reports and artifacts confidential until disclosure is permitted.

## Retest and close

Recheck scope before retesting. Repeat the original minimal case, verify expected behavior, and inspect closely related variants only when authorized. Separate a regression from an independent flaw and record tested fixed versions. Remove synthetic data, revoke test tokens, shut down callbacks and lab resources, and retain only the evidence required by your records and program terms.

Record retest results for the original entry point, a legitimate neighboring operation, and any other caller of the corrected guard that is both relevant and authorized. A returned error is insufficient if a queued side effect still occurs. If the fix changes token revocation, account linking, cache ownership, or update verification, include the corresponding lifecycle boundary. When a variant remains untested, list it explicitly instead of claiming the patch closes the entire vulnerability family.

End each hunt with a small retrospective: what boundary mattered, which assumption failed, what evidence eliminated a false positive, and what reusable query or technique is worth keeping. Do not carry confidential details into reusable public templates.

## References

- FIRST. [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document), document version 1.2; accessed 11 September 2026. Used for severity characteristics and metric groups.
- FIRST. [CVSS v4.0 User Guide](https://www.first.org/cvss/v4.0/user-guide), version 1.2, 14 November 2025; accessed 11 September 2026. Used for Base severity versus risk and score/vector presentation.
- CVE Program. [CNA Operational Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules), version 4.1.0, effective 14 May 2025; accessed 11 September 2026. Used for CVE/CNA coordination context.


---

<a id="page-oss"></a>

# OSS repositories and self-hosted products

Repository hunting succeeds when source access becomes a reproducible explanation of an attacker crossing a security boundary. An unsafe function, dependency advisory, or permissive setting is a lead. A strong report connects an eligible released version, attacker-controlled input, reachable behavior, missing control, and observable impact. Audit the application and the machinery that builds and distributes it as two connected attack surfaces.

## Choose the correct research route

| Route | Establish before investing | Useful deliverable |
|---|---|---|
| OSS product with a bounty | Exact repository, branches/releases, supported configurations, eligible vulnerability classes, disclosure channel, and current reward rules | Local reproduction on an eligible release with product-level impact |
| OSS project accepting disclosure | `SECURITY.md`, private reporting availability, supported versions, maintainer contact | Coordinated vulnerability report; payment is not implied |
| Vendor-hosted service with public source | Whether the repository and live service are separately in scope; deployed-version uncertainty | Source-supported hypothesis, followed only by permitted service testing |
| Self-hosted deployment in an authorized program | Deployment owner, deployment-specific scope, edition, settings, plugins, and versions | Finding against that deployment with product/configuration attribution |
| Private source-assisted assessment | Permission to possess and process code, approved tooling/storage, branches, environments, third-party exclusions | Evidence retained within the agreed confidentiality boundary |
| Library, SDK, parser, CLI, or agent | Supported consumers, caller contract, attacker-controlled inputs, local versus remote impact | Minimal consumer/harness demonstrating the violated contract |

A public repository does not extend a program's scope to its maintainers' infrastructure, package registries, customers, or public deployments. A locally reproduced product vulnerability does not establish that every deployed instance is affected. If payment matters, capture the current program's eligibility terms before starting; a CVE and a bounty are separate outcomes. GitHub offers private vulnerability reporting only where maintainers enable it, and repository advisories support private discussion and fixes. [GitHub: private reporting](https://docs.github.com/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability), [repository advisories](https://docs.github.com/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories).

## Staged playbook

The following gates are recommended operating criteria, not platform-imposed requirements.

| Stage | Inputs and actions | Evidence | Exit gate |
|---|---|---|---|
| 1. Qualify | Read policy, supported versions, prior advisories, release notes, architecture, installation requirements | Scope snapshot, repository identity, likely audit themes | An eligible version and confidential reporting route exist |
| 2. Freeze | Preserve commit SHA, release tag, lockfiles, submodules, image digests, tool versions | Reproduction manifest and source inventory | Another researcher can identify the same inputs |
| 3. Build the lab | Review build scripts; install in a disposable VM; create synthetic users, tenants, data, and dependencies | Clean snapshot, config delta, health check, reset procedure | Normal workflows work and unintended egress is blocked |
| 4. Map | Trace entry points, authentication, authorization, queues, storage, integrations, and deployment boundaries | Data-flow map and role/resource matrix | Each priority feature has a known entry and protected operation |
| 5. Form hypotheses | Combine manual review, local scans, advisory review, and changed-code inspection | Ranked hypotheses with source paths and required assumptions | Each candidate states a falsifiable security invariant |
| 6. Validate | Exercise the smallest synthetic case; inspect call path; compare an authorized control | Sanitized requests, outputs, trace, before/after state | Impact reproduces without changing unrelated security controls |
| 7. Audit delivery | Review dependency, build, workflow, package, image, and IaC paths | Separate reachability and privilege chains | Supply-chain claims have a concrete consumer or privileged sink |
| 8. Report and retest | Minimize reproduction, bound versions, suggest fix, privately submit, retest patch | Report package and updated validation matrix | Recipient can reproduce; remaining assumptions are explicit |

## Reproducible lab design

Treat unfamiliar repositories and their dependency installation as executable input. Review Dockerfiles, Compose, Makefiles, lifecycle scripts, build backends, development-container settings, and CI scripts before invoking them. Use a disposable VM for untrusted builds; containers within it help reproduce services but are not a reason to expose the host Docker socket, SSH agent, cloud credentials, or personal home directory.

Separate the preparation phase, where reviewed dependencies and databases are downloaded, from the test phase. Bind application ports to loopback. Create synthetic tenant A and B, ordinary and privileged accounts, a local mail catcher, and local callback/file-storage services. Block external egress during exploit validation; replace integrations with controlled fixtures. Preserve a working baseline before modifying configuration.

Record environment differences explicitly: community versus enterprise edition, reverse proxy behavior, authentication mode, enabled plugins, database backend, OS/architecture, and documented deployment topology. An attack that depends on `DEBUG`, disabled authentication, or a deliberately exposed administrator interface has different prerequisites from one affecting the supported production setup. A dangerous default or documented deployment recipe can be a legitimate product issue; demonstrate the actual boundary and check program policy.

## Application and source audit

Start with business capabilities, then inspect implementation. OWASP emphasizes manual review for application logic, data flows, and contextual flaws that automated tools can miss. Use scanning to prioritize code; manually establish the security argument. [OWASP: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html).

For each feature, write one invariant: “a project member can retrieve documents only from projects they belong to,” or “an import cannot create files outside its assigned directory.” Trace both forward from attacker-controlled inputs and backward from sensitive operations. The intersection is your candidate path.

| Area | Trace precisely | Proof target |
|---|---|---|
| Authentication | Login, password reset, invitations, SSO callbacks, token issuance/refresh, revocation | A synthetic principal acquires or retains an unintended identity/session |
| Object/tenant authorization | Route → actor resolution → queryset/service → object → tenant/role check | Account A accesses a fixture owned by B through the real handler |
| Privileged actions | UI restriction versus server policy; API variants, bulk endpoints, background jobs | A lower role performs an operation reserved for a higher role |
| Injection | Input parsing → transformations → ORM/raw query, process, template, evaluator, interpreter | Input changes interpretation at the sink under supported conditions |
| Files and archives | Upload name/content → normalization → extraction → symlink handling → persistence → serving | A synthetic file crosses an intended path or content boundary |
| Outbound requests | URL parsing → scheme/host validation → DNS/redirect handling → fetch → response exposure | The application reaches a blocked local fixture or returns prohibited fixture content |
| Asynchronous work | Job creation → serialized actor/context → queue → worker → retry | A worker loses the initiating user's authorization context or repeats a protected effect |
| Concurrency | Read/check/write sequence, transaction boundaries, locks, uniqueness, idempotency | Two bounded local operations violate an explicit invariant |
| Extensions and AI features | Plugin/tool selection, retrieval ownership, instruction/data boundary, delegated credentials | Lower-trust content causes a demonstrably unauthorized tool or data action |

**Authentication and authorization require separate proofs.** A valid JWT says little about whether a user owns the requested object. Check where tenant identity originates, whether membership is current, whether query scoping survives joins and bulk operations, and whether subsequent service calls replace validated identifiers. Inspect alternate endpoints, download URLs, exports, websocket handlers, and scheduled tasks that share the same service.

**Taint analysis is a model.** Define sources, propagators, sanitizers, and sinks for the actual framework and wrappers. A sanitizer is valid only for the destination context; HTML escaping does not establish filesystem containment. An authorization guard is not equivalent to value sanitization. Validate your rule against a vulnerable fixture and a safe sibling. Semgrep documents these modeling components; its CE analysis does not provide every interprocedural/interfile capability available in paid engines. [Semgrep: taint analysis](https://docs.semgrep.dev/writing-rules/data-flow/taint-mode/overview), [CLI capabilities](https://docs.semgrep.dev/cli-reference).

**Reachability is the decisive filter.** Record the entry point, attacker role, call sequence, feature flag, build inclusion, configuration, and guard outcomes. Dead code, administrator-only extension loading, a debug-only helper, and a low-privilege production route are different findings. A negative scanner result is not proof that a route is safe. For dynamic dispatch, generated code, reflection, framework magic, or runtime plugin resolution, explain what static analysis did not cover.

**Prove the real execution path.** A unit-level demonstration that calls an internal helper directly may bypass the very authorization check being assessed. Begin with the supported application interface when claiming application impact. Use instrumentation to explain the path, but reproduce again with security behavior unchanged. Keep the authorized control case beside the failing case.

## Dependencies, secrets, and delivery infrastructure

Give this work its own review pass. Application SAST does not examine who can alter a release, which registry supplies dependencies, or whether a worker image contains additional vulnerable components.

### Dependencies and packaged artifacts

Build separate inventories for source/lockfiles, installed runtime dependencies, build/test tooling, and final images or release archives. Record package ecosystem, name, resolved version, origin, direct/transitive relationship, and shipped artifact. An SBOM records composition; a vulnerability matcher associates known advisories. Neither alone proves exploitability. Syft generates SBOMs; OSV-Scanner extracts package information and matches it against vulnerability records. [Syft](https://github.com/anchore/syft), [OSV-Scanner usage](https://google.github.io/osv-scanner/usage/).

For each advisory, establish: affected version range, relevant API or feature, application call path, attacker-controlled argument, necessary configuration, deployed inclusion, and security impact. Check distro backports and vendored modifications. A package in a development dependency may affect the build pipeline without shipping in the application; keep those impact stories separate. Avoid submitting “old package version” when the program requires a demonstrated vulnerable use.

For dependency confusion, inspect scoped registry mappings, fallback behavior, namespace ownership, lockfile integrity, URL dependencies, install hooks, and privileged build context. Reproduce resolution behavior using a local registry and synthetic package names. Do not claim real package names, publish to public registries, or trigger target builds as an assumed extension of repository scope.

### Secrets

Inspect the working tree and available Git history separately, including release archives and readable build configuration. Classify a finding as fixture, public identifier, non-secret material, or plausible credential. Preserve the file path, commit, secret type, relevant context, and a redacted fingerprint. Ask the owner to validate and rotate plausible exposed credentials; do not log in with them or call provider validation endpoints. Gitleaks' modern interfaces are `git`, `dir`, and `stdin`; `detect` and `protect` are deprecated. Redaction is not a substitute for reviewing exported evidence. [Gitleaks official documentation](https://github.com/gitleaks/gitleaks).

### CI/CD and GitHub Actions

For each workflow, trace **event actor → attacker-controlled data/code → executed step → token/environment privilege → release or deployment effect**. Enumerate workflow triggers, reusable workflows, local/composite actions, shell interpolation, downloaded artifacts, cache consumers, package-install hooks, credentials, runner isolation, and deployment approvals. Review the action implementation at the pinned revision. GitHub recommends minimum token permissions and immutable commit-SHA action references. [GitHub: secure use](https://docs.github.com/en/actions/reference/security/secure-use).

`pull_request_target` or `workflow_run` is a review signal, not a complete vulnerability. Determine whether untrusted code or artifacts are actually executed and which privileges are available. Current GitHub documentation describes checkout protections and cache restrictions for `pull_request_target`; inspect the exact action revision, explicit opt-outs, repository settings, and observed behavior instead of assuming older examples still reproduce. Use a private/local fixture with inert marker output and dummy credentials; request a maintainer-assisted run if real workflow behavior is necessary. [GitHub: event semantics](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows), [securely using pull_request_target](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target).

### Registries, signing, images, and IaC

Map repository permissions to release tags, build inputs, artifacts, registry publishing, and deployment identities. Examine whether untrusted material can enter after review or before signing. Verify provenance against the expected source and builder; authenticated provenance does not prove application correctness. For OIDC, inspect issuer, audience, repository/workflow identity, branch/environment conditions, and the actual role permissions. GitHub's AWS guidance specifically calls for evaluation of the token subject to restrict trusted workflows. [GitHub: OIDC in AWS](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws).

Trusted publishing removes reliance on long-lived publish credentials, but its security depends on the configured trusted workflow. Inspect publisher settings and legacy token fallback instead of treating an OIDC badge as sufficient. npm documents workflow identity restrictions; PyPI explicitly analyzes how compromised workflows can affect trusted publishers. [npm: trusted publishing](https://docs.npmjs.com/trusted-publishers/), [PyPI: security model](https://docs.pypi.org/trusted-publishers/security-model/).

Compare the final image with source expectations: inherited packages, copied secrets, build layers, entrypoint privilege, capabilities, host mounts, and update mechanism. Review IaC defaults, exposed services, wildcard IAM, cross-tenant storage, secret injection, and metadata-service assumptions. A scanner's root-user or wildcard-policy finding becomes a bounty candidate only when it violates an applicable security expectation with defensible impact. Preserve the relevant rendered configuration rather than reporting a template variable whose deployed value is unknown.

## Parsers, native code, and fuzzing

Choose a narrow parser or state transition with realistic attacker input. First reproduce normal usage through its public API. Build an in-process harness that resets state, bounds input size, avoids network/disk side effects, and instruments relevant code. Seed it with a small representative corpus, add format dictionaries when useful, and use ASan/UBSan where appropriate. Track coverage growth, unique root causes, and minimized reproducers rather than raw crash totals. LLVM documents libFuzzer corpus handling, runtime/resource bounds, and crash minimization. [LLVM: libFuzzer](https://llvm.org/docs/LibFuzzer.html).

Confirm that a crash belongs to the target rather than your harness. Reproduce on the eligible build, minimize the input, deduplicate by root cause, and identify whether the outcome is memory corruption, bounded parsing failure, or resource exhaustion. State remote/local exposure through a real consumer. Do not convert a local crash into an unsupported remote-code-execution claim; do not fuzz live shared services under this local workflow.

## Patch analysis, reporting, and CVEs

Read security patches to identify the invariant being restored, then inspect equivalent call sites, alternate encodings, older supported branches, and duplicated helpers. Patch-diff work is valuable for learning and identifying incomplete fixes; reproducing an already-disclosed issue may be ineligible or duplicate. Record which version introduced the flaw, which tested versions remain affected, and which patch actually prevents the behavior.

A report package should contain the exact source revision and product version, supported setup, minimal configuration delta, attacker role, reproduction steps, expected/actual results, root-cause path, affected-version evidence, demonstrated impact, and a focused remediation suggestion. Provide synthetic fixture data and a minimal local PoC. For retesting, compare the vulnerable case, authorized behavior, and a nearby variant; report remaining uncertainty instead of extrapolating a version range.

Use the private channel specified by the program or maintainers. Coordinate an advisory and disclosure timing. GitHub allows maintainers to request a CVE within the repository advisory workflow when they do not already have one; requesting an identifier is separate from proving eligibility or earning payment. [GitHub: publishing advisories and requesting a CVE](https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory).

## Local command cheat sheet

Examples target only an existing local `./repo`; they have not been executed against a target. Create `./evidence` first and keep it outside the scan root. Preinstall pinned tool versions, inspect inherited configurations, and prepare required rules/databases/packs in a separate connected preparation phase. Run private-code analysis with network egress blocked. Scanner exit codes can represent findings or execution failures; preserve stderr and classify the outcome before interpreting the report.

**1. Freeze the source identity.** [Git reference](https://git-scm.com/docs/git-rev-parse).

```bash
git -C ./repo rev-parse --verify HEAD > ./evidence/commit.txt
```

**2. Inventory source and hidden configuration without reading Git objects.** [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md).

```bash
rg --files --hidden -g '!.git' ./repo > ./evidence/files.txt
```

**3. Run reviewed local Semgrep rules.** No registry rules are fetched by this command. [Semgrep CLI](https://docs.semgrep.dev/cli-reference).

```bash
semgrep scan --oss-only --config ./rules --metrics=off \
  --disable-version-check --sarif \
  --output ./evidence/semgrep.sarif ./repo
```

The CE engine uses LGPL-2.1; Semgrep-maintained registry rules have a separate Semgrep Rules License, and third-party rules have their own licenses. Internal research and embedding rules into a commercial scanning service are different uses. Prefer original local rules or rules whose terms fit the intended use. [Semgrep licensing](https://docs.semgrep.dev/licensing), [Rules License](https://semgrep.dev/legal/rules-license/).

**4. Review local Git history for secrets.** A shallow clone limits historical coverage. Inspect the output before sharing. [Gitleaks](https://github.com/gitleaks/gitleaks).

```bash
gitleaks git ./repo --redact=100 --report-format json \
  --report-path ./evidence/gitleaks.json
```

**5. Inventory local packages.** [Syft output formats](https://oss.anchore.com/docs/guides/sbom/formats/).

```bash
syft dir:./repo -o cyclonedx-json=./evidence/sbom.cdx.json
```

**6. Match dependencies using previously cached OSV ecosystem databases.** Full `--offline` prevents network use; `--offline-vulnerabilities` alone still permits other network features. Offline mode lacks commit-level matching. [OSV source scanning](https://google.github.io/osv-scanner/usage/scan-source), [offline mode](https://google.github.io/osv-scanner/usage/offline-mode/).

```bash
osv-scanner scan source --offline -r --format json \
  ./repo > ./evidence/osv.json
```

**7. Inspect dependencies and IaC with prepared Trivy databases/checks.** These flags independently disable online resolution, updates, notices, and telemetry. Missing caches or unsupported flags on older releases require preparation/version correction, not silent fallback to online scanning. [Trivy filesystem CLI](https://trivy.dev/docs/latest/references/configuration/cli/trivy_filesystem/).

```bash
trivy fs --scanners vuln,misconfig --offline-scan \
  --skip-db-update --skip-java-db-update --skip-check-update \
  --skip-version-check --disable-telemetry \
  --format json --output ./evidence/trivy.json ./repo
```

**8. Create and query a Python CodeQL database.** Requires a prepared local query suite and its dependencies; language/build setup differs for other projects. [Database preparation](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/prepare-code-for-analysis), [analysis](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/analyze-code).

```bash
codeql database create ./evidence/codeql-python \
  --language=python --source-root=./repo
codeql database analyze ./evidence/codeql-python \
  ./queries/python-security.qls --format=sarif-latest \
  --output=./evidence/codeql.sarif
```

CodeQL is free for public repositories under its terms. Private organization repositories require the applicable GitHub plan and GitHub Code Security license; possession of source does not grant unrestricted CodeQL use. The query libraries' open-source license does not replace the CLI terms. [GitHub: CodeQL availability and license](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-cli).

## Exit checklist

- [ ] Repository, product edition, version, scope, and reporting channel recorded.
- [ ] Working baseline, synthetic identities, reset procedure, and config delta preserved.
- [ ] Priority entry points mapped to authentication, authorization, and sensitive operations.
- [ ] Every promoted finding has attacker control, reachability, prerequisites, and impact evidence.
- [ ] Source, runtime, build, and shipped dependency inventories distinguished.
- [ ] Secrets redacted; no discovered credential used for verification.
- [ ] CI events, artifact/cache consumers, publishing identity, images, and IaC reviewed.
- [ ] Scanner errors, excluded files, stale databases, and unresolved models recorded.
- [ ] Local PoC minimizes side effects and includes a legitimate control case.
- [ ] Prior advisories checked; tested versions distinguished from inferred versions.
- [ ] Report and patch retest can be reproduced from preserved inputs.

## GitLab and provider-specific CI branches

The shared release audit applies to GitLab, but GitHub event names and defaults do not transfer directly. Use [GitLab pipeline boundaries](#page-modules-gitlab-pipeline-boundaries) to trace the configuration revision, execution project, trigger actor, protected resources, job tokens, downstream inputs and runner state. Keep these three identities separate in the report; a merge request does not by itself prove execution with parent-project authority.

For jobs that deploy into Azure or GCP, continue through [provider-specific identity and storage boundaries](#page-modules-azure-gcp-boundaries). Record the exact token-to-cloud-principal binding and final synthetic resource operation. A cloud login inside a CI job is one edge in the chain, not a complete release or tenant-isolation proof.

## Source registry

All sources were accessed on **2026-09-11**. Unless a date is listed, the cited documentation is undated/living documentation; tool and service behavior must be checked again when used.

| Publisher | Source | Publication/update date | Supports |
|---|---|---|---|
| OWASP | [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) | Undated | Manual review, logic/data-flow emphasis |
| GitHub | [Privately reporting a vulnerability](https://docs.github.com/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability) | Undated | Private reporting availability |
| GitHub | [Repository security advisories](https://docs.github.com/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories) | Undated | Private collaboration/disclosure |
| GitHub | [Publishing an advisory](https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory) | Undated | CVE request workflow |
| Semgrep | [Taint analysis](https://docs.semgrep.dev/writing-rules/data-flow/taint-mode/overview) | Undated | Sources, sinks, propagators, sanitizers |
| Semgrep | [CLI reference](https://docs.semgrep.dev/cli-reference) | Undated | Local rules, flags, engine capabilities |
| Semgrep | [Licensing](https://docs.semgrep.dev/licensing) and [Rules License](https://semgrep.dev/legal/rules-license/) | Undated | CE and rule licensing distinctions |
| Gitleaks maintainers | [Official repository documentation](https://github.com/gitleaks/gitleaks) | Undated | Current commands, history, redaction |
| Anchore | [Syft](https://github.com/anchore/syft) and [output formats](https://oss.anchore.com/docs/guides/sbom/formats/) | Undated | SBOM inventory and output syntax |
| Google | [OSV usage](https://google.github.io/osv-scanner/usage/), [source scanning](https://google.github.io/osv-scanner/usage/scan-source), [offline mode](https://google.github.io/osv-scanner/usage/offline-mode/) | Undated | Version matching, recursion, offline limits |
| Aqua Security | [Trivy filesystem reference](https://trivy.dev/docs/latest/references/configuration/cli/trivy_filesystem/) | Undated | Scanners and individual offline/update flags |
| GitHub | [Secure use reference](https://docs.github.com/en/actions/reference/security/secure-use) | Undated | Least privilege, immutable action references |
| GitHub | [Workflow events](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) and [pull_request_target guidance](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target) | Undated | Event trust boundaries and current protections |
| GitHub | [OIDC in AWS](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws) | Undated | Subject/identity restrictions |
| npm | [Trusted publishing](https://docs.npmjs.com/trusted-publishers/) | Updated 2026-09-03 | Publisher identity and authentication |
| Python Package Index | [Trusted publisher security model](https://docs.pypi.org/trusted-publishers/security-model/) | Undated | Workflow compromise and publishing trust |
| LLVM Project | [libFuzzer](https://llvm.org/docs/LibFuzzer.html) | Undated | Harness, corpus, bounds, minimization |
| GitHub | [CodeQL CLI](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-cli), [database preparation](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/prepare-code-for-analysis), [analysis](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/analyze-code) | Undated | Eligibility and local CLI workflow |
| Git Project | [git-rev-parse](https://git-scm.com/docs/git-rev-parse) | Undated | Commit identity command |
| Andrew Gallant/ripgrep contributors | [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md) | Undated | Local file inventory flags |


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.
- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.
- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.
- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.
- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.
- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.
- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function)
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property)
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection)
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass)
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary)
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection)
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow)
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change)
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read)
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation)
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution)
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape)
- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input)
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response)
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization)
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz)
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization)
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking)
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials)
- [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection)
- [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution)
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning)
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution)
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos)
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files)
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path)
- [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope)
- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read)
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write)
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope)
- [Kubernetes Secret access exceeds tenant permissions](#page-vulnerabilities-kube-secret-rbac-exposure)
- [Workload creation grants unintended service-account authority](#page-vulnerabilities-kube-workload-identity-selection)
- [Admission policy misses a supported object or update path](#page-vulnerabilities-kube-admission-policy-gap)
- [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure)
- [Sensitive values exposed through state or plan artifacts](#page-vulnerabilities-iac-state-secret-exposure)
- [Secrets retained in container build artifacts](#page-vulnerabilities-container-build-secret-leak)
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default)
- [Redis authentication or key ACL boundary failure](#page-vulnerabilities-redis-canary-access)
- [PostgreSQL trust authentication exceeds the approved network boundary](#page-vulnerabilities-postgres-unintended-trust-auth)
- [Message broker permissions cross a virtual-host boundary](#page-vulnerabilities-queue-virtual-host-boundary)
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth)
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate)
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact)
- [Indirect prompt injection into protected tool actions](#page-vulnerabilities-indirect-prompt-tool-injection)
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization)
- [Agent approval is not bound to executed arguments](#page-vulnerabilities-agent-approval-argument-drift)
- [MCP proxy consent confuses different clients](#page-vulnerabilities-mcp-proxy-confused-deputy)
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion)
- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval)
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak)
- [Contract callback reentrancy violates a state invariant](#page-vulnerabilities-contract-reentrant-state)
- [Contract initializer permits unauthorized ownership or configuration](#page-vulnerabilities-contract-unprotected-initializer)
- [Contract upgrade authority can be bypassed](#page-vulnerabilities-contract-upgrade-authorization)
- [Vault share conversion or rounding breaks entitlement](#page-vulnerabilities-contract-share-accounting)
- [Signed contract action can be replayed unexpectedly](#page-vulnerabilities-contract-signature-replay)
- [Signed action does not bind its intended context](#page-vulnerabilities-contract-signature-context)
- [Oracle freshness or dependency state permits an invalid decision](#page-vulnerabilities-contract-stale-oracle)
- [Oracle denomination or decimal conversion is incorrect](#page-vulnerabilities-contract-oracle-unit-confusion)
- [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation)
- [Firmware security-version state can be lowered](#page-vulnerabilities-firmware-security-version-rollback)
- [Firmware verification fails to enforce required product binding](#page-vulnerabilities-firmware-product-binding)
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials)
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret)
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust)
- [Clickjacking of a sensitive authenticated action](#page-vulnerabilities-clickjacking-sensitive-action)
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust)
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure)
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness)
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash)
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing)
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust)
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass)
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure)
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion)
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass)
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection)
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict)
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection)
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure)
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding)
- [GitLab job token crosses an unintended project boundary](#page-vulnerabilities-gitlab-job-token-boundary)
- [Shared CI runner exposes private state across jobs](#page-vulnerabilities-ci-runner-cross-job-state)
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority)
- [Delayed extension result reaches a different document](#page-vulnerabilities-extension-document-reply-confusion)
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership)
- [MCP resumed state changes authorization or request meaning](#page-vulnerabilities-mcp-resume-state-integrity)
- [Private MCP result is reused across authorization contexts](#page-vulnerabilities-mcp-private-cache-context)
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect)
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading)
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure)
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit)


---

<a id="page-web-api"></a>

# Web, API, SaaS, and network field manual

Original research cutoff: 11 September 2026; targeted content review: 14 September 2026. Commands below are examples, not scans performed during this research. Operational budgets and report thresholds are recommended field practice; each program's written policy overrides them.

## 1. Turn scope into executable boundaries

Record an authorization tuple for every candidate: `program + asset identifier + owner + environment + scheme/protocol + port + path + permitted accounts + permitted techniques + exclusions + policy timestamp`. Keep **discovered**, **ownership-attributed**, **authorized**, **reward-eligible**, and **tested** as separate states. A CNAME, certificate, repository reference, ASN association, or company logo proves none of the later states by itself.

The following interpretations deliberately avoid silently expanding a program's words. A program-specific definition can broaden or narrow any row.

| Scope expression | Working interpretation | Gate before expansion |
|---|---|---|
| Exact URL `https://app.example.com/report` | Listed scheme, host, port, and resource | Confirm whether query variants, child paths, and sibling routes are covered |
| Path prefix `https://app.example.com/api/v2/` | Listed origin and documented path subtree | `/api/v20`, `/admin`, redirects, alternative encodings, and rewritten paths require independent evaluation |
| Exact hostname `api.example.com` | That hostname, with the program's permitted protocols/ports | Neither siblings nor its resolved IP as a general network target follows automatically |
| Apex `example.com` | The apex hostname | Subdomains are separate unless expressly included |
| Wildcard `*.example.com` | Hostnames matching the policy's wildcard definition | Do not assume apex inclusion, unlimited depth, every port, or third-party hosted services |
| IP `192.0.2.10` | This IP and allowed services | No automatic entitlement to other IPs, other virtual hosts, provider control planes, or every tenant |
| CIDR `192.0.2.0/28` | Addresses within the prefix, subject to exclusions | Verify ownership and service restrictions; no ASN-wide expansion |
| Port `:8443` / TCP / UDP | The specified transport and port | TCP/443 permission does not imply UDP/443, SSH, SMTP, or an origin backend |
| Staging, demo, or sandbox | Named deployment and test account context | Shared identity, payment, telemetry, and production backends remain separate boundaries |
| SaaS tenant / workspace | Authorized tenant and stated cross-tenant test setup | Other customers and vendor infrastructure are not automatically authorized |
| Repository or self-hosted product | Eligible code/version and your controlled deployment | Public deployments of that software need their own authorization |

Implement exclusions before inclusions and fail closed on malformed URLs, credentials in URLs, ambiguous encodings, unsupported schemes, and unresolved ownership. Compare parsed hosts, not substring matches: `example.com.attacker.test` is unrelated to `example.com`. Normalize IDNs and trailing DNS dots consistently. For path-limited scope, record the exact request target and any proxy normalization; do not let an allowlist's normalization disagree with the client that sends the request. Recheck each redirect and every discovered URL before sending a new request.

Use WSTG for testing procedures and ASVS for expected controls. Pin references: the WSTG project identifies 4.2 as a released version and 5.0 as development; ASVS identifies 5.0.0, released 30 May 2025. Neither framework makes every failed control a payable bounty. [OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/), [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/).

## 2. Recon that produces hypotheses

**Pass 1 — third-party discovery.** Read program documentation, public API references, repository references, certificate-transparency results, historical URL indexes, and already collected search-engine/network-index records. Save source and collection time; stale records are leads. Searching an existing Shodan/Censys record is different from requesting a fresh scan. Third-party discovery can disclose the target name to a provider even when it does not probe the target.

**Pass 2 — allowlist review.** Resolve candidates into exact permitted origins/resources. Do not pipe passive output directly into a scanner. Retain excluded and uncertain candidates in a review queue. Separate broad wildcard inventory from a single-app campaign: the latter needs route and workflow discovery more than another million hostnames.

**Pass 3 — active validation.** DNS resolution is a network operation and recursive resolution may reach authoritative infrastructure. HTTP requests, TLS handshakes, screenshots, crawling, directory discovery, port scans, DNS brute force, and vulnerability checks are active. Use the program's identification header and rate limit. If no rate is specified, begin manually; a conservative automation starting point is one worker and at most one request/second, only where automation is permitted. This is a proposed budget, not a universal authorization.

**Pass 4 — application mapping.** Exercise normal workflows through an intercepting proxy. Inventory method, path, operation name, object IDs, role, tenant, side effects, upload/download behavior, integrations, and request source. Compare UI traffic with OpenAPI schemas, SDKs, JavaScript and source maps. Old versions, undocumented operations, export jobs and background tasks become hypotheses, not automatic findings.

```bash
# Third-party discovery only: do not add -active/-nW.
# Review installed config and available provider credentials first.
subfinder -d example.com -silent -o candidates.txt

# Human-reviewed file: exact URLs, explicit schemes and permitted ports.
# Use a reviewed empty YAML config to prevent inherited scan options.
httpx -config scope-httpx.yaml -l approved-origins.txt \
  -nfs -sc -title -location -json -threads 1 -rate-limit 1 \
  -retries 0 -timeout 10 -disable-update-check -o inventory.jsonl

# Single approved URL; -q first ignores inherited curlrc options.
# No -L/--location: inspect any Location before a separate request.
curl -q --proto '=https' --connect-timeout 5 --max-time 15 \
  --dump-header evidence/headers.txt --output evidence/body.txt \
  'https://app.example.com/approved-path'
```

`scope-httpx.yaml` should contain `{}`; `evidence/` must already exist. These commands assume tools are installed. `httpx` here means ProjectDiscovery's binary. Its `-nfs` preserves the input scheme; `-nf` has different behavior. Omit redirect-following, screenshot, TLS-domain, CSP-domain, favicon, additional-port, and extra-path probing flags. `-fhr` limits redirects to the same host, **not** to the same port/path. `-allow/-deny` are IP/CIDR controls, not URL scope enforcement. For exact-path scope, prefer a reviewed single request until client behavior is confirmed. [Subfinder usage](https://docs.projectdiscovery.io/opensource/subfinder/usage), [httpx usage](https://docs.projectdiscovery.io/opensource/httpx/usage), [curl manual](https://curl.se/docs/manpage.html).

Automated vulnerability checks come after mapping. Review each selected template's requests, methods, payload count, redirects, extracted targets, code/headless behavior, callbacks and cleanup. A severity label is not a safety classification. A low rate does not make a destructive request safe. Do not use “run all templates” as a discovery stage.

## 3. Authorization: two identities, two tenants, controlled objects

Create accounts A and B and tenants T1 and T2 where permitted. Initially A owns T1 and B owns T2. Seed distinguishable synthetic objects O1 and O2. For within-tenant checks, temporarily add B to T1 with a documented limited role, then revoke that membership. Use separate browser profiles and token stores. Additional administrator identities improve coverage when available, but are not required to start.

Record expected behavior from documentation and normal use before testing. “Not visible in the UI” alone does not establish a forbidden action. Different status codes are not proof: inspect response data, resulting state, audit events, and eventual background-job output. [PortSwigger access control](https://portswigger.net/web-security/access-control).

| Actor/context | Resource/action | Expected result to validate |
|---|---|---|
| Anonymous | Private O1 read/export | No private content or downloadable artifact |
| A in T1 | O1 normal operations | Authorized baseline succeeds |
| B, T2 only | O1 read, update, delete, share | Denied across tenants |
| B as T1 viewer | O1 modification, invite, billing, token creation | Restricted by role |
| B as T1 member | A's explicitly private object | Restricted by ownership or sharing policy |
| B after removal | Old token, existing socket, queued export | Access follows documented revocation semantics |
| A using T2 identifier | O2 nested resource and batch operation | Server checks tenant/object relation |
| A with restricted API key | Administrator function or forbidden field | Key permissions apply independently of UI permissions |

For each operation, test three independent dimensions: **object** (whose record), **function** (which action), and **property** (which fields may be read or written). Substitute only known IDs from your controlled accounts; include IDs in paths, JSON bodies, query parameters, headers, nested objects, arrays, export IDs, download tokens and WebSocket subscriptions. Verify list/search/count routes as well as direct reads. Do not enumerate strangers' IDs to demonstrate scale.

**Report threshold:** a reproducible violation of the intended permission boundary on controlled data. Save a baseline request, the minimally modified request, both identities' roles, expected rule, response/state evidence and cleanup. **Stop:** once the first unauthorized read/write is proven; do not turn one record into a mass export. If real customer data appears, preserve the minimum necessary metadata and stop that path.

## 4. Protocol branches

| Surface | Focused checks | Evidence and stopping rule |
|---|---|---|
| REST / JSON | Methods, versions, nested resources, server-owned fields, batch operations, pagination, alternate content types | Compare two controlled identities; prove changed server state or private output, not merely HTTP 200 |
| GraphQL | Resolver and field authorization, nodes/global IDs, mutations, subscriptions, aliases with tiny batches | An exposed schema alone is usually a lead; prove forbidden data/action. Avoid depth/complexity exhaustion |
| gRPC | Known `.proto` methods, channel versus per-call credentials, tenant metadata, unary/stream authorization | Capture method, metadata and gRPC status/trailers; HTTP 200 alone says little. Reflection alone is not privilege escalation |
| WebSocket | Handshake authentication, Origin handling, per-message authorization, room subscription, logout/revocation | A controls the sender, B the recipient. Prove unauthorized subscription/action with a marker; stop after one message |

GraphQL introspection helps map a schema, but public APIs may intentionally expose it. Prefer observed operations and small schema queries before broad introspection; authorization still belongs at the resolver/object/field boundary. [PortSwigger GraphQL](https://portswigger.net/web-security/graphql).

gRPC distinguishes channel credentials from call credentials, and reflection exposes service descriptors for tooling. Test the real trust boundary rather than reporting the existence of either mechanism. Avoid assuming a token valid for one service may be forwarded to another. [gRPC authentication](https://grpc.io/docs/guides/auth/), [gRPC reflection](https://grpc.io/docs/guides/reflection/).

WebSocket checks must cover messages after the handshake, including existing connections after membership changes. Cross-site WebSocket hijacking requires a browser-feasible connection and meaningful unauthorized interaction; an accepted arbitrary Origin header in a proxy is insufficient by itself. [PortSwigger WebSockets](https://portswigger.net/web-security/websockets).

## 5. Authentication, federation, and session lifecycle

Build a state diagram in notes: registration → email verification → login → MFA → sensitive reauthentication → recovery → account linking → logout/revocation. Test alternate entry points, mobile/API clients, and identity changes using your own inboxes. Check that a password reset changes the intended account, consumed tokens cannot be replayed, and email changes do not silently inherit an old verified identity.

For sessions, compare pre-login and post-login identifiers, privilege-change rotation, inactivity/absolute expiry, logout, reset, MFA change, device removal, API-key revocation and tenant removal. Distinguish browser logout from server-side invalidation; assess residual validity against promised behavior and impact rather than assuming every token must instantly disappear. [OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).

For OAuth, test authorization-response binding to the initiating browser, exact approved redirect handling, authorization-code reuse, PKCE behavior, account-linking confirmation and issuer mix-up boundaries. Missing `state` alone is not conclusive if another valid binding mechanism exists. RFC 9700 is the current OAuth security BCP, published January 2025. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html), [PortSwigger OAuth](https://portswigger.net/web-security/oauth).

For OIDC, verify signature trust, issuer, audience, expiry and nonce when applicable; distinguish an ID token identifying a user from an access token authorizing API use. For SAML in an authorized test identity provider/service provider setup, examine signature coverage, trusted certificates, audience/recipient/destination, request correlation and assertion replay. **Report threshold:** demonstrate login, linking, privilege or session access as the wrong controlled identity. **Stop:** no identity-provider-wide attacks or takeover of real users. [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html), [OWASP SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html).

## 6. Business logic and bounded concurrency

Write invariants before payloads: “Only an owner can transfer ownership”; “one invitation creates one membership”; “a cancelled subscription cannot create new privileged credentials”; “a discount applies once”; “an export belongs to the requesting tenant.” Trace intermediate states and repeat, reorder, skip or replay one transition at a time. Include asynchronous workers, webhook delivery, stale links, retries, negative/zero quantities, precision/currency conversion, and price inputs where the program provides a nonfinancial sandbox. [PortSwigger business logic](https://portswigger.net/web-security/logic-flaws).

For a race, first run the sequence serially and record the expected state. Preconditions: explicit permission for concurrency, a reversible test object, a way to inspect durable state, and no real money/inventory impact. Start with **two** synchronized requests and a fixed small experiment budget; do not assume this budget is safe for every endpoint. Compare with serial controls and inspect committed state after jobs settle. Two success responses may still represent one committed operation. **Report threshold:** a duplicate transition or violated invariant that survives completion. **Stop:** at first proof, increased errors, queue growth, or unintended side effects; restore your test object. Practice timing techniques locally before production. [PortSwigger race conditions](https://portswigger.net/web-security/race-conditions).

## 7. Focused vulnerability test cards

Each card assumes the exact endpoint and technique are authorized, a baseline exists, and synthetic data is available.

| Class | Bounded action | Evidence / report threshold | Stop or defer |
|---|---|---|---|
| SQL / NoSQL injection | Change one input with paired controls; confirm input reaches a query/operator context | Reproducible query-semantic change tied to input; syntax errors alone remain leads | No database dumps, destructive statements, or unbounded timing probes |
| Command / template injection | In a local replica first, use a harmless expression/marker appropriate to the sink | Distinguish template evaluation from client rendering and reflection; show relevant execution impact | Stop at minimal proof; no shell persistence or environment-secret collection |
| XSS | Determine HTML/attribute/JS/DOM context; demonstrate a benign marker executing for controlled B | Another permitted user's browser executes in the affected origin with realistic delivery | No cookie/token exfiltration; avoid content visible to real users |
| Upload | Test filename, content type, file content, ownership, retrieval and processing independently | Unauthorized controlled-file access, unsafe interpretation, traversal, or executable handling | No web shells, overwriting application files, archive bombs, or expensive documents |
| Path traversal | Use an owner-provided canary or file planted in your local replica outside the allowed directory | Read/write outside intended path boundary with a known harmless file | Do not retrieve production configuration, keys or user files |
| SSRF / XXE | Send a unique callback to infrastructure you control; separate DNS from HTTP observations | Show unintended server-side request and reachable policy boundary; intended URL fetching is not automatically SSRF | No cloud credential retrieval, internal sweeps or unrelated destinations; ask owner for an internal canary if needed |
| CSRF | From your controlled origin, make B's real browser perform one reversible protected action | Ambient credentials plus attacker-deliverable request cause unauthorized state change | Missing token alone is insufficient; do not involve real users |
| CORS | From controlled origin, read a private response in B's browser with realistic credential behavior | Browser actually exposes sensitive controlled data cross-origin | `Access-Control-Allow-Origin: *` with public content is not a finding; wildcard plus credentials is not automatically browser-exploitable |
| Cache poisoning / deception | Use a demonstrably isolated cache key and controlled marker/accounts | Another controlled client receives poisoned content or A's private data from shared cache | Unique query strings may be ignored in cache keys; stop if isolation is uncertain |
| Request parsing / smuggling | Reproduce proxy/backend disagreement in a lab or program-approved isolated endpoint | Demonstrate a request-boundary mismatch with controlled paired traffic | Production desynchronization can affect unrelated users; no broad probes or response-queue capture |

Technical references for the respective cards: [SQL injection](https://portswigger.net/web-security/sql-injection), [NoSQL injection](https://portswigger.net/web-security/nosql-injection), [template injection](https://portswigger.net/web-security/server-side-template-injection), [XSS](https://portswigger.net/web-security/cross-site-scripting), [uploads](https://portswigger.net/web-security/file-upload), [path traversal](https://portswigger.net/web-security/file-path-traversal), [SSRF](https://portswigger.net/web-security/ssrf), [CSRF](https://portswigger.net/web-security/csrf), [CORS](https://portswigger.net/web-security/cors), [cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), [request smuggling](https://portswigger.net/web-security/request-smuggling).

## 8. Network, DNS, TLS, and email branches

Use the dedicated [Network services playbook](#page-network) for the full DNS, TLS, email, database, queue, VPN and appliance workflow.

Only use this branch when the service/IP/port is covered. A website scope does not automatically authorize its hosting provider's network. An open port identifies a reachable service, not a vulnerability; an observed version can be backported, masked or misidentified. Nmap service detection sends protocol probes and can have side effects; even its documentation excludes printer port 9100 by default for that reason. Select individual services before deeper interrogation. [Nmap port states](https://nmap.org/book/man-port-scanning-basics.html), [Nmap version detection](https://nmap.org/book/man-version-detection.html).

For DNS, inspect A/AAAA/CNAME/NS/MX/TXT relationships. Public DNS lookups differ from passive historical DNS searches. A dangling CNAME is evidence of a configuration lead, not proof that the referenced resource is claimable. Resource claiming can change production routing; obtain the program-approved proof method before registration. Zone transfer, dynamic updates, recursion abuse and amplification testing require a specific allowed branch.

For TLS, connect using the intended SNI and verify the intended hostname; a wrong default certificate from an IP-only connection may simply reflect virtual hosting. Certificate SANs provide candidates, not added scope. Avoid treating a scanner's “old cipher” label as meaningful impact without the program's eligibility criteria. [OWASP TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html).

```bash
# Active DNS queries; only after the applicable discovery gate.
dig +time=2 +tries=1 app.example.com A
dig +time=2 +tries=1 app.example.com AAAA

# Active handshake to an approved hostname and port.
timeout 15 openssl s_client -connect app.example.com:443 \
  -servername app.example.com -verify_hostname app.example.com \
  -verify_return_error -brief </dev/null
```

The DNS and TLS commands use their official documented query/connection options. Hostname verification and SNI are separate controls. [BIND manual](https://bind9.readthedocs.io/en/latest/manpages.html), [OpenSSL s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/).

For SMTP/IMAP, distinguish the domain's mail configuration from an authorized mail-server service. Review SPF/DKIM/DMARC findings against program exclusions and actual spoofing/identity impact. Any relay or delivery test needs explicit scope and researcher-controlled mailboxes; do not send messages to staff to prove delivery. An MX pointing to a provider does not authorize that provider. For SSH, databases, queues, object stores and administration panels, start with service identity and authentication requirements; never jump from a banner to default-password spraying or reading datasets.

## 9. Exit checklist

- [ ] Policy snapshot and exact asset/technique authorization recorded; exclusions applied.
- [ ] Every candidate has an ownership and scope decision; redirects and dependencies reviewed.
- [ ] Synthetic accounts, two tenants, role transitions and cleanup plan established.
- [ ] Endpoints include background jobs, exports, integrations and alternate protocols.
- [ ] Object, function and property authorization checked independently.
- [ ] Authentication and revocation tested across UI/API/socket paths.
- [ ] High-value business invariants have serial controls before concurrency tests.
- [ ] Browser findings verified in a real browser; server findings have controlled differential evidence.
- [ ] Finding has a reproducible boundary violation, not only a scanner label or missing hardening control.
- [ ] Sensitive evidence minimized; timestamps, requests, relevant responses and state changes preserved.
- [ ] Test records removed, tokens revoked, callbacks stopped and report submitted privately.

## Identity and protocol coverage review — 14 September 2026

The shared procedures now distinguish **account lifecycle**, **authenticator proof**, **federation trust**, and **API transport**. Complete the applicable branch for the deployed feature; unavailable access is an untested branch, not a passed check.

| Observed feature | Additional checks | Reusable procedure |
|---|---|---|
| Email verification, invitations, account merging | Pending identity, stale links, cancelled invitations, retained sessions | [Identity lifecycle](#page-modules-identity-session) |
| MFA, passkeys, recovery codes | Factor binding, replacement, replay, verification policy | [Authenticator lifecycle](#page-modules-authenticator-lifecycle) |
| OAuth, OIDC, SAML | Transaction binding, token purpose, issuer/audience, signature coverage | [Federation and token trust](#page-modules-federation-token-trust) |
| Enterprise SSO and SCIM | Alternate login paths, tenant provisioning scope, group removal and revocation interval | [Identity lifecycle](#page-modules-identity-session) |
| HTTP/JSON-to-gRPC or gRPC-Web gateway | Same method and object through each deployed authentication path | [Protocol parity](#page-modules-api-protocols) |
| SSE and resumed streams | New-event authorization, reconnect cursor, membership removal | [Protocol parity](#page-modules-api-protocols) |

Start with a legitimate request, change one identity/proof/context, inspect a protected result, and preserve a control. Follow the module's full procedure before reaching its command card. The new classes are indexed with reverse references in the [vulnerability catalog](#page-vulnerabilities).

- [ ] Enrollment and recovery cannot silently reduce a required authentication guarantee.
- [ ] Account verification or linking does not preserve unintended access.
- [ ] An enforced SSO policy is checked at protected tenant access.
- [ ] Token purpose and claim checks are distinguished from signature checks.
- [ ] GraphQL alternate methods, deployed gateways, and resumed streams preserve permissions.

## Follow the two commonly missed server entry points

The server-side review now includes [request-value interpretation](#page-modules-request-value-parsing) and [webhook event integrity](#page-modules-webhook-event-integrity). These are reusable across web/API, self-hosted OSS, cloud services and AI integrations. Run them when the application has multiple parsing layers, internal service calls or external event delivery; record an inapplicable result with the reason when those features are absent.

| Boundary | Minimal controlled comparison | Required evidence |
|---|---|---|
| Duplicate query/JSON values | Allowed scalar, denied scalar, both values in each order | The value checked differs from the value used in a forbidden operation |
| Downstream parameter construction | Literal marker, delimiter marker, correctly encoded control | Actual internal request parameters plus changed policy semantics |
| Webhook authenticity | Genuine event, invalid signature, changed body with unchanged signature | No protected effect for invalid cases, or the exact unauthorized worker transition |
| Provider-to-tenant mapping | Valid events from two controlled integrations | Authenticated provider identity tied to the correct local tenant/object |
| Retry and event ordering | Serial replay and two valid events in reversed order | Durable effect count and final permissions after workers settle |
| Delayed injection | Store marker, trigger observed export/job, compare literal control | Both entry and later sink, including the stored bytes |

Keep ordinary parser preference, delivery acknowledgement and cached responses separate from demonstrated security failures. Use the modules' numbered procedures and linked vulnerability cards for report thresholds and false-positive controls.

- [ ] Parser/type/precedence behavior checked where multiple layers consume input.
- [ ] Later consumers of stored input traced where exports or workers exist.
- [ ] Incoming events authenticated before privileged processing and bound to tenant/object.
- [ ] Replay, ordering and queue effects inspected against the documented workflow.
- [ ] File links, cache revalidation and actual SSRF connection identity checked when applicable.

Review additions verified against primary documentation on 14 September 2026. Earlier chapter references retain their original review dates; these additions do not imply that every external link or every target was tested.

## Source registry

All sources accessed 2026-09-11. “Undated” means no reliable publication date was established; it does not imply old content. Sources were read directly. This chapter's test budgets, matrices, ordering and stopping rules are synthesis, not quotations from those sources.

| Source | Date/version | URL |
|---|---|---|
| OWASP WSTG project | v4.2 released 2020-12-03; v5 development | https://owasp.org/www-project-web-security-testing-guide/ |
| OWASP ASVS | v5.0.0 released 2025-05-30 | https://owasp.org/www-project-application-security-verification-standard/ |
| ProjectDiscovery Subfinder usage | Undated | https://docs.projectdiscovery.io/opensource/subfinder/usage |
| ProjectDiscovery httpx usage | Undated | https://docs.projectdiscovery.io/opensource/httpx/usage |
| curl manual | Undated rolling manual | https://curl.se/docs/manpage.html |
| PortSwigger access control | Undated | https://portswigger.net/web-security/access-control |
| PortSwigger GraphQL | Undated | https://portswigger.net/web-security/graphql |
| gRPC authentication | Last modified 2024-01-12 | https://grpc.io/docs/guides/auth/ |
| gRPC reflection | Undated | https://grpc.io/docs/guides/reflection/ |
| PortSwigger WebSockets | Undated | https://portswigger.net/web-security/websockets |
| OWASP Session Management | Undated | https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html |
| RFC 9700 OAuth Security BCP | January 2025 | https://www.rfc-editor.org/rfc/rfc9700.html |
| PortSwigger OAuth | Undated | https://portswigger.net/web-security/oauth |
| OpenID Connect Core | 1.0 incorporating errata set 2 | https://openid.net/specs/openid-connect-core-1_0.html |
| OWASP SAML Security | Undated | https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html |
| PortSwigger business logic | Undated | https://portswigger.net/web-security/logic-flaws |
| PortSwigger race conditions | Undated | https://portswigger.net/web-security/race-conditions |
| PortSwigger SQL injection | Undated | https://portswigger.net/web-security/sql-injection |
| PortSwigger NoSQL injection | Undated | https://portswigger.net/web-security/nosql-injection |
| PortSwigger template injection | Undated | https://portswigger.net/web-security/server-side-template-injection |
| PortSwigger XSS | Undated | https://portswigger.net/web-security/cross-site-scripting |
| PortSwigger file uploads | Undated | https://portswigger.net/web-security/file-upload |
| PortSwigger path traversal | Undated | https://portswigger.net/web-security/file-path-traversal |
| PortSwigger SSRF | Undated | https://portswigger.net/web-security/ssrf |
| PortSwigger CSRF | Undated | https://portswigger.net/web-security/csrf |
| PortSwigger CORS | Undated | https://portswigger.net/web-security/cors |
| PortSwigger cache poisoning | Undated | https://portswigger.net/web-security/web-cache-poisoning |
| PortSwigger request smuggling | Undated | https://portswigger.net/web-security/request-smuggling |
| Nmap port states | Undated | https://nmap.org/book/man-port-scanning-basics.html |
| Nmap version detection | Undated | https://nmap.org/book/man-version-detection.html |
| OWASP TLS | Undated | https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html |
| BIND manual | Rolling development manual, undated | https://bind9.readthedocs.io/en/latest/manpages.html |
| OpenSSL s_client | Version 3.5 manual, undated | https://docs.openssl.org/3.5/man1/openssl-s_client/ |

Review update, 14 September 2026: the official [OWASP API Security Top 10 2023 overview](https://api-security.owasp.org/editions/2023/en/0x11-t10/), BOLA and object-property authorization pages were successfully retrieved. Original source-registry access dates remain historical.


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.
- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.
- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function)
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property)
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection)
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass)
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary)
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection)
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow)
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change)
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read)
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation)
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution)
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape)
- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input)
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response)
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization)
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz)
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization)
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking)
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos)
- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read)
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write)
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope)
- [Private delivery policy bypassed through the origin](#page-vulnerabilities-cloud-origin-access-bypass)
- [Dangling DNS reference to a retired service](#page-vulnerabilities-dns-dangling-resource-reference)
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization)
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion)
- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval)
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak)
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust)
- [Clickjacking of a sensitive authenticated action](#page-vulnerabilities-clickjacking-sensitive-action)
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust)
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure)
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness)
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash)
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing)
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust)
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass)
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure)
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion)
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass)
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection)
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict)
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection)
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure)
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding)
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority)
- [Delayed extension result reaches a different document](#page-vulnerabilities-extension-document-reply-confusion)
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership)
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect)
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure)
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit)


---

<a id="page-network"></a>

# Network services, DNS, TLS, email, and appliances

This is a separate campaign branch: discovering a network service through a website does not automatically authorize testing it. Commands are documentation-verified examples; none were executed against targets. The budgets, sequence, and evidence thresholds below are operational recommendations.

## Stage 1 — define the service boundary

Create one inventory row per `owner → environment → address family → IP → transport → port → service → identity/tenant`. Retain the hostname, SNI and HTTP Host when virtual hosting applies. Distinguish a website's public edge from its origin and from the provider's control plane. An IP resolving from an authorized hostname is not automatically a target for every service; a CIDR does not necessarily include unrelated customer workloads inside it.

TCP/443, UDP/443 and a VPN on UDP/500 are separate surfaces. An A record does not authorize IPv6; an AAAA record does not authorize an entire IPv6 prefix. Querying an AAAA record over IPv4 is not an IPv6 connectivity test. Expand only into address families, protocols, ports and ownership categories covered by the policy. Avoid brute-force IPv6 address discovery across huge prefixes.

**Gate:** save the exact scope entry, exclusions, approved source address, allowed time window, credentials, concurrency/rate budget, and emergency contact. If appliance disruption or parser tests are excluded, move those hypotheses into a local product lab.

## Stage 2 — separate inventory from vulnerability confirmation

Start with public vendor documentation, existing network-index records and historical DNS. Searching previously collected records is passive relative to the target; requesting a new third-party scan is active. DNS queries, TCP connections, UDP packets and TLS negotiations are active even when no login or state change occurs.

For authorized services, establish a normal protocol exchange and identify the product, build, deployment mode and authentication challenge. Keep the network vantage point and timestamps: `filtered` or `open|filtered` are observations from that vantage, not proof a service is absent or vulnerable. UDP silence is especially ambiguous. [Nmap port states](https://nmap.org/book/man-port-scanning-basics.html).

Treat banner-to-CVE matches as candidates. Vendor backports can fix vulnerabilities without adopting the upstream version number that a scanner expects. Match vendor advisory, package build, enabled feature and exploit prerequisites; validate behavior safely before claiming vulnerability. A stale banner is not remote code execution. [Red Hat backporting](https://access.redhat.com/security/updates/backporting).

## Stage 3 — bounded command reference

Replace these documentation addresses only with approved assets. Here `192.0.2.53` is an authorized DNS server and `192.0.2.10` an explicitly approved host. Run commands individually; inspect each result before continuing. No default broad scans, NSE script sets, OS detection, traceroute or version detection are enabled.

```bash
# 1. One UDP SOA query to an approved authoritative server.
dig -r @192.0.2.53 example.com SOA \
  +norecurse +notcp +ignore +time=2 +tries=1

# 2. One AAAA lookup; still uses IPv4 transport to this DNS server.
dig -r @192.0.2.53 app.example.com AAAA \
  +norecurse +notcp +ignore +time=2 +tries=1

# 3. Inspect the domain's published DMARC record.
dig -r @192.0.2.53 _dmarc.example.com TXT \
  +norecurse +notcp +ignore +time=2 +tries=1

# 4. TLS handshake with the intended SNI and certificate identity.
timeout 15 openssl s_client -connect app.example.com:443 \
  -servername app.example.com -verify_hostname app.example.com \
  -verify_return_error -brief </dev/null

# 5. SMTP STARTTLS negotiation only: no AUTH or message delivery.
timeout 15 openssl s_client -starttls smtp \
  -connect mail.example.com:587 -servername mail.example.com \
  -verify_hostname mail.example.com -verify_return_error \
  -brief </dev/null

# 6. Explicitly approved TCP ports on one approved IPv4 address.
nmap -sT -Pn -n --disable-arp-ping -p 22,443 \
  --max-rate 1 --scan-delay 1s --max-parallelism 1 \
  --max-retries 0 --host-timeout 30s \
  -oX network-one.xml 192.0.2.10
```

`dig -r` ignores inherited `.digrc` options; `+ignore` prevents automatic TCP fallback after a truncated UDP response. A truncated answer is incomplete, so request TCP separately only if allowed. `+norecurse` suits a known authoritative server; a referral is not a complete answer. Use record types A, CNAME, NS, MX, SPF TXT or a **known** DKIM selector only as separately reviewed queries. [BIND 9.20.13 dig manual](https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility).

SNI selects a virtual TLS service; hostname verification checks identity. OpenSSL's STARTTLS option performs the protocol negotiation needed before TLS. A successful handshake does not test authentication or mail delivery. [OpenSSL s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/).

Nmap `-p` overrides its default port set, and `-Pn` skips ordinary host discovery that could touch additional ports. `-n` avoids reverse DNS. Scan timing options do not constitute a hard limit on every kernel-generated packet. For separately authorized IPv6 testing, use `-6` and the exact approved IPv6 address. Do not append `-sV`: version detection introduces additional protocol probes and potential side effects. [Nmap port selection](https://nmap.org/book/man-port-specification.html), [host discovery](https://nmap.org/book/man-host-discovery.html), [timing](https://nmap.org/book/man-performance.html), [IPv6](https://nmap.org/book/man-misc-options.html), [version detection](https://nmap.org/book/man-version-detection.html).

## Stage 4 — test a concrete hypothesis

| Hypothesis | Preconditions and minimal action | Evidence / reporting threshold | Stop condition |
|---|---|---|---|
| DNS delegation or CNAME is abandoned | Authorized DNS review; inspect current chain and provider ownership requirements | Record chain, error and claimability evidence; classify unconfirmed takeover honestly | Do not register a domain/resource or replace DNS without the approved proof method |
| Resolver allows unintended recursion | That DNS service and recursion checks are allowed; query one unique name in your own zone | Resolver response plus your authoritative log establishes one recursive lookup; report according to policy impact | No spoofed source, ANY/amplification batches, or load measurement |
| TLS identity/transport boundary fails | Expected hostname and trust model known; one handshake and a controlled client comparison | Explain which actual client accepts the wrong identity or exposes sensitive traffic | No live interception of unrelated users; no exhaustive stress negotiation |
| Database/queue/file service bypasses authentication or ACL | Dedicated test account and synthetic resource supplied | Restricted account accesses a forbidden test key, row, queue, share or administration function | Stop at first proof; no listing/dumping real datasets or consuming production messages |
| IPv6 exposes a management path blocked on IPv4 | Both exact addresses are authorized; compare the same approved service | Same product/service, different access boundary, actual privileged exposure | Do not expand into neighboring addresses or internal routes |
| SMTP relay or sender-identity control fails | Policy allows mail tests; sender, recipient and relevant endpoints controlled | One delivery, envelope/header identity, trusted receiver results and relay transcript | No staff recipients, unsolicited messages, forwarding to customers or bulk delivery |
| Appliance parser crosses a security boundary | Own isolated hardware/VM, exact firmware, snapshots and recovery | Minimized input plus reproducible crash/authorization or memory-safety evidence | Production reproduction requires its own allowed method; never cause an outage to verify a lab result |

For databases, queues, SSH, SMB/NFS, LDAP and management APIs, test authentication and authorization separately. A TCP connection or banner does not grant data access. Prefer one read of a supplied canary over `list all`, queue consumption or configuration export. Compare limited and privileged test identities; examine revocation and certificate-to-account mapping. Redis documents separate protected mode, authentication, ACL and TLS controls; PostgreSQL's host-based authentication evaluates connection type, address, user and database. [Redis security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/), [PostgreSQL authentication](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html).

## DNS and email: prove the relevant impact

DNSSEC provides DNS data authenticity and integrity; it does not encrypt DNS or provide authorization for zone updates. Missing DNSSEC alone does not demonstrate a practical takeover. A broken chain may create availability problems for validating resolvers; record the observed resolution failure without deliberately breaking records. Requesting DNSSEC records with `dig +dnssec` does not itself perform cryptographic validation. [RFC 4033](https://www.rfc-editor.org/rfc/rfc4033.html), [BIND manual](https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility).

SPF evaluates authorized sending hosts for envelope/HELO identities. DKIM verifies a signature associated with a signing domain. DMARC relates authenticated SPF/DKIM identifiers to the visible From domain through alignment; a passing DKIM signature from an unrelated domain is insufficient. Evaluate the actual message path, including forwarding, instead of treating these controls as interchangeable. [SPF RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html), [DKIM RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html), [DMARC RFC 7489](https://www.rfc-editor.org/rfc/rfc7489.html).

Missing SPF, a DKIM selector returning NXDOMAIN, DMARC `p=none`, or an “AUTH offered” banner does not independently prove accepted impersonation or mailbox access. A guessed selector can simply be wrong. Check whether email spoofing is eligible before investing in it. If allowed, send one inert, clearly identified test to a researcher-owned mailbox using the agreed identity; save trusted receiver-generated authentication results, raw headers and timestamps. Delivery to a permissive receiver you control does not prove a protected recipient would accept the mail. Distinguish SMTP acceptance, queueing and actual delivery; `250` during a transaction is not sufficient proof of final delivery or open relay. [SMTP RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html).

## Router, VPN, and protocol-parser lab branch

Choose one product family and obtain authorized firmware or a vendor trial. Record hardware revision, firmware hash, enabled modules and initial configuration. Isolate management and simulated clients from your normal network; supply local DNS, identity and callback services. Capture a legitimate protocol conversation first. Map pre-authentication versus authenticated parsers, management versus data plane, and low-privilege versus administrator commands.

Review exposed handlers and parsers, reproduce one hypothesis, minimize the triggering input, then compare vulnerable and fixed builds. Preserve logs, crash trace, exact configuration and a reset procedure. A crash establishes an availability or memory-safety lead; do not claim code execution without evidence. For a private target running the same appliance, report validated applicability and remaining uncertainty; obtain an agreed canary or lab-equivalent verification if production testing would disrupt service. No persistence, firmware replacement or route changes on a live target are needed for a useful report.

## Exit checklist

- [ ] Exact IPv4/IPv6, transport, port, owner and environment are authorized.
- [ ] Shared hosting, origin, provider and customer boundaries are documented.
- [ ] Active requests are separated from historical third-party discovery.
- [ ] DNS server, query type and UDP/TCP behavior are explicit.
- [ ] Commands have explicit ports, timeouts and bounded concurrency.
- [ ] Service identity includes build/configuration and possible vendor backports.
- [ ] SNI and expected TLS hostname are recorded.
- [ ] Authentication and resource authorization have separate test cases.
- [ ] Synthetic data or owner-provided canaries support evidence.
- [ ] DNS/mail configuration observations are tied to eligible impact.
- [ ] Parser/appliance testing has isolation, recovery and minimized inputs.
- [ ] First-proof stopping, cleanup and private reporting are completed.

## Extend the canary method to LDAP, file shares and SSH

These services need protocol-specific boundaries in addition to a working socket. Use the shared [network-service module](#page-modules-network-service-boundaries) for endpoint identity and allowed/denied controls.

| Surface | Exact controlled comparison | Interpretation |
|---|---|---|
| LDAP | Read one known fixture DN and one synthetic attribute as the intended account and restricted account; keep the bind method, TLS and base scope constant | Successful bind does not grant all directory attributes. A root DSE response or intended anonymous discovery is not private-entry disclosure. [OpenLDAP ACLs](https://www.openldap.org/doc/admin26/access-control.html) |
| SMB file shares | Open one owner-supplied share and retrieve one predetermined synthetic file under each identity | Share access, filesystem permissions and authenticated identity must all be understood; a share name or successful negotiation alone is insufficient. [Samba client](https://www.samba.org/samba/docs/current/man-html/smbclient.1.html) |
| SSH/SFTP | Compare the account's promised restricted subsystem with permitted local fixtures; inspect effective Match rules, forced command and forwarding controls | A forced command does not independently disable forwarding. Authentication success is not proof of a restricted-account escape. Any forwarding check must terminate at an owned canary endpoint. [OpenSSH server configuration](https://man.openbsd.org/sshd_config) |

For LDAP, account for referrals and client behavior before following a response into another server. For SMB, save whether guest mapping occurred instead of assuming the requested username was authenticated. For SSH, record whether the promised restriction comes from the server configuration, authorized-key options or a surrounding gateway. Test the actual control layer rather than a deliberately weakened lab substitute.

Keep the proof narrow: one known entry, attribute, file or owned connection. A lab administrator can confirm presence when a low-privilege client returns no result. Preserve object ownership, effective identity, exact operation, allowed control and expected denial. Reuse the same synthetic resource after the proposed fix; remove only the recorded fixture objects and accounts.

## Source registry

All accessed 2026-09-11. Undated means a reliable publication date was not established. RFCs below substantiate protocol mechanics, not a claim that no later updating RFC exists.

| Source | Date/version | URL |
|---|---|---|
| Nmap port states | Undated | https://nmap.org/book/man-port-scanning-basics.html |
| Nmap port selection | Undated | https://nmap.org/book/man-port-specification.html |
| Nmap discovery | Undated | https://nmap.org/book/man-host-discovery.html |
| Nmap timing | Undated | https://nmap.org/book/man-performance.html |
| Nmap IPv6/miscellaneous | Undated | https://nmap.org/book/man-misc-options.html |
| Nmap version detection | Undated | https://nmap.org/book/man-version-detection.html |
| BIND dig | Version 9.20.13 manual | https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility |
| OpenSSL s_client | Version 3.5 manual | https://docs.openssl.org/3.5/man1/openssl-s_client/ |
| Red Hat backporting | Undated | https://access.redhat.com/security/updates/backporting |
| Redis security | Undated rolling docs | https://redis.io/docs/latest/operate/oss_and_stack/management/security/ |
| PostgreSQL authentication | Version 18 rolling docs | https://www.postgresql.org/docs/current/auth-pg-hba-conf.html |
| DNSSEC RFC 4033 | March 2005 | https://www.rfc-editor.org/rfc/rfc4033.html |
| SPF RFC 7208 | April 2014 | https://www.rfc-editor.org/rfc/rfc7208.html |
| DKIM RFC 6376 | September 2011 | https://www.rfc-editor.org/rfc/rfc6376.html |
| DMARC RFC 7489 | March 2015 | https://www.rfc-editor.org/rfc/rfc7489.html |
| SMTP RFC 5321 | October 2008 | https://www.rfc-editor.org/rfc/rfc5321.html |


## Shared investigation procedures

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.
- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

## Vulnerability reference

- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input)
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response)
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization)
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Namespace or workload network restriction is ineffective](#page-vulnerabilities-kube-network-isolation-failure)
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default)
- [Dangling DNS reference to a retired service](#page-vulnerabilities-dns-dangling-resource-reference)
- [Restricted DNS zone transferable from an unintended source](#page-vulnerabilities-dns-unrestricted-zone-transfer)
- [DNS recursion available outside the intended client network](#page-vulnerabilities-dns-unrestricted-recursion)
- [SMTP relay allows unauthenticated external delivery](#page-vulnerabilities-smtp-unintended-open-relay)
- [Redis authentication or key ACL boundary failure](#page-vulnerabilities-redis-canary-access)
- [PostgreSQL trust authentication exceeds the approved network boundary](#page-vulnerabilities-postgres-unintended-trust-auth)
- [Message broker permissions cross a virtual-host boundary](#page-vulnerabilities-queue-virtual-host-boundary)
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth)
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate)
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials)


---

<a id="page-mobile"></a>

# Mobile

## Scope and learning route

Mobile bounty work means testing an explicitly identified application and its reachable trust boundaries. Record the Android package ID or iOS bundle ID, store URL, publisher, signing identity, version/build number, acquisition date, artifact SHA-256, OS version, architecture, and distribution channel. Include Android split APKs and dynamic features; an App Bundle is a publishing artifact, not necessarily the exact installed package set. Keep production, TestFlight, enterprise, debug, and locally compiled OSS builds distinct. A repository commit and a store build are separate evidence coordinates.

Treat backend domains, identity providers, analytics vendors, embedded SDKs, companion apps, and operating-system components as independently scoped assets. A mobile package listing does not automatically authorize arbitrary testing of every URL recovered from it. Likewise, a hostname containing “mobile” in a discovery list establishes neither app identity nor testing authorization. For OSS, reproduce against a locally built release or documented self-hosted backend; do not use maintainers’ demo infrastructure unless its policy includes it.

Use **MASVS** to organize required security properties, **MASTG** for testing techniques, and **MASWE** to name weaknesses. They serve different purposes; a control failure is not automatically bounty-eligible. Record the exact taxonomy version or retrieval date, since identifiers and test mappings evolve. [OWASP MASVS](https://mas.owasp.org/MASVS/), [MASTG](https://mas.owasp.org/MASTG/), [MASWE](https://mas.owasp.org/MASWE/).

Recommended progression: package anatomy and platform permissions → storage and session lifecycle → exported interfaces and deep links → WebView bridges → native libraries and release differences. Advance when you can show an attacker-controlled entry point reaching a protected operation, explain the required privileges, and reproduce the result without changing the security property under test.

## Lab prerequisites

For Android, use an owned device or emulator, Android SDK Platform Tools, APK Analyzer/build tools, JADX, Apktool, and a scoped interception proxy. Start with an ordinary release installation; keep a separate instrumented image for tracing. Match API level, ABI, target SDK, split packages, and relevant Google-service dependencies. Decompiler output is a navigation aid: verify ambiguous control flow against bytecode, original source, or runtime behavior. [Android SDK tools](https://developer.android.com/tools/adb), [JADX](https://github.com/skylot/jadx).

For iOS, use a Mac with compatible Xcode tooling and an owned supported iPhone/iPad when device behavior matters. A simulator needs a simulator-compatible build; a normal device IPA is not interchangeable with one. Obtain source, symbols, or an authorized test build where available. Jailbreaking, repackaging, changed entitlements, and instrumentation alter assumptions and must be disclosed; unsupported hardware or unavailable binary access can limit coverage. [OWASP iOS Security Testing](https://mas.owasp.org/MASTG/0x06b-iOS-Security-Testing/).

Create two owned application accounts where allowed, seed recognizable synthetic records, and capture an untouched baseline. Keep backend traffic within the explicit scope. An interception certificate installed for the lab changes the trust environment: distinguish expected trust of that certificate from an app accepting invalid certificates without an approved trust anchor. Android debug trust overrides may deliberately change pinning behavior and are ignored in non-debuggable builds. [Android network security configuration](https://developer.android.com/privacy-and-security/security-config).

## Android playbook

1. **Establish provenance.** Inventory version, signature, complete package set, minimum/target SDK, and release flags. **Gate:** the artifact corresponds to the scoped release, or the report clearly limits its claim to another eligible build.
2. **Map external inputs.** Enumerate activities, services, receivers, providers, intent filters, URI grants, custom permissions, and dynamically registered interfaces. Trace inputs to sensitive reads, writes, navigation, account operations, and file handling. **Gate:** a reachable input exists under the proposed attacker privileges. An exported component may be intentional; export status alone proves no unauthorized operation. [Android exported components](https://developer.android.com/privacy-and-security/risks/android-exported).
3. **Exercise one boundary at a time.** Use a minimal companion test app to model an ordinary installed application. Check permission enforcement, caller identity, grants, and object ownership. ADB is useful for observation, but its shell identity may have privileges unavailable to an ordinary app. **Gate:** repeat the finding under the claimed attacker identity with synthetic data. Content-provider access combines URI identification with provider permissions and grants. [Android content providers](https://developer.android.com/guide/topics/providers/content-provider-basics).
4. **Trace links and embedded content.** Follow deep-link parameters through redirects, route selection, authentication gates, and WebView loading. Examine nested frames and native bridge exposure. **Gate:** untrusted input reaches protected functionality; merely opening a public screen is expected behavior. Verified links bind routing but do not replace authorization or input validation. [Android deep links](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks), [WebView native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges).
5. **Observe lifecycle and trust.** Compare storage, logs, caches, clipboard, notifications, backups, and tokens before login, after account switching, and after logout. Trace key use and local authentication rather than collecting every string resembling a secret. **Gate:** identify sensitive material, its actual exposure path, and an attacker who can access or reuse it.
6. **Validate release impact.** Reproduce the smallest meaningful result on the eligible build, with preconditions and negative controls. Report only the supported chain; label any backend conclusion requiring separately authorized testing as unverified.

## iOS playbook

1. **Fingerprint the application.** Record bundle/version identifiers, signing team, provisioning context, architecture, embedded extensions, and entitlement set. Review `Info.plist`, associated domains, App Groups, Keychain groups, URL types, document handlers, and ATS configuration. **Gate:** the inspected artifact and runtime installation match.
2. **Model shared capabilities.** Trace app-to-extension sharing, document imports, pasteboard access, URL handling, and WebView message handlers. Identify which sender or origin the app trusts. **Gate:** reproduce with a separately controlled input, without granting that input the target’s signing identity.
3. **Test URL transitions.** Cover logged-out, logged-in, expired-session, and account-switch states using harmless links and local fixtures. Verify sensitive operations still authorize the current account. Universal links use website/app association; custom schemes have different routing guarantees. Neither makes arbitrary URL parameters trustworthy. [Apple universal-link model](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html).
4. **Inspect data protection semantically.** Determine Keychain accessibility class, access group, synchronization, user-presence constraints, and whether sensitive operations use the protected key. Test lock/unlock and logout behavior against the product’s intended offline/background capabilities. **Gate:** demonstrate a violation of the intended access boundary, not simply that a secret exists while its owner is authenticated. [Apple Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web).
5. **Trace network and native paths.** Examine trust-delegate behavior, ATS exceptions, authenticated WebViews, callback handling, imported files, and bundled native parsers. Use instrumentation to locate a cause, then separate observations introduced by instrumentation. **Gate:** the claimed result remains valid under documented release preconditions.

## Mobile hypotheses

| Hypothesis | Minimal controlled experiment | Evidence required before reporting |
|---|---|---|
| Exported Android provider exposes private data | Seed one record; request it from an unprivileged test app | Caller permissions, URI, synthetic record, expected denial |
| Deep link bypasses an account boundary | Open an owned-account resource link in a different owned session | Identity before/after, resulting unauthorized action/data |
| Web content reaches a privileged bridge | Load a harmless controlled page through a supported entry point | Origin/frame, exposed method, bounded protected operation |
| Logout leaves reusable authorization | Observe one owned token’s documented revocation lifecycle | Applicable policy, timing, separately scoped backend result |
| Local unlock is only a cosmetic gate | Trace whether protected data/key use requires authentication | Attacker prerequisite and actual protected data access |
| Imported file crosses a storage boundary | Import a synthetic file with a unique marker | Intended destination, actual destination, accessible privilege |

These are prioritization hypotheses, not claims that every listed behavior is a vulnerability. Screenshots, missing obfuscation, root detection, pinning, and generic API keys need program-specific impact and eligibility analysis.

## Mobile checklist

**Android**

- [ ] Package ID, publisher, store channel, version, hash, and signer recorded.
- [ ] Base and relevant split/dynamic-feature packages included.
- [ ] Device API, ABI, target SDK, and release/debug state recorded.
- [ ] Exported and dynamically registered components mapped.
- [ ] Component permissions and caller identity checked.
- [ ] Provider permissions, URI grants, and path handling reviewed.
- [ ] Intent forwarding and PendingIntent authority traced.
- [ ] Deep-link host, path, parameter, and session validation checked.
- [ ] WebView navigation, frames, and bridge methods mapped.
- [ ] Storage, logs, notifications, clipboard, and backups examined.
- [ ] Key storage, key use, and local authentication connected.
- [ ] Network trust behavior separated from lab CA changes.
- [ ] Account switching and logout tested with synthetic identities.
- [ ] Claimed ordinary-app issue reproduced without ADB-only privilege.

**iOS**

- [ ] Bundle ID, build, channel, hash, signing team, and device recorded.
- [ ] Simulator, device, and instrumented builds distinguished.
- [ ] `Info.plist` and embedded extension metadata inspected.
- [ ] Associated domains and custom URL schemes inventoried.
- [ ] URL parameters and account context validated independently.
- [ ] App Groups and Keychain access groups mapped.
- [ ] Keychain class, synchronization, and user-presence policy reviewed.
- [ ] Sensitive file protection evaluated for intended lock states.
- [ ] Extension and document-import trust boundaries exercised.
- [ ] WebView frames, navigation, and message handlers inspected.
- [ ] ATS configuration and actual certificate validation checked.
- [ ] Cache, logs, pasteboard, screenshots, and backup exposure assessed.
- [ ] Local authentication tied to sensitive data or key access.
- [ ] Re-signing/jailbreak limitations and release reproduction documented.

## Mobile command cheat sheet

Run these against owned lab devices and local artifacts. The commands inspect metadata or write analysis copies; they do not test discovered Internet hosts. Replace identifiers and paths deliberately. Android commands require the indicated SDK tools on `PATH`; JADX and Apktool require their supported Java runtime. [ADB](https://developer.android.com/tools/adb), [APK Analyzer](https://developer.android.com/tools/apkanalyzer), [APK signer](https://developer.android.com/tools/apksigner), [JADX CLI](https://github.com/skylot/jadx), [Apktool CLI](https://apktool.org/docs/cli-parameters/).

```bash
# Android: choose one owned device when more than one is attached.
adb devices -l
adb -s DEVICE_SERIAL shell pm path com.example.lab
adb -s DEVICE_SERIAL shell dumpsys package com.example.lab
apkanalyzer apk summary ./app.apk
apkanalyzer manifest print ./app.apk
apkanalyzer manifest permissions ./app.apk
apksigner verify --verbose --print-certs ./app.apk
jadx -d ./analysis-jadx ./app.apk
apktool d ./app.apk -o ./analysis-apktool
```

On macOS, inspect a locally acquired/extracted app without modifying its signature. `codesign` applies to both iOS bundles and macOS applications, but entitlements and runtime enforcement differ. Check installed `man plutil` / `man codesign` when tooling differs. [OWASP Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/), [OWASP entitlement extraction](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/).

```bash
plutil -p ./Payload/Lab.app/Info.plist
codesign -dv --verbose=4 ./Payload/Lab.app
codesign -d --entitlements :- ./Payload/Lab.app
```

## Native sign-in and privacy coverage matrix

Run identity tests through the shipped app and its authorized backend; a deep link opening a screen and a biometric prompt succeeding are only intermediate observations.

| Route | Controlled comparison | Required result |
|---|---|---|
| Native OAuth return | Normal callback versus another owned pending attempt | Code, verifier and transaction resolve to the correct final account |
| Account linking | Fresh link versus account-switch/cancelled flow | No external identity attaches to a different owned account |
| Passkey sign-in | Valid fixture versus wrong challenge/account fixture | The server rejects invalid assertions before session creation |
| Local protected key | Intended unlock versus supported alternate route | The protected operation observes the required local authentication state |
| Private UI/data | Public/private markers across lock and account switch | No new exposure to the stated unintended reader |

Use [federation and token trust](#page-modules-federation-token-trust) and [authenticator lifecycle](#page-modules-authenticator-lifecycle) for the shared server-side procedures. Native-specific continuations are in [Android components](#page-modules-android-components) and [iOS boundaries](#page-modules-ios-boundaries); use [client storage and privacy](#page-modules-client-storage-transport) for notifications, snapshots, clipboard and metadata-only hypotheses. RFC 8252 establishes the native external-agent/PKCE model, while Android distinguishes the client, credential provider and verifying server. [Native OAuth](https://www.rfc-editor.org/rfc/rfc8252), [Credential Manager](https://developer.android.com/identity/credential-manager).

- [ ] Record the final authenticated account or actual key operation.
- [ ] Repeat with an untouched eligible build after tracing.
- [ ] Distinguish the OS authorization screen from backend validation.

## Sources


All sources accessed **2026-09-11**. “Undated” means no reliable publication/update date was established from the retrieved page. Dates are page metadata, not a guarantee of completeness for every current OS version. Archived Apple sources are used for established mechanisms and command syntax, not blanket claims about current platform enforcement.

| ID | Publisher / exact source | Date | Use |
|---|---|---|---|
| MD01 | OWASP, [OWASP MASVS](https://mas.owasp.org/MASVS/) | Undated; living standard | Mobile control organization |
| MD02 | OWASP, [OWASP MASTG](https://mas.owasp.org/MASTG/) | Undated; living guide | Testing methodology and technique catalog |
| MD03 | OWASP, [Mobile Application Security Weakness Enumeration](https://mas.owasp.org/MASWE/) | Undated; living catalog | Weakness taxonomy and version caution |
| MD04 | Google, [Android Debug Bridge](https://developer.android.com/tools/adb) | Updated 2026-09-02 | Device/package inspection commands |
| MD05 | Google, [apkanalyzer](https://developer.android.com/tools/apkanalyzer) | Updated 2026-03-05 | APK metadata and manifest CLI |
| MD06 | Google, [apksigner](https://developer.android.com/tools/apksigner) | Updated 2026-03-05 | APK certificate/signature inspection |
| MD07 | Google, [android:exported](https://developer.android.com/privacy-and-security/risks/android-exported) | 2024-09-24, indexed page date | Component exposure and version dependence |
| MD08 | Google, [Unsafe use of deep links](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks) | 2024-10-24, indexed page date | Deep-link validation |
| MD09 | Google, [WebView – Native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges) | Updated 2024-10-15 | Frames, native bridges, origin boundaries |
| MD10 | Google, [Network security configuration](https://developer.android.com/privacy-and-security/security-config) | Updated 2026-08-28 | Trust anchors and debug overrides |
| MD11 | Google, [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics) | Undated in this registry | Provider access model |
| MD12 | skylot/JADX maintainers, [JADX repository and CLI](https://github.com/skylot/jadx) | Undated; living README | Decompiler usage and limitations |
| MD13 | Apktool maintainers, [CLI Parameters](https://apktool.org/docs/cli-parameters/) | Undated | Local package decoding |
| MD14 | OWASP, [iOS Security Testing](https://mas.owasp.org/MASTG/0x06b-iOS-Security-Testing/) | Undated | iOS lab/platform distinctions |
| MD15 | Apple, [Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) | Published 2024-12-19 | Access groups, classes, authentication constraints |
| MD16 | Apple, [Support Universal Links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html) | Updated 2016-12-15; archived | App/website association model |
| MD17 | OWASP, [MASTG-TOOL-0062: Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/) | Undated | Property-list inspection tooling |
| MD18 | OWASP, [MASTG-TECH-0111: Extracting Entitlements from MachO Binaries](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/) | Undated | Signing/entitlement inspection |
| MD19 | Apple, [TN2206: macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html) | Page updated 2016-09-13; archived | Signature verification command and boundaries |
| MD20 | Microsoft / Mark Russinovich, [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) | Published 2026-09-10 | Local process, registry, filesystem observation |
| MD21 | Microsoft, [Get-AuthenticodeSignature](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) | Undated; PowerShell 7.5 documentation | Windows signature inspection |
| MD22 | Microsoft, [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) | Updated 2025-06-09 | Windows ACL inspection |
| MD23 | OpenJS Foundation / Electron contributors, [Security](https://www.electronjs.org/docs/latest/tutorial/security) | Undated; living documentation | Renderer, navigation, IPC boundaries |
| MD24 | Electron contributors, [Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation) | Undated | Bridge limitations and API exposure |
| MD25 | Google, [Stay secure](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure) | Page states updated 2018-03-06 | Extension permissions and untrusted messages |
| MD26 | Google, [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging) | Page states updated 2025-12-03 | Extension messaging contexts |
| MD27 | Google, [Native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) | Page states updated 2023-02-27 | Native host manifest and execution boundary |
| MD28 | AFL++ maintainers, [Fuzzing in Depth](https://aflplus.plus/docs/fuzzing_in_depth/) | Undated; living guide | Harness, corpus, execution, resource limits |
| MD29 | GNU Binutils / Sourceware, [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) | Undated | Non-executing ELF metadata inspection |


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function)
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property)
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection)
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass)
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow)
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change)
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read)
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation)
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution)
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz)
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization)
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking)
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials)
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning)
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos)
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files)
- [Exported Android component exposes a protected operation](#page-vulnerabilities-android-exported-operation)
- [Content-provider permission or URI-grant escape](#page-vulnerabilities-android-provider-grant)
- [Nested intent redirects application authority](#page-vulnerabilities-android-intent-redirection)
- [PendingIntent grants unintended mutable or replayable authority](#page-vulnerabilities-android-pendingintent-delegation)
- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler)
- [Untrusted WebView content reaches a native bridge](#page-vulnerabilities-mobile-webview-native-bridge)
- [Keychain accessibility violates the intended lock boundary](#page-vulnerabilities-ios-keychain-access-policy)
- [Extension input crosses an iOS shared-container boundary](#page-vulnerabilities-ios-shared-container-trust)
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate)
- [Backup or transfer exposes unintended sensitive client state](#page-vulnerabilities-client-backup-sensitive-state)
- [Sensitive client state leaks through accessible diagnostics](#page-vulnerabilities-client-secret-logging)
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate)
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact)
- [Attacker-controlled rollback restores a prohibited security state](#page-vulnerabilities-update-security-rollback)
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust)
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness)
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash)
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing)
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass)
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure)
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion)
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass)
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure)


---

<a id="page-desktop"></a>

# Desktop

## Scope and learning route

Desktop scope must identify the product, platform, architecture, installer/package format, release channel, version, and publisher identity. Include separate entries for installers, updaters, background services, privileged helpers, plugins, browser extensions, native-messaging hosts, and local APIs. For extensions, record store listing, extension ID, version, browser build, Manifest version, and whether the tested copy is store-installed or unpacked. Explicitly distinguish a user application, system service, browser extension, and operating-system vulnerability.

An OSS clone supports local source review; it does not establish authorization for the vendor’s update infrastructure. An installer available for download does not automatically make all distribution hosts or dependencies bounty-eligible. Record whether local privilege escalation, user-assisted file attacks, denial of service, enterprise-only deployment, beta releases, and unsupported versions qualify before committing time.

Recommended progression: installer/package inspection → process and privilege mapping → local IPC and protocol handlers → update verification → Electron/extension bridges → native parser fuzzing. The useful skill is explaining precisely which lower-trust principal gains a higher-trust capability.

## Lab and evidence model

Use disposable Windows and Linux VMs and an owned Mac or supported macOS virtualization environment. Snapshot before installation; use a standard user for attacker modeling and a separate administrative account only for setup. Keep shared folders and personal credentials out of the experiment. Instrument only the target’s processes and synthetic files where practical.

Create a boundary ledger: entry point, attacker control, consumer identity, validation, protected capability, observation, and negative control. Local administrator modification of an application is not evidence of privilege escalation. A missing DLL in a trace, broad file permission, or unsigned resource becomes significant only when a lower-privileged actor can influence a path actually trusted by a more privileged consumer. Windows Process Monitor records file, registry, and process activity useful for establishing that chain. [Microsoft Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon).

## Native desktop playbook

1. **Inventory installation and updates.** Compare package contents, install destination, post-install actions, services/helpers, scheduled tasks, and registration of custom schemes/file types. Observe a normal install/update in the snapshot. **Gate:** retain exact installer hash, version, signer, and default configuration.
2. **Map local authority.** On Windows, review service configuration, named-pipe access, registry and filesystem ACLs. On macOS, inspect launch agents/daemons, XPC services, entitlements, helper identity validation, and container boundaries. On Linux, examine service users, Unix sockets, D-Bus/polkit interfaces, package scripts, capabilities, file ownership, and writable search paths. **Gate:** identify a real lower-trust caller or writable object used by the target, rather than assuming every local IPC endpoint is unprotected.
3. **Trace file and command inputs.** Review document import, archive extraction, plugin loading, URL handlers, temporary files, argument construction, and working-directory assumptions. Use unique harmless markers in a dedicated test directory. **Gate:** show the unintended operation and effective identity; do not infer command execution from a parsing error.
4. **Verify the update trust chain.** Determine whether metadata, downloaded bytes, publisher identity, and applicable version/rollback policy are verified before installation or execution. Model tampered artifacts only in a local updater harness or explicitly supported test feed. **Gate:** a production-equivalent decision accepts an unauthorized artifact or violates the intended version policy. A valid outer installer signature does not prove all subsequent update decisions are correct. Apple’s archived code-signing note supports signature inspection, but modern runtime/notarization behavior must be verified on the actual supported OS. [Apple TN2206](https://developer.apple.com/library/archive/technotes/tn2206/_index.html).
5. **Fuzz exposed native parsers.** Select a reachable file/protocol parser, isolate it behind a deterministic harness, seed representative valid inputs, and measure coverage. Use an instrumented local build and suitable sanitizers; bound CPU, memory, disk, and runtime. **Gate:** minimize and reproduce the crash, identify root cause, and explain how an attacker delivers the input to a supported release. A crash alone does not prove code execution or bounty eligibility. [AFL++ fuzzing guide](https://aflplus.plus/docs/fuzzing_in_depth/).
6. **Retest with realistic privileges.** Restore the clean snapshot and reproduce the smallest effect without debugger-granted access or administrative preconfiguration that the attack would not possess. Include user interaction, restart requirements, and deployment differences in the report.

## Electron and browser-extension playbook

For **Electron**, map remote/local content → renderer → preload/context bridge → main-process IPC → filesystem, shell, credentials, or privileged helper. Inspect window-specific settings rather than assuming defaults apply everywhere. Trace navigation, child windows, custom protocols, `shell.openExternal`, and permission decisions. Validate IPC sender frame/origin and arguments; `contextIsolation: true` does not repair a bridge exposing arbitrary privileged methods. **Gate:** demonstrate an attacker-controlled input reaching a protected operation through the shipped bridge, rather than executing code manually in developer tools. [Electron security](https://www.electronjs.org/docs/latest/tutorial/security), [Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation).

For **extensions**, map page → content script → service worker/extension page → privileged browser API. Inspect host permissions, optional permissions, `externally_connectable`, web-accessible resources, CSP, and message handlers. Check sender identity, origin/frame association, action allowlists, and argument constraints across asynchronous navigation. Broad permissions increase the potential impact but do not themselves demonstrate abuse. **Gate:** a controlled web page or authorized test extension causes an unintended privileged action without first receiving privileges unavailable to a realistic attacker. [Chrome extension security](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure), [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging).

If a native-messaging host exists, extend the analysis into its manifest, allowed extension origins, executable location, framing/parser, and command handling. The native host runs outside the browser process; extension-side validation is only one part of the chain. **Gate:** preserve the complete web-to-extension-to-native sequence and its actual privileges, or report only the narrower verified boundary. [Chrome native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging).

## Desktop hypotheses

| Hypothesis | Local validation | Evidence gate |
|---|---|---|
| A privileged service trusts a writable file | Trace one normal operation and inspect its ACL | Standard-user control, consumer identity, meaningful effect |
| Update verification covers the wrong object | Exercise a local fixture through equivalent verification code | Accepted bytes, expected signer/policy, acceptance point |
| URL/file handler misinterprets input | Use a synthetic URI/document with a harmless marker | Entry path, argument interpretation, resulting operation |
| Electron IPC trusts an untrusted frame | Trace a controlled frame through a shipped bridge | Sender origin, method reachability, protected capability |
| Extension forwards arbitrary privileged requests | Exercise a local page through its normal content script | Real sender, requested action, cross-boundary result |
| Native parser has a memory-safety defect | Minimize a local sanitizer-triggering input | Reproducible fault, root cause, supported attack path |

## Desktop checklist

**Native applications: apply each item to Windows, macOS, or Linux as relevant.**

- [ ] Product, platform, architecture, channel, version, hash, signer recorded.
- [ ] Installer, updater, service/helper, and plugin scope separated.
- [ ] Clean snapshot and standard-user baseline captured.
- [ ] Default installation paths and post-install actions mapped.
- [ ] Service/helper effective identity documented.
- [ ] IPC caller authentication and object-level authorization reviewed.
- [ ] Writable executable, configuration, temporary, and search paths checked.
- [ ] Windows registry/filesystem ACLs and named-pipe access inspected.
- [ ] macOS XPC, launch services, entitlements, and signing checks inspected.
- [ ] Linux sockets, D-Bus/polkit, service users, capabilities, and ownership inspected.
- [ ] Protocol handlers, file associations, imports, and archive boundaries exercised.
- [ ] Update metadata, artifact, signer, and rollback policy traced.
- [ ] Parser fuzzing limited to a local harness with resource limits.
- [ ] Crashes minimized; impact distinguished from code-execution speculation.
- [ ] Reproduction repeated without artificial administrator privileges.

**Electron and extensions**

- [ ] Shipped Electron/browser version and extension ID/version captured.
- [ ] Store-installed and modified/unpacked evidence distinguished.
- [ ] Every renderer/window’s security settings inspected.
- [ ] Context isolation and sandbox assumptions verified.
- [ ] Preload methods and main-process IPC handlers inventoried.
- [ ] IPC sender frame/origin and argument checks inspected.
- [ ] Navigation, child-window, and external-protocol handling reviewed.
- [ ] Host/API/optional permissions and intended usage mapped.
- [ ] External messaging and web-accessible resources restricted appropriately.
- [ ] Page-origin data treated as untrusted through content-script messages.
- [ ] Privileged service-worker actions require bounded inputs.
- [ ] Native-messaging host origin list, path, and parser reviewed.
- [ ] Local browser profile contains only synthetic application data.
- [ ] Result reproduced through a realistic entry point, without console-only access.

## Desktop command cheat sheet

These are local inspection examples. Paths refer to lab copies. A successful signature check establishes signature validity under the tool’s rules, not absence of vulnerabilities. PowerShell Authenticode inspection is Windows-specific; Apple commands require macOS. [Microsoft Authenticode](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5), [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls), [Apple signature verification](https://developer.apple.com/library/archive/technotes/tn2206/_index.html), [GNU readelf](https://sourceware.org/binutils/docs/binutils/readelf.html).

```powershell
# Windows / PowerShell: inspection only.
Get-AuthenticodeSignature -FilePath 'C:\Lab\App.exe' | Format-List
icacls 'C:\Lab\App.exe'
icacls 'C:\Program Files\ExampleApp'
```

```bash
# macOS: inspect a lab copy; do not re-sign it for the baseline.
plutil -p ./Example.app/Contents/Info.plist
codesign -dv --verbose=4 ./Example.app
codesign -d --entitlements :- ./Example.app
codesign --verify --deep --strict --verbose=2 ./Example.app

# Linux or another host with GNU binutils: read ELF metadata without execution.
readelf -hW ./lab-app
readelf -lW ./lab-app
readelf -dW ./lab-app

# Search local source/extracted JavaScript; matches are investigation leads.
rg -n 'ipcMain|contextBridge|nodeIntegration|contextIsolation|openExternal' ./source
rg -n 'onMessage|externally_connectable|host_permissions|nativeMessaging' ./extension
```

For an already prepared AFL++ lab, first inspect `afl-fuzz -h`. A campaign skeleton is `afl-fuzz -i ./seeds -o ./fuzz-results -- ./parser-harness @@`; `@@` supplies the current input filename. It runs until stopped unless bounded by supported runtime options. Configure limits before starting, and interrupt with Ctrl-C. The harness must avoid network calls, production credentials, and side effects outside the disposable lab. [AFL++ execution and resource guidance](https://aflplus.plus/docs/fuzzing_in_depth/).

## Extension cases to complete before closing the review

The [extension message procedure](#page-modules-extension-message-boundaries) adds a full case matrix for page forwarding, browser-supplied identity, changed document after navigation, worker restart and optional permission revocation. Run it before [native IPC](#page-modules-desktop-ipc) if the product contains an extension. Chrome's message metadata and service-worker lifetime are separate concerns; preserve both in the evidence. [MessageSender](https://developer.chrome.com/docs/extensions/reference/api/runtime#type-MessageSender), [worker lifecycle](https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle).

| Boundary | Positive control | Negative control |
|---|---|---|
| Page to extension | Intended action from allowed page | Same action from second controlled origin |
| Delayed response | Original document remains | Tab navigates before result delivery |
| Worker lifetime | Authorized operation before stop | Denied operation remains denied after restart |
| Optional permission | User grants required capability | Capability revoked through browser controls |

Backend sign-in shared with mobile/web belongs in [federation/token trust](#page-modules-federation-token-trust) and [authenticator lifecycle](#page-modules-authenticator-lifecycle). Preserve the native callback or extension route in the reproduction instead of reporting only a generic server test.

## Sources


All sources accessed **2026-09-11**. “Undated” means no reliable publication/update date was established from the retrieved page. Dates are page metadata, not a guarantee of completeness for every current OS version. Archived Apple sources are used for established mechanisms and command syntax, not blanket claims about current platform enforcement.

| ID | Publisher / exact source | Date | Use |
|---|---|---|---|
| MD01 | OWASP, [OWASP MASVS](https://mas.owasp.org/MASVS/) | Undated; living standard | Mobile control organization |
| MD02 | OWASP, [OWASP MASTG](https://mas.owasp.org/MASTG/) | Undated; living guide | Testing methodology and technique catalog |
| MD03 | OWASP, [Mobile Application Security Weakness Enumeration](https://mas.owasp.org/MASWE/) | Undated; living catalog | Weakness taxonomy and version caution |
| MD04 | Google, [Android Debug Bridge](https://developer.android.com/tools/adb) | Updated 2026-09-02 | Device/package inspection commands |
| MD05 | Google, [apkanalyzer](https://developer.android.com/tools/apkanalyzer) | Updated 2026-03-05 | APK metadata and manifest CLI |
| MD06 | Google, [apksigner](https://developer.android.com/tools/apksigner) | Updated 2026-03-05 | APK certificate/signature inspection |
| MD07 | Google, [android:exported](https://developer.android.com/privacy-and-security/risks/android-exported) | 2024-09-24, indexed page date | Component exposure and version dependence |
| MD08 | Google, [Unsafe use of deep links](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks) | 2024-10-24, indexed page date | Deep-link validation |
| MD09 | Google, [WebView – Native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges) | Updated 2024-10-15 | Frames, native bridges, origin boundaries |
| MD10 | Google, [Network security configuration](https://developer.android.com/privacy-and-security/security-config) | Updated 2026-08-28 | Trust anchors and debug overrides |
| MD11 | Google, [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics) | Undated in this registry | Provider access model |
| MD12 | skylot/JADX maintainers, [JADX repository and CLI](https://github.com/skylot/jadx) | Undated; living README | Decompiler usage and limitations |
| MD13 | Apktool maintainers, [CLI Parameters](https://apktool.org/docs/cli-parameters/) | Undated | Local package decoding |
| MD14 | OWASP, [iOS Security Testing](https://mas.owasp.org/MASTG/0x06b-iOS-Security-Testing/) | Undated | iOS lab/platform distinctions |
| MD15 | Apple, [Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) | Published 2024-12-19 | Access groups, classes, authentication constraints |
| MD16 | Apple, [Support Universal Links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html) | Updated 2016-12-15; archived | App/website association model |
| MD17 | OWASP, [MASTG-TOOL-0062: Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/) | Undated | Property-list inspection tooling |
| MD18 | OWASP, [MASTG-TECH-0111: Extracting Entitlements from MachO Binaries](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/) | Undated | Signing/entitlement inspection |
| MD19 | Apple, [TN2206: macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html) | Page updated 2016-09-13; archived | Signature verification command and boundaries |
| MD20 | Microsoft / Mark Russinovich, [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) | Published 2026-09-10 | Local process, registry, filesystem observation |
| MD21 | Microsoft, [Get-AuthenticodeSignature](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) | Undated; PowerShell 7.5 documentation | Windows signature inspection |
| MD22 | Microsoft, [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) | Updated 2025-06-09 | Windows ACL inspection |
| MD23 | OpenJS Foundation / Electron contributors, [Security](https://www.electronjs.org/docs/latest/tutorial/security) | Undated; living documentation | Renderer, navigation, IPC boundaries |
| MD24 | Electron contributors, [Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation) | Undated | Bridge limitations and API exposure |
| MD25 | Google, [Stay secure](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure) | Page states updated 2018-03-06 | Extension permissions and untrusted messages |
| MD26 | Google, [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging) | Page states updated 2025-12-03 | Extension messaging contexts |
| MD27 | Google, [Native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) | Page states updated 2023-02-27 | Native host manifest and execution boundary |
| MD28 | AFL++ maintainers, [Fuzzing in Depth](https://aflplus.plus/docs/fuzzing_in_depth/) | Undated; living guide | Harness, corpus, execution, resource limits |
| MD29 | GNU Binutils / Sourceware, [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) | Undated | Non-executing ELF metadata inspection |


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller.
- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function)
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property)
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection)
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass)
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary)
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection)
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow)
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change)
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read)
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation)
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution)
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape)
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz)
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization)
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking)
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials)
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning)
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution)
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos)
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files)
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path)
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate)
- [Backup or transfer exposes unintended sensitive client state](#page-vulnerabilities-client-backup-sensitive-state)
- [Sensitive client state leaks through accessible diagnostics](#page-vulnerabilities-client-secret-logging)
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate)
- [Electron IPC exposes main-process authority to an untrusted sender](#page-vulnerabilities-electron-ipc-confused-deputy)
- [Desktop protocol handler misinterprets external input](#page-vulnerabilities-desktop-protocol-confusion)
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact)
- [Privileged updater consumes lower-user-controlled staging content](#page-vulnerabilities-updater-privileged-staging)
- [Attacker-controlled rollback restores a prohibited security state](#page-vulnerabilities-update-security-rollback)
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness)
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash)
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing)
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass)
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure)
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion)
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass)
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection)
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority)
- [Delayed extension result reaches a different document](#page-vulnerabilities-extension-document-reply-confusion)
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure)


---

<a id="page-cloud"></a>

# Cloud, containers, Kubernetes and infrastructure as code

The hunting unit is a **principal acting on a resource across a promised boundary**. A cloud-hosted application, its customer's cloud account, the underlying managed service, and the cloud provider are separate scopes. A public hostname or uploaded domain inventory does not establish ownership of the backing bucket, account, cluster, CDN distribution or SaaS tenant.

## Scope and provider policy

Record the provider, account/project/subscription ID, tenant or organization ID, region, exact resource identifier, endpoint, permitted principal and excluded adjacent services. For containers, add image repository and digest, runtime, host ownership and allowed execution environment. For Kubernetes, add cluster/context, namespace, service account, controller and control-plane ownership. For IaC, add repository commit, module/provider versions, workspace and whether generated plans or deployed infrastructure are included.

Provider permission and program permission must both cover the activity. A SaaS program can authorize application testing without authorizing customer-owned integrations or the CSP control plane. Conversely, a provider's permission to test your own resources does not make another customer's resources available.

| Provider | Current operational rule | Hunting implication |
|---|---|---|
| AWS | Listed services may be tested without prior approval; unlisted services require AWS engagement. Testing AWS infrastructure/services themselves is outside this customer policy. C2 needs prior approval. The page explicitly prohibits S3 bucket takeover and subdomain takeover, flooding and specified Route 53 attacks; API Gateway and Bedrock AgentCore are prohibited for outbound penetration testing. | Check the current service/activity list. An application's bounty policy cannot override AWS restrictions. Do not claim dangling AWS resources as a default validation step. [AWS policy](https://aws.amazon.com/security/penetration-testing/) |
| Microsoft/Azure | The unified rules cover owned or explicitly authorized assets. They prohibit third-party data/credential access, including publicly leaked credentials, DoS, excessive automation and post-exploit activity beyond initial identification. They encourage cross-tenant tests using test accounts and require immediate reporting of identified vulnerabilities. | Use two owned trial tenants where applicable. Stop at the initial boundary proof; do not enumerate internal files, dump secrets or pivot. Check the separate bounty scope for reward eligibility. [Microsoft rules](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement) |
| Google Cloud | Prior notification is unnecessary for testing your own projects, provided tests affect only those projects and comply with the AUP and terms. | Project identity matters more than a shared IP range. Provider vulnerabilities follow Google's reporting route; customer application findings follow the customer's program. [Google Cloud FAQ](https://support.google.com/cloud/answer/6262505?hl=en) |

These are policy snapshots checked on 2026-09-11, not permanent permissions. Account inventory commands below are ordinary authorized administration; their presence does not imply that every service is approved for penetration testing.

## Staged playbook

**1. Establish two controlled identities.** Prefer program-provided test credentials or two owned lab tenants, each with synthetic objects. Separate the administrative fixture-creation identity from the low-privilege identity used to reproduce the issue. Record the effective caller before every session. A role called “read only” is not sufficient evidence: inspect permitted actions and data access.

**2. Build the authority graph.** Trace user → application → workload identity → cloud API → resource. Distinguish management-plane permissions from data-plane permissions; a reader of resource configuration may lack blob access, while a workload can have data access without subscription administration. For AWS, evaluate identity policies, resource policies, boundaries, session restrictions and organization controls together; a single allow statement does not establish effective access. [IAM evaluation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)

**3. Follow a business object through storage and jobs.** Create one canary document in tenant A and another in B. Exercise upload, preview, export, asynchronous processing, attachment download, sharing and deletion. Compare the authenticated caller with the tenant supplied in URLs, object keys, job messages and signing requests. Inspect authorization at both submission and retrieval: a protected export creation endpoint can still produce an unprotected result URL.

Presigned URLs are bearer capabilities. Sharing one can intentionally grant access until expiry; this alone is not IDOR. Investigate unauthorized URL issuance, a signature covering the wrong object/method, excess lifetime against a documented requirement, or ability to replace a different tenant's object. AWS documents that their usable lifetime also depends on the signing credentials. [S3 presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)

**4. Inspect Kubernetes boundaries before attempting runtime behavior.** Determine whether the promise is namespace separation, virtual control planes, dedicated nodes or dedicated clusters. Namespaces require supporting authorization, networking and storage controls; creating a NetworkPolicy object does not prove enforcement by the CNI. Map ingress, pod egress, persistent volumes and shared controller privileges separately. [Kubernetes multi-tenancy](https://kubernetes.io/docs/concepts/security/multi-tenancy/)

Review workload-creation permission as a capability to select service accounts and mount namespace resources. Inspect `bind`, `escalate`, `impersonate`, token-request and `nodes/proxy` grants; even a `get` on `nodes/proxy` is not necessarily read only. Do not dump Secrets to prove that `list` reveals their content. Use permission review, supplied policy exports and a deliberately created canary instead. [RBAC risks](https://kubernetes.io/docs/concepts/security/rbac-good-practices/)

**5. Review admission and controllers as separate authorization layers.** Check create/update coverage, resource/subresource matches, exclusions, namespace labels, mutating order and webhook failure behavior. A low-privilege custom resource can be consumed by a powerful operator: inspect whether it can nominate another namespace, secret reference, service account, volume or external destination. In an isolated cluster, compare the requested object, admission decision and controller-produced object. Server dry-run contacts admission components and is not an offline safety guarantee. [Admission guidance](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)

**6. Trace IaC and container assumptions into deployment.** Inspect default values, conditional branches, environment overlays, chart rendering, mutable image references and identity bindings. A repository warning becomes a strong finding when a supported deployment creates an unintended reachable boundary. Pin the image digest, map the vulnerable code to that image, and separate container UID 0 from proven host privilege. Review privileged mode, host namespaces, host mounts and capabilities against the deployment's isolation promise. [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)

Terraform's `sensitive` flag redacts normal display; it does not automatically remove values from state. Review state/plan access and secret lifetimes, while treating any obtained state as sensitive evidence. Never run unreviewed provider binaries or provisioning code with workstation credentials. [Terraform sensitive data](https://developer.hashicorp.com/terraform/language/manage-sensitive-data)

## Hypotheses, controlled tests and evidence

The following are test-design recommendations; prerequisites must be satisfied before execution.

| Hypothesis | Minimum controlled test | Evidence and interpretation |
|---|---|---|
| Tenant supplied by the client controls the signing identity | Ask as A for a signed URL naming B's owned canary, then perform only the permitted canary read | A identity, B object ownership, signing request, resulting canary bytes. Ordinary use of a legitimately issued share URL is a negative control. |
| A queued job loses caller authorization | Submit a benign export, revoke A's access to its own fixture, then request the result | Job ID, before/after access state, export timestamp and documented revocation semantics. Do not assume immediate revocation is promised. |
| Fetcher follows an unsafe destination | Send one URL to an owned callback; test redirect handling entirely between owned endpoints | Unique nonce and callback log prove server-side fetching only. They do not prove metadata access or credential theft. Use a mock metadata service in a local replica for that path. |
| IAM trust is broader than the integration contract | Compare supplied trust conditions and principal restrictions against two owned identities | Exact policies and denied/allowed benign operation. Treat missing conditions as a hypothesis until their security consequence is shown. |
| A controller trusts cross-namespace references | In a local cluster, have tenant A reference tenant B's synthetic object through one supported custom resource | Custom resource, reconciler identity, generated object and synthetic result; isolate controller behavior from a direct RBAC bypass. |
| Admission excludes a supported update path | Compare normal creation and one equivalent update using a harmless lab workload | Both requests, policy match information and final security context. Never deploy a privileged production workload just to strengthen evidence. |
| Template defaults undermine isolation | Render the supported configuration; inspect policy and reproduce with local fixtures | Commit, values file, rendered resource, reachable boundary and secure comparison. A linter finding alone is not demonstrated exploitation. |

## Checklist

- [ ] Exact account/project/subscription, resource owner and active principal match scope.
- [ ] CSP policy and bounty policy both cover the method; third-party integrations are identified.
- [ ] Test tenants A/B, synthetic objects and baseline denied requests exist.
- [ ] Management plane, data plane, storage signing and background jobs are separately mapped.
- [ ] IAM inheritance and restrictions are considered; exported policy is not mistaken for effective permission.
- [ ] Cluster, namespace, CNI, admission, operator and node boundaries are distinguished.
- [ ] Workload creation and sensitive RBAC verbs are reviewed without reading real secrets.
- [ ] Image/module digest, supported deployment mode and runtime reachability are recorded.
- [ ] SSRF proof uses owned callbacks; impact beyond the callback remains explicitly unproven.
- [ ] The report contains one minimum boundary violation, redacted evidence and cleanup status.

## Command cheat sheet

Use installed official CLIs, your own configured lab credentials and the literal approved IDs. These eight commands read configuration or perform local validation; none grants permission to broaden scope. Do not substitute credentials found in a repository. Protect output files because policies and identities can be confidential.

```bash
# 1. Confirm the AWS principal; no secret value is printed.
aws --profile bounty-lab sts get-caller-identity --output json --no-cli-pager

# 2. Inspect one owned general-purpose bucket's policy status.
aws --profile bounty-lab s3api get-bucket-policy-status \
  --bucket YOUR_OWN_BUCKET --expected-bucket-owner YOUR_ACCOUNT_ID \
  --output json --no-cli-pager

# 3. Confirm Azure's selected subscription and tenant.
az account show --query '{subscription:id,tenant:tenantId,user:user.name}' -o json

# 4. Read the policy attached to one owned GCP project.
gcloud projects get-iam-policy YOUR_OWN_PROJECT_ID --format=json

# 5. Ask permission without reading the canary Secret.
kubectl --context bounty-lab -n tenant-a auth can-i get secrets/bounty-canary

# 6. Review only the owned namespace's configuration.
kubectl --context bounty-lab -n tenant-a get roles,rolebindings,networkpolicies -o json

# 7. Inspect a local image without executing its entrypoint.
docker image inspect YOUR_LOCAL_IMAGE --format '{{.Id}} {{json .Config.User}}'

# 8. Validate a trusted, already-initialized local Terraform module.
terraform -chdir=./owned-lab-iac validate -json
```

Command references: [AWS identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html), [bucket status](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-policy-status.html), [Azure account](https://learn.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest), [GCP policy](https://docs.cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy), [kubectl permission query](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/), [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), [Docker inspect](https://docs.docker.com/reference/cli/docker/image/inspect/), [Terraform validate](https://developer.hashicorp.com/terraform/cli/commands/validate).

Interpret results narrowly: bucket policy status is not a complete audit of all object-access paths; a GCP project policy does not enumerate every inherited control; `can-i` evaluates authorization, not admission or exploitability; `terraform validate` checks configuration validity, not security. Terraform may invoke installed provider plugins, so “local” does not mean safe for an untrusted repository.

## Provider-specific execution branch

Use [Azure and GCP boundaries](#page-modules-azure-gcp-boundaries) alongside the shared IAM and storage procedures. Azure testing must distinguish Entra data roles from management authority, account-key access and SAS. GCP testing must distinguish service-account attachment from token creation, and bucket IAM from object ACLs where those remain enabled. The module includes bounded policy and single-object metadata commands with explicit authentication assumptions.

Map each observed result to its actual credential path. If an SDK or CLI silently changes from user authentication to account keys or an impersonated service account, rerun the comparison with the intended identity before calling it an authorization bypass.

## Sources

All accessed 11 September 2026. Match living documentation to the target version.

| Publisher | Source | Publication or version |
|---|---|---|
| Amazon Web Services | [Penetration Testing](https://aws.amazon.com/security/penetration-testing/) | Undated |
| Microsoft Security Response Center | [Microsoft Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement) | Undated |
| Google | [Cloud Security FAQ](https://support.google.com/cloud/answer/6262505?hl=en) | Undated |
| Amazon Web Services | [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) | Undated |
| Amazon Web Services | [Download and upload objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) | Undated |
| Kubernetes | [Multi-tenancy](https://kubernetes.io/docs/concepts/security/multi-tenancy/) | Undated living documentation |
| Kubernetes | [Role Based Access Control Good Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) | Undated living documentation |
| Kubernetes | [Admission Webhook Good Practices](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/) | Undated living documentation |
| Kubernetes | [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) | Undated living documentation |
| Kubernetes | [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | Undated living documentation |
| HashiCorp | [Manage sensitive data in your configuration](https://developer.hashicorp.com/terraform/language/manage-sensitive-data) | Undated |
| Amazon Web Services | [get-caller-identity — AWS CLI v2 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html) | Undated living documentation |
| Amazon Web Services | [get-bucket-policy-status — AWS CLI v2 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-policy-status.html) | Undated living documentation |
| Microsoft Learn | [az account](https://learn.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest) | Undated living documentation |
| Google Cloud | [gcloud projects get-iam-policy](https://docs.cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy) | Undated living documentation |
| Kubernetes | [kubectl auth can-i](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/) | Undated living documentation |
| Docker | [docker image inspect](https://docs.docker.com/reference/cli/docker/image/inspect/) | Undated |
| HashiCorp | [terraform validate command reference](https://developer.hashicorp.com/terraform/cli/commands/validate) | Undated |


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.
- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.
- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.
- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function)
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary)
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input)
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response)
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization)
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials)
- [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection)
- [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution)
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning)
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files)
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path)
- [Overbroad cloud role trust](#page-vulnerabilities-cloud-iam-role-trust)
- [Excessive service-role delegation](#page-vulnerabilities-cloud-passrole-escalation)
- [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope)
- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read)
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write)
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope)
- [Private delivery policy bypassed through the origin](#page-vulnerabilities-cloud-origin-access-bypass)
- [Kubernetes Secret access exceeds tenant permissions](#page-vulnerabilities-kube-secret-rbac-exposure)
- [Workload creation grants unintended service-account authority](#page-vulnerabilities-kube-workload-identity-selection)
- [Admission policy misses a supported object or update path](#page-vulnerabilities-kube-admission-policy-gap)
- [Namespace or workload network restriction is ineffective](#page-vulnerabilities-kube-network-isolation-failure)
- [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure)
- [Sensitive values exposed through state or plan artifacts](#page-vulnerabilities-iac-state-secret-exposure)
- [Secrets retained in container build artifacts](#page-vulnerabilities-container-build-secret-leak)
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default)
- [Dangling DNS reference to a retired service](#page-vulnerabilities-dns-dangling-resource-reference)
- [Redis authentication or key ACL boundary failure](#page-vulnerabilities-redis-canary-access)
- [PostgreSQL trust authentication exceeds the approved network boundary](#page-vulnerabilities-postgres-unintended-trust-auth)
- [Message broker permissions cross a virtual-host boundary](#page-vulnerabilities-queue-virtual-host-boundary)
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth)
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate)
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret)
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust)
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust)
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass)
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure)
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion)
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass)
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection)
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict)
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection)
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure)
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding)
- [GitLab job token crosses an unintended project boundary](#page-vulnerabilities-gitlab-job-token-boundary)
- [Shared CI runner exposes private state across jobs](#page-vulnerabilities-ci-runner-cross-job-state)
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure)
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit)


---

<a id="page-ai"></a>

# AI, LLM, agent and MCP scopes

An AI finding needs an attacker-controlled input, a security boundary, a measurable unauthorized result and reproducible conditions. Offensive wording, hallucinations and a model repeating supplied text are not automatically vulnerabilities. A program may separately reward model-safety failures; check that scope explicitly. OWASP's AI Testing Guide covers broader trustworthiness properties as well as security, while its LLM Top 10 supplies a risk taxonomy rather than universal bounty eligibility. [AI Testing Guide](https://owasp.org/www-project-ai-testing-guide/), [LLM Top 10](https://genai.owasp.org/llm-top-10/)

## Scope decomposition

| Scope | Identity to pin | Boundary worth testing |
|---|---|---|
| Hosted inference/chat API | Endpoint, model identifier, project, API principal, version/date | Authentication, tenant objects, model access, quotas and output processing |
| RAG/document assistant | Tenant, collection/index, document IDs, source permissions | Ingestion ownership, retrieval filtering, citations, caches and revocation |
| Tool-using agent | Agent version, caller, available tools, execution identity | Instructions versus retrieved data, tool authorization and user approval |
| MCP implementation | Client/server package versions, protocol version, transport, OAuth issuer/resource | Token audience, per-request identity, tool/resource authorization and state ownership |
| Open weights/model artifact | Repository revision, weight digest, format, loader/runtime | Artifact provenance, parser behavior and loading-time code execution |
| Training/fine-tuning pipeline | Dataset/version, job/project, checkpoint destination | Poisoning, unauthorized training data and model/artifact publication |

These scopes are independent. A license to download weights does not authorize attacks on their hosting platform. An inference endpoint does not grant permission to extract unpublished weights or training data. A local loader finding may be an OSS vulnerability without affecting the hosted deployment; demonstrate the actual supported path.

## Staged playbook

**1. Establish the product contract and deterministic baseline.** Identify what the user intended, what the attacker can change and which tools the agent can invoke. Record model identifier, sampling parameters, system/application configuration where available, enabled connectors and versioned fixtures. Build two owned tenants and unique synthetic canaries. Set a small explicit trial count and request/token budget; a refusal screenshot is not a complete test outcome.

**2. Map every entry point and sink.** Entry points include chat, uploaded files, OCR/transcripts, repository text, retrieved web pages, vector results, tool descriptions and tool responses. Sinks include rendered HTML, SQL, shell arguments, network requests, document writes, permissions and external messages. Follow context through summarization and agent handoffs: security decisions must survive transformations, not just the initial prompt.

**3. Separate behavior steering from an authority violation.** Put a harmless instruction in one lower-trust fixture and have the owned victim account perform its legitimate task. First observe whether the instruction influences the answer. Then test whether that influence causes a restricted synthetic data read, changes a tool argument, or bypasses a required confirmation in a mocked action. An agent saying it sent a message proves nothing unless the tool/audit log shows the action. Excessive agency concerns the combination of tool functionality, permission and autonomy. [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)

Example proof design: tenant B owns a private document containing a random `B_PRIVATE_...` marker. Tenant A controls a shared document that the assistant is legitimately asked to summarize. If processing A's document causes B's assistant to retrieve B's private marker and expose it through an attacker-visible result, record that precise data boundary. Keep both identities under researcher control; use a stub outbox if the product action is a message. The marker must not appear in the attack text or baseline context, otherwise the experiment proves copying rather than disclosure.

**4. Audit RAG as an authorization system.** Trace tenant identity from the authenticated session into the query filter, document resolver and citation downloader. Compare direct document access with semantic retrieval; test renamed documents, deleted/revoked sources, shared-to-private transitions and cached answers. In local source review, look for optional client-supplied tenant filters and global fallback searches. Log retrieved document IDs and the final response independently: unauthorized retrieval remains important even when the final model declines to quote it, but externally observable impact must be stated accurately. [OWASP Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)

**5. Test tools below the model.** Repeat the controlled tool operation directly through its supported API with the same principal. Vary only owned object IDs, tenant IDs, destination accounts or a synthetic state handle. Verify server-side identity binding, schema validation, object ownership, canonical paths and approval state. A tool description saying “read only” does not implement authorization. Distinguish model-induced unauthorized behavior from a conventional backend authorization defect that the model merely exposes. [MCP Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)

**6. Audit MCP according to the deployed protocol era.** As checked on 2026-09-11, the 2026-07-28 specification removes the initialization handshake and protocol sessions; requests carry version/capability metadata, and `server/discover` advertises capabilities. Earlier deployments through 2025-11-25 can still use `initialize` and session IDs. Apply session-binding tests to those implementations and explicit state-handle ownership tests to modern ones. Mixing protocol eras creates false positives. [MCP changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)

For OAuth, separate client → MCP and MCP → upstream credentials. Check issuer, audience/resource, expiry, scope and per-request validation with your own tokens. A token for one resource must not become a credential for another merely because the proxy accepts it. Inspect per-client consent where an MCP proxy uses a shared upstream OAuth client; previous consent to one client must not silently authorize a different client. [MCP Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

For HTTP transports, check invalid `Origin` rejection and whether header/body metadata disagree across a gateway and backend. Current Streamable HTTP requires version and method headers corresponding to the body, plus name/parameter headers where applicable. An authentication failure is not proof that Origin validation works; use an otherwise-valid request. In local stdio setups, inspect the executable/package provenance, inherited environment, allowed filesystem roots and process sandbox. Test OAuth metadata fetching with owned callback URLs, not actual cloud metadata or internal services. [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

**7. Review weights and model-loading paths as software supply chains.** Pin repository revision, model hash, loader package and all custom-code dependencies. Inspect `trust_remote_code`, unsafe deserialization, remote archive extraction, template parsing and plugin discovery. Hugging Face custom models can require executing repository-defined model code; that is an explicit trust decision, not automatically a library vulnerability. PyTorch's restricted weight loading reduces attack surface but is not a complete hostile-file sandbox. Begin with static inspection; perform malformed-artifact tests only in an isolated disposable runtime without credentials. [Transformers custom models](https://huggingface.co/docs/transformers/custom_models), [PyTorch serialization](https://docs.pytorch.org/docs/stable/notes/serialization.html)

**8. Minimize and quantify.** Preserve full relevant inputs, retrieved content hashes, visible outputs and tool/audit events. Repeat fresh sessions with and without the candidate input, report successes/attempts and avoid presenting a stochastic result as universal. Keep the successful transcript, including the legitimate task; an attack string without the surrounding conditions is rarely reproducible. System-prompt disclosure should be assessed for exposed sensitive data or broken authorization, not presumed critical simply because instructions were revealed. [OWASP System Prompt Leakage](https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/)

## Hypotheses, controlled tests and evidence

| Hypothesis | Minimum controlled test | Evidence and interpretation |
|---|---|---|
| Retrieved instructions become tool authority | One attacker-owned document causes an owned victim's agent to invoke a mock restricted tool | Document hash, legitimate task, tool name/arguments, execution identity and stub audit event. An answer-style change alone is behavior evidence. |
| RAG applies tenant filtering only in the UI | Query A for a unique B-only marker through retrieval and citation paths | A token identity, B document ownership, retrieved IDs and final disclosure; include expected denied direct access. |
| Tool accepts caller-supplied ownership | Call the tool as A with B's synthetic object or workspace ID | Backend decision and canary result. Categorize underlying BOLA/IDOR independently of the LLM. |
| Agent approval binds to an obsolete action | In a local fixture, approve a harmless draft, then change its destination before execution | Approved argument digest versus executed argument digest and mock result. Do not send a real message. |
| MCP accepts a token for a different audience | Use a valid token issued to your own second resource against a harmless protected lab tool | Token claim summary, expected audience, request and unauthorized synthetic result; never publish token values. |
| State handles are bearer authorization | Supply your B-owned workflow handle while authenticated as A | Both authenticated identities, handle creation and B canary output. Legacy session behavior requires a version-specific test. |
| Gateway and MCP server disagree on routing identity | In a local fixture, vary one mirrored header against its body field | Request, gateway route, backend principal and result; mere protocol nonconformance is not automatically exploitable. |
| Model loading executes unintended code | Trace an externally reachable import path into an unsafe loader; reproduce using a benign local marker fixture | Digest, loader call, minimal input, isolated side effect and supported deployment path; do not load unknown artifacts on a credentialed workstation. |

## Checklist

- [ ] Hosted application, model, artifact, connector and provider scopes are distinguished.
- [ ] Attacker capability and the legitimate user's task are explicitly recorded.
- [ ] A/B tenants and private random canaries exist; canaries are absent from attacker input.
- [ ] Baseline requests establish expected permissions before adversarial input.
- [ ] Model version, runtime, sampling settings and trial budget are fixed and logged.
- [ ] Retrieval authorization, citations, caches and revocation are tested separately.
- [ ] Tool argument ownership and approval binding are checked below the model.
- [ ] MCP protocol era, transport, OAuth audience and upstream credentials are mapped.
- [ ] Model hashes, custom code and deserialization paths are reviewed in isolation.
- [ ] Success means an observable security consequence; hallucinated actions are excluded.
- [ ] Attempts/successes, evidence redaction and cleanup are documented.

## Command cheat sheet

These six commands are static/local inspection or protocol discovery against an owned fixture. Use a trusted Python 3.11+ interpreter for `file_digest`; isolated mode and disabled site initialization prevent imports from the working directory and site customizations. No model or repository code is executed by the first four. Local HTTP examples assume your intentionally unauthenticated loopback fixture; for an authenticated fixture, use its documented lab credentials. Inventory results do not establish tool-call authorization.

```bash
# 1. Find loader and execution sinks in a local source checkout.
rg -n 'trust_remote_code|torch\.load|pickle\.loads?|subprocess|shell=True' ./repo

# 2. Fingerprint one local weight artifact without loading the model.
python3 -I -S -c 'import hashlib; f=open("./model/model.safetensors","rb"); print(hashlib.file_digest(f,"sha256").hexdigest())'

# 3. Inspect JSON model configuration without importing custom model code.
python3 -I -S -m json.tool ./model/config.json

# 4. Generate a synthetic marker for your private test document.
python3 -I -S -c 'import secrets; print("B_PRIVATE_" + secrets.token_hex(16))'

# 5. Discover a local MCP server implementing the 2026-07-28 protocol.
curl -q --noproxy '*' --proto '=http' --silent --show-error --max-time 10 http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' -H 'Mcp-Method: server/discover' \
  --data '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{},"io.modelcontextprotocol/clientInfo":{"name":"bounty-lab","version":"1.0"}}}}'

# 6. List tool schemas, without calling a tool, on the same modern fixture.
curl -q --noproxy '*' --proto '=http' --silent --show-error --max-time 10 http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' -H 'Mcp-Method: tools/list' \
  --data '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{},"io.modelcontextprotocol/clientInfo":{"name":"bounty-lab","version":"1.0"}}}}'
```

References for command semantics: [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md), [Python hashlib](https://docs.python.org/3/library/hashlib.html), [Python JSON](https://docs.python.org/3/library/json.html), [Python secrets](https://docs.python.org/3/library/secrets.html), [MCP changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog), [MCP HTTP binding](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools). Syntax was checked against documentation; these examples were not run against a live target.

## Close the persistence, retry and pipeline gaps

Run [AI state lifecycle](#page-modules-ai-state-lifecycle) after the initial prompting/tool tests. It covers thread/checkpoint ownership, memory provenance, delayed worker identity, MCP resumed-state controls, private caches and duplicate committed actions. A protected conversation read is not enough coverage for a separate resume or export endpoint.

| Pipeline handoff | Preserve and test |
|---|---|
| Upload → OCR/parser → index | Source owner, file validation and permission labels |
| Retrieval → summary → durable memory | Source provenance and ability to influence later authority |
| Human approval → background worker | Acting principal, argument binding, revocation and completion state |
| Model output → HTML/SQL/file/tool | Actual consumer validation and the final protected effect |
| Imported model → loader/runtime | Artifact digest, executable-code trust decision and isolation |

Reuse [file boundaries](#page-modules-file-boundaries), [source dataflow](#page-modules-source-dataflow), [browser trust](#page-modules-browser-trust) and [injection tracing](#page-modules-injection-tracing) at those ordinary software boundaries. Use [resource budgets](#page-modules-resource-budget-controls) for bounded cost and fan-out checks.

For MCP 2026-07-28, session removal does not remove application state: MRTR returns state that must be validated when it affects protected decisions. Private cache results require separate authorization contexts, and state-bearing retries have additional cache restrictions. Test the deployed implementation rather than transferring these requirements to older protocol versions. [MRTR](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr), [caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching).

Training/fine-tuning remains a distinct track: identify who may supply a dataset, start a job, select its base model and publish the resulting artifact. Test A/B job and artifact ownership before poisoning hypotheses. A measurable output change is not automatically a security violation; use the program's integrity/confidentiality contract and a separate untouched dataset control.

## Sources

All accessed 11 September 2026. Match living documentation to the target version.

| Publisher | Source | Publication or version |
|---|---|---|
| OWASP Foundation | [OWASP AI Testing Guide](https://owasp.org/www-project-ai-testing-guide/) | 2025-11-26 (v1 announcement) |
| OWASP GenAI Security Project | [LLM Top 10](https://genai.owasp.org/llm-top-10/) | 2025 edition |
| OWASP GenAI Security Project | [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) | 2025 edition |
| OWASP GenAI Security Project | [LLM08:2025 Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) | 2025 edition |
| OWASP GenAI Security Project | [LLM07:2025 System Prompt Leakage](https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/) | 2025 edition |
| Model Context Protocol | [Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) | 2026-07-28 |
| Model Context Protocol | [Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog) | 2026-07-28 |
| Model Context Protocol | [Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) | 2026-07-28 |
| Model Context Protocol | [Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) | 2026-07-28 revision |
| Model Context Protocol | [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) | 2026-07-28 |
| Hugging Face | [Customizing models — Transformers](https://huggingface.co/docs/transformers/custom_models) | Undated |
| PyTorch | [Serialization semantics](https://docs.pytorch.org/docs/stable/notes/serialization.html) | Undated living documentation |
| Andrew Gallant / ripgrep contributors | [ripgrep User Guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md) | Undated living repository |
| Python Software Foundation | [hashlib — Secure hashes and message digests](https://docs.python.org/3/library/hashlib.html) | Undated living documentation |
| Python Software Foundation | [json — JSON encoder and decoder](https://docs.python.org/3/library/json.html) | Undated living documentation |
| Python Software Foundation | [secrets — Generate secure random numbers for managing secrets](https://docs.python.org/3/library/secrets.html) | Undated living documentation |
| Python Software Foundation | [Command-line options](https://docs.python.org/3/using/cmdline.html) | Living documentation |


## Shared investigation procedures

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.
- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

## Vulnerability reference

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access)
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property)
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass)
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion)
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure)
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection)
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass)
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary)
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection)
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation)
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary)
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution)
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape)
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz)
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization)
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials)
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution)
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion)
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos)
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path)
- [Indirect prompt injection into protected tool actions](#page-vulnerabilities-indirect-prompt-tool-injection)
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization)
- [Agent approval is not bound to executed arguments](#page-vulnerabilities-agent-approval-argument-drift)
- [MCP proxy consent confuses different clients](#page-vulnerabilities-mcp-proxy-confused-deputy)
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion)
- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval)
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak)
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret)
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure)
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness)
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection)
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict)
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection)
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure)
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding)
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership)
- [MCP resumed state changes authorization or request meaning](#page-vulnerabilities-mcp-resume-state-integrity)
- [Private MCP result is reused across authorization contexts](#page-vulnerabilities-mcp-private-cache-context)
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect)
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading)
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure)
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit)


---

<a id="page-web3"></a>

# Web3, smart contracts and blockchain protocols

Treat this branch as an audit of **deployed state, economic rules and trust assumptions**. Solidity source is only part of the target. A valid finding connects an attacker action to an eligible impact on the correct deployment; an interesting flaw in a repository does not establish that connection.

## Roadmap and entry criteria

| Stage | Work product | Exit criterion |
|---|---|---|
| Execution semantics | Local examples covering storage, calls, delegate calls, revert behavior, token hooks and signing | Explain which address owns state and which actor has authority at every call boundary |
| Protocol accounting | A balance-sheet model for one vault, lending market or exchange | Derive asset, liability, share and fee relationships with explicit units and rounding |
| Stateful research | Deterministic reproductions and a handler-based invariant suite | Reach meaningful sequences of operations without granting unrealistic powers |
| Bounty investigation | Deployment manifest, hypotheses, minimal fork PoC and impact calculation | Reproduce against the eligible version and satisfy the program’s reporting requirements |

This is a suggested competency sequence, not a promise that a particular number of weeks produces paid findings. Start with a compact protocol whose accounting you can explain completely before adding cross-chain messaging or consensus machinery.

## Scope and environment gate

Save the program page, excluded impacts, known issues, audit exclusions and PoC requirements. Record chain name **and chain ID**; proxy address; implementation, beacon or facet addresses where applicable; deployment transaction; repository commit; compiler and optimizer settings; dependencies; fork block number and block hash; roles; external oracle and token addresses. Distinguish currently deployed contracts from proposed upgrades, deprecated deployments and test fixtures. OpenZeppelin documents materially different proxy families and initialization requirements, so resolve the actual architecture instead of assuming every address is a simple implementation. [Proxy documentation](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

Check whether eligibility follows explicit asset/file rules or **primacy of impact**. On Immunefi, some programs allow eligible impacts on project-owned assets beyond the explicit list; that does not make all related organizations, test files or impacts eligible. Apply the exact program’s categories and limitations. [Example program explanation](https://immunefi.com/bug-bounty/immunefi/information/)

**Immunefi currently prohibits testing on mainnet and public testnet contracts.** Use a local fork; do not deploy an exploit or submit transactions to a live network. Its rules also prohibit unauthorized rescue of funds, incomplete required PoCs, and misleading asset or severity claims. A public testnet is therefore not a default alternative. For other programs, use a private development network or the expressly authorized environment. [Immunefi rules](https://immunefi.com/rules/)

Forking reads chain state through an RPC provider but executes the test locally. Keep production signing keys out of the research environment. Separate the read-only upstream RPC configuration from local transaction tooling. An ordinary RPC account and its quotas remain a separate service dependency. Pinning a block makes the result reproducible and prevents a moving head from silently changing the experiment. [Foundry fork testing](https://www.getfoundry.sh/guides/fork-testing)

## Operational playbook

**1. Reconstruct the economic model.** Write down who contributes value, who can withdraw it, who bears losses, and who changes parameters. Follow deposits through shares, debt, collateral, interest, rewards, liquidation and settlement. Mark units on every variable: raw token units, decimals, normalized values, seconds, basis points and shares. Build two ordinary users, a permissionless attacker and the actual administrative roles in the local model. Keep privileged setup separate from attacker actions.

**2. Identify invariants before choosing tools.** Examples are: one claim cannot settle twice; unauthorized users cannot change ownership; liabilities remain covered under documented assumptions; withdrawals burn the correct claim; an operation cannot create value merely through rounding; and a completed cross-chain transfer cannot execute again. These are candidate properties requiring adaptation, not universal formulas. For example, comparing vault assets directly to share supply is invalid when their units or exchange rate differ.

**3. Trace trust transitions.** Review user-to-router, router-to-pool, callback-to-caller, implementation-to-proxy, oracle-to-consumer and message-to-executor boundaries. Reentrancy can involve another function or another contract, rather than only recursion into one withdrawal. Establish what state is observable during external calls and whether a downstream component trusts an inconsistent intermediate value. [Solidity security considerations](https://docs.soliditylang.org/en/latest/security-considerations.html)

**4. Use static findings as hypotheses.** Build with the project’s compatible toolchain and inspect Slither output alongside inheritance, call relationships and deployment configuration. A detector match is not proof of reachable loss. Do not discard a dependency finding solely because it originates under `lib/`; first determine whether the affected behavior reaches an eligible asset. Conversely, a clean static scan does not validate the economics. [Slither usage](https://github.com/crytic/slither/wiki/Usage)

**5. Exercise sequences and adversarial actors locally.** Handlers should prepare valid balances, approvals and positions, then vary operation order and amounts. Inspect successful call counts and discarded inputs: an invariant suite that repeatedly reverts before changing state provides weak evidence. Keep a seed or minimized sequence, configuration and fork snapshot. Use ghost accounting independent of the implementation being tested. [Foundry invariant testing](https://getfoundry.sh/forge/invariant-testing?highlight=invariant)

**6. Minimize the proof and calculate bounded impact.** Show initial state, necessary preconditions, attacker actions, resulting victim/protocol loss and the failed property. Disclose flash liquidity, fees, slippage, collateral, timing and privileges. Do not claim total value locked as loss unless the demonstrated path reaches it. Local balance provisioning is a test convenience; minting arbitrary collateral, impersonating a privileged operator or forcing an impossible oracle state does not demonstrate that an ordinary attacker can do the same.

## Technical checklist

| Area | Investigation | Evidence that advances a report |
|---|---|---|
| Deployment identity | Correct chain, implementation and configuration at the pinned block | Address/commit manifest and the executed call path |
| Authorization | Initializers, role delegation, upgrade authority, emergency controls, arbitrary call permissions | An unprivileged actor crosses the documented permission boundary |
| Accounting | Deposits, redemptions, fees, debt indexes, rewards, donations, empty pools | Before/after balance sheet with explicit units and a violated relationship |
| Token behavior | Supported fee-on-transfer, rebasing, hooks, nonstandard returns and decimal variation | A supported integration produces incorrect accounting or authority |
| Oracle integration | Price denomination, freshness, decimals, failure modes and L2 downtime | Reachable accepted input causes an incorrect economic decision |
| Callbacks | Callback authentication, intermediate state, cross-function and cross-contract reentry | A local trace showing the unexpected state transition and impact |
| Signatures | Domain, signer, nonce, deadline, action binding, chain and verifying contract | A signature authorizes an unintended second action or context |
| Governance | Snapshot voting, quorum, proposal state, timelock, cancellation and execution | A locally demonstrated bypass of the actual governance guarantees |
| Bridges | Source authentication, destination binding, message uniqueness, ordering and finality | A local two-sided model with a duplicated or unauthorized state transition |
| Liveness | Unbounded processing, poisoned queues, dependency failure and recovery | A bounded local test proving eligible user funds or operations become stuck |
| Economic ordering | Slippage, deadlines, quote validity and attacker-controlled order | Loss exceeding intended, documented market behavior under feasible assumptions |
| Regression | Current implementation and known exclusions | Fresh reproduction and comparison with documented known issues |

Oracle checks must be feed-specific. Chainlink exposes answer metadata and timestamps; applications must interpret values and freshness correctly. On supported L2 integrations, evaluate sequencer availability and any required recovery grace period. A missing generic check is only a lead until its concrete consequence is established. [Data Feeds API](https://docs.chain.link/data-feeds/api-reference), [L2 sequencer feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds)

Vault rounding and donations deserve explicit boundary tests around zero supply, small deposits and conversions. OpenZeppelin’s ERC-4626 discussion illustrates why share arithmetic and inflation defenses require economic reasoning. Signature review likewise needs more than finding EIP-712: the standard itself does not supply replay protection. Inspect application nonces, consumption and action binding. [ERC-4626 security considerations](https://docs.openzeppelin.com/contracts/5.x/erc4626), [EIP-712](https://eips.ethereum.org/EIPS/eip-712)

Governance review must follow the configured module composition: voting and execution may be separated, and a timelock changes which contract executes the action. Bridges introduce additional assumptions about relayers, validators and cross-chain finality. Reproduce these assumptions explicitly rather than replacing their security checks with unconditional mocks. [OpenZeppelin governance](https://docs.openzeppelin.com/contracts/5.x/api/governance), [Ethereum bridges](https://ethereum.org/developers/docs/bridges/)

MEV describes value extracted through transaction inclusion or ordering, including arbitrage and sandwich behavior. Its existence is not automatically a bounty vulnerability. The report must identify an eligible broken guarantee, realistic capital and ordering assumptions, and the resulting harm; reproduce ordering locally. [Ethereum MEV](https://ethereum.org/developers/docs/mev/)

For non-EVM branches, retain the same scope and evidence model but replace the execution harness. Solana research needs account ownership, signer and writable privileges, PDA derivation and CPI boundaries; Sui/Move research needs module authority and object ownership; protocol/client research needs versioned consensus rules, serialization, state transitions and private multi-node reproductions. Treat these as separate specialization tracks, not as Solidity detector configurations. Select the chain’s official SDK and program-specific build requirements before testing. [Solana privileges](https://solana.com/docs/core/cpi/cpi-execution), [Sui Move concepts](https://docs.sui.io/develop/write-move/sui-move-concepts), [Ethereum client architecture](https://ethereum.org/developers/docs/nodes-and-clients/)

## Command cheat sheet

Run these from an isolated, reviewed local checkout with its required dependencies. `CHAIN_RPC_URL` is the permitted read-only state provider and `FORK_BLOCK` is a recorded decimal block number. Commands are examples of documented syntax, not a universal installer or completed PoC.

```bash
git rev-parse HEAD
forge --version
slither --version
forge build
slither . --json slither.json
forge test --match-test '^test_PoC$' \
  --fork-url "$CHAIN_RPC_URL" \
  --fork-block-number "$FORK_BLOCK" -vvvv
forge test --match-test '^invariant_' \
  --fork-url "$CHAIN_RPC_URL" \
  --fork-block-number "$FORK_BLOCK"
```

`test_PoC` and `invariant_*` are harness functions you implement; they are not built-in vulnerability checks. Preserve the harness, minimized inputs, dependency lock state and traces. Review untrusted build scripts before execution. [Foundry testing](https://www.getfoundry.sh/forge/testing), [Forge test reference](https://www.getfoundry.sh/reference/forge/test), [Slither usage](https://github.com/crytic/slither/wiki/Usage)

**Submission gate:** correct eligible deployment; realistic attacker; reproducible local fork; necessary privileges disclosed; precise impact category; bounded loss; known issues checked; private reporting channel used; no real funds moved. Read the current PoC requirements linked by the program before submitting; a toy reimplementation can explain the idea but does not establish deployed impact.

## Governance and non-EVM completion cases

Go beyond a list of keywords for the protocol features actually present. For governance, record proposal identity, voting snapshot, quorum, queue time and execution authority. In a local fixture compare legitimate propose → vote → queue → execute with early execution, cancelled execution and a repeated execution. Check the actual composed modules: an intentionally permissionless timelock executor is different from bypassing its scheduled operation. Preserve roles and a harmless local target event. [OpenZeppelin governance](https://docs.openzeppelin.com/contracts/5.x/api/governance).

For a supported contract-wallet signer, compare ERC-1271's successful return with a different value and a reverting wallet, then test any state-dependent revocation contract. A non-reverting call is not sufficient signature validation. The expanded procedure is in [contract signatures and oracles](#page-modules-contract-signatures-oracles). [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271).

For non-EVM deployments, make an explicit applicability ledger: signer/owner/writable/PDA/CPI cases for Solana; object ownership, shared-object transitions and capability authority for Move; serialization/state-transition/finality cases for clients and bridges. Mark an unavailable compatible harness as **not tested** rather than inheriting EVM coverage. A genuine bridge proof needs both sides' authentication and replay rules preserved; replacing verification with an unconditional mock only demonstrates the toy model.

- [ ] Governance transitions include early, cancelled and repeated execution controls.
- [ ] Contract-wallet acceptance checks its actual return semantics.
- [ ] Chain-specific unsupported surfaces are visible as coverage limitations.

## Sources

All sources accessed 2026-09-11. Documentation pages are undated unless noted; versioned documentation must be matched to the target’s actual dependency version.

1. Immunefi. [Rules](https://immunefi.com/rules/). Undated, current rules.
2. Immunefi. [Immunefi Bug Bounty: Information](https://immunefi.com/bug-bounty/immunefi/information/). Undated, current program example.
3. Foundry. [Fork Testing](https://www.getfoundry.sh/guides/fork-testing). Undated; search index displays 2026-08-28.
4. Foundry. [Testing](https://www.getfoundry.sh/forge/testing). Undated; search index displays 2026-07-09.
5. Foundry. [forge test](https://www.getfoundry.sh/reference/forge/test). Undated CLI reference.
6. Foundry. [Invariant Testing](https://getfoundry.sh/forge/invariant-testing?highlight=invariant). Undated.
7. Trail of Bits / Crytic. [Slither Usage](https://github.com/crytic/slither/wiki/Usage). Edited 2024-07-23.
8. OpenZeppelin. [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy). Contracts 5.x; undated.
9. Solidity. [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html). Rolling development documentation; undated.
10. Chainlink. [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference). Undated.
11. Chainlink. [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds). Undated.
12. OpenZeppelin. [ERC-4626](https://docs.openzeppelin.com/contracts/5.x/erc4626). Contracts 5.x; undated.
13. Ethereum Improvement Proposals. [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712). Created 2017-09-12.
14. OpenZeppelin. [Governance](https://docs.openzeppelin.com/contracts/5.x/api/governance). Contracts 5.x; undated.
15. Ethereum.org. [Bridges](https://ethereum.org/developers/docs/bridges/). Undated.
16. Ethereum.org. [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/). Undated.
17. Solana. [CPI Execution and Privileges](https://solana.com/docs/core/cpi/cpi-execution). Undated.
18. Sui. [Move Concepts](https://docs.sui.io/develop/write-move/sui-move-concepts). Undated.
19. Ethereum.org. [Nodes and Clients](https://ethereum.org/developers/docs/nodes-and-clients/). Undated.


## Shared investigation procedures

- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.
- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.

## Vulnerability reference

- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition)
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass)
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay)
- [Contract callback reentrancy violates a state invariant](#page-vulnerabilities-contract-reentrant-state)
- [Contract initializer permits unauthorized ownership or configuration](#page-vulnerabilities-contract-unprotected-initializer)
- [Contract upgrade authority can be bypassed](#page-vulnerabilities-contract-upgrade-authorization)
- [Vault share conversion or rounding breaks entitlement](#page-vulnerabilities-contract-share-accounting)
- [Signed contract action can be replayed unexpectedly](#page-vulnerabilities-contract-signature-replay)
- [Signed action does not bind its intended context](#page-vulnerabilities-contract-signature-context)
- [Oracle freshness or dependency state permits an invalid decision](#page-vulnerabilities-contract-stale-oracle)
- [Oracle denomination or decimal conversion is incorrect](#page-vulnerabilities-contract-oracle-unit-confusion)


---

<a id="page-hardware"></a>

# Hardware, IoT, firmware and embedded systems

Treat hardware research as a **versioned product and attacker-access investigation**. A firmware image, a physical device, its radio interface and its cloud service can have different owners and different bounty eligibility. A weakness visible after dismantling a device may fall outside a program that only accepts remote or closed-chassis attacks.

## Roadmap and entry criteria

| Stage | Work product | Exit criterion |
|---|---|---|
| Firmware literacy | Architecture map, image inventory and recovered filesystem where present | Explain boot, update, persistence and service startup without executing unknown binaries on the workstation |
| Device observation | Own-device baseline, controlled network capture and interface inventory | Distinguish provisioning, normal operation and recovery behavior |
| Boundary research | One reachable parser, authorization or update-trust hypothesis | Demonstrate a security consequence in a recoverable local setup |
| Specialist research | Versioned hardware/firmware findings with reproducible evidence | Match the program’s physical-access model and show affected production configuration |

Build confidence using intentionally vulnerable images or owned development hardware before using expensive production equipment. Buying a device is not itself evidence that its vendor rewards firmware findings or permits testing related infrastructure. Intel’s current program illustrates the distinction: it explicitly excludes open-chassis physical attacks from bounty rewards. [Intel program terms](https://app.intigriti.com/programs/intel/intel/detail)

## Scope and laboratory gate

Create a target card with vendor, exact product/SKU, board revision, SoC revision, bootloader, firmware version and image hash, region/carrier variant, enabled features, lifecycle state and acquisition source. Record whether the device is retail, engineering/debug, previously rooted or already modified. Compare results with an unmodified baseline; a debug unit cannot establish behavior on locked retail hardware.

Document the required access: remote internet, same network/proximity, physical access without opening, or access to internal components. Record digital privileges independently: unauthenticated, ordinary user, administrator or manufacturer. OWASP ISTG distinguishes physical and authorization access, including non-invasive and invasive access. These distinctions determine applicable tests and prevent overstating a bench-only result as a remote vulnerability. [ISTG attacker model](https://github.com/OWASP/owasp-istg/blob/main/src/02_framework/attacker_model.md)

Use a segregated lab network with synthetic accounts and no route to ordinary home/work devices. Observe expected destinations before selectively allowing connectivity. Keep a power and recovery plan, original firmware, configuration backup and known-good device state. A local firmware emulator still needs containment: embedded startup scripts can contact vendor services or alter the host environment if executed carelessly. Treat extraction tools and package parsers as attack surfaces too.

For UART/JTAG and other probes, establish pinout, voltage levels, ground reference and power ownership from reliable device documentation and measurement. Begin with passive observation. Do not make fuse changes, overwrite bootloaders, desolder components, glitch power or permanently unlock production hardware as a generic first step. Such operations require an explicitly suitable device, recovery capability and scope; their omission should be recorded as a test limitation.

## Operational playbook

**1. Acquire authentic inputs.** Prefer vendor downloads, authorized source releases, program-provided images or read-only acquisition from owned in-scope devices. Preserve the original bytes and hash before unpacking. Record how the image relates to the installed version; a downloaded update container may omit the bootloader, calibration data or secrets stored on the device. Do not assume an image found on an unrelated sharing service is authentic or covered.

**2. Inventory the image and startup paths.** Identify format, compression, partitions, architecture, endianness, executable ABI, filesystem and init mechanism. Bare-metal or RTOS images may not contain a Linux filesystem at all. Map network listeners, CGI/web handlers, configuration import/export, update agents, privileged helpers and inter-process messaging. Firmware methodology separates acquisition, unpacking, static review and dynamic validation; extraction alone is not an audit result. [OWASP FSTM](https://github.com/scriptingxss/owasp-fstm)

**3. Establish the normal trust model.** Trace provisioning to first ownership, adding a second user, local/cloud control, account removal, ownership transfer and reset. Mark which operations require physical presence and which are authenticated remotely. Build at least two owned test identities where the product supports them. A report about cross-owner access should demonstrate a boundary using those identities rather than a third party’s device.

**4. Follow external input into privileged behavior.** Prioritize reachable parsers: HTTP, binary control messages, configuration archives, media/file imports and update metadata. Map decoding, length checks, integer arithmetic and privilege changes. For native code, distinguish a controlled parser crash, memory corruption and demonstrated execution; they have different evidentiary strength. A missing stack canary or an outdated library version is a lead until reachability and applicable impact are shown.

**5. Validate with the least invasive faithful environment.** Extracted-process emulation can isolate a parser; full-system emulation can recover service interactions; the owned device confirms hardware-dependent behavior. Record divergences such as mocked peripherals, absent secure elements or different kernel versions. Use bounded inputs and synthetic data. Stop at a reproducible boundary violation rather than escalating to persistence, uncontrolled radio traffic or damage.

**6. Reproduce after reset and prepare disclosure.** Verify the issue survives a clean supported configuration, document exact preconditions, and capture evidence of the protected action or data access. Preserve recovery steps and device health. Report confirmed versions separately from suspected related products; matching strings or reused libraries do not prove a shared exploitable condition.

## Technical investigation checklist

| Area | Investigation | Evidence that advances a report |
|---|---|---|
| Firmware identity | Model, revision, update package, installed build, hashes | Exact affected product and reproducible baseline |
| Provisioning | Initial ownership, pairing, reset, reassignment and local presence | An unauthorized identity obtains a protected role or capability |
| Update trust | Signature verification, trusted keys, authenticated metadata, target compatibility | A harmless unauthorized artifact crosses the actual acceptance boundary |
| Rollback | Version counters, signed old images and recovery paths | An allowed attacker can restore a vulnerable security state |
| Boot chain | ROM-to-bootloader-to-application verification and recovery trust | A gap in the claimed chain under the eligible access model |
| Secrets | Per-device versus shared keys, credentials, debug logs and persistent storage | Protected capability established without publishing usable secrets |
| Debug interfaces | UART console, JTAG/SWD, test modes and privilege separation | Unexpected access on the production configuration |
| Local services | Authentication, authorization, command construction and configuration import | Reachable low-privilege input causes a protected operation |
| Memory safety | Length fields, parsers, allocation/free patterns and signedness | Minimized input, crash location, reachability and bounded consequence |
| Wireless | Pairing/bonding, identity, replay, sequencing and encrypted transport | Own-device controlled capture shows an authentication or integrity failure |
| Cloud/app coupling | Device claims, token scoping, ownership transfer and command routing | Reproduction only against separately authorized API/app assets |
| Recovery | Reboot, factory reset, watchdog and supported restore procedures | Device restored and test limitations documented |

Update transport encryption, update authentication and secure boot are separate checks. HTTPS can protect download transport while leaving a local update path insufficiently authenticated. A signed image may still be unsuitable for the model or permit a security downgrade. Examine what bytes and metadata are verified and what executes afterward. [ISTG firmware update mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)

Vendor details matter. On ESP32, Secure Boot v2 support depends on chip revision, and Espressif documents interactions with JTAG and flash encryption. Its security guidance separately describes anti-rollback controls. Do not infer the presence or absence of a production control from a generic SoC feature list; inspect the target configuration and matching vendor documentation. [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html), [Security overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html)

Classify discovered secrets before testing them: public certificate, local password hash, per-device private key, shared fleet credential or build-time sample. Demonstrating a secret’s role on an owned lab device is stronger than indiscriminate credential trials against cloud endpoints. For storage, distinguish attacker-accessible contents from intended administrator/debug access; note encryption-key placement, deletion behavior and residual data after reset. [ISTG installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md), [ISTG memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md)

Internal interfaces deserve their own boundary assessment. A UART that prints boot diagnostics differs from an unauthenticated privileged console; accessible JTAG differs from a demonstrated ability to extract protected secrets. Record physical effort and whether opening the case is required. Radio observations likewise differ from active tests: perform replay or malformed-message experiments only between owned devices in a controlled setup, and evaluate pairing and message authentication in the relevant protocol. [ISTG internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md), [ISTG wireless interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md)

## Command cheat sheet

Use an offline copy of a vendor image in an isolated non-root analysis environment. These commands inspect local files; they do not acquire firmware from an unknown device or authorize testing any embedded endpoint.

```bash
mkdir -p evidence
sha256sum firmware.bin > evidence/firmware.sha256
file firmware.bin > evidence/firmware-type.txt
binwalk firmware.bin > evidence/firmware-layout.txt
strings -a -n 8 firmware.bin > evidence/firmware-strings.txt

# After an appropriate extractor has produced an owned local filesystem:
rg --files extracted-rootfs > evidence/file-inventory.txt
rg -n -i 'password|token|private.key|update|signature' \
  extracted-rootfs > evidence/review-leads.txt

# For an identified ELF binary, not for every firmware format:
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
```

Select the extractor for the detected format, verify its current syntax and inspect archive contents before extraction. Keep unknown images away from host mounts and privileged analysis processes. Binwalk identifies embedded content and can support extraction workflows; high entropy alone does not distinguish encryption from compression. The `rg` matches above are review leads, not confirmed credentials or findings. [Binwalk](https://github.com/ReFirmLabs/binwalk), [OWASP FSTM](https://github.com/scriptingxss/owasp-fstm)

**Evidence bundle:** product/revision photo with unnecessary identifiers redacted; firmware and extracted-file hashes; access model; wiring/interface notes where applicable; synthetic account roles; minimal input; serial or packet logs; observed versus expected behavior; reproducibility count; device recovery status; and exact affected versions. Include proof that emulation assumptions also hold on the claimed product, or clearly limit the claim to the emulated component.

## Specialist boundaries

Vehicles, industrial equipment, medical devices, energy systems and safety-related controls require a dedicated bench or simulator, disconnected actuators and a product-specific safety plan. Do not run generic active probes on deployed equipment or moving vehicles. Fault injection, invasive chip extraction, RF transmission and physical access are separate research capabilities with separate permissions and operational requirements. Tesla’s product-security page and each vendor’s actual program terms should be checked before planning vehicle work; device ownership alone does not settle every condition. [Tesla product security](https://www.tesla.com/legal/security)

**Submission gate:** eligible model and access level; supported configuration; a demonstrated security boundary; secrets minimized; no unrelated cloud assets tested; no physical damage required for the proof; clean reproduction; limitations explicit. Prefer one reproducible issue with measured impact over a long inventory of absent hardening flags.

## Sources

All sources accessed 2026-09-11. Undated pages are live references. OWASP citations point to the guide’s official maintained source files.

1. Intel / Intigriti. [Intel Bug Bounty Program](https://app.intigriti.com/programs/intel/intel/detail). Undated, current program terms.
2. OWASP. [ISTG: Attacker Model](https://github.com/OWASP/owasp-istg/blob/main/src/02_framework/attacker_model.md). Undated.
3. OWASP / Aaron Guzman. [Firmware Security Testing Methodology](https://github.com/scriptingxss/owasp-fstm). Undated, maintained repository.
4. OWASP. [ISTG: Firmware Update Mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md). Undated.
5. Espressif. [Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html). ESP-IDF stable, ESP32; undated.
6. Espressif. [Security Overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html). ESP-IDF stable, ESP32; undated.
7. OWASP. [ISTG: Installed Firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md). Undated.
8. OWASP. [ISTG: Memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md). Undated.
9. OWASP. [ISTG: Internal Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md). Undated.
10. OWASP. [ISTG: Wireless Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md). Undated.
11. ReFirm Labs. [Binwalk](https://github.com/ReFirmLabs/binwalk). Undated, maintained repository.
12. Tesla. [Product Security](https://www.tesla.com/legal/security). Undated, current policy.


## Shared investigation procedures

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.
- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

## Vulnerability reference

- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read)
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write)
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free)
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow)
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files)
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path)
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact)
- [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation)
- [Firmware security-version state can be lowered](#page-vulnerabilities-firmware-security-version-rollback)
- [Firmware verification fails to enforce required product binding](#page-vulnerabilities-firmware-product-binding)
- [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap)
- [Production UART exposes an unauthenticated privileged console](#page-vulnerabilities-hardware-unauthenticated-console)
- [On-chip debug interface exposes protected memory or control](#page-vulnerabilities-hardware-debug-authorization)
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials)
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing)


---

<a id="page-modules"></a>

# Reusable test modules

Each canonical procedure combines setup, workflow, commands, controls, evidence and completion checks.

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai).
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud).
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) · [Desktop & extensions](#page-desktop).
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai).
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud).
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3).
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network).
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe. Used in: [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai).
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant. Used in: [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai).
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain. Used in: [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai).
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact. Used in: [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports. Used in: [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai).
- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation. Used in: [Cloud & containers](#page-cloud).
- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects. Used in: [Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss).
- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers. Used in: [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss).
- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts. Used in: [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss).
- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests. Used in: [Network services](#page-network) · [Cloud & containers](#page-cloud).
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities. Used in: [Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss).
- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation. Used in: [Mobile](#page-mobile).
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use. Used in: [Mobile](#page-mobile).
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers. Used in: [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop).
- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller. Used in: [Desktop & extensions](#page-desktop).
- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions. Used in: [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile).
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary. Used in: [AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss).
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes. Used in: [AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss).
- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting. Used in: [Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss).
- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls. Used in: [Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss).
- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts. Used in: [Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss).
- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit. Used in: [Hardware & firmware](#page-hardware) · [Network services](#page-network).
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud).
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures. Used in: [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud).
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs. Used in: [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api).
- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts. Used in: [Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss).
- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time. Used in: [AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss).
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects. Used in: [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai).


---

<a id="page-vulnerabilities"></a>

# Vulnerability catalog

140 curated families. This is an extensible index, not an exhaustive list of every possible flaw. Candidate CWE references require root-cause evidence; ATT&CK associations require the stated behavior.

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access) — CWE-639. An actor can access another owner’s protected object by supplying its identifier.
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function) — CWE-862, CWE-863. A lower-privilege actor invokes a function reserved for another role.
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property) — CWE-862, CWE-863. An otherwise permitted object response includes fields the actor is not entitled to read.
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property) — CWE-915. Automatic request binding lets a user modify a property that should be set only by trusted server logic.
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass) — CWE-287. A session that has not completed required authentication can perform protected operations.
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding) — CWE-384. A session known to an attacker remains usable after another controlled user authenticates into it.
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access) — CWE-613. A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding) — CWE-640. Recovery proof can change the wrong account or be reused contrary to the recovery contract.
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion) — CWE-287, CWE-352. An authorization response or external identity is bound to the wrong application session or controlled account.
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure) — CWE-347, CWE-287. A service accepts token claims without the required signature or trusted issuer/key validation.
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection) — CWE-89. Input changes SQL query structure instead of remaining a bound value.
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass) — CWE-943. An unexpected object, operator, or expression crosses a NoSQL query boundary.
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary) — CWE-78. An untrusted parameter becomes shell command syntax rather than remaining a data argument.
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection) — CWE-1336. Lower-trust data becomes executable template source at a server-side renderer.
- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution) — CWE-79. Attacker-controlled input executes in another controlled user’s browser under the application origin.
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow) — CWE-79. Browser-side code moves attacker-controlled data into an executable DOM or script sink.
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change) — CWE-352. A browser can be induced to perform a protected state change using ambient credentials.
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read) — CWE-942. A lower-trust origin can read a protected response using the controlled user’s browser credentials.
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation) — CWE-346. A message handler trusts an unauthorized sender or leaks protected data to an unintended origin.
- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination) — CWE-918. A server-side fetch crosses the feature’s destination, network, or credential policy.
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation) — CWE-434. Uploaded content is handled in a security-sensitive context beyond its permitted file contract.
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary) — CWE-22. A controlled path escapes the intended filesystem or object-key boundary.
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution) — CWE-611. An XML parser resolves untrusted external entities across an unintended file or network boundary.
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape) — CWE-22. An archive member is extracted outside its designated output directory.
- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input) — CWE-349. Unkeyed attacker-controlled input changes a representation later served from shared cache.
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response) — CWE-524. A path/cache-policy discrepancy stores a private response for retrieval by another client.
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization) — CWE-444. Two HTTP-processing components disagree about request boundaries or parsing.
- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition) — CWE-362. Concurrent operations violate a rule that holds when the same actions run serially.
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass) — CWE-841. An actor can complete a protected workflow without its required prior approval or immutable conditions.
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay) — CWE-837. A replay creates another protected effect where the operation must be unique or idempotent.
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz) — CWE-863. A GraphQL path or protected field bypasses the permission enforced for the same object elsewhere.
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization) — CWE-862. A valid connection performs unauthorized per-message actions or receives a private subscription.
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking) — CWE-346, CWE-352. A page on another origin opens an authenticated socket and reads or performs protected operations.
- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials) — CWE-798. A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.
- [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection) — CWE-94. Pull-request titles, branch metadata, issue fields, or artifact values are inserted into a generated shell/program instead of being handled as data.
- [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution) — CWE-829. A trusted workflow fetches or loads contribution-controlled code, configuration, or dependencies and executes them with authority unavailable to the contributor.
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning) — CWE-829. A higher-trust workflow treats attacker-controlled test/build output as executable code or authoritative release input without adequate producer and content constraints.
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion) — CWE-829. Dependency resolution selects an attacker-controlled package origin where the build or application expects an organization-controlled package.
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization) — CWE-502. Untrusted bytes reach a format that can instantiate behavior-bearing objects or invoke code, such as Python pickle, without a sufficient trust boundary.
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution) — CWE-1321. An attacker-controlled property path changes inherited object state, which can affect unrelated objects and security-sensitive consumers.
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read) — CWE-125. A parser or native consumer reads outside the valid extent of an object or buffer, potentially causing a crash or disclosure depending on how the result is used.
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write) — CWE-787. A native component writes beyond an allocated object because length, index, or allocation assumptions do not agree.
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free) — CWE-416. Code uses an object after its lifetime has ended, often across callbacks, error handling, reference counting, or asynchronous operations.
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow) — CWE-190. Input-derived arithmetic wraps or overflows so the checked size, allocation size, and later operation refer to different effective values.
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion) — CWE-400. A small accepted input causes disproportionate CPU, memory, recursion, or expanded output consumption without effective limits at the relevant consumer.
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos) — CWE-1333. An attacker-controlled string makes the chosen regular-expression engine perform excessive backtracking or other disproportionate matching work.
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files) — CWE-377. A component creates or reuses temporary files in a way that permits another local principal to precreate, replace, read, or redirect sensitive operations.
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path) — CWE-427. A program resolves an executable/library/module from an attacker-writable search location instead of the intended trusted component.
- [Overbroad cloud role trust](#page-vulnerabilities-cloud-iam-role-trust) — CWE-863. A principal outside the integration's intended trust set can obtain an owned role's authority.
- [Excessive service-role delegation](#page-vulnerabilities-cloud-passrole-escalation) — CWE-266. A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.
- [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope) — CWE-863. OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.
- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read) — CWE-732. An unsigned request retrieves an object that the product promises to keep private.
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write) — CWE-732. An unauthorized principal can create or replace an object in a protected storage location.
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope) — CWE-863. The application issues or accepts a storage capability for an object, operation or lifetime beyond the caller's entitlement.
- [Private delivery policy bypassed through the origin](#page-vulnerabilities-cloud-origin-access-bypass) — CWE-862. A private object is protected at the CDN or application edge but remains accessible directly at an owned origin.
- [Kubernetes Secret access exceeds tenant permissions](#page-vulnerabilities-kube-secret-rbac-exposure) — CWE-732. A restricted cluster principal can read a canary Secret outside its intended resource boundary.
- [Workload creation grants unintended service-account authority](#page-vulnerabilities-kube-workload-identity-selection) — CWE-266. An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.
- [Admission policy misses a supported object or update path](#page-vulnerabilities-kube-admission-policy-gap) — CWE-863. A tenant can persist an object prohibited by the advertised admission policy through a missed operation, selector or subresource.
- [Namespace or workload network restriction is ineffective](#page-vulnerabilities-kube-network-isolation-failure) — CWE-923. A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.
- [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure) — CWE-250. A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.
- [Sensitive values exposed through state or plan artifacts](#page-vulnerabilities-iac-state-secret-exposure) — CWE-522. A deployment artifact readable by an unintended principal contains credentials or equivalent confidential material.
- [Secrets retained in container build artifacts](#page-vulnerabilities-container-build-secret-leak) — CWE-522. A build places confidential inputs in image history, layers or artifacts available outside their intended audience.
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default) — CWE-276. A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.
- [Dangling DNS reference to a retired service](#page-vulnerabilities-dns-dangling-resource-reference) — CWE-672. An owned hostname still points to a released provider resource, creating a possible takeover path if provider binding rules permit it.
- [Restricted DNS zone transferable from an unintended source](#page-vulnerabilities-dns-unrestricted-zone-transfer) — CWE-732. An unauthorized source can retrieve an entire zone that the owner intends to restrict.
- [DNS recursion available outside the intended client network](#page-vulnerabilities-dns-unrestricted-recursion) — CWE-862, CWE-863. A resolver performs recursive lookups for a client excluded by its intended access policy.
- [SMTP relay allows unauthenticated external delivery](#page-vulnerabilities-smtp-unintended-open-relay) — CWE-441. An untrusted unauthenticated client can relay between external domains contrary to the server's relay policy.
- [Redis authentication or key ACL boundary failure](#page-vulnerabilities-redis-canary-access) — CWE-862, CWE-863. An anonymous or restricted client can read a key outside the service's intended access policy.
- [PostgreSQL trust authentication exceeds the approved network boundary](#page-vulnerabilities-postgres-unintended-trust-auth) — CWE-306. An unintended source can connect as a protected database identity without the required authentication because an effective trust rule applies.
- [Message broker permissions cross a virtual-host boundary](#page-vulnerabilities-queue-virtual-host-boundary) — CWE-863. A restricted broker identity can act on a queue or exchange belonging to a different isolated fixture tenant.
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth) — CWE-306. An untrusted network client reaches protected container-management functionality without the required identity checks.
- [Exported Android component exposes a protected operation](#page-vulnerabilities-android-exported-operation) — CWE-926. An externally reachable activity, service or receiver performs work that its caller is not entitled to request.
- [Content-provider permission or URI-grant escape](#page-vulnerabilities-android-provider-grant) — CWE-926, CWE-863. A recipient obtains data or file capabilities beyond the URI and permissions deliberately shared with it.
- [Nested intent redirects application authority](#page-vulnerabilities-android-intent-redirection) — CWE-441. An exported entry point forwards attacker-supplied intent fields into a protected destination using the target application’s authority.
- [PendingIntent grants unintended mutable or replayable authority](#page-vulnerabilities-android-pendingintent-delegation) — CWE-863. A recipient can alter or reuse a delegated action beyond its intended destination, parameters or lifetime.
- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler) — CWE-939, CWE-863. An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
- [Untrusted WebView content reaches a native bridge](#page-vulnerabilities-mobile-webview-native-bridge) — CWE-749. A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.
- [Keychain accessibility violates the intended lock boundary](#page-vulnerabilities-ios-keychain-access-policy) — CWE-922. A sensitive item or protected key operation is available in a device state that the application’s security policy requires it to deny.
- [Extension input crosses an iOS shared-container boundary](#page-vulnerabilities-ios-shared-container-trust) — CWE-863. The main application trusts content written through a lower-trust extension/input path as if it were an authorized app action.
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate) — CWE-288. A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
- [Backup or transfer exposes unintended sensitive client state](#page-vulnerabilities-client-backup-sensitive-state) — CWE-530, CWE-922. A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.
- [Sensitive client state leaks through accessible diagnostics](#page-vulnerabilities-client-secret-logging) — CWE-532. Logs, crash reports or user-exportable diagnostics disclose a secret or private record to a principal outside its intended audience.
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate) — CWE-295, CWE-297. Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.
- [Electron IPC exposes main-process authority to an untrusted sender](#page-vulnerabilities-electron-ipc-confused-deputy) — CWE-749, CWE-863. An attacker-controlled renderer or frame invokes a privileged main-process operation through insufficient sender or argument validation.
- [Desktop protocol handler misinterprets external input](#page-vulnerabilities-desktop-protocol-confusion) — CWE-88. An OS-dispatched URL reaches a native command or operation with attacker-controlled arguments outside the intended handler contract.
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact) — CWE-494, CWE-347. The real update decision accepts modified bytes or an unrelated publisher identity before activation.
- [Privileged updater consumes lower-user-controlled staging content](#page-vulnerabilities-updater-privileged-staging) — CWE-732, CWE-367. A standard user can replace a staged file or redirect a path actually consumed by a privileged installation process.
- [Attacker-controlled rollback restores a prohibited security state](#page-vulnerabilities-update-security-rollback) — CWE-863. An attacker bypasses an update version authorization policy to cause a rollback that restores a prohibited security state.
- [Indirect prompt injection into protected tool actions](#page-vulnerabilities-indirect-prompt-tool-injection) — CWE-1427. Lower-trust retrieved content influences the agent into a tool operation outside the legitimate task or granted authority.
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization) — CWE-863. A tool trusts caller-supplied object or workspace identifiers instead of enforcing the authenticated principal’s authority.
- [Agent approval is not bound to executed arguments](#page-vulnerabilities-agent-approval-argument-drift) — CWE-367. An approved harmless action can be modified before dispatch without revalidating the approval’s scope.
- [MCP proxy consent confuses different clients](#page-vulnerabilities-mcp-proxy-confused-deputy) — CWE-441. A proxy reuses upstream consent in a way that grants a new MCP client access without the resource owner’s intended per-client consent.
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion) — CWE-287. A protected MCP resource accepts a token that was not issued for that resource.
- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval) — CWE-863. Search filters, chunk retrieval or citation download omit an ownership decision required for the effective caller.
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak) — CWE-863. A new retrieval or cache response exposes protected content after its applicable permission revocation has taken effect.
- [Contract callback reentrancy violates a state invariant](#page-vulnerabilities-contract-reentrant-state) — CWE-1265. Nested calls observe or alter state under assumptions that do not hold while an earlier operation is incomplete.
- [Contract initializer permits unauthorized ownership or configuration](#page-vulnerabilities-contract-unprotected-initializer) — CWE-862. A reachable initialization path lets an ordinary actor establish or replace privileged state outside the intended deployment lifecycle.
- [Contract upgrade authority can be bypassed](#page-vulnerabilities-contract-upgrade-authorization) — CWE-862. An actor outside the upgrade policy can change a proxy’s execution target or equivalent privileged configuration.
- [Vault share conversion or rounding breaks entitlement](#page-vulnerabilities-contract-share-accounting) — CWE-682. Conversions, fees or rounding create an unintended claim on assets or an eligible loss under supported token behavior.
- [Signed contract action can be replayed unexpectedly](#page-vulnerabilities-contract-signature-replay) — CWE-294. A successfully consumed authorization remains reusable despite a one-use or otherwise bounded execution contract.
- [Signed action does not bind its intended context](#page-vulnerabilities-contract-signature-context) — CWE-345. A valid signature is accepted for another recipient, action, verifier or chain context contrary to the authorization contract.
- [Oracle freshness or dependency state permits an invalid decision](#page-vulnerabilities-contract-stale-oracle) — CWE-754. A consumer accepts an observation outside its required freshness or availability conditions and makes an incorrect economic decision.
- [Oracle denomination or decimal conversion is incorrect](#page-vulnerabilities-contract-oracle-unit-confusion) — CWE-682. The consumer mixes quote currencies, token precision or feed precision and assigns the wrong economic value.
- [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation) — CWE-347. The relevant update acceptance path fails to authenticate executable payload or security-relevant metadata correctly.
- [Firmware security-version state can be lowered](#page-vulnerabilities-firmware-security-version-rollback) — CWE-1328. An attacker can reduce the protected security version and thereby restore software excluded by the anti-rollback policy.
- [Firmware verification fails to enforce required product binding](#page-vulnerabilities-firmware-product-binding) — CWE-20. An otherwise authentic image is accepted for an incompatible product or security configuration despite required target restrictions.
- [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap) — CWE-345. A reachable boot path omits an authenticity check required by the product’s execution trust model.
- [Production UART exposes an unauthenticated privileged console](#page-vulnerabilities-hardware-unauthenticated-console) — CWE-306. The in-scope physical access model yields a protected console capability without required authentication.
- [On-chip debug interface exposes protected memory or control](#page-vulnerabilities-hardware-debug-authorization) — CWE-1191. A production debug/test interface permits a protected capability beyond the documented physical-access authorization.
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials) — CWE-798. An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret) — CWE-540. Source, history, or a published artifact exposes a credential outside its intended audience.
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust) — CWE-601. Attacker input controls a navigation destination that the application treats as trusted.
- [Clickjacking of a sensitive authenticated action](#page-vulnerabilities-clickjacking-sensitive-action) — CWE-1021. An untrusted origin can frame and visually disguise an authenticated operation.
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust) — CWE-346. The application constructs a security-sensitive origin from request metadata that an attacker can influence.
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure) — CWE-209. An error or debug output crosses a confidentiality boundary by revealing protected state.
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness) — CWE-338. A security token relies on randomness that does not meet its unpredictability requirement.
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash) — CWE-916. A password verifier has insufficient computational cost for its supported threat model.
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing) — CWE-353. A protected data format permits security-relevant changes that are not detected before use.
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust) — CWE-347, CWE-287. The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass) — CWE-287. A lower-assurance or wrong-account context can add, replace, or remove an authentication factor contrary to its management policy.
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure) — CWE-287, CWE-347. The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion) — CWE-287. Registration, verification, email change, or federation merging transfers trust to an identity while retaining an unintended actor's usable credentials or session.
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass) — CWE-288. A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection) — CWE-88. A value-only input changes options or mode of the intended executable, even when no shell is used.
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict) — CWE-436. Validation or authorization uses one interpretation of a request value while the protected operation uses another.
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection) — CWE-235. An outer input injects or alters parameters in a server-created downstream request.
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure) — CWE-345. An event is processed with privileged consequences without establishing the required sender and content authenticity.
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding) — CWE-863. A valid provider event is misbound to a local tenant, installation, mode or resource the event is not authorized to modify.
- [GitLab job token crosses an unintended project boundary](#page-vulnerabilities-gitlab-job-token-boundary) — CWE-863. A contribution-controlled job acquires access to a private receiving-project resource beyond the CI integration contract.
- [Shared CI runner exposes private state across jobs](#page-vulnerabilities-ci-runner-cross-job-state) — CWE-668. A job reaches a previous job's private filesystem or image material despite the runner's promised isolation.
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority) — CWE-441, CWE-863. An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.
- [Delayed extension result reaches a different document](#page-vulnerabilities-extension-document-reply-confusion) — CWE-367, CWE-863. An asynchronous extension operation reuses stale tab/frame authority after navigation and exposes a protected result to another document.
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership) — CWE-863. Persisted agent state or its resume/export path is accessible or mutable by a principal outside its intended owner or sharing grant.
- [MCP resumed state changes authorization or request meaning](#page-vulnerabilities-mcp-resume-state-integrity) — CWE-345, CWE-863. An MRTR server trusts modified or context-mismatched requestState when it affects a protected resumed operation.
- [Private MCP result is reused across authorization contexts](#page-vulnerabilities-mcp-private-cache-context) — CWE-524, CWE-863. A shared cache delivers caller-specific protocol data outside the authorization context that produced it.
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect) — CWE-841. A response-loss or resume path duplicates an operation whose application contract requires at-most-once effect.
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure) — . A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading) — CWE-502, CWE-829. An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure) — CWE-770. An operation consumes an unconstrained protected resource through input size, fan-out, queued work, output size or retries.
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit) — CWE-799. An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.


---

<a id="page-commands"></a>

# Command workbench

Every command appears with its setup, controls and checklist in the canonical procedures below. The website and separate workbench download also provide the collected snippets.

- [Object, function, and property authorization](#page-modules-authz-matrix)
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session)
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing)
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary)
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust)
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries)
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic)
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols)
- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache)
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction)
- [Source review: entry point to protected operation](#page-modules-source-dataflow)
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci)
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability)
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing)
- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries)
- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery)
- [Container and Kubernetes isolation](#page-modules-container-kubernetes)
- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config)
- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail)
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries)
- [Android components, intents and deep links](#page-modules-android-components)
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries)
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport)
- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc)
- [Update signatures, rollback and privileged installation](#page-modules-update-integrity)
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust)
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation)
- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state)
- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles)
- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update)
- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces)
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle)
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust)
- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing)
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity)
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries)
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries)
- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries)
- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle)
- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls)

---

<a id="page-coverage"></a>

# Coverage and reuse map

Documentation coverage, not vulnerability prevalence or completed target testing. Entries may apply to several families.

| Target family | Procedures | Vulnerability families |
| --- | ---: | ---: |
| [OSS & self-hosted](#page-oss) | 32 | 113 |
| [Web & API](#page-web-api) | 22 | 69 |
| [Network services](#page-network) | 5 | 20 |
| [Mobile](#page-mobile) | 17 | 60 |
| [Desktop & extensions](#page-desktop) | 19 | 63 |
| [Cloud & containers](#page-cloud) | 23 | 60 |
| [AI, agents & MCP](#page-ai) | 19 | 50 |
| [Web3 & protocols](#page-web3) | 3 | 11 |
| [Hardware & firmware](#page-hardware) | 3 | 15 |

## Shared procedures

| Procedure | Applicable playbooks |
| --- | --- |
| [Object, function, and property authorization](#page-modules-authz-matrix) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) |
| [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [Trace input into queries, commands, and templates](#page-modules-injection-tracing) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud) |
| [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) · [Desktop & extensions](#page-desktop) |
| [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) |
| [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud) |
| [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3) |
| [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network) |
| [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) | [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) |
| [Source review: entry point to protected operation](#page-modules-source-dataflow) | [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) |
| [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) | [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) |
| [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) | [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) | [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai) |
| [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) | [Cloud & containers](#page-cloud) |
| [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) | [Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) |
| [Container and Kubernetes isolation](#page-modules-container-kubernetes) | [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) |
| [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) | [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) |
| [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) | [Network services](#page-network) · [Cloud & containers](#page-cloud) |
| [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) | [Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) |
| [Android components, intents and deep links](#page-modules-android-components) | [Mobile](#page-mobile) |
| [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) | [Mobile](#page-mobile) |
| [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) | [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) |
| [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) | [Desktop & extensions](#page-desktop) |
| [Update signatures, rollback and privileged installation](#page-modules-update-integrity) | [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) |
| [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) | [AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss) |
| [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) | [AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) |
| [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) | [Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss) |
| [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) | [Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss) |
| [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) | [Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss) |
| [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) | [Hardware & firmware](#page-hardware) · [Network services](#page-network) |
| [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) |
| [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |
| [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) | [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) |
| [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) | [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) |
| [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) | [Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) |
| [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) | [AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) |
| [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) | [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) |

Record actual outcomes and evidence using the [coverage template](#page-templates).


---

<a id="page-attack"></a>

# MITRE ATT&CK mapping

MITRE ATT&CK® describes adversary behavior. Use these **conditional references** to annotate demonstrated attack steps; a vulnerability name alone does not establish a mapping. This curated Enterprise selection is not an exhaustive vulnerability taxonomy, a required testing checklist, or evidence of an incident. **No direct mapping** is a valid result.

Verified against official technique pages on **14 September 2026**, with **ATT&CK v19.2** current. Enterprise v19 split Defense Evasion into **Stealth** and **Defense Impairment**; Mobile retains its separate taxonomy. The tactic labels below follow current Enterprise pages. [Version history](https://attack.mitre.org/resources/versions/), [v19 changes](https://attack.mitre.org/resources/updates/updates-april-2026/), [v19.2 release](https://attack.mitre.org/resources/updates/updates-august-2026/).

## Choose the right reference layer

Keep the vulnerability classification, demonstrated behavior, test coverage, and severity in separate fields. They answer different questions and can coexist in the same report. The relationships below are a practical annotation convention, not an official automatic crosswalk.

| Reference | Question it answers | What to record |
| --- | --- | --- |
| [CWE](https://cwe.mitre.org/about/index.html) | Which software or hardware weakness caused the failure? | The most specific supported root cause. |
| [CAPEC](https://capec.mitre.org/about/index.html) | What recurring attack pattern exploits that weakness? | An applicable pattern and its preconditions. |
| [WSTG](https://owasp.org/www-project-web-security-testing-guide/) | How was the web security property tested? | Versioned scenario and completed evidence. |
| [ASVS](https://owasp.org/www-project-application-security-verification-standard/) | Which technical security requirement should hold? | Versioned control and observed failure. |
| [MITRE ATT&CK](https://attack.mitre.org/resources/faq/) | What adversary behavior does this demonstrated step resemble? | Domain, technique, evidence, and justified tactic. |
| [CVSS](https://www.first.org/cvss/v4.0/specification-document) | What are the vulnerability's technical characteristics and severity? | Version, vector, score, and assumptions. |

There is no universal one-to-one conversion. A single SSRF weakness may enable several different behaviors, while several different weaknesses may enable the same behavior. An ATT&CK label neither increases a bounty nor substitutes for the impact argument. A count of mapped techniques is not a severity score.

## Choose a reportable CWE root cause

Catalog badges are candidate references. Before putting a CWE in a report, read its current **Vulnerability Mapping Notes**, including whether its use is allowed, requires review, or is discouraged. Explain the implementation mistake instead of copying a category name from a checklist. [MITRE root-cause guidance](https://cwe.mitre.org/documents/cwe_usage/guidance.html).

| Evidence identifies | Classification decision |
| --- | --- |
| No required authorization decision occurs | Consider [CWE-862](https://cwe.mitre.org/data/definitions/862.html). |
| A decision occurs but accepts the wrong actor/action/resource | Consider [CWE-863](https://cwe.mitre.org/data/definitions/863.html). |
| A resource was assigned inappropriate permissions | Review [CWE-732](https://cwe.mitre.org/data/definitions/732.html); failed permission checking is a different cause. |
| Protected data becomes visible | Identify the disclosure mechanism. [CWE-200](https://cwe.mitre.org/data/definitions/200.html) is discouraged for real vulnerability mapping; confidentiality loss alone is an impact. |
| Only a broad access-control failure is established | Refine the cause when possible. [CWE-284](https://cwe.mitre.org/data/definitions/284.html) is a discouraged high-level pillar. |
| An executable receives attacker-controlled options | Distinguish [argument injection](https://cwe.mitre.org/data/definitions/88.html) from [OS command injection](https://cwe.mitre.org/data/definitions/78.html); a shell is not required for the former. |

Several badges are alternatives, not proof of several independent flaws. Describe a causal chain only when the evidence supports its distinct steps. When implementation details are unavailable, record the uncertainty rather than choosing an artificially precise root cause.

## Map from evidence in six steps

1. **Write the observed action first.** Identify the actor's starting access, the affected component, the operation performed, the boundary crossed, and the resulting access. Keep a separate sentence for untested follow-on possibilities.
2. **Select the domain and environment.** These cards are Enterprise references. Check the technique's platform list and description; a similarly named Mobile behavior may have a different ID. A mobile application's backend API can still have an Enterprise-relevant behavior.
3. **Find candidates using the action.** Search for token acquisition, token reuse, trust modification, or private-repository collection. Do not search only for a vulnerability label and accept the first apparent match.
4. **Read the full technique and nearest alternatives.** Confirm its objective, mechanism, and boundary. Use a sub-technique only when the evidence supports that specificity. Otherwise retain a parent technique, mark the relationship conditional, or record no direct mapping.
5. **Attach the evidence reference.** Link the sanitized request, test fixture, process trace, audit event, or reproduction step. Label the result demonstrated on the authorized target, reproduced in an isolated lab, or hypothetical. These labels prevent a lab capability from becoming an unsupported incident claim.
6. **Record the version and reviewer rationale.** Include the technique URL, domain, catalog version, verification date, and why alternatives were rejected. Select only the tactic justified by this step; a card's complete official tactic list is context, not proof of every goal.

ATT&CK describes tactics as goals and techniques as actions; its tactics are not a compulsory ordered sequence. The workflow above is this manual's application of those distinctions. [MITRE FAQ](https://attack.mitre.org/resources/faq/).

## Worked mapping decisions

| Finding and evidence | Appropriate annotation | Unsupported shortcut |
| --- | --- | --- |
| Account A changes an invoice ID and reads account B's seeded invoice. | Consider [CWE-639](https://cwe.mitre.org/data/definitions/639.html) when the user-controlled key causes the authorization bypass; no direct ATT&CK mapping may be best. | BOLA always equals T1190 or T1068. |
| SSRF retrieves credential-bearing metadata in an isolated cloud instance. | [CWE-918](https://cwe.mitre.org/data/definitions/918.html) for the weakness; [T1552.005](https://attack.mitre.org/techniques/T1552/005/) for the demonstrated credential-access behavior. | A DNS callback proves metadata credential theft or cloud takeover. |
| An unauthorized CI artifact download exposes a service access token. | [T1528](https://attack.mitre.org/techniques/T1528/) for token acquisition; [T1552.001](https://attack.mitre.org/techniques/T1552/001/) can describe its file source. Choose useful specificity. | Every CI artifact issue is supply-chain compromise. |
| A substituted release artifact is consumed by a controlled downstream installer. | [T1195.002](https://attack.mitre.org/techniques/T1195/002/); separately document artifact acceptance and downstream execution. | Merely uploading an unused artifact proves consumer compromise. |
| An OAuth flaw discloses a controlled victim's access token; a permitted test reuses it. | [T1528](https://attack.mitre.org/techniques/T1528/) and [T1550.001](https://attack.mitre.org/techniques/T1550/001/) describe separate supported actions. | Token theft and token reuse are interchangeable. |
| A tenant boundary failure permits adding a controlled federation provider in a lab. | [T1484.002](https://attack.mitre.org/techniques/T1484/002/) when the changed trust relationship matches its description. | An existing broad OIDC trust policy alone is trust modification. |
| A local service flaw changes effective identity from an ordinary user to SYSTEM/root. | [T1068](https://attack.mitre.org/techniques/T1068/) with before/after privilege evidence. | Any application endpoint named admin is OS privilege escalation. |
| A lab device accepts modified peripheral firmware and executes it after reboot. | Evaluate [T1542.002](https://attack.mitre.org/techniques/T1542/002/) against the actual component and persistence evidence. | Every extracted firmware secret is firmware persistence. |

T1190 requires a demonstrated initial-access relationship to an Internet-facing host or system. The issue may be injection, deserialization, or a configuration flaw, but its mere presence in a web application is insufficient. Likewise, a BOLA affecting actual cloud-stored confidential objects may support T1530; record that storage context rather than inheriting the mapping from the word BOLA. [T1190](https://attack.mitre.org/techniques/T1190/), [T1530](https://attack.mitre.org/techniques/T1530/).

## Reusable report annotation

```yaml
weakness:
  id: CWE-918
  rationale: URL validation permits requests to the fixture metadata service.
attack:
  domain: enterprise-attack
  catalog_version: '19.2'
  checked_at: '2026-09-14'
  technique: T1552.005
  demonstrated_tactic: Credential Access
  evidence_level: isolated-lab-reproduction
  evidence_refs: [request-04, metadata-fixture-response]
  rationale: The response disclosed the fixture workload credential.
  limitations: No production credentials accessed; cloud token reuse untested.
  incident_attribution: none
```

For a weak relationship, replace the technique with `null` and explain: `Object authorization failure demonstrated; no sufficiently specific ATT&CK behavior established.` Preserve the vulnerability and its impact; an empty mapping is not a failed finding.

## Review checklist and boundaries

- [ ] Root cause and demonstrated behavior are separate.
- [ ] The domain, platform, ID, name, and current technique status were checked.
- [ ] Each asserted step has an evidence reference and starting privileges.
- [ ] Token acquisition, token reuse, role grants, and trust changes are distinguished.
- [ ] Hypothetical follow-on actions are explicitly labelled and excluded from demonstrated coverage.
- [ ] A lab result is not described as an incident or attributed to an actor.
- [ ] No additional persistence, collection, or scope expansion was performed merely to fill a matrix.
- [ ] The report includes limitations, cleanup, severity reasoning, and a reproducible regression condition.

For device-side Android/iOS behavior, consult the [Mobile matrix](https://attack.mitre.org/matrices/mobile/); do not copy Enterprise IDs by name. For Web3 reentrancy or oracle manipulation, no direct Enterprise mapping is often appropriate. For AI-specific prompt injection or model manipulation, evaluate **MITRE ATLAS separately**, with its own identifiers and version. Conventional follow-on behavior, such as demonstrated application-token theft, can still be annotated independently. ATLAS maintains a distinct knowledge base for adversarial behavior targeting AI systems. [Official ATLAS data](https://github.com/mitre-atlas/atlas-data).

Reverse references in this manual mean that a playbook discusses a technique under stated conditions. They do not certify that every vulnerability in that family implements it, that a tool detected it, or that the target has experienced it.


## Conditional technique references



### T1190 · Exploit Public-Facing Application

**Enterprise tactics:** Initial Access. [Official technique](https://attack.mitre.org/techniques/T1190/).

**Apply only when:** A demonstrated exploit of an Internet-facing service provides initial access to its host, system, or environment; explain the foothold and trust boundary.

**Do not equate with:** Not a blanket label for every web/API weakness. A reflected parameter, scanner alert, or ordinary cross-account object read alone does not establish initial network/system access.

**Catalog reverse references:** [OS command injection](#page-vulnerabilities-os-command-argument-boundary) · [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection) · [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization)





### T1203 · Exploitation for Client Execution

**Enterprise tactics:** Execution. [Official technique](https://attack.mitre.org/techniques/T1203/).

**Apply only when:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process.

**Do not equate with:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.

**Catalog reverse references:** [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization) · [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write) · [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free) · [Electron IPC exposes main-process authority to an untrusted sender](#page-vulnerabilities-electron-ipc-confused-deputy) · [Desktop protocol handler misinterprets external input](#page-vulnerabilities-desktop-protocol-confusion)





### T1068 · Exploitation for Privilege Escalation

**Enterprise tactics:** Privilege Escalation. [Official technique](https://attack.mitre.org/techniques/T1068/).

**Apply only when:** A software vulnerability crosses a privilege boundary into a more privileged process or security context; record before/after identities and the vulnerable component.

**Do not equate with:** Do not infer this from any feature named admin, a writable path alone, or a kernel version match. Application role authorization flaws need their own contextual analysis.

**Catalog reverse references:** [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write) · [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free) · [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path) · [Privileged updater consumes lower-user-controlled staging content](#page-vulnerabilities-updater-privileged-staging)





### T1611 · Escape to Host

**Enterprise tactics:** Privilege Escalation. [Official technique](https://attack.mitre.org/techniques/T1611/).

**Apply only when:** A controlled test shows code or access escaping a container or virtual machine into the underlying host/hypervisor security context.

**Do not equate with:** Root inside a container is not necessarily host root. A permissive manifest or exposed Docker socket is a hypothesis until its actual boundary effect is established.

**Catalog reverse references:** [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure)





### T1059.004 · Command and Scripting Interpreter: Unix Shell

**Enterprise tactics:** Execution. [Official technique](https://attack.mitre.org/techniques/T1059/004/).

**Apply only when:** The demonstrated exploit invokes a Unix shell to execute commands; capture the shell invocation or equivalent process evidence in a controlled reproduction.

**Do not equate with:** Calling an executable directly without a shell, template evaluation, and generic RCE are not automatically Unix Shell. Choose an interpreter only when supported by evidence.

**Catalog reverse references:** [OS command injection](#page-vulnerabilities-os-command-argument-boundary) · [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection)





### T1552.001 · Unsecured Credentials: Credentials In Files

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1552/001/).

**Apply only when:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details.

**Do not equate with:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

**Catalog reverse references:** [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials) · [Sensitive values exposed through state or plan artifacts](#page-vulnerabilities-iac-state-secret-exposure) · [Secrets retained in container build artifacts](#page-vulnerabilities-container-build-secret-leak) · [Sensitive client state leaks through accessible diagnostics](#page-vulnerabilities-client-secret-logging) · [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials) · [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret)





### T1552.004 · Unsecured Credentials: Private Keys

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1552/004/).

**Apply only when:** A weakness exposes or allows export of a private authentication/decryption key, such as an SSH private key; identify its type and protection state without publishing it.

**Do not equate with:** A public key, certificate without its private key, key fingerprint, or inaccessible encrypted key does not by itself establish usable private-key compromise.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1552.005 · Unsecured Credentials: Cloud Instance Metadata API

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1552/005/).

**Apply only when:** SSRF or local access reaches cloud instance metadata and demonstrates access to credential-bearing metadata; use isolated fixtures or explicitly permitted controlled identities.

**Do not equate with:** An outbound callback, generic internal reachability, or harmless metadata document alone does not prove credential access. Do not infer a metadata-to-cloud takeover chain.

**Catalog reverse references:** [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination)





### T1528 · Steal Application Access Token

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1528/).

**Apply only when:** An application, CI/CD, OAuth, or container boundary failure exposes another principal's access or refresh token to the test actor.

**Do not equate with:** An OAuth redirect weakness without token capture, a public client ID, or a token the actor already legitimately controls is not token theft. Separate acquisition from reuse.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1550.001 · Use Alternate Authentication Material: Application Access Token

**Enterprise tactics:** Lateral Movement. [Official technique](https://attack.mitre.org/techniques/T1550/001/).

**Apply only when:** A captured or improperly obtainable application token is actually accepted for access to a protected service or resource outside the actor's intended permissions.

**Do not equate with:** Finding a token alone is not reuse; routine authorized API calls are not this behavior. Current Enterprise tactic metadata lists Lateral Movement, not the old Defense Evasion label.

**Catalog reverse references:** [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion)





### T1550.004 · Use Alternate Authentication Material: Web Session Cookie

**Enterprise tactics:** Lateral Movement. [Official technique](https://attack.mitre.org/techniques/T1550/004/).

**Apply only when:** A session cookie acquired across a security boundary is accepted in another controlled client to access the represented user's protected session.

**Do not equate with:** A missing cookie flag, reflected cookie name, or untested assumption about MFA bypass is insufficient. Ordinary cookie-based login does not demonstrate compromise.

**Catalog reverse references:** [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding) · [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access)





### T1539 · Steal Web Session Cookie

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1539/).

**Apply only when:** The tested weakness exposes an authentication session cookie across a boundary, for example from a controlled victim browser or improperly protected storage.

**Do not equate with:** XSS alone does not prove cookie theft, especially when the relevant cookie is HttpOnly. Cookie acquisition and successful session replay are distinct evidence steps.

**Catalog reverse references:** [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution)





### T1606.002 · Forge Web Credentials: SAML Tokens

**Enterprise tactics:** Credential Access. [Official technique](https://attack.mitre.org/techniques/T1606/002/).

**Apply only when:** The reproduction generates new forged SAML assertions using a trusted signing capability or attacker-controlled federation trust, and identifies the accepting relying party.

**Do not equate with:** JWT parsing problems, OAuth token theft, and generic SSO bypass are not automatically SAML token forgery. Validate that the tested mechanism matches the SAML technique description.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1078.004 · Valid Accounts: Cloud Accounts

**Enterprise tactics:** Stealth, Persistence, Privilege Escalation, Initial Access. [Official technique](https://attack.mitre.org/techniques/T1078/004/).

**Apply only when:** A controlled reproduction uses compromised or misused valid cloud credentials/accounts to gain access or exceed the account's intended role; identify the specific observed goal.

**Do not equate with:** The existence of a cloud account, a suspected leaked key, or authorized use of a researcher account is not enough. The official tactic list does not mean all four goals occurred.

**Catalog reverse references:** [Overbroad cloud role trust](#page-vulnerabilities-cloud-iam-role-trust) · [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope)





### T1098.001 · Account Manipulation: Additional Cloud Credentials

**Enterprise tactics:** Persistence, Privilege Escalation. [Official technique](https://attack.mitre.org/techniques/T1098/001/).

**Apply only when:** An unauthorized actor can add their controlled credential to a cloud account, application, or service principal; prove in an isolated tenant with an audit trail and rollback.

**Do not equate with:** Reading an existing key or finding broad IAM permissions is not evidence that a credential was added. Keep policy-only reachability analysis explicitly labelled as a hypothesis.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1098.003 · Account Manipulation: Additional Cloud Roles

**Enterprise tactics:** Persistence, Privilege Escalation. [Official technique](https://attack.mitre.org/techniques/T1098/003/).

**Apply only when:** A test actor adds cloud roles or permissions to an account they control or have compromised, including a controlled external account granted rights in a test tenant.

**Do not equate with:** Existing excessive permissions and use of an existing assume-role policy are not themselves role modification. Distinguish new grants from the abuse of old grants.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1484.002 · Domain or Tenant Policy Modification: Trust Modification

**Enterprise tactics:** Defense Impairment, Privilege Escalation. [Official technique](https://attack.mitre.org/techniques/T1484/002/).

**Apply only when:** A demonstrated boundary failure permits alteration of domain/tenant federation trust or addition of an attacker-controlled identity provider that changes accepted identities.

**Do not equate with:** An overbroad existing OIDC condition, an ordinary role assumption, or merely reading a trust document does not demonstrate trust modification. Identify the actual trust object changed.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1195.001 · Supply Chain Compromise: Compromise Software Dependencies and Development Tools

**Enterprise tactics:** Initial Access. [Official technique](https://attack.mitre.org/techniques/T1195/001/).

**Apply only when:** A controlled reproduction shows maliciously modified dependency or development-tool content being consumed through a software supply chain, such as a substituted reusable build action.

**Do not equate with:** An old vulnerable dependency, an SBOM finding, or arbitrary CI log access does not prove supply-chain compromise. Show the manipulated component and consumer path.

**Catalog reverse references:** [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution) · [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion)





### T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain

**Enterprise tactics:** Initial Access. [Official technique](https://attack.mitre.org/techniques/T1195/002/).

**Apply only when:** A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab.

**Do not equate with:** Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.

**Catalog reverse references:** [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection) · [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution) · [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning) · [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact)





### T1530 · Data from Cloud Storage

**Enterprise tactics:** Collection. [Official technique](https://attack.mitre.org/techniques/T1530/).

**Apply only when:** A demonstrated authorization or configuration failure permits collection of a controlled confidential object from an actual cloud storage service, including supported SaaS storage contexts.

**Do not equate with:** A bucket name, public-by-design file, general BOLA, or any API response simply hosted in the cloud is insufficient. Establish the storage context and protected data boundary.

**Catalog reverse references:** [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read) · [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope)





### T1213.003 · Data from Information Repositories: Code Repositories

**Enterprise tactics:** Collection. [Official technique](https://attack.mitre.org/techniques/T1213/003/).

**Apply only when:** A controlled actor gains unauthorized access to a private code repository and collects a limited test file or proprietary source material as evidence.

**Do not equate with:** Cloning an intentionally public OSS project is not this technique. MITRE distinguishes collection from private repositories from reconnaissance through public repositories.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





### T1542.001 · Pre-OS Boot: System Firmware

**Enterprise tactics:** Stealth, Persistence. [Official technique](https://attack.mitre.org/techniques/T1542/001/).

**Apply only when:** A lab demonstration modifies system firmware, such as BIOS/UEFI, to maintain execution/access across boot; record the firmware component, persistence behavior, and recovery procedure.

**Do not equate with:** Downloading firmware, finding an embedded password, or detecting missing signature checks alone is not firmware persistence. Ordinary application firmware packaging needs component-level analysis.

**Catalog reverse references:** [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation) · [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap)





### T1542.002 · Pre-OS Boot: Component Firmware

**Enterprise tactics:** Stealth, Persistence. [Official technique](https://attack.mitre.org/techniques/T1542/002/).

**Apply only when:** A controlled reproduction modifies peripheral/component firmware to preserve execution or access outside the main OS/system firmware, with evidence of that persistence.

**Do not equate with:** A firmware binary containing a vulnerable library is insufficient. Do not treat every IoT firmware issue as either system firmware or component firmware persistence.

**Catalog reverse references:** [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation) · [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap)





### T1505.003 · Server Software Component: Web Shell

**Enterprise tactics:** Persistence. [Official technique](https://attack.mitre.org/techniques/T1505/003/).

**Apply only when:** An isolated reproduction establishes a server-side web-accessible script that provides continuing server control; its placement and execution are supported by evidence.

**Do not equate with:** File upload, a static marker file, one-off RCE, or a shell command alone does not establish a web shell. Do not deploy persistence to a live target merely to add this label.

**Catalog reverse references:** No specific catalog entry selected. Use the demonstrated behavior to assess applicability.





---

<a id="page-checklist"></a>

# Master checklist

Use this as an engagement preflight and a submission review. A tick means the item was checked; record the evidence and outcome in the coverage template. An unchecked item is not automatically a vulnerability. **Not applicable, blocked, untested, passed, and finding are different outcomes.** Scope-specific checklists follow the common gates.

## Before testing

- [ ] Official policy URL and review time recorded; current intake status confirmed.
- [ ] Researcher eligibility, invitation, confidentiality and collaboration conditions satisfied.
- [ ] Exact asset, version, environment and test identity approved.
- [ ] Repository scope distinguished from vendor infrastructure and customer deployments.
- [ ] Third-party services, redirects, callbacks and provider restrictions reviewed.
- [ ] Allowed techniques, time window, rate and concurrency recorded.
- [ ] Payment eligibility and disclosure terms recorded separately from test permission.
- [ ] Owned or program-issued accounts, tenants, fixtures and recovery method ready.
- [ ] Tools, rules, queries, databases, artifact hashes and versions recorded.
- [ ] Scope evaluator prevents newly discovered assets from entering active jobs automatically.
- [ ] Logs and callbacks will not expose private data to an unapproved external service.
- [ ] Stop conditions and security contact available.

## During research

- [ ] Normal product behavior and intended security contract understood.
- [ ] Actors, resources, entry points, privileged actions and trust boundaries mapped.
- [ ] Each prioritized hypothesis states preconditions, expected violation and evidence.
- [ ] Baseline and negative control captured before interpreting the result.
- [ ] Synthetic resource ownership verified independently of guessed IDs.
- [ ] Asynchronous jobs, alternative protocols and state transitions considered where relevant.
- [ ] Security behavior changed by instrumentation or debug mode documented.
- [ ] A successful status code checked against actual data or state.
- [ ] Failed tools and timeouts recorded as failures rather than clean scans.
- [ ] Sensitive data encounter or service degradation triggers the agreed stop behavior.
- [ ] Every session ends with a result and a specific next action.

## Before submission

- [ ] A real security boundary is crossed under eligible attacker assumptions.
- [ ] Exact affected asset, product release/commit and supported configuration provided.
- [ ] Clean reproduction succeeds using written steps and preserved fixtures.
- [ ] Demonstrated impact is separated from possible downstream consequences.
- [ ] Prior advisories, known issues, recent fixes and program exclusions checked.
- [ ] PoC is minimal and does not depend on unnecessary data access or destructive effects.
- [ ] Report includes expected/actual behavior, numbered steps, evidence and controls.
- [ ] Source findings show the real public entry path, guard behavior and reachable sink.
- [ ] Client/device findings distinguish modified builds from production-relevant behavior.
- [ ] AI findings contain actual retrieval/tool events, not only generated claims.
- [ ] Web3 findings pin chain/address/block/source and satisfy program proof requirements.
- [ ] Hardware findings state physical access, revision, firmware and recovery assumptions.
- [ ] Severity uses the required rubric with justified assumptions and a vector if applicable.
- [ ] Tokens, personal data and unnecessary private details removed from attachments.
- [ ] Submission uses the designated confidential channel.

## After submission

- [ ] Report ID, submitted version, triage questions and decisions recorded.
- [ ] Replies answer the actual reproduction or impact uncertainty.
- [ ] Retest permission and fixed version checked before new requests.
- [ ] Original case and legitimate control compared against the fix.
- [ ] Disclosure timing and allowable content agreed or governed by the program policy.
- [ ] Synthetic data, accounts, tokens, callbacks and lab costs cleaned up as appropriate.
- [ ] Evidence retained or removed according to program rules and the retention plan.
- [ ] Reusable lessons sanitized before adding to a personal or public knowledge base.

## Scope-specific review lists

The lists below retain the evidence and eligibility expectations of their technical chapters. Read the linked playbook before checking its items.

## OSS & self-hosted

[Open the OSS & self-hosted playbook](#page-oss).

- [ ] Repository, product edition, version, scope, and reporting channel recorded.
- [ ] Working baseline, synthetic identities, reset procedure, and config delta preserved.
- [ ] Priority entry points mapped to authentication, authorization, and sensitive operations.
- [ ] Every promoted finding has attacker control, reachability, prerequisites, and impact evidence.
- [ ] Source, runtime, build, and shipped dependency inventories distinguished.
- [ ] Secrets redacted; no discovered credential used for verification.
- [ ] CI events, artifact/cache consumers, publishing identity, images, and IaC reviewed.
- [ ] Scanner errors, excluded files, stale databases, and unresolved models recorded.
- [ ] Local PoC minimizes side effects and includes a legitimate control case.
- [ ] Prior advisories checked; tested versions distinguished from inferred versions.
- [ ] Report and patch retest can be reproduced from preserved inputs.



## Web & API

[Open the Web & API playbook](#page-web-api).

- [ ] Policy snapshot and exact asset/technique authorization recorded; exclusions applied.
- [ ] Every candidate has an ownership and scope decision; redirects and dependencies reviewed.
- [ ] Synthetic accounts, two tenants, role transitions and cleanup plan established.
- [ ] Endpoints include background jobs, exports, integrations and alternate protocols.
- [ ] Object, function and property authorization checked independently.
- [ ] Authentication and revocation tested across UI/API/socket paths.
- [ ] High-value business invariants have serial controls before concurrency tests.
- [ ] Browser findings verified in a real browser; server findings have controlled differential evidence.
- [ ] Finding has a reproducible boundary violation, not only a scanner label or missing hardening control.
- [ ] Sensitive evidence minimized; timestamps, requests, relevant responses and state changes preserved.
- [ ] Test records removed, tokens revoked, callbacks stopped and report submitted privately.



## Network services

[Open the Network services playbook](#page-network).

- [ ] Exact IPv4/IPv6, transport, port, owner and environment are authorized.
- [ ] Shared hosting, origin, provider and customer boundaries are documented.
- [ ] Active requests are separated from historical third-party discovery.
- [ ] DNS server, query type and UDP/TCP behavior are explicit.
- [ ] Commands have explicit ports, timeouts and bounded concurrency.
- [ ] Service identity includes build/configuration and possible vendor backports.
- [ ] SNI and expected TLS hostname are recorded.
- [ ] Authentication and resource authorization have separate test cases.
- [ ] Synthetic data or owner-provided canaries support evidence.
- [ ] DNS/mail configuration observations are tied to eligible impact.
- [ ] Parser/appliance testing has isolation, recovery and minimized inputs.
- [ ] First-proof stopping, cleanup and private reporting are completed.



## Mobile

[Open the Mobile playbook](#page-mobile).

**Android**

- [ ] Package ID, publisher, store channel, version, hash, and signer recorded.
- [ ] Base and relevant split/dynamic-feature packages included.
- [ ] Device API, ABI, target SDK, and release/debug state recorded.
- [ ] Exported and dynamically registered components mapped.
- [ ] Component permissions and caller identity checked.
- [ ] Provider permissions, URI grants, and path handling reviewed.
- [ ] Intent forwarding and PendingIntent authority traced.
- [ ] Deep-link host, path, parameter, and session validation checked.
- [ ] WebView navigation, frames, and bridge methods mapped.
- [ ] Storage, logs, notifications, clipboard, and backups examined.
- [ ] Key storage, key use, and local authentication connected.
- [ ] Network trust behavior separated from lab CA changes.
- [ ] Account switching and logout tested with synthetic identities.
- [ ] Claimed ordinary-app issue reproduced without ADB-only privilege.

**iOS**

- [ ] Bundle ID, build, channel, hash, signing team, and device recorded.
- [ ] Simulator, device, and instrumented builds distinguished.
- [ ] `Info.plist` and embedded extension metadata inspected.
- [ ] Associated domains and custom URL schemes inventoried.
- [ ] URL parameters and account context validated independently.
- [ ] App Groups and Keychain access groups mapped.
- [ ] Keychain class, synchronization, and user-presence policy reviewed.
- [ ] Sensitive file protection evaluated for intended lock states.
- [ ] Extension and document-import trust boundaries exercised.
- [ ] WebView frames, navigation, and message handlers inspected.
- [ ] ATS configuration and actual certificate validation checked.
- [ ] Cache, logs, pasteboard, screenshots, and backup exposure assessed.
- [ ] Local authentication tied to sensitive data or key access.
- [ ] Re-signing/jailbreak limitations and release reproduction documented.



## Desktop & extensions

[Open the Desktop & extensions playbook](#page-desktop).

**Native applications: apply each item to Windows, macOS, or Linux as relevant.**

- [ ] Product, platform, architecture, channel, version, hash, signer recorded.
- [ ] Installer, updater, service/helper, and plugin scope separated.
- [ ] Clean snapshot and standard-user baseline captured.
- [ ] Default installation paths and post-install actions mapped.
- [ ] Service/helper effective identity documented.
- [ ] IPC caller authentication and object-level authorization reviewed.
- [ ] Writable executable, configuration, temporary, and search paths checked.
- [ ] Windows registry/filesystem ACLs and named-pipe access inspected.
- [ ] macOS XPC, launch services, entitlements, and signing checks inspected.
- [ ] Linux sockets, D-Bus/polkit, service users, capabilities, and ownership inspected.
- [ ] Protocol handlers, file associations, imports, and archive boundaries exercised.
- [ ] Update metadata, artifact, signer, and rollback policy traced.
- [ ] Parser fuzzing limited to a local harness with resource limits.
- [ ] Crashes minimized; impact distinguished from code-execution speculation.
- [ ] Reproduction repeated without artificial administrator privileges.

**Electron and extensions**

- [ ] Shipped Electron/browser version and extension ID/version captured.
- [ ] Store-installed and modified/unpacked evidence distinguished.
- [ ] Every renderer/window’s security settings inspected.
- [ ] Context isolation and sandbox assumptions verified.
- [ ] Preload methods and main-process IPC handlers inventoried.
- [ ] IPC sender frame/origin and argument checks inspected.
- [ ] Navigation, child-window, and external-protocol handling reviewed.
- [ ] Host/API/optional permissions and intended usage mapped.
- [ ] External messaging and web-accessible resources restricted appropriately.
- [ ] Page-origin data treated as untrusted through content-script messages.
- [ ] Privileged service-worker actions require bounded inputs.
- [ ] Native-messaging host origin list, path, and parser reviewed.
- [ ] Local browser profile contains only synthetic application data.
- [ ] Result reproduced through a realistic entry point, without console-only access.



## Cloud & containers

[Open the Cloud & containers playbook](#page-cloud).

- [ ] Exact account/project/subscription, resource owner and active principal match scope.
- [ ] CSP policy and bounty policy both cover the method; third-party integrations are identified.
- [ ] Test tenants A/B, synthetic objects and baseline denied requests exist.
- [ ] Management plane, data plane, storage signing and background jobs are separately mapped.
- [ ] IAM inheritance and restrictions are considered; exported policy is not mistaken for effective permission.
- [ ] Cluster, namespace, CNI, admission, operator and node boundaries are distinguished.
- [ ] Workload creation and sensitive RBAC verbs are reviewed without reading real secrets.
- [ ] Image/module digest, supported deployment mode and runtime reachability are recorded.
- [ ] SSRF proof uses owned callbacks; impact beyond the callback remains explicitly unproven.
- [ ] The report contains one minimum boundary violation, redacted evidence and cleanup status.



## AI, agents & MCP

[Open the AI, agents & MCP playbook](#page-ai).

- [ ] Hosted application, model, artifact, connector and provider scopes are distinguished.
- [ ] Attacker capability and the legitimate user's task are explicitly recorded.
- [ ] A/B tenants and private random canaries exist; canaries are absent from attacker input.
- [ ] Baseline requests establish expected permissions before adversarial input.
- [ ] Model version, runtime, sampling settings and trial budget are fixed and logged.
- [ ] Retrieval authorization, citations, caches and revocation are tested separately.
- [ ] Tool argument ownership and approval binding are checked below the model.
- [ ] MCP protocol era, transport, OAuth audience and upstream credentials are mapped.
- [ ] Model hashes, custom code and deserialization paths are reviewed in isolation.
- [ ] Success means an observable security consequence; hallucinated actions are excluded.
- [ ] Attempts/successes, evidence redaction and cleanup are documented.



## Web3 & protocols

[Open the Web3 & protocols playbook](#page-web3).

| Area | Investigation | Evidence that advances a report |
|---|---|---|
| Deployment identity | Correct chain, implementation and configuration at the pinned block | Address/commit manifest and the executed call path |
| Authorization | Initializers, role delegation, upgrade authority, emergency controls, arbitrary call permissions | An unprivileged actor crosses the documented permission boundary |
| Accounting | Deposits, redemptions, fees, debt indexes, rewards, donations, empty pools | Before/after balance sheet with explicit units and a violated relationship |
| Token behavior | Supported fee-on-transfer, rebasing, hooks, nonstandard returns and decimal variation | A supported integration produces incorrect accounting or authority |
| Oracle integration | Price denomination, freshness, decimals, failure modes and L2 downtime | Reachable accepted input causes an incorrect economic decision |
| Callbacks | Callback authentication, intermediate state, cross-function and cross-contract reentry | A local trace showing the unexpected state transition and impact |
| Signatures | Domain, signer, nonce, deadline, action binding, chain and verifying contract | A signature authorizes an unintended second action or context |
| Governance | Snapshot voting, quorum, proposal state, timelock, cancellation and execution | A locally demonstrated bypass of the actual governance guarantees |
| Bridges | Source authentication, destination binding, message uniqueness, ordering and finality | A local two-sided model with a duplicated or unauthorized state transition |
| Liveness | Unbounded processing, poisoned queues, dependency failure and recovery | A bounded local test proving eligible user funds or operations become stuck |
| Economic ordering | Slippage, deadlines, quote validity and attacker-controlled order | Loss exceeding intended, documented market behavior under feasible assumptions |
| Regression | Current implementation and known exclusions | Fresh reproduction and comparison with documented known issues |

Oracle checks must be feed-specific. Chainlink exposes answer metadata and timestamps; applications must interpret values and freshness correctly. On supported L2 integrations, evaluate sequencer availability and any required recovery grace period. A missing generic check is only a lead until its concrete consequence is established. [Data Feeds API](https://docs.chain.link/data-feeds/api-reference), [L2 sequencer feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds)

Vault rounding and donations deserve explicit boundary tests around zero supply, small deposits and conversions. OpenZeppelin’s ERC-4626 discussion illustrates why share arithmetic and inflation defenses require economic reasoning. Signature review likewise needs more than finding EIP-712: the standard itself does not supply replay protection. Inspect application nonces, consumption and action binding. [ERC-4626 security considerations](https://docs.openzeppelin.com/contracts/5.x/erc4626), [EIP-712](https://eips.ethereum.org/EIPS/eip-712)

Governance review must follow the configured module composition: voting and execution may be separated, and a timelock changes which contract executes the action. Bridges introduce additional assumptions about relayers, validators and cross-chain finality. Reproduce these assumptions explicitly rather than replacing their security checks with unconditional mocks. [OpenZeppelin governance](https://docs.openzeppelin.com/contracts/5.x/api/governance), [Ethereum bridges](https://ethereum.org/developers/docs/bridges/)

MEV describes value extracted through transaction inclusion or ordering, including arbitrage and sandwich behavior. Its existence is not automatically a bounty vulnerability. The report must identify an eligible broken guarantee, realistic capital and ordering assumptions, and the resulting harm; reproduce ordering locally. [Ethereum MEV](https://ethereum.org/developers/docs/mev/)

For non-EVM branches, retain the same scope and evidence model but replace the execution harness. Solana research needs account ownership, signer and writable privileges, PDA derivation and CPI boundaries; Sui/Move research needs module authority and object ownership; protocol/client research needs versioned consensus rules, serialization, state transitions and private multi-node reproductions. Treat these as separate specialization tracks, not as Solidity detector configurations. Select the chain’s official SDK and program-specific build requirements before testing. [Solana privileges](https://solana.com/docs/core/cpi/cpi-execution), [Sui Move concepts](https://docs.sui.io/develop/write-move/sui-move-concepts), [Ethereum client architecture](https://ethereum.org/developers/docs/nodes-and-clients/)



## Hardware & firmware

[Open the Hardware & firmware playbook](#page-hardware).

| Area | Investigation | Evidence that advances a report |
|---|---|---|
| Firmware identity | Model, revision, update package, installed build, hashes | Exact affected product and reproducible baseline |
| Provisioning | Initial ownership, pairing, reset, reassignment and local presence | An unauthorized identity obtains a protected role or capability |
| Update trust | Signature verification, trusted keys, authenticated metadata, target compatibility | A harmless unauthorized artifact crosses the actual acceptance boundary |
| Rollback | Version counters, signed old images and recovery paths | An allowed attacker can restore a vulnerable security state |
| Boot chain | ROM-to-bootloader-to-application verification and recovery trust | A gap in the claimed chain under the eligible access model |
| Secrets | Per-device versus shared keys, credentials, debug logs and persistent storage | Protected capability established without publishing usable secrets |
| Debug interfaces | UART console, JTAG/SWD, test modes and privilege separation | Unexpected access on the production configuration |
| Local services | Authentication, authorization, command construction and configuration import | Reachable low-privilege input causes a protected operation |
| Memory safety | Length fields, parsers, allocation/free patterns and signedness | Minimized input, crash location, reachability and bounded consequence |
| Wireless | Pairing/bonding, identity, replay, sequencing and encrypted transport | Own-device controlled capture shows an authentication or integrity failure |
| Cloud/app coupling | Device claims, token scoping, ownership transfer and command routing | Reproduction only against separately authorized API/app assets |
| Recovery | Reboot, factory reset, watchdog and supported restore procedures | Device restored and test limitations documented |

Update transport encryption, update authentication and secure boot are separate checks. HTTPS can protect download transport while leaving a local update path insufficiently authenticated. A signed image may still be unsuitable for the model or permit a security downgrade. Examine what bytes and metadata are verified and what executes afterward. [ISTG firmware update mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)

Vendor details matter. On ESP32, Secure Boot v2 support depends on chip revision, and Espressif documents interactions with JTAG and flash encryption. Its security guidance separately describes anti-rollback controls. Do not infer the presence or absence of a production control from a generic SoC feature list; inspect the target configuration and matching vendor documentation. [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html), [Security overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html)

Classify discovered secrets before testing them: public certificate, local password hash, per-device private key, shared fleet credential or build-time sample. Demonstrating a secret’s role on an owned lab device is stronger than indiscriminate credential trials against cloud endpoints. For storage, distinguish attacker-accessible contents from intended administrator/debug access; note encryption-key placement, deletion behavior and residual data after reset. [ISTG installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md), [ISTG memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md)

Internal interfaces deserve their own boundary assessment. A UART that prints boot diagnostics differs from an unauthenticated privileged console; accessible JTAG differs from a demonstrated ability to extract protected secrets. Record physical effort and whether opening the case is required. Radio observations likewise differ from active tests: perform replay or malformed-message experiments only between owned devices in a controlled setup, and evaluate pairing and message authentication in the relevant protocol. [ISTG internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md), [ISTG wireless interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md)




## Module-level completion checks

Every [reusable module](#page-modules) contains its own checkable completion criteria alongside the procedure and commands. Use these after the master preflight. Mark blocked and inapplicable cases with reasons in the coverage record.


---

<a id="page-cheat-sheet"></a>

# Cheat sheet

Quick reference for decisions, evidence and commands. Every command inherits its branch's prerequisites. Values such as `YOUR_OWN_BUCKET`, `./repo`, and loopback addresses are examples for controlled environments; do not replace them with an inventory of unreviewed targets.

## The five-line hunt record

```text
Scope: exact asset/version + policy + environment + permitted action
Hypothesis: starting actor can violate this specific boundary
Control: legitimate operation + expected denied operation
Evidence: request/input + response/state + identity + version + timestamp
Result: confirmed / disproved / blocked / next test
```

## Report thresholds

| Observation | Still missing before promoting it |
|---|---|
| SAST match | Reachable source-to-sink path, effective guards, attacker control and consequence |
| Dependency advisory | Affected deployed version, relevant feature/API and exploitable conditions |
| Secret-looking string | Credible secret type, exposure path, owner context, redacted evidence; no default credential use |
| Different HTTP response | Proof of unauthorized data or action, with valid baseline |
| Public storage/signing URL | Unintended exposure or unauthorized issuance, not intended sharing alone |
| SSRF callback | Security consequence beyond intended fetching; callback alone proves only reachability |
| Missing pinning/hardening flag | Program-accepted threat model and a security consequence |
| Local crash | Target root cause, minimal reproducer, eligible build, security relevance and exposure |
| AI instruction following | Unauthorized data/tool/action boundary and actual execution evidence |
| Smart-contract discrepancy | Violated accepted invariant, exact scoped deployment, runnable local proof |
| Firmware secret/debug interface | Intended trust boundary, physical access assumptions, affected revision and concrete impact |

## Scope traps

| Tempting shortcut | Correct decision |
|---|---|
| “It is in certificate transparency.” | Discovery lead only |
| “It belongs to the same brand.” | Verify ownership and exact policy |
| “The parent domain is listed.” | Verify wildcard/apex/path/port semantics |
| “The app calls this API.” | Check the API's independent inclusion |
| “The repo is public.” | Code access does not authorize deployment testing |
| “It runs on my cloud account.” | Provider rules still apply; isolate other identities/resources |
| “The redirect stayed on the same host.” | Port and path may still have left scope |
| “A scanner marked critical.” | Validate exploitability and apply the program's rubric |
| “I have a CVE.” | Disclosure identity, payment, severity and acceptance remain distinct |

## Tool selection by task

| Task | Starting tools | What they do not establish |
|---|---|---|
| Source navigation | Git, ripgrep, language server, debugger | Product reachability or vulnerability on their own |
| Static analysis | Semgrep, CodeQL where licensed | Complete business-logic or framework coverage |
| Secrets | Gitleaks | Credential validity, ownership or permission to use |
| Dependencies / SBOM | OSV-Scanner, Syft, Trivy | Exploitable application use |
| HTTP/manual API | Browser tools, Burp or ZAP, curl | Intentional versus broken authorization without a control |
| Scoped discovery/probing | Subfinder, ProjectDiscovery httpx | Permission for candidates, redirects or discovered services |
| Mobile | adb, JADX, apktool, platform tooling, permitted instrumentation | Release exploitation from a modified test build |
| Desktop / native | Platform debugger, signing/ACL tools, parser harness | Privilege crossing from a crash alone |
| Cloud / Kubernetes | Official provider CLIs, kubectl, policy exports | Full effective security posture from one command |
| AI | Source search, synthetic fixtures, retrieval/tool audit logs | Security impact from a changed answer alone |
| Web3 | Foundry, Slither, ecosystem-specific tools | Non-EVM or economic correctness from Solidity warnings |
| Hardware / firmware | Vendor tooling, file/hash/readelf/strings, isolated emulation | Runtime impact from a suspicious extracted string |

Tool references and installation links are supplied in each branch's official documentation. Prefer pinned releases and recorded checksums. Prepare scanners and dependency databases before confidential analysis; network-disabled execution requires prepared local inputs. Building an untrusted repo, initializing a toolchain, opening a project in an IDE, or loading a model can execute code even when no exploit test has started.

## Command reference by scope

The following sections collect the documented examples from the technical playbooks, including their prerequisites and caveats. Commands were reviewed against references, not run against live targets. Check `--help` and the installed release before use; an unknown flag is an execution failure, not a reason to silently remove a safety constraint.

## OSS & self-hosted

[Context and complete playbook](#page-oss).

Examples target only an existing local `./repo`; they have not been executed against a target. Create `./evidence` first and keep it outside the scan root. Preinstall pinned tool versions, inspect inherited configurations, and prepare required rules/databases/packs in a separate connected preparation phase. Run private-code analysis with network egress blocked. Scanner exit codes can represent findings or execution failures; preserve stderr and classify the outcome before interpreting the report.

**1. Freeze the source identity.** [Git reference](https://git-scm.com/docs/git-rev-parse).

```bash
git -C ./repo rev-parse --verify HEAD > ./evidence/commit.txt
```

**2. Inventory source and hidden configuration without reading Git objects.** [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md).

```bash
rg --files --hidden -g '!.git' ./repo > ./evidence/files.txt
```

**3. Run reviewed local Semgrep rules.** No registry rules are fetched by this command. [Semgrep CLI](https://docs.semgrep.dev/cli-reference).

```bash
semgrep scan --oss-only --config ./rules --metrics=off \
  --disable-version-check --sarif \
  --output ./evidence/semgrep.sarif ./repo
```

The CE engine uses LGPL-2.1; Semgrep-maintained registry rules have a separate Semgrep Rules License, and third-party rules have their own licenses. Internal research and embedding rules into a commercial scanning service are different uses. Prefer original local rules or rules whose terms fit the intended use. [Semgrep licensing](https://docs.semgrep.dev/licensing), [Rules License](https://semgrep.dev/legal/rules-license/).

**4. Review local Git history for secrets.** A shallow clone limits historical coverage. Inspect the output before sharing. [Gitleaks](https://github.com/gitleaks/gitleaks).

```bash
gitleaks git ./repo --redact=100 --report-format json \
  --report-path ./evidence/gitleaks.json
```

**5. Inventory local packages.** [Syft output formats](https://oss.anchore.com/docs/guides/sbom/formats/).

```bash
syft dir:./repo -o cyclonedx-json=./evidence/sbom.cdx.json
```

**6. Match dependencies using previously cached OSV ecosystem databases.** Full `--offline` prevents network use; `--offline-vulnerabilities` alone still permits other network features. Offline mode lacks commit-level matching. [OSV source scanning](https://google.github.io/osv-scanner/usage/scan-source), [offline mode](https://google.github.io/osv-scanner/usage/offline-mode/).

```bash
osv-scanner scan source --offline -r --format json \
  ./repo > ./evidence/osv.json
```

**7. Inspect dependencies and IaC with prepared Trivy databases/checks.** These flags independently disable online resolution, updates, notices, and telemetry. Missing caches or unsupported flags on older releases require preparation/version correction, not silent fallback to online scanning. [Trivy filesystem CLI](https://trivy.dev/docs/latest/references/configuration/cli/trivy_filesystem/).

```bash
trivy fs --scanners vuln,misconfig --offline-scan \
  --skip-db-update --skip-java-db-update --skip-check-update \
  --skip-version-check --disable-telemetry \
  --format json --output ./evidence/trivy.json ./repo
```

**8. Create and query a Python CodeQL database.** Requires a prepared local query suite and its dependencies; language/build setup differs for other projects. [Database preparation](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/prepare-code-for-analysis), [analysis](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/analyze-code).

```bash
codeql database create ./evidence/codeql-python \
  --language=python --source-root=./repo
codeql database analyze ./evidence/codeql-python \
  ./queries/python-security.qls --format=sarif-latest \
  --output=./evidence/codeql.sarif
```

CodeQL is free for public repositories under its terms. Private organization repositories require the applicable GitHub plan and GitHub Code Security license; possession of source does not grant unrestricted CodeQL use. The query libraries' open-source license does not replace the CLI terms. [GitHub: CodeQL availability and license](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-cli).



## Web & API

[Context and complete playbook](#page-web-api).

**Pass 1 — third-party discovery.** Read program documentation, public API references, repository references, certificate-transparency results, historical URL indexes, and already collected search-engine/network-index records. Save source and collection time; stale records are leads. Searching an existing Shodan/Censys record is different from requesting a fresh scan. Third-party discovery can disclose the target name to a provider even when it does not probe the target.

**Pass 2 — allowlist review.** Resolve candidates into exact permitted origins/resources. Do not pipe passive output directly into a scanner. Retain excluded and uncertain candidates in a review queue. Separate broad wildcard inventory from a single-app campaign: the latter needs route and workflow discovery more than another million hostnames.

**Pass 3 — active validation.** DNS resolution is a network operation and recursive resolution may reach authoritative infrastructure. HTTP requests, TLS handshakes, screenshots, crawling, directory discovery, port scans, DNS brute force, and vulnerability checks are active. Use the program's identification header and rate limit. If no rate is specified, begin manually; a conservative automation starting point is one worker and at most one request/second, only where automation is permitted. This is a proposed budget, not a universal authorization.

**Pass 4 — application mapping.** Exercise normal workflows through an intercepting proxy. Inventory method, path, operation name, object IDs, role, tenant, side effects, upload/download behavior, integrations, and request source. Compare UI traffic with OpenAPI schemas, SDKs, JavaScript and source maps. Old versions, undocumented operations, export jobs and background tasks become hypotheses, not automatic findings.

```bash
# Third-party discovery only: do not add -active/-nW.
# Review installed config and available provider credentials first.
subfinder -d example.com -silent -o candidates.txt

# Human-reviewed file: exact URLs, explicit schemes and permitted ports.
# Use a reviewed empty YAML config to prevent inherited scan options.
httpx -config scope-httpx.yaml -l approved-origins.txt \
  -nfs -sc -title -location -json -threads 1 -rate-limit 1 \
  -retries 0 -timeout 10 -disable-update-check -o inventory.jsonl

# Single approved URL; -q first ignores inherited curlrc options.
# No -L/--location: inspect any Location before a separate request.
curl -q --proto '=https' --connect-timeout 5 --max-time 15 \
  --dump-header evidence/headers.txt --output evidence/body.txt \
  'https://app.example.com/approved-path'
```

`scope-httpx.yaml` should contain `{}`; `evidence/` must already exist. These commands assume tools are installed. `httpx` here means ProjectDiscovery's binary. Its `-nfs` preserves the input scheme; `-nf` has different behavior. Omit redirect-following, screenshot, TLS-domain, CSP-domain, favicon, additional-port, and extra-path probing flags. `-fhr` limits redirects to the same host, **not** to the same port/path. `-allow/-deny` are IP/CIDR controls, not URL scope enforcement. For exact-path scope, prefer a reviewed single request until client behavior is confirmed. [Subfinder usage](https://docs.projectdiscovery.io/opensource/subfinder/usage), [httpx usage](https://docs.projectdiscovery.io/opensource/httpx/usage), [curl manual](https://curl.se/docs/manpage.html).

Automated vulnerability checks come after mapping. Review each selected template's requests, methods, payload count, redirects, extracted targets, code/headless behavior, callbacks and cleanup. A severity label is not a safety classification. A low rate does not make a destructive request safe. Do not use “run all templates” as a discovery stage.


Use the dedicated [Network services playbook](#page-network) for the full DNS, TLS, email, database, queue, VPN and appliance workflow.

Only use this branch when the service/IP/port is covered. A website scope does not automatically authorize its hosting provider's network. An open port identifies a reachable service, not a vulnerability; an observed version can be backported, masked or misidentified. Nmap service detection sends protocol probes and can have side effects; even its documentation excludes printer port 9100 by default for that reason. Select individual services before deeper interrogation. [Nmap port states](https://nmap.org/book/man-port-scanning-basics.html), [Nmap version detection](https://nmap.org/book/man-version-detection.html).

For DNS, inspect A/AAAA/CNAME/NS/MX/TXT relationships. Public DNS lookups differ from passive historical DNS searches. A dangling CNAME is evidence of a configuration lead, not proof that the referenced resource is claimable. Resource claiming can change production routing; obtain the program-approved proof method before registration. Zone transfer, dynamic updates, recursion abuse and amplification testing require a specific allowed branch.

For TLS, connect using the intended SNI and verify the intended hostname; a wrong default certificate from an IP-only connection may simply reflect virtual hosting. Certificate SANs provide candidates, not added scope. Avoid treating a scanner's “old cipher” label as meaningful impact without the program's eligibility criteria. [OWASP TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html).

```bash
# Active DNS queries; only after the applicable discovery gate.
dig +time=2 +tries=1 app.example.com A
dig +time=2 +tries=1 app.example.com AAAA

# Active handshake to an approved hostname and port.
timeout 15 openssl s_client -connect app.example.com:443 \
  -servername app.example.com -verify_hostname app.example.com \
  -verify_return_error -brief </dev/null
```

The DNS and TLS commands use their official documented query/connection options. Hostname verification and SNI are separate controls. [BIND manual](https://bind9.readthedocs.io/en/latest/manpages.html), [OpenSSL s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/).

For SMTP/IMAP, distinguish the domain's mail configuration from an authorized mail-server service. Review SPF/DKIM/DMARC findings against program exclusions and actual spoofing/identity impact. Any relay or delivery test needs explicit scope and researcher-controlled mailboxes; do not send messages to staff to prove delivery. An MX pointing to a provider does not authorize that provider. For SSH, databases, queues, object stores and administration panels, start with service identity and authentication requirements; never jump from a banner to default-password spraying or reading datasets.



## Network services

[Context and complete playbook](#page-network).

Replace these documentation addresses only with approved assets. Here `192.0.2.53` is an authorized DNS server and `192.0.2.10` an explicitly approved host. Run commands individually; inspect each result before continuing. No default broad scans, NSE script sets, OS detection, traceroute or version detection are enabled.

```bash
# 1. One UDP SOA query to an approved authoritative server.
dig -r @192.0.2.53 example.com SOA \
  +norecurse +notcp +ignore +time=2 +tries=1

# 2. One AAAA lookup; still uses IPv4 transport to this DNS server.
dig -r @192.0.2.53 app.example.com AAAA \
  +norecurse +notcp +ignore +time=2 +tries=1

# 3. Inspect the domain's published DMARC record.
dig -r @192.0.2.53 _dmarc.example.com TXT \
  +norecurse +notcp +ignore +time=2 +tries=1

# 4. TLS handshake with the intended SNI and certificate identity.
timeout 15 openssl s_client -connect app.example.com:443 \
  -servername app.example.com -verify_hostname app.example.com \
  -verify_return_error -brief </dev/null

# 5. SMTP STARTTLS negotiation only: no AUTH or message delivery.
timeout 15 openssl s_client -starttls smtp \
  -connect mail.example.com:587 -servername mail.example.com \
  -verify_hostname mail.example.com -verify_return_error \
  -brief </dev/null

# 6. Explicitly approved TCP ports on one approved IPv4 address.
nmap -sT -Pn -n --disable-arp-ping -p 22,443 \
  --max-rate 1 --scan-delay 1s --max-parallelism 1 \
  --max-retries 0 --host-timeout 30s \
  -oX network-one.xml 192.0.2.10
```

`dig -r` ignores inherited `.digrc` options; `+ignore` prevents automatic TCP fallback after a truncated UDP response. A truncated answer is incomplete, so request TCP separately only if allowed. `+norecurse` suits a known authoritative server; a referral is not a complete answer. Use record types A, CNAME, NS, MX, SPF TXT or a **known** DKIM selector only as separately reviewed queries. [BIND 9.20.13 dig manual](https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility).

SNI selects a virtual TLS service; hostname verification checks identity. OpenSSL's STARTTLS option performs the protocol negotiation needed before TLS. A successful handshake does not test authentication or mail delivery. [OpenSSL s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/).

Nmap `-p` overrides its default port set, and `-Pn` skips ordinary host discovery that could touch additional ports. `-n` avoids reverse DNS. Scan timing options do not constitute a hard limit on every kernel-generated packet. For separately authorized IPv6 testing, use `-6` and the exact approved IPv6 address. Do not append `-sV`: version detection introduces additional protocol probes and potential side effects. [Nmap port selection](https://nmap.org/book/man-port-specification.html), [host discovery](https://nmap.org/book/man-host-discovery.html), [timing](https://nmap.org/book/man-performance.html), [IPv6](https://nmap.org/book/man-misc-options.html), [version detection](https://nmap.org/book/man-version-detection.html).



## Mobile

[Context and complete playbook](#page-mobile).

Run these against owned lab devices and local artifacts. The commands inspect metadata or write analysis copies; they do not test discovered Internet hosts. Replace identifiers and paths deliberately. Android commands require the indicated SDK tools on `PATH`; JADX and Apktool require their supported Java runtime. [ADB](https://developer.android.com/tools/adb), [APK Analyzer](https://developer.android.com/tools/apkanalyzer), [APK signer](https://developer.android.com/tools/apksigner), [JADX CLI](https://github.com/skylot/jadx), [Apktool CLI](https://apktool.org/docs/cli-parameters/).

```bash
# Android: choose one owned device when more than one is attached.
adb devices -l
adb -s DEVICE_SERIAL shell pm path com.example.lab
adb -s DEVICE_SERIAL shell dumpsys package com.example.lab
apkanalyzer apk summary ./app.apk
apkanalyzer manifest print ./app.apk
apkanalyzer manifest permissions ./app.apk
apksigner verify --verbose --print-certs ./app.apk
jadx -d ./analysis-jadx ./app.apk
apktool d ./app.apk -o ./analysis-apktool
```

On macOS, inspect a locally acquired/extracted app without modifying its signature. `codesign` applies to both iOS bundles and macOS applications, but entitlements and runtime enforcement differ. Check installed `man plutil` / `man codesign` when tooling differs. [OWASP Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/), [OWASP entitlement extraction](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/).

```bash
plutil -p ./Payload/Lab.app/Info.plist
codesign -dv --verbose=4 ./Payload/Lab.app
codesign -d --entitlements :- ./Payload/Lab.app
```



## Desktop & extensions

[Context and complete playbook](#page-desktop).

These are local inspection examples. Paths refer to lab copies. A successful signature check establishes signature validity under the tool’s rules, not absence of vulnerabilities. PowerShell Authenticode inspection is Windows-specific; Apple commands require macOS. [Microsoft Authenticode](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5), [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls), [Apple signature verification](https://developer.apple.com/library/archive/technotes/tn2206/_index.html), [GNU readelf](https://sourceware.org/binutils/docs/binutils/readelf.html).

```powershell
# Windows / PowerShell: inspection only.
Get-AuthenticodeSignature -FilePath 'C:\Lab\App.exe' | Format-List
icacls 'C:\Lab\App.exe'
icacls 'C:\Program Files\ExampleApp'
```

```bash
# macOS: inspect a lab copy; do not re-sign it for the baseline.
plutil -p ./Example.app/Contents/Info.plist
codesign -dv --verbose=4 ./Example.app
codesign -d --entitlements :- ./Example.app
codesign --verify --deep --strict --verbose=2 ./Example.app

# Linux or another host with GNU binutils: read ELF metadata without execution.
readelf -hW ./lab-app
readelf -lW ./lab-app
readelf -dW ./lab-app

# Search local source/extracted JavaScript; matches are investigation leads.
rg -n 'ipcMain|contextBridge|nodeIntegration|contextIsolation|openExternal' ./source
rg -n 'onMessage|externally_connectable|host_permissions|nativeMessaging' ./extension
```

For an already prepared AFL++ lab, first inspect `afl-fuzz -h`. A campaign skeleton is `afl-fuzz -i ./seeds -o ./fuzz-results -- ./parser-harness @@`; `@@` supplies the current input filename. It runs until stopped unless bounded by supported runtime options. Configure limits before starting, and interrupt with Ctrl-C. The harness must avoid network calls, production credentials, and side effects outside the disposable lab. [AFL++ execution and resource guidance](https://aflplus.plus/docs/fuzzing_in_depth/).



## Cloud & containers

[Context and complete playbook](#page-cloud).

Use installed official CLIs, your own configured lab credentials and the literal approved IDs. These eight commands read configuration or perform local validation; none grants permission to broaden scope. Do not substitute credentials found in a repository. Protect output files because policies and identities can be confidential.

```bash
# 1. Confirm the AWS principal; no secret value is printed.
aws --profile bounty-lab sts get-caller-identity --output json --no-cli-pager

# 2. Inspect one owned general-purpose bucket's policy status.
aws --profile bounty-lab s3api get-bucket-policy-status \
  --bucket YOUR_OWN_BUCKET --expected-bucket-owner YOUR_ACCOUNT_ID \
  --output json --no-cli-pager

# 3. Confirm Azure's selected subscription and tenant.
az account show --query '{subscription:id,tenant:tenantId,user:user.name}' -o json

# 4. Read the policy attached to one owned GCP project.
gcloud projects get-iam-policy YOUR_OWN_PROJECT_ID --format=json

# 5. Ask permission without reading the canary Secret.
kubectl --context bounty-lab -n tenant-a auth can-i get secrets/bounty-canary

# 6. Review only the owned namespace's configuration.
kubectl --context bounty-lab -n tenant-a get roles,rolebindings,networkpolicies -o json

# 7. Inspect a local image without executing its entrypoint.
docker image inspect YOUR_LOCAL_IMAGE --format '{{.Id}} {{json .Config.User}}'

# 8. Validate a trusted, already-initialized local Terraform module.
terraform -chdir=./owned-lab-iac validate -json
```

Command references: [AWS identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html), [bucket status](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-policy-status.html), [Azure account](https://learn.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest), [GCP policy](https://docs.cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy), [kubectl permission query](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/), [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), [Docker inspect](https://docs.docker.com/reference/cli/docker/image/inspect/), [Terraform validate](https://developer.hashicorp.com/terraform/cli/commands/validate).

Interpret results narrowly: bucket policy status is not a complete audit of all object-access paths; a GCP project policy does not enumerate every inherited control; `can-i` evaluates authorization, not admission or exploitability; `terraform validate` checks configuration validity, not security. Terraform may invoke installed provider plugins, so “local” does not mean safe for an untrusted repository.



## AI, agents & MCP

[Context and complete playbook](#page-ai).

These six commands are static/local inspection or protocol discovery against an owned fixture. Use a trusted Python 3.11+ interpreter for `file_digest`; isolated mode and disabled site initialization prevent imports from the working directory and site customizations. No model or repository code is executed by the first four. Local HTTP examples assume your intentionally unauthenticated loopback fixture; for an authenticated fixture, use its documented lab credentials. Inventory results do not establish tool-call authorization.

```bash
# 1. Find loader and execution sinks in a local source checkout.
rg -n 'trust_remote_code|torch\.load|pickle\.loads?|subprocess|shell=True' ./repo

# 2. Fingerprint one local weight artifact without loading the model.
python3 -I -S -c 'import hashlib; f=open("./model/model.safetensors","rb"); print(hashlib.file_digest(f,"sha256").hexdigest())'

# 3. Inspect JSON model configuration without importing custom model code.
python3 -I -S -m json.tool ./model/config.json

# 4. Generate a synthetic marker for your private test document.
python3 -I -S -c 'import secrets; print("B_PRIVATE_" + secrets.token_hex(16))'

# 5. Discover a local MCP server implementing the 2026-07-28 protocol.
curl -q --noproxy '*' --proto '=http' --silent --show-error --max-time 10 http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' -H 'Mcp-Method: server/discover' \
  --data '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{},"io.modelcontextprotocol/clientInfo":{"name":"bounty-lab","version":"1.0"}}}}'

# 6. List tool schemas, without calling a tool, on the same modern fixture.
curl -q --noproxy '*' --proto '=http' --silent --show-error --max-time 10 http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' -H 'Mcp-Method: tools/list' \
  --data '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{},"io.modelcontextprotocol/clientInfo":{"name":"bounty-lab","version":"1.0"}}}}'
```

References for command semantics: [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md), [Python hashlib](https://docs.python.org/3/library/hashlib.html), [Python JSON](https://docs.python.org/3/library/json.html), [Python secrets](https://docs.python.org/3/library/secrets.html), [MCP changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog), [MCP HTTP binding](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), [MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools). Syntax was checked against documentation; these examples were not run against a live target.



## Web3 & protocols

[Context and complete playbook](#page-web3).

Run these from an isolated, reviewed local checkout with its required dependencies. `CHAIN_RPC_URL` is the permitted read-only state provider and `FORK_BLOCK` is a recorded decimal block number. Commands are examples of documented syntax, not a universal installer or completed PoC.

```bash
git rev-parse HEAD
forge --version
slither --version
forge build
slither . --json slither.json
forge test --match-test '^test_PoC$' \
  --fork-url "$CHAIN_RPC_URL" \
  --fork-block-number "$FORK_BLOCK" -vvvv
forge test --match-test '^invariant_' \
  --fork-url "$CHAIN_RPC_URL" \
  --fork-block-number "$FORK_BLOCK"
```

`test_PoC` and `invariant_*` are harness functions you implement; they are not built-in vulnerability checks. Preserve the harness, minimized inputs, dependency lock state and traces. Review untrusted build scripts before execution. [Foundry testing](https://www.getfoundry.sh/forge/testing), [Forge test reference](https://www.getfoundry.sh/reference/forge/test), [Slither usage](https://github.com/crytic/slither/wiki/Usage)

**Submission gate:** correct eligible deployment; realistic attacker; reproducible local fork; necessary privileges disclosed; precise impact category; bounded loss; known issues checked; private reporting channel used; no real funds moved. Read the current PoC requirements linked by the program before submitting; a toy reimplementation can explain the idea but does not establish deployed impact.



## Hardware & firmware

[Context and complete playbook](#page-hardware).

Use an offline copy of a vendor image in an isolated non-root analysis environment. These commands inspect local files; they do not acquire firmware from an unknown device or authorize testing any embedded endpoint.

```bash
mkdir -p evidence
sha256sum firmware.bin > evidence/firmware.sha256
file firmware.bin > evidence/firmware-type.txt
binwalk firmware.bin > evidence/firmware-layout.txt
strings -a -n 8 firmware.bin > evidence/firmware-strings.txt

# After an appropriate extractor has produced an owned local filesystem:
rg --files extracted-rootfs > evidence/file-inventory.txt
rg -n -i 'password|token|private.key|update|signature' \
  extracted-rootfs > evidence/review-leads.txt

# For an identified ELF binary, not for every firmware format:
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
```

Select the extractor for the detected format, verify its current syntax and inspect archive contents before extraction. Keep unknown images away from host mounts and privileged analysis processes. Binwalk identifies embedded content and can support extraction workflows; high entropy alone does not distinguish encryption from compression. The `rg` matches above are review leads, not confirmed credentials or findings. [Binwalk](https://github.com/ReFirmLabs/binwalk), [OWASP FSTM](https://github.com/scriptingxss/owasp-fstm)

**Evidence bundle:** product/revision photo with unnecessary identifiers redacted; firmware and extracted-file hashes; access model; wiring/interface notes where applicable; synthetic account roles; minimal input; serial or packet logs; observed versus expected behavior; reproducibility count; device recovery status; and exact affected versions. Include proof that emulation assumptions also hold on the claimed product, or clearly limit the claim to the emulated component.




## Search commands by tool or boundary

The [command workbench](#page-commands) adds filterable snippets from every detailed module. Each snippet links to the canonical setup, expected result, and checklist.


---

<a id="page-templates"></a>

# Working templates

Copy these into a private per-target workspace. They are records, not executable authorization policies. Use the program's required report fields where they differ. Store credentials separately; the records use identity references and redacted evidence paths.

## Scope record

```yaml
program:
  name: example-program
  policy_url: https://example.com/security/policy
  policy_checked_at: YYYY-MM-DDTHH:MM:SSZ
  policy_snapshot_sha256: REPLACE_WITH_ACTUAL_HASH
  intake_status: needs_review
  participation: public_or_invited
  enrollment_verified: false
  reward_eligibility: unknown
  disclosure_terms_reference: REPLACE

asset:
  kind: exact_url
  identifier: https://app.example.com:443/api/v1/export
  repository_commit_or_artifact_hash: null
  environment: designated_test_tenant
  ownership_evidence: REPLACE
  included_by: REPLACE_WITH_EXACT_POLICY_RULE
  exclusions_reviewed: false
  third_party_dependencies: []

activity:
  intended_method: controlled_authorization_comparison
  permitted_methods_reference: REPLACE
  identities: [owned_tenant_a_member, owned_tenant_b_member]
  data: synthetic_canaries_only
  rate_limit_from_policy: null
  internal_request_budget: null
  concurrency_limit_from_policy: null
  callback_destinations: []
  redirects_require_revalidation: true
  test_window: null
  stop_conditions: [scope_change, service_degradation, unexpected_sensitive_data]

decision:
  status: needs_review
  reason: no_active_testing_until_completed
  approved_actions: []
  reviewed_by: REPLACE
  recheck_on: [new_session, policy_change, ownership_change, new_destination]
```

Null limits and an empty approval list mean **unresolved**, not unlimited. A scope engine needs explicit logic for every asset type; this template deliberately does not pretend that a YAML list is sufficient enforcement.

## Hypothesis card

```text
ID:
Asset and version:
Policy/action reference:
Starting actor and controlled input:
Legitimate workflow:
Expected security invariant:
Suspected missing guard:
Test fixture and reset:
Baseline successful operation:
Baseline prohibited operation:
Smallest proposed test:
Expected evidence if true:
Evidence that would disprove it:
Request/time/cost budget:
Stop condition:
Actual observations:
Demonstrated impact:
Unproven implications:
Status:
Next action:
```

## Coverage record

```csv
asset,version,entry_point,actor,resource_owner,action,state,boundary,status,evidence,limitation
local-fixture,COMMIT,/exports,tenant_a_member,tenant_b,read,private,tenant,untested,,awaiting_baseline
```

Use `untested`, `passed`, `finding`, `blocked`, or `not_applicable`. “Passed” means a specific test did not break the expected rule under recorded conditions. It is not a claim that the entire feature is secure. For client and hardware targets, replace endpoint-oriented columns with the relevant IPC method, parser entry point, physical interface, or update stage.

Include stable references when using the manual as a reusable testing system:

```yaml
coverage_item:
  id: COV-001
  module_ids: [authz-matrix]
  vulnerability_family_ids: [bola-controlled-object-access]
  asset_ref: exact-approved-asset
  entry_point: POST_/exports
  boundary: tenant_and_document_ownership
  baseline_evidence: evidence/baseline-redacted.txt
  negative_control_evidence: evidence/control-redacted.txt
  result: untested
  observed_at: null
  tool_and_config_ref: null
  limitations: [worker_retrieval_not_yet_tested]
  next_action: observe_the_export_worker_under_two_owned_tenants
```

`module_ids` and vulnerability-family IDs are navigation references, not proof of test execution or final CWE classification. Record the assessed root cause and any conditional ATT&CK behavior separately after validation.

## Retest matrix

```csv
finding_ref,fixed_version,case,expected,actual,evidence,status
REPORT-001,FIXED_COMMIT,original_reproduction,deny_without_side_effect,,,untested
REPORT-001,FIXED_COMMIT,legitimate_control,allowed_operation_still_works,,,untested
REPORT-001,FIXED_COMMIT,shared_guard_variant,record_intended_rule,,,untested
REPORT-001,FIXED_COMMIT,queued_or_cached_result,record_lifecycle_semantics,,,untested
```

Keep the vulnerable and fixed environment manifests. Record whether a result depends on token renewal, a cache reset, delayed job completion, a client restart, or a newly issued artifact. Use `not_applicable` with a reason when a listed case has no corresponding surface.

## Normalized evidence record

```json
{
  "record_type": "observation",
  "schema_version": 1,
  "program_ref": "private-local-reference",
  "asset_ref": "exact-approved-asset",
  "policy_snapshot_ref": "policy-sha256",
  "hypothesis_id": "H-001",
  "observed_at": "YYYY-MM-DDTHH:MM:SSZ",
  "tool": {"name": "manual", "version": "record_actual_version"},
  "environment": {"build": "actual-build", "principal_ref": "test-a"},
  "evidence": [{"path": "evidence/redacted-response.txt", "sha256": "actual-hash"}],
  "outcome": "needs-validation",
  "demonstrated_impact": null,
  "limitations": ["not_reproduced_after_reset"],
  "confidentiality": "program-private"
}
```

Keep raw tool output and the normalized observation together. Do not discard stderr, request ordering, source path, or configuration needed to explain a result. Deduplicate on root cause and affected boundary; a shared scanner rule ID alone is not a sound duplicate key.

## Reproducible report

```text
Title
[Starting actor] can [unauthorized action] on [resource] through [root cause]

Summary
Describe the actual boundary violation and demonstrated consequence in 2–4 sentences.

Affected asset and versions
Exact URL/repo/package/app/contract/device identity, tested release/commit/hash.
Separate tested affected versions from inferred ranges.

Preconditions
Starting account/role, owned tenants/data, supported configuration, build and setup.

Steps to reproduce
1. Reset/setup the controlled fixture.
2. Establish the normal successful and denied behaviors.
3. Perform the minimal candidate operation.
4. Verify the resulting synthetic data or state.

Expected behavior
The documented or clearly intended security invariant.

Actual behavior
The observed result, with evidence references and relevant timestamps.

Impact
What the attacker demonstrably gains; clearly label additional inferred consequences.

Evidence
Minimal requests/inputs, responses/state, logs, artifact hashes, source path and PoC.
Redact tokens and irrelevant private data.

Severity
Required program rubric; CVSS version/vector if applicable; assumptions explained.

Root cause and remediation suggestion
Relevant guard or trust decision; a focused correction where known.

Cleanup and disclosure
Actions taken, test records remaining, confidential coordination preferences.
```

## OSS lab manifest

```text
Repository URL:
Source commit and tag:
Product edition:
Artifact/image digest:
OS/architecture/runtime:
Dependency lockfile hash:
Build command and trusted toolchain versions:
Network access required during setup:
Configuration delta from documented default:
Test users and synthetic objects:
Reachable public interface:
Exact local reproduction:
Expected and observed result:
Reset and teardown:
Affected/fixed version evidence:
```

## AI trial record

```text
Product/model/runtime version:
Legitimate user task:
Attacker-controlled surface:
Private synthetic marker location:
Confirmation that marker is absent from attacker input:
Caller identity and available tools:
Applicable tool permissions and approval requirement:
Prompt/input and retrieved artifact hashes:
Sampling settings and session reset:
Baseline trials:
Candidate trials:
Successful boundary violations / total trials:
Actual retrieval/tool audit event:
Attacker-visible result:
Unproven broader impact:
```

## Web3 and device addenda

| Web3 report fields | Hardware/device report fields |
|---|---|
| Chain ID, deployed and implementation addresses | Model, board revision, firmware/build, artifact hash |
| Pinned fork block and corresponding source commit | Physical access and starting privilege |
| Accepted impact category and invariant | Interface and documented trust expectation |
| Controlled principals and setup transactions | Lab wiring, voltage assumptions, isolation and recovery |
| Before/after balances or other state | Before/after state, trace or captured local output |
| Deterministic runnable local test | Repeatable non-destructive reproduction |
| Economic/liquidity/oracle assumptions | Limitations of emulation or modified/debug firmware |

## End-of-session note

```text
Resolved today:
Best remaining hypothesis:
Exact next file/function/request:
Access or policy blocker:
Evidence saved:
Cleanup due:
Reason to continue or rotate:
```


---

<a id="page-review"></a>

# Review and updates

**Content review: 14 September 2026.** The review covered the existing chapters, all 31 original shared procedures, and all 119 original vulnerability cards. It checked missing test paths, technical accuracy, evidence thresholds, duplication, command defaults, taxonomy and selected current policies. The revised manual contains **40 shared procedures and 140 vulnerability families**.

This is a review of the manual, not a security assessment of the hostnames in the uploaded inventory. Commands remain documentation-reviewed examples. No target testing was performed, and a catalog entry does not mean that a vulnerability exists on a target.

## Nine new shared procedures

Each addition includes prerequisites, a workflow, a command or inspection recipe, expected evidence, false-positive controls and completion checks. Canonical procedures are embedded in applicable playbooks, with reciprocal links from vulnerability cards.

| Added procedure | Gap it closes |
| --- | --- |
| [MFA and passkey lifecycle](#page-modules-authenticator-lifecycle) | Factor enrollment, replacement, recovery, one-time proof consumption and WebAuthn ceremony binding. |
| [Federation and token trust](#page-modules-federation-token-trust) | OAuth/OIDC/SAML transaction binding, valid signatures with the wrong context, token purpose and refresh/replay handling. |
| [Request value parsing](#page-modules-request-value-parsing) | Duplicate parameters and JSON names, interpretation conflicts, and values injected into downstream requests. |
| [Webhook event integrity](#page-modules-webhook-event-integrity) | Signature verification, provider and tenant identity, duplicate delivery, ordering, and effects committed by workers. |
| [Resource budgets and sensitive flows](#page-modules-resource-budget-controls) | Request fan-out, queued work, retries, recipient limits, cost amplification and quota ownership. |
| [GitLab pipeline boundaries](#page-modules-gitlab-pipeline-boundaries) | Fork and parent-project trust, job-token permissions, downstream inputs and shared runner state. |
| [Azure and GCP boundaries](#page-modules-azure-gcp-boundaries) | Provider-specific identity, delegation and storage semantics beyond the existing AWS examples. |
| [Extension message boundaries](#page-modules-extension-message-boundaries) | Page-to-extension authority, browser-provided sender identity, document replacement and worker restarts. |
| [AI state lifecycle](#page-modules-ai-state-lifecycle) | Conversation and checkpoint ownership, persistent memory, resumed MCP requests, private caches and duplicate effects. |

The [vulnerability catalog](#page-vulnerabilities) adds **21 families** for these gaps and related client privacy/model-loading cases. Existing entries gain references to the new procedures; the catalog still does not claim to enumerate every possible vulnerability.

## Corrections and deeper coverage

- **Classify the demonstrated root cause.** The [mapping guide](#page-attack) now explains discouraged broad CWE entries, missing versus incorrect authorization, and the distinction between signature and token-context validation. Shell interpretation and shell-free argument injection have separate cards. CWE badges remain candidates, not automatic report assignments. [MITRE mapping guidance](https://cwe.mitre.org/documents/cwe_usage/guidance.html).
- **Preserve local command intent.** Loopback curl examples explicitly bypass inherited proxy variables. Fuzzer examples terminate on selected undefined behavior so a recoverable diagnostic is not mistaken for a saved crashing test. These changes improve reproducibility; they do not establish exploitability. [curl manual](https://curl.se/docs/manpage.html), [Clang UBSan](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).
- **Follow work beyond the first request.** Existing modules now cover stored input reaching later interpreters, archive links and extraction filters, cache revalidation, SSRF connection identity/retries, account merging, SSO/SCIM lifecycle, SSE cursors and gateway permission parity. Read the individual procedure for the applicable version and controls.
- **Complete the client and protocol context.** Added native authentication and privacy comparisons, LDAP/SMB/SSH interpretation, and contract-wallet signature controls. Repeated certificate-validation and update-verification prose was consolidated into one comparison per card.
- **Make coverage and retests concrete.** The [operating playbook](#page-operations) now varies actor, object, lifecycle, timing, representation, integrations and budget. [Templates](#page-templates) record original reproductions, legitimate neighboring behavior, shared guards and queued/cached state separately.
- **Keep downloads reusable.** Markdown exports now contain text, tables, checklists and intact code blocks instead of interactive page markup. The complete download includes the canonical procedures once and links between its chapters; individual downloads link back to the website.

## Policy and framework review

The [platform chapter](#page-platforms) adds submission-readiness checks, policy-change handling, broader Google product reporting routes and guidance for permitted historical Huntr records. It preserves distinctions between authorization, intake eligibility and possible payment.

The IBB funding pause is supported by the official Node.js notice. The direct IBB policy could not be reverified in this review, and some Google policy bodies remained inaccessible. Their limitations are stated beside the affected claims; no unavailable payout or eligibility rules were reconstructed. [Node.js notice](https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties).

All **24 listed Enterprise ATT&CK technique IDs, names and tactics** were checked against official MITRE references. The guide retains ATT&CK v19.2 terminology and evidence-dependent mappings. The new families have no automatic mapping merely because they are security weaknesses. [ATT&CK mapping guide](#page-attack), [MITRE versions](https://attack.mitre.org/resources/versions/).

## Dates, limitations and ongoing maintenance

Original chapters retain their **11 September 2026** research dates; the first expansion retains **12 September 2026**. This review adds **14 September 2026** context for selected source checks and changes. It does not claim that every linked page was freshly retrieved. Some GitHub-hosted hardware references could not be refreshed; the hardware procedures were read, with no material correction identified in this pass.

Before applying the manual, match the exact product version, configuration and scope. Protocol and provider procedures describe boundaries to investigate, not uniform behavior across all deployments. Product-specific workflows, new platforms and future vulnerabilities will require additional entries.

Use the [coverage record](#page-templates) to distinguish untested, passed, finding, blocked and not applicable. A checked checklist item records work reviewed, not proof that an entire vulnerability family is absent.


---

<a id="page-sources"></a>

# Sources and research notes

Primary documentation, program policies, maintainers’ publications and official tool references underpin this manual. Sources were accessed on **11 September 2026**. The working frameworks, milestones, priorities and test designs are analytical recommendations unless explicitly attributed to a program requirement.

## How to read the evidence

Program policy is time-sensitive. Check the exact asset, current intake, supported release, testing method, researcher eligibility and reward conditions before starting a new hunt. Undated documentation is a living reference, not a guarantee that an older deployment implements the same behavior. Archived Apple material is identified as historical; current MCP guidance is explicitly versioned.

Some Google OSS policy content was not fully extractable. The platform chapter marks this limitation and does not reconstruct missing reward tiers. Some OWASP pages failed to render; where available, citations use their official source repositories. No live targets were tested. Tool examples are documentation-reviewed recipes, not execution results. The uploaded all.txt supports only the local inventory counts stated in the scope chapter.

## Reference inventory

The sections below retain publishers, exact links, dates or versions, and claim context from the individual chapters. Some sources occur in more than one branch because they support different decisions.

## Roadmap

[Read the associated chapter](#page-roadmap).

- PortSwigger. [Web Security Academy](https://portswigger.net/web-security). Live training catalog; undated; accessed 11 September 2026. Used for the lab resource recommendation.
- OWASP Foundation. [Juice Shop](https://owasp.org/www-project-juice-shop/). Live project documentation; accessed 11 September 2026. Used for intentionally vulnerable application practice.
- OWASP Foundation. [crAPI](https://owasp.org/www-project-crapi/). Undated project documentation; accessed 11 September 2026. Used for API-specific practice.


## Platforms & participation

[Read the associated chapter](#page-platforms).

Original registry accessed **2026-09-11**. A selective follow-up review on **2026-09-14** rechecked the participation mechanics and policy-sensitive claims described above. “Undated/current” records the original retrieval context; it does not certify every program’s present intake. Google’s dynamic policy bodies and the direct IBB policy body could not be reverified. Search-index information is labeled where used, and no inaccessible page is treated as proof that a program closed or reopened.

| Source title | Publisher | Publication/update date | Exact URL | Claim used |
|---|---|---|---|---|
| Bug Bounty Programs | HackerOne | Undated/current | https://www.hackerone.com/bug-bounty-programs | Program discovery route |
| Invitations | HackerOne | 2025-10-15 | https://docs.hackerone.com/en/articles/8470802-invitations | Reputation, signal, conduct, solicitation prohibition |
| Private Opportunities | HackerOne | 2025-01-29 | https://docs.hackerone.com/en/articles/10485859-private-opportunities | Eligible researchers can claim listed opportunities; limited availability |
| Finding a Program | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/finding-program/ | Public/private access, brief and special requirements |
| Viewing and Accepting Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/ | Newer engagement matching criteria |
| Viewing and Accepting Program Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/viewing-invitations/ | Older numerical criteria differ from newer engagement language |
| Program confidentiality levels | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels | Four participation modes |
| Program settings | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/5928505-program-settings | Identity, geography, 2FA and payout restrictions |
| Programs | YesWeHack | Undated/current | https://helpcenter.yeswehack.io/en/collections/875314-programs | Scope grids, grey-box credentials, VPN |
| Invite new hunters on a program | YesWeHack | Relative update label only on 2026-09-14; exact date unverified | https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program | Curated invitation criteria |
| Huntr 2.0 FAQ | Huntr / Palo Alto Networks | 2026; retrieved page had no exact date | https://blog.huntr.com/huntr-2-0-faq | OSS intake closure/freeze; challenge pivot; provisional model-format route |
| Google OSS VRP Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules | Current OSS policy route; dynamic body incomplete |
| Streamlining Google's OSS VRP: Key Rule Updates | Google | 2026 title; exact update date not reverified 2026-09-14 | https://bughunters.google.com/blog/ossvrp-rule-updates-2026 | 2026 rule update exists; do not reuse launch-era rules |
| Patch Rewards Program Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules | Separate patch incentive |
| Internet Bug Bounty policy | HackerOne / IBB | Direct policy body unavailable 2026-09-14 | https://hackerone.com/ibb | Previous policy reference; current intake controls and exact pause date not reverified |
| Security Bug Bounty Program Paused Due to Loss of Funding | Node.js | Updated 2026-04-02 | https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties | IBB loss pauses Node.js payments while intake continues |
| Privately reporting a security vulnerability | GitHub | Undated/current | https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately | Repository private reporting and private forks |
| Next chapter: Restructuring GitHub's bug bounty program | GitHub | 2026-07-22; effective 2026-07-27 | https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/ | Public/VIP restructuring and signal gate |
| GitHub Security | GitHub | Undated/current | https://bounty.github.com/ | Product program entry point |
| GitLab Bug Bounty Program policy updates | GitLab | 2026-01-20 | https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/ | Self-managed versus hosted testing and scope |
| Bug Bounty Program | Wordfence | Undated/current | https://www.wordfence.com/threat-intel/bug-bounty-program | Tiers and eligibility conditions |
| Bug Bounty Guidelines & Rules (2026 edition) | Patchstack | Published 2022-07-10; update effective 2026-09-01 | https://patchstack.com/articles/bug-bounty-guidelines-rules/ | Pool/individual reward distinction and recent conditions |
| Microsoft Bounty Programs | Microsoft | Undated/current | https://www.microsoft.com/en-us/msrc/bounty | Program families |
| In scope by default | Microsoft MSRC | 2025-12-11 | https://www.microsoft.com/en-us/msrc/blog/2025/12/in-scope-by-default | Critical online-service impact expansion |
| Guidelines | Apple Security Research | Undated/current | https://security.apple.com/bounty/guidelines/ | Actionable evidence and reward eligibility |
| Security Research Device Program | Apple | Undated/current | https://security.apple.com/research-device/ | Separate research-device program |
| Security Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/bug-bounty/ | Mozilla program entry |
| Client Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/client-bug-bounty/ | Supported client configurations, proof requirements, mitigation scope |
| Bug Bounty Programs | Immunefi | Current directory | https://immunefi.com/bug-bounty/ | Web3 bounty directory |
| Bug bounty and crowdsourced audit platform | HackenProof | Current homepage | https://hackenproof.com/ | Live platform/route types |
| Opportunities | Cantina | Current directory | https://cantina.xyz/opportunities | Bounties, competitions and deposit indicators |
| Welcome to Cantina | Cantina | Current documentation | https://docs.cantina.security/introduction | Current documentation/domain |
| Competitions | Code4rena | Current documentation | https://docs.code4rena.com/ | Competitive audit route |
| Bounties | Code4rena | Current documentation; indexed 2026-03-25 | https://docs.code4rena.com/bounties | Runnable proof, severity and 25 USDC deposit |
| Audits | Sherlock | Current documentation | https://docs.sherlock.xyz/audits | Contest process and judging/payout documentation |
| About Us | TrendAI Zero Day Initiative | Undated/current | https://www.zerodayinitiative.com/about/ | Vendor-agnostic acquisition and coordination |
| Pwn2Own Berlin 2026 Rules | ZDI | 2026 event rules | https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html | Fixed event, registration and technical target conditions |
| RFC 9116 | IETF / RFC Editor | 2022-04 | https://www.rfc-editor.org/rfc/rfc9116.html | Contact/policy discovery; no implied test authorization |
| Vulnerability Disclosure Policy | US Consumer Product Safety Commission | Undated/current | https://www.cpsc.gov/vulnerability-disclosure-policy | Institutional VDP and stopping conditions |
| BUG-BOUNTY.md | curl project | Current repository policy | https://github.com/curl/curl/blob/master/docs/BUG-BOUNTY.md | End of curl bounty in January 2026 |
| The end of the curl bug-bounty | Daniel Stenberg, curl maintainer | 2026-01-26 | https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ | Closure effective 2026-01-31 |
| Google-owned product vulnerability intake | Google | Undated; official index checked 2026-09-14 | https://bughunters.google.com/report/vrp | Broader Google product/service reporting route; dynamic body unavailable |


## Scope model

[Read the associated chapter](#page-scope).

- Foudil, E., and Y. Shafranovich / IETF. [RFC 9116: A File Format to Aid in Security Vulnerability Disclosure](https://www.rfc-editor.org/rfc/rfc9116.html). April 2022; accessed 11 September 2026. Used for security.txt location, scope and lack of implied testing permission.
- HackerOne. [Gold Standard Safe Harbor Statement](https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement). 11 August 2025; accessed 11 September 2026. Used for third-party and policy-compliance limits.
- Uploaded all.txt. Local supplied copy; accessed 11 September 2026. Used only for line-level inventory analysis; no public URL or authorization evidence.


## Operating playbook

[Read the associated chapter](#page-operations).

- FIRST. [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document), document version 1.2; accessed 11 September 2026. Used for severity characteristics and metric groups.
- FIRST. [CVSS v4.0 User Guide](https://www.first.org/cvss/v4.0/user-guide), version 1.2, 14 November 2025; accessed 11 September 2026. Used for Base severity versus risk and score/vector presentation.
- CVE Program. [CNA Operational Rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules), version 4.1.0, effective 14 May 2025; accessed 11 September 2026. Used for CVE/CNA coordination context.


## OSS & self-hosted

[Read the associated chapter](#page-oss).

All sources were accessed on **2026-09-11**. Unless a date is listed, the cited documentation is undated/living documentation; tool and service behavior must be checked again when used.

| Publisher | Source | Publication/update date | Supports |
|---|---|---|---|
| OWASP | [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) | Undated | Manual review, logic/data-flow emphasis |
| GitHub | [Privately reporting a vulnerability](https://docs.github.com/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability) | Undated | Private reporting availability |
| GitHub | [Repository security advisories](https://docs.github.com/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories) | Undated | Private collaboration/disclosure |
| GitHub | [Publishing an advisory](https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory) | Undated | CVE request workflow |
| Semgrep | [Taint analysis](https://docs.semgrep.dev/writing-rules/data-flow/taint-mode/overview) | Undated | Sources, sinks, propagators, sanitizers |
| Semgrep | [CLI reference](https://docs.semgrep.dev/cli-reference) | Undated | Local rules, flags, engine capabilities |
| Semgrep | [Licensing](https://docs.semgrep.dev/licensing) and [Rules License](https://semgrep.dev/legal/rules-license/) | Undated | CE and rule licensing distinctions |
| Gitleaks maintainers | [Official repository documentation](https://github.com/gitleaks/gitleaks) | Undated | Current commands, history, redaction |
| Anchore | [Syft](https://github.com/anchore/syft) and [output formats](https://oss.anchore.com/docs/guides/sbom/formats/) | Undated | SBOM inventory and output syntax |
| Google | [OSV usage](https://google.github.io/osv-scanner/usage/), [source scanning](https://google.github.io/osv-scanner/usage/scan-source), [offline mode](https://google.github.io/osv-scanner/usage/offline-mode/) | Undated | Version matching, recursion, offline limits |
| Aqua Security | [Trivy filesystem reference](https://trivy.dev/docs/latest/references/configuration/cli/trivy_filesystem/) | Undated | Scanners and individual offline/update flags |
| GitHub | [Secure use reference](https://docs.github.com/en/actions/reference/security/secure-use) | Undated | Least privilege, immutable action references |
| GitHub | [Workflow events](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) and [pull_request_target guidance](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target) | Undated | Event trust boundaries and current protections |
| GitHub | [OIDC in AWS](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws) | Undated | Subject/identity restrictions |
| npm | [Trusted publishing](https://docs.npmjs.com/trusted-publishers/) | Updated 2026-09-03 | Publisher identity and authentication |
| Python Package Index | [Trusted publisher security model](https://docs.pypi.org/trusted-publishers/security-model/) | Undated | Workflow compromise and publishing trust |
| LLVM Project | [libFuzzer](https://llvm.org/docs/LibFuzzer.html) | Undated | Harness, corpus, bounds, minimization |
| GitHub | [CodeQL CLI](https://docs.github.com/en/code-security/concepts/code-scanning/codeql/codeql-cli), [database preparation](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/prepare-code-for-analysis), [analysis](https://docs.github.com/en/code-security/tutorials/customize-code-scanning/analyze-code) | Undated | Eligibility and local CLI workflow |
| Git Project | [git-rev-parse](https://git-scm.com/docs/git-rev-parse) | Undated | Commit identity command |
| Andrew Gallant/ripgrep contributors | [ripgrep guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md) | Undated | Local file inventory flags |


## Web & API

[Read the associated chapter](#page-web-api).

All sources accessed 2026-09-11. “Undated” means no reliable publication date was established; it does not imply old content. Sources were read directly. This chapter's test budgets, matrices, ordering and stopping rules are synthesis, not quotations from those sources.

| Source | Date/version | URL |
|---|---|---|
| OWASP WSTG project | v4.2 released 2020-12-03; v5 development | https://owasp.org/www-project-web-security-testing-guide/ |
| OWASP ASVS | v5.0.0 released 2025-05-30 | https://owasp.org/www-project-application-security-verification-standard/ |
| ProjectDiscovery Subfinder usage | Undated | https://docs.projectdiscovery.io/opensource/subfinder/usage |
| ProjectDiscovery httpx usage | Undated | https://docs.projectdiscovery.io/opensource/httpx/usage |
| curl manual | Undated rolling manual | https://curl.se/docs/manpage.html |
| PortSwigger access control | Undated | https://portswigger.net/web-security/access-control |
| PortSwigger GraphQL | Undated | https://portswigger.net/web-security/graphql |
| gRPC authentication | Last modified 2024-01-12 | https://grpc.io/docs/guides/auth/ |
| gRPC reflection | Undated | https://grpc.io/docs/guides/reflection/ |
| PortSwigger WebSockets | Undated | https://portswigger.net/web-security/websockets |
| OWASP Session Management | Undated | https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html |
| RFC 9700 OAuth Security BCP | January 2025 | https://www.rfc-editor.org/rfc/rfc9700.html |
| PortSwigger OAuth | Undated | https://portswigger.net/web-security/oauth |
| OpenID Connect Core | 1.0 incorporating errata set 2 | https://openid.net/specs/openid-connect-core-1_0.html |
| OWASP SAML Security | Undated | https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html |
| PortSwigger business logic | Undated | https://portswigger.net/web-security/logic-flaws |
| PortSwigger race conditions | Undated | https://portswigger.net/web-security/race-conditions |
| PortSwigger SQL injection | Undated | https://portswigger.net/web-security/sql-injection |
| PortSwigger NoSQL injection | Undated | https://portswigger.net/web-security/nosql-injection |
| PortSwigger template injection | Undated | https://portswigger.net/web-security/server-side-template-injection |
| PortSwigger XSS | Undated | https://portswigger.net/web-security/cross-site-scripting |
| PortSwigger file uploads | Undated | https://portswigger.net/web-security/file-upload |
| PortSwigger path traversal | Undated | https://portswigger.net/web-security/file-path-traversal |
| PortSwigger SSRF | Undated | https://portswigger.net/web-security/ssrf |
| PortSwigger CSRF | Undated | https://portswigger.net/web-security/csrf |
| PortSwigger CORS | Undated | https://portswigger.net/web-security/cors |
| PortSwigger cache poisoning | Undated | https://portswigger.net/web-security/web-cache-poisoning |
| PortSwigger request smuggling | Undated | https://portswigger.net/web-security/request-smuggling |
| Nmap port states | Undated | https://nmap.org/book/man-port-scanning-basics.html |
| Nmap version detection | Undated | https://nmap.org/book/man-version-detection.html |
| OWASP TLS | Undated | https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html |
| BIND manual | Rolling development manual, undated | https://bind9.readthedocs.io/en/latest/manpages.html |
| OpenSSL s_client | Version 3.5 manual, undated | https://docs.openssl.org/3.5/man1/openssl-s_client/ |

Review update, 14 September 2026: the official [OWASP API Security Top 10 2023 overview](https://api-security.owasp.org/editions/2023/en/0x11-t10/), BOLA and object-property authorization pages were successfully retrieved. Original source-registry access dates remain historical.


## Network services

[Read the associated chapter](#page-network).

All accessed 2026-09-11. Undated means a reliable publication date was not established. RFCs below substantiate protocol mechanics, not a claim that no later updating RFC exists.

| Source | Date/version | URL |
|---|---|---|
| Nmap port states | Undated | https://nmap.org/book/man-port-scanning-basics.html |
| Nmap port selection | Undated | https://nmap.org/book/man-port-specification.html |
| Nmap discovery | Undated | https://nmap.org/book/man-host-discovery.html |
| Nmap timing | Undated | https://nmap.org/book/man-performance.html |
| Nmap IPv6/miscellaneous | Undated | https://nmap.org/book/man-misc-options.html |
| Nmap version detection | Undated | https://nmap.org/book/man-version-detection.html |
| BIND dig | Version 9.20.13 manual | https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility |
| OpenSSL s_client | Version 3.5 manual | https://docs.openssl.org/3.5/man1/openssl-s_client/ |
| Red Hat backporting | Undated | https://access.redhat.com/security/updates/backporting |
| Redis security | Undated rolling docs | https://redis.io/docs/latest/operate/oss_and_stack/management/security/ |
| PostgreSQL authentication | Version 18 rolling docs | https://www.postgresql.org/docs/current/auth-pg-hba-conf.html |
| DNSSEC RFC 4033 | March 2005 | https://www.rfc-editor.org/rfc/rfc4033.html |
| SPF RFC 7208 | April 2014 | https://www.rfc-editor.org/rfc/rfc7208.html |
| DKIM RFC 6376 | September 2011 | https://www.rfc-editor.org/rfc/rfc6376.html |
| DMARC RFC 7489 | March 2015 | https://www.rfc-editor.org/rfc/rfc7489.html |
| SMTP RFC 5321 | October 2008 | https://www.rfc-editor.org/rfc/rfc5321.html |


## Mobile

[Read the associated chapter](#page-mobile).

All sources accessed **2026-09-11**. “Undated” means no reliable publication/update date was established from the retrieved page. Dates are page metadata, not a guarantee of completeness for every current OS version. Archived Apple sources are used for established mechanisms and command syntax, not blanket claims about current platform enforcement.

| ID | Publisher / exact source | Date | Use |
|---|---|---|---|
| MD01 | OWASP, [OWASP MASVS](https://mas.owasp.org/MASVS/) | Undated; living standard | Mobile control organization |
| MD02 | OWASP, [OWASP MASTG](https://mas.owasp.org/MASTG/) | Undated; living guide | Testing methodology and technique catalog |
| MD03 | OWASP, [Mobile Application Security Weakness Enumeration](https://mas.owasp.org/MASWE/) | Undated; living catalog | Weakness taxonomy and version caution |
| MD04 | Google, [Android Debug Bridge](https://developer.android.com/tools/adb) | Updated 2026-09-02 | Device/package inspection commands |
| MD05 | Google, [apkanalyzer](https://developer.android.com/tools/apkanalyzer) | Updated 2026-03-05 | APK metadata and manifest CLI |
| MD06 | Google, [apksigner](https://developer.android.com/tools/apksigner) | Updated 2026-03-05 | APK certificate/signature inspection |
| MD07 | Google, [android:exported](https://developer.android.com/privacy-and-security/risks/android-exported) | 2024-09-24, indexed page date | Component exposure and version dependence |
| MD08 | Google, [Unsafe use of deep links](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks) | 2024-10-24, indexed page date | Deep-link validation |
| MD09 | Google, [WebView – Native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges) | Updated 2024-10-15 | Frames, native bridges, origin boundaries |
| MD10 | Google, [Network security configuration](https://developer.android.com/privacy-and-security/security-config) | Updated 2026-08-28 | Trust anchors and debug overrides |
| MD11 | Google, [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics) | Undated in this registry | Provider access model |
| MD12 | skylot/JADX maintainers, [JADX repository and CLI](https://github.com/skylot/jadx) | Undated; living README | Decompiler usage and limitations |
| MD13 | Apktool maintainers, [CLI Parameters](https://apktool.org/docs/cli-parameters/) | Undated | Local package decoding |
| MD14 | OWASP, [iOS Security Testing](https://mas.owasp.org/MASTG/0x06b-iOS-Security-Testing/) | Undated | iOS lab/platform distinctions |
| MD15 | Apple, [Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) | Published 2024-12-19 | Access groups, classes, authentication constraints |
| MD16 | Apple, [Support Universal Links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html) | Updated 2016-12-15; archived | App/website association model |
| MD17 | OWASP, [MASTG-TOOL-0062: Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/) | Undated | Property-list inspection tooling |
| MD18 | OWASP, [MASTG-TECH-0111: Extracting Entitlements from MachO Binaries](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/) | Undated | Signing/entitlement inspection |
| MD19 | Apple, [TN2206: macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html) | Page updated 2016-09-13; archived | Signature verification command and boundaries |
| MD20 | Microsoft / Mark Russinovich, [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) | Published 2026-09-10 | Local process, registry, filesystem observation |
| MD21 | Microsoft, [Get-AuthenticodeSignature](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) | Undated; PowerShell 7.5 documentation | Windows signature inspection |
| MD22 | Microsoft, [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) | Updated 2025-06-09 | Windows ACL inspection |
| MD23 | OpenJS Foundation / Electron contributors, [Security](https://www.electronjs.org/docs/latest/tutorial/security) | Undated; living documentation | Renderer, navigation, IPC boundaries |
| MD24 | Electron contributors, [Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation) | Undated | Bridge limitations and API exposure |
| MD25 | Google, [Stay secure](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure) | Page states updated 2018-03-06 | Extension permissions and untrusted messages |
| MD26 | Google, [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging) | Page states updated 2025-12-03 | Extension messaging contexts |
| MD27 | Google, [Native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) | Page states updated 2023-02-27 | Native host manifest and execution boundary |
| MD28 | AFL++ maintainers, [Fuzzing in Depth](https://aflplus.plus/docs/fuzzing_in_depth/) | Undated; living guide | Harness, corpus, execution, resource limits |
| MD29 | GNU Binutils / Sourceware, [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) | Undated | Non-executing ELF metadata inspection |


## Desktop & extensions

[Read the associated chapter](#page-desktop).

All sources accessed **2026-09-11**. “Undated” means no reliable publication/update date was established from the retrieved page. Dates are page metadata, not a guarantee of completeness for every current OS version. Archived Apple sources are used for established mechanisms and command syntax, not blanket claims about current platform enforcement.

| ID | Publisher / exact source | Date | Use |
|---|---|---|---|
| MD01 | OWASP, [OWASP MASVS](https://mas.owasp.org/MASVS/) | Undated; living standard | Mobile control organization |
| MD02 | OWASP, [OWASP MASTG](https://mas.owasp.org/MASTG/) | Undated; living guide | Testing methodology and technique catalog |
| MD03 | OWASP, [Mobile Application Security Weakness Enumeration](https://mas.owasp.org/MASWE/) | Undated; living catalog | Weakness taxonomy and version caution |
| MD04 | Google, [Android Debug Bridge](https://developer.android.com/tools/adb) | Updated 2026-09-02 | Device/package inspection commands |
| MD05 | Google, [apkanalyzer](https://developer.android.com/tools/apkanalyzer) | Updated 2026-03-05 | APK metadata and manifest CLI |
| MD06 | Google, [apksigner](https://developer.android.com/tools/apksigner) | Updated 2026-03-05 | APK certificate/signature inspection |
| MD07 | Google, [android:exported](https://developer.android.com/privacy-and-security/risks/android-exported) | 2024-09-24, indexed page date | Component exposure and version dependence |
| MD08 | Google, [Unsafe use of deep links](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks) | 2024-10-24, indexed page date | Deep-link validation |
| MD09 | Google, [WebView – Native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges) | Updated 2024-10-15 | Frames, native bridges, origin boundaries |
| MD10 | Google, [Network security configuration](https://developer.android.com/privacy-and-security/security-config) | Updated 2026-08-28 | Trust anchors and debug overrides |
| MD11 | Google, [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics) | Undated in this registry | Provider access model |
| MD12 | skylot/JADX maintainers, [JADX repository and CLI](https://github.com/skylot/jadx) | Undated; living README | Decompiler usage and limitations |
| MD13 | Apktool maintainers, [CLI Parameters](https://apktool.org/docs/cli-parameters/) | Undated | Local package decoding |
| MD14 | OWASP, [iOS Security Testing](https://mas.owasp.org/MASTG/0x06b-iOS-Security-Testing/) | Undated | iOS lab/platform distinctions |
| MD15 | Apple, [Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) | Published 2024-12-19 | Access groups, classes, authentication constraints |
| MD16 | Apple, [Support Universal Links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html) | Updated 2016-12-15; archived | App/website association model |
| MD17 | OWASP, [MASTG-TOOL-0062: Plutil](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/) | Undated | Property-list inspection tooling |
| MD18 | OWASP, [MASTG-TECH-0111: Extracting Entitlements from MachO Binaries](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/) | Undated | Signing/entitlement inspection |
| MD19 | Apple, [TN2206: macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html) | Page updated 2016-09-13; archived | Signature verification command and boundaries |
| MD20 | Microsoft / Mark Russinovich, [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) | Published 2026-09-10 | Local process, registry, filesystem observation |
| MD21 | Microsoft, [Get-AuthenticodeSignature](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) | Undated; PowerShell 7.5 documentation | Windows signature inspection |
| MD22 | Microsoft, [icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) | Updated 2025-06-09 | Windows ACL inspection |
| MD23 | OpenJS Foundation / Electron contributors, [Security](https://www.electronjs.org/docs/latest/tutorial/security) | Undated; living documentation | Renderer, navigation, IPC boundaries |
| MD24 | Electron contributors, [Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation) | Undated | Bridge limitations and API exposure |
| MD25 | Google, [Stay secure](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure) | Page states updated 2018-03-06 | Extension permissions and untrusted messages |
| MD26 | Google, [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging) | Page states updated 2025-12-03 | Extension messaging contexts |
| MD27 | Google, [Native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) | Page states updated 2023-02-27 | Native host manifest and execution boundary |
| MD28 | AFL++ maintainers, [Fuzzing in Depth](https://aflplus.plus/docs/fuzzing_in_depth/) | Undated; living guide | Harness, corpus, execution, resource limits |
| MD29 | GNU Binutils / Sourceware, [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) | Undated | Non-executing ELF metadata inspection |


## Cloud & containers

[Read the associated chapter](#page-cloud).

All accessed 11 September 2026. Match living documentation to the target version.

| Publisher | Source | Publication or version |
|---|---|---|
| Amazon Web Services | [Penetration Testing](https://aws.amazon.com/security/penetration-testing/) | Undated |
| Microsoft Security Response Center | [Microsoft Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement) | Undated |
| Google | [Cloud Security FAQ](https://support.google.com/cloud/answer/6262505?hl=en) | Undated |
| Amazon Web Services | [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) | Undated |
| Amazon Web Services | [Download and upload objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) | Undated |
| Kubernetes | [Multi-tenancy](https://kubernetes.io/docs/concepts/security/multi-tenancy/) | Undated living documentation |
| Kubernetes | [Role Based Access Control Good Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) | Undated living documentation |
| Kubernetes | [Admission Webhook Good Practices](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/) | Undated living documentation |
| Kubernetes | [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) | Undated living documentation |
| Kubernetes | [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | Undated living documentation |
| HashiCorp | [Manage sensitive data in your configuration](https://developer.hashicorp.com/terraform/language/manage-sensitive-data) | Undated |
| Amazon Web Services | [get-caller-identity — AWS CLI v2 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html) | Undated living documentation |
| Amazon Web Services | [get-bucket-policy-status — AWS CLI v2 Command Reference](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-policy-status.html) | Undated living documentation |
| Microsoft Learn | [az account](https://learn.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest) | Undated living documentation |
| Google Cloud | [gcloud projects get-iam-policy](https://docs.cloud.google.com/sdk/gcloud/reference/projects/get-iam-policy) | Undated living documentation |
| Kubernetes | [kubectl auth can-i](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/) | Undated living documentation |
| Docker | [docker image inspect](https://docs.docker.com/reference/cli/docker/image/inspect/) | Undated |
| HashiCorp | [terraform validate command reference](https://developer.hashicorp.com/terraform/cli/commands/validate) | Undated |


## AI, agents & MCP

[Read the associated chapter](#page-ai).

All accessed 11 September 2026. Match living documentation to the target version.

| Publisher | Source | Publication or version |
|---|---|---|
| OWASP Foundation | [OWASP AI Testing Guide](https://owasp.org/www-project-ai-testing-guide/) | 2025-11-26 (v1 announcement) |
| OWASP GenAI Security Project | [LLM Top 10](https://genai.owasp.org/llm-top-10/) | 2025 edition |
| OWASP GenAI Security Project | [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) | 2025 edition |
| OWASP GenAI Security Project | [LLM08:2025 Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) | 2025 edition |
| OWASP GenAI Security Project | [LLM07:2025 System Prompt Leakage](https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/) | 2025 edition |
| Model Context Protocol | [Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) | 2026-07-28 |
| Model Context Protocol | [Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog) | 2026-07-28 |
| Model Context Protocol | [Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) | 2026-07-28 |
| Model Context Protocol | [Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) | 2026-07-28 revision |
| Model Context Protocol | [Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) | 2026-07-28 |
| Hugging Face | [Customizing models — Transformers](https://huggingface.co/docs/transformers/custom_models) | Undated |
| PyTorch | [Serialization semantics](https://docs.pytorch.org/docs/stable/notes/serialization.html) | Undated living documentation |
| Andrew Gallant / ripgrep contributors | [ripgrep User Guide](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md) | Undated living repository |
| Python Software Foundation | [hashlib — Secure hashes and message digests](https://docs.python.org/3/library/hashlib.html) | Undated living documentation |
| Python Software Foundation | [json — JSON encoder and decoder](https://docs.python.org/3/library/json.html) | Undated living documentation |
| Python Software Foundation | [secrets — Generate secure random numbers for managing secrets](https://docs.python.org/3/library/secrets.html) | Undated living documentation |
| Python Software Foundation | [Command-line options](https://docs.python.org/3/using/cmdline.html) | Living documentation |


## Web3 & protocols

[Read the associated chapter](#page-web3).

All sources accessed 2026-09-11. Documentation pages are undated unless noted; versioned documentation must be matched to the target’s actual dependency version.

1. Immunefi. [Rules](https://immunefi.com/rules/). Undated, current rules.
2. Immunefi. [Immunefi Bug Bounty: Information](https://immunefi.com/bug-bounty/immunefi/information/). Undated, current program example.
3. Foundry. [Fork Testing](https://www.getfoundry.sh/guides/fork-testing). Undated; search index displays 2026-08-28.
4. Foundry. [Testing](https://www.getfoundry.sh/forge/testing). Undated; search index displays 2026-07-09.
5. Foundry. [forge test](https://www.getfoundry.sh/reference/forge/test). Undated CLI reference.
6. Foundry. [Invariant Testing](https://getfoundry.sh/forge/invariant-testing?highlight=invariant). Undated.
7. Trail of Bits / Crytic. [Slither Usage](https://github.com/crytic/slither/wiki/Usage). Edited 2024-07-23.
8. OpenZeppelin. [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy). Contracts 5.x; undated.
9. Solidity. [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html). Rolling development documentation; undated.
10. Chainlink. [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference). Undated.
11. Chainlink. [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds). Undated.
12. OpenZeppelin. [ERC-4626](https://docs.openzeppelin.com/contracts/5.x/erc4626). Contracts 5.x; undated.
13. Ethereum Improvement Proposals. [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712). Created 2017-09-12.
14. OpenZeppelin. [Governance](https://docs.openzeppelin.com/contracts/5.x/api/governance). Contracts 5.x; undated.
15. Ethereum.org. [Bridges](https://ethereum.org/developers/docs/bridges/). Undated.
16. Ethereum.org. [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/). Undated.
17. Solana. [CPI Execution and Privileges](https://solana.com/docs/core/cpi/cpi-execution). Undated.
18. Sui. [Move Concepts](https://docs.sui.io/develop/write-move/sui-move-concepts). Undated.
19. Ethereum.org. [Nodes and Clients](https://ethereum.org/developers/docs/nodes-and-clients/). Undated.


## Hardware & firmware

[Read the associated chapter](#page-hardware).

All sources accessed 2026-09-11. Undated pages are live references. OWASP citations point to the guide’s official maintained source files.

1. Intel / Intigriti. [Intel Bug Bounty Program](https://app.intigriti.com/programs/intel/intel/detail). Undated, current program terms.
2. OWASP. [ISTG: Attacker Model](https://github.com/OWASP/owasp-istg/blob/main/src/02_framework/attacker_model.md). Undated.
3. OWASP / Aaron Guzman. [Firmware Security Testing Methodology](https://github.com/scriptingxss/owasp-fstm). Undated, maintained repository.
4. OWASP. [ISTG: Firmware Update Mechanism](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md). Undated.
5. Espressif. [Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html). ESP-IDF stable, ESP32; undated.
6. Espressif. [Security Overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/security.html). ESP-IDF stable, ESP32; undated.
7. OWASP. [ISTG: Installed Firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md). Undated.
8. OWASP. [ISTG: Memory](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/memory/README.md). Undated.
9. OWASP. [ISTG: Internal Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md). Undated.
10. OWASP. [ISTG: Wireless Interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/wireless_interfaces/README.md). Undated.
11. ReFirm Labs. [Binwalk](https://github.com/ReFirmLabs/binwalk). Undated, maintained repository.
12. Tesla. [Product Security](https://www.tesla.com/legal/security). Undated, current policy.



## Expansion research

The reusable modules, vulnerability cards, and conditional ATT&CK references were researched on **12 September 2026**. Each module and card keeps primary citations beside the relevant procedure. The existing platform policies retain their original 11 September research date; check the live policy before testing. Examples are documentation-reviewed, not executed test results. ATT&CK associations are conditional editorial mappings and do not imply that MITRE has mapped each weakness to that technique.

- [Object, function, and property authorization](#page-modules-authz-matrix) — inline primary references and test prerequisites.

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — inline primary references and test prerequisites.

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — inline primary references and test prerequisites.

- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — inline primary references and test prerequisites.

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — inline primary references and test prerequisites.

- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — inline primary references and test prerequisites.

- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — inline primary references and test prerequisites.

- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — inline primary references and test prerequisites.

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — inline primary references and test prerequisites.

- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — inline primary references and test prerequisites.

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — inline primary references and test prerequisites.

- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — inline primary references and test prerequisites.

- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — inline primary references and test prerequisites.

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — inline primary references and test prerequisites.

- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — inline primary references and test prerequisites.

- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — inline primary references and test prerequisites.

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — inline primary references and test prerequisites.

- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — inline primary references and test prerequisites.

- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — inline primary references and test prerequisites.

- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — inline primary references and test prerequisites.

- [Android components, intents and deep links](#page-modules-android-components) — inline primary references and test prerequisites.

- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — inline primary references and test prerequisites.

- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — inline primary references and test prerequisites.

- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — inline primary references and test prerequisites.

- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — inline primary references and test prerequisites.

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — inline primary references and test prerequisites.

- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — inline primary references and test prerequisites.

- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — inline primary references and test prerequisites.

- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — inline primary references and test prerequisites.

- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — inline primary references and test prerequisites.

- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — inline primary references and test prerequisites.

- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — inline primary references and test prerequisites.

- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — inline primary references and test prerequisites.

- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — inline primary references and test prerequisites.

- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — inline primary references and test prerequisites.

- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — inline primary references and test prerequisites.

- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — inline primary references and test prerequisites.

- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — inline primary references and test prerequisites.

- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — inline primary references and test prerequisites.

- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — inline primary references and test prerequisites.


## Content review — 14 September 2026

All original chapters, shared modules and vulnerability cards were reviewed for gaps and accuracy. Selected primary references were rechecked; this does not redate every source above. Read the [review and updates](#page-review) for new procedures, corrections, source limitations and scope. The current OWASP API Security 2023 overview and selected API1/API3/API4/API6 pages were successfully retrieved. Direct IBB/Google policy bodies and some hardware-source refreshes remained limited as described in the relevant chapters. No target tests were performed.


---

<a id="page-modules-authz-matrix"></a>

# Object, function, and property authorization

Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

## Investigation sequence

1. Establish permission rule
2. Seed two controlled identities
3. Replay one changed dimension
4. Verify durable effect
5. Revoke and repeat
6. Record smallest violation

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Use accounts A and B, two private tenants, and one synthetic document per tenant. Create a viewer role only if the product supports it. Record the exact build, API version, actor, tenant membership, document visibility, and expected permission rule. The invariant is: **the server authorizes the actor, action, object, and each protected property together**. UI visibility is supporting context; product policy establishes the boundary. Horizontal, vertical, and context-dependent authorization are separate dimensions. [Access-control models](https://portswigger.net/web-security/access-control).

### Numbered test procedure

1. **Capture a working baseline.** As A, create private O1 containing `BB-A-ONLY-01`; as B create O2 containing `BB-B-ONLY-01`. Save each normal read response and a normal reversible rename. Keep separate browser profiles and credentials. Confirm anonymous access to O1 fails.
2. **Test the object dimension.** Replay A's O1 read using B's credentials, changing nothing else. Then keep B's identity and replace O1 with O2 as a positive control. Substitute only known controlled identifiers, including parent tenant IDs, child IDs, attachment IDs, and export-job IDs. A nonexistent synthetic ID is the negative control for error handling; it does not replace the cross-account test.
3. **Test the function dimension.** Give B a documented viewer role in A's test tenant. Capture an owner-only operation as A, such as renaming a private test folder, and replay it as B. If the product permits viewer renames, select an actually restricted operation. Inspect durable state from A's browser after the request completes.
4. **Test the property dimension.** Start with a permitted profile update. Add exactly one known server-controlled property from schema or source, such as a role field in the isolated tenant. Read back the stored object, then test one corresponding restricted action. Repeat separately for unauthorized response properties. Automatic binding of request fields can create mass-assignment issues; read-side property disclosure is a different mechanism. [OWASP mass assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html).
5. **Test lifecycle and alternate delivery.** Remove B's membership, replay the previously successful request, and check an existing subscription or queued export. Repeat the same permission rule at list/search, download, batch, and versioned endpoints where present. Use two-item batches containing O1 and O2; do not enumerate identifiers.
6. **Interpret and clean up.** Match markers, object IDs, committed changes, and resulting permissions. A 200 with an empty list, a 202 for a rejected job, or a redirect without private content is not proof. Remove synthetic records and memberships after preserving minimal evidence.

### Command card

These illustrative routes require your local replica. Create `A.header` and `B.header` containing each test account's complete `Authorization: Bearer …` header; protect the files and exclude them from reports. curl can load headers from a file. [curl manual](https://curl.se/docs/manpage.html).

```bash
mkdir -p evidence/authz
chmod 600 A.header B.header
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -D evidence/authz/a.h -o evidence/authz/a.json \
  http://127.0.0.1:8000/api/documents/O1
curl -q --noproxy '*' --max-time 10 --header @B.header \
  -D evidence/authz/b.h -o evidence/authz/b.json \
  http://127.0.0.1:8000/api/documents/O1
curl -q --noproxy '*' --max-time 10 --header @B.header \
  -o evidence/authz/control.json \
  http://127.0.0.1:8000/api/documents/O2
```

### Report threshold and checklist

Report a demonstrated unauthorized read, action, or protected-property change. Attach the intended rule, both actors' roles, minimal request difference, and independent state verification. UUID disclosure, shared objects, intentionally public exports, stale UI state, and identical status codes are common false positives.

- [ ] Ownership and visibility confirmed before testing.
- [ ] Object, function, and property decisions tested separately.
- [ ] Positive and negative controls captured.
- [ ] Background output and revoked membership checked.
- [ ] No unrelated customer records accessed.

Local curl examples use `--noproxy '*'` to bypass inherited proxy variables; `-q` alone only disables the default curl configuration file. Configure intentional interception separately. [curl manual](https://curl.se/docs/manpage.html).


## Vulnerability reverse references

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access) — An actor can access another owner’s protected object by supplying its identifier.
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function) — A lower-privilege actor invokes a function reserved for another role.
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property) — An otherwise permitted object response includes fields the actor is not entitled to read.
- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property) — Automatic request binding lets a user modify a property that should be set only by trusted server logic.
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access) — A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass) — An actor can complete a protected workflow without its required prior approval or immutable conditions.
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz) — A GraphQL path or protected field bypasses the permission enforced for the same object elsewhere.
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization) — A valid connection performs unauthorized per-message actions or receives a private subscription.
- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler) — An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization) — A tool trusts caller-supplied object or workspace identifiers instead of enforcing the authenticated principal’s authority.
- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval) — Search filters, chunk retrieval or citation download omit an ownership decision required for the effective caller.
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak) — A new retrieval or cache response exposes protected content after its applicable permission revocation has taken effect.
- [Contract initializer permits unauthorized ownership or configuration](#page-vulnerabilities-contract-unprotected-initializer) — A reachable initialization path lets an ordinary actor establish or replace privileged state outside the intended deployment lifecycle.
- [Contract upgrade authority can be bypassed](#page-vulnerabilities-contract-upgrade-authorization) — An actor outside the upgrade policy can change a proxy’s execution target or equivalent privileged configuration.
- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict) — Validation or authorization uses one interpretation of a request value while the protected operation uses another.
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding) — A valid provider event is misbound to a local tenant, installation, mode or resource the event is not authorized to modify.
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership) — Persisted agent state or its resume/export path is accessible or mutable by a principal outside its intended owner or sharing grant.


---

<a id="page-modules-identity-session"></a>

# Authentication, recovery, federation, and session lifecycle

Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

## Investigation sequence

1. Map identity states
2. Capture valid and invalid controls
3. Alter one binding
4. Verify account identity
5. Test revocation
6. Restore account settings

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Prepare two controlled accounts, separate inboxes, browser profiles, and a recovery route for each. Use an isolated identity provider for federation modifications. Write the accepted identity states: unverified, password accepted, MFA pending, fully authenticated, elevated, recovered, and revoked. The invariant is: **each privileged transition requires the right identity proof, and credentials remain bound to their intended account and purpose**. Consult documented expiry and revocation semantics before judging residual access. [OWASP authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html).

### Numbered test procedure

1. **Inventory entry points.** Record registration, email verification, password login, passkey/MFA completion, mobile login, SSO, API-token issuance, email change, linking, reset, and logout. Capture one complete normal sequence with timestamps and account identifiers. An anonymous call to `/api/me` and an intentionally invalid credential form negative controls.
2. **Check incomplete authentication.** Stop A's normal login immediately before MFA. Use that intermediate cookie or token for a single protected profile read. Compare it with a completed A session and an anonymous request. Also check the observed alternate API route; avoid guessing or spraying credentials. Protected access without the required second factor is the finding, not the mere existence of an intermediate token.
3. **Check recovery binding.** Request one reset for A and one for B. In the local replica, submit A's reset proof with B's account selector, if that selector is client-controlled. After an authorized normal reset of A, replay the consumed proof once. Confirm which controlled account's credential changed by a fresh login. Restore passwords afterward. Single-use, expiry, and account binding are independent checks. [OWASP recovery](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html).
4. **Check session transitions.** Save the pre-login identifier, completed session, and any refresh credential separately. Compare identifiers after login and elevation. Perform logout or explicit device revocation and make one old-session profile request. Record access and refresh outcomes separately; a refresh token being revoked does not necessarily revoke already-issued access tokens. Evaluate the actual advertised security behavior. [OWASP sessions](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html).
5. **Check identity changes and pre-existing state.** Change A's verified email to a second owned inbox; compare verification, pending state, and recovery delivery before/after confirmation. In the replica, keep an unverified password account open, then complete the legitimate verified/federated signup for the same owned inbox in another profile. Inspect whether the original password, session, or linked identity can still access the now-verified account. Independently test reusing a stale verification link after another email change. A duplicate signup error or two aliases reaching the same mailbox proves no takeover. Do not assume case folding, dot removal, or plus-address handling is universal. [Email identity comparison and verification](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html).
6. **Follow enterprise onboarding and offboarding.** Use a disposable tenant with a second recovery administrator. Record invitation recipient/role/tenant, acceptance, cancellation, SSO enforcement, group assignment, and deactivation. Compare a fresh invite with one cancelled invite; confirm whether a changed recipient is allowed by the product contract. After enabling enforced SSO, attempt the observed password, reset/magic-link, and alternate client entry paths once with controlled accounts, then request one protected tenant object. Deliberate break-glass exceptions are separate policy. For SCIM, use the tenant's provisioning credentials and verify deactivation, group removal, token refresh, and existing streams after the configured sync interval. SCIM `active` has provider-defined semantics; it is not a universal immediate-session-kill instruction. [SCIM schema](https://www.rfc-editor.org/rfc/rfc7643.html). Provisioning credentials must still map to the permitted tenant/resources. [SCIM authorization](https://www.rfc-editor.org/rfc/rfc7644.html).
7. **Follow the specialized proof branches.** Use [MFA/passkey lifecycle](#page-modules-authenticator-lifecycle) for enrollment, factor replacement, backup-code reuse, and WebAuthn verifier checks. Use [federation/token trust](#page-modules-federation-token-trust) for OAuth PKCE, OIDC claim and account-linking decisions, JWT validation, and SAML. Do not substitute decoded claims for a protected-resource result. Document which providers, authentication methods, and enterprise features were unavailable rather than marking them passed.

### Command card

Export A's local cookie jar before using the application's real logout button. These requests compare protected content before and after logout; routes and credential transport must match the replica.

```bash
mkdir -p evidence/session
chmod 600 A-before.cookies
curl -q --noproxy '*' --max-time 10 -b A-before.cookies \
  -D evidence/session/before.h -o evidence/session/before.json \
  http://127.0.0.1:8000/api/me
# Perform the actual logout or device-revocation workflow now.
curl -q --noproxy '*' --max-time 10 -b A-before.cookies \
  -D evidence/session/after.h -o evidence/session/after.json \
  http://127.0.0.1:8000/api/me
curl -q --noproxy '*' --max-time 10 -o evidence/session/anonymous.json \
  http://127.0.0.1:8000/api/me
```

### Report threshold and checklist

Report access as the wrong controlled identity, completion without required authentication, unauthorized account linking, or a material violation of revocation guarantees. Cosmetic logout, unsent browser cookies, decoded JWT contents, and reset forms displaying without completing are common false positives.

- [ ] Account and session state recorded for every request.
- [ ] Browser binding distinguished from token validity.
- [ ] Correct and incorrect proofs compared independently.
- [ ] Fresh login verifies any credential or linking change.
- [ ] Verification, linking, invitations, and enforced-SSO fallback paths evaluated.
- [ ] Provisioning changes checked against configured sync and revocation behavior.
- [ ] Recovery settings restored; live tokens removed from report.

## Vulnerability reverse references

- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass) — A session that has not completed required authentication can perform protected operations.
- [Session fixation across login](#page-vulnerabilities-session-fixation-login-binding) — A session known to an attacker remains usable after another controlled user authenticates into it.
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access) — A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.
- [Password reset binding or single-use failure](#page-vulnerabilities-password-reset-account-binding) — Recovery proof can change the wrong account or be reused contrary to the recovery contract.
- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion) — An authorization response or external identity is bound to the wrong application session or controlled account.
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure) — A service accepts token claims without the required signature or trusted issuer/key validation.
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization) — A valid connection performs unauthorized per-message actions or receives a private subscription.
- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler) — An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate) — A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
- [Backup or transfer exposes unintended sensitive client state](#page-vulnerabilities-client-backup-sensitive-state) — A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.
- [MCP proxy consent confuses different clients](#page-vulnerabilities-mcp-proxy-confused-deputy) — A proxy reuses upstream consent in a way that grants a new MCP client access without the resource owner’s intended per-client consent.
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion) — A protected MCP resource accepts a token that was not issued for that resource.
- [Signed action does not bind its intended context](#page-vulnerabilities-contract-signature-context) — A valid signature is accepted for another recipient, action, verifier or chain context contrary to the authorization contract.
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust) — Attacker input controls a navigation destination that the application treats as trusted.
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust) — The application constructs a security-sensitive origin from request metadata that an attacker can influence.
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness) — A security token relies on randomness that does not meet its unpredictability requirement.
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust) — The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass) — A lower-assurance or wrong-account context can add, replace, or remove an authentication factor contrary to its management policy.
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure) — The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion) — Registration, verification, email change, or federation merging transfers trust to an identity while retaining an unintended actor's usable credentials or session.
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass) — A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.


---

<a id="page-modules-injection-tracing"></a>

# Trace input into queries, commands, and templates

Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

## Investigation sequence

1. Identify input and sink
2. Freeze a synthetic fixture
3. Send paired controls
4. Observe sink semantics
5. Confirm smallest effect
6. Document root cause

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud)

### Setup and invariant

Use a local replica seeded only with synthetic records, a normal request, and an observable sink: database query logs, a template render, or a disposable worker's process log. Identify input type and decoding layers before selecting syntax. The invariant is: **untrusted input remains data, or is constrained to an explicitly authorized language**. A SQL search field, MongoDB filter, template editor, and process argument have different trust contracts; the same string is not a universal test.

### Numbered test procedure

1. **Trace the route.** From the handler, follow validation, normalization, service calls, query builders, template compilation, and subprocess invocation. In a black-box target, infer this from observed feature behavior and errors, then reproduce locally when possible. Record the last point where input is still data and the first interpreter boundary. An ORM can still contain unsafe raw fragments.
2. **Freeze controls.** Create exactly one matching synthetic record and one nonmatching record. Capture the normal response. Choose an input that must produce no match under the intended semantics. Keep actor, tenant, pagination, and cache state unchanged across each pair.
3. **Test SQL or NoSQL semantics.** For a known SQL string context in the lab, compare logically true and false expressions while retaining the same synthetic predicate. Prefer local query logs over timing or data extraction. For a JSON filter expected to accept a string, compare `{"name":"BB-CANARY"}` with `{"name":{"$eq":"BB-CANARY"}}`, then `$eq` with a nonexistent marker. Operator acceptance becomes a vulnerability when it escapes the allowed query contract or security predicate; intentional query APIs are different. [SQL injection](https://portswigger.net/web-security/sql-injection), [NoSQL injection](https://portswigger.net/web-security/nosql-injection).
4. **Test template evaluation.** For a documented Jinja/Twig-like local sink, compare literal text, `{{7*7}}`, and `{{7*8}}`. Inspect the raw HTTP response before JavaScript executes. Results 49 and 56 support server interpretation; a single 49 might be ordinary content. If the feature intentionally supports expressions, determine whether a lower-trust actor crosses a promised sandbox or data boundary before reporting. Arithmetic alone does not establish OS execution. [Template injection](https://portswigger.net/web-security/server-side-template-injection).
5. **Test command interpretation locally.** With an identified POSIX shell sink, use a disposable process and a marker-only operation such as `printf BB-CMD-01`; compare the literal argument path with the shell-interpreted path in process logs. Avoid file writes, network callbacks, account enumeration, and long sleeps. Also distinguish argument injection into a legitimate executable from starting an additional shell command. [Command injection](https://portswigger.net/web-security/os-command-injection).
6. **Confirm causality and clean up.** Repeat the baseline and one successful pair, then switch to the validated/parameterized route in the replica as a negative control. Capture the input-to-sink path, raw values after decoding, and smallest observable impact. Remove fixtures and stop at proof.

### Command card

The following performs three bounded template probes against an illustrative local endpoint. Use only when that endpoint is expected to render the parameter as text; do not infer engine identity from one expression.

```bash
mkdir -p evidence/injection
curl -q --noproxy '*' --max-time 10 --get --data-urlencode 'name=BB-LITERAL' \
  -o evidence/injection/baseline.txt \
  http://127.0.0.1:8000/preview
curl -q --noproxy '*' --max-time 10 --get --data-urlencode 'name={{7*7}}' \
  -o evidence/injection/expression-a.txt \
  http://127.0.0.1:8000/preview
curl -q --noproxy '*' --max-time 10 --get --data-urlencode 'name={{7*8}}' \
  -o evidence/injection/expression-b.txt \
  http://127.0.0.1:8000/preview
```

### Report threshold and checklist

Report attacker-controlled interpretation that violates the feature's contract, supported by paired results or an instrumented source trace. Syntax errors, WAF blocks, reflection, slow requests, and intentionally supported expression syntax are insufficient alone. State whether the demonstrated impact is query manipulation, expression evaluation, argument injection, or command execution.

- [ ] Sink, language, quoting context, and decode order identified.
- [ ] Synthetic positive and negative records available.
- [ ] One input changed per comparison.
- [ ] Raw server output separated from client rendering.
- [ ] Evidence stops short of secret retrieval or destructive execution.

Local curl examples bypass environment proxies with `--noproxy '*'`; `-q` alone only suppresses curl configuration files. These snippets target loopback and do not follow redirects. [curl manual](https://curl.se/docs/manpage.html).


### Delayed consumers and argument-only execution

A safe database insert does not make the stored value trusted forever. In the replica, save a marker through the normal create/update route, then trigger one observed export, search, scheduled job, or administration view that consumes it. Capture both requests, the stored bytes, and the later interpreter call. Repeat with a literal marker and one context-specific expression; keep the actor and selected synthetic record constant. This checks second-order injection that an immediate-response scan misses. [Second-order SQL injection](https://portswigger.net/web-security/sql-injection).

Treat process arguments as a separate boundary. A subprocess argument array with `shell=False` can still pass an attacker-controlled option to the intended executable. In a local wrapper, compare a normal filename-like argument with a harmless, documented mode switch and observe the exact argument vector and output. Prove that the caller was allowed to supply a value but not that mode. Do not test options that write files, run another program, or contact a network. Report shell-command interpretation under CWE-78 and argument/option injection under CWE-88; neither automatically proves the other. [CWE-88](https://cwe.mitre.org/data/definitions/88.html).

- [ ] Stored input followed through its later privileged consumer where one exists.
- [ ] Argument vector distinguished from shell command text.


## Vulnerability reverse references

- [Mass assignment of server-controlled properties](#page-vulnerabilities-mass-assignment-protected-property) — Automatic request binding lets a user modify a property that should be set only by trusted server logic.
- [SQL injection](#page-vulnerabilities-sql-query-structure-injection) — Input changes SQL query structure instead of remaining a bound value.
- [NoSQL operator or query injection](#page-vulnerabilities-nosql-operator-contract-bypass) — An unexpected object, operator, or expression crosses a NoSQL query boundary.
- [OS command injection](#page-vulnerabilities-os-command-argument-boundary) — An untrusted parameter becomes shell command syntax rather than remaining a data argument.
- [Server-side template injection (SSTI)](#page-vulnerabilities-server-template-expression-injection) — Lower-trust data becomes executable template source at a server-side renderer.
- [Argument or option injection without shell interpretation](#page-vulnerabilities-process-argument-option-injection) — A value-only input changes options or mode of the intended executable, even when no shell is used.
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection) — An outer input injects or alters parameters in a server-created downstream request.


---

<a id="page-modules-ssrf-boundary"></a>

# Server-side fetching and network trust boundaries

Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.

## Investigation sequence

1. Map fetch contract
2. Start controlled canary
3. Confirm ordinary fetch
4. Change one destination rule
5. Correlate server evidence
6. Bound the impact

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) · [Desktop & extensions](#page-desktop)

### Setup and invariant

Identify a feature that causes server-side requests: preview, import, webhook verification, document conversion, image fetch, repository import, or AI tool execution. Record allowed schemes, destinations, redirect rules, credentials, and whether response bodies are returned. Use a local replica with a tiny HTTP canary reachable from its worker. If the application runs in a container, localhost means that container; place the canary on an explicitly controlled test network instead of guessing host addresses.

The invariant is: **every actual destination and credential transfer follows the feature's intended policy**. A URL-fetching feature contacting your public receiver is often normal functionality. SSRF requires an unintended request or trust-boundary violation. [SSRF mechanics](https://portswigger.net/web-security/ssrf).

### Numbered test procedure

1. **Document the ordinary path.** Submit a permitted static URL on your own receiver, containing a unique marker in its path. Record submission time, job ID, request method, receiver log, worker identity if available, and returned output. Confirm the browser did not fetch the URL directly by repeating through curl with the browser closed.
2. **Establish controls.** Submit a second permitted URL that returns a different marker. Also submit a deliberately rejected scheme or destination from the feature's documented policy. Record whether rejection happens before queueing, at DNS resolution, after connection, or during response handling. A DNS lookup alone establishes resolution, not HTTP access.
3. **Test one policy boundary in the replica.** Compare a permitted receiver with an owner-provided private canary that policy should block. If arbitrary public destinations are intended, concentrate on restricted network ranges, forbidden ports or schemes, or unintended credentials, using only designated canaries. Never use production metadata credentials as proof.
4. **Test redirect handling.** Configure your first controlled endpoint to return one redirect to the second controlled canary. First verify both endpoints independently. Submit the first URL and correlate logs to show whether the second destination was validated. An initial allowlist check is insufficient if the actual redirected destination crosses the rule. Where authorized, study DNS validation/connection consistency in the replica with a controlled resolver; do not perform Internet-wide rebinding experiments. [OWASP SSRF prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html).
5. **Inspect authority and output.** Check whether a synthetic authorization header, test cookie, or privileged worker identity reaches the receiver unexpectedly. If the app displays a response, return only a fixed canary string. Distinguish blind connectivity from a readable internal response, and identify whether headers, method, body, or destination are attacker-controlled.
6. **Interpret and stop.** Correlate exact marker, time, source, request, and job. Rule out your browser, webhook delivery by design, scanners, and unfurling services. Stop after the first controlled boundary violation; do not sweep adjacent hosts or ports. Shut down canaries and delete test jobs.

### Command card

Run the receiver in a new empty directory in one terminal. This Python server serves only the canary directory and binds loopback. It is a local test receiver, not production hosting. [Python HTTP server](https://docs.python.org/3/library/http.server.html).

```bash
mkdir -p ssrf-canary
printf '%s\n' 'BB-SSRF-CANARY-01' > ssrf-canary/probe.txt
python3 -m http.server 8765 --bind 127.0.0.1 --directory ssrf-canary
```

In another terminal, send one request to your local application's observed fetch route. The example assumes same-host processes and JSON request data.

```bash
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -H 'Content-Type: application/json' \
  --data '{"url":"http://127.0.0.1:8765/probe.txt?case=BB01"}' \
  http://127.0.0.1:8000/api/preview
```

### Report threshold and checklist

Report the prohibited destination or credential boundary actually reached. Label DNS-only evidence and environmental limitations explicitly. An open redirect or successful public image import alone does not prove internal access.

- [ ] Feature's destination contract written down.
- [ ] Receiver ownership and worker network namespace established.
- [ ] Ordinary fetch and rejected control recorded.
- [ ] Redirect destination and credential behavior inspected.
- [ ] No metadata secrets, unrelated internal addresses, or port sweeps used.

Local curl examples bypass environment proxies with `--noproxy '*'`; `-q` alone only suppresses curl configuration files. These snippets target loopback and do not follow redirects. [curl manual](https://curl.se/docs/manpage.html).


### Resolver, retry and connection identity

In source review, trace the URL parser, A/AAAA lookup, selected socket address, redirect handling and retry path as one decision. Verify the checked address is the one actually connected to; a second resolution, IPv6 path, alternate IP representation, redirect or worker retry must not escape the intended policy. For a DNS-change hypothesis, use a controlled resolver and designated canaries in the replica, record returned addresses and actual connections, and compare with a fixed-answer control. Merely accepting an unusual URL spelling does not prove a prohibited connection. Keep TLS verification enabled where HTTPS is used; do not change the client trust model to make the proof succeed. [OWASP SSRF prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html).


## Vulnerability reverse references

- [Server-side request forgery (SSRF)](#page-vulnerabilities-ssrf-forbidden-destination) — A server-side fetch crosses the feature’s destination, network, or credential policy.
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution) — An XML parser resolves untrusted external entities across an unintended file or network boundary.


---

<a id="page-modules-browser-trust"></a>

# Browser execution, cross-origin reads, and forged actions

Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

## Investigation sequence

1. Locate source and browser sink
2. Prepare two controlled origins
3. Establish normal behavior
4. Run browser-feasible probe
5. Verify execution or state
6. Remove stored content

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Use two controlled accounts and separate browser profiles. For cross-origin tests, use a researcher page and the local target on different ports; these are different origins but may still be the same site. For conclusions involving SameSite cookies, reproduce with genuinely different sites in an authorized HTTPS setup. Record browser version, cookie attributes, CSP, iframe sandboxing, request initiator, and navigation context.

The invariant is: **a lower-trust origin or stored value cannot execute in the application origin, read protected responses, or cause an unauthorized credentialed action**. Each of those outcomes is a separate test. [XSS](https://portswigger.net/web-security/cross-site-scripting), [CSRF](https://portswigger.net/web-security/csrf), [CORS](https://portswigger.net/web-security/cors).

### Numbered test procedure

1. **Map sources and sinks.** Start with a distinctive text marker. Track it through reflected HTML, attributes, JavaScript strings, DOM insertion, Markdown preview, stored comments, embedded documents, and `postMessage` handlers. Record what is escaped and whether rendering occurs server-side or in JavaScript. Do not copy one payload across unrelated contexts.
2. **Build a normal and inert control.** As A, save plain text into a private object B is allowed to view. Verify B sees it. An HTML-escaped version is the inert comparison. For a local HTML text sink, a marker-only example is `<img src=x onerror="document.documentElement.dataset.bb='BB-XSS-01'">`. Inspect B's DOM for the resulting attribute; the payload never reads cookies or sends data. If CSP blocks execution, preserve that outcome instead of claiming execution.
3. **Test CSRF delivery.** Capture B's normal reversible preference change. From the controlled other origin, reproduce it using a browser-deliverable form or fetch request without a manually inserted target bearer token. Verify which cookies were actually sent, whether preflight occurred, and whether the setting changed in a fresh target tab. Use an invalid CSRF token or logged-out profile as a control. A manually edited HTTP request is not by itself a browser exploit.
4. **Test CORS reads.** From the researcher page, call a private test endpoint with `credentials: 'include'` and attempt to read the response body. Compare an allowed application origin, the researcher origin, and an anonymous request. Save the actual browser result and credential behavior. A request reaching the server is different from JavaScript reading its response; wildcard origins do not enable credentialed response access. [Browser CORS behavior](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS).
5. **Test messages and embedding where present.** For an observed `postMessage` handler, send the expected message shape from your controlled page and change only the sender origin. Verify a harmless state marker or a restricted action on your account. For iframe interaction, prove the sensitive action is practically inducible, rather than reporting absent framing headers alone.
6. **Interpret delivery and cleanup.** Record which account planted content, which viewed it, the effective origin, and the boundary crossed. Remove stored payloads and reverse preference changes. A payload that only executes after the tester pastes JavaScript into DevTools has not established an application injection path.

### Command card

Create `browser-probe/index.html` locally with this content, then serve it using the command below. Open it while the separate controlled target session exists; confirm that your browser's cookie policy permits the intended experiment.

```html
<!doctype html><meta charset="utf-8"><pre id="result"></pre>
<script>
fetch('http://127.0.0.1:8000/api/me', {credentials: 'include'})
  .then(r => r.text())
  .then(t => { document.querySelector('#result').textContent = t; })
  .catch(() => { document.querySelector('#result').textContent = 'Read blocked or request failed'; });
</script>
```

```bash
python3 -m http.server 8766 --bind 127.0.0.1 --directory browser-probe
```

### Report threshold and checklist

Report cross-user execution, a browser-readable private response, or a forged protected state change with realistic delivery. Reflection, arbitrary Origin acceptance in curl, missing CSRF tokens, and same-site laboratory results generalized to cross-site attacks are common false positives.

- [ ] Real browser reproduces the claimed behavior.
- [ ] Origin and site relationships recorded separately.
- [ ] Credentials, CSP, preflight, and redirects observed.
- [ ] Benign marker demonstrates only the required impact.
- [ ] Stored content and account settings cleaned up.

## Vulnerability reverse references

- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution) — Attacker-controlled input executes in another controlled user’s browser under the application origin.
- [DOM-based cross-site scripting](#page-vulnerabilities-dom-xss-source-sink-flow) — Browser-side code moves attacker-controlled data into an executable DOM or script sink.
- [Cross-site request forgery (CSRF)](#page-vulnerabilities-csrf-browser-forged-state-change) — A browser can be induced to perform a protected state change using ambient credentials.
- [CORS private-data exposure](#page-vulnerabilities-cors-private-credentialed-read) — A lower-trust origin can read a protected response using the controlled user’s browser credentials.
- [Cross-origin messaging trust failure](#page-vulnerabilities-postmessage-origin-validation) — A message handler trusts an unauthorized sender or leaks protected data to an unintended origin.
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation) — Uploaded content is handled in a security-sensitive context beyond its permitted file contract.
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking) — A page on another origin opens an authenticated socket and reads or performs protected operations.
- [Untrusted WebView content reaches a native bridge](#page-vulnerabilities-mobile-webview-native-bridge) — A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.
- [Electron IPC exposes main-process authority to an untrusted sender](#page-vulnerabilities-electron-ipc-confused-deputy) — An attacker-controlled renderer or frame invokes a privileged main-process operation through insufficient sender or argument validation.
- [Open redirect across an origin trust boundary](#page-vulnerabilities-open-redirect-trust) — Attacker input controls a navigation destination that the application treats as trusted.
- [Clickjacking of a sensitive authenticated action](#page-vulnerabilities-clickjacking-sensitive-action) — An untrusted origin can frame and visually disguise an authenticated operation.
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority) — An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.


---

<a id="page-modules-file-boundaries"></a>

# Uploads, downloads, paths, archives, and XML

Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

## Investigation sequence

1. Map file lifecycle
2. Seed harmless canaries
3. Change one file property
4. Check parser and destination
5. Verify another controlled reader
6. Remove every derivative

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud)

### Setup and invariant

Use a local replica, a tiny supported file, two controlled accounts, and a dedicated scratch directory. Identify upload handler, object store, converter, background worker, CDN/download route, and deletion path. Place a unique harmless canary just outside the permitted download root, through normal local filesystem access. The invariant is: **user-controlled file metadata or contents cannot escape storage, interpretation, or ownership rules**.

Separate filename, MIME declaration, actual bytes, storage key, filesystem path, and retrieval origin. Each component may normalize them differently. Acceptance of an unusual extension alone does not prove unsafe execution. [Upload handling](https://portswigger.net/web-security/file-upload).

### Numbered test procedure

1. **Record a supported baseline.** Upload a tiny text/image fixture through the documented route. Save its object ID, resulting filename, declared and detected type, processor status, retrieval headers, and response bytes. Verify A can retrieve it and B cannot when the file is private.
2. **Change one property.** Resubmit the same harmless content with a different filename or MIME declaration, independently. For a type-restricted image endpoint, text labeled `image/png` should either fail or be safely handled. Inspect the stored result and actual browser rendering. Do not upload executable shells or server configuration files to demonstrate an extension mismatch.
3. **Check path containment.** In the local replica, request the planted out-of-root marker using one relevant `../` path. Compare a valid in-root file and a nonexistent sibling path. Preserve the raw request target and server-resolved path; a client or proxy may normalize dot segments before they reach the application. If testing writes, use only a dedicated disposable output directory and check that an outside marker is not created. [Path traversal](https://portswigger.net/web-security/file-path-traversal).
4. **Check ownership through derivatives.** As B, request A's controlled original, thumbnail, conversion result, archive export, and any observed signed URL. Record whether the URL is intentionally a share capability and its documented lifetime. Deleting the primary record does not prove every derivative became inaccessible; evaluate the product's promised behavior.
5. **Check archive and XML processing locally.** For an extractor, create a tiny archive with one ordinary member and one canary path outside its designated extraction directory; inspect resolved paths without overwriting anything important. For an XML parser, compare a plain literal field with one external entity referencing the controlled HTTP canary from the SSRF module. Correlate callback logs and returned marker. Do not use recursive entities, oversized documents, or operating-system files. XML acceptance or a DOCTYPE error alone is not external-entity resolution. [XXE](https://portswigger.net/web-security/xxe).
6. **Interpret downstream effects.** Wait for the single test job to finish. Compare bytes, filesystem location, ownership, browser origin, and any parser callback. Source review should locate the exact join/extraction/parse operation and whether containment checks occur after normalization. Delete originals, derivatives, exports, and queued test jobs.

### Command card

This creates a local download fixture. Configure the replica's allowed download directory as `file-lab/public`; illustrative endpoint and parameter names must match the application.

```bash
mkdir -p file-lab/public evidence/files
printf '%s\n' 'BB-INSIDE-01' > file-lab/public/inside.txt
printf '%s\n' 'BB-OUTSIDE-01' > file-lab/outside.txt
curl -q --noproxy '*' --max-time 10 --get --header @A.header \
  --data-urlencode 'name=inside.txt' \
  -o evidence/files/baseline.txt \
  http://127.0.0.1:8000/api/download
curl -q --noproxy '*' --max-time 10 --get --header @A.header \
  --data-urlencode 'name=../outside.txt' \
  -o evidence/files/traversal.txt \
  http://127.0.0.1:8000/api/download
```

### Report threshold and checklist

Report a proven outside-root read/write, unauthorized controlled-file access, unsafe browser/server interpretation, or prohibited parser fetch. A reflected filename, harmless stored extension, public sharing by design, and asynchronous rejection are frequent false positives.

- [ ] Upload and retrieval rules documented independently.
- [ ] Only tiny, synthetic files and dedicated canaries used.
- [ ] Filename, MIME, contents, and ownership varied separately.
- [ ] Raw request and resolved destination retained.
- [ ] Processed derivatives included in evidence and cleanup.

Local curl examples bypass environment proxies with `--noproxy '*'`; `-q` alone only suppresses curl configuration files. These snippets target loopback and do not follow redirects. [curl manual](https://curl.se/docs/manpage.html).


### Containment beyond dot segments

For a link-capable filesystem or archive format, test a tiny symbolic-link fixture in the disposable directory as a separate case. Point it only to the already-planted harmless outside canary, then exercise the product's real reader/extractor. Record the final resolved destination and the identity that opened it. A lexical `..` rejection does not establish containment when links, absolute member paths, platform separators, or case collisions change the destination. Do not generalize a local administrator-created link into a remote vulnerability: show how the stated attacker can create or influence that link through the product.

Pin the runtime and actual extraction API/filter. Python's tar extraction filters can reject outside destinations and links, but filter availability, explicit overrides, and additional resource limits matter. A failed extraction may also leave earlier members on disk; inspect and remove only the disposable output. If a TOCTOU claim depends on replacing a path between validation and opening, demonstrate that timing separately in the replica; a static link test does not prove a race. [Python extraction filters and limitations](https://docs.python.org/3/library/tarfile.html#extraction-filters).

- [ ] Final resolved file or link target stays inside the intended root.
- [ ] Actual runtime/filter and partial-extraction cleanup documented.


## Vulnerability reverse references

- [Reflected or stored cross-site scripting](#page-vulnerabilities-xss-reflected-stored-origin-execution) — Attacker-controlled input executes in another controlled user’s browser under the application origin.
- [Unsafe upload interpretation or placement](#page-vulnerabilities-unsafe-upload-interpretation) — Uploaded content is handled in a security-sensitive context beyond its permitted file contract.
- [Path traversal outside an allowed root](#page-vulnerabilities-path-traversal-controlled-canary) — A controlled path escapes the intended filesystem or object-key boundary.
- [XML external entity injection (XXE)](#page-vulnerabilities-xxe-external-entity-resolution) — An XML parser resolves untrusted external entities across an unintended file or network boundary.
- [Archive extraction path escape](#page-vulnerabilities-archive-extraction-path-escape) — An archive member is extracted outside its designated output directory.
- [Content-provider permission or URI-grant escape](#page-vulnerabilities-android-provider-grant) — A recipient obtains data or file capabilities beyond the URI and permissions deliberately shared with it.
- [Extension input crosses an iOS shared-container boundary](#page-vulnerabilities-ios-shared-container-trust) — The main application trusts content written through a lower-trust extension/input path as if it were an authorized app action.
- [Desktop protocol handler misinterprets external input](#page-vulnerabilities-desktop-protocol-confusion) — An OS-dispatched URL reaches a native command or operation with attacker-controlled arguments outside the intended handler contract.
- [Privileged updater consumes lower-user-controlled staging content](#page-vulnerabilities-updater-privileged-staging) — A standard user can replace a staged file or redirect a path actually consumed by a privileged installation process.
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure) — An error or debug output crosses a confidentiality boundary by revealing protected state.
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing) — A protected data format permits security-relevant changes that are not detected before use.


---

<a id="page-modules-state-business-logic"></a>

# Workflow invariants, replay, idempotency, and races

Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.

## Investigation sequence

1. Write business invariant
2. Capture normal transitions
3. Change ordering or replay
4. Compare serial control
5. Try bounded lab concurrency
6. Verify committed state

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3)

### Setup and invariant

Choose one reversible workflow in a local or nonfinancial sandbox: accepting an invitation, creating one test resource, applying a test credit, approving a draft, or consuming a one-time action. Write the exact invariant, for example: **one invitation grants at most one membership, to its intended recipient and role**. Record preconditions, state transitions, actor permissions, durable result, retries, and cleanup. Logic findings depend on intended rules, not whether the request is technically valid. [Business logic](https://portswigger.net/web-security/logic-flaws).

### Numbered test procedure

1. **Draw the normal transition table.** List draft → submitted → approved → completed, or the product's actual equivalent. For each edge, record actor, required prior state, immutable fields, and transaction identifier. Perform one normal run with synthetic objects and save before/after state, not just HTTP responses.
2. **Test skipped and reordered transitions.** On a fresh disposable object, attempt the observed completion request before approval. Then change only a value that should be frozen after approval, such as recipient or test quantity. Compare with a fully approved control and an invalid object ID. If a transition is intentionally optional, adjust the invariant rather than treating missing UI steps as a bug.
3. **Test serial replay.** Repeat the same completed operation once after it settles. For documented idempotency keys, compare the same key/same body with the same key/different body, using sandbox data. Determine whether keys are scoped by actor, tenant, endpoint, and expiry. Returning the first result again can be correct idempotent behavior.
4. **Test boundary values selectively.** Use zero, a single negative value, or a precision boundary only where the sandbox permits it. Record server-calculated totals and immutable values. Avoid real billing, inventory, refunds, transfers, or customer notifications. A strange displayed number without a committed consequence is not enough.
5. **Test concurrency only in an authorized setting.** First demonstrate expected serial behavior. Reset a test object, then send exactly two simultaneous requests as a small experiment. The local example below uses a barrier; it does not guarantee server arrival within the vulnerable interval. If there is no overlap, record inconclusive timing rather than absence of a race. More aggressive synchronization belongs in the isolated lab. [Race conditions](https://portswigger.net/web-security/race-conditions).
6. **Inspect after completion.** Wait for both requests and relevant workers. Count durable memberships/resources or inspect the ledger of synthetic events. Two success responses may correspond to one commit. Repeat only to resolve a specific uncertainty, then restore the object and stop at the first demonstrated invariant failure.

### Command card

This sends exactly two requests to a disposable local invitation endpoint. Put a valid local test bearer token in `A.token`, with restrictive permissions, and replace the route with the observed one. Create a fresh invitation for each serial/concurrent comparison. Run against localhost only.

```python
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
from threading import Barrier
from urllib.request import Request, build_opener, ProxyHandler, HTTPRedirectHandler
from urllib.error import HTTPError

class NoRedirect(HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        return None

gate = Barrier(2)
token = Path('A.token').read_text().strip()
def attempt(index):
    req = Request('http://127.0.0.1:8000/api/invitations/TEST-INVITE/accept',
                  data=b'{}', method='POST',
                  headers={'Authorization': 'Bearer ' + token,
                           'Content-Type': 'application/json'})
    gate.wait()
    try:
        with build_opener(ProxyHandler({}), NoRedirect()).open(req, timeout=10) as response:
            return index, response.status, response.read(1024).decode(errors='replace')
    except HTTPError as error:
        return index, error.code, error.read(1024).decode(errors='replace')

with ThreadPoolExecutor(max_workers=2) as pool:
    print(list(pool.map(attempt, range(2))))
```

### Report threshold and checklist

Report a durable violation of the stated rule, with serial controls, initial conditions, minimal request sequence, and final state. Duplicate responses, transient UI counters, expected retries, and intentionally cumulative operations are common false positives. Describe the demonstrated consequence; do not infer financial loss from a sandbox counter alone.

- [ ] Business rule and expected actor written down.
- [ ] Normal and serial-replay controls completed.
- [ ] Fresh fixture used for each experiment.
- [ ] Only bounded authorized concurrency used.
- [ ] Durable state and asynchronous effects verified.

The Python example disables environment proxies and redirect following. A redirect is captured by the HTTPError branch; inspect its destination before any separate request.


### Events that arrive after the request

Apply the same invariant to workers and integration events, not only the HTTP endpoint. Record a deduplication key's scope and when it becomes durable relative to the protected effect. A claim written before a worker fails can lose work; a claim written after the effect can permit duplicates. Use an instrumented fault point in the replica to distinguish these cases, and inspect committed state after retry. Then run the [webhook event integrity procedure](#page-modules-webhook-event-integrity) for signature, event ownership and out-of-order delivery checks. Do not assume provider delivery time is a reliable object version or that an HTTP acknowledgement proves processing completed.


## Vulnerability reverse references

- [Race condition in a security-sensitive transition](#page-vulnerabilities-race-condition-duplicate-transition) — Concurrent operations violate a rule that holds when the same actions run serially.
- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass) — An actor can complete a protected workflow without its required prior approval or immutable conditions.
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay) — A replay creates another protected effect where the operation must be unique or idempotent.
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect) — A response-loss or resume path duplicates an operation whose application contract requires at-most-once effect.
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit) — An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.


---

<a id="page-modules-api-protocols"></a>

# REST, GraphQL, gRPC, WebSocket, and SSE permission parity

Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

## Investigation sequence

1. Inventory observed operations
2. Choose one permission invariant
3. Compare controlled identities
4. Test alternate protocol path
5. Check stream lifecycle
6. Record semantic result

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Start from normal client traffic and supplied API schemas. Create two controlled accounts and private synthetic objects. Map REST paths, GraphQL operations/fields, gRPC methods, and WebSocket message types to the same business action. The invariant is: **changing transport, API version, batching, or connection lifetime does not widen an actor's permission**. Reuse the authorization matrix and session modules; protocol-specific testing adds delivery details rather than duplicating those foundations.

### Numbered test procedure

1. **Build a semantic inventory.** Record operation name, method/path, actor, tenant selector, object ID, request schema, response fields, and side effects. Observe one success and one forbidden controlled-object request per available protocol. Preserve response bodies, GraphQL errors, gRPC status/trailers, or socket messages; HTTP status alone does not define application success.
2. **Check REST parity.** Replay the same controlled-object rule through observed v1/v2 routes, nested resources, exports, and a two-item batch. Compare read, update, and server-controlled properties independently. An alternate route being live is not a vulnerability unless its behavior violates the intended permission or lifecycle rule.
3. **Check GraphQL resolvers and fields.** Begin with the client's existing query. As B, change only A's known object ID, then request one protected field omitted from B's normal response. Try the observed global-node route if present. Use at most two aliases as a bounded comparison of resolver behavior; do not use recursive depth or massive aliases. A schema or introspection response helps discovery but is not a confidentiality breach by itself. Where cookie authentication and alternate HTTP methods exist, check a reversible mutation through the observed transport: GraphQL GET is for queries, not mutations. If claiming CSRF, prove delivery in a real browser using the [browser-trust procedure](#page-modules-browser-trust). Persisted query IDs are operation selectors, not permission proofs. [GraphQL HTTP semantics](https://graphql.org/learn/serving-over-http/). [GraphQL testing](https://portswigger.net/web-security/graphql).
4. **Check gRPC context.** Use the provided `.proto` file or authorized reflection to identify one method. Compare channel identity, per-call credentials, tenant metadata, and the selected resource. Repeat a forbidden request with B's genuine credentials, not a token fabricated from decoded claims. For streaming methods, check whether a permitted start improperly authorizes later messages for another controlled resource. Channel credentials and call credentials serve different roles. If an HTTP/JSON transcoding gateway or gRPC-Web route is actually deployed, replay this same invariant there: a translated request can travel through different authentication middleware. Preserve the gateway path and backend method instead of inferring exposure from a `.proto` annotation. [HTTP/JSON transcoding](https://docs.cloud.google.com/endpoints/docs/grpc/transcoding). [gRPC authentication](https://grpc.io/docs/guides/auth/).
5. **Check WebSocket and SSE lifecycle.** Capture a normal handshake and one subscription message. In B's profile, request A's private room using its known ID; have A send a single harmless marker. Remove B from a previously shared room and test one further message on the existing socket. For cross-site hijacking, use a real controlled origin and actual browser cookies. An accepted forged Origin header from a nonbrowser client does not prove browser delivery. [OWASP WebSocket security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html).
For server-sent events, use the observed event endpoint with A and B, then remove B and inspect one new synthetic event. A reconnect cursor or `Last-Event-ID` selects delivery position; test that it cannot select another controlled tenant's history. Close the browser EventSource during cleanup because it normally reconnects automatically. [SSE connection and reconnection](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events).

6. **Interpret and consolidate.** Read partial data as well as error arrays; an error on one field can coexist with leaked data elsewhere. Correlate socket subscription IDs and asynchronous messages. Group instances by shared root cause only when the evidence supports it, and name untested transports explicitly. Close sockets and remove test resources.

### Command card

Prepare protected `A.header` and `B.header` files as described in the [authorization module](#page-modules-authz-matrix). The example assumes the local schema exposes `document(id:)`. Replace it with the already observed query, not an invented production operation. The second request changes only identity.

```bash
mkdir -p evidence/protocols
cat > document-query.json <<'JSON'
{"query":"query($id:ID!){document(id:$id){id title}}","variables":{"id":"O1"}}
JSON
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -H 'Content-Type: application/json' --data @document-query.json \
  -o evidence/protocols/a.json http://127.0.0.1:8000/graphql
curl -q --noproxy '*' --max-time 10 --header @B.header \
  -H 'Content-Type: application/json' --data @document-query.json \
  -o evidence/protocols/b.json http://127.0.0.1:8000/graphql
```

For a local socket, use the browser's Network → WS view to copy the observed message schema. Change one controlled room ID and send one message; protocol libraries often add framing, acknowledgements, or subscription IDs that a generic text frame would omit.

### Report threshold and checklist

Report forbidden controlled data/action, a protected-field leak, or unauthorized ongoing delivery after the applicable revocation point. Reflection, introspection, websocket connectivity, and partial errors without forbidden output are discovery observations.

- [ ] Normal client operation and schema preserved.
- [ ] Same permission rule compared across available transports.
- [ ] Application-level errors and partial output inspected.
- [ ] Authentication at connection and message levels distinguished.
- [ ] Every stream closed and fixture cleaned up.

## Vulnerability reverse references

- [Broken object-level authorization (BOLA / IDOR)](#page-vulnerabilities-bola-controlled-object-access) — An actor can access another owner’s protected object by supplying its identifier.
- [Broken function-level authorization (BFLA)](#page-vulnerabilities-bfla-restricted-function) — A lower-privilege actor invokes a function reserved for another role.
- [Broken property authorization: private response fields](#page-vulnerabilities-bopla-private-response-property) — An otherwise permitted object response includes fields the actor is not entitled to read.
- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass) — A session that has not completed required authentication can perform protected operations.
- [Residual access after explicit session revocation](#page-vulnerabilities-session-revocation-residual-access) — A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.
- [GraphQL resolver or field authorization failure](#page-vulnerabilities-graphql-resolver-field-authz) — A GraphQL path or protected field bypasses the permission enforced for the same object elsewhere.
- [WebSocket message or subscription authorization failure](#page-vulnerabilities-websocket-message-authorization) — A valid connection performs unauthorized per-message actions or receives a private subscription.
- [Cross-site WebSocket hijacking](#page-vulnerabilities-cross-site-websocket-hijacking) — A page on another origin opens an authenticated socket and reads or performs protected operations.
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass) — A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.
- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure) — An operation consumes an unconstrained protected resource through input size, fan-out, queued work, output size or retries.


---

<a id="page-modules-proxy-cache"></a>

# Proxy normalization, cache isolation, and request boundaries

Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.

## Investigation sequence

1. Map HTTP processing layers
2. Prove isolation
3. Establish normal cache behavior
4. Change one interpretation input
5. Verify second controlled client
6. Purge and document

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network)

### Setup and invariant

Use a local proxy plus application, or a program-provided isolated cache namespace and upstream pool. Record protocol on each hop, request normalization, cache key, cache policy, authentication placement, and whether connections are reused. The invariant is: **all layers agree on the request target, request boundary, and which client may receive a cached representation**. These tests can affect requests other than your own; an unproven random query parameter is not isolation.

### Numbered test procedure

1. **Map the layers.** From configuration or operator-provided logs, identify browser → CDN/proxy → application. Capture an ordinary controlled URL from two independent clients. Record `Age`, cache-status headers where present, `Vary`, `Cache-Control`, effective host/path, and origin logs. A header name or latency difference alone does not establish caching.
2. **Prove the test namespace.** Configure a dedicated local path or verified cache-key component. Request two distinct canary paths and confirm they remain separate through origin and cache logs. A query string may be ignored, normalized, or partially keyed. If separation cannot be established in a shared environment, keep mutation experiments in the replica.
3. **Test cache poisoning.** On a fresh isolated key, vary one input that changes origin output but may not be in the cache key, such as an observed forwarding header used in a generated absolute link. Use a harmless marker host under your control. Make a second request without that input and inspect whether the marker persists. Confirm a control key remains clean. The evidence must show an altered representation served from shared cache to the second controlled client. [Cache poisoning](https://portswigger.net/web-security/web-cache-poisoning).
4. **Test cache deception.** Create a private page containing A's unique synthetic marker. In the lab, compare the canonical path with one suffix/path-normalization variant that the origin resolves to the same page but the cache may treat as static. Request that variant as A, then as anonymous B. Verify B receives A's marker because of caching; compare B's direct origin response or a fresh key. Sharing via an intentionally public capability URL is not deception. [Cache deception](https://portswigger.net/web-security/web-cache-deception).
5. **Test parsing agreement in isolation.** Capture the bytes seen by front end and backend for a normal request. In the lab, create one malformed framing case and observe whether both components reject it consistently. For ambiguous length/framing, verify how many requests each layer parsed and where the second controlled request begins. Do not treat a timeout as proof, or use unrelated users' responses to demonstrate desynchronization. HTTP/1.1 framing and HTTP/2-to-HTTP/1 translation must be assessed separately. [HTTP/1.1 framing](https://www.rfc-editor.org/rfc/rfc9112.html), [Request smuggling](https://portswigger.net/web-security/request-smuggling).
6. **Verify consequence and clean up.** Save origin/cache logs, exact requests, normalized targets, cache keys, and client identities. Purge only the dedicated test namespace or restart the disposable cache. Report whether the outcome is poisoned content, private response disclosure, authorization normalization bypass, or request-boundary disagreement; those are distinct findings.

### Command card

These ordinary requests establish a local cache baseline. Configure `/bb-cache/case-01` and `/bb-cache/case-02` as separate keys in your own proxy first. A later poisoning probe must vary only a specific source-identified input.

```bash
mkdir -p evidence/cache
curl -q --noproxy '*' --max-time 10 -D evidence/cache/first.h \
  -o evidence/cache/first.txt http://127.0.0.1:8080/bb-cache/case-01
curl -q --noproxy '*' --max-time 10 -D evidence/cache/second.h \
  -o evidence/cache/second.txt http://127.0.0.1:8080/bb-cache/case-01
curl -q --noproxy '*' --max-time 10 -D evidence/cache/control.h \
  -o evidence/cache/control.txt http://127.0.0.1:8080/bb-cache/case-02
```

### Report threshold and checklist

Report a controlled second-client effect or demonstrated parser disagreement with a meaningful security boundary. Mere caching, unexpected 400/502 responses, reflected Host values, and differences caused by the testing proxy are common false positives.

- [ ] Cache namespace and upstream isolation verified.
- [ ] Every HTTP hop and protocol recorded.
- [ ] Normal, mutated, second-client, and clean-key controls saved.
- [ ] No production response-queue capture or broad desync probing.
- [ ] Test cache entries purged after evidence collection.

Local curl examples bypass environment proxies with `--noproxy '*'`; `-q` alone only suppresses curl configuration files. These snippets target loopback and do not follow redirects. [curl manual](https://curl.se/docs/manpage.html).


### Cache semantics and revocation control

Interpret response directives precisely: unqualified `no-cache` permits storage but requires validation before reuse; `no-store` prohibits storage/reuse subject to the specification's defined exceptions; unqualified `private` prevents shared-cache storage but permits private-cache storage. `Set-Cookie` alone does not disable caching. Requests containing `Authorization` have special shared-cache restrictions, with explicit exceptions such as `public` and `s-maxage`; cookie-authenticated requests need their own correct response policy and cache partitioning. Read the effective configuration and observe behavior. [RFC 9111, sections 3.5, 5.2 and 7.3](https://www.rfc-editor.org/rfc/rfc9111.html).

In an isolated namespace, compare A, anonymous B, and a fresh control key after A changes or deletes the private marker. Also exercise one normal conditional request if the application uses validators. Inspect which identity the origin checked and which stored body the cache reused after a `304`. Do not infer privacy from an `Age: 0`, absent cache header, or an initial miss. Report stale post-revocation access against the product's promised lifecycle, distinguishing a previously downloaded copy from a newly served shared response.

- [ ] Storage, revalidation and private/shared-cache behavior distinguished.
- [ ] Fresh, cached and post-change responses compared where applicable.


## Vulnerability reverse references

- [Web cache poisoning](#page-vulnerabilities-web-cache-poisoning-unkeyed-input) — Unkeyed attacker-controlled input changes a representation later served from shared cache.
- [Web cache deception](#page-vulnerabilities-web-cache-deception-private-response) — A path/cache-policy discrepancy stores a private response for retrieval by another client.
- [HTTP request smuggling / desynchronization](#page-vulnerabilities-http-request-boundary-desynchronization) — Two HTTP-processing components disagree about request boundaries or parsing.
- [Untrusted Host or forwarding-header origin construction](#page-vulnerabilities-host-header-origin-trust) — The application constructs a security-sensitive origin from request metadata that an attacker can influence.


---

<a id="page-modules-oss-lab-reproduction"></a>

# OSS lab: pin, install, prove, reset

Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.

## Investigation sequence

1. Qualify release
2. Freeze inputs
3. Review installation
4. Build fixtures
5. Compare controls
6. Reset and repeat

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Start with a reproducibility contract

Record repository, product edition, supported release, immutable commit, package locks, image digests, operating system, database, authentication mode, and enabled extensions. Keep **tested**, **inferred**, and **unknown** versions separate. A source tag does not identify the image running in a vendor deployment. Your initial output is a manifest plus a working baseline, before any vulnerability attempt.

Use a disposable VM for an unfamiliar project's build. Review its Dockerfiles, build backends, package lifecycle scripts, Makefiles, and downloaded installers first. Provide synthetic credentials and fixtures. Separate dependency preparation from validation; disable unnecessary external integration calls during validation. Preserve the installation instructions you followed and every deviation. This makes it possible to distinguish a supported insecure default from a flaw introduced by the research setup.

## Freeze source without overwriting work

These are adaptable local examples, not a claimed execution. Start with an existing reviewed clone at `./repo`; create a fresh output directory. Substitute a real eligible release in the second command. A detached worktree allows a separate copy at that revision while sharing Git objects. [Git worktrees](https://git-scm.com/docs/git-worktree).

```bash
mkdir -p ./evidence
git -C ./repo rev-parse --verify 'v1.2.3^{commit}'
git -C ./repo worktree add --detach ../lab-source v1.2.3
git -C ./lab-source rev-parse HEAD > ./evidence/source-commit.txt
git -C ./lab-source status --porcelain=v1 > ./evidence/source-status.txt
git -C ./lab-source submodule status --recursive > ./evidence/submodules.txt
```

Expected: a full commit identifier and an initially clean status file. A submodule entry is inventory, not confirmation its source has been obtained or reviewed. Save compiler/runtime/tool versions separately. Never silently replace a failing eligible release with current `main`.

## Review the effective deployment

Compose configuration can interpolate environment values, so use a synthetic lab environment and inspect output before sharing. Render first; check host mounts, image references, ports, capabilities, external volumes, privileged mode, and startup scripts. A project name alone does not isolate explicitly named shared volumes. [Docker Compose config](https://docs.docker.com/reference/cli/docker/compose/config/).

```bash
docker compose -p bounty-lab -f ./lab-source/compose.yaml config \
  > ./evidence/compose-effective.yaml
docker compose -p bounty-lab -f ./lab-source/compose.yaml \
  up -d --wait --wait-timeout 120
```

Run `up` only after review and required dependency preparation. `--wait` depends on declared health checks for application readiness; a running process alone is insufficient. Establish login, ordinary creation, retrieval, and a worker task through the real interface. [Docker Compose up](https://docs.docker.com/reference/cli/docker/compose/up/).

| Fixture | Normal operation | Boundary case |
|---|---|---|
| Tenant A and B | Each reads its own document | A requests B's synthetic document |
| Member and administrator | Administrator manages invitations | Member attempts the same operation |
| Import directory | Valid sample stays inside destination | Malformed sample attempts a harmless boundary crossing |
| Background worker | Queued operation completes once | Membership changes before job execution |

## Preserve the failing and passing stories

Example trace: member A requests an export, the route returns a job ID, and the worker reads a document owned by B. Capture the request, job record, worker resolution, synthetic output, and authorized B control. A direct call to the export helper explains the implementation but does not establish route reachability. Continue in [source data flow](#page-modules-source-dataflow) and reuse the [authorization matrix](#page-modules-authz-matrix).

Diagnose setup failures before testing: a migration error invalidates database assumptions; disabled workers invalidate asynchronous conclusions; missing enterprise features limit edition claims. Record unresolved differences instead of compensating by disabling security controls.

## Reset and report gate

Prefer restoring a dedicated VM snapshot or documented fixture/database snapshot. Include queues, object storage, cache, local mail, and generated files in the reset recipe. Container restart is not state reset. Repeat the minimal reproduction after restoration; a result dependent on an earlier experiment is not yet isolated.

- [ ] Eligible revision, dependency locks, and deployment differences recorded.
- [ ] Normal user workflow and comparison account work.
- [ ] Required worker/integration fixtures are present.
- [ ] Synthetic evidence survives outside reset storage.
- [ ] Clean restoration reproduces the same boundary failure.
- [ ] Report distinguishes product behavior from lab-only configuration.

## Vulnerability reverse references

- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials) — A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization) — Untrusted bytes reach a format that can instantiate behavior-bearing objects or invoke code, such as Python pickle, without a sufficient trust boundary.
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files) — A component creates or reuses temporary files in a way that permits another local principal to precreate, replace, read, or redirect sensitive operations.
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact) — The real update decision accepts modified bytes or an unrelated publisher identity before activation.
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading) — An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.


---

<a id="page-modules-source-dataflow"></a>

# Source review: entry point to protected operation

Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

## Investigation sequence

1. State invariant
2. Find entry
3. Trace transformations
4. Check guards
5. Exercise interface
6. Retest sibling paths

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Write the invariant first

Choose a business rule precise enough to falsify: “a member can export documents only from a project where membership is currently active.” Record actor, object, operation, tenant, and when authorization must hold. A suspicious function becomes useful when you identify who can reach it and what protected state it changes. Reuse the [authorization matrix](#page-modules-authz-matrix) for principal/object combinations and [injection tracing](#page-modules-injection-tracing) for interpreter-specific input handling.

Start forward at a real interface: HTTP route, websocket event, CLI argument, uploaded project, plugin callback, or queue producer. Then work backward from the sensitive read, write, process invocation, parser, or credential use. Join the two traces; unresolved dynamic dispatch is an explicit gap. Check route registration and feature gating rather than assuming a named handler is exposed.

## A worked asynchronous trace

The following is a hypothetical review worksheet, not a finding against a named project.

| Hop | Value or context | Question to resolve |
|---|---|---|
| `POST /exports` | Authenticated member A supplies `document_id` | Does the route check document membership or only login? |
| `ExportService.create` | A job stores `document_id`, `requested_by` | Is the trusted tenant copied from the session or accepted from input? |
| Queue serialization | Job survives after request completes | Can another low-trust producer alter the fields? |
| `run_export(job)` | Worker reloads document by ID | Is current membership enforced at execution time? |
| Object storage write | Export receives a download reference | Who can fetch it, and can authorization expire? |

A useful candidate is “worker rehydrates an object globally after a tenant-scoped request.” Confirm whether the earlier guard binds the *same* immutable identifier, whether membership revocation should affect queued jobs, and whether the output is actually accessible. Business requirements may deliberately snapshot permissions; document that distinction rather than treating every delayed check as defective.

## Local search and modeling cheat sheet

Examples inspect a reviewed local repository. Patterns are leads, not a complete inventory. Place evidence outside the scan root; prepare local rules before offline/private-code analysis.

```bash
rg -n --hidden -g '!.git' \
  'route\(|router\.|websocket|add_task|enqueue|\.delay\(' ./repo
rg -n --hidden -g '!.git' \
  'pickle\.loads|yaml\.load|subprocess\.|child_process|exec\(' ./repo
semgrep scan --oss-only --config ./rules --metrics=off \
  --disable-version-check --json \
  --output ./evidence/source-leads.json ./repo
```

The Semgrep command uses reviewed local rules and the OSS engine. Inspect stderr, skipped files, and scan completion; an empty result with parser failures is not a clean audit. Rule licenses and engine capabilities are separate concerns. [Semgrep CLI reference](https://docs.semgrep.dev/cli-reference).

Model sources, propagation, context-specific sanitizers, and sinks. A path validator does not sanitize a shell argument; a role check does not validate serialized data. Custom wrappers can hide a source or sink from default rules. Create one vulnerable fixture and one safe sibling to validate your model. Static taint analysis does not automatically establish tenant policy or full runtime reachability. [Semgrep taint model](https://docs.semgrep.dev/writing-rules/data-flow/taint-mode/overview).

## Prove the boundary through supported use

Instrument the local application to log identifiers, decisions, and function names without credentials. Reproduce from the ordinary interface with synthetic accounts. Keep four observations together: allowed own-object request; denied or expected-to-deny foreign-object request; actual protected effect; resulting output access. Repeat without instrumentation changing security behavior. If only an internal helper is callable, qualify the finding as a library/caller-contract issue until a consumer path is established.

Inspect alternate callers after proving one flaw: bulk API, export service, websocket subscription, scheduled task, and administrative UI may reuse the same operation with different guards. Group equivalent paths by root cause and record tested variants. Do not inflate one shared defect into five independent findings.

## Completion and report threshold

- [ ] Invariant identifies actor, object, operation, and trust boundary.
- [ ] Attacker-controlled field is tracked through transformations and aliases.
- [ ] Every guard is evaluated with concrete fixture values.
- [ ] Feature, edition, role, and configuration prerequisites are explicit.
- [ ] Real interface reproduces the protected effect beside an authorized control.
- [ ] Safe sibling and patch retest preserve legitimate behavior.

Submit the smallest connected argument: entry point → attacker control → ineffective boundary → sensitive operation → demonstrated impact. A sink search, scanner trace, or direct helper call alone belongs in the hypothesis queue.

## Vulnerability reverse references

- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials) — A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.
- [Unsafe object deserialization](#page-vulnerabilities-unsafe-deserialization) — Untrusted bytes reach a format that can instantiate behavior-bearing objects or invoke code, such as Python pickle, without a sufficient trust boundary.
- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution) — An attacker-controlled property path changes inherited object state, which can affect unrelated objects and security-sensitive consumers.
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write) — A native component writes beyond an allocated object because length, index, or allocation assumptions do not agree.
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free) — Code uses an object after its lifetime has ended, often across callbacks, error handling, reference counting, or asynchronous operations.
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow) — Input-derived arithmetic wraps or overflows so the checked size, allocation size, and later operation refer to different effective values.
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos) — An attacker-controlled string makes the chosen regular-expression engine perform excessive backtracking or other disproportionate matching work.
- [Predictable temporary files and unsafe creation](#page-vulnerabilities-insecure-temporary-files) — A component creates or reuses temporary files in a way that permits another local principal to precreate, replace, read, or redirect sensitive operations.
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path) — A program resolves an executable/library/module from an attacker-writable search location instead of the intended trusted component.
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials) — An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret) — Source, history, or a published artifact exposes a credential outside its intended audience.
- [Sensitive data in errors, debug routes, or generated files](#page-vulnerabilities-sensitive-error-disclosure) — An error or debug output crosses a confidentiality boundary by revealing protected state.
- [Predictable security token or capability identifier](#page-vulnerabilities-weak-security-token-randomness) — A security token relies on randomness that does not meet its unpredictability requirement.
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash) — A password verifier has insufficient computational cost for its supported threat model.
- [Encrypted data accepted without integrity authentication](#page-vulnerabilities-crypto-authentication-missing) — A protected data format permits security-relevant changes that are not detected before use.
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust) — The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading) — An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.


---

<a id="page-modules-supply-chain-ci"></a>

# CI and releases: trace untrusted input into privileged work

Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

## Investigation sequence

1. Identify event trust
2. Map executable input
3. Inspect privileges
4. Follow artifacts
5. Validate locally
6. Verify release identity

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai)

## Draw the actual privilege chain

For every release-capable workflow, record event actor, workflow-file revision, checked-out revision, executable inputs, token permissions, reachable secrets, runner persistence, and final consumer. Distinguish data review from code execution: a checked-out contribution becomes executable through Makefiles, package install hooks, test discovery, plugins, and local actions as well as explicit shell scripts.

Use one row per job. Include reusable workflows and composite actions; apparent isolation at the top-level YAML may disappear inside their implementation. A permissive token setting without a lower-trust entry is a hardening observation, not a completed takeover claim.

| Boundary | Local evidence to collect | Comparison control |
|---|---|---|
| Metadata → generated shell | Original expression and resulting script | Environment variable passed as data |
| Fork content → privileged build | Exact fetched revision and executed file | Trusted base revision only |
| Test artifact → publisher | Producer identity, run association, consumed path | Artifact from expected trusted build |
| Build → attestation → release | Artifact digest and accepted signer identity | Wrong-source artifact rejected |

## Triage commands and a safe coding pattern

These examples inspect local files; they have not been run against a target. Grep-style matching deliberately overselects candidates.

```bash
rg -n --hidden -g '*.yml' -g '*.yaml' \
  'pull_request_target|workflow_run|issue_comment|permissions:|id-token:' \
  ./repo/.github
rg -n --hidden -g '*.yml' -g '*.yaml' \
  'download-artifact|upload-artifact|cache-mode|head\.sha|npm install|make ' \
  ./repo/.github
```

Passing untrusted metadata through an environment variable avoids inserting its contents into the generated shell program. Quote it and do not subsequently `eval` it. This pattern does not solve dangerous argument semantics in downstream tools. [GitHub secure use](https://docs.github.com/en/actions/reference/security/secure-use).

```yaml
- name: Inspect title as data
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: printf '%s\n' "$PR_TITLE"
```

## Check current protections before declaring a pwn request

GitHub currently documents fork-ref checkout protection for `pull_request_target` and read-only default cache access for that event. Inspect action revision, explicit `allow-unsafe-pr-checkout`, `cache-mode`, manual fetches, repository policy, and actual execution. The trigger name alone proves neither execution nor writable cache. Controls can differ from older published examples. [Current pull_request_target guidance](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target).

Hypothetical trace: an unprivileged test job uploads `report.zip`; a privileged follow-up selects an artifact by a generic name; an extracted helper is executed before publication. Validate run/repository binding, extraction destination, and consumer behavior in your own fixture with an inert marker and dummy credentials. A successful workflow conclusion does not authenticate every byte it produced. An artifact parsed strictly as data may break the supposed execution chain. [GitHub Security Lab workflow analysis](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/).

## Follow identity to the shipped artifact

For a known public artifact, this read-only verification example contacts GitHub. Replace repository, workflow, and commit with expected identities established independently; do not copy identities out of the untrusted artifact and then “verify” against them.

```bash
gh attestation verify ./dist/product.tar.gz \
  --repo OWNER/REPO \
  --signer-workflow OWNER/REPO/.github/workflows/release.yml \
  --source-digest EXPECTED_COMMIT \
  --format json > ./evidence/attestation.json
```

A reusable workflow may be the signer rather than the calling workflow. Verified provenance supports an origin claim; it does not prove the builder was uncompromised or the software is vulnerability-free. [GitHub CLI verification](https://cli.github.com/manual/gh_attestation_verify).

Trusted publishing reduces long-lived publish-token exposure, but a compromised authorized workflow can still obtain publishing authority. Review environment approval, workflow identity, build separation, and remaining legacy credentials. [PyPI trusted publisher security model](https://docs.pypi.org/trusted-publishers/security-model/).

## Report and retest gate

- [ ] A permitted low-trust actor controls the demonstrated input.
- [ ] Exact workflow/action revisions and security defaults are captured.
- [ ] Inert local reproduction reaches the privileged consumer.
- [ ] Real permissions are supported by configuration, not guessed from a trigger.
- [ ] Artifact run binding and signer/source identity are checked.
- [ ] Patched data handling rejects the case while normal releases still work.

Report the reachable capability and its prerequisites. Do not run target publishing steps or use discovered tokens to prove a local workflow hypothesis; maintainers can confirm live permissions through a coordinated reproduction when needed.

For GitLab repositories, also use [GitLab pipeline boundaries](#page-modules-gitlab-pipeline-boundaries): parent-project merge-request execution, job-token permissions and runner isolation have distinct semantics.

## Vulnerability reverse references

- [Hard-coded product credentials](#page-vulnerabilities-hardcoded-credentials) — A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.
- [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection) — Pull-request titles, branch metadata, issue fields, or artifact values are inserted into a generated shell/program instead of being handled as data.
- [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution) — A trusted workflow fetches or loads contribution-controlled code, configuration, or dependencies and executes them with authority unavailable to the contributor.
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning) — A higher-trust workflow treats attacker-controlled test/build output as executable code or authoritative release input without adequate producer and content constraints.
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion) — Dependency resolution selects an attacker-controlled package origin where the build or application expects an organization-controlled package.
- [Untrusted executable, library, or module search path](#page-vulnerabilities-untrusted-search-path) — A program resolves an executable/library/module from an attacker-writable search location instead of the intended trusted component.
- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact) — The real update decision accepts modified bytes or an unrelated publisher identity before activation.
- [Exposed repository or history secret](#page-vulnerabilities-exposed-repository-secret) — Source, history, or a published artifact exposes a credential outside its intended audience.
- [GitLab job token crosses an unintended project boundary](#page-vulnerabilities-gitlab-job-token-boundary) — A contribution-controlled job acquires access to a private receiving-project resource beyond the CI integration contract.


---

<a id="page-modules-dependency-reachability"></a>

# Dependencies: from advisory match to reachable impact

Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.

## Investigation sequence

1. Inventory layers
2. Resolve advisory
3. Trace consumer
4. Check prerequisites
5. Compare fixed behavior
6. Bound affected versions

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Keep four questions separate

An SBOM answers what a tool identified in an artifact. An advisory matcher asks whether a component version matches known vulnerability data. Reachability asks whether the relevant implementation is used. Exploitability asks whether an attacker can satisfy the conditions and cross a security boundary. Preserve each conclusion independently; a negative result at one layer does not answer every other layer.

Inventory source locks, installed runtime, development/build dependencies, and final release output separately. A vulnerable parser in a lockfile may be absent from the production image. A development-only package may still run inside a privileged publisher. Record ecosystem, package identity, resolved version, origin, dependency path, optional features, and artifact digest. Use [CI and release analysis](#page-modules-supply-chain-ci) for build impact and [source data flow](#page-modules-source-dataflow) for runtime impact.

## Inventory and match locally

Examples require installed tools, reviewed inherited configuration, existing local paths, and prepared OSV ecosystem databases. They are command templates, not claimed results. `./release-root` means an already extracted, reviewed release tree.

```bash
mkdir -p ./evidence
syft dir:./repo -o cyclonedx-json=./evidence/source.cdx.json
syft dir:./release-root -o cyclonedx-json=./evidence/release.cdx.json
osv-scanner scan source --offline -r --format json \
  ./repo > ./evidence/osv-source.json
```

Syft supports directory inventory and structured SBOM output; detected composition depends on catalogers and available metadata. Compare the two inventories rather than assuming they represent the same execution environment. [Syft documentation](https://github.com/anchore/syft).

OSV source scanning uses supported manifests and lockfiles. Full `--offline` requires cached databases and avoids network activity; `--offline-vulnerabilities` has a narrower meaning and can permit other network features. Missing caches are an incomplete scan. Preserve database age and scanner stderr alongside findings. [OSV source scanning](https://google.github.io/osv-scanner/usage/scan-source), [offline behavior](https://google.github.io/osv-scanner/usage/offline-mode/).

## Build a reachability worksheet for each serious candidate

| Question | Concrete evidence | If unresolved |
|---|---|---|
| Is the resolved component affected? | Exact advisory range, vendored source, backport patch | Version match only |
| Is affected code present? | Release tree, build flags, linked module | Source-only candidate |
| Is the vulnerable API called? | Consumer call site and dynamic trace | Reachability unknown |
| Can an attacker control its argument? | Ordinary route/file/CLI input and transformations | No attacker path established |
| Are prerequisites satisfied? | Parser mode, operating system, feature, privilege | Conditional exposure |
| What changes across the boundary? | Synthetic output or bounded local fault | Impact unproven |

Hypothetical example: a document service ships an affected archive library, but the advisory concerns symbolic-link extraction. Trace upload acceptance → import job → actual extraction API → filter configuration → destination. A safe filter can defeat that specific path even when the version matcher is correct. Conversely, an optional compatibility flag may restore the unsafe behavior. Test supported configurations explicitly and reuse the [pinned lab](#page-modules-oss-lab-reproduction).

## Check package origin as well as version

For dependency confusion, first inspect registry selection, namespace ownership, fallback, lockfiles, integrity hashes, and install hooks. pip documents that candidates from configured locations are considered together, rather than treating an extra index as a guaranteed lower-priority fallback. [pip install index behavior](https://pip.pypa.io/en/stable/cli/pip_install/).

Reproduce with two local registries and synthetic names that belong to your lab. Use packages containing metadata and harmless marker files; record which origin wins under the target's resolver configuration. Do not publish a real organization's missing package name. Resolver selection is one proof step; a product-impact claim must also show an affected build/consumer and applicable package controls.

## Control, report, and completion

Run the same smallest input against the affected and patched dependency in equivalent consumers. If swapping versions also changes application behavior or configuration, isolate that difference before crediting the patch. Test normal input to ensure the “fix” is not simply a broken integration. Avoid claiming every historical release is affected from one sampled version.

- [ ] Source, runtime, build, and release inventories are labeled.
- [ ] Advisory and patch are checked for the exact resolved component.
- [ ] Backports, vendoring, and optional features are considered.
- [ ] Attacker input reaches the affected API through supported use.
- [ ] Local impact and a fixed/control case are preserved.
- [ ] Tested versions, inferred exposure, and unknowns are separated.

The reporting threshold is a reproducible vulnerable use or the program's explicitly accepted dependency criterion. An old version number alone should remain a triage lead.

## Vulnerability reverse references

- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning) — A higher-trust workflow treats attacker-controlled test/build output as executable code or authoritative release input without adequate producer and content constraints.
- [Dependency confusion and unintended package origin](#page-vulnerabilities-dependency-confusion) — Dependency resolution selects an attacker-controlled package origin where the build or application expects an organization-controlled package.
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read) — A parser or native consumer reads outside the valid extent of an object or buffer, potentially causing a crash or disclosure depending on how the result is used.
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion) — A small accepted input causes disproportionate CPU, memory, recursion, or expanded output consumption without effective limits at the relevant consumer.


---

<a id="page-modules-parser-fuzzing"></a>

# Libraries and parsers: bounded fuzzing to a minimal reproducer

Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.

## Investigation sequence

1. Choose contract
2. Build harness
3. Instrument target
4. Fuzz within bounds
5. Minimize root cause
6. Verify consumer impact

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai)

## Choose an attacker-relevant parser contract

Select a public API and a realistic input boundary: imported image, archive, document, packet, model file, project metadata, or CLI input file. Record who supplies bytes, the consumer's preprocessing, format limits, parser options, and the privilege of the process. Fuzzing an internal helper with impossible arguments may reveal a harness defect rather than a violated library contract.

Keep the first harness narrow: one parse operation, deterministic configuration, fresh state for each input, bounded allocations, and cleanup on both success and failure. Remove network and uncontrolled filesystem side effects. Seed with a few valid, small representative samples to reach deeper code; an all-random corpus may spend every iteration failing the magic-header check.

## Harness and build cheat sheet

The following is a **template**: `product_parser.h`, `ProductDocument`, and the parser functions are placeholders to replace with the target's documented API. Return/error ownership must follow that API. The commands have not been executed here.

```cpp
#include <cstddef>
#include <cstdint>
#include "product_parser.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    if (size > 65536) return 0;
    ProductDocument* doc = product_parse(data, size);
    if (doc != nullptr) product_document_free(doc);
    return 0;
}
```

Build the target library itself with compatible sanitizer and coverage instrumentation; instrumenting only the harness misses much of the parser's behavior. Replace the source list with its reviewed build recipe. The example assumes Clang and a compatible C++ project. [AddressSanitizer build guidance](https://clang.llvm.org/docs/AddressSanitizer.html).

```bash
clang++ -g -O1 -fno-omit-frame-pointer \
  -fsanitize=fuzzer,address,undefined -fno-sanitize-recover=undefined \
  ./fuzz_parser.cc ./parser.cc -o ./fuzz_parser
mkdir -p ./corpus ./artifacts ./evidence
./fuzz_parser ./corpus -max_total_time=120 -timeout=2 \
  -rss_limit_mb=512 -max_len=65536 -artifact_prefix=./artifacts/
```

Add reviewed seed files before running. libFuzzer's time, input-length, timeout, and RSS settings bound the campaign; they are not a VM resource boundary. Run inside your local disposable environment with external memory/CPU limits appropriate for the workload. Track new coverage and distinct root causes rather than raw executions. [libFuzzer reference](https://llvm.org/docs/LibFuzzer.html).

## Interpret the failure precisely

| Observation | Immediate question | Defensible first claim |
|---|---|---|
| ASan heap read overflow | Does the public API permit this byte sequence? | Out-of-bounds read in the tested build |
| ASan write overflow | Which length check and allocation disagree? | Out-of-bounds write; execution impact unproven |
| Use-after-free | Did the harness violate ownership rules? | Lifetime defect if public usage is valid |
| UBSan arithmetic finding | Does overflow reach an unsafe allocation/index? | Undefined operation plus traced consequence |
| Timeout or RSS limit | Is it reproducible at modest input sizes? | Bounded evidence of resource exhaustion |

`-fno-sanitize-recover=undefined` makes the selected UBSan failures terminate instead of allowing a fuzzing run to continue after a diagnostic, which helps preserve reproducible failing inputs. UBSan checks selected undefined behaviors, not every arithmetic error. Unsigned integer wrap is defined in C/C++ and is not part of the default `undefined` group; choose additional checks when the target's threat model requires them. [UndefinedBehaviorSanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).

## Minimize and verify the consumer

Copy one candidate into `./artifacts/repro.bin`, then minimize with a unique output path. Preserve the original input, toolchain, build flags, revision, and symbolized trace.

```bash
./fuzz_parser -timeout=2 -rss_limit_mb=512 ./artifacts/repro.bin
./fuzz_parser -minimize_crash=1 -max_total_time=60 -timeout=2 -rss_limit_mb=512 \
  -exact_artifact_path=./artifacts/minimized.bin ./artifacts/repro.bin
```

Replay the minimized bytes through a supported consumer in the [pinned OSS lab](#page-modules-oss-lab-reproduction). If the consumer rejects them before calling the library, report the library contract separately and leave consumer exposure unproven. A sanitizer crash is not proof of remote code execution, and its absence in an optimized build does not erase a confirmed memory-safety defect.

Hypothetical root cause: a header count is multiplied into a narrow allocation size, then a wider loop trusts the original count. Preserve the values, allocation site, failing access, and missing bound. The fix should bind accepted count to available input and checked allocation size; merely suppressing the crash is insufficient.

- [ ] Public API and ownership contract respected.
- [ ] Target code, not only harness, instrumented.
- [ ] Resources, seeds, revision, and toolchain recorded.
- [ ] Minimal input reproduces the same root cause.
- [ ] Normal input succeeds in affected and fixed builds.
- [ ] Library impact and real consumer exposure are stated separately.

Replay timeout and memory artifacts under the same resource limits as discovery. A minimized crash must retain the original root cause; a shorter input that fails differently is not equivalent evidence.


## Vulnerability reverse references

- [JavaScript prototype pollution](#page-vulnerabilities-prototype-pollution) — An attacker-controlled property path changes inherited object state, which can affect unrelated objects and security-sensitive consumers.
- [Out-of-bounds memory read](#page-vulnerabilities-out-of-bounds-read) — A parser or native consumer reads outside the valid extent of an object or buffer, potentially causing a crash or disclosure depending on how the result is used.
- [Out-of-bounds memory write](#page-vulnerabilities-out-of-bounds-write) — A native component writes beyond an allocated object because length, index, or allocation assumptions do not agree.
- [Use after free in a public API or parser lifecycle](#page-vulnerabilities-use-after-free) — Code uses an object after its lifetime has ended, often across callbacks, error handling, reference counting, or asynchronous operations.
- [Integer overflow affecting allocation or bounds](#page-vulnerabilities-integer-overflow) — Input-derived arithmetic wraps or overflows so the checked size, allocation size, and later operation refer to different effective values.
- [Parser resource exhaustion and decompression amplification](#page-vulnerabilities-parser-resource-exhaustion) — A small accepted input causes disproportionate CPU, memory, recursion, or expanded output consumption without effective limits at the relevant consumer.
- [Regular-expression denial of service](#page-vulnerabilities-regex-dos) — An attacker-controlled string makes the chosen regular-expression engine perform excessive backtracking or other disproportionate matching work.


---

<a id="page-modules-cloud-iam-boundaries"></a>

# Cloud IAM: trust, delegation and effective permissions

Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.

## Investigation sequence

1. Pin account and principals
2. Draw authority graph
3. Establish allowed and denied controls
4. Test one delegation edge
5. Reproduce and remove fixtures

## Used in these playbooks

[Cloud & containers](#page-cloud)

## Setup and security invariant

Use two owned accounts or explicitly supplied test identities: an administrator for fixtures, principal A with restricted rights, and principal B representing the allowed integration. Record account IDs, role ARNs, session type, region, policy versions and a synthetic object. The invariant is precise: **A cannot obtain B's authority or make a service exercise it on A's behalf.** Reuse the [authorization matrix](#page-modules-authz-matrix) for rows and evidence naming.

Before cloud testing, check the current provider policy for the exact service and activity. AWS customer testing permission does not extend to attacking the provider itself. [AWS testing policy](https://aws.amazon.com/security/penetration-testing/)

## Procedure

1. **Confirm identity, then map enforcement.** Write one row for caller → trust policy → assumed role → service API → resource. Collect owner-supplied identity and resource policies, session restrictions, boundaries and organization restrictions. An isolated wildcard allow does not establish effective access. Preserve missing policy visibility as an explicit uncertainty. [AWS policy evaluation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)

2. **Create paired controls.** B performs one approved metadata lookup against the canary; A attempts the identical operation and should be denied. Use fresh sessions and the same resource identifier. If both fail, repair the fixture or connectivity before testing a vulnerability hypothesis.

3. **Change one trust input.** With two owned integration identities, compare the documented allowed principal with the disallowed one. For a third-party integration, inspect who assigns the external ID and whether the service ties it to the correct customer. A missing external ID alone is not universally a vulnerability: demonstrate the applicable confused-deputy path. [Third-party role access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)

4. **Test delegation separately.** Review whether A can select a more powerful service role while creating or updating a workload. In an isolated account, use a single approved disposable job that only checks canary metadata. Compare its normal role with the proposed excessive role. Record both workload-creation permission and role trust; PassRole alone is insufficient. The relevant audit event is the service create/update operation because PassRole is a permission, not an independent API event. [PassRole documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)

5. **Check federation claims.** In an owned identity-provider fixture, change only one legitimate token claim: subject, audience, repository, branch or environment, as applicable. Do not forge another organization's identity. Record which rule rejects the negative case. Token correctness and cloud role selection are separate checks; reuse [identity and sessions](#page-modules-identity-session). [OIDC role trust](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)

## Command card

Replace identifiers with the fixture values. Run individually; the profiles must already use owned credentials. Commands inspect identity, trust and one object's metadata.

```bash
aws --profile lab-low sts get-caller-identity \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10

aws --profile lab-owner iam get-role --role-name BountyFixture \
  --query 'Role.{Arn:Arn,Trust:AssumeRolePolicyDocument}' \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10

aws --profile lab-low s3api head-object \
  --bucket OWNED_BUCKET --key bounty/canary.txt \
  --expected-bucket-owner YOUR_ACCOUNT_ID \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10
```

Repeat the last command with the allowed fixture profile. Expect metadata for the allowed principal and denial for A. A denied metadata request can also mean a missing object: establish existence using the owner control. [GetRole CLI](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html), [HeadObject semantics](https://docs.aws.amazon.com/cli/latest/reference/s3api/head-object.html), [caller identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html)

## Evidence, false positives and cleanup

Save the principal/resource matrix, exact changed input, redacted policies, request IDs and one audit event. Distinguish **policy candidate**, **successful authority acquisition**, and **demonstrated canary access**. Intended administrator delegation, denied actions and policy simulation alone do not prove escalation. Delete disposable jobs and roles by recorded fixture IDs; revoke fixture sessions where supported and verify canary access is denied again.

- [ ] Effective caller and resource owner captured.
- [ ] Allowed and denied controls use the same operation.
- [ ] Trust, service creation and data permission distinguished.
- [ ] Tokens and live credentials excluded from the report.
- [ ] Fixture removal and post-cleanup denial recorded.

The worked commands below use AWS. For Azure managed identities, management/data separation, and GCP service-account attachment versus impersonation, continue with [Azure and GCP boundaries](#page-modules-azure-gcp-boundaries).

## Vulnerability reverse references

- [Overbroad cloud role trust](#page-vulnerabilities-cloud-iam-role-trust) — A principal outside the integration's intended trust set can obtain an owned role's authority.
- [Excessive service-role delegation](#page-vulnerabilities-cloud-passrole-escalation) — A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.
- [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope) — OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.
- [Workload creation grants unintended service-account authority](#page-vulnerabilities-kube-workload-identity-selection) — An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.


---

<a id="page-modules-storage-delivery"></a>

# Object storage, signed URLs and delivery boundaries

Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.

## Investigation sequence

1. Create private canaries
2. Map origin and delivery
3. Compare anonymous and tenant access
4. Test capability scope
5. Verify cleanup and expiry

## Used in these playbooks

[Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Setup and invariant

Create two tiny text objects in controlled storage, one private object per tenant, containing different random markers. Record bucket/account, exact keys, region, encryption requirements, application ownership and delivery host. Obtain the intended read, write, share and revocation rules. **Only an entitled caller may mint or exercise the capability promised by the product.** Reuse [authorization testing](#page-modules-authz-matrix) for tenant changes; this module adds cloud storage and delivery behavior.

## Procedure

1. **Separate the access paths.** Draw upload API → signer → storage object → CDN → browser. Add direct origin access, access points and background exports if the product uses them. Decide whether a file is meant to be public before calling anonymous retrieval a finding.

2. **Establish object-specific baselines.** The owner must retrieve the exact marker; an unauthenticated client and the other tenant should fail where privacy is promised. Inspect owner-provided policy and effective public-access controls. A permissive bucket statement can be overridden by account or other public-access blocks; a block-status response does not examine every application sharing path. [S3 public-access controls](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)

3. **Inspect signed capability issuance.** Ask tenant A to create its normal download or upload capability. Then change only the owned fixture's target key to B's key through the application's supported request. Compare authorization before signing and before asynchronous result release. Properly issued presigned URLs are intentionally usable by their holders; that property alone is not an authorization bug. [S3 presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)

4. **Test the promised restrictions.** Compare the allowed method/object with a changed method or the other synthetic key. Check the agreed expiry using timestamps and a single later request, allowing for documented credential lifetime and clock behavior. For write tests, allocate a separate disposable key and explicit permission; never overwrite an existing customer file. Capture the owner-confirmed object version and marker before and after.

5. **Compare delivery and origin.** Request the private fixture through the intended authenticated CDN path, then directly from its owned origin without credentials. The direct path should enforce the documented protection. A publicly intended origin is a valid control, not a bypass. CloudFront origin access control applies differently to normal S3 origins and website endpoints; match the actual configuration. [CloudFront origin restrictions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)

## Command card

The first command reads at most 64 bytes of the exact fixture through unsigned S3 access. It performs no listing. Credentials, URLs and output files should stay private.

```bash
aws s3api get-object --bucket OWNED_BUCKET \
  --key bounty/private-canary.txt --range bytes=0-63 \
  --expected-bucket-owner YOUR_ACCOUNT_ID --no-sign-request \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10 \
  ./anonymous-canary.bin

aws --profile lab-owner s3 presign \
  s3://OWNED_BUCKET/bounty/private-canary.txt \
  --expires-in 60 --region YOUR_REGION \
  --cli-connect-timeout 5 --cli-read-timeout 10

curl -q --silent --show-error --max-time 10 --max-filesize 1024 \
  --dump-header ./delivery.headers \
  --output ./delivery-canary.txt \
  https://OWNED_DELIVERY_HOST/bounty/private-canary.txt
```

Use the second command only to establish an intentionally issued positive control. Do not paste its bearer URL into reports or shared shell history. The curl command follows no redirects: inspect any redirect destination before testing it. Expected evidence is the marker or an access denial, not merely HTTP 200. [S3 GetObject CLI](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-object.html), [presign CLI](https://docs.aws.amazon.com/cli/latest/reference/s3/presign.html)

## Interpretation and completion

Report the precise failed boundary: anonymous private read, unauthorized capability issuance, cross-tenant overwrite, or direct-origin bypass. A 403 cannot distinguish every encryption, ownership and permission cause; an HTML login page is not object exposure. Avoid speculative findings based only on predictable keys or a reusable valid share URL. For URL-driven storage imports, reuse [SSRF boundaries](#page-modules-ssrf-boundary).

- [ ] Object owner, privacy promise and marker recorded.
- [ ] Anonymous, entitled and other-tenant cases compared.
- [ ] Signature lifetime distinguished from application-session lifetime.
- [ ] Origin and delivery tested against the same fixture.
- [ ] Fixture versions removed; temporary shares revoked where supported.
- [ ] Cached copies handled according to the owner's cleanup procedure.

For Azure SAS types and Entra versus Shared Key access, or GCP object ACLs and uniform bucket-level access, use [Azure and GCP boundaries](#page-modules-azure-gcp-boundaries) alongside this shared canary procedure.

## Vulnerability reverse references

- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read) — An unsigned request retrieves an object that the product promises to keep private.
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write) — An unauthorized principal can create or replace an object in a protected storage location.
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope) — The application issues or accepts a storage capability for an object, operation or lifetime beyond the caller's entitlement.
- [Private delivery policy bypassed through the origin](#page-vulnerabilities-cloud-origin-access-bypass) — A private object is protected at the CDN or application edge but remains accessible directly at an owned origin.


---

<a id="page-modules-container-kubernetes"></a>

# Container and Kubernetes isolation

Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

## Investigation sequence

1. Pin lab and isolation promise
2. Map permission layers
3. Test canary access
4. Compare admission and network controls
5. Remove only recorded fixtures

## Used in these playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Setup and invariant

Use an isolated cluster or an explicitly provided test namespace with two tenant identities. Record context, API version, namespace, CNI, admission configuration, image digest and service accounts. Prepare one canary Secret and one inert HTTP service using administrator fixtures. **A tenant may not acquire another tenant's data, workload identity or host authority through the deployment features it is allowed to use.** A namespace name alone does not specify the isolation promise.

## Procedure

1. **Start from the actual low-privilege identity.** Use its own kubeconfig context. Separate resource reads, workload creation, role binding, impersonation and token issuance. Review permission grants before using them. `kubectl auth can-i` asks the authorization layer; it does not prove admission acceptance or exploitation. [RBAC risks](https://kubernetes.io/docs/concepts/security/rbac-good-practices/), [permission query reference](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/)

2. **Compare direct and indirect canary access.** The fixture owner reads its canary; the restricted principal should be denied. If workload creation is permitted, inspect whether a pod can choose a more powerful service account or mount a forbidden namespace resource. In the lab, use a one-shot workload that checks only the synthetic marker and exits. Record its resulting service account and generated pod, not only the submitted template. Service-account identity and its authorization are separate configuration elements. [Service accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)

3. **Exercise admission coverage.** Use an allowed manifest as a positive control. Compare one owner-approved manifest that violates the advertised policy, then the equivalent supported update path. In a disposable cluster, compare admission responses and final persisted objects. Avoid actual privileged workloads when admission rejection already answers the test. Server dry-run still contacts admission components; it is not offline inspection. [Admission webhook guidance](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)

4. **Measure network isolation independently.** From two pre-created test pods, request the same tiny canary endpoint once. Record source/destination labels, namespaces, port and policy direction. The allowed source should receive the marker; the disallowed source should not. A timeout is inconclusive until the service and allowed route work. Policy objects require an enforcing network implementation; do not infer isolation from YAML alone. [NetworkPolicy behavior](https://kubernetes.io/docs/concepts/services-networking/network-policies/)

5. **Inspect the container-to-host boundary.** Record privileged mode, capabilities, host namespaces, host paths, socket mounts and UID mapping. Root inside a container does not establish host root. Where the owner supplies an isolated host fixture, a read of a synthetic host-mounted marker can demonstrate unintended filesystem exposure without reading host credentials. Compare with the restricted deployment. [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/), [Docker security](https://docs.docker.com/engine/security/)

## Command card

These commands query one named resource or inspect one owned container. They do not create workloads.

```bash
kubectl --context lab-tenant-a --request-timeout=10s \
  -n tenant-b auth can-i get secrets/bounty-canary

kubectl --context lab-tenant-a --request-timeout=10s \
  -n tenant-a auth can-i create pods

kubectl --context lab-owner --request-timeout=10s \
  -n tenant-a get pod bounty-probe \
  -o jsonpath='{.spec.serviceAccountName}{"\n"}'

docker --context lab-engine container inspect bounty-probe \
  --format '{{json .HostConfig.Privileged}} {{json .HostConfig.Binds}}'
```

Expect `no` for cross-tenant Secret access. A `yes` is an authorization finding candidate; verify only the supplied canary when reading is allowed. The inspect output establishes configuration, not an escape exploit. [Docker inspect](https://docs.docker.com/reference/cli/docker/container/inspect/)

## Evidence, cleanup and checklist

Store the starting role, requested object, admission decision, resulting workload, canary result and comparison case. Link business-level ownership to the shared [authorization matrix](#page-modules-authz-matrix). False positives include intended cluster administrators, intentionally shared namespaces and policies ineffective only because the lab omitted the production CNI. Describe those limitations explicitly.

- [ ] Namespace, workload, node and network boundaries separated.
- [ ] Low-privilege context used for reproduction.
- [ ] Only synthetic Secrets and markers accessed.
- [ ] Admission acceptance distinguished from runtime impact.
- [ ] Saved fixture UIDs checked before deletion.
- [ ] Disposable pods, role bindings and markers removed without deleting shared namespaces.

## Vulnerability reverse references

- [Kubernetes Secret access exceeds tenant permissions](#page-vulnerabilities-kube-secret-rbac-exposure) — A restricted cluster principal can read a canary Secret outside its intended resource boundary.
- [Workload creation grants unintended service-account authority](#page-vulnerabilities-kube-workload-identity-selection) — An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.
- [Admission policy misses a supported object or update path](#page-vulnerabilities-kube-admission-policy-gap) — A tenant can persist an object prohibited by the advertised admission policy through a missed operation, selector or subresource.
- [Namespace or workload network restriction is ineffective](#page-vulnerabilities-kube-network-isolation-failure) — A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.
- [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure) — A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth) — An untrusted network client reaches protected container-management functionality without the required identity checks.
- [Shared CI runner exposes private state across jobs](#page-vulnerabilities-ci-runner-cross-job-state) — A job reaches a previous job's private filesystem or image material despite the runner's promised isolation.


---

<a id="page-modules-infrastructure-config"></a>

# Infrastructure configuration: from repository default to deployed impact

Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.

## Investigation sequence

1. Freeze supported configuration
2. Render with synthetic values
3. Trace risky settings
4. Compare deployed controls
5. Remove artifacts and resources

## Used in these playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Setup and invariant

Choose one supported deployment path: Terraform workspace, Helm chart, Docker Compose stack or image build. Pin the repository commit, lockfiles, provider/chart versions, image digest and documented values. Use an isolated environment with synthetic credentials and no workstation cloud credentials. **A supported configuration must preserve its documented trust boundaries and keep deployment secrets away from unintended readers.** A linter warning is a hypothesis until the affected deployment and boundary are established.

## Procedure

1. **Reconstruct the real defaults.** Read quick-start instructions, production overrides, environment-variable precedence and optional features. Record which configuration a normal user actually follows. Compare the default deployment with the maintainer-recommended secure profile. A development-only example is not automatically a production vulnerability.

2. **Render trusted configuration.** Render supplied charts or Compose files with synthetic values, then inspect resulting listeners, host publications, identities, volumes and access policies. Keep rendered files private: interpolation can materialize credentials. Rendering is useful evidence of intended resources, but it does not prove deployment reachability. [Helm template](https://helm.sh/docs/helm/helm_template/), [Compose configuration](https://docs.docker.com/reference/cli/docker/compose/config/)

3. **Trace secret lifetime.** Follow a synthetic marker from input variable through plan, state, output, image layer, artifact archive and logs. Ask which principal can read each artifact. Terraform's `sensitive` designation mainly controls display; state or JSON output can still contain values. Prefer a known fixture plan over reading live state. Do not run unreviewed initialization, provider binaries or provisioning hooks on a credentialed workstation. [Terraform sensitive data](https://developer.hashicorp.com/terraform/language/manage-sensitive-data), [Terraform show](https://developer.hashicorp.com/terraform/cli/commands/show)

4. **Inspect packaging separately from runtime.** For an owned image containing synthetic inputs, review build history and layers against the build recipe. A secret removed from a later filesystem layer may still exist in earlier content. Check whether build arguments or environment variables carry credentials where a build-secret mechanism is appropriate. Record the exact image digest and artifact accessibility; a random string match does not establish a live credential. [Docker build secrets](https://docs.docker.com/build/building/secrets/)

5. **Confirm one deployed consequence.** In the disposable deployment, test one known canary from the intended allowed location and an owner-controlled disallowed location. For exposed databases, reuse [network-service boundaries](#page-modules-network-service-boundaries). For broad roles or storage policies, reuse [cloud IAM](#page-modules-cloud-iam-boundaries) and [storage delivery](#page-modules-storage-delivery). Change only the relevant setting, redeploy the lab fixture and repeat the pair.

## Command card

Use a reviewed, already initialized Terraform fixture and trusted chart. These examples write only local evidence; commands are not instructions to initialize an arbitrary repository.

```bash
umask 077

helm template bounty ./trusted-chart \
  --values ./fixture-values.yaml > ./fixture-rendered.yaml

terraform -chdir=./lab-iac show -json ./fixture.tfplan \
  > ./fixture-plan.json

docker image history OWNED_SYNTHETIC_IMAGE \
  --no-trunc --format '{{.CreatedBy}}' \
  > ./fixture-history.txt

rg --files-with-matches --fixed-strings \
  'BB_SYNTHETIC_SECRET_2026' \
  ./fixture-plan.json ./fixture-history.txt ./fixture-rendered.yaml
```

A returned filename proves only that the chosen marker is present in that file. The security result also needs unintended artifact access and the intended confidentiality rule. Restrict provider execution to the disposable lab even for inspection commands that may need installed plugins. [Image history reference](https://docs.docker.com/reference/cli/docker/image/history/)

## Interpretation, cleanup and checklist

The report should connect **supported input → rendered setting → deployed resource → unintended reader or actor → canary result**. Include the secure comparison and minimum affected configuration. Avoid claiming that every deployment is exposed when a particular override is required. Public ports without usable privilege, fake example secrets, intentional debug builds and unreachable rules are common false positives.

- [ ] Supported mode and exact dependency versions pinned.
- [ ] Default values separated from operator overrides.
- [ ] Synthetic data used throughout artifacts.
- [ ] Actual artifact reader or service boundary identified.
- [ ] Remediated comparison reproduces the expected denial.
- [ ] Only fixture resource IDs destroyed; volumes, plans, logs and disposable credentials cleaned up.

## Vulnerability reverse references

- [Container exposes unintended host files or privileges](#page-vulnerabilities-container-host-resource-exposure) — A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.
- [Sensitive values exposed through state or plan artifacts](#page-vulnerabilities-iac-state-secret-exposure) — A deployment artifact readable by an unintended principal contains credentials or equivalent confidential material.
- [Secrets retained in container build artifacts](#page-vulnerabilities-container-build-secret-leak) — A build places confidential inputs in image history, layers or artifacts available outside their intended audience.
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default) — A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.


---

<a id="page-modules-dns-tls-mail"></a>

# DNS, TLS and email trust boundaries

Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

## Investigation sequence

1. Pin owned services and trust promise
2. Collect exact protocol baseline
3. Run one paired control
4. Correlate protocol and receiver evidence
5. Remove synthetic mail and fixtures

## Used in these playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud)

## Setup and invariant

Treat DNS, TLS and SMTP as separate services with explicit owners, addresses, ports and test methods. Use an owned miniature zone, known certificate hostname and researcher-controlled mail sender and receiver. **A service must enforce the claimed ownership, peer identity or relay boundary.** Define the expected result before probing: public DNS answers are normally intentional; private zone transfer or unauthenticated external relay may not be.

## Procedure

1. **Inspect DNS ownership without claiming resources.** Record the exact CNAME or delegation chain, provider error, TTL and owner-supplied resource inventory. A missing backing resource creates a takeover candidate; it does not prove that another account can bind the hostname. Check provider validation and reservation rules. Do not claim dangling resources as a generic proof step. [Azure dangling DNS guidance](https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover)

2. **Separate transfer and recursion.** AXFR requests the zone contents, so test only an owned small zone or an explicitly supplied fixture. Compare the permitted transfer source with the denied source. For recursion, query one unique name in an owned authoritative zone through the tested resolver; correlate the authoritative log with the resolver response. Cached answers and the RA flag alone do not prove unrestricted recursion. [AXFR protocol](https://www.rfc-editor.org/rfc/rfc5936.html), [BIND configuration](https://bind9.readthedocs.io/en/v9.20.13/reference.html)

3. **Verify TLS identity as the real client.** Use the intended hostname, SNI, port and trust store. Compare the valid fixture certificate with an owned wrong-host certificate in a local client integration test. OpenSSL diagnostics confirm the fixture but do not establish that the product's client accepts an invalid identity. Certificate-chain trust and hostname matching both matter. [OpenSSL s_client](https://docs.openssl.org/3.5/man1/openssl-s_client/)

4. **Test SMTP relay with one synthetic message.** Only when message delivery is allowed, use sender and receiver domains controlled by the researcher and outside the tested relay's local destination domains. Start from an untrusted source address with no SMTP authentication. The secure control rejects external-to-external relay; the permitted control uses the documented authenticated submission path. A test from an allowlisted office or VPN address does not prove an open relay.

5. **Correlate SMTP acceptance with delivery.** Retain the envelope, transcript, unique subject marker and receiver logs. A successful RCPT response or queue ID alone does not establish final delivery. Keep relay testing separate from SPF, DKIM and DMARC alignment findings. For sender-identity tests, the receiving policy and trusted authentication results determine the demonstrated impact. [SMTP protocol](https://www.rfc-editor.org/rfc/rfc5321.html)

## Command card

Replace all example addresses only with owned fixtures. Run one command at a time. The AXFR example is limited to the small fixture zone; it retrieves that zone.

```bash
timeout 10 dig -r @192.0.2.53 fixture.example AXFR \
  +tcp +time=2 +tries=1

timeout 15 openssl s_client -connect tls.fixture.example:443 \
  -servername tls.fixture.example \
  -verify_hostname tls.fixture.example \
  -verify_return_error -brief </dev/null

timeout 20 swaks --config --server relay.fixture.example --port 25 \
  --timeout 10 --from probe@sender.fixture.example \
  --to receiver@recipient.fixture.example \
  --header 'Subject: Bounty relay fixture 2026-01' \
  --body 'Synthetic authorized relay test; no action required.'
```

Use a clean shell with no `SWAKS_OPT_*` overrides; `--config` disables automatic configuration files, not environment settings. Confirm the transcript contains no AUTH and exactly one intended recipient. The fixture message contains no credentials; this example does not claim transport-security testing. [BIND dig](https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility), [Swaks reference](https://jetmore.org/john/code/swaks/latest/doc/ref.txt)

## Result and cleanup checklist

- [ ] Public records distinguished from restricted zone contents.
- [ ] Dangling DNS labeled candidate unless claimability is established.
- [ ] TLS finding reproduced in the product's actual client.
- [ ] Relay test source is outside trusted networks.
- [ ] Acceptance, queueing and delivered fixture correlated.
- [ ] No real recipients contacted; synthetic mail and temporary zone/certificate fixtures removed.

## Vulnerability reverse references

- [Dangling DNS reference to a retired service](#page-vulnerabilities-dns-dangling-resource-reference) — An owned hostname still points to a released provider resource, creating a possible takeover path if provider binding rules permit it.
- [Restricted DNS zone transferable from an unintended source](#page-vulnerabilities-dns-unrestricted-zone-transfer) — An unauthorized source can retrieve an entire zone that the owner intends to restrict.
- [DNS recursion available outside the intended client network](#page-vulnerabilities-dns-unrestricted-recursion) — A resolver performs recursive lookups for a client excluded by its intended access policy.
- [SMTP relay allows unauthenticated external delivery](#page-vulnerabilities-smtp-unintended-open-relay) — An untrusted unauthenticated client can relay between external domains contrary to the server's relay policy.
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate) — Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.


---

<a id="page-modules-network-service-boundaries"></a>

# Database, cache, queue and management service boundaries

Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

## Investigation sequence

1. Record exact endpoint and allowed method
2. Establish authenticated baseline
3. Read one forbidden fixture
4. Compare identity and network controls
5. Document and remove canaries

## Used in these playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Setup and invariant

Record one service row: owner, exact IPv4 or IPv6 address, hostname, transport, port, product build, authentication method and intended access boundary. A hostname in web scope does not automatically include every backing service. Prepare a restricted account, an allowed account and one synthetic key, row, queue or management fixture. **A network position or low-privilege account must not gain the protected data or administrative operation outside its stated permissions.**

Use version banners only to select hypotheses. Vendor backports and disabled features can invalidate a banner-to-CVE match. First establish a normal connection, intended authenticated operation and expected rejection. Keep source network and timestamps constant when comparing identities.

## Procedure

1. **Separate reachability from authority.** Record a connection outcome without treating an open port as a vulnerability. Check whether the service is intentionally public, behind mutual TLS or protected by native authentication. A health response is not administrative access.

2. **Use one exact resource.** For Redis, request only the agreed canary key; do not run keyspace enumeration, configuration changes or flush commands. Compare anonymous access, the permitted principal and the restricted principal. Redis network protection, authentication, ACLs and TLS solve different parts of this boundary. [Redis security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)

3. **Check connection rules and database grants independently.** In PostgreSQL, examine the owner-supplied host-based authentication rule selected by connection type, source, database and user. Establish whether authentication genuinely happened, then test permission for one fixture row. A trusted local administration connection is not evidence of internet exposure. [PostgreSQL host authentication](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html)

4. **Model queues as stateful resources.** In an isolated broker, create two fixture virtual hosts and named queues. Compare whether A can declare, publish to or consume B's fixture according to the contract. Use a single marked message and account for acknowledgement behavior; consuming production messages changes application state. Broker login does not imply permissions across all virtual hosts. [RabbitMQ access control](https://www.rabbitmq.com/docs/access-control)

5. **Evaluate management APIs and network parity.** For an owned Docker daemon, review listener and client authentication configuration; use only an approved metadata endpoint for the initial proof. Do not create privileged containers to confirm broad authority on production. Compare an explicitly owned IPv4 and IPv6 service only when both are in scope: different exposure is relevant when it defeats the same promised restriction. [Docker daemon protection](https://docs.docker.com/engine/security/protect-access/)

## Command card

The Redis endpoint below is an isolated local fixture. The environment removal prevents an inherited password from contaminating the unauthenticated control. The database example uses the supplied test account and private password file, with TLS identity verification and a read-only transaction.

```bash
env -u REDISCLI_AUTH timeout 10 redis-cli \
  -h 127.0.0.1 -p 16379 --raw GET bounty:canary

timeout 15 psql -X -w \
  "host=db.fixture.example port=5432 dbname=bounty_fixture user=lab_low sslmode=verify-full sslrootcert=./fixture-ca.pem connect_timeout=5 options='-c statement_timeout=3000'" \
  -v ON_ERROR_STOP=1 \
  -c "BEGIN READ ONLY; SELECT marker FROM bounty_canary WHERE id=1; ROLLBACK;"
```

An unauthenticated marker demonstrates read access to that fixture. `NOAUTH`, `NOPERM`, connection failure and an absent value mean different things; compare the known-good control. For PostgreSQL, distinguish TLS failure, authentication failure and SQL permission denial. Credentials can come from a password file even with `-w`; that flag disables prompting, not password authentication. [Redis CLI](https://redis.io/docs/latest/develop/tools/cli/), [PostgreSQL connection parameters](https://www.postgresql.org/docs/current/libpq-connect.html), [psql options](https://www.postgresql.org/docs/current/app-psql.html)

## Evidence, false positives and cleanup

Save the endpoint, source, verified account, precise operation, response, fixture ownership and comparison. Public service banners, intentionally anonymous health checks and intended shared queues are not equivalent to data exposure. Reuse [authorization matrices](#page-modules-authz-matrix) for per-resource checks and [identity/session testing](#page-modules-identity-session) for revocation behavior.

- [ ] Allowed and denied controls have working connectivity.
- [ ] No wildcard reads, real queue consumption or configuration mutation.
- [ ] Network access distinguished from authentication and authorization.
- [ ] Lab result separated from unverified production applicability.
- [ ] Canary records, messages and test accounts removed using their recorded identifiers.

## Vulnerability reverse references

- [Namespace or workload network restriction is ineffective](#page-vulnerabilities-kube-network-isolation-failure) — A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.
- [Supported deployment default exposes a protected service](#page-vulnerabilities-iac-insecure-supported-default) — A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.
- [Redis authentication or key ACL boundary failure](#page-vulnerabilities-redis-canary-access) — An anonymous or restricted client can read a key outside the service's intended access policy.
- [PostgreSQL trust authentication exceeds the approved network boundary](#page-vulnerabilities-postgres-unintended-trust-auth) — An unintended source can connect as a protected database identity without the required authentication because an effective trust rule applies.
- [Message broker permissions cross a virtual-host boundary](#page-vulnerabilities-queue-virtual-host-boundary) — A restricted broker identity can act on a queue or exchange belonging to a different isolated fixture tenant.
- [Container daemon management endpoint lacks required client authentication](#page-vulnerabilities-container-daemon-client-auth) — An untrusted network client reaches protected container-management functionality without the required identity checks.


---

<a id="page-modules-android-components"></a>

# Android components, intents and deep links

Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.

## Investigation sequence

1. Fingerprint release
2. Map caller authority
3. Record valid baseline
4. Change one input
5. Verify boundary
6. Restore lab

## Used in these playbooks

[Mobile](#page-mobile)

## Setup and invariant

Use an owned emulator/device, the scoped release APK and relevant splits, SDK Platform Tools, APK Analyzer, and an ordinary companion application you control. Seed a private record `BB-ANDROID-01` and a deliberately shareable record. Keep ADB for orchestration and observation; its shell identity is not equivalent to an ordinary installed app.

**Invariant:** an external caller receives only the component actions and URI grants deliberately delegated to that caller. A public activity must still enforce the sensitive operation's requirements. Export defaults vary across components and platform versions, so inspect resolved package state as well as the manifest. [Android component exposure](https://developer.android.com/privacy-and-security/risks/android-exported).

## Procedure and command sheet

1. **Fingerprint.** Record package, version, target SDK, device API, signer, and release/debug state. These commands inspect a local APK and one selected device:

```bash
adb devices -l
adb -s DEVICE_SERIAL shell pm path com.example.lab
adb -s DEVICE_SERIAL shell dumpsys package com.example.lab
apkanalyzer apk summary ./app.apk
apkanalyzer manifest print ./app.apk
apkanalyzer manifest permissions ./app.apk
```

Use the printed manifest to create rows for activity/service/receiver/provider, export state, permission, URI authority, grant flags, external input, and protected operation. [ADB](https://developer.android.com/tools/adb), [APK Analyzer](https://developer.android.com/tools/apkanalyzer).

2. **Establish a baseline.** Exercise the intended share or navigation action. Record exactly which URI, recipient, and capability were granted. From the companion app, request only the seeded record through `ContentResolver`; retain the result or exception. A provider may require permissions or a temporary grant even when externally addressable. [Provider access model](https://developer.android.com/guide/topics/providers/content-provider-basics).

3. **Run one negative control.** Repeat without the grant, with the second seeded URI, or from a fresh ordinary caller. The control must change only one condition. For a link, compare normal login with logged-out and account-switched states. ADB can launch a harmless route for diagnosis:

```bash
adb -s DEVICE_SERIAL shell am start -W -a android.intent.action.VIEW -d 'labapp://item/BB-ANDROID-01' com.example.lab
```

Use the actual discovered scheme/package, and repeat any result from the companion app. If links reach the backend, reuse the [authorization matrix](#page-modules-authz-matrix) and [identity/session experiments](#page-modules-identity-session). Link verification does not validate arbitrary parameters. [Deep-link risks](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks).

4. **Inspect delegation.** Trace nested intents, forwarded extras, and obtained PendingIntent tokens. Determine which action/destination remains caller-controlled. Check one harmless alternate destination or repeat of an intended single-use action. Record OS behavior: Android 16 adds default intent-redirection hardening, so reproduce on the supported version rather than extrapolating from an older emulator. [Intent redirection](https://developer.android.com/privacy-and-security/risks/intent-redirection), [PendingIntent delegation](https://developer.android.com/privacy-and-security/risks/pending-intent).

5. **Decide and retain evidence.** A report needs caller identity/permissions, precise URI or intent, eligible build, expected denial, and the protected result. An exported activity opening a public screen, a denied request, or access obtained only after granting the attacker target-equivalent privilege is not this finding. Route path handling into [file boundaries](#page-modules-file-boundaries), and WebView-origin questions into [browser trust](#page-modules-browser-trust).

## Completion and cleanup

- [ ] Compare intended recipient, unauthorized caller, and revoked-grant state.
- [ ] Repeat the smallest result without ADB-only privileges.
- [ ] Distinguish data reads, harmless navigation, and state-changing operations.
- [ ] Record minimum OS, target SDK, interactions, and ownership assumptions.
- [ ] Revoke temporary shares, remove companion-app fixtures, and restore the emulator snapshot after exporting redacted evidence.

## Native authentication continuation

Treat OAuth routing and authorization as separate decisions. Record the external authorization UI, registered callback, app instance, pending transaction and PKCE verifier lifecycle. With two owned local login attempts, compare a normal return with a callback delivered to the other pending attempt. Then compare the correct verifier with the other attempt's verifier at the local token endpoint. A intercepted code that cannot be redeemed is a protected control, not account takeover. Use [federation/token trust](#page-modules-federation-token-trust) for issuer, code, state and token decisions. Native public clients require PKCE; an embedded shared client secret is not a confidential per-installation secret. [RFC 8252](https://www.rfc-editor.org/rfc/rfc8252), [PKCE](https://www.rfc-editor.org/rfc/rfc7636.html).

For passkeys, follow Credential Manager's result into the relying-party server; the credential-selection UI does not finish server authentication. Reuse [authenticator lifecycle](#page-modules-authenticator-lifecycle) for challenge, credential/account binding and required verification flags. Record the release signer and native origin/association configuration; do not infer the production origin allowlist from a re-signed APK. Android separates the client, credential provider and verifying server. [Credential Manager architecture](https://developer.android.com/identity/credential-manager).

```bash
rg -n 'code_verifier|code_challenge|redirect_uri|CredentialManager|PublicKeyCredential' ./source
```

- [ ] Callback receiver and backend authenticated identity are both observed.
- [ ] Cross-attempt, expired-attempt and valid-attempt controls use fresh codes.
- [ ] Re-signing, debug credentials and altered app links are disclosed.


## Vulnerability reverse references

- [Exported Android component exposes a protected operation](#page-vulnerabilities-android-exported-operation) — An externally reachable activity, service or receiver performs work that its caller is not entitled to request.
- [Content-provider permission or URI-grant escape](#page-vulnerabilities-android-provider-grant) — A recipient obtains data or file capabilities beyond the URI and permissions deliberately shared with it.
- [Nested intent redirects application authority](#page-vulnerabilities-android-intent-redirection) — An exported entry point forwards attacker-supplied intent fields into a protected destination using the target application’s authority.
- [PendingIntent grants unintended mutable or replayable authority](#page-vulnerabilities-android-pendingintent-delegation) — A recipient can alter or reuse a delegated action beyond its intended destination, parameters or lifetime.
- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler) — An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
- [Untrusted WebView content reaches a native bridge](#page-vulnerabilities-mobile-webview-native-bridge) — A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure) — A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.


---

<a id="page-modules-ios-boundaries"></a>

# iOS signing capabilities, links and protected data

Connect entitlements and application groups to actual callers, URL transitions and protected key use.

## Investigation sequence

1. Identify signed build
2. Map capabilities
3. Observe normal access
4. Change caller or lock state
5. Verify release result
6. Clean fixtures

## Used in these playbooks

[Mobile](#page-mobile)

## Setup and invariant

Prepare a Mac with Xcode tooling and an owned supported device. Record bundle ID, build, signing team, distribution channel, OS, and artifact hash. Keep device IPA, simulator build, enterprise build, and re-signed copy separate. Create two synthetic accounts and one private document whose marker can be recognized without collecting other data.

**Invariant:** links and extensions cannot borrow capabilities outside their intended trust relationship, and sensitive data/key use respects the promised authentication and lock state. Entitlements describe granted capabilities; they do not demonstrate that an unrelated app can exercise them. Apple enforces application-group relationships through signing and sandbox rules. [App protection and groups](https://support.apple.com/guide/security/app-protection-and-app-groups-sec1a976c067/web).

## Procedure and command sheet

1. **Inspect the unchanged bundle.** On macOS, inspect the main app and repeat for each embedded extension. The entitlement command writes to stdout; it does not re-sign the app.

```bash
plutil -p ./Payload/Lab.app/Info.plist
codesign -dv --verbose=4 ./Payload/Lab.app
codesign -d --entitlements - ./Payload/Lab.app
```

Capture `CFBundleURLTypes`, associated domains, App Groups, Keychain access groups, extension points, and ATS exceptions. A capability missing from `Info.plist` may be in the signature, so inspect both. [OWASP entitlement extraction](https://mas.owasp.org/MASTG/techniques/ios/MASTG-TECH-0111/), [OWASP plist tooling](https://mas.owasp.org/MASTG/tools/ios/MASTG-TOOL-0062/).

2. **Build a capability table.** Use columns for main app, extension, signing identity, shared container, shared secret, intended consumer, and external input. In source-available work, locate storage and callback code:

```bash
rg -n 'SecItem(Add|CopyMatching)|kSecAttrAccessible|kSecAttrAccessGroup|LAContext|evaluatePolicy' ./source
rg -n 'openURL|continueUserActivity|WKScriptMessageHandler|containerURL' ./source
```

Matches identify implementation paths, not vulnerabilities. Trace the actual access group/class and the operation that uses the retrieved key; do not infer a security boundary from a biometric-looking screen alone.

3. **Compare link transitions.** Open one normal universal link and one custom-scheme route using an owned Notes/browser fixture. Repeat while logged out, after account switching, and with a mismatched synthetic resource. Record browser/app routing separately from account authorization. Universal links require website/app association; custom schemes have different ownership guarantees. For OAuth callbacks, reuse [identity/session tests](#page-modules-identity-session); for object access, use the [authorization matrix](#page-modules-authz-matrix). [Apple universal-link model](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html).

4. **Test one protected-state transition.** Establish legitimate access when unlocked, then lock the device and exercise only the supported background/extension path. Compare with a denied access class or an operation requiring fresh user presence. Record whether sensitive plaintext or usable key operations become available, not simply whether encrypted bytes remain on disk. Keychain accessibility, synchronization, and user-presence policy serve different purposes. [Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web).

5. **Confirm the caller model.** Test extension input with a harmless imported document or URL through the normal share sheet. Reuse [file boundaries](#page-modules-file-boundaries) and [browser trust](#page-modules-browser-trust) when files or WKWebView messages are involved. An attacker app signed with the target's team or a jailbreak granting container access invalidates an ordinary-app claim; disclose such constraints and seek an unchanged-build reproduction.

## Completion and cleanup

- [ ] Preserve exact build, signature, device state, input and expected denial.
- [ ] Explain why background access violates a product promise rather than an intended feature.
- [ ] Keep proof to the seeded document or one reversible operation.
- [ ] Remove synthetic links/documents and testing profiles; revoke lab sessions and restore the owned device configuration.

## Native authentication continuation

For browser-based sign-in, record the actual authentication session, callback scheme or associated-domain route, and the pending login or account-linking transaction. In the local identity fixture, begin independent A/B attempts and return A's callback while B is pending. Compare the resulting account and token decision with an untouched control. Route matching alone does not establish that a callback belongs to the current transaction. Reuse [federation/token trust](#page-modules-federation-token-trust) for the complete code/PKCE/issuer checks; RFC 8252's native-client model separates the external authorization agent from the native client. [OAuth for native apps](https://www.rfc-editor.org/rfc/rfc8252).

For passkeys or local authentication, record whether the protected operation is a remote session issuance or local use of a protected key. Trace the returned credential to the server and apply [authenticator lifecycle](#page-modules-authenticator-lifecycle). A successful Face ID prompt is not evidence that server-side challenge and account binding are correct. Inspect local paths without changing signing identities:

```bash
rg -n 'ASWebAuthenticationSession|ASAuthorization|code_verifier|redirect_uri|SecKeyCreateSignature' ./source
```

- [ ] Record callback routing, pending transaction and final account separately.
- [ ] Exercise cancellation/expiration and an account switch with synthetic identities.
- [ ] Preserve the valid control and confirm no useful credential is issued for the mismatched transaction.


## Vulnerability reverse references

- [Mobile link handler trusts routing as authorization](#page-vulnerabilities-mobile-link-handler) — An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
- [Untrusted WebView content reaches a native bridge](#page-vulnerabilities-mobile-webview-native-bridge) — A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.
- [Keychain accessibility violates the intended lock boundary](#page-vulnerabilities-ios-keychain-access-policy) — A sensitive item or protected key operation is available in a device state that the application’s security policy requires it to deny.
- [Extension input crosses an iOS shared-container boundary](#page-vulnerabilities-ios-shared-container-trust) — The main application trusts content written through a lower-trust extension/input path as if it were an authorized app action.
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate) — A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure) — A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.


---

<a id="page-modules-client-storage-transport"></a>

# Client storage, logs, backup and transport trust

Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.

## Investigation sequence

1. Define secret and reader
2. Capture lifecycle baseline
3. Observe exposure path
4. Run trust controls
5. Validate impact
6. Remove lab material

## Used in these playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Setup and invariant

Use a clean owned device or desktop VM with the scoped release, two synthetic accounts, a scoped interception setup, and a unique marker such as `BB-CLIENT-01`. Define the prospective reader: another ordinary app, another OS user, someone receiving an exported diagnostic bundle, an authorized backup recipient, or a network adversary. A debugger/root reader is a separate model.

**Invariant:** credentials and private records do not enter a channel readable by an unintended principal, and the release rejects an unauthenticated network peer. Prioritize actual token/data movement; a string called `api_key`, a backup-enabled manifest, or absent certificate pinning alone is insufficient.

## Procedure and command sheet

1. **Record the lifecycle.** Start logged out; sign in, perform one marked operation, background/lock, switch accounts, then log out. For each state record relevant preferences, databases, caches, clipboard, notifications and user-exportable diagnostics. Use [identity/session](#page-modules-identity-session) for token validity and revocation, and [authorization checks](#page-modules-authz-matrix) for backend effects.

2. **Locate only relevant sinks.** Search a local source copy and explicitly acquired lab exports. The bounded file-size limit reduces accidental scanning of large databases; use filenames first when output may contain secrets.

```bash
rg -n 'Log\.|NSLog|os_log|console\.log|SharedPreferences|UserDefaults' ./source
rg -l --max-filesize 2M 'BB-CLIENT-01' ./lab-export
apkanalyzer manifest print ./app.apk
```

On Android, inspect `allowBackup`, `fullBackupContent`, `dataExtractionRules`, and the referenced XML. Test the supported restore path using synthetic data. Cloud backups and device transfers can follow different rules; neither follows reliably from one flag across all versions/OEMs. Do not use a legacy `adb backup` recipe as a universal modern test. [Android backup rules](https://developer.android.com/identity/data/autobackup).

3. **Prove reader access.** If the marker appears in logs, show who can obtain that release log under the stated prerequisites. Modern log access is restricted; ADB output does not prove every app can read it. If a diagnostic export includes an owned token, demonstrate the expected exclusion with an otherwise identical export that lacks a session. Share a redacted excerpt and file location, not a full personal log. [Android log disclosure](https://developer.android.com/privacy-and-security/risks/log-info-disclosure).

4. **Use a transport control matrix.** In a local endpoint or approved test environment, compare a valid certificate, an untrusted issuer, and a wrong-host certificate. Keep request content identical and send only synthetic data. Record the release's exact trust store, endpoint, handshake result and whether an application request is sent. A refusal caused by connectivity is not validation evidence; the valid control must connect. Custom trust code can mistakenly accept invalid chains. [Unsafe trust managers](https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager).

5. **Separate lab changes.** A user-installed CA, debug-only trust anchor, disabled trust callback, or instrumentation can make interception intentional. Android debug overrides may bypass pins when their debug CA is used; they are ignored for a non-debuggable build. Therefore verify bad-peer acceptance on the unchanged eligible release before reporting a certificate-validation defect. [Network security configuration](https://developer.android.com/privacy-and-security/security-config).

## Evidence, decisions and cleanup

Retain state before/after, sensitivity, exact reader privileges, minimum exposed marker, and reproducible impact. Intended account-owner backup access and approved offline storage are not automatically vulnerabilities. Use [file boundaries](#page-modules-file-boundaries) when exposure depends on permissions or export paths.

- [ ] Compare account A, account B, and logged-out state.
- [ ] Demonstrate the reader without granting extra privileges.
- [ ] Distinguish missing pinning from accepting invalid certificates.
- [ ] Remove test CAs/proxies, delete synthetic exports, clear test clipboard values, revoke owned sessions, and restore the lab snapshot.

## Privacy surfaces and metadata-only leakage

Add a reader-specific matrix instead of reporting absent UI flags. Seed one private message `BB-PRIVATE-VIEW` and a public title. Compare unlocked/locked, foreground/background and A/B account-switch states. Inspect the app switcher snapshot, lock-screen notification preview, clipboard, accessibility text and a diagnostic export through supported OS interfaces. Record the precise reader privileges, user settings and platform version. A photograph taken by an already authorized user or access after explicitly granting a privileged accessibility service is a different threat model. MASVS-STORAGE-2 covers unintended sensitive-data leakage; product guarantees and eligibility determine the report. [OWASP storage leakage control](https://mas.owasp.org/MASVS/controls/MASVS-STORAGE-2/).

For analytics/telemetry, place a synthetic marker in a private field and inspect only the lab app's own traffic or configured local sink. Compare the documented consent states and identify the receiving component and fields. Do not test the analytics vendor. A tracking SDK or a privacy-label mismatch alone does not demonstrate the claimed access boundary. [OWASP privacy minimization](https://mas.owasp.org/MASVS/controls/MASVS-PRIVACY-1/).

For a timing/size/existence hypothesis, first implement it locally using a small blinded set of synthetic present/absent records. Randomize order, keep request sizes and authentication equal, retain every sample, and evaluate the prediction on held-out fixtures. Show what private fact is inferable, from which observable, with what error rate. Ordinary latency variation, a single paired sample and a marker already supplied in the query establish no disclosure. This is an experimental design to investigate a suspected side channel, not evidence that one exists.

- [ ] Private content is actually available to the stated unintended reader.
- [ ] User consent, OS grants and already-delivered copies are accounted for.
- [ ] A metadata-only claim reports false positives and fresh validation cases.
- [ ] Remove notifications, clipboard markers, exports and synthetic analytics data.


## Vulnerability reverse references

- [Keychain accessibility violates the intended lock boundary](#page-vulnerabilities-ios-keychain-access-policy) — A sensitive item or protected key operation is available in a device state that the application’s security policy requires it to deny.
- [Local authentication does not gate the protected operation](#page-vulnerabilities-client-local-auth-gate) — A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
- [Backup or transfer exposes unintended sensitive client state](#page-vulnerabilities-client-backup-sensitive-state) — A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.
- [Sensitive client state leaks through accessible diagnostics](#page-vulnerabilities-client-secret-logging) — Logs, crash reports or user-exportable diagnostics disclose a secret or private record to a principal outside its intended audience.
- [TLS peer certificate or hostname verification failure](#page-vulnerabilities-client-invalid-certificate) — Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.
- [Password storage without an adequate adaptive hash](#page-vulnerabilities-password-storage-weak-hash) — A password verifier has insufficient computational cost for its supported threat model.
- [Private client content leaks through a lower-trust display or sharing channel](#page-vulnerabilities-client-private-ui-disclosure) — A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.


---

<a id="page-modules-desktop-ipc"></a>

# Desktop IPC, Electron bridges and native protocols

Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller.

## Investigation sequence

1. Map process authority
2. Inventory entry points
3. Record trusted call
4. Exercise untrusted caller
5. Validate capability
6. Restore snapshot

## Used in these playbooks

[Desktop & extensions](#page-desktop)

## Setup and invariant

Prepare a disposable desktop VM or owned Mac, a standard-user account, a clean application profile and synthetic files in a dedicated lab directory. Record release, Electron/runtime version when present, OS and installation mode. Capture the normal process tree: renderer, preload, main process, extension service worker, native host, helper or service.

**Invariant:** a lower-trust caller gets only explicitly authorized operations with constrained arguments. A local listener, broad preload API, or privileged process becomes actionable when a realistic caller can reach a sensitive capability. Console execution manually injected into a trusted renderer does not establish that route.

## Procedure and command sheet

1. **Inventory actual handlers.** In local source or extracted JavaScript, locate windows, preload APIs, IPC registrations and protocol handlers. These are read-only searches:

```bash
rg -n 'ipcMain\.(handle|on)|contextBridge|nodeIntegration|contextIsolation|sandbox' ./source
rg -n 'openExternal|setAsDefaultProtocolClient|open-url|second-instance|protocol\.handle' ./source
rg -n 'connectNative|sendNativeMessage|allowed_origins|externally_connectable' ./extension
```

For each hit record input origin, current process identity, argument schema, authorization check, and final file/shell/helper operation. Include auxiliary windows rather than assuming the main window's settings apply everywhere.

2. **Capture a valid transaction.** Open an intended file or settings panel and trace one documented bridge method. Record sender frame/origin, method, arguments, and result. Electron recommends validating IPC senders, including relevant frame identity; navigation can change which document is using a renderer. [Electron security](https://www.electronjs.org/docs/latest/tutorial/security).

3. **Change one trust condition.** Exercise the same method from an attacker-controlled page/frame reachable through an actual app feature, or from an ordinary local client for a native IPC endpoint. Compare with the trusted baseline and a disallowed method/argument. Keep the proof to reading a seeded nonsensitive file or writing one marker in the test directory. `contextIsolation` does not repair an overbroad bridge; inspect the capability exposed and the main-process checks. [Context isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation).

4. **Trace external protocols.** Invoke a discovered handler through the OS-supported route with a harmless synthetic URI. On macOS, after verifying the registered scheme:

```bash
open 'labapp://open?item=BB-DESKTOP-01'
```

Record URI parsing and argument construction before reaching native functionality. Compare a normal item with a malformed/unknown item; the latter should be rejected without launching unintended functionality. Test packaged behavior because protocol registration differs by OS and packaging. Never infer command execution merely from `shell.openExternal` being present. [Electron deep links](https://www.electronjs.org/docs/latest/tutorial/launch-app-from-url-in-another-app), [Shell API](https://www.electronjs.org/docs/latest/api/shell).

5. **Extend into native hosts.** For a browser extension, inspect native-host `allowed_origins`, executable path, message schema and downstream arguments. An allowed extension still needs to constrain untrusted page messages it forwards. A native host invocation has the user's process privileges unless another actual boundary is shown. [Chrome native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging).

## Evidence, reuse and cleanup

Preserve the complete sequence from realistic entry point to capability, with sender identity, target identity, exact input, expected denial and result. Reuse [browser trust](#page-modules-browser-trust) for origin/navigation validation, [file boundaries](#page-modules-file-boundaries) for path handling and [authorization matrix](#page-modules-authz-matrix) for action ownership. Backend token effects belong to [identity/session](#page-modules-identity-session).

- [ ] Reproduce from a reachable untrusted context, without developer-console privilege.
- [ ] Separate same-user capability abuse from administrator/system escalation.
- [ ] Compare valid sender, untrusted sender, and invalid arguments.
- [ ] Remove test protocol registrations if created, close local clients, delete marker fixtures and restore the clean profile/snapshot.

## Extension-specific continuation

For page forwarding, browser-supplied sender metadata, navigation races, worker restarts and optional permission changes, run [extension message boundaries](#page-modules-extension-message-boundaries). Return here only when the verified path crosses into a native host, local protocol or privileged helper. Preserve the same originating page and owned synthetic marker across both procedures.


## Vulnerability reverse references

- [Electron IPC exposes main-process authority to an untrusted sender](#page-vulnerabilities-electron-ipc-confused-deputy) — An attacker-controlled renderer or frame invokes a privileged main-process operation through insufficient sender or argument validation.
- [Desktop protocol handler misinterprets external input](#page-vulnerabilities-desktop-protocol-confusion) — An OS-dispatched URL reaches a native command or operation with attacker-controlled arguments outside the intended handler contract.
- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority) — An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.


---

<a id="page-modules-update-integrity"></a>

# Update signatures, rollback and privileged installation

Test the update decision and installation boundary while preserving production signer and privilege assumptions.

## Investigation sequence

1. Observe genuine update
2. Identify policy and consumer
3. Build local controls
4. Test rejection points
5. Confirm minimum effect
6. Restore clean state

## Used in these playbooks

[Desktop & extensions](#page-desktop) · [Mobile](#page-mobile)

## Setup and invariant

Use a disposable installation, the eligible release, one genuine update, a standard-user attacker account and a separate administrative setup account. For source-available projects, create a local updater harness or documented test feed that exercises the real verifier. Record any configuration change: redirecting production traffic or granting the attacker an update signing key would change the claim.

**Invariant:** installation consumes exactly the artifact authorized by the expected publisher policy, and lower-privileged users cannot substitute content before a privileged consumer uses it. Version rollback is a defect only when it violates a defined security policy or restores a demonstrable vulnerability under realistic attacker control.

## Procedure and command sheet

1. **Observe a genuine update.** Record installed version, requested channel, feed metadata, downloaded filename/hash, expected publisher identity, temporary path, verifier result and installing process identity. Inspect local artifacts without executing them:

```bash
apksigner verify --verbose --print-certs ./update.apk
codesign -dv --verbose=4 ./Update.app
codesign --verify --deep --strict --verbose=2 ./Update.app
```

The Apple commands require macOS; the APK command requires Android build tools. A valid signature establishes properties checked by that tool, not that the product updater enforces its intended publisher. [APK signer](https://developer.android.com/tools/apksigner), [Apple code-signing inspection](https://developer.apple.com/library/archive/technotes/tn2206/_index.html).

2. **Identify the actual updater.** Read the shipped update library/version and packaging configuration. Electron update behavior depends on platform and package mechanism; a generic claim about all Electron applications is too broad. Android platform update signing is separate from application-managed downloadable modules or scripts. [Electron autoUpdater](https://www.electronjs.org/docs/latest/api/auto-updater), [Android application signing](https://developer.android.com/studio/publish/app-signing).

3. **Build three local controls.** Use a genuine authorized artifact as the positive control, a one-byte-corrupted copy as the integrity control, and an artifact signed by an unrelated lab publisher as the identity control where the harness supports it. Keep the latter inert. Change only the relevant input and record the precise rejection/acceptance decision. Acceptance of metadata alone does not establish installation; distinguish download, verification, staging and activation.

4. **Inspect the privilege boundary.** Determine who can write the staged artifact, parent directory, updater configuration and helper executable. On Windows, these commands inspect signatures and ACLs:

```powershell
Get-AuthenticodeSignature -FilePath 'C:\Lab\Update.exe' | Format-List
icacls 'C:\Program Files\ExampleApp'
icacls 'C:\Lab\Update.exe'
```

Use the actual observed staging path, not the illustrative path above. A broad ACL matters only if the standard user can control bytes that a more privileged process actually consumes. Demonstrate a harmless marker operation in a lab path; keep service identity and write access in the evidence. [Authenticode inspection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5), [ACL inspection](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls).

5. **Test rollback semantically.** Compare a supported older genuine release with the current release in the local harness. Check whether the defined version policy rejects it and whether an attacker can supply it without administrative or signing authority. Do not force an ADB downgrade and report the explicitly requested platform behavior as an updater bypass. Reuse [file boundaries](#page-modules-file-boundaries) for staging/extraction and [identity/session](#page-modules-identity-session) when a rollback changes credential protections.

## Completion and cleanup

- [ ] Record exact accepted bytes and identity, not just a green verification UI.
- [ ] Preserve genuine, tampered, wrong-publisher and applicable rollback results.
- [ ] Explain prerequisite control, installing privilege and demonstrated effect.
- [ ] Label locally modified verifier behavior as a limitation until release equivalence is established.
- [ ] Restore original feed/configuration, remove inert fixtures, restore the VM snapshot and confirm the normal update path works.

## Vulnerability reverse references

- [Updater accepts an artifact outside its publisher trust policy](#page-vulnerabilities-update-untrusted-artifact) — The real update decision accepts modified bytes or an unrelated publisher identity before activation.
- [Privileged updater consumes lower-user-controlled staging content](#page-vulnerabilities-updater-privileged-staging) — A standard user can replace a staged file or redirect a path actually consumed by a privileged installation process.
- [Attacker-controlled rollback restores a prohibited security state](#page-vulnerabilities-update-security-rollback) — An attacker bypasses an update version authorization policy to cause a rollback that restores a prohibited security state.


---

<a id="page-modules-ai-tool-trust"></a>

# AI tools: input trust, execution identity and approvals

Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.

## Investigation sequence

1. Pin legitimate task
2. Map context to tool
3. Run paired trials
4. Check server decision
5. Minimize evidence

## Used in these playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Start with a local agent application, two researcher-owned identities, and stub tools that write only to an in-memory ledger or local JSONL file. Record the model identifier, sampling settings, application commit, available tools, connector scopes and legitimate user task. The invariant is: **retrieved content can supply task data, but cannot grant permission, change the acting principal or silently expand an approved operation**. Reuse the [authorization matrix](#page-modules-authz-matrix) for tool objects and [identity/session procedure](#page-modules-identity-session) for credentials.

Make a four-column trust map: attacker-editable source, transformation, tool argument, server-side decision. Include tool descriptions, tool results, document text, OCR and summaries. Follow the actual source path using [source-to-sink review](#page-modules-source-dataflow). A changed answer style demonstrates instruction influence; a security finding needs an unauthorized read, write, destination, privilege or other protected consequence. OWASP separates excessive tool functionality, permissions and autonomy. [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)

## Controlled procedure

1. **Record the baseline.** Ask the owned victim agent to summarize one benign shared document. Save the exact prompt, document hash, tool calls and outbox state. Verify that a separately authorized mock write succeeds and an unapproved write is rejected; otherwise a silent tool failure could masquerade as protection.
2. **Change one lower-trust input.** In a copy of the document, add a test instruction requesting a harmless change to the stub destination. Keep task, tools and identities constant. Run five fresh baseline trials and five fresh candidate trials with a fixed small token budget. Save every attempt, including failures; do not assume sampling controls make a hosted model deterministic.
3. **Inspect execution independently.** Compare suggested calls, dispatched calls and committed stub events. Record which principal reached the backend. A model claiming success is insufficient. Repeat the same operation directly through the local tool adapter to determine whether the backend itself has an ordinary object-authorization defect.
4. **Bind approval to the action.** Approve one harmless draft, then vary only its object ID, destination or content in the local fixture. The approved values and executed values must match, or the product must request renewed approval according to its contract. Compare canonical argument digests, not UI labels.
5. **Check the MCP boundary separately.** With your own OAuth fixtures, compare a correct-resource token with a valid token for another resource. Exercise client A consent followed by a fresh client B request. MCP requires intended-audience validation and per-client consent in the documented proxy scenario; inherited upstream consent is not sufficient. Match all requests to the deployed protocol version. [MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), [MCP security guidance](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

## Command and evidence cheat sheet

Run these local inspection commands in the reviewed lab checkout. `lab/tool-events.jsonl` is your recorded adapter output, with one JSON object per event; these commands inspect evidence and do not invoke an agent.

```bash
rg -n 'approve|consent|tools/call|audience|tenant_id|workspace_id' ./src
python3 -I -S -m json.tool lab/case.json
python3 -I -S - <<'PY'
import json
from collections import Counter
with open('lab/tool-events.jsonl') as stream:
    rows = [json.loads(line) for line in stream if line.strip()]
print(Counter((r['case'], r['decision']) for r in rows))
PY
```

Use event fields `case`, `trial`, `principal`, `tool`, `argument_digest`, `decision` and `committed`. Redact credentials. Python's JSON CLI validates the case file; it does not assess the security result. [Python JSON documentation](https://docs.python.org/3/library/json.html)

## Evidence, false positives and completion

Preserve the legitimate task, attacker capability, differing document bytes, full relevant tool trace, principal and controlled side effect. Exclude hallucinated actions, canaries already present in the attack text, intentionally authorized tool use, and tests requiring nonexistent attacker editing rights.

- [ ] Baseline allowed operation and denied operation both work as expected.
- [ ] Every candidate has an unchanged benign comparison.
- [ ] Suggested, attempted and committed actions are distinguished.
- [ ] Approval arguments and execution identity are recorded.
- [ ] Successes/attempts and cleanup of local fixtures are included.

## Continue across task lifetime

An initial allowed or denied tool call does not cover later resumed work. Continue with [AI state lifecycle](#page-modules-ai-state-lifecycle) for memory/checkpoint ownership, MRTR state binding, cancel/retry behavior and private caches. Apply [resource budgets](#page-modules-resource-budget-controls) to tool fan-out, loop limits and per-principal cost without generating load on a live service. For model-output HTML, SQL or file effects, inspect the final consumer using [browser trust](#page-modules-browser-trust), [injection tracing](#page-modules-injection-tracing) and [file boundaries](#page-modules-file-boundaries); model output is input to those components.


## Vulnerability reverse references

- [Indirect prompt injection into protected tool actions](#page-vulnerabilities-indirect-prompt-tool-injection) — Lower-trust retrieved content influences the agent into a tool operation outside the legitimate task or granted authority.
- [Agent tool accepts unauthorized object or tenant parameters](#page-vulnerabilities-agent-tool-object-authorization) — A tool trusts caller-supplied object or workspace identifiers instead of enforcing the authenticated principal’s authority.
- [Agent approval is not bound to executed arguments](#page-vulnerabilities-agent-approval-argument-drift) — An approved harmless action can be modified before dispatch without revalidating the approval’s scope.
- [MCP proxy consent confuses different clients](#page-vulnerabilities-mcp-proxy-confused-deputy) — A proxy reuses upstream consent in a way that grants a new MCP client access without the resource owner’s intended per-client consent.
- [MCP accepts a token for another resource](#page-vulnerabilities-mcp-token-audience-confusion) — A protected MCP resource accepts a token that was not issued for that resource.
- [MCP resumed state changes authorization or request meaning](#page-vulnerabilities-mcp-resume-state-integrity) — An MRTR server trusts modified or context-mismatched requestState when it affects a protected resumed operation.
- [Untrusted model artifact reaches executable deserialization or custom code](#page-vulnerabilities-model-artifact-unsafe-loading) — An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.


---

<a id="page-modules-rag-tenant-isolation"></a>

# RAG isolation: ingestion, retrieval, citations and revocation

Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.

## Investigation sequence

1. Seed private canaries
2. Verify direct access
3. Trace retrieval
4. Change ownership state
5. Compare exposed results

## Used in these playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Use owned tenants A/B with private and shared collections. Place unique markers only in each tenant's private document. Record ingestion state, collection/document IDs and permissions. The invariant is: **the effective caller can retrieve or resolve only currently authorized content through every supported path**. Reuse the [authorization matrix](#page-modules-authz-matrix) for object swaps and [identity/session checks](#page-modules-identity-session) for tenant identity.

Unauthorized chunks may reach the model without appearing in its answer; filtered search can still return an unprotected citation download. OWASP identifies risks from shared vector stores and inadequate access controls. Test those boundaries separately. [OWASP Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)

## Controlled procedure

1. **Prove readiness.** As A retrieve A's canary; as B retrieve B's. Then request B's document directly as A and verify denial. Record whether permissions belong to tenants, teams, individual users or externally synchronized groups. A canary missing from its owner's search is an ingestion problem, not isolation evidence.
2. **Compare retrieval paths.** As A, issue the same semantic query used by B, with no secret marker in the query. Exercise search, chat, document lookup and citation download independently. In a local white-box fixture, log the authenticated principal, effective query filter, retrieved chunk IDs and resolver decision. Repeat with an absent tenant filter and a B collection ID only where the API actually accepts those fields.
3. **Inspect ingestion ownership.** Upload a harmless A document while supplying B's collection or source reference. Confirm where the completed document is stored and who can read it. A rejected upload is a useful negative control; a successful job response alone does not show cross-tenant insertion. Follow async workers and document reindexing through [source dataflow](#page-modules-source-dataflow).
4. **Test sharing transitions.** Share one synthetic document, retrieve it legitimately, then revoke access. After the product's documented synchronization interval, test a fresh conversation, an existing conversation, direct download, citations and cached answers. Record which content was already delivered before revocation; users retaining their earlier copy is not a new disclosure.
5. **Separate caches from filters.** Warm a cache as B, repeat the same query as A, then repeat after an allowed lab cache clear or with a new synthetic document. Compare cold/warm results and cache keys. If only the warm path leaks, preserve that sequence. Test an A-only cache warm as the benign comparison.

## Reusable case matrix

| Case | Caller and state | Expected observation |
|---|---|---|
| Owner baseline | B → B-private document | Retrieval and resolver succeed |
| Tenant isolation | A → B-private document | No unauthorized chunk or download |
| Shared baseline | A → explicitly shared document | Allowed content is available |
| Revocation | A after share removal and sync | New protected retrieval is denied |
| Cache separation | B warms; A repeats | B's private result is absent |

## Local command cheat sheet

```bash
python3 -I -S - <<'PY'
import secrets
for owner in ('A', 'B'):
    print(owner + '_PRIVATE_' + secrets.token_hex(16))
PY
rg -n 'tenant_id|collection_id|document_id|cache_key|namespace' ./src
python3 -I -S -m json.tool lab/retrieval-case.json
```

Store each generated marker only in its private fixture. Record caller, path, expected/actual document IDs, visibility and timestamp. These commands do not call hosted models or vector databases. [Python secrets](https://docs.python.org/3/library/secrets.html)

## Evidence and checklist

Report the strongest observed boundary precisely: unauthorized chunk retrieval in logs, user-visible disclosure, or unprotected download. Do not present an internal trace as proof that an external attacker can see its contents. Exclude intentional shared collections, stale permissions within the stated synchronization window and markers included in the user's own query.

- [ ] Both owners can retrieve their own seeded documents.
- [ ] Search, answers and citation resolution were compared separately.
- [ ] Cold/warm cache and sharing-state controls are recorded.
- [ ] Actual caller identity and document ownership support the claim.
- [ ] Synthetic documents and temporary sharing grants were removed.

## Beyond document retrieval

Run [AI state lifecycle](#page-modules-ai-state-lifecycle) when a private chunk is copied into a conversation, checkpoint, durable memory, background job or protocol cache. Record the new object owner and retention rule at each copy. A fresh search filter cannot repair an earlier copy served through an unprotected history/export API. Reuse the revocation controls above and distinguish content already delivered under a valid grant from a newly exposed private artifact.


## Vulnerability reverse references

- [RAG retrieval or citation resolver crosses tenant boundaries](#page-vulnerabilities-rag-cross-tenant-retrieval) — Search filters, chunk retrieval or citation download omit an ownership decision required for the effective caller.
- [RAG cache or fresh retrieval ignores revoked access](#page-vulnerabilities-rag-cache-revocation-leak) — A new retrieval or cache response exposes protected content after its applicable permission revocation has taken effect.
- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership) — Persisted agent state or its resume/export path is accessible or mutable by a principal outside its intended owner or sharing grant.
- [Private MCP result is reused across authorization contexts](#page-vulnerabilities-mcp-private-cache-context) — A shared cache delivers caller-specific protocol data outside the authorization context that produced it.


---

<a id="page-modules-smart-contract-state"></a>

# Contract state: authorization, callbacks and accounting

Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.

## Investigation sequence

1. Resolve implementation
2. Write unit-aware invariants
3. Build actor baseline
4. Exercise sequences
5. Minimize state trace

## Used in these playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Prepare a reviewed local checkout with dependencies and compiler already available. Use a private local EVM test harness; keep wallet secrets absent and review configuration for FFI, RPC endpoints and fork creation before execution. Record commit, compiler settings, proxy family, implementation, initialized roles and supported token behavior. A local reproduction against a simplified model explains an idea; an eligible report must establish that the same path exists in the relevant deployed implementation.

Write properties using explicit units: assets, shares, debt, fees and time. For example, **redeeming a claim cannot pay more assets than its defined entitlement**, and **an ordinary actor cannot change the implementation or initialize an already initialized proxy**. Do not equate token balance and share supply. Reuse the [authorization matrix](#page-modules-authz-matrix) for actors and protected transitions. OpenZeppelin documents proxy-specific initialization and upgrade behavior, so inspect the actual family and version. [OpenZeppelin proxies](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

## Controlled procedure

1. **Build realistic actors.** Separate setup administrator, ordinary depositor A, depositor B and callback receiver. Setup may allocate synthetic tokens, but record each privilege and stop using administrator impersonation before the candidate sequence. Verify a normal deposit/redemption round trip and expected privileged-operation rejection.
2. **Trace callbacks.** Mark every external call and the state visible at that instant. Give an owned callback contract one bounded reentry attempt into the original or a related function. Compare with a receiver that accepts the callback without reentry. Solidity warns that reentrancy concerns external contract calls and interacting contracts, not only Ether transfers. [Solidity security considerations](https://docs.soliditylang.org/en/latest/security-considerations.html)
3. **Track independent accounting.** Record user assets, shares, protocol holdings, debts and fees before and after every action. Calculate the expected relationship independently of the implementation under test. For rounding, test zero supply, minimal amounts, mixed decimals, partial redemption and a direct donation, using only supported tokens. Quantify attacker cost as well as victim loss. ERC-4626 conversions and donations can expose rounding-sensitive states. [OpenZeppelin ERC-4626](https://docs.openzeppelin.com/contracts/5.x/erc4626)
4. **Exercise ordering.** Try short valid sequences: deposit → transfer shares → redeem; deposit → donate → second deposit; callback → related read/write; initialize → initialize again. Change one amount, role or order at a time. Count successful state-changing calls so an all-revert fuzz run cannot be mistaken for coverage.
5. **Minimize the failure.** Reduce the sequence and amounts while preserving the violated property. Run the identical sequence with the benign callback or corrected authorization as a control. Preserve the earliest inconsistent state as well as the final balance difference.

## Harness and command cheat sheet

Create target-specific test functions; the names below are a suggested harness contract, not built-in Foundry scans.

| Function | Required assertion |
|---|---|
| `test_BaselineRoundTrip` | Expected fees and rounding explain final balances |
| `test_UnauthorizedUpgradeDenied` | Ordinary actor cannot alter implementation |
| `test_CallbackInvariant` | Bounded callback preserves the chosen property |
| `test_MinimizedSequence` | Replays exact candidate and checks measured effect |

```bash
git rev-parse HEAD
forge --version
rg -n 'ffi|rpc_endpoints|createFork|createSelectFork' foundry.toml test
forge test --match-test '^test_BaselineRoundTrip$' -vvvv
forge test --match-test '^test_CallbackInvariant$' -vvvv
forge test --match-test '^test_MinimizedSequence$' -vvvv
```

Run only after the named local tests exist and their setup has been reviewed. `--match-test` selects your tests; verbosity exposes local traces. These commands do not broadcast transactions, but test code can explicitly access external resources, which is why harness review matters. [Foundry test reference](https://www.getfoundry.sh/reference/forge/test)

## Evidence, false positives and completion

Provide the implementation identity, exact harness, trace, initial capital, privileges, unit-aware balance sheet and bounded impact. Exclude unsupported malicious-token assumptions, fabricated oracle authority, admin-only behavior working as designed, and a callback that cannot occur in the real path.

- [ ] Baseline exercises the same implementation and setup.
- [ ] Actor powers match the claimed attack model.
- [ ] Successful transitions and reverts are counted.
- [ ] Loss is demonstrated independently of total value locked.
- [ ] Reproduction stays entirely in the local EVM.

## Vulnerability reverse references

- [Contract callback reentrancy violates a state invariant](#page-vulnerabilities-contract-reentrant-state) — Nested calls observe or alter state under assumptions that do not hold while an earlier operation is incomplete.
- [Contract initializer permits unauthorized ownership or configuration](#page-vulnerabilities-contract-unprotected-initializer) — A reachable initialization path lets an ordinary actor establish or replace privileged state outside the intended deployment lifecycle.
- [Contract upgrade authority can be bypassed](#page-vulnerabilities-contract-upgrade-authorization) — An actor outside the upgrade policy can change a proxy’s execution target or equivalent privileged configuration.
- [Vault share conversion or rounding breaks entitlement](#page-vulnerabilities-contract-share-accounting) — Conversions, fees or rounding create an unintended claim on assets or an eligible loss under supported token behavior.


---

<a id="page-modules-contract-signatures-oracles"></a>

# Contract signatures and oracles: context, freshness and units

Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.

## Investigation sequence

1. Record trust contract
2. Prove valid baseline
3. Vary one binding
4. Vary feed metadata
5. Calculate consequence

## Used in these playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Setup and invariants

Create two locally deployed verifier instances, a local-only signer, two ordinary actors and a mock feed whose state you can vary. Write the expected signed action as a tuple: signer, action type, recipient, amount, nonce, deadline, chain and verifying contract. Record which fields the application intentionally binds. The invariant is: **a signed instruction permits only its intended action and replay policy**. EIP-712 defines typed hashing and domain separation; replay protection remains the application's responsibility. [EIP-712](https://eips.ethereum.org/EIPS/eip-712)

For price consumers, record base/quote currency, feed decimals, token decimals, supported price range, freshness policy and dependency-failure behavior. The invariant is: **an accepted observation has the meaning and validity required for the resulting economic decision**. Chainlink exposes round metadata and timestamps; consumers must interpret them in their own integration. [Chainlink data-feed API](https://docs.chain.link/data-feeds/api-reference)

## Controlled procedure

1. **Prove both baselines.** A valid local signature executes its harmless ledger action once. A fresh positive-price feed produces the expected collateral or quote calculation. Verify an invalid signature and an explicitly disallowed stale observation are rejected, where that policy is part of the product's contract.
2. **Vary one signature dimension.** After the valid action, replay exactly the same bytes. Then use fresh baselines to vary only the recipient, amount, action type, verifier instance, chain context or expired timestamp. Record the recovered signer and nonce-consumption point. A reverting transaction normally rolls back its state; prove whether the replay state survives a successful action rather than assuming a pre-revert write consumed the nonce.
3. **Check alternate signer paths.** If contract wallets are supported, compare an owned wallet returning the ERC-1271 success value `0x1626ba7e`, a wallet returning a different value, and a reverting wallet. A non-reverting call alone does not establish a valid signature. ERC-1271 validity can depend on current contract state: change the authorized local signer after a valid baseline and repeat only where the consumer promises current authorization. Record validation at execution versus an intentionally earlier irrevocable authorization. Do not classify unsupported signature formats as a vulnerability. Reuse [identity and session binding](#page-modules-identity-session) for off-chain issuance. [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271).
4. **Vary feed metadata.** Starting from a valid response, test an old timestamp, zero or negative answer where the feed type can produce it, changed decimals, failed feed call and mismatched quote currency. Keep all other fields realistic. Demonstrate the consumer's accepted result and economic effect; an artificial impossible feed response is a robustness result until reachable conditions are shown.
5. **Test L2 recovery if applicable.** Model sequencer down, just restarted and beyond the configured grace period separately. This is integration-specific: not every chain or feed uses identical checks. Chainlink's L2 guidance explains uptime signals and post-recovery grace periods. [L2 sequencer feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds)
6. **Calculate the consequence.** Compare collateral, debt, quote or liquidation outcome with an independently calculated expectation. Include price units, rounding, capital, timing, fees and user constraints. A missing named check without a reachable incorrect decision remains a review lead.

## Local cheat sheet and case matrix

Implement these names in your reviewed local Foundry harness; they are not scanner features. The signer key must be generated or hard-coded solely for this disposable local fixture.

```bash
rg -n 'ecrecover|nonces|deadline|DOMAIN_SEPARATOR|latestRoundData|decimals' src
forge test --match-test '^test_ValidSignature$' -vvvv
forge test --match-test '^test_ReplayRejected$' -vvvv
forge test --match-test '^test_WrongDomainRejected$' -vvvv
forge test --match-test '^test_StaleFeedRejected$' -vvvv
forge test --match-test '^test_PriceUnitInvariant$' -vvvv
```

`--match-test` selects target-specific tests and trace verbosity helps identify the accepted transition. Use preinstalled compiler/dependencies and no RPC/fork/FFI setup for these local fixtures. [Foundry test reference](https://www.getfoundry.sh/reference/forge/test)

| Comparison | Hold constant | Vary |
|---|---|---|
| Replay | Signature, actor, verifier | Prior successful consumption |
| Domain | Message and signature | Local verifier or chain context |
| Freshness | Price and units | Observation timestamp |
| Unit conversion | Economic value | Supported decimal representation |

## Evidence and checklist

- [ ] Exact message schema, domain and successful baseline are saved.
- [ ] Only one context field changes in each negative case.
- [ ] Mock feed deviations are separated from reachable attacker powers.
- [ ] Nonces, timestamps, units and downstream decisions appear in evidence.
- [ ] No real signatures, transactions or funds are used.

## Vulnerability reverse references

- [Signed contract action can be replayed unexpectedly](#page-vulnerabilities-contract-signature-replay) — A successfully consumed authorization remains reusable despite a one-use or otherwise bounded execution contract.
- [Signed action does not bind its intended context](#page-vulnerabilities-contract-signature-context) — A valid signature is accepted for another recipient, action, verifier or chain context contrary to the authorization contract.
- [Oracle freshness or dependency state permits an invalid decision](#page-vulnerabilities-contract-stale-oracle) — A consumer accepts an observation outside its required freshness or availability conditions and makes an incorrect economic decision.
- [Oracle denomination or decimal conversion is incorrect](#page-vulnerabilities-contract-oracle-unit-confusion) — The consumer mixes quote currencies, token precision or feed precision and assigns the wrong economic value.


---

<a id="page-modules-firmware-update"></a>

# Firmware update and boot trust: signed bytes, product binding and rollback

Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.

## Investigation sequence

1. Identify image and board
2. Trace acceptance gates
3. Compare artifact variants
4. Inspect boot and recovery
5. Record bounded result

## Used in these playbooks

[Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Obtain an authentic image and record product/SKU, board revision, SoC revision, firmware version, source and SHA-256. Use an isolated non-root workspace with no device attached for initial review. Prepare an original and disposable copies, the relevant verification code if available, and a recoverable owned lab device only if later needed. The invariant is: **only authorized, correctly targeted software at an allowed security version reaches execution**.

Separate five gates: who can request an update, how metadata is authenticated, which payload bytes are verified, whether that image fits this product, and what the boot path enforces. TLS does not replace image authenticity. An encrypted package is not automatically signed. OWASP treats update authorization, signature verification and rollback as distinct tests. [OWASP firmware update tests](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)

## Controlled procedure

1. **Map the container.** Identify headers, manifest, payload, signatures and any bootloader/recovery component. Locate verification before extraction, writing and execution. If source is available, follow length and offset calculations using [source dataflow](#page-modules-source-dataflow). Keep extraction confined because the archive parser is itself exposed to untrusted input.
2. **Establish the acceptance baseline.** Feed an unchanged vendor image into the actual local verifier, emulator or documented validation-only path. Confirm it accepts the correct product and rejects a genuinely malformed sample. A checker that rejects every file provides no useful security comparison.
3. **Change one field or byte.** On disposable copies, alter one non-executable payload marker, remove the signature, change a target identifier or alter a signed manifest field. Record both package parsing and signature decisions. Use a vendor-accurate container parser: an arbitrary byte flip that destroys compression only demonstrates malformed-input rejection.
4. **Test version policy.** Compare an allowed current image with an authentic older signed image that has a known lower security version. Inspect whether the permitted caller can lower the stored security counter or select an alternate recovery path. A lower marketing version is not necessarily a lower security version. Espressif's OTA documentation distinguishes application rollback after failed validation from anti-rollback based on security version. [Espressif OTA](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/ota.html)
5. **Inspect execution trust.** Map ROM → bootloader → selected application, including alternate slots and recovery. Determine whether an update accepted into storage would still fail at boot. For supported ESP32 revisions, Secure Boot v2 verifies bootloader and application signatures; applicability depends on chip revision and enabled configuration. [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html)

## Local inspection cheat sheet

```bash
mkdir -p evidence
sha256sum firmware.bin > evidence/firmware.sha256
file firmware.bin > evidence/firmware-format.txt
binwalk firmware.bin > evidence/firmware-layout.txt
rg -n -i 'signature|rollback|secure_version|board_id|verify' ./source
```

Binwalk's default file argument identifies embedded content; extraction requires a format-appropriate, separately reviewed procedure. These commands do not flash, boot or rewrite firmware. [Binwalk README](https://github.com/ReFirmLabs/binwalk/blob/master/README.md)

Create this reusable acceptance matrix before modifying any copy:

| Variant | Expected verifier result | Record separately |
|---|---|---|
| Authentic current image | Accept for correct product | Parser, signature, model and version |
| Altered protected payload | Reject | Verified byte range and error stage |
| Wrong product | Reject if product binding is required | Target identifier and compatibility |
| Older security version | Enforce documented downgrade policy | Counter and recovery behavior |

## Evidence, false positives and completion

Report precisely where the candidate crosses a boundary: parse acceptance, staging, installation or actual execution. Do not turn acceptance by a standalone inspection tool into a device execution claim. Debug builds, an administrator's explicitly supported downgrade, unsigned non-executable padding and a vendor checksum mismatch alone are common false positives.

- [ ] Authentic baseline and every modified copy are hashed.
- [ ] Parser rejection and authentication rejection are distinguished.
- [ ] Security-version policy and attacker update privilege are stated.
- [ ] Boot/recovery enforcement limits the claimed impact appropriately.
- [ ] No fuse, bootloader or production-device write was needed for this procedure.

## Vulnerability reverse references

- [Firmware verifier accepts unauthenticated protected bytes](#page-vulnerabilities-firmware-signature-validation) — The relevant update acceptance path fails to authenticate executable payload or security-relevant metadata correctly.
- [Firmware security-version state can be lowered](#page-vulnerabilities-firmware-security-version-rollback) — An attacker can reduce the protected security version and thereby restore software excluded by the anti-rollback policy.
- [Firmware verification fails to enforce required product binding](#page-vulnerabilities-firmware-product-binding) — An otherwise authentic image is accepted for an incompatible product or security configuration despite required target restrictions.
- [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap) — A reachable boot path omits an authenticity check required by the product’s execution trust model.


---

<a id="page-modules-hardware-interfaces"></a>

# Hardware interfaces: production debug access and protected data

Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

## Investigation sequence

1. Document access model
2. Observe baseline
3. Classify interface
4. Check protected capability
5. Confirm production state

## Used in these playbooks

[Hardware & firmware](#page-hardware) · [Network services](#page-network)

## Setup and security invariant

Record exact retail SKU, board revision, installed firmware, provisioning state and whether the case must be opened. Distinguish unauthenticated nearby access, opened-case access and already privileged administrator access. Use a recoverable owned bench device, its matching documentation and a passive capture first. The invariant is: **the documented physical access level does not expose a protected command, memory region or reusable credential without the required authorization**.

Use the shared [authorization matrix](#page-modules-authz-matrix) for local service roles and [identity/session checks](#page-modules-identity-session) when the device also has app/cloud identities. Network callbacks or downloaded configuration belong in the shared [SSRF boundary procedure](#page-modules-ssrf-boundary); permission to inspect a purchased device does not extend to unrelated cloud services.

## Controlled procedure

1. **Preserve the retail baseline.** Photograph configuration and interface locations without unnecessary serial numbers. Record whether secure boot, flash encryption and debug locks are configured, using read-only vendor diagnostics when available. A development board or previously unlocked unit cannot establish behavior on a locked retail device.
2. **Observe UART without transmitting.** Verify pinout, ground and logic voltage before connecting a receive-only capture adapter or logic analyzer. Keep transmit and power pins disconnected for passive observation. Record baud/framing from documentation or the capture, startup stage and visible data. Do not assume that an RS-232 adapter and a TTL UART use compatible electrical levels.
3. **Classify the capability.** Separate boot logs, an authenticated console, an unauthenticated restricted monitor and a privileged shell. A prompt string proves neither interactivity nor privilege. If a console is within the lab scope, use a benign identity query or read a synthetic fixture after documenting why that access should be restricted. Compare logged-out versus correctly authenticated behavior. OWASP's internal-interface tests distinguish exposed functionality and authorization. [OWASP internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md)
4. **Assess JTAG/SWD conservatively.** Start from documented lock state and allowed read-only diagnostics. Prove a specific protected capability only on a suitable lab unit; avoid unlock, erase, fuse and flash commands. Finding pads or a debug identifier is weaker than reading a protected synthetic memory region. CWE-1191 specifically covers access control for on-chip debug and test interfaces. [CWE-1191](https://cwe.mitre.org/data/definitions/1191.html)
5. **Classify recovered secrets.** In offline firmware, distinguish public certificates, password hashes, test credentials, per-device private keys and fleet-wide credentials. Compare two authentic owned-device images if available. Demonstrate a candidate credential's function on a local service, with redacted output; do not try it against vendor infrastructure. Installed-firmware review includes exposed authentication material and configuration. [OWASP installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md)
6. **Confirm and restore.** Reproduce after a supported clean reset if needed and safe for the unit. Record what access survived, what was configured during testing and whether recovery succeeded. State emulation or missing hardware limitations explicitly.

## Offline command cheat sheet

```bash
rg -n -i 'login|console|debug|jtag|swd|password|private.key' extracted-rootfs
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
sha256sum evidence/uart-capture.bin
```

These commands inspect an already extracted filesystem and saved UART capture. Replace the daemon with an identified ELF; `readelf` is not useful for arbitrary compressed firmware. `-h` shows the ELF header, `-l` program headers and `-W` wide output. [GNU readelf](https://sourceware.org/binutils/docs/binutils/readelf.html)

## Evidence and completion

Capture access level, wiring diagram, voltage, tool version, production lifecycle state, before/after decisions and protected capability. A verbose boot log, root access granted to an intended administrator, generic missing hardening, or readable public key is not automatically a vulnerability.

- [ ] Retail and debug configurations are distinguished.
- [ ] Passive observation precedes any authorized interaction.
- [ ] Prompt visibility and protected capability are separate findings.
- [ ] Secret classification is supported without exposing usable values.
- [ ] No irreversible debug unlock or device write was performed.

## Vulnerability reverse references

- [Boot or recovery path executes an unverified component](#page-vulnerabilities-firmware-boot-chain-gap) — A reachable boot path omits an authenticity check required by the product’s execution trust model.
- [Production UART exposes an unauthenticated privileged console](#page-vulnerabilities-hardware-unauthenticated-console) — The in-scope physical access model yields a protected console capability without required authentication.
- [On-chip debug interface exposes protected memory or control](#page-vulnerabilities-hardware-debug-authorization) — A production debug/test interface permits a protected capability beyond the documented physical-access authorization.
- [Firmware contains a reusable shared authentication credential](#page-vulnerabilities-firmware-shared-credentials) — An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.


---

<a id="page-modules-authenticator-lifecycle"></a>

# MFA and passkeys: enrollment, proof, replacement, and recovery

Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.

## Investigation sequence

1. Record assurance policy
2. Enroll controlled factors
3. Compare fresh and stale proof
4. Check assertion bindings
5. Replace and recover
6. Verify removal

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

### Setup and invariant

Reuse [identity/session fixtures](#page-modules-identity-session). Prepare two disposable accounts, recovery access, separate browser profiles, and one reversible protected operation. Record whether the product promises MFA, passwordless login, recent reauthentication, or a particular authenticator class; these are different contracts. The invariant is: **a proof must authorize the intended account, ceremony, and assurance level, including factor management**. Capture the server's stored factor list and audit events, not just a green browser badge.

### Numbered procedure

1. **Test enrollment before authentication.** Register A's first and second factors through the legitimate UI. Compare an authenticated registration with anonymous, MFA-pending, and stale-session attempts to complete that same observed operation. For an account-bound enrollment flow, begin in A and attempt completion in B, changing only the account/session context. Confirm the final factor owner with a fresh login. For username-less authentication, successful login to the factor's rightful owner is expected; it must not be reported as cross-account bypass.
2. **Exercise replacement and removal.** Capture normal add, rename, delete, recovery-code regeneration, and fallback changes. In the replica, replay one sensitive factor change without the required recent proof, then with a fresh valid proof. Verify whether a newly added factor can log in and whether the removed factor still authenticates. Preserve a recovery route throughout. A factor addition that only changes a label proves nothing. Factor replacement deserves the same care as initial login. [OWASP MFA management](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html).
3. **Test OTP and recovery consumption separately.** Use A's successful OTP once more in a fresh pending login during its validity window; use an invalid code as the negative control. Test one recovery code, then attempt the consumed code again. Regenerate the recovery-code set and check one old code. Do not brute-force codes or trigger real push/SMS floods. Record which transaction succeeded, not merely whether the numeric value appeared twice. TOTP verification must prevent reuse after successful validation; an identical code displayed during one time step is normal. [RFC 6238](https://www.rfc-editor.org/rfc/rfc6238.html). Saved recovery credentials also need explicit lifecycle controls. [NIST authenticator management](https://pages.nist.gov/800-63-4/sp800-63b.html).
4. **Build a real passkey baseline.** In the local application, open DevTools → More tools → WebAuthn, enable the virtual authenticator, select CTAP2 and the required resident-key/user-verification capabilities, then register through the application's normal page. Record the RP ID and credential owner. This tests server integration; it does not demonstrate compromise of a hardware authenticator. [Chrome virtual-authenticator workflow](https://developer.chrome.com/docs/devtools/webauthn/).
5. **Separate signature checks from semantic checks.** Compare a fresh assertion with a consumed assertion and one with an invalid signature. For username-first login, verify the credential belongs to the intended account; for discoverable credentials, verify the returned user handle resolves consistently to the credential owner. Trace the verifier's challenge, ceremony type, origin, RP-ID hash, signature, and presence/verification decisions. A local authenticator fixture can sign a deliberately mismatched case; changing signed JSON without re-signing only tests signature rejection. [WebAuthn assertion fields](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Authentication.html).
6. **Check policy-sensitive WebAuthn branches.** Verify UV when the ceremony requires user verification; a touch proving user presence does not by itself prove UV. Account for an explicitly configured related-origin deployment and applicable legacy AppID handling before calling an origin/RP mismatch a bypass. Counter anomalies are risk signals, not standalone clone proof; some authenticators keep zero counters. Synced credentials and absent attestation are not automatically weaknesses. Evaluate the deployed library and RP policy against the pinned [WebAuthn Level 3 Recommendation](https://www.w3.org/TR/2026/REC-webauthn-3-20260825/).

### Local inspection card

Export an **owned test assertion** in the application's JSON transport format to `assertion.json`. This prints selected metadata and a challenge fingerprint; it does not verify the signature or establish a vulnerability. If your wrapper uses different keys, adapt the field path.

```bash
python3 - <<'PYCODE'
import base64, hashlib, json
from pathlib import Path
x = json.loads(Path('assertion.json').read_text())
s = x['response']['clientDataJSON']
c = json.loads(base64.urlsafe_b64decode(s + '=' * (-len(s) % 4)))
print(json.dumps({
    'type': c.get('type'), 'origin': c.get('origin'),
    'crossOrigin': c.get('crossOrigin'),
    'challenge_sha256': hashlib.sha256(c['challenge'].encode()).hexdigest()
}, indent=2))
PYCODE
```

### Evidence and completion

Report a newly usable unauthorized factor, authentication below a required assurance level, or acceptance of a proof for the wrong account/transaction. Attach the expected rule, before/after factors, request order, independent fresh-login result, and cleanup. Missing notification alone is hardening evidence; a successful server rejection is a passed check.

- [ ] Enrollment and replacement evaluated independently.
- [ ] OTP, backup codes, and passkey ceremonies have separate controls.
- [ ] Username-first and discoverable flows distinguished.
- [ ] Signature rejection separated from signed-context validation.
- [ ] Removed test factors and credentials no longer authenticate.
- [ ] Virtual authenticator exports and live recovery secrets excluded from reports.


## Vulnerability reverse references

- [Authentication or MFA state bypass](#page-vulnerabilities-authentication-incomplete-state-bypass) — A session that has not completed required authentication can perform protected operations.
- [Unauthorized authenticator enrollment, replacement, or removal](#page-vulnerabilities-authenticator-management-proof-bypass) — A lower-assurance or wrong-account context can add, replace, or remove an authentication factor contrary to its management policy.
- [WebAuthn assertion accepted for an invalid account or ceremony context](#page-vulnerabilities-webauthn-assertion-binding-failure) — The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.


---

<a id="page-modules-federation-token-trust"></a>

# OAuth, OIDC, and SAML: transaction binding and token trust

Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

## Investigation sequence

1. Map issuers and clients
2. Capture authorized flow
3. Alter one binding
4. Verify token semantics
5. Check replay and linking
6. Remove test grants

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

### Setup and trust record

Use two controlled accounts, two registered lab clients when available, and a test identity provider. Record authorization server, client ID/type, exact redirect URI, grant, scopes, resource/audience, browser transaction, issuer/subject, and resulting local account. Pin deployed protocol profiles and libraries. Reuse the [session lifecycle](#page-modules-identity-session) and [authorization matrix](#page-modules-authz-matrix); this procedure adds federation-specific decisions.

The invariant is: **a valid credential for one transaction, client, issuer, or purpose must not silently authorize another**. A decoded token, valid cryptographic signature, and successful login are three different observations.

### Numbered procedure

1. **Establish browser binding.** Capture a normal authorization-code login and a separate account-link operation. In the replica, deliver A's response into B's pending transaction and compare the resulting local account/link with untouched controls. Track which session initiated each transaction. Missing `state` alone is not decisive when transaction-specific PKCE or another valid mechanism provides the required binding. Validate a registered redirect with exact matching, accounting for the native loopback-port exception. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html).
2. **Check code and PKCE handling independently.** On separate fresh authorization codes, compare the correct verifier, a wrong verifier, and a missing verifier. Then replay one already redeemed code. Where the flow supports PKCE, inspect whether removing the challenge can create a downgrade path. Keep client authentication, client ID, and redirect constant so rejection can be attributed correctly. A verifier is secret; a public challenge is not. Generate a new verifier for each real transaction. [PKCE specification](https://www.rfc-editor.org/rfc/rfc7636.html).
3. **Validate OIDC context.** With the lab issuer, produce otherwise valid fixtures with one wrong issuer, client audience, expired time, or mismatched nonce when that flow requires it. Check profile-specific `azp`, hash, and authentication-age rules rather than assuming every claim is universal. Local identity should use the issuer/subject pair; equal email claims do not establish that two identities may be merged. Compare UserInfo subject with the ID-token subject when UserInfo is used. [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html).
4. **Test JWT trust and purpose.** First show rejection of one invalid signature. Then use validly signed local fixtures for another resource or purpose: an ID token at an access-token endpoint, or an email-verification token at a session endpoint, where the implementation exposes that path. In source review, inspect algorithm allowlists, issuer-selected key material, key-ID lookup, and mutually exclusive validation rules. Do not turn a token-supplied key URL into a production callback experiment. A signature-valid but unauthorized token is a semantic trust failure, not necessarily broken cryptography. [RFC 8725](https://www.rfc-editor.org/rfc/rfc8725.html).
5. **Check refresh replay under the actual design.** Record original and rotated refresh credentials separately. After one normal rotation, attempt the previous credential once from another local client and inspect both the returned token and a harmless resource read. If tokens are sender-constrained, test the relevant missing/wrong sender proof instead. Public-client refresh tokens require rotation or sender constraint; documented retry grace affects interpretation but does not erase demonstrated independent unauthorized access. [OAuth refresh-token protection](https://www.rfc-editor.org/rfc/rfc9700.html).
6. **Follow SAML from verified bytes to identity.** In a local IdP/SP pair, compare a normal response with independently changed signed content, a wrongly targeted assertion, an expired assertion, and one replay. Trace the exact signed element from which the SP consumes identity and attributes; verifying an unrelated signed element is insufficient. For SP-initiated SSO check request correlation. For supported IdP-initiated SSO, missing request correlation is expected, but replay and recipient/trust checks still matter. Keep RelayState handling separate from assertion integrity. [OWASP SAML processing](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html).

### Local command card

Prepare `expected.header` and `other-resource.header` using **valid tokens minted by your lab issuer**; each contains its complete `Authorization: Bearer …` line. The second token is intentionally valid only for a different resource under the issuer policy. Preserve the same subject and request where possible. The protected route is illustrative. These requests do not test a public provider.

```bash
mkdir -p evidence/federation
chmod 600 expected.header other-resource.header
curl -q --noproxy '*' --max-time 10 --header @expected.header \
  -D evidence/federation/expected.h -o evidence/federation/expected.json \
  http://127.0.0.1:8000/api/me
curl -q --noproxy '*' --max-time 10 --header @other-resource.header \
  -D evidence/federation/wrong-resource.h -o evidence/federation/wrong-resource.json \
  http://127.0.0.1:8000/api/me
```

A 401/403 is a useful control, but also inspect bodies and resulting identity. Successful use of the expected token establishes only the baseline. Token transport and audience selection must match the actual local deployment.

### Evidence and checklist

Capture one invalid condition, accepted identity or capability, minimal synthetic response, and the intended trust configuration. Document any test signing keys you supplied: possession of the real IdP signing key already grants authority and is not a new bypass. A rejected code, intentional multi-audience policy, or unconsumed altered claim is not takeover evidence.

- [ ] Browser binding and token validity tested separately.
- [ ] Correct, wrong, omitted, and consumed proof cases kept distinct.
- [ ] Token purpose and issuer/audience validation separated from signature validation.
- [ ] SAML consumed identity traced to the validated signed element.
- [ ] Grants, sessions, test keys, and transient credentials removed after evidence capture.


## Vulnerability reverse references

- [OAuth login or account-linking confusion](#page-vulnerabilities-oauth-login-account-linking-confusion) — An authorization response or external identity is bound to the wrong application session or controlled account.
- [JWT signature, issuer, audience, or token-purpose validation failure](#page-vulnerabilities-jwt-signature-trust-failure) — A service accepts token claims without the required signature or trusted issuer/key validation.
- [SAML assertion signature, audience, or response binding failure](#page-vulnerabilities-saml-assertion-trust) — The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
- [Verification or account merge preserves another actor's access](#page-vulnerabilities-identity-verification-merge-confusion) — Registration, verification, email change, or federation merging transfers trust to an identity while retaining an unintended actor's usable credentials or session.
- [Enforced SSO bypass through an alternate login path](#page-vulnerabilities-enforced-sso-alternate-login-bypass) — A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.


---

<a id="page-modules-request-value-parsing"></a>

# Request values: duplicate parameters, parser conflicts and downstream queries

Trace the value a security layer validates through to the value the application or downstream service actually consumes.

## Investigation sequence

1. Map parser chain
2. Freeze two object controls
3. Vary one representation
4. Trace authorized value
5. Inspect consumed value
6. Prove controlled impact

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Map the actual processing chain: gateway, framework parser, schema validator, authorization code, service client, and worker. Use two synthetic objects, A-readable O1 and B-only O2, in a local replica with per-layer logs. The invariant is: **the value authorized is the same value the protected operation consumes**. This procedure covers application values; HTTP message framing stays in the [proxy/cache procedure](#page-modules-proxy-cache).

### Numbered test procedure

1. **Create a value ledger.** Capture raw request bytes, content type, parsed field type, validated value, authorized object and final downstream request. Start with O1 allowed and O2 denied under A's identity. Disable response caching for this local comparison. List which locations are accepted for each field: path, query, JSON, form, or multipart. Do not infer framework-wide behavior from a single handler.
2. **Compare duplicate parameters.** Submit the original scalar, the alternative scalar, then the two values together in each order. Follow the value through validation and consumption. First-value, last-value, list or rejection behavior is not a vulnerability alone. A finding needs a security decision on O1 followed by an operation on O2, or another demonstrated rule violation. Test one observed parameter rather than fuzzing every field. [WSTG parameter pollution](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution).
3. **Preserve duplicate JSON names.** Construct raw JSON bytes instead of a language dictionary, which may discard duplicates before sending. Compare a valid string, a repeated name, and a schema-invalid type such as a two-element array when a scalar is required. Record whether the gateway validates the first occurrence while the application consumes the last. RFC 8259 recommends unique object names and describes divergent receiver behavior; it does not make every accepted duplicate a vulnerability. Avoid asserting that all compliant parsers must reject them. [RFC 8259, section 4](https://www.rfc-editor.org/rfc/rfc8259.html#section-4).
4. **Check location and normalization precedence.** Where the real endpoint accepts more than one representation, compare a query field against the same JSON/form field and a path ID against a body ID. In separate trials, inspect one relevant percent-decoding or Unicode-normalization difference. Only send supported content types; prove which route and middleware ran. A different error response or equivalent spelling alone is not an authorization bypass.
5. **Inspect server-created requests.** A single external scalar may be interpolated into an internal query string or path. In a local service stub, use a marker such as `BB01&bb_probe=BB02` as the complete outer value and inspect whether it remains one downstream value or becomes an added parameter. Encode it for the outer request exactly once. If a delimiter appears downstream, use only source-confirmed synthetic fields to establish a changed policy decision; do not guess internal administrative operations. Contrast correct URL-builder encoding with string concatenation. [Server-side parameter pollution](https://portswigger.net/web-security/api-testing/server-side-parameter-pollution).
6. **Confirm the boundary.** Replay the minimal case through the normal ingress path and compare the strict-schema/consistent-parser negative control. Save the values each layer used and A's resulting access to the controlled O2 marker. Separate a reachable production path from a test harness configured with deliberately contradictory parsers. Remove both fixtures.

### Command card: duplicate-preserving local requests

Assume an observed local `/api/object-preview` endpoint accepts scalar `object`, with test identities in `A.header`. Configure O1 as A-readable and O2 as B-only. The route names are placeholders, not discovered endpoints. This makes four ordinary, sequential requests without redirect following or inherited proxies.

```bash
mkdir -p evidence/parameters
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -o evidence/parameters/allowed.txt \
  'http://127.0.0.1:8000/api/object-preview?object=O1'
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -o evidence/parameters/denied.txt \
  'http://127.0.0.1:8000/api/object-preview?object=O2'
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -o evidence/parameters/forward.txt \
  'http://127.0.0.1:8000/api/object-preview?object=O1&object=O2'
curl -q --noproxy '*' --max-time 10 --header @A.header \
  -o evidence/parameters/reverse.txt \
  'http://127.0.0.1:8000/api/object-preview?object=O2&object=O1'
```

For a JSON variation, preserve the literal repeated-name body in a file and use `--data-binary @file` with the correct content type; do not reconstruct it using a dictionary or UI form. [curl data handling](https://curl.se/docs/manpage.html).

### Report threshold and checklist

The report must identify the disagreeing components, raw ambiguous input, protected value checked, different value consumed, and controlled impact. A gateway-only rejection, intentional multivalue API, simple parser preference, or a client that changed the payload is insufficient. Use CWE-436 for an established interpretation conflict; add the specific resulting access or injection weakness where supported.

- [ ] Allowed and forbidden single-value controls recorded.
- [ ] Raw duplicates survived the test client.
- [ ] Parsed types, precedence and downstream construction recorded.
- [ ] Exact authorization/consumption mismatch demonstrated.
- [ ] Fixed-parser or fixed-encoding negative control compared.


## Vulnerability reverse references

- [Parameter or JSON parser disagreement crosses a security check](#page-vulnerabilities-request-parser-value-conflict) — Validation or authorization uses one interpretation of a request value while the protected operation uses another.
- [Server-side parameter pollution in a constructed request](#page-vulnerabilities-downstream-parameter-injection) — An outer input injects or alters parameters in a server-created downstream request.


---

<a id="page-modules-webhook-event-integrity"></a>

# Webhooks and integration events: authenticity, tenant binding and replay

Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.

## Investigation sequence

1. Capture genuine event
2. Verify signed bytes
3. Bind provider and tenant
4. Check replay and order
5. Inspect durable effect
6. Revoke and clean up

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

### Setup and invariant

Treat an integration event as a separate privileged entry point. Inventory the subscription, receiving route, signing/authentication scheme, provider account, installation, tenant mapping, accepted event types, queue and final consumer. Use a local replica, a provider sandbox or local provider stub, two controlled tenants, and a reversible nonfinancial action. The invariant is: **only an authentic, correctly bound event may cause its permitted effect, once under the workflow's rules**.

Keep inbound event authenticity separate from [outbound destination checks](#page-modules-ssrf-boundary) and [object authorization](#page-modules-authz-matrix). A valid signature does not itself identify which local tenant may be changed.

### Numbered test procedure

1. **Capture a genuine baseline.** Generate one ordinary event through the controlled integration. Save exact body bytes, verification headers, event/object IDs, provider account and mode, local tenant, queue ID and final state. Write down the expected change, such as granting one sandbox entitlement. Capture a correctly signed irrelevant event as a no-effect control. An HTTP `2xx` can acknowledge receipt before the worker runs.
2. **Test authenticity before side effects.** In the replica, compare the baseline with a missing signature, an invalid signature, and a one-byte body change retaining the original signature. Restore the local object, queue and deduplication fixture between authenticity trials: an already-consumed event can conceal a missing verifier. Follow both receiver and worker logs; rejection after a privileged item was accepted is too late. Respect the actual verification scheme. GitHub's documented HMAC covers payload bytes, so JSON reserialization changes the signed bytes; separately supplied event/delivery headers are not automatically covered. Prefer the official verifier and confirm failures stop processing. [GitHub verification](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries).
3. **Bind provider identity to the local object.** Use valid sandbox events from two controlled provider accounts/installations. Verify each maps through trusted configuration to its correct tenant and provider object. For a local mutation experiment, change one untrusted routing field or unsigned header; a signed-field mutation requires an appropriately signed stub event and is a source-test hypothesis until its real attacker path is established. Check test/live mode and disconnected integrations. Do not claim a production forgery merely because the tester controls the lab signing key.
4. **Separate freshness, duplicates and order.** Replay one valid event once and inspect durable effects. If the provider signs a timestamp, check the documented acceptance window using a local clock/fixture. A fresh signature is not a deduplication guarantee. Deliver two distinct legitimate events in reverse order in the sandbox and verify that an old update cannot undo a later revocation. Stripe documents duplicate delivery and does not guarantee event order; event creation seconds are not a safe total ordering or deduplication key. Use event identity and the product's object-state rules. [Stripe webhook delivery behavior](https://docs.stripe.com/webhooks).
5. **Check dispatch and lifecycle.** Compare the allowed event type/action with a genuine unsupported type and malformed-but-authentic local fixture. Ensure a loosely selected handler does not treat every event as success. Rotate a sandbox signing secret, record the intentional overlap, then check the old secret after that overlap ends. Remove the integration and test the documented handling of already queued events. GitHub recommends checking event type/action and keeps the delivery ID unchanged on redelivery. Treat any deduplication based on an unsigned header according to the actual authenticated binding. [GitHub best practices](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks).
6. **Inspect the transaction boundary.** In the replica only, introduce one controlled worker failure before or after the effect, then retry. Check whether deduplication and the protected update can disagree, causing lost processing or duplicate effects. Use the existing [state/replay procedure](#page-modules-state-business-logic) for transactional controls. Restore fixtures, cancel queued test deliveries, and remove local capture files when evidence has been redacted.

### Command card: signed-body tamper control

Prepare `event-valid.json` and `event-valid.headers` from a newly generated local/sandbox delivery. The headers file contains only required verification and event metadata, not copied Host, Content-Length or production cookies. Prepare `event-tampered.json` by changing one known marker byte without re-signing. Start each authenticity case from the same clean local snapshot, including queue and deduplication state. Use a nonfinancial event and remain inside any signature freshness window.

```bash
mkdir -p evidence/webhooks
curl -q --noproxy '*' --max-time 10 \
  --header @event-valid.headers -H 'Content-Type: application/json' \
  --data-binary @event-valid.json \
  -D evidence/webhooks/valid.h -o evidence/webhooks/valid.txt \
  http://127.0.0.1:8000/webhooks/lab
# Inspect the valid effect, then restore the local fixture before this case.
curl -q --noproxy '*' --max-time 10 \
  --header @event-valid.headers -H 'Content-Type: application/json' \
  --data-binary @event-tampered.json \
  -D evidence/webhooks/tampered.h -o evidence/webhooks/tampered.txt \
  http://127.0.0.1:8000/webhooks/lab
```

For the separate replay experiment, restore once, send the valid request, wait for completion, and repeat it once without resetting. Inspect the durable effect count; two acknowledgements can correctly refer to one effect. The endpoint is illustrative. `--data-binary` preserves file bytes; these requests do not follow redirects. [curl manual](https://curl.se/docs/manpage.html).

### Report threshold and checklist

Report a forged protected transition, authentic event applied to the wrong controlled tenant, or replay/order failure with a durable security consequence. Acceptance of an intentionally unsigned public notification, permitted secret-rotation overlap, a harmless no-op acknowledgement, or a mock-only signing capability is not enough.

- [ ] Exact authenticated bytes and unsigned metadata distinguished.
- [ ] Provider identity, tenant, object and mode binding verified.
- [ ] Invalid/tampered controls caused no privileged worker effect.
- [ ] Freshness, duplicate delivery and order tested separately.
- [ ] Final state, retry behavior and cleanup recorded.


## Vulnerability reverse references

- [Workflow order or approval bypass](#page-vulnerabilities-workflow-order-validation-bypass) — An actor can complete a protected workflow without its required prior approval or immutable conditions.
- [Single-use action or idempotency replay failure](#page-vulnerabilities-single-use-idempotency-replay) — A replay creates another protected effect where the operation must be unique or idempotent.
- [Unverified or tampered webhook causes a protected effect](#page-vulnerabilities-webhook-event-authenticity-failure) — An event is processed with privileged consequences without establishing the required sender and content authenticity.
- [Authentic integration event applied to the wrong tenant or object](#page-vulnerabilities-webhook-provider-tenant-binding) — A valid provider event is misbound to a local tenant, installation, mode or resource the event is not authorized to modify.


---

<a id="page-modules-gitlab-pipeline-boundaries"></a>

# GitLab pipelines: contribution, job token and runner boundaries

Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.

## Investigation sequence

1. Pin version and pipeline context
2. Resolve included configuration
3. Map job and downstream authority
4. Compare one private fixture
5. Reset runner and artifacts

## Used in these playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Scope and fixture contract

Use an owned GitLab project pair and disposable runner, or owner-supplied configuration exports. Pin GitLab and Runner versions, feature flags, repository commit, pipeline ID, source project, target project and triggering user. Create a private synthetic artifact in project B and one job in A. **Control over A's contribution or job must not acquire B's private authority or a release identity beyond the stated integration.** Reuse [CI and release tracing](#page-modules-supply-chain-ci) for artifact provenance and [source data flow](#page-modules-source-dataflow) for executable input.

## 1. Establish which pipeline really runs

Trace merge-request source, configuration revision, execution project and trigger actor independently. Fork pipelines ordinarily run with fork resources. A parent member can run a fork merge-request pipeline in the parent context, using fork-controlled configuration with parent resources and that member's permissions. Inspect the exact settings and approval path. Protected variables and runners have additional requirements, including same-project protected branches; do not infer their exposure merely from parent execution. Re-running an older pipeline can retain its original context. [GitLab merge request pipelines](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/)

Build one row per job: who edits the YAML, who changes included files, which commit is fetched, which scripts execute, and what the resulting identity can do. Package installation, test discovery and generated scripts are executable inputs even when the visible job looks like a harmless test command.

## 2. Follow configuration and downstream trust

Resolve `include`, `extends`, component inputs, dynamic child configuration and multi-project triggers before judging a job. Capture the merged configuration through an owner-provided export. For remote includes, compare a pinned expected file with a changed inert fixture; supported `include:integrity` verifies a SHA-256 digest and rejects a mismatch. A mutable reference is a candidate until the lower-trust editor and privileged consumer are connected. [GitLab YAML reference](https://docs.gitlab.com/ci/yaml/)

Track forwarded variables and generated child YAML into the receiving pipeline. A downstream job may interpret a value as a shell command, artifact selector, deployment environment or cloud role. Compare the allowed value and one disallowed synthetic value at that exact sink. Preserve the downstream pipeline's own policy and actor, since upstream success does not establish downstream entitlement. [Downstream pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/)

## 3. Separate token restrictions from secret masking

A job token is limited by its API capabilities and the triggering user's authority. Review the receiving project's allowlist, feature visibility and any fine-grained restrictions together. Allowlisting a project does not independently grant its users new project permissions. Distinguish currently running jobs from expired-token attempts. Review repository-push settings for the deployed GitLab version rather than assuming every job token is permanently read only. [GitLab job tokens](https://docs.gitlab.com/ci/jobs/ci_job_token/)

Masked and hidden variables address exposure in interfaces; code already authorized to consume a variable can still misuse it. With a dummy value, identify the exact job receiving it, environment scope and later executable consumer. Never print real CI variables to inventory privileges. [GitLab CI variables](https://docs.gitlab.com/ci/variables/)

## 4. Reproduce one boundary using inert controls

| Candidate | Controlled comparison | Required evidence |
|---|---|---|
| Fork code enters parent authority | Trusted base versus inert fork fixture | Configuration SHA, execution project, actor and marker-only result |
| Job A reaches private project B | Allowed integration versus disallowed project/actor | Exact synthetic resource, token context and accepted/denied response |
| Runner leaks previous job state | Two owned jobs on a disposable runner | Known marker survives across a boundary that promises isolation |
| Publisher consumes wrong artifact | Expected producer versus wrong fixture run | Digest, selected run and actual trusted consumption |

For runners, inspect executor, host/socket mounts, shared working directories, cache policy and whether private images can be reused by unauthorized jobs. Use one predetermined synthetic marker path and one owned image. A shell executor or privileged container is a risk signal; the demonstrated issue is unintended cross-job access. Do not inspect other users' workspaces. [Runner isolation guidance](https://docs.gitlab.com/runner/security/)

## Local command cheat sheet

These searches read a local clone and execute no CI jobs. Follow results into referenced files; absence of a match is not coverage proof.

```bash
rg --files --hidden -g '!.git' -g '*gitlab*' -g '*.yml' -g '*.yaml' ./repo
rg -n --hidden -g '!.git' -g '*.yml' -g '*.yaml' \
  'include:|extends:|trigger:|forward:|id_tokens:|environment:' ./repo
rg -n --hidden -g '!.git' \
  'CI_JOB_TOKEN|CI_PIPELINE_SOURCE|CI_MERGE_REQUEST|privileged|pull_policy' ./repo
```

## Evidence and completion

- [ ] Pipeline project, configuration revision and triggering actor recorded separately.
- [ ] Parent/fork and protected-resource assumptions verified for the installed version.
- [ ] Included configuration, downstream inputs and executable consumers traced.
- [ ] Token capability, actor permission and receiving-project policy distinguished.
- [ ] Allowed and denied cases use the same private synthetic resource.
- [ ] Job logs contain no usable credentials; fixtures and runner state are removed.

A report should state the lowest actor that can initiate the chain, required maintainer interaction, exact acquired capability and secure comparison. Intended public artifacts, a rejected token, or deliberate shared runner trust do not establish a private boundary failure.

## Vulnerability reverse references

- [CI metadata interpreted as executable script](#page-vulnerabilities-ci-script-injection) — Pull-request titles, branch metadata, issue fields, or artifact values are inserted into a generated shell/program instead of being handled as data.
- [Untrusted contribution executed by privileged CI](#page-vulnerabilities-ci-untrusted-code-execution) — A trusted workflow fetches or loads contribution-controlled code, configuration, or dependencies and executes them with authority unavailable to the contributor.
- [CI artifact poisoning across a workflow trust boundary](#page-vulnerabilities-ci-artifact-poisoning) — A higher-trust workflow treats attacker-controlled test/build output as executable code or authoritative release input without adequate producer and content constraints.
- [GitLab job token crosses an unintended project boundary](#page-vulnerabilities-gitlab-job-token-boundary) — A contribution-controlled job acquires access to a private receiving-project resource beyond the CI integration contract.
- [Shared CI runner exposes private state across jobs](#page-vulnerabilities-ci-runner-cross-job-state) — A job reaches a previous job's private filesystem or image material despite the runner's promised isolation.


---

<a id="page-modules-azure-gcp-boundaries"></a>

# Azure and GCP: identity, delegation and storage access

Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

## Investigation sequence

1. Pin provider and auth mode
2. Map management and data grants
3. Trace delegated identity
4. Compare one canary
5. Record propagation and clean up

## Used in these playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss) · [Web & API](#page-web-api)

## Define the provider-specific authority graph

Keep the shared [IAM procedure](#page-modules-cloud-iam-boundaries), [storage procedure](#page-modules-storage-delivery) and [authorization matrix](#page-modules-authz-matrix). Add the provider's actual identity and permission system before transferring an AWS hypothesis. Use two owned principals, one allowed and one restricted, and one private canary per tenant. Record Azure tenant/subscription/resource IDs or GCP organization/project/resource names, selected CLI account and impersonation settings. **An application tenant must not select another tenant's cloud identity or access path.**

## Azure: distinguish management, data and delegation

1. **Classify the caller.** Record whether the application uses a user, service principal or managed identity. Map application tenant to that principal's object ID and allowed resource. Separate Microsoft Entra directory roles from Azure resource-role assignments. Inspect inherited assignments, groups, conditions and deny assignments using owner exports when visibility is incomplete.

2. **Trace the real blob authorization route.** A storage management role is not automatically a Blob data role when using Entra authentication. However, management permission to retrieve account keys can create a different data-access route if Shared Key is permitted. Preserve whether the request used Entra, Shared Key or a SAS; otherwise an apparent RBAC bypass may simply be a different credential. Test only the canary and reuse the identical auth mode for both controls. [Azure Blob authorization](https://learn.microsoft.com/en-us/azure/storage/blobs/authorize-access-azure-active-directory)

3. **Identify the SAS type.** Distinguish user delegation, service and account SAS. Record signed resource, allowed operations, validity interval and any stored-access-policy relationship before testing issuance. Ask tenant A for B's owned canary through the application, then verify only the issued capability's permitted synthetic operation. A correctly issued bearer SAS working after application logout is not automatically a flaw. Revocation mechanisms differ by SAS type; compare against the product's promise instead of assuming a uniform logout rule. [Azure SAS overview](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview)

## GCP: distinguish attachment, impersonation and storage grants

1. **Map service-account selection.** `iam.serviceAccounts.actAs` supports attaching an identity to an executable resource; it does not by itself grant general short-lived token creation. Token Creator permissions are a separate path. Inspect workload-create/update authority, selected service account and that account's actual resource access together. In a disposable fixture, compare one canary-only workload using the normal identity with the same supported operation using a more powerful owned identity. Do not create long-lived keys as a proof step. [Service-account permission model](https://docs.cloud.google.com/iam/docs/service-account-permissions)

2. **Resolve inherited and object-level access.** Record project/folder/organization grants and relevant restrictions. For Cloud Storage, determine whether uniform bucket-level access is enabled. When it is disabled, object ACLs can supply access independently of bucket IAM; when enabled, ACL operations are disabled. Compare the exact object and generation under the same account. A project policy export alone cannot establish every object-access path. [Uniform bucket-level access](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access)

3. **Inspect workload federation bindings.** Verify issuer, audience, attribute mapping, attribute condition and target-resource/service-account binding. For a shared CI identity issuer, bind trust to the intended organization/repository and environment using the provider's documented claim semantics. Compare legitimate allowed and disallowed identities in an owned fixture. A valid issuer signature establishes token origin, not entitlement to every configured workload pool. [Federation for deployment pipelines](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines)

## Bounded command card

These commands contact provider APIs. Run individually using prepared owned credentials. Supply approved literal IDs; inspect Azure storage environment variables and GCP impersonation configuration first. The Azure policy command avoids Microsoft Graph name lookups, but is still an authenticated management API request. It does not enumerate group membership or prove effective access. [Azure role-assignment CLI](https://learn.microsoft.com/en-us/cli/azure/role/assignment?view=azure-cli-latest)

```bash
timeout 20 az role assignment list \
  --subscription OWNED_SUBSCRIPTION_ID \
  --scope /subscriptions/OWNED_SUBSCRIPTION_ID/resourceGroups/bounty-fixture \
  --assignee-object-id OWNED_PRINCIPAL_OBJECT_ID \
  --include-inherited --fill-principal-name false -o json

env -u AZURE_STORAGE_KEY -u AZURE_STORAGE_SAS_TOKEN \
  -u AZURE_STORAGE_CONNECTION_STRING timeout 20 az storage blob show \
  --subscription OWNED_SUBSCRIPTION_ID --account-name OWNED_STORAGE_ACCOUNT \
  --container-name bounty-fixture --name canary.txt \
  --auth-mode login --only-show-errors -o json

timeout 20 gcloud --configuration=bounty-lab-low \
  storage objects describe gs://OWNED_BUCKET/bounty/canary.txt \
  --format=json
```

`--auth-mode login` prevents the Azure CLI's legacy key-lookup route from changing the identity argument. The last two commands request metadata of one known fixture. Repeat under the intended allowed identity; metadata access does not itself prove the file contents were disclosed. A timeout or absent object is not a permission denial. [Azure Blob CLI](https://learn.microsoft.com/en-us/cli/azure/storage/blob?view=azure-cli-latest), [GCP object describe](https://docs.cloud.google.com/sdk/gcloud/reference/storage/objects/describe)

## Report and cleanup checklist

- [ ] Provider, tenant/project, principal and selected authentication mode recorded.
- [ ] Management, data access and delegated workload authority separated.
- [ ] Inheritance, ACLs, conditions and visibility gaps documented.
- [ ] Allowed and denied controls address one identical synthetic resource.
- [ ] SAS/federation claims redacted; usable tokens excluded from evidence.
- [ ] Documented propagation delays considered before claiming revocation failure.
- [ ] Disposable workloads, object generations, temporary grants and shares cleaned up.

Preserve the precise failed edge and request IDs. A powerful administrator, intended delegation, stale session or deliberately public object must remain separate from an application tenant escaping its assigned authority.

## Vulnerability reverse references

- [Overbroad cloud role trust](#page-vulnerabilities-cloud-iam-role-trust) — A principal outside the integration's intended trust set can obtain an owned role's authority.
- [Excessive service-role delegation](#page-vulnerabilities-cloud-passrole-escalation) — A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.
- [Federated cloud role accepts the wrong workload identity](#page-vulnerabilities-cloud-oidc-subject-scope) — OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.
- [Anonymous access to private object storage](#page-vulnerabilities-cloud-storage-anonymous-read) — An unsigned request retrieves an object that the product promises to keep private.
- [Unauthorized object creation or replacement](#page-vulnerabilities-cloud-storage-unauthorized-write) — An unauthorized principal can create or replace an object in a protected storage location.
- [Signed storage capability exceeds its authorized scope](#page-vulnerabilities-cloud-presigned-capability-scope) — The application issues or accepts a storage capability for an object, operation or lifetime beyond the caller's entitlement.
- [Private delivery policy bypassed through the origin](#page-vulnerabilities-cloud-origin-access-bypass) — A private object is protected at the CDN or application edge but remains accessible directly at an owned origin.


---

<a id="page-modules-extension-message-boundaries"></a>

# Browser extensions: message authority and document lifetime

Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.

## Investigation sequence

1. Identify installed release
2. Map message channels
3. Capture allowed action
4. Change sender or document
5. Confirm recipient and effect
6. Restore profile

## Used in these playbooks

[Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Use the scoped store release, a disposable browser profile and two controlled local web origins. Record extension ID/version, browser version, Manifest version and granted optional permissions. Keep a separate unpacked copy for source tracing; changing its manifest, ID or permission grants changes the reproduction assumptions. Seed one private marker and one public marker in the extension's supported lab data. **Invariant: a page cannot borrow extension or native-host authority beyond the specific operation delegated to that page and document.**

## Procedure, controls and interpretation

1. **Separate the message channels.** Draw page → DOM event/content script → service worker → browser API/native host. Inventory `window.postMessage`, custom events, `runtime.onMessage`, external-message listeners and ports separately. An external-message allowlist does not control an ordinary content script forwarding page data. Use only the channel actually reachable from a normal page. Chrome documents that content scripts are a lower-trust context for extension messages. [Message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging), [external messaging configuration](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable).

2. **Capture a legitimate request.** Trigger one supported page action and record action name, input schema, browser-provided sender ID/origin, tab/frame/document and the protected operation. Distinguish browser-supplied metadata from fields named `origin`, `sender`, `tabId` or `trusted` inside the message body. A content-script sender ID identifying the extension does not establish that its forwarded page input was authorized. Keep sensitive values out of the page until its entitlement is established.

3. **Vary one authority dimension.** Compare the valid page with the second controlled origin, a child frame, an unsupported action and a different known synthetic resource. Invoke through the product's real page listener; do not paste privileged extension APIs into its developer console. For a fetch broker, compare the intended public fixture with the protected marker destination and inspect who receives the response. Chrome's network guidance specifically warns against letting an untrusted sender choose arbitrary fetch destinations. Reuse [browser trust](#page-modules-browser-trust) and [SSRF boundaries](#page-modules-ssrf-boundary) for URL normalization and redirect decisions. [Extension network requests](https://developer.chrome.com/docs/extensions/develop/concepts/network-requests).

4. **Test document lifetime.** Pause a local mock response, navigate the initiating tab to the second origin, then release the response. Observe whether the reply or permission decision follows the original document or merely a reused tab/frame. Include same-tab navigation and a child-frame case separately. Chrome exposes `documentId` and `origin` on message senders; those fields need browser-version-aware handling. The inference being tested is whether the product preserves the identity it authorized across an asynchronous gap. A dropped reply is a valid denied control. [MessageSender](https://developer.chrome.com/docs/extensions/reference/api/runtime#type-MessageSender), [document-specific tab messaging](https://developer.chrome.com/docs/extensions/reference/api/tabs#method-sendMessage).

5. **Restart and revoke.** Let the service worker stop naturally or stop it through the local debugging UI; repeat the denied case after restart. Separately revoke an optional permission through supported browser controls. Record whether trusted state, grants or pending replies are re-created safely. Service-worker global variables are not durable storage. A debugging session can alter worker lifetime, so repeat the minimum case with developer tools closed. [Service worker lifecycle](https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle).

6. **Confirm the capability.** Record the actual returned marker or reversible operation. For native messaging, continue with [desktop IPC](#page-modules-desktop-ipc); distinguish extension-to-user-process access from a demonstrated administrator boundary. Broad permissions, a public resource, or a rejected unknown action are not standalone findings.

## Local command sheet

These inspect an acquired lab copy without loading it or invoking browser APIs:

```bash
python3 -I -S -m json.tool ./extension/manifest.json
rg -n 'postMessage|addEventListener|onMessage|onConnect|externally_connectable' ./extension
rg -n 'sender\.|documentId|frameId|tabs\.(sendMessage|connect)|sendNativeMessage' ./extension
rg -n 'fetch\(|host_permissions|optional_host_permissions|storage\.(local|session)' ./extension
```

For each match, save an evidence row: initiating origin/document, message fields, trusted metadata, decision, receiving document and resulting capability. The source scan identifies routes to exercise; a match itself proves no reachability.

## Completion checklist

- [ ] Allowed and denied origins produce the expected baseline decisions.
- [ ] The candidate works through the shipped page/content-script entry.
- [ ] Body-supplied identities are distinguished from browser metadata.
- [ ] Navigation and restart results include their event order.
- [ ] Optional permission grants and user interaction are documented.
- [ ] Remove local page fixtures and restore the disposable profile after retaining redacted evidence.

## Vulnerability reverse references

- [Page message borrows unintended browser-extension authority](#page-vulnerabilities-extension-message-authority) — An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.
- [Delayed extension result reaches a different document](#page-vulnerabilities-extension-document-reply-confusion) — An asynchronous extension operation reuses stale tab/frame authority after navigation and exposes a protected result to another document.


---

<a id="page-modules-ai-state-lifecycle"></a>

# AI state: memory, resumed work, retries and private caches

Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.

## Investigation sequence

1. Seed owned state
2. Verify owner controls
3. Change principal or lifetime
4. Resume or retry once
5. Inspect committed effects
6. Clear fixtures

## Used in these playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Setup and security invariant

Use a local agent/backend with two owned principals A/B, a persistent test database, a deterministic mock model and a stub tool that only appends a marked event. Record agent/framework version, protocol version, connector identity and task contract. Keep budgets to one operation per case and at most two delivery attempts. **Invariant: stored context, delayed work and retries preserve the authorized principal, operation and permitted lifetime.** Use [tool approvals](#page-modules-ai-tool-trust) for initial consent, [RAG isolation](#page-modules-rag-tenant-isolation) for documents and [resource budgets](#page-modules-resource-budget-controls) for cost bounds.

## Operational procedure

1. **Inventory persistent objects.** List conversation, checkpoint, durable memory, task/job, result artifact and connector credential separately, with owner and authorized readers. Thread history and cross-thread memory can live in different stores; LangGraph explicitly distinguishes these persistence systems. Seed a random private B marker, absent from A's prompts and fixtures. Confirm both owners can read their own state and A cannot directly read B's. [LangGraph persistence](https://docs.langchain.com/oss/python/langgraph/persistence).

2. **Exercise state handles below the model.** Compare A's own conversation/checkpoint with a known B-owned handle using A's same authenticated request. Follow read, resume, export and delete independently; successful queue admission is not proof that work completed. Repeat a resume after removing membership and after switching the active account, observing the worker's effective principal. A scheduler's service account must not erase the narrower authority of the initiating job. Report a stored-object authorization defect independently of any prompt injection.

3. **Track memory provenance.** Store one explicitly approved harmless preference as a positive control. Introduce an alternate preference only through a lower-trust retrieved fixture. Start a fresh task and inspect whether that content was promoted into trusted instructions or another tenant's memory. Use a stub destination change as the protected effect. A legitimate user-approved memory or changed answer style is not evidence of unauthorized persistent control. Record the original source and each summary/handoff, then remove the memory and confirm the effect stops. This is a proposed experiment for the product's persistence contract, not a claim that every memory feature is vulnerable.

4. **Bind resumed MCP requests.** For implementations using 2026-07-28 MRTR, compare an untouched `requestState` with one altered local copy, a B-owned state under A, an expired state and the same state with changed action arguments. Observe a harmless protected result. The specification requires integrity checks where state affects authorization or business logic; it recommends principal, expiry and originating-request binding. Single-use effects require server-side enforcement beyond a protected token. These controls apply to the server, even though a conforming client treats the state as opaque. [MCP MRTR](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr).

5. **Disconnect at a defined point.** In the local adapter, commit one marked stub operation and simulate loss of its response, then retry once. Compare committed events with received responses. A fresh JSON-RPC ID identifies a request, not automatically a business-level idempotency key. Require at-most-once behavior only when the operation promises it; intentionally repeatable actions need a different invariant. Also cancel before commitment and verify the documented cancellation boundary. The HTTP protocol removes stream redelivery, so transport reconnect behavior must not be mistaken for proof of business deduplication. [MCP HTTP transport](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http).

6. **Compare private caches.** Warm a synthetic private resource as B, then request the same method/parameters as A. Compare cold and warm results and each authorization context. MCP private results cannot be shared across authorization contexts; MRTR retries carrying input/state are not cacheable. Record protocol hints and actual returned data, since hints alone do not enforce object access. An identical public tool list is expected. [MCP caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching).

## Bounded command and ledger sheet

```bash
rg -n 'thread_id|checkpoint_id|requestState|inputResponses|cacheScope|idempotency' ./src
python3 -I -S - <<'PY'
import collections, json
events = collections.Counter()
with open('lab/state-events.jsonl') as stream:
    for number, line in enumerate(stream):
        if number >= 1000:
            raise SystemExit('Fixture exceeds 1000 event review limit')
        row = json.loads(line)
        if row.get('committed'):
            events[(row['case'], row['principal'], row['operation_id'])] += 1
for key, count in sorted(events.items()):
    print(*key, 'commits=', count)
PY
```

The ledger is your locally recorded fixture output, not a scanner result. Include `case`, `principal`, `operation_id`, `committed`, timestamp, authorization decision and state/argument digests. Never log usable credentials.

## Evidence and cleanup

- [ ] Owner, cross-owner, expired/revoked and valid-resume cases are recorded.
- [ ] Committed effects are counted independently of model text and responses.
- [ ] Memory source and receiving principal survive every transformation.
- [ ] Cold/warm cache evidence identifies the actual reader.
- [ ] Restore the test database, delete canaries/checkpoints and revoke fixture credentials.

## Vulnerability reverse references

- [Agent conversation, checkpoint or memory crosses ownership boundaries](#page-vulnerabilities-ai-persistent-state-ownership) — Persisted agent state or its resume/export path is accessible or mutable by a principal outside its intended owner or sharing grant.
- [MCP resumed state changes authorization or request meaning](#page-vulnerabilities-mcp-resume-state-integrity) — An MRTR server trusts modified or context-mismatched requestState when it affects a protected resumed operation.
- [Private MCP result is reused across authorization contexts](#page-vulnerabilities-mcp-private-cache-context) — A shared cache delivers caller-specific protocol data outside the authorization context that produced it.
- [Agent retry commits a protected single-use action twice](#page-vulnerabilities-agent-retry-duplicate-effect) — A response-loss or resume path duplicates an operation whose application contract requires at-most-once effect.


---

<a id="page-modules-resource-budget-controls"></a>

# Resource budgets and sensitive business flows

Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.

## Investigation sequence

1. Name the protected resource
2. Prepare recording stubs
3. Establish limit controls
4. Vary one budget dimension
5. Count committed work
6. Restore and retest

## Used in these playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Identify the unit that must be bounded

An HTTP request can fan out into database queries, recipient notifications, reservations, image conversions, token generation, or recurring background work. Name the scarce resource and the authority that should own its budget: actor, tenant, recipient, workflow, or global service. A request-per-second limit does not necessarily constrain those downstream units. OWASP distinguishes unrestricted resource consumption from excessive use of sensitive business workflows; both need a concrete product-specific impact. [API4](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/), [API6](https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/).

Build a small cost map before a test. For each entry point record accepted input size, batch cardinality, query/page complexity, queued jobs, retries, output size, and billed provider calls. Include failed requests: validation after a notification or job enqueue can return an error after consuming the protected resource. Use the [state and business logic module](#page-modules-state-business-logic) for one-time transitions and the [API protocol module](#page-modules-api-protocols) for per-operation behavior.

## Controlled procedure

1. **State the business rule.** Specify the prohibited outcome, such as more than two notifications to one synthetic recipient per lab window, or a member reserving an object after their allocation is exhausted. A missing CAPTCHA or rate-limit header alone is not the outcome.
2. **Prepare a faithful local deployment.** Replace email, SMS, payments and model providers with recording stubs. Use supported configuration to reduce a real limit to a small lab value when possible. Record the configuration difference. Do not introduce a new guard or a fabricated endpoint and claim it represents the original application.
3. **Establish accepted and rejected controls.** Exercise a permitted request and one documented over-limit case. Inspect actual downstream events and final state alongside the response. If the protected limit does not exist, bound the observation through source analysis and an isolated fixture; do not seek a production outage.
4. **Change one dimension.** Compare a single operation with a small batch; the same actor through two permitted entry points; an original event with a duplicate; or a queued operation before and after its reservation expires. Keep the recipient, tenant, and resource ownership under your control. Test concurrency only when required to distinguish a non-atomic counter, using a local two-worker harness.
5. **Measure work and isolation.** Record request count, accepted operation count, provider-stub count, bytes, task retries, and the budget's key. Check whether tenant A can consume tenant B's allocation or cause B's valid request to be rejected. A shared quota can be intentional; use the stated product rule.
6. **Reset and minimize.** Cancel pending jobs, release synthetic reservations, clear only the dedicated fixture's state, and replay the smallest sequence. Recheck that a legitimate operation still works after the counter expires or allocation is restored.

## Local command card

The following is an adaptable request recipe, not a runnable application. Prepare `lab/baseline.json`, `lab/at-limit.json`, and `lab/over-limit.json` using the product's real request schema; create a header file with a synthetic lab token. Replace `/api/exports` with the reviewed local endpoint. Confirm the application uses recording stubs and that all three cases fit the agreed tiny experiment before running it.

```bash
mkdir -p evidence
for lab_case in baseline at-limit over-limit; do
  curl -q --noproxy '*' --proto '=http' \
    --connect-timeout 2 --max-time 10 --max-filesize 65536 \
    --request POST --header @lab/authorization.header \
    --header 'Content-Type: application/json' \
    --data-binary "@lab/${lab_case}.json" \
    --dump-header "evidence/${lab_case}.headers" \
    --output "evidence/${lab_case}.body" \
    'http://127.0.0.1:8000/api/exports' || break
done
```

This sends at most three sequential requests and does not follow redirects. It does not reset state, enforce the server's budget, or prove a limit. Capture the application's worker and stub logs separately. A transport failure stops the loop and must be recorded as blocked; HTTP error responses remain available for interpretation. If each case requires a fresh counter, restore the fixture between cases instead of running the loop as written. [curl options](https://curl.se/docs/manpage.html).

## Evidence, false positives, and completion

Keep the expected budget, configuration, identities, input sequence, counter key, downstream effects, and valid control together. Demonstrated local resource amplification may support an impact argument; projected production cost remains an extrapolation until deployment and pricing assumptions are established. A few accepted requests below an unknown threshold do not prove unlimited access. A slow response is not proof of denial of service, and standard product automation may be intended.

- [ ] The protected resource or business allocation and intended owner are explicit.
- [ ] Real integrations are stubbed; no uninvolved recipient, customer, or bill is affected.
- [ ] The accepted control and over-limit control use the same relevant configuration.
- [ ] Downstream work is counted even when the HTTP response indicates rejection.
- [ ] Batch size, retries, async processing, and identity/tenant budget keys are considered.
- [ ] The minimal observation and any cost extrapolation are clearly separated.
- [ ] Pending work and fixture state are restored, with a legitimate operation retested.


## Vulnerability reverse references

- [Unbounded resource allocation or request amplification](#page-vulnerabilities-resource-allocation-limit-failure) — An operation consumes an unconstrained protected resource through input size, fan-out, queued work, output size or retries.
- [Sensitive business flow exceeds its permitted frequency or allocation](#page-vulnerabilities-sensitive-flow-frequency-limit) — An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.


---

<a id="page-vulnerabilities-bola-controlled-object-access"></a>

# Broken object-level authorization (BOLA / IDOR)

An actor can access another owner’s protected object by supplying its identifier.

**Candidate CWE:** [CWE-639](https://cwe.mitre.org/data/definitions/639.html)

## Test hypothesis

Create private O1 as A and O2 as B. Replay the O1 request with B’s credentials, retaining method and body; confirm B’s own O2 request succeeds. Test known child/export identifiers separately.

## Evidence required

A’s unique marker is returned to B, or A independently observes B’s unauthorized change. Preserve object privacy, both identities, the exact changed header or identifier, and cleanup.

## Rule out false positives

A UUID appearing in a response, a public object, intentional sharing, or HTTP 200 without protected data is not BOLA.

## Playbook and command references

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger access control](https://portswigger.net/web-security/access-control)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-bfla-restricted-function"></a>

# Broken function-level authorization (BFLA)

A lower-privilege actor invokes a function reserved for another role.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Record a documented owner-only reversible action on a disposable object. Replay it as the controlled viewer. Compare owner success, viewer denial on the normal route, and the observed alternate route.

## Evidence required

The restricted operation commits under the viewer identity. Include role definitions, actor tokens redacted, request sequence, and owner-side state verification. Select CWE-862 if the required function-level check is absent; select CWE-863 if a check exists but makes the wrong authorization decision.

## Rule out false positives

A hidden menu, reachable administrator HTML shell, or function explicitly available to members does not establish privilege escalation.

## Playbook and command references

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger access control](https://portswigger.net/web-security/access-control)
- [MITRE CWE-862](https://cwe.mitre.org/data/definitions/862.html)
- [MITRE CWE-863](https://cwe.mitre.org/data/definitions/863.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-bopla-private-response-property"></a>

# Broken property authorization: private response fields

An otherwise permitted object response includes fields the actor is not entitled to read.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use a controlled object visible to both actors but containing one owner-only synthetic field. Compare owner and viewer responses, including nested API or GraphQL fields and export serializers.

## Evidence required

The viewer receives the private marker from a protected property despite a documented field-level rule. Save the smallest response fragment proving disclosure. Classify an omitted field-level decision as CWE-862, or an implemented but incorrect decision as CWE-863. Confidentiality loss is the impact, not a reason to add CWE-200.

## Rule out false positives

The UI hiding a field, normal public profile metadata, and intentionally shared properties do not establish a read-side permission boundary.

## Playbook and command references

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger access control](https://portswigger.net/web-security/access-control)
- [MITRE CWE-862](https://cwe.mitre.org/data/definitions/862.html)
- [MITRE CWE-863](https://cwe.mitre.org/data/definitions/863.html)
- [MITRE CWE-200](https://cwe.mitre.org/data/definitions/200.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mass-assignment-protected-property"></a>

# Mass assignment of server-controlled properties

Automatic request binding lets a user modify a property that should be set only by trusted server logic.

**Candidate CWE:** [CWE-915](https://cwe.mitre.org/data/definitions/915.html)

## Test hypothesis

In a disposable tenant, capture a permitted profile edit. Add one source/schema-confirmed protected field. Read back persisted state and check one corresponding restricted action, then restore it.

## Evidence required

The protected field is stored and changes authorization, ownership, verification, or another stated security invariant. Include the binding path when source is available.

## Rule out false positives

An echoed JSON field that is ignored, freely editable metadata, or a schema accepting arbitrary nonsecurity properties is insufficient.

## Playbook and command references

- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP mass assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-authentication-incomplete-state-bypass"></a>

# Authentication or MFA state bypass

A session that has not completed required authentication can perform protected operations.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

Stop a controlled login before MFA or verification completion. Make one private profile request using its intermediate credential. Compare with a completed session and an anonymous request.

## Evidence required

Protected controlled data or an action is available without the required step. Record actual authentication state, route, credential source, and resulting identity.

## Rule out false positives

Issuing an intermediate token, showing a login shell, or allowing explicitly public profile data is not a bypass.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-session-fixation-login-binding"></a>

# Session fixation across login

A session known to an attacker remains usable after another controlled user authenticates into it.

**Candidate CWE:** [CWE-384](https://cwe.mitre.org/data/definitions/384.html)

## Test hypothesis

In the local replica, obtain an anonymous session and establish a realistic way to place it in B’s browser. After B logs in, replay the original session from A’s separate client.

## Evidence required

A’s client gains B’s authenticated identity using the previously known identifier. Document the delivery precondition and whether the server rotates or rebinds the credential.

## Rule out false positives

An unchanged analytics cookie or session name, or no feasible method to fix the victim’s session, does not prove account access.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1550.004 · Use Alternate Authentication Material: Web Session Cookie](#page-attack) — **Only if:** A session cookie acquired across a security boundary is accepted in another controlled client to access the represented user's protected session. **Not established by:** A missing cookie flag, reflected cookie name, or untested assumption about MFA bypass is insufficient. Ordinary cookie-based login does not demonstrate compromise.

## Primary references

- [OWASP session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-session-revocation-residual-access"></a>

# Residual access after explicit session revocation

A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.

**Candidate CWE:** [CWE-613](https://cwe.mitre.org/data/definitions/613.html)

## Test hypothesis

Save a valid controlled session, confirm one private read, perform explicit device/session revocation, then replay that read. Test refresh credentials and existing streams independently.

## Evidence required

The old credential still produces protected data or actions after the documented revocation point. Include timestamps, expected behavior, session type, and exact retained permission.

## Rule out false positives

Browser-only logout, a public cache, documented short-lived access-token behavior, or offline UI data requires separate interpretation.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1550.004 · Use Alternate Authentication Material: Web Session Cookie](#page-attack) — **Only if:** A session cookie acquired across a security boundary is accepted in another controlled client to access the represented user's protected session. **Not established by:** A missing cookie flag, reflected cookie name, or untested assumption about MFA bypass is insufficient. Ordinary cookie-based login does not demonstrate compromise.

## Primary references

- [OWASP session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-password-reset-account-binding"></a>

# Password reset binding or single-use failure

Recovery proof can change the wrong account or be reused contrary to the recovery contract.

**Candidate CWE:** [CWE-640](https://cwe.mitre.org/data/definitions/640.html)

## Test hypothesis

Request recovery for two controlled inboxes. In the replica, change only the client-controlled account selector when submitting A’s proof. Separately replay a consumed proof once after a successful reset.

## Evidence required

A fresh login verifies the wrong controlled account changed, or a consumed proof changes a credential again. Record issuance, intended subject, consumption time, and result without publishing the proof.

## Rule out false positives

A reset form remaining visible, a generic success page, and repeated submission that makes no credential change are not sufficient.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP forgot password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-oauth-login-account-linking-confusion"></a>

# OAuth login or account-linking confusion

An authorization response or external identity is bound to the wrong application session or controlled account.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html) · [CWE-352](https://cwe.mitre.org/data/definitions/352.html)

## Test hypothesis

Use separate A/B browser profiles and a test IdP. Capture a normal linking flow, then submit A’s response into B’s pending transaction. Test code reuse and wrong PKCE verifier as separate controls.

## Evidence required

The application logs in or links the wrong controlled identity without required confirmation. Preserve issuer, client, subject, redirect, transaction binding, and the final linked identity.

## Rule out false positives

Missing state alone is inconclusive when valid alternative binding exists. A rejected mismatched response or public redirect does not prove takeover.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OAuth 2.0 security BCP](https://www.rfc-editor.org/rfc/rfc9700.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-jwt-signature-trust-failure"></a>

# JWT signature, issuer, audience, or token-purpose validation failure

A service accepts token claims without the required signature or trusted issuer/key validation.

**Candidate CWE:** [CWE-347](https://cwe.mitre.org/data/definitions/347.html) · [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

Compare the normal controlled token with one invalid signature. Separately use validly signed lab fixtures for a wrong issuer, audience, expiry or token purpose. Change one condition at a time; read the same harmless protected resource. Trace configured algorithm/key trust and purpose-specific validation when source is available.

## Evidence required

Show which invalid condition was accepted and the resulting synthetic identity/capability. Use CWE-347 for signature verification failures; select the actual authentication/trust weakness for semantic validation errors instead of labelling every JWT bug broken cryptography. Redact live credentials.

## Rule out false positives

Base64-decoding claims, accepting a valid token for its intended audience, or displaying untrusted claims without granting access is insufficient.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [RFC 8725 JWT Best Current Practices](https://www.rfc-editor.org/rfc/rfc8725.html)
- [OpenID Connect Core incorporating errata set 2](https://openid.net/specs/openid-connect-core-1_0.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-sql-query-structure-injection"></a>

# SQL injection

Input changes SQL query structure instead of remaining a bound value.

**Candidate CWE:** [CWE-89](https://cwe.mitre.org/data/definitions/89.html)

## Test hypothesis

On a local fixture containing only synthetic rows, identify the quoting context and compare true/false expressions that preserve the same selected record. Inspect query logs and repeat the original baseline.

## Evidence required

Paired inputs cause reproducible SQL-semantic changes or an instrumented trace shows attacker-controlled query structure with a security consequence. Keep the proof to synthetic data.

## Rule out false positives

A quote-triggered 500, WAF rejection, reflected payload, or unrelated response timing difference is only a lead.

## Playbook and command references

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger SQL injection](https://portswigger.net/web-security/sql-injection)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-nosql-operator-contract-bypass"></a>

# NoSQL operator or query injection

An unexpected object, operator, or expression crosses a NoSQL query boundary.

**Candidate CWE:** [CWE-943](https://cwe.mitre.org/data/definitions/943.html)

## Test hypothesis

Use a local string-only filter with one synthetic matching row. Compare a scalar with an operator object, then change its operand to a nonexistent marker. Inspect the resulting filter and tenant predicate.

## Evidence required

The crafted value changes prohibited query semantics or removes a security constraint. Show the expected input contract, resulting query, and controlled data/action impact.

## Rule out false positives

An API intentionally exposing a constrained query language, an operator accepted only as text, or validation errors is not automatically vulnerable.

## Playbook and command references

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger NoSQL injection](https://portswigger.net/web-security/nosql-injection)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-os-command-argument-boundary"></a>

# OS command injection

An untrusted parameter becomes shell command syntax rather than remaining a data argument.

**Candidate CWE:** [CWE-78](https://cwe.mitre.org/data/definitions/78.html)

## Test hypothesis

Trace an observed local worker into its subprocess sink. In the disposable replica, use a marker-only printf operation appropriate to that shell, comparing the literal and interpreted paths in process logs.

## Evidence required

The marker comes from shell-command interpretation at the identified sink, with a reproducible input path and attacker preconditions. If only options to the intended executable change, use the separate argument-injection card and CWE-88.

## Rule out false positives

Text reflection, a failed command, and a tool whose documented purpose permits that exact trusted operation are not proof of a boundary violation.

## Playbook and command references

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1190 · Exploit Public-Facing Application](#page-attack) — **Only if:** A demonstrated exploit of an Internet-facing service provides initial access to its host, system, or environment; explain the foothold and trust boundary. **Not established by:** Not a blanket label for every web/API weakness. A reflected parameter, scanner alert, or ordinary cross-account object read alone does not establish initial network/system access.
- [T1059.004 · Command and Scripting Interpreter: Unix Shell](#page-attack) — **Only if:** The demonstrated exploit invokes a Unix shell to execute commands; capture the shell invocation or equivalent process evidence in a controlled reproduction. **Not established by:** Calling an executable directly without a shell, template evaluation, and generic RCE are not automatically Unix Shell. Choose an interpreter only when supported by evidence.

## Primary references

- [PortSwigger command injection](https://portswigger.net/web-security/os-command-injection)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-server-template-expression-injection"></a>

# Server-side template injection (SSTI)

Lower-trust data becomes executable template source at a server-side renderer.

**Candidate CWE:** [CWE-1336](https://cwe.mitre.org/data/definitions/1336.html)

## Test hypothesis

At a source-confirmed local template sink, compare a literal marker with two arithmetic expressions producing distinct values. Read raw HTTP output before browser scripts execute and inspect the renderer call.

## Evidence required

Server-side evaluation violates the field’s text-only or sandbox contract. State the demonstrated capability; arithmetic supports expression evaluation and does not by itself prove OS execution.

## Rule out false positives

A supported template editor, client-side computation, one coincidental arithmetic result, or escaped expression text is insufficient.

## Playbook and command references

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [AI, agents & MCP](#page-ai) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1190 · Exploit Public-Facing Application](#page-attack) — **Only if:** A demonstrated exploit of an Internet-facing service provides initial access to its host, system, or environment; explain the foothold and trust boundary. **Not established by:** Not a blanket label for every web/API weakness. A reflected parameter, scanner alert, or ordinary cross-account object read alone does not establish initial network/system access.

## Primary references

- [PortSwigger template injection](https://portswigger.net/web-security/server-side-template-injection)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-xss-reflected-stored-origin-execution"></a>

# Reflected or stored cross-site scripting

Attacker-controlled input executes in another controlled user’s browser under the application origin.

**Candidate CWE:** [CWE-79](https://cwe.mitre.org/data/definitions/79.html)

## Test hypothesis

Locate the HTML, attribute, or script context with a text marker. In a private shared fixture, use a context-appropriate benign DOM-marker payload and verify execution from B’s normal viewing workflow.

## Evidence required

The affected origin executes the marker in B’s browser without manual DevTools execution. Preserve source input, delivery path, sink, browser context, and cleanup.

## Rule out false positives

Reflection without execution, self-XSS requiring console paste, execution only in an isolated untrusted origin, or CSP-blocked payloads do not prove the claimed impact.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1539 · Steal Web Session Cookie](#page-attack) — **Only if:** The tested weakness exposes an authentication session cookie across a boundary, for example from a controlled victim browser or improperly protected storage. **Not established by:** XSS alone does not prove cookie theft, especially when the relevant cookie is HttpOnly. Cookie acquisition and successful session replay are distinct evidence steps.

## Primary references

- [PortSwigger XSS](https://portswigger.net/web-security/cross-site-scripting)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-dom-xss-source-sink-flow"></a>

# DOM-based cross-site scripting

Browser-side code moves attacker-controlled data into an executable DOM or script sink.

**Candidate CWE:** [CWE-79](https://cwe.mitre.org/data/definitions/79.html)

## Test hypothesis

Trace an observed URL fragment, query, message, or stored value through client code. Use a benign marker and debugger breakpoints to identify the sink, then reproduce from a fresh browser navigation.

## Evidence required

A normal deliverable input causes marker execution at the application origin. Record the source-to-sink path and distinguish client transformation from reflected server output.

## Rule out false positives

A dangerous API name in source, unreachable code, sanitized DOM text, or a tester-modified runtime variable is not a complete exploit path.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger DOM XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-csrf-browser-forged-state-change"></a>

# Cross-site request forgery (CSRF)

A browser can be induced to perform a protected state change using ambient credentials.

**Candidate CWE:** [CWE-352](https://cwe.mitre.org/data/definitions/352.html)

## Test hypothesis

Capture a normal reversible setting change. Reproduce it from a controlled other site using browser-deliverable data, without inserting a victim bearer token. Compare an invalid proof and logged-out control.

## Evidence required

The actual browser sends required credentials and commits the unauthorized setting change. Save the initiating page, cookie behavior, request, and independent before/after state.

## Rule out false positives

A missing token, manual proxy replay, preflight-blocked JSON request, or request sent without the required cookies is not enough.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger CSRF](https://portswigger.net/web-security/csrf)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cors-private-credentialed-read"></a>

# CORS private-data exposure

A lower-trust origin can read a protected response using the controlled user’s browser credentials.

**Candidate CWE:** [CWE-942](https://cwe.mitre.org/data/definitions/942.html)

## Test hypothesis

From your researcher page, fetch a private controlled endpoint with credentials included and read the body. Compare the legitimate origin and anonymous response, recording preflight and cookie behavior.

## Evidence required

JavaScript on the researcher origin reads the private canary response. Header inspection supports the evidence but the real browser read establishes exploitability.

## Rule out false positives

Public data with wildcard CORS, wildcard plus credentials that browsers reject, a request without readable response, or header spoofing only in curl is insufficient.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger CORS](https://portswigger.net/web-security/cors)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-postmessage-origin-validation"></a>

# Cross-origin messaging trust failure

A message handler trusts an unauthorized sender or leaks protected data to an unintended origin.

**Candidate CWE:** [CWE-346](https://cwe.mitre.org/data/definitions/346.html)

## Test hypothesis

Observe a legitimate postMessage exchange in a local controlled application. From a researcher frame/window, send its expected shape and change only sender origin; use a harmless state marker.

## Evidence required

The unauthorized sender triggers a protected action or receives the controlled private marker. Include window/frame relationship, message schema, origin checks, and normal-delivery prerequisites.

## Rule out false positives

A wildcard target on non-sensitive messages, a handler with no reachable security-sensitive action, or console-only invocation is not a complete finding.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP HTML5 security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ssrf-forbidden-destination"></a>

# Server-side request forgery (SSRF)

A server-side fetch crosses the feature’s destination, network, or credential policy.

**Candidate CWE:** [CWE-918](https://cwe.mitre.org/data/definitions/918.html)

## Test hypothesis

Start with an ordinary controlled receiver. In the replica, compare a policy-permitted destination with an owner-designated prohibited canary, and separately test one controlled redirect between them.

## Evidence required

Correlated server/receiver logs show the prohibited request or synthetic authority transfer. State whether evidence proves DNS, HTTP connectivity, readable response, or credential forwarding.

## Rule out false positives

Intended public URL fetching, a callback from your own browser, or DNS resolution without HTTP access does not prove the broader claim.

## Playbook and command references

- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.005 · Unsecured Credentials: Cloud Instance Metadata API](#page-attack) — **Only if:** SSRF or local access reaches cloud instance metadata and demonstrates access to credential-bearing metadata; use isolated fixtures or explicitly permitted controlled identities. **Not established by:** An outbound callback, generic internal reachability, or harmless metadata document alone does not prove credential access. Do not infer a metadata-to-cloud takeover chain.

## Primary references

- [PortSwigger SSRF](https://portswigger.net/web-security/ssrf)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-unsafe-upload-interpretation"></a>

# Unsafe upload interpretation or placement

Uploaded content is handled in a security-sensitive context beyond its permitted file contract.

**Candidate CWE:** [CWE-434](https://cwe.mitre.org/data/definitions/434.html)

## Test hypothesis

Use a tiny supported baseline. Change filename, declared MIME, and harmless bytes independently in a replica; inspect storage path, processing, retrieval origin, and actual rendering from controlled B.

## Evidence required

Show unsafe interpretation, prohibited placement, or a consequential parser path. Record the exact lifecycle stage and avoid claiming code execution from file acceptance alone.

## Rule out false positives

An unusual extension accepted as inert download, safe isolated hosting, or a file rejected after asynchronous processing is not executable-upload proof.

## Playbook and command references

- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger file uploads](https://portswigger.net/web-security/file-upload)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-path-traversal-controlled-canary"></a>

# Path traversal outside an allowed root

A controlled path escapes the intended filesystem or object-key boundary.

**Candidate CWE:** [CWE-22](https://cwe.mitre.org/data/definitions/22.html)

## Test hypothesis

Place a harmless canary outside the local permitted root. Compare a normal in-root request, one relevant traversal path to the canary, and a nonexistent control while preserving raw request bytes.

## Evidence required

The outside marker is read or a disposable outside output is created. Include server-resolved path, normalization order, required privileges, and effective boundary.

## Rule out false positives

A reflected path, client-normalized request, error exposing a filename, or an intentionally accessible directory is not proof of traversal.

## Playbook and command references

- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger path traversal](https://portswigger.net/web-security/file-path-traversal)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-xxe-external-entity-resolution"></a>

# XML external entity injection (XXE)

An XML parser resolves untrusted external entities across an unintended file or network boundary.

**Candidate CWE:** [CWE-611](https://cwe.mitre.org/data/definitions/611.html)

## Test hypothesis

In a local XML fixture, compare a literal marker field with one external entity referencing your controlled HTTP canary. Correlate parser input and receiver log; avoid recursive entities and sensitive files.

## Evidence required

The external entity fetch occurs at the parser, or its controlled marker is returned in parsed output. Record whether the consequence is blind fetch or readable content.

## Rule out false positives

Accepting XML or DOCTYPE, a parser error, or a browser-side request without server entity resolution is insufficient.

## Playbook and command references

- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.
- [Server-side fetching and network trust boundaries](#page-modules-ssrf-boundary) — Separate an intended fetch from a request that reaches a prohibited destination, forwards authority, or exposes a protected response.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger XXE](https://portswigger.net/web-security/xxe)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-archive-extraction-path-escape"></a>

# Archive extraction path escape

An archive member is extracted outside its designated output directory.

**Candidate CWE:** [CWE-22](https://cwe.mitre.org/data/definitions/22.html)

## Test hypothesis

In a disposable local directory, build a tiny archive with one ordinary file and one ../canary member. Run the actual product extraction route and compare resolved output paths with a normal archive. Where the format supports links, inspect one separate link-to-canary case and any pre-existing extraction-directory link, using the real product route and a disposable destination.

## Evidence required

The product creates a harmless marker outside the authorized extraction root. Preserve archive metadata, destination configuration, extraction API, and resulting filesystem paths. Record runtime, extraction filter, final resolved link targets, and any partial output left after rejection.

## Rule out false positives

A malicious member name being listed or rejected, or a testing script deliberately extracting outside the root instead of the product, is not a product vulnerability.

## Playbook and command references

- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP file upload security](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)
- [Python tarfile extraction filters and limitations](https://docs.python.org/3/library/tarfile.html#extraction-filters)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-web-cache-poisoning-unkeyed-input"></a>

# Web cache poisoning

Unkeyed attacker-controlled input changes a representation later served from shared cache.

**Candidate CWE:** [CWE-349](https://cwe.mitre.org/data/definitions/349.html)

## Test hypothesis

Prove a dedicated cache namespace. Change one source-confirmed unkeyed input to a harmless marker; request the same key from controlled B without that input and compare a clean key.

## Evidence required

B receives the altered cached representation, supported by origin/cache logs and exact key behavior. Describe the demonstrated output impact and purge test entries.

## Rule out false positives

Reflected input on the initial request, an ignored query cache-buster, or caching isolated to the submitting user is not cross-client poisoning.

## Playbook and command references

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-web-cache-deception-private-response"></a>

# Web cache deception

A path/cache-policy discrepancy stores a private response for retrieval by another client.

**Candidate CWE:** [CWE-524](https://cwe.mitre.org/data/definitions/524.html)

## Test hypothesis

In an isolated local cache, place A’s private marker on a page. Compare its canonical route with one variant treated as static; request the variant as A and then anonymous B.

## Evidence required

B receives A’s marker because of cache behavior, while direct/fresh-key controls deny it. Save normalized routes, cache policy, and both client requests.

## Rule out false positives

A public share URL, application-level BOLA without caching, or the tester’s authenticated browser cache is not cache deception.

## Playbook and command references

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger cache deception](https://portswigger.net/web-security/web-cache-deception)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-http-request-boundary-desynchronization"></a>

# HTTP request smuggling / desynchronization

Two HTTP-processing components disagree about request boundaries or parsing.

**Candidate CWE:** [CWE-444](https://cwe.mitre.org/data/definitions/444.html)

## Test hypothesis

Use an isolated front-end/backend pool. Capture normal paired traffic, introduce one lab framing discrepancy, and compare each layer’s parsed request count and boundaries with rejection controls.

## Evidence required

Logs or byte traces demonstrate the mismatch and a controlled security consequence. Distinguish HTTP/1 framing from HTTP/2 translation; all follow-up requests must be yours.

## Rule out false positives

A timeout, 400/502, unsupported Transfer-Encoding, or a tool-normalized malformed request alone does not demonstrate desynchronization.

## Playbook and command references

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger request smuggling](https://portswigger.net/web-security/request-smuggling)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-race-condition-duplicate-transition"></a>

# Race condition in a security-sensitive transition

Concurrent operations violate a rule that holds when the same actions run serially.

**Candidate CWE:** [CWE-362](https://cwe.mitre.org/data/definitions/362.html)

## Test hypothesis

Use a fresh nonfinancial fixture. Complete a normal serial/replay control, reset it, then submit two bounded simultaneous operations. Inspect durable state after both requests and workers finish.

## Evidence required

A duplicate membership, resource, or synthetic state transition persists. Include the invariant, initial state, serial control, concurrency mechanism, and committed result.

## Rule out false positives

Two 200 responses, transient UI counters, expected retries, or no verified timing overlap do not prove or disprove a race.

## Playbook and command references

- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger race conditions](https://portswigger.net/web-security/race-conditions)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-workflow-order-validation-bypass"></a>

# Workflow order or approval bypass

An actor can complete a protected workflow without its required prior approval or immutable conditions.

**Candidate CWE:** [CWE-841](https://cwe.mitre.org/data/definitions/841.html)

## Test hypothesis

Write the normal transition table. On a fresh controlled object, send the observed completion request before approval or alter one field that must be frozen after approval. Compare a valid sequence. If state changes arrive as integration events, deliver two legitimate sandbox events in reverse order and check that an older event cannot restore a revoked privilege.

## Evidence required

The forbidden transition commits and changes a documented security/business outcome. Save state before and after, actor rights, exact sequence, and cleanup.

## Rule out false positives

Skipping optional UI pages, editable fields allowed by policy, and a success page without committed effect are not sufficient.

## Playbook and command references

- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger business logic](https://portswigger.net/web-security/logic-flaws)
- [Stripe webhook verification, ordering and duplicate handling](https://docs.stripe.com/webhooks)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-single-use-idempotency-replay"></a>

# Single-use action or idempotency replay failure

A replay creates another protected effect where the operation must be unique or idempotent.

**Candidate CWE:** [CWE-837](https://cwe.mitre.org/data/definitions/837.html)

## Test hypothesis

Complete a one-time operation on a disposable object, then replay it once serially. For a documented idempotency key, compare same-key/same-body and same-key/changed-body behavior using sandbox data. For an integration event, separately replay one genuine signed delivery and inspect the worker effect after acknowledgement.

## Evidence required

A second unauthorized durable effect occurs, or the key crosses actor/tenant scope to affect another controlled object. Include the uniqueness contract and independent state count.

## Rule out false positives

Returning the original success response, safely reusing an existing result, or an intentionally repeatable action is not a replay vulnerability.

## Playbook and command references

- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.
- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Web3 & protocols](#page-web3)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-837 unique action enforcement](https://cwe.mitre.org/data/definitions/837.html)
- [Stripe webhook verification, ordering and duplicate handling](https://docs.stripe.com/webhooks)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-graphql-resolver-field-authz"></a>

# GraphQL resolver or field authorization failure

A GraphQL path or protected field bypasses the permission enforced for the same object elsewhere.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use an observed query on controlled O1. Replay as B, request one protected field, and compare an observed node/nested route. Keep aliases to two items and avoid recursive complexity tests.

## Evidence required

The response contains forbidden controlled data or a committed mutation, even if another field returns an error. Include operation, variables, role, and relevant partial data.

## Rule out false positives

Introspection, public schema fields, HTTP 200 with only errors, or an intentionally accessible object is not an authorization finding.

## Playbook and command references

- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger GraphQL](https://portswigger.net/web-security/graphql)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-websocket-message-authorization"></a>

# WebSocket message or subscription authorization failure

A valid connection performs unauthorized per-message actions or receives a private subscription.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html)

## Test hypothesis

Capture the normal message protocol. Have controlled B subscribe to A’s known private room; A sends one marker. Separately revoke B from a shared room and inspect one subsequent message.

## Evidence required

B receives the unauthorized marker or performs a restricted action. Preserve handshake identity, subscription ID, message sequence, and applicable revocation semantics.

## Rule out false positives

A successful handshake, an ignored subscribe request, or public broadcast messages is not evidence of private channel access.

## Playbook and command references

- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP WebSocket security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cross-site-websocket-hijacking"></a>

# Cross-site WebSocket hijacking

A page on another origin opens an authenticated socket and reads or performs protected operations.

**Candidate CWE:** [CWE-346](https://cwe.mitre.org/data/definitions/346.html) · [CWE-352](https://cwe.mitre.org/data/definitions/352.html)

## Test hypothesis

From a controlled researcher page, open the observed socket using the actual browser session behavior. Send one harmless application-protocol message and compare a logged-out browser control.

## Evidence required

The other-origin page receives private controlled data or commits a protected action using ambient credentials. Record cookie policy, Origin, handshake, and message exchange.

## Rule out false positives

Arbitrary Origin accepted in a nonbrowser client, missing cookies, or a socket that permits only public data is insufficient.

## Playbook and command references

- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger cross-site WebSocket hijacking](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-hardcoded-credentials"></a>

# Hard-coded product credentials

A reusable credential is embedded in source, history, a release, or a default configuration. Distinguish a shared built-in credential from an accidentally committed deployment credential when assigning the weakness.

**Candidate CWE:** [CWE-798](https://cwe.mitre.org/data/definitions/798.html)

## Test hypothesis

Run `gitleaks git ./repo --redact=100 --report-format json --report-path ./evidence/secrets.json` against a local clone, then inspect surrounding code and supported setup. Check whether a shipped synthetic lab accepts the documented shared default. For a discovered real token, establish ownership and exposure from context; ask the owner to validate and rotate it rather than using it.

## Evidence required

Repository path and commit, first/last observed exposure, credential purpose, shipped/default use where proved, and a redacted fingerprint. Never attach the complete credential. Separate proven lab authentication from unknown validity of a deployment secret. Apply CWE-798 only where the credential is embedded in product authentication or outbound credential use. For accidental repository disclosure, use the separate exposed-repository-secret entry and classify the actual exposure root cause.

## Rule out false positives

Test keys, intentionally public identifiers, revoked values, example-only placeholders, and fixtures not shipped in the product. An entropy match alone is insufficient.

## Playbook and command references

- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [Gitleaks official documentation](https://github.com/gitleaks/gitleaks)
- [MITRE CWE-798](https://cwe.mitre.org/data/definitions/798.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ci-script-injection"></a>

# CI metadata interpreted as executable script

Pull-request titles, branch metadata, issue fields, or artifact values are inserted into a generated shell/program instead of being handled as data.

**Candidate CWE:** [CWE-94](https://cwe.mitre.org/data/definitions/94.html)

## Test hypothesis

Trace the exact expression from event payload to `run:` or generated script. Reproduce in a private fixture with dummy credentials and an inert marker; compare an environment-variable/data-argument implementation. Check subsequent `eval` or command construction even when the first transfer is safe.

## Evidence required

Attacker role, triggering event, workflow/action revision, generated script, marker-only result, job permissions, and comparison control. Claim only capabilities supported by the actual job context.

## Rule out false positives

A value remains a quoted data argument without later interpretation; attacker cannot supply that event field; or a privileged capability is assumed but absent.

## Playbook and command references

- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1059.004 · Command and Scripting Interpreter: Unix Shell](#page-attack) — **Only if:** The demonstrated exploit invokes a Unix shell to execute commands; capture the shell invocation or equivalent process evidence in a controlled reproduction. **Not established by:** Calling an executable directly without a shell, template evaluation, and generic RCE are not automatically Unix Shell. Choose an interpreter only when supported by evidence.
- [T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain](#page-attack) — **Only if:** A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab. **Not established by:** Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.

## Primary references

- [GitHub Actions secure use](https://docs.github.com/en/actions/reference/security/secure-use)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ci-untrusted-code-execution"></a>

# Untrusted contribution executed by privileged CI

A trusted workflow fetches or loads contribution-controlled code, configuration, or dependencies and executes them with authority unavailable to the contributor.

**Candidate CWE:** [CWE-829](https://cwe.mitre.org/data/definitions/829.html)

## Test hypothesis

Map event → exact fetched revision → executed Makefile/test/install hook → token or environment authority. Verify current checkout protections, explicit opt-outs, manual fetches, and approvals. Use an owned fixture and harmless output; a `pull_request_target` trigger alone does not prove this chain. For GitLab, record fork/source configuration, parent execution project and trigger actor separately; verify protected-resource restrictions for the installed version.

## Evidence required

Concrete low-trust contribution path, executable file, workflow and action SHA, relevant policy/defaults, dummy-token fixture results, and source-supported privilege scope. Separate confirmed settings from maintainer-only facts.

## Rule out false positives

Only trusted base code executes; fork material is inspected exclusively as data; current checkout protections block the path; or no intended trust boundary is crossed.

## Playbook and command references

- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1195.001 · Supply Chain Compromise: Compromise Software Dependencies and Development Tools](#page-attack) — **Only if:** A controlled reproduction shows maliciously modified dependency or development-tool content being consumed through a software supply chain, such as a substituted reusable build action. **Not established by:** An old vulnerable dependency, an SBOM finding, or arbitrary CI log access does not prove supply-chain compromise. Show the manipulated component and consumer path.
- [T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain](#page-attack) — **Only if:** A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab. **Not established by:** Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.

## Primary references

- [GitHub pull_request_target protections](https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target)
- [MITRE CWE-829](https://cwe.mitre.org/data/definitions/829.html)
- [GitLab merge request pipeline trust](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ci-artifact-poisoning"></a>

# CI artifact poisoning across a workflow trust boundary

A higher-trust workflow treats attacker-controlled test/build output as executable code or authoritative release input without adequate producer and content constraints.

**Candidate CWE:** [CWE-829](https://cwe.mitre.org/data/definitions/829.html)

## Test hypothesis

Follow artifact producer, run ID/repository association, selection criteria, extraction, and consumer. In an owned workflow pair, create a harmless marker artifact and observe whether the privileged consumer executes or publishes its controlled content. Also test that an artifact from the wrong run is rejected.

## Evidence required

Producer and consumer workflow revisions, artifact digest, selection rule, exact executed/packaged path, consumer identity, and rejected-control result. An attacker-created artifact alone does not prove a privileged consumer accepts it.

## Rule out false positives

Correct producer binding plus safe data-only parsing prevents the claimed effect; a generic artifact name is accompanied by strong run constraints; or the artifact never reaches an authoritative consumer.

## Playbook and command references

- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain](#page-attack) — **Only if:** A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab. **Not established by:** Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.

## Primary references

- [GitHub Security Lab: preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/)
- [MITRE CWE-829](https://cwe.mitre.org/data/definitions/829.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-dependency-confusion"></a>

# Dependency confusion and unintended package origin

Dependency resolution selects an attacker-controlled package origin where the build or application expects an organization-controlled package.

**Candidate CWE:** [CWE-829](https://cwe.mitre.org/data/definitions/829.html)

## Test hypothesis

Inspect resolver configuration, namespace ownership, lock/integrity handling, and fallback rules. Reproduce with two local registries and synthetic package names using the relevant package-manager version. Record origin selection and whether install/build/runtime code would consume it; do not register real missing package names.

## Evidence required

Exact dependency and resolver configuration, package-manager version, local registry logs, selected package origin/version/hash, and affected consumer/build context. Separate resolver behavior from unconfirmed public namespace control.

## Rule out false positives

Private index mapping, exclusive source constraints, verified hashes, or immutable resolution prevents the alternate package from being selected. A public package of the same name existing is not enough.

## Playbook and command references

- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1195.001 · Supply Chain Compromise: Compromise Software Dependencies and Development Tools](#page-attack) — **Only if:** A controlled reproduction shows maliciously modified dependency or development-tool content being consumed through a software supply chain, such as a substituted reusable build action. **Not established by:** An old vulnerable dependency, an SBOM finding, or arbitrary CI log access does not prove supply-chain compromise. Show the manipulated component and consumer path.

## Primary references

- [pip install: index selection](https://pip.pypa.io/en/stable/cli/pip_install/)
- [MITRE CWE-829](https://cwe.mitre.org/data/definitions/829.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-unsafe-deserialization"></a>

# Unsafe object deserialization

Untrusted bytes reach a format that can instantiate behavior-bearing objects or invoke code, such as Python pickle, without a sufficient trust boundary.

**Candidate CWE:** [CWE-502](https://cwe.mitre.org/data/definitions/502.html)

## Test hypothesis

Trace file/queue/cache/import input to the real loader, including integrity verification before loading. In an isolated synthetic lab, use a benign marker-only object demonstrating an unexpected callable or object type. Compare a valid normal object and a rejected untrusted object through the supported interface.

## Evidence required

Input origin, loader and options, signature/check placement, attacker role, complete reachable consumer path, and harmless observable behavior. For ML/model formats, distinguish plain numeric data from executable serialization features.

## Rule out false positives

Only trusted, integrity-verified inputs are accepted under the documented contract; a safe loader is used; or the claim bypasses the caller validation by invoking the loader directly.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai) · [Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1190 · Exploit Public-Facing Application](#page-attack) — **Only if:** A demonstrated exploit of an Internet-facing service provides initial access to its host, system, or environment; explain the foothold and trust boundary. **Not established by:** Not a blanket label for every web/API weakness. A reflected parameter, scanner alert, or ordinary cross-account object read alone does not establish initial network/system access.
- [T1203 · Exploitation for Client Execution](#page-attack) — **Only if:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process. **Not established by:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.

## Primary references

- [Python pickle security warning](https://docs.python.org/3/library/pickle.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-prototype-pollution"></a>

# JavaScript prototype pollution

An attacker-controlled property path changes inherited object state, which can affect unrelated objects and security-sensitive consumers.

**Candidate CWE:** [CWE-1321](https://cwe.mitre.org/data/definitions/1321.html)

## Test hypothesis

Trace recursive merge, object-path setter, or property assignment from a supported input. In an isolated fresh process, use a synthetic property and check inheritance on a newly created object. Then identify a concrete consumer whose behavior changes; compare own-property/schema validation and reset the process between attempts.

## Evidence required

Polluting path, input parser behavior, affected prototype/property, fresh-object observation, reachable consumer, and demonstrated consequence. Keep pollution primitive and downstream impact separate.

## Rule out false positives

A special key is merely an ordinary own property; null-prototype maps or key validation block prototype access; state change requires modifying the process yourself; or no supported attacker input reaches the setter.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP prototype pollution prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-out-of-bounds-read"></a>

# Out-of-bounds memory read

A parser or native consumer reads outside the valid extent of an object or buffer, potentially causing a crash or disclosure depending on how the result is used.

**Candidate CWE:** [CWE-125](https://cwe.mitre.org/data/definitions/125.html)

## Test hypothesis

Build the real parser with AddressSanitizer, provide realistic byte input through its public API, and minimize a reproducible failure. Verify lengths and object ownership in the harness. Check a supported consumer separately; prove returned adjacent synthetic data if claiming disclosure.

## Evidence required

Minimal input and hash, revision, compiler flags, symbolized read/allocation trace, relevant sizes, and supported API invocation. A crashing read does not by itself prove information disclosure.

## Rule out false positives

Harness passes an incorrect size or invalid pointer contrary to the API contract; fault occurs only in test scaffolding; or an ordinary bounds-checked error is mistaken for a memory access.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MITRE CWE-125](https://cwe.mitre.org/data/definitions/125.html)
- [Clang AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-out-of-bounds-write"></a>

# Out-of-bounds memory write

A native component writes beyond an allocated object because length, index, or allocation assumptions do not agree.

**Candidate CWE:** [CWE-787](https://cwe.mitre.org/data/definitions/787.html)

## Test hypothesis

Use an instrumented local harness with documented API ownership and realistic input. Minimize the failing bytes and trace the input-derived value into allocation and write. Retest the public consumer and a fixed build; demonstrate memory corruption without turning the PoC into a code-execution payload.

## Evidence required

ASan write trace, allocation extent, triggering values, source location, build flags, minimized input, and normal-input control. State exploitation constraints instead of equating every write overflow with RCE.

## Rule out false positives

The caller violates a required buffer-size contract, the harness underallocates its own output buffer, or the fault belongs to unsupported test-only code.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1203 · Exploitation for Client Execution](#page-attack) — **Only if:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process. **Not established by:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.
- [T1068 · Exploitation for Privilege Escalation](#page-attack) — **Only if:** A software vulnerability crosses a privilege boundary into a more privileged process or security context; record before/after identities and the vulnerable component. **Not established by:** Do not infer this from any feature named admin, a writable path alone, or a kernel version match. Application role authorization flaws need their own contextual analysis.

## Primary references

- [MITRE CWE-787](https://cwe.mitre.org/data/definitions/787.html)
- [Clang AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-use-after-free"></a>

# Use after free in a public API or parser lifecycle

Code uses an object after its lifetime has ended, often across callbacks, error handling, reference counting, or asynchronous operations.

**Candidate CWE:** [CWE-416](https://cwe.mitre.org/data/definitions/416.html)

## Test hypothesis

Model documented ownership for create/use/callback/release. Build a minimal valid call sequence that triggers the stale access under ASan. Reset state between cases; compare the same sequence on a fixed build and distinguish implementation lifetime failures from caller misuse.

## Evidence required

Creation, free, and use stack traces; minimized call sequence/input; object ownership contract; revision; and realistic consumer path. A crash supports the lifetime defect, while privilege or code-execution impact needs additional evidence.

## Rule out false positives

The caller deliberately calls an API after its documented destruction point, omits a required reference, or the harness incorrectly frees borrowed memory.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1203 · Exploitation for Client Execution](#page-attack) — **Only if:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process. **Not established by:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.
- [T1068 · Exploitation for Privilege Escalation](#page-attack) — **Only if:** A software vulnerability crosses a privilege boundary into a more privileged process or security context; record before/after identities and the vulnerable component. **Not established by:** Do not infer this from any feature named admin, a writable path alone, or a kernel version match. Application role authorization flaws need their own contextual analysis.

## Primary references

- [MITRE CWE-416](https://cwe.mitre.org/data/definitions/416.html)
- [Clang AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-integer-overflow"></a>

# Integer overflow affecting allocation or bounds

Input-derived arithmetic wraps or overflows so the checked size, allocation size, and later operation refer to different effective values.

**Candidate CWE:** [CWE-190](https://cwe.mitre.org/data/definitions/190.html)

## Test hypothesis

Trace counts/offsets through type conversions and arithmetic to the allocation/index consumer. Use boundary-sized logical values with small local fixtures. Apply UBSan and appropriate additional integer checks, remembering unsigned wrap is defined and outside the default undefined group.

## Evidence required

Input value, operand widths/signedness, operation, resulting allocation/index, sanitizer or traced consequence, and fixed checked-arithmetic control. Arithmetic behavior alone does not establish a security impact.

## Rule out false positives

Intentional modular arithmetic, later bounds checks, unreachable lengths due to validated format constraints, or an overflow warning with no unsafe consumer.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Clang UndefinedBehaviorSanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-parser-resource-exhaustion"></a>

# Parser resource exhaustion and decompression amplification

A small accepted input causes disproportionate CPU, memory, recursion, or expanded output consumption without effective limits at the relevant consumer.

**Candidate CWE:** [CWE-400](https://cwe.mitre.org/data/definitions/400.html)

## Test hypothesis

Measure a few progressively sized synthetic local inputs under fixed time/memory bounds, then stop once scaling and the missing limit are established. Compare a normal input and configured size/depth/expansion limits. Check whether the public consumer imposes effective limits before the library runs.

## Evidence required

Input sizes, repeatable time/RSS/output measurements, tool/build configuration, parser call path, and enforced versus missing bounds. Report local amplification and exposed workload; never infer service-wide denial from one slow call alone.

## Rule out false positives

Expected work on proportionately large input, a tight upstream limit, a lab configured without documented production bounds, or timeouts caused by unrelated I/O.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Dependencies: from advisory match to reachable impact](#page-modules-dependency-reachability) — Separate composition, advisory matching, runtime reachability, and exploit prerequisites so dependency reports describe product impact.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Network services](#page-network) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MITRE CWE-400](https://cwe.mitre.org/data/definitions/400.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-regex-dos"></a>

# Regular-expression denial of service

An attacker-controlled string makes the chosen regular-expression engine perform excessive backtracking or other disproportionate matching work.

**Candidate CWE:** [CWE-1333](https://cwe.mitre.org/data/definitions/1333.html)

## Test hypothesis

Identify engine/version, exact pattern, matching API, and reachable input length. Benchmark a small bounded progression of near-matching synthetic strings in an isolated process with a hard timeout. Compare the same lengths with normal strings and a safe pattern or engine configuration.

## Evidence required

Pattern, engine/version, accepted input path, lengths versus elapsed work, timeout ceiling, and consumer concurrency/limits where known. A dangerous-looking regex is a hypothesis until its real engine and input contract are checked.

## Rule out false positives

Engine guarantees bounded matching for this feature set; short upstream input limits defeat the claimed effect; or most time is spent outside the matcher.

## Playbook and command references

- [Libraries and parsers: bounded fuzzing to a minimal reproducer](#page-modules-parser-fuzzing) — Build a realistic local harness, instrument the target, bound fuzzing resources, and turn unique faults into defensible library or consumer reports.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MITRE CWE-1333](https://cwe.mitre.org/data/definitions/1333.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-insecure-temporary-files"></a>

# Predictable temporary files and unsafe creation

A component creates or reuses temporary files in a way that permits another local principal to precreate, replace, read, or redirect sensitive operations.

**Candidate CWE:** [CWE-377](https://cwe.mitre.org/data/definitions/377.html)

## Test hypothesis

In a local multi-user fixture, inspect path selection, creation atomicity, permissions, and link handling. Use an owned synthetic destination and a harmless marker to test precreation or replacement. Establish the attacker's directory permissions and the victim's actual privilege.

## Evidence required

Temporary path construction, creation flags/mode, distinct actor identities, directory permissions, protected synthetic effect, and safe exclusive-creation control. For races, preserve a repeatable bounded sequence and observed success count.

## Rule out false positives

Secure atomic creation in a private directory, restrictive file permissions, caller-owned paths with no privilege difference, or a hypothetical race with no attainable scheduling/permission conditions.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [Cloud & containers](#page-cloud) · [Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MITRE CWE-377](https://cwe.mitre.org/data/definitions/377.html)
- [Python tempfile API](https://docs.python.org/3/library/tempfile.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-untrusted-search-path"></a>

# Untrusted executable, library, or module search path

A program resolves an executable/library/module from an attacker-writable search location instead of the intended trusted component.

**Candidate CWE:** [CWE-427](https://cwe.mitre.org/data/definitions/427.html)

## Test hypothesis

Trace basename-based execution, dynamic loading, and plugin discovery with their actual PATH/module search rules. In a local fixture, place a harmless marker component in an attacker-writable candidate directory and observe which file resolves. Compare an absolute trusted path or constrained search configuration.

## Evidence required

Search order, directory ownership, attacker capability, selected file path/hash, invoking process identity, and marker-only observation. Explain the privilege boundary or trusted action influenced by the substituted component.

## Rule out false positives

Attacker already controls the same process/code; the directory is not writable to the proposed actor; the component is explicitly user-selected under the product contract; or trusted resolution precedes it.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [Hardware & firmware](#page-hardware) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1068 · Exploitation for Privilege Escalation](#page-attack) — **Only if:** A software vulnerability crosses a privilege boundary into a more privileged process or security context; record before/after identities and the vulnerable component. **Not established by:** Do not infer this from any feature named admin, a writable path alone, or a kernel version match. Application role authorization flaws need their own contextual analysis.

## Primary references

- [MITRE CWE-427](https://cwe.mitre.org/data/definitions/427.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-iam-role-trust"></a>

# Overbroad cloud role trust

A principal outside the integration's intended trust set can obtain an owned role's authority.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

In two owned accounts, compare the intended principal with a disallowed fixture principal against the same role and one canary metadata operation. Change only the relevant trust input or external-ID association; keep the role's data permissions constant.

## Evidence required

Caller IDs, role ARN, effective trust conditions, allowed/denied pair, resulting session identity and one canary operation with request ID.

## Rule out false positives

An intended cross-account administrator, a missing external ID without an applicable third-party deputy path, or an allow statement blocked by effective policy.

## Playbook and command references

- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1078.004 · Valid Accounts: Cloud Accounts](#page-attack) — **Only if:** A controlled reproduction uses compromised or misused valid cloud credentials/accounts to gain access or exceed the account's intended role; identify the specific observed goal. **Not established by:** The existence of a cloud account, a suspected leaked key, or authorized use of a researcher account is not enough. The official tactic list does not mean all four goals occurred.

## Primary references

- [AWS role trust for third-party access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)
- [AWS policy evaluation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-passrole-escalation"></a>

# Excessive service-role delegation

A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.

**Candidate CWE:** [CWE-266](https://cwe.mitre.org/data/definitions/266.html)

## Test hypothesis

In an isolated owned account, compare one disposable canary-only job using its intended role with the same job using the excessive role. Check service create/update permission, role trust and resource permissions together. On GCP, assess workload-create/update permission together with service-account attachment (actAs) and the selected account's resource grants; do not equate actAs with Token Creator.

## Evidence required

Starting identity, role selection, accepted service operation, generated job identity and synthetic metadata access that the starting identity cannot perform.

## Rule out false positives

PassRole permission without a usable service operation, incompatible role trust, or intended administrative delegation. PassRole has no standalone API audit event.

## Playbook and command references

- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [AWS PassRole requirements and audit behavior](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)
- [GCP service-account roles](https://docs.cloud.google.com/iam/docs/service-account-permissions)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-oidc-subject-scope"></a>

# Federated cloud role accepts the wrong workload identity

OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use the owned identity provider's normal token issuance to create allowed and disallowed fixture identities. Attempt the same role exchange and canary operation, changing one claim dimension at a time.

## Evidence required

Redacted issuer/audience/subject claims, trust policy, session role and allowed/denied control. Keep full tokens out of the report.

## Rule out false positives

A token merely decodes successfully, a wildcard covers only the intended trust set, or the provider rejects the exchange before any authority is obtained.

## Playbook and command references

- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1078.004 · Valid Accounts: Cloud Accounts](#page-attack) — **Only if:** A controlled reproduction uses compromised or misused valid cloud credentials/accounts to gain access or exceed the account's intended role; identify the specific observed goal. **Not established by:** The existence of a cloud account, a suspected leaked key, or authorized use of a researcher account is not enough. The official tactic list does not mean all four goals occurred.

## Primary references

- [AWS OIDC role federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-storage-anonymous-read"></a>

# Anonymous access to private object storage

An unsigned request retrieves an object that the product promises to keep private.

**Candidate CWE:** [CWE-732](https://cwe.mitre.org/data/definitions/732.html)

## Test hypothesis

Create a tiny private canary through the intended workflow; confirm its contents with the owner identity. Request only its exact key anonymously, with a bounded range, and compare the private policy configuration. On GCP, inspect whether object ACLs remain active or uniform bucket-level access applies; on Azure, identify whether the observed request uses Entra, Shared Key, SAS or anonymous access.

## Evidence required

Object owner and privacy setting, unsigned request, exact marker, account/bucket identity and the intended authenticated control.

## Rule out false positives

Public website assets, intentional shared objects, a login page returned with status 200, or a policy candidate overridden by effective controls.

## Playbook and command references

- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1530 · Data from Cloud Storage](#page-attack) — **Only if:** A demonstrated authorization or configuration failure permits collection of a controlled confidential object from an actual cloud storage service, including supported SaaS storage contexts. **Not established by:** A bucket name, public-by-design file, general BOLA, or any API response simply hosted in the cloud is insufficient. Establish the storage context and protected data boundary.

## Primary references

- [S3 public-access controls](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)
- [S3 GetObject CLI](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-object.html)
- [Azure Blob management and data permissions](https://learn.microsoft.com/en-us/azure/storage/blobs/authorize-access-azure-active-directory)
- [GCP uniform bucket-level access](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-storage-unauthorized-write"></a>

# Unauthorized object creation or replacement

An unauthorized principal can create or replace an object in a protected storage location.

**Candidate CWE:** [CWE-732](https://cwe.mitre.org/data/definitions/732.html)

## Test hypothesis

Reserve a disposable key with the owner, record its initial marker/version, then attempt one inert write as the disallowed fixture identity. Have the owner confirm the resulting bytes and clean up every fixture version.

## Evidence required

Protected prefix/key rule, writer identity, accepted write request, owner-confirmed marker/version and secure comparison.

## Rule out false positives

Intentionally anonymous uploads confined to a quarantine area, a returned upload URL that cannot write, or writing only to the caller's allowed prefix.

## Playbook and command references

- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [S3 public-access controls](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)
- [S3 signed upload/download behavior](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-presigned-capability-scope"></a>

# Signed storage capability exceeds its authorized scope

The application issues or accepts a storage capability for an object, operation or lifetime beyond the caller's entitlement.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Compare normal signing for A's fixture with signing for B's owned fixture. Separately compare the allowed method/key and the documented expiry case, changing one input at a time.

## Evidence required

A's identity, B's ownership, issuance request, capability scope, timestamps and successful canary operation. Redact the usable signature.

## Rule out false positives

A legitimately issued presigned URL works without the user's session, is reusable before expiry, or lasts within the explicitly documented sharing policy.

## Playbook and command references

- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1530 · Data from Cloud Storage](#page-attack) — **Only if:** A demonstrated authorization or configuration failure permits collection of a controlled confidential object from an actual cloud storage service, including supported SaaS storage contexts. **Not established by:** A bucket name, public-by-design file, general BOLA, or any API response simply hosted in the cloud is insufficient. Establish the storage context and protected data boundary.

## Primary references

- [S3 presigned URL semantics](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-cloud-origin-access-bypass"></a>

# Private delivery policy bypassed through the origin

A private object is protected at the CDN or application edge but remains accessible directly at an owned origin.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html)

## Test hypothesis

Use the same private fixture through the intended protected delivery path and a known owner-supplied origin URL. Compare unauthenticated behavior without changing the resource or following unreviewed redirects.

## Evidence required

Origin ownership, delivery policy, both requests and identical canary bytes retrieved through the unauthorized origin route.

## Rule out false positives

The origin intentionally serves public files, the CDN only supplies performance, or the responses are different resources or authentication pages.

## Playbook and command references

- [Object storage, signed URLs and delivery boundaries](#page-modules-storage-delivery) — Follow one private canary through upload, signing, CDN delivery and expiry without enumerating real objects.
- [Azure and GCP: identity, delegation and storage access](#page-modules-azure-gcp-boundaries) — Apply provider-specific controls for Azure management/data permissions and SAS, plus GCP service accounts, federation and object ACLs.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [Web & API](#page-web-api)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CloudFront restrictions for S3 origins](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-kube-secret-rbac-exposure"></a>

# Kubernetes Secret access exceeds tenant permissions

A restricted cluster principal can read a canary Secret outside its intended resource boundary.

**Candidate CWE:** [CWE-732](https://cwe.mitre.org/data/definitions/732.html)

## Test hypothesis

Query permission for the named Secret using the actual low-privilege context; if a read is allowed by the test scope, retrieve only the administrator-created canary and compare a correctly restricted identity.

## Evidence required

Context identity, namespace/name, effective RBAC grants, authorization result and only the synthetic marker. Avoid Secret lists and real credential content.

## Rule out false positives

Intended cluster administration, intentionally shared namespace secrets, or a permission query without the relevant complete resource/subresource context.

## Playbook and command references

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Kubernetes Secret security practices](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)
- [kubectl auth can-i](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-kube-workload-identity-selection"></a>

# Workload creation grants unintended service-account authority

An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.

**Candidate CWE:** [CWE-266](https://cwe.mitre.org/data/definitions/266.html)

## Test hypothesis

In the isolated fixture namespace, compare an inert job using its intended service account with the supported selection of a more powerful canary account. Check the admitted pod and one synthetic resource operation.

## Evidence required

Creator identity, submitted spec, admitted/generated workload, selected service account and canary result that the creator cannot obtain directly.

## Rule out false positives

Administrators intentionally allowed to choose all namespace identities, rejected admission, or a powerful-looking account with no effective additional rights.

## Playbook and command references

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.
- [Cloud IAM: trust, delegation and effective permissions](#page-modules-cloud-iam-boundaries) — Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Kubernetes service accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)
- [Kubernetes RBAC risks](https://kubernetes.io/docs/concepts/security/rbac-good-practices/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-kube-admission-policy-gap"></a>

# Admission policy misses a supported object or update path

A tenant can persist an object prohibited by the advertised admission policy through a missed operation, selector or subresource.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use a permitted manifest as the positive control. In a disposable cluster, compare a harmless policy-violating fixture on the normal create path and the equivalent supported alternate operation; inspect the final persisted object.

## Evidence required

Policy version and match rules, paired admission responses, caller identity and final object demonstrating the missed restriction.

## Rule out false positives

Warn/audit-only policies, intentional exceptions, dry-run rejection misread as persistence, or no demonstrated security effect beyond formatting differences.

## Playbook and command references

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Kubernetes admission webhook guidance](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-kube-network-isolation-failure"></a>

# Namespace or workload network restriction is ineffective

A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.

**Candidate CWE:** [CWE-923](https://cwe.mitre.org/data/definitions/923.html)

## Test hypothesis

Create one inert marker endpoint and two owned source pods. Compare one request from the allowed source and one from the denied source with the same destination and port; record labels, policy direction and CNI.

## Evidence required

Successful allowed control, disallowed-source marker response, source/destination identity and applicable policies plus enforcing implementation. CWE-923 is a candidate when the failed boundary permits communication with an unintended endpoint. Refine to the actual selector, permission-assignment, or enforcement mistake when supported; do not infer a particular implementation error from connectivity alone.

## Rule out false positives

A timeout while the service is broken, intentionally allowed egress, unsupported policy semantics, or a lab missing the production network plugin.

## Playbook and command references

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Kubernetes NetworkPolicy semantics](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
- [MITRE CWE-923](https://cwe.mitre.org/data/definitions/923.html)
- [MITRE CWE-284](https://cwe.mitre.org/data/definitions/284.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-container-host-resource-exposure"></a>

# Container exposes unintended host files or privileges

A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.

**Candidate CWE:** [CWE-250](https://cwe.mitre.org/data/definitions/250.html)

## Test hypothesis

Inspect one owned container's capabilities, host namespaces and mounts. In an isolated host fixture, compare access to a synthetic host marker with the restricted deployment; stop at the smallest demonstrated access.

## Evidence required

Image digest, runtime configuration, UID mapping, specific host resource and canary observation from the restricted workload identity.

## Rule out false positives

Container UID 0 alone, intended privileged administration agents, read-only access that does not meet the claimed impact, or a configuration warning without reachable authority.

## Playbook and command references

- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.
- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1611 · Escape to Host](#page-attack) — **Only if:** A controlled test shows code or access escaping a container or virtual machine into the underlying host/hypervisor security context. **Not established by:** Root inside a container is not necessarily host root. A permissive manifest or exposed Docker socket is a hypothesis until its actual boundary effect is established.

## Primary references

- [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
- [Docker Engine security](https://docs.docker.com/engine/security/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-iac-state-secret-exposure"></a>

# Sensitive values exposed through state or plan artifacts

A deployment artifact readable by an unintended principal contains credentials or equivalent confidential material.

**Candidate CWE:** [CWE-522](https://cwe.mitre.org/data/definitions/522.html)

## Test hypothesis

Create a trusted fixture plan/state with a synthetic secret marker. Trace the marker into the artifact, then compare artifact access for its owner and a principal who should not receive the value.

## Evidence required

Exact artifact version, marker presence, storage/access policy, unintended reader and secure comparison. Redact real values if encountered incidentally.

## Rule out false positives

The sensitive display flag does not remove state values by design; the finding requires an inappropriate reader, exposure path or broken confidentiality promise.

## Playbook and command references

- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [Terraform sensitive data handling](https://developer.hashicorp.com/terraform/language/manage-sensitive-data)
- [Terraform JSON display](https://developer.hashicorp.com/terraform/cli/commands/show)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-container-build-secret-leak"></a>

# Secrets retained in container build artifacts

A build places confidential inputs in image history, layers or artifacts available outside their intended audience.

**Candidate CWE:** [CWE-522](https://cwe.mitre.org/data/definitions/522.html)

## Test hypothesis

Build only a reviewed fixture recipe with a synthetic marker in the suspected secret input. Inspect the resulting owned image history/layers and compare a build using the documented secret mechanism.

## Evidence required

Build recipe and commit, exact image digest, marker location, image-reader access and the secure build comparison.

## Rule out false positives

Fake sample strings, public non-secret build metadata, or a secret mount that is not persisted into the final accessible artifact.

## Playbook and command references

- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [Docker build secrets](https://docs.docker.com/build/building/secrets/)
- [Docker image history](https://docs.docker.com/reference/cli/docker/image/history/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-iac-insecure-supported-default"></a>

# Supported deployment default exposes a protected service

A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.

**Candidate CWE:** [CWE-276](https://cwe.mitre.org/data/definitions/276.html)

## Test hypothesis

Freeze the documented install inputs, render with synthetic values, deploy in the owned lab and compare one canary operation from allowed and disallowed network positions. Change only the implicated setting and repeat.

## Evidence required

Versioned installation instructions, values, rendered resource, actual endpoint and unauthorized canary result alongside the corrected default.

## Rule out false positives

Development-only templates, operator-added unsafe overrides, a public port still protected by appropriate authentication, or a rendered rule never deployed.

## Playbook and command references

- [Infrastructure configuration: from repository default to deployed impact](#page-modules-infrastructure-config) — Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.
- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Docker Compose effective configuration](https://docs.docker.com/reference/cli/docker/compose/config/)
- [Helm template behavior](https://helm.sh/docs/helm/helm_template/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-dns-dangling-resource-reference"></a>

# Dangling DNS reference to a retired service

An owned hostname still points to a released provider resource, creating a possible takeover path if provider binding rules permit it.

**Candidate CWE:** [CWE-672](https://cwe.mitre.org/data/definitions/672.html)

## Test hypothesis

Inspect the exact record chain, resource absence and provider ownership-validation requirements. Use owner inventory and a separate controlled provider fixture to assess the failure mode; do not claim or rebind the target hostname without an approved method.

## Evidence required

DNS answers and timestamps, resource status and documented binding requirements. Mark exploitability unconfirmed if claimability cannot be established.

## Rule out false positives

NXDOMAIN alone, reserved or protected names, required ownership verification, transient provisioning errors and stale cached records.

## Playbook and command references

- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [Web & API](#page-web-api)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Microsoft dangling DNS and takeover prevention](https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover)
- [CWE-672 definition](https://cwe.mitre.org/data/definitions/672.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-dns-unrestricted-zone-transfer"></a>

# Restricted DNS zone transferable from an unintended source

An unauthorized source can retrieve an entire zone that the owner intends to restrict.

**Candidate CWE:** [CWE-732](https://cwe.mitre.org/data/definitions/732.html)

## Test hypothesis

Use one explicitly owned, small fixture zone and a single AXFR request to its approved authoritative server. Compare the permitted transfer source with the restricted source, preserving transport and source identity.

## Evidence required

The exact zone, source addresses, full fixture transfer bracketed by SOA records and the owner's transfer-access rule.

## Rule out false positives

Intentionally published zones, a legitimate secondary server, ordinary public DNS queries, or an incomplete transfer response without the claimed disclosure.

## Playbook and command references

- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [AXFR protocol](https://www.rfc-editor.org/rfc/rfc5936.html)
- [BIND dig reference](https://bind9.readthedocs.io/en/v9.20.13/manpages.html#dig-dns-lookup-utility)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-dns-unrestricted-recursion"></a>

# DNS recursion available outside the intended client network

A resolver performs recursive lookups for a client excluded by its intended access policy.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

From an owned disallowed source, send one unique query for a record in the researcher's authoritative zone through the approved resolver. Compare the permitted-source control and correlate the authoritative callback.

## Evidence required

Resolver/source identities, unique query and response, authoritative log and intended recursion ACL. No spoofed-source or amplification testing is needed. Determine whether recursion authorization is missing (CWE-862) or an implemented check accepts the wrong client (CWE-863); do not substitute the high-level CWE-284 for that root-cause analysis.

## Rule out false positives

A public recursive service by design, cached responses, an authoritative answer, or the RA flag without proof the resolver performed the lookup.

## Playbook and command references

- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [BIND recursion and access controls](https://bind9.readthedocs.io/en/v9.20.13/reference.html)
- [MITRE CWE-862](https://cwe.mitre.org/data/definitions/862.html)
- [MITRE CWE-863](https://cwe.mitre.org/data/definitions/863.html)
- [MITRE CWE-284](https://cwe.mitre.org/data/definitions/284.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-smtp-unintended-open-relay"></a>

# SMTP relay allows unauthenticated external delivery

An untrusted unauthenticated client can relay between external domains contrary to the server's relay policy.

**Candidate CWE:** [CWE-441](https://cwe.mitre.org/data/definitions/441.html)

## Test hypothesis

When mail delivery is explicitly covered, send one inert marked message from an owned sender domain to an owned external receiver through the tested relay. Use a source outside trusted networks and no inherited SMTP authentication.

## Evidence required

Source address, no-AUTH transcript, external envelope identities, queue response and receiver-confirmed delivery of the marker. Preserve the permitted submission comparison.

## Rule out false positives

Delivery to local domains, an allowlisted source, intended authenticated submission, RCPT acceptance without delivery, or a message routed through a different server.

## Playbook and command references

- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [SMTP protocol](https://www.rfc-editor.org/rfc/rfc5321.html)
- [Swaks transaction controls](https://jetmore.org/john/code/swaks/latest/doc/ref.txt)
- [CWE-441 definition](https://cwe.mitre.org/data/definitions/441.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-redis-canary-access"></a>

# Redis authentication or key ACL boundary failure

An anonymous or restricted client can read a key outside the service's intended access policy.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

On an owned fixture, compare one exact canary GET without inherited credentials, with the allowed account and with the restricted account. Keep the endpoint and known key constant; do not enumerate keyspace.

## Evidence required

Source and account identity, exact GET response containing the synthetic marker, effective ACL and the expected denial control.

## Rule out false positives

An intentionally permitted anonymous health command, absent keys, connectivity failure, inherited REDISCLI_AUTH credentials, or broad-looking network exposure protected by appropriate ACLs.

## Playbook and command references

- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Redis security model](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)
- [Redis CLI authentication behavior](https://redis.io/docs/latest/develop/tools/cli/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-postgres-unintended-trust-auth"></a>

# PostgreSQL trust authentication exceeds the approved network boundary

An unintended source can connect as a protected database identity without the required authentication because an effective trust rule applies.

**Candidate CWE:** [CWE-306](https://cwe.mitre.org/data/definitions/306.html)

## Test hypothesis

Using the owner-supplied fixture account and canary database, compare connection from intended and disallowed controlled sources. Clear password/service inheritance for the unauthenticated case, record the selected pg_hba rule and read one canary row.

## Evidence required

Source address, connection type, database/user, authentication logs or effective trust rule, and a canary result with credentials demonstrably absent.

## Rule out false positives

Authorized local socket administration, a supplied password file authenticating the connection, another valid authentication method, or a trust entry that never matches the tested path.

## Playbook and command references

- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PostgreSQL host authentication rules](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html)
- [PostgreSQL connection parameters](https://www.postgresql.org/docs/current/libpq-connect.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-queue-virtual-host-boundary"></a>

# Message broker permissions cross a virtual-host boundary

A restricted broker identity can act on a queue or exchange belonging to a different isolated fixture tenant.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Create two owned virtual hosts with one synthetic queue each. Compare the same permitted operation in A with the disallowed operation in B; use one marked message only if publishing or consuming is part of the authorized test.

## Evidence required

Broker identity, virtual host/resource names, configured permission regexes, precise operation and marker/acknowledgement result.

## Rule out false positives

Successful broker login alone, intended shared virtual hosts, a permission pattern that correctly matches only A's resources, or a test that changes the fixture owner's account.

## Playbook and command references

- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [RabbitMQ authentication and resource permissions](https://www.rabbitmq.com/docs/access-control)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-container-daemon-client-auth"></a>

# Container daemon management endpoint lacks required client authentication

An untrusted network client reaches protected container-management functionality without the required identity checks.

**Candidate CWE:** [CWE-306](https://cwe.mitre.org/data/definitions/306.html)

## Test hypothesis

Inspect the owned daemon's listener, TLS/client-certificate policy and trusted proxy behavior. Compare an approved protected metadata request with and without the fixture client identity; stop before workload creation or host mounts.

## Evidence required

Endpoint ownership, actual management API response, missing required authentication and configuration corroborating the affected authority. State any untested administrative operations as unproven.

## Rule out false positives

A public health/version endpoint behind a correctly restricted management proxy, an already trusted local socket, or TLS encryption mistakenly assumed to require client certificates.

## Playbook and command references

- [Database, cache, queue and management service boundaries](#page-modules-network-service-boundaries) — Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.
- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Docker daemon access protection](https://docs.docker.com/engine/security/protect-access/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-android-exported-operation"></a>

# Exported Android component exposes a protected operation

An externally reachable activity, service or receiver performs work that its caller is not entitled to request.

**Candidate CWE:** [CWE-926](https://cwe.mitre.org/data/definitions/926.html)

## Test hypothesis

Record the intended app action, then repeat one harmless seeded operation from an ordinary companion app without the required permission. Compare with an explicitly authorized caller.

## Evidence required

Package/build/API level, resolved export and permission state, companion identity, exact intent, expected denial and protected result.

## Rule out false positives

Exported status or opening a public screen is insufficient. ADB-only access or privileged caller setup does not establish ordinary-app reachability.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Android exported components](https://developer.android.com/privacy-and-security/risks/android-exported)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-android-provider-grant"></a>

# Content-provider permission or URI-grant escape

A recipient obtains data or file capabilities beyond the URI and permissions deliberately shared with it.

**Candidate CWE:** [CWE-926](https://cwe.mitre.org/data/definitions/926.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Seed two records. Grant an ordinary test app access to one, then request the other and repeat after the grant is revoked. Use only known synthetic URIs.

## Evidence required

Provider authority, URI, caller permissions, exact grant flags/lifecycle and the second record or unintended write capability.

## Rule out false positives

Intentionally shared resources and requests denied by the provider are expected. Root access to provider storage is a different model.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Content-provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-android-intent-redirection"></a>

# Nested intent redirects application authority

An exported entry point forwards attacker-supplied intent fields into a protected destination using the target application’s authority.

**Candidate CWE:** [CWE-441](https://cwe.mitre.org/data/definitions/441.html)

## Test hypothesis

Trace one legitimate forwarding path, then substitute a harmless lab destination while preserving other fields. Repeat from an ordinary app on the supported OS.

## Evidence required

Original and nested intents, controlled fields, caller/target identities, invoked capability and platform enforcement result.

## Rule out false positives

A forwarded public action is insufficient. Android 16 hardening can affect reachability; an older emulator or an opt-out test build cannot establish every release is affected.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Intent redirection and platform hardening](https://developer.android.com/privacy-and-security/risks/intent-redirection)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-android-pendingintent-delegation"></a>

# PendingIntent grants unintended mutable or replayable authority

A recipient can alter or reuse a delegated action beyond its intended destination, parameters or lifetime.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Obtain a token through a supported test-app interaction. Compare its intended action with one harmless altered field or repeat of a documented single-use action.

## Evidence required

How the attacker receives the token, creation flags, mutable fields, expected lifetime and demonstrated unauthorized action.

## Rule out false positives

Mutable or reusable PendingIntents can be intentional. Flag absence alone does not show abuse; the receiver may enforce the required policy.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PendingIntent risks](https://developer.android.com/privacy-and-security/risks/pending-intent)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mobile-link-handler"></a>

# Mobile link handler trusts routing as authorization

An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.

**Candidate CWE:** [CWE-939](https://cwe.mitre.org/data/definitions/939.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Open a known benign link, then vary one resource or callback parameter across logged-out/account-switched states. Keep callbacks and test objects owned.

## Evidence required

Exact URL, OS routing, eligible build, current account, handler path and resulting protected capability; document callback verification when relevant.

## Rule out false positives

A verified domain association does not prove parameter safety. A custom scheme existing or a public route opening is not a vulnerability by itself.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Android deep-link risks](https://developer.android.com/privacy-and-security/risks/unsafe-use-of-deeplinks)
- [Apple universal links](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mobile-webview-native-bridge"></a>

# Untrusted WebView content reaches a native bridge

A page or frame controlled outside the trusted app origin can invoke native capabilities through a shipped WebView bridge.

**Candidate CWE:** [CWE-749](https://cwe.mitre.org/data/definitions/749.html)

## Test hypothesis

Load a harmless owned page via a supported navigation/import feature; exercise one exposed method against a seeded lab resource and compare a trusted-origin control.

## Evidence required

Real content entry path, origin/frame, bridge name, reachable method, native operation and actual caller permissions.

## Rule out false positives

A bridge declaration, JavaScript execution alone, or developer-injected code is insufficient. Prove both the untrusted entry and native effect.

## Playbook and command references

- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Android WebView native bridges](https://developer.android.com/privacy-and-security/risks/insecure-webview-native-bridges)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ios-keychain-access-policy"></a>

# Keychain accessibility violates the intended lock boundary

A sensitive item or protected key operation is available in a device state that the application’s security policy requires it to deny.

**Candidate CWE:** [CWE-922](https://cwe.mitre.org/data/definitions/922.html)

## Test hypothesis

Compare one seeded item’s normal unlocked access with the supported locked/background path. Record class, group, synchronization and user-presence requirements separately.

## Evidence required

Actual item attributes, device state, consumer identity, exact recovered marker or permitted key operation and the violated requirement.

## Rule out false positives

Background access and synchronization may be deliberate. Dumping a jailbroken device’s Keychain does not establish an ordinary-app exploit.

## Playbook and command references

- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Apple Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ios-shared-container-trust"></a>

# Extension input crosses an iOS shared-container boundary

The main application trusts content written through a lower-trust extension/input path as if it were an authorized app action.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Map group membership and intended sharing, import one synthetic document through the real extension, and compare the main app’s treatment of expected and invalid metadata.

## Evidence required

Entitlements, signed participants, share-sheet or other real entry, controlled file/message and the resulting protected operation.

## Rule out false positives

App Group membership is not itself a leak. Signing the attacker app with the victim team or granting matching entitlements changes the attacker model.

## Playbook and command references

- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Apple app protection and groups](https://support.apple.com/guide/security/app-protection-and-app-groups-sec1a976c067/web)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-client-local-auth-gate"></a>

# Local authentication does not gate the protected operation

A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.

**Candidate CWE:** [CWE-288](https://cwe.mitre.org/data/definitions/288.html)

## Test hypothesis

Record legitimate unlock, then invoke an alternative supported route without satisfying local authentication. Limit the operation to a seeded private item.

## Evidence required

Documented protection promise, attacker access prerequisites, actual denied and alternate paths, and usable plaintext or key operation.

## Rule out false positives

Changing a return value with privileged instrumentation may only demonstrate the privileges you supplied. A UI preference that never promises a security boundary needs separate impact.

## Playbook and command references

- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Apple Keychain data protection](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-client-backup-sensitive-state"></a>

# Backup or transfer exposes unintended sensitive client state

A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.

**Candidate CWE:** [CWE-530](https://cwe.mitre.org/data/definitions/530.html) · [CWE-922](https://cwe.mitre.org/data/definitions/922.html)

## Test hypothesis

Seed one owned secret, run the supported backup/restore or export workflow, then check whether an explicitly excluded item becomes usable in the destination. Compare a session-free baseline.

## Evidence required

OS/build, actual backup channel and rules, restored marker, recipient privileges and any scoped demonstration that recovered authorization remains usable.

## Rule out false positives

Backup enabled alone is insufficient. Account-owner migration may be intended; Android cloud and device-transfer behavior can differ.

## Playbook and command references

- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Android Auto Backup](https://developer.android.com/identity/data/autobackup)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-client-secret-logging"></a>

# Sensitive client state leaks through accessible diagnostics

Logs, crash reports or user-exportable diagnostics disclose a secret or private record to a principal outside its intended audience.

**Candidate CWE:** [CWE-532](https://cwe.mitre.org/data/definitions/532.html)

## Test hypothesis

Perform one marked action, inspect its relevant release diagnostic output, and obtain that output using only the stated reader privileges. Compare a logged-out run.

## Evidence required

Logging source/sink, redacted synthetic value, release build, who can read/export it and a concrete confidentiality or token-reuse consequence.

## Rule out false positives

A debug-only log or ADB access does not prove another app can read it. Redacted identifiers and nonsensitive telemetry are not automatically secrets.

## Playbook and command references

- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [Android log information disclosure](https://developer.android.com/privacy-and-security/risks/log-info-disclosure)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-client-invalid-certificate"></a>

# TLS peer certificate or hostname verification failure

Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.

**Candidate CWE:** [CWE-295](https://cwe.mitre.org/data/definitions/295.html) · [CWE-297](https://cwe.mitre.org/data/definitions/297.html)

## Test hypothesis

In an owned endpoint fixture, compare a valid certificate, an untrusted issuer and a wrong-host certificate while keeping the release, trust store and synthetic application request fixed. The valid control must connect. Observe the actual client decision and application exchange rather than treating a diagnostic command that continues after an error as proof.

## Evidence required

Record release provenance, expected hostname, certificate SANs, trust-store context, handshake decision and whether the protected request was transmitted. Preserve matched valid/invalid controls and all changes to lab CA, proxy and trust configuration.

## Rule out false positives

Missing pinning, intentional trust in a lab CA, debug overrides, instrumentation that disables checks, or a diagnostic client configured to continue after verification errors is not a release validation defect.

## Playbook and command references

- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [DNS, TLS and email trust boundaries](#page-modules-dns-tls-mail) — Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Network services](#page-network) · [Cloud & containers](#page-cloud) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Unsafe X509TrustManager](https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager)
- [Android network security configuration](https://developer.android.com/privacy-and-security/security-config)
- [OpenSSL verification controls](https://docs.openssl.org/3.5/man1/openssl-s_client/)
- [CWE-297 definition](https://cwe.mitre.org/data/definitions/297.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-electron-ipc-confused-deputy"></a>

# Electron IPC exposes main-process authority to an untrusted sender

An attacker-controlled renderer or frame invokes a privileged main-process operation through insufficient sender or argument validation.

**Candidate CWE:** [CWE-749](https://cwe.mitre.org/data/definitions/749.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Trace a legitimate bridge call, then repeat it from an untrusted context reachable through a real feature; compare rejected sender and invalid-argument controls.

## Evidence required

Actual frame/origin, entry path, exposed bridge, IPC handler, argument constraints and one bounded native read/write result.

## Rule out false positives

Context isolation enabled is not a complete defense, but its absence alone is not a finding. Console-only execution does not establish an attacker entry.

## Playbook and command references

- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1203 · Exploitation for Client Execution](#page-attack) — **Only if:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process. **Not established by:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.

## Primary references

- [Electron IPC sender validation](https://www.electronjs.org/docs/latest/tutorial/security)
- [Electron context isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-desktop-protocol-confusion"></a>

# Desktop protocol handler misinterprets external input

An OS-dispatched URL reaches a native command or operation with attacker-controlled arguments outside the intended handler contract.

**Candidate CWE:** [CWE-88](https://cwe.mitre.org/data/definitions/88.html)

## Test hypothesis

Invoke a harmless discovered scheme normally, then vary one encoded argument in a local fixture and observe parsing and the eventual operation.

## Evidence required

Packaged application/OS, registered scheme, exact URI, argument construction, required interaction and protected effect.

## Rule out false positives

Protocol registration and opening a legitimate application are expected. Do not label parsing errors as command execution without a verified command boundary.

## Playbook and command references

- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1203 · Exploitation for Client Execution](#page-attack) — **Only if:** A client-application vulnerability executes attacker-controlled code when the client processes a file, document, or other content; identify the affected desktop/client process. **Not established by:** A parser crash alone is insufficient. Ordinary web XSS is not automatically a native client execution exploit, and Mobile uses separate technique IDs.

## Primary references

- [Electron deep links](https://www.electronjs.org/docs/latest/tutorial/launch-app-from-url-in-another-app)
- [Electron shell API](https://www.electronjs.org/docs/latest/api/shell)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-update-untrusted-artifact"></a>

# Updater accepts an artifact outside its publisher trust policy

The real update decision accepts modified bytes or an unrelated publisher identity before activation.

**Candidate CWE:** [CWE-494](https://cwe.mitre.org/data/definitions/494.html) · [CWE-347](https://cwe.mitre.org/data/definitions/347.html)

## Test hypothesis

Use the product's local updater fixture or production-equivalent verifier. Compare a genuine update, an inert corrupted copy, a wrong-publisher fixture and an applicable metadata/artifact mismatch. Hold the trusted publisher policy fixed and show the attacker's actual replacement/distribution control. Record download, verification, staging and activation separately.

## Evidence required

Preserve expected signer/source policy, exact accepted artifact digest, verifier version, verification order, staging permissions and the harmless consumed marker or activation result. Distinguish a correctly authenticated artifact from the separate question of whether its build contents are trustworthy.

## Rule out false positives

A failed standalone signature check does not show updater acceptance. Attacker-added trust roots, disabled production verification, rejected substituted artifacts, or a setup that bypasses the real distribution boundary invalidate that claim. No particular signing technology is universally required when other controls satisfy the actual threat model.

## Playbook and command references

- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop) · [Mobile](#page-mobile) · [OSS & self-hosted](#page-oss) · [Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain](#page-attack) — **Only if:** A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab. **Not established by:** Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.

## Primary references

- [Android application signing](https://developer.android.com/studio/publish/app-signing)
- [Electron autoUpdater](https://www.electronjs.org/docs/latest/api/auto-updater)
- [MITRE CWE-494](https://cwe.mitre.org/data/definitions/494.html)
- [GitHub CLI artifact verification](https://cli.github.com/manual/gh_attestation_verify)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-updater-privileged-staging"></a>

# Privileged updater consumes lower-user-controlled staging content

A standard user can replace a staged file or redirect a path actually consumed by a privileged installation process.

**Candidate CWE:** [CWE-732](https://cwe.mitre.org/data/definitions/732.html) · [CWE-367](https://cwe.mitre.org/data/definitions/367.html)

## Test hypothesis

Trace a normal update, inspect the observed parent/file ACLs, then use an inert fixture to show a standard-user change reaches the privileged consumer in a disposable VM.

## Evidence required

Write permission, exact path/object, real consumer identity, timing if a race is claimed and a harmless resulting operation.

## Rule out false positives

Writable unused directories, same-user modifications, or actions requiring administrator privileges do not establish escalation.

## Playbook and command references

- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1068 · Exploitation for Privilege Escalation](#page-attack) — **Only if:** A software vulnerability crosses a privilege boundary into a more privileged process or security context; record before/after identities and the vulnerable component. **Not established by:** Do not infer this from any feature named admin, a writable path alone, or a kernel version match. Application role authorization flaws need their own contextual analysis.

## Primary references

- [Microsoft ACL inspection](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls)
- [Apple code signing boundaries](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-update-security-rollback"></a>

# Attacker-controlled rollback restores a prohibited security state

An attacker bypasses an update version authorization policy to cause a rollback that restores a prohibited security state.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

In a local update fixture, compare current and older authentic versions under unchanged verifier policy. Show how the attacker supplies the older artifact without signing or administrative authority.

## Evidence required

Rollback policy, exact versions, artifact authenticity, attacker control and the concrete restored security consequence.

## Rule out false positives

Supported manual downgrade, administrator-selected rollback, or older-version installation alone is insufficient. Explicit ADB downgrade flags do not demonstrate a bypass. Select the final CWE from the demonstrated root cause; algorithm negotiation and hardware security-version CWEs do not automatically apply.

## Playbook and command references

- [Update signatures, rollback and privileged installation](#page-modules-update-integrity) — Test the update decision and installation boundary while preserving production signer and privilege assumptions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop) · [Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Android application signing and update identity](https://developer.android.com/studio/publish/app-signing)
- [Electron updater behavior](https://www.electronjs.org/docs/latest/api/auto-updater)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-indirect-prompt-tool-injection"></a>

# Indirect prompt injection into protected tool actions

Lower-trust retrieved content influences the agent into a tool operation outside the legitimate task or granted authority.

**Candidate CWE:** [CWE-1427](https://cwe.mitre.org/data/definitions/1427.html)

## Test hypothesis

Compare a benign document with a copy containing a harmless stub-action instruction. Keep the owned victim task and tool set constant; compare attempted and committed mock events over a fixed small trial count.

## Evidence required

Exact legitimate task, edited source, document hash, acting identity, tool arguments and unauthorized synthetic side effect; report successes/attempts.

## Rule out false positives

Style changes, policy refusals and fabricated action claims do not prove a protected boundary was crossed.

## Playbook and command references

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-1427: LLM prompting input](https://cwe.mitre.org/data/definitions/1427.html)
- [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-agent-tool-object-authorization"></a>

# Agent tool accepts unauthorized object or tenant parameters

A tool trusts caller-supplied object or workspace identifiers instead of enforcing the authenticated principal’s authority.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

As A, call the local tool with A’s owned object, then B’s synthetic object while holding credentials constant. Repeat directly through the tool adapter to locate backend authorization independently of prompting.

## Evidence required

A/B ownership records, authenticated principal, accepted arguments, server decision and B canary or protected state change.

## Rule out false positives

Shared objects or deliberately delegated connector access can legitimately cross apparent workspace boundaries.

## Playbook and command references

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- [MCP Authorization 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-agent-approval-argument-drift"></a>

# Agent approval is not bound to executed arguments

An approved harmless action can be modified before dispatch without revalidating the approval’s scope.

**Candidate CWE:** [CWE-367](https://cwe.mitre.org/data/definitions/367.html)

## Test hypothesis

Approve a local draft addressed to a stub destination, then change only the object, destination or content before execution. Compare with the unchanged approved draft and an explicitly unapproved draft.

## Evidence required

Approval timestamp, canonical approved/executed values or digests, user-visible approval text and the mock committed event.

## Rule out false positives

Approval may intentionally cover a defined batch or dynamic scope; show that the mutation exceeds that documented scope.

## Playbook and command references

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mcp-proxy-confused-deputy"></a>

# MCP proxy consent confuses different clients

A proxy reuses upstream consent in a way that grants a new MCP client access without the resource owner’s intended per-client consent.

**Candidate CWE:** [CWE-441](https://cwe.mitre.org/data/definitions/441.html)

## Test hypothesis

In an owned OAuth fixture, authorize client A, retain the browser’s normal upstream state, then initiate client B. Compare with a clean-browser baseline and inspect whether B receives authorized access before its own consent.

## Evidence required

Both registered client IDs, requested scopes, consent records, redirect binding and a synthetic resource-access result; redact codes and tokens.

## Rule out false positives

A shared upstream client ID alone is not proof; demonstrate the complete consent bypass conditions.

## Playbook and command references

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MCP Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mcp-token-audience-confusion"></a>

# MCP accepts a token for another resource

A protected MCP resource accepts a token that was not issued for that resource.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

Use local issuer fixtures to compare a correctly issued token with an otherwise valid token intended only for a second owned resource. Request the same harmless protected operation with each.

## Evidence required

Expected resource, redacted issuer/audience/scope claims, verification outcome and unauthorized synthetic response.

## Rule out false positives

Some deployments intentionally define a valid audience set; compare against actual issuer and resource policy, not a guessed hostname.

## Playbook and command references

- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1550.001 · Use Alternate Authentication Material: Application Access Token](#page-attack) — **Only if:** A captured or improperly obtainable application token is actually accepted for access to a protected service or resource outside the actor's intended permissions. **Not established by:** Finding a token alone is not reuse; routine authorized API calls are not this behavior. Current Enterprise tactic metadata lists Lateral Movement, not the old Defense Evasion label.

## Primary references

- [MCP Authorization 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-rag-cross-tenant-retrieval"></a>

# RAG retrieval or citation resolver crosses tenant boundaries

Search filters, chunk retrieval or citation download omit an ownership decision required for the effective caller.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Seed A/B private markers; verify owner access and cross-tenant direct denial. As A query for B’s subject without including its secret marker, then compare returned chunk IDs, answer text and citation download.

## Evidence required

Authenticated A context, B document ownership, exact retrieval/resolver path and exposed synthetic content. Distinguish internal retrieval from user-visible disclosure.

## Rule out false positives

Intentionally shared corpora, marker echo from the query and ingestion failures are not tenant-isolation proof.

## Playbook and command references

- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-rag-cache-revocation-leak"></a>

# RAG cache or fresh retrieval ignores revoked access

A new retrieval or cache response exposes protected content after its applicable permission revocation has taken effect.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Retrieve a shared synthetic document as A; revoke its share, wait the documented sync interval, then compare fresh and existing conversations plus cold/warm caches. Verify direct access denial in the same state.

## Evidence required

Share/revocation timestamps, sync policy, cache warm sequence, effective identity and newly delivered protected content.

## Rule out false positives

Content already delivered before revocation, intended transcript retention and behavior inside a documented sync window need separate interpretation.

## Playbook and command references

- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-reentrant-state"></a>

# Contract callback reentrancy violates a state invariant

Nested calls observe or alter state under assumptions that do not hold while an earlier operation is incomplete.

**Candidate CWE:** [CWE-1265](https://cwe.mitre.org/data/definitions/1265.html)

## Test hypothesis

Use one bounded local callback attempt into the same or related function. Compare with an inert callback under identical balances and roles, then check an independent accounting or authorization invariant.

## Evidence required

External-call trace, intermediate state, nested transition, initial capital and measured entitlement or balance violation.

## Rule out false positives

A callback or missing guard alone is insufficient when state ordering and other controls preserve the property.

## Playbook and command references

- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-1265: Unintended reentrant invocation](https://cwe.mitre.org/data/definitions/1265.html)
- [Solidity security considerations](https://docs.soliditylang.org/en/latest/security-considerations.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-unprotected-initializer"></a>

# Contract initializer permits unauthorized ownership or configuration

A reachable initialization path lets an ordinary actor establish or replace privileged state outside the intended deployment lifecycle.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html)

## Test hypothesis

In a faithful local deployment, compare intended initialization, a repeated initialization attempt and an ordinary actor’s attempt against the proxy or relevant instance. Check actual storage and roles.

## Evidence required

Proxy/implementation identity, initialization state, caller role, accepted transition and resulting protected capability.

## Rule out false positives

Initializing an unused implementation does not automatically compromise its proxy; prove how the changed state matters.

## Playbook and command references

- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OpenZeppelin Contracts 5.x proxies](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-upgrade-authorization"></a>

# Contract upgrade authority can be bypassed

An actor outside the upgrade policy can change a proxy’s execution target or equivalent privileged configuration.

**Candidate CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html)

## Test hypothesis

Compare authorized and ordinary local actors invoking the actual upgrade path, using a benign compatible implementation that emits a local marker. Inspect the effective implementation and authority checks.

## Evidence required

Exact proxy family, authorization path, implementation state before/after and harmless proof that execution follows the new target.

## Rule out false positives

A configured owner performing an intended upgrade is not an authorization bypass; role-compromise assumptions must be disclosed.

## Playbook and command references

- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OpenZeppelin Contracts 5.x proxies](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-share-accounting"></a>

# Vault share conversion or rounding breaks entitlement

Conversions, fees or rounding create an unintended claim on assets or an eligible loss under supported token behavior.

**Candidate CWE:** [CWE-682](https://cwe.mitre.org/data/definitions/682.html)

## Test hypothesis

In a local vault, compare ordinary round trips with minimal amounts, zero-supply state, direct donations and mixed supported decimals. Track independent asset/share balances and attacker cost.

## Evidence required

Units, initial supply, exact sequence, fees, rounding direction and bounded victim/protocol loss versus baseline.

## Rule out false positives

Expected rounding dust, unsupported token semantics and unprofitable scenarios without eligible harm do not establish the claimed exploit.

## Playbook and command references

- [Contract state: authorization, callbacks and accounting](#page-modules-smart-contract-state) — Turn protocol promises into explicit invariants and test realistic local operation sequences with independent accounting.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OpenZeppelin ERC-4626](https://docs.openzeppelin.com/contracts/5.x/erc4626)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-signature-replay"></a>

# Signed contract action can be replayed unexpectedly

A successfully consumed authorization remains reusable despite a one-use or otherwise bounded execution contract.

**Candidate CWE:** [CWE-294](https://cwe.mitre.org/data/definitions/294.html)

## Test hypothesis

Sign a harmless action with a local test key, execute it successfully, then submit identical bytes again in the local EVM. Compare with a fresh nonce and an invalid signature.

## Evidence required

Signed message, expected replay policy, nonce state and distinct accepted effects; use only disposable keys.

## Rule out false positives

Some signed orders intentionally allow partial fills or repeated use up to a limit; prove the documented limit was exceeded.

## Playbook and command references

- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [EIP-712](https://eips.ethereum.org/EIPS/eip-712)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-signature-context"></a>

# Signed action does not bind its intended context

A valid signature is accepted for another recipient, action, verifier or chain context contrary to the authorization contract.

**Candidate CWE:** [CWE-345](https://cwe.mitre.org/data/definitions/345.html)

## Test hypothesis

Generate a local baseline signature, then vary exactly one intended binding in a fresh local setup: recipient, amount, verifier instance or chain context. Compare recovered signer and accepted state change.

## Evidence required

Message schema, domain, differing context field, verifier logic and unintended local operation.

## Rule out false positives

Intentionally portable authorizations and unsupported signing paths require a demonstrated conflicting guarantee.

## Playbook and command references

- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [EIP-712](https://eips.ethereum.org/EIPS/eip-712)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-stale-oracle"></a>

# Oracle freshness or dependency state permits an invalid decision

A consumer accepts an observation outside its required freshness or availability conditions and makes an incorrect economic decision.

**Candidate CWE:** [CWE-754](https://cwe.mitre.org/data/definitions/754.html)

## Test hypothesis

Compare a valid feed state with one realistically stale timestamp, dependency failure, or applicable L2 sequencer recovery state. Keep price units and other metadata constant in the local harness.

## Evidence required

Configured freshness policy, feed timestamps, reachability assumptions, accepted consumer branch and measured quote/collateral consequence.

## Rule out false positives

A missing generic timestamp check alone is a lead; upstream guarantees and impossible mocked conditions can invalidate the claim.

## Playbook and command references

- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Chainlink Data Feeds API](https://docs.chain.link/data-feeds/api-reference)
- [Chainlink L2 sequencer uptime feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-contract-oracle-unit-confusion"></a>

# Oracle denomination or decimal conversion is incorrect

The consumer mixes quote currencies, token precision or feed precision and assigns the wrong economic value.

**Candidate CWE:** [CWE-682](https://cwe.mitre.org/data/definitions/682.html)

## Test hypothesis

Use local mock feeds representing equal economic prices at supported decimal scales. Compare against an independent unit-aware calculation and the normal supported feed baseline.

## Evidence required

Feed address/type assumptions, currency pair, feed/token decimals, exact conversion and downstream value discrepancy.

## Rule out false positives

Changing a feed to an unsupported format solely through administrator control is not necessarily an attacker-reachable vulnerability.

## Playbook and command references

- [Contract signatures and oracles: context, freshness and units](#page-modules-contract-signatures-oracles) — Test signed-action context and price-consumer assumptions with local keys, mock feeds and explicit negative controls.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web3 & protocols](#page-web3) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Chainlink Data Feeds API](https://docs.chain.link/data-feeds/api-reference)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-firmware-signature-validation"></a>

# Firmware verifier accepts unauthenticated protected bytes

The relevant update acceptance path fails to authenticate executable payload or security-relevant metadata correctly.

**Candidate CWE:** [CWE-347](https://cwe.mitre.org/data/definitions/347.html)

## Test hypothesis

Compare an authentic image with a format-valid disposable copy containing one harmless changed protected field or missing signature. Use the real verifier in a local validation path and record the acceptance stage.

## Evidence required

Original/modified hashes, byte location, covered ranges, trust key source and parser-versus-signature decisions.

## Rule out false positives

Accepting an image for inspection or staging does not prove installation or execution; unprotected padding may be intentional.

## Playbook and command references

- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1542.001 · Pre-OS Boot: System Firmware](#page-attack) — **Only if:** A lab demonstration modifies system firmware, such as BIOS/UEFI, to maintain execution/access across boot; record the firmware component, persistence behavior, and recovery procedure. **Not established by:** Downloading firmware, finding an embedded password, or detecting missing signature checks alone is not firmware persistence. Ordinary application firmware packaging needs component-level analysis.
- [T1542.002 · Pre-OS Boot: Component Firmware](#page-attack) — **Only if:** A controlled reproduction modifies peripheral/component firmware to preserve execution or access outside the main OS/system firmware, with evidence of that persistence. **Not established by:** A firmware binary containing a vulnerable library is insufficient. Do not treat every IoT firmware issue as either system firmware or component firmware persistence.

## Primary references

- [OWASP firmware update tests](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-firmware-security-version-rollback"></a>

# Firmware security-version state can be lowered

An attacker can reduce the protected security version and thereby restore software excluded by the anti-rollback policy.

**Candidate CWE:** [CWE-1328](https://cwe.mitre.org/data/definitions/1328.html)

## Test hypothesis

In a local model or recoverable bench fixture, compare an authentic current image and older signed security version. Trace whether the eligible caller can lower the counter or select a bypass path.

## Evidence required

Security counter before/after, downgrade policy, signed image versions, caller access and reinstated vulnerable security state.

## Rule out false positives

Normal application rollback after failed boot validation, lower marketing versions and explicitly permitted recovery are distinct from anti-rollback bypass.

## Playbook and command references

- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-1328: Security version mutable to older versions](https://cwe.mitre.org/data/definitions/1328.html)
- [Espressif OTA documentation](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/ota.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-firmware-product-binding"></a>

# Firmware verification fails to enforce required product binding

An otherwise authentic image is accepted for an incompatible product or security configuration despite required target restrictions.

**Candidate CWE:** [CWE-20](https://cwe.mitre.org/data/definitions/20.html)

## Test hypothesis

Using format-valid local fixtures, compare the correct SKU/board/security variant with a different owned variant while holding signature validity constant. Inspect the actual compatibility gate without flashing.

## Evidence required

Product identifiers, expected compatibility rule, verified manifest fields and acceptance stage; execution impact requires additional faithful evidence.

## Rule out false positives

Vendors may intentionally ship one image across several SKUs; names differing is not proof of incompatibility.

## Playbook and command references

- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP firmware update tests](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/firmware_update_mechanism.md)
- [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-firmware-boot-chain-gap"></a>

# Boot or recovery path executes an unverified component

A reachable boot path omits an authenticity check required by the product’s execution trust model.

**Candidate CWE:** [CWE-345](https://cwe.mitre.org/data/definitions/345.html)

## Test hypothesis

Map normal and recovery stages in matching source/configuration; compare authentic and harmless altered component fixtures using the documented local verifier or emulator. Confirm where execution is gated.

## Evidence required

Exact chip revision, production security configuration, component trust relationships and faithfully observed bypass stage.

## Rule out false positives

Secure boot disabled on an intentionally open development board or a simulator that omits hardware verification is not production bypass proof.

## Playbook and command references

- [Firmware update and boot trust: signed bytes, product binding and rollback](#page-modules-firmware-update) — Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.
- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1542.001 · Pre-OS Boot: System Firmware](#page-attack) — **Only if:** A lab demonstration modifies system firmware, such as BIOS/UEFI, to maintain execution/access across boot; record the firmware component, persistence behavior, and recovery procedure. **Not established by:** Downloading firmware, finding an embedded password, or detecting missing signature checks alone is not firmware persistence. Ordinary application firmware packaging needs component-level analysis.
- [T1542.002 · Pre-OS Boot: Component Firmware](#page-attack) — **Only if:** A controlled reproduction modifies peripheral/component firmware to preserve execution or access outside the main OS/system firmware, with evidence of that persistence. **Not established by:** A firmware binary containing a vulnerable library is insufficient. Do not treat every IoT firmware issue as either system firmware or component firmware persistence.

## Primary references

- [Espressif Secure Boot v2](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v2.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-hardware-unauthenticated-console"></a>

# Production UART exposes an unauthenticated privileged console

The in-scope physical access model yields a protected console capability without required authentication.

**Candidate CWE:** [CWE-306](https://cwe.mitre.org/data/definitions/306.html)

## Test hypothesis

Capture UART passively first; on an owned suitable lab unit, compare logged-out and authenticated behavior using a harmless identity or synthetic-file read. Record actual privilege and physical effort.

## Evidence required

Retail configuration, access requirements, wiring/voltage notes, console transcript and a protected capability beyond banner output.

## Rule out false positives

Diagnostics, a login prompt, deliberately open developer hardware and intended administrator shells are different cases.

## Playbook and command references

- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP internal interfaces](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/internal_interfaces/README.md)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-hardware-debug-authorization"></a>

# On-chip debug interface exposes protected memory or control

A production debug/test interface permits a protected capability beyond the documented physical-access authorization.

**Candidate CWE:** [CWE-1191](https://cwe.mitre.org/data/definitions/1191.html)

## Test hypothesis

Use documented read-only diagnostics on an owned suitable unit to compare expected locked state with actual access to a synthetic protected region. Avoid unlock, erase and fuse operations.

## Evidence required

Chip/board version, lifecycle configuration, physical-access model, requested region and demonstrated unauthorized read or control.

## Rule out false positives

Visible JTAG pads, an accessible device ID or a development lifecycle state alone do not demonstrate protected-data access.

## Playbook and command references

- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-1191: On-chip debug access control](https://cwe.mitre.org/data/definitions/1191.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-firmware-shared-credentials"></a>

# Firmware contains a reusable shared authentication credential

An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.

**Candidate CWE:** [CWE-798](https://cwe.mitre.org/data/definitions/798.html)

## Test hypothesis

Classify the value offline; compare authentic owned-device artifacts if available and validate its role only against a local fixture or owned service. Establish whether it is per-device or shared.

## Evidence required

Affected image hashes, redacted credential location/type, privilege granted and controlled local authentication result.

## Rule out false positives

Public certificates, example passwords, unusable build secrets and hashes without a demonstrated authentication path remain leads.

## Playbook and command references

- [Hardware interfaces: production debug access and protected data](#page-modules-hardware-interfaces) — Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Hardware & firmware](#page-hardware) · [Network services](#page-network) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [OWASP installed firmware](https://github.com/OWASP/owasp-istg/blob/main/src/03_test_cases/firmware/installed_firmware.md)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-exposed-repository-secret"></a>

# Exposed repository or history secret

Source, history, or a published artifact exposes a credential outside its intended audience.

**Candidate CWE:** [CWE-540](https://cwe.mitre.org/data/definitions/540.html)

## Test hypothesis

Find the value locally, trace its consumer and intended audience, and identify the affected commit or artifact. Use a synthetic substitute to demonstrate the credential path. Ask the owner to establish validity or use a specifically permitted identity-only validation; do not try an unknown key against unrelated services.

## Evidence required

Record the location and access path, credential type, consumer, privilege assumptions, and a redacted fingerprint. Distinguish owner-confirmed validity from an unverified secret-like pattern. CWE-540 describes sensitive material included in source; classify an artifact exposure by its actual storage/disclosure cause.

## Rule out false positives

A fake example, revoked token, public client identifier, or scanner regex match does not establish exploitable credential exposure. A deployment secret accidentally committed to a repo is not automatically a hard-coded product credential.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

- [T1552.001 · Unsecured Credentials: Credentials In Files](#page-attack) — **Only if:** The tested path retrieves credentials from insufficiently protected configuration, source, log, archive, or other files; retain only redacted evidence and location details. **Not established by:** A high-entropy string, sample credential, or accessible file without authentication material is insufficient. Reading arbitrary non-secret data is a different behavior.

## Primary references

- [GitHub secret-scanning patterns](https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-open-redirect-trust"></a>

# Open redirect across an origin trust boundary

Attacker input controls a navigation destination that the application treats as trusted.

**Candidate CWE:** [CWE-601](https://cwe.mitre.org/data/definitions/601.html)

## Test hypothesis

Capture a normal return URL, change only its destination to a controlled lab origin, and inspect the actual navigation. Compare an approved local path with a denied foreign origin. If the claimed impact is OAuth leakage, reproduce the additional token or code transfer on your own client and account; a redirect alone is not that chain.

## Evidence required

Preserve the initiating URL, validation decision, Location or browser destination, and the smallest demonstrated trust violation. Document whether a warning or explicit user choice intervenes.

## Rule out false positives

A documented external redirect service, a plain external link, or an origin rejected before navigation may be intended behavior. A phishing hypothesis alone does not prove account takeover.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP redirects and forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-clickjacking-sensitive-action"></a>

# Clickjacking of a sensitive authenticated action

An untrusted origin can frame and visually disguise an authenticated operation.

**Candidate CWE:** [CWE-1021](https://cwe.mitre.org/data/definitions/1021.html)

## Test hypothesis

On two controlled origins, embed the target page and establish whether its session remains usable in the frame. Align a harmless synthetic setting action and demonstrate the intended click changes that setting. Compare a protected sibling route and test the actual browser framing policy.

## Evidence required

Capture browser version, frame response policy, authenticated frame state, the interaction, and the before/after setting. Explain any required user gesture or extra confirmation.

## Rule out false positives

Missing X-Frame-Options is insufficient when CSP frame-ancestors blocks framing. A frameable public page, an unauthenticated frame, or an operation requiring undisguisable reauthentication does not establish the same impact.

## Playbook and command references

- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger clickjacking](https://portswigger.net/web-security/clickjacking)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-host-header-origin-trust"></a>

# Untrusted Host or forwarding-header origin construction

The application constructs a security-sensitive origin from request metadata that an attacker can influence.

**Candidate CWE:** [CWE-346](https://cwe.mitre.org/data/definitions/346.html)

## Test hypothesis

In the local proxy/application topology, capture a password-reset link for your own account. Change one Host or forwarded-origin input to a controlled sink and compare generated links and routing. Preserve the normal proxy path; direct-backend behavior is a separate reachability hypothesis.

## Evidence required

Show which hop accepted the untrusted value, the resulting sensitive link or policy decision, and a controlled artifact demonstrating impact. Treat cache poisoning as a separate chain requiring a second clean client.

## Rule out false positives

An echoed Host header or a denied invalid host is not a takeover. A backend trusted header that external callers cannot set is not attacker-controlled in that deployment.

## Playbook and command references

- [Proxy normalization, cache isolation, and request boundaries](#page-modules-proxy-cache) — Investigate layered HTTP behavior with isolated cache keys and controlled front-end/back-end traffic.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger Host header attacks](https://portswigger.net/web-security/host-header)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-sensitive-error-disclosure"></a>

# Sensitive data in errors, debug routes, or generated files

An error or debug output crosses a confidentiality boundary by revealing protected state.

**Candidate CWE:** [CWE-209](https://cwe.mitre.org/data/definitions/209.html)

## Test hypothesis

Send one malformed request for a synthetic object and compare it with the successful request. Identify a private marker, secret-bearing configuration, or privileged internal artifact in the response. If access is through a backup or debug file instead of an error message, map that actual exposure cause.

## Evidence required

Retain the exact request, redacted output, marker ownership, and intended confidentiality rule. Explain how the disclosed value enables the claimed impact without gathering unrelated records.

## Rule out false positives

A generic stack trace, version banner, local path, or public schema can be only informational; it does not automatically prove sensitive-data exposure or code execution.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger information disclosure](https://portswigger.net/web-security/information-disclosure)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-weak-security-token-randomness"></a>

# Predictable security token or capability identifier

A security token relies on randomness that does not meet its unpredictability requirement.

**Candidate CWE:** [CWE-338](https://cwe.mitre.org/data/definitions/338.html)

## Test hypothesis

Locate token generation in source and identify the random source, entropy input, encoding, and lifecycle. Generate a small synthetic fixture set locally and test a concrete prediction hypothesis. Compare against a cryptographically secure generator; do not brute-force live accounts.

## Evidence required

Show a prediction or generator-state argument sufficient to produce a valid controlled token, plus its accepted privilege and lifetime. Use a more precise CWE if the actual cause is insufficient entropy or an exposed token rather than the PRNG choice.

## Rule out false positives

Sequential public record IDs are not authentication secrets by themselves. A tiny sample passing or failing a statistical test does not establish cryptographic predictability.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-password-storage-weak-hash"></a>

# Password storage without an adequate adaptive hash

A password verifier has insufficient computational cost for its supported threat model.

**Candidate CWE:** [CWE-916](https://cwe.mitre.org/data/definitions/916.html)

## Test hypothesis

In your lab, create a synthetic password and inspect the stored verifier and verification path. Identify algorithm, salt handling, cost, migration behavior, and any server-side pepper. Measure the configured hash locally; preserve the application version and deployment settings.

## Evidence required

Provide a redacted verifier format, relevant code and configuration, and a bounded cost comparison. Distinguish plain-text storage, reversible encryption, and inadequate work factor; they have different root causes. Program eligibility and access prerequisites still matter.

## Rule out false positives

A visible salt, a random-looking digest, or a hash name alone is insufficient. An old digest that is immediately upgraded and inaccessible under the stated threat model needs qualified impact.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP password storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-crypto-authentication-missing"></a>

# Encrypted data accepted without integrity authentication

A protected data format permits security-relevant changes that are not detected before use.

**Candidate CWE:** [CWE-353](https://cwe.mitre.org/data/definitions/353.html)

## Test hypothesis

Identify the encryption mode and where integrity is checked. Save a valid synthetic message, change a controlled field or authenticated context in the local fixture, and compare processing with an invalid-tag control. Trace whether downstream code consumes plaintext before verification.

## Evidence required

Show the accepted modified value and resulting forbidden state; document key, nonce, tag, associated-data and parser assumptions. Nonce reuse is a separate cryptographic defect that needs its own demonstration.

## Rule out false positives

Encryption without an explicit MAC in one function may still be protected by authenticated encryption or an outer signed envelope. A rejected corruption or parser error is not authenticated forgery.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [Uploads, downloads, paths, archives, and XML](#page-modules-file-boundaries) — Follow a file through acceptance, storage, processing, publication, and retrieval while preserving ownership and path boundaries.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Web & API](#page-web-api) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Hardware & firmware](#page-hardware)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP cryptographic storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-saml-assertion-trust"></a>

# SAML assertion signature, audience, or response binding failure

The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.

**Candidate CWE:** [CWE-347](https://cwe.mitre.org/data/definitions/347.html) · [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

Use a local IdP/SP with two synthetic accounts. Compare a valid assertion with independently changed signed content, wrong audience/recipient, expiry, one replay, and mismatched InResponseTo where required. Trace which validated signed XML element supplies the consumed identity and attributes.

## Evidence required

Record the accepted identity, trust configuration, validation path, and the one invalid condition that survives. Keep signature failure separate from audience or response-binding failure when assigning a CWE.

## Rule out false positives

Decoding XML, modifying an unsigned irrelevant field, or using an explicitly supported IdP-initiated flow does not prove forgery. A signature check on one element does not establish that the consumed identity came from that element.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP SAML security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-authenticator-management-proof-bypass"></a>

# Unauthorized authenticator enrollment, replacement, or removal

A lower-assurance or wrong-account context can add, replace, or remove an authentication factor contrary to its management policy.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

In a disposable account, capture the legitimate factor-change flow. Compare required recent proof with stale, omitted, or other-account proof; independently test completed and MFA-pending sessions. Confirm a newly added factor through a fresh login, or a removed factor through one further login attempt.

## Evidence required

Expected factor-management rule, actor authentication state, factor owner before/after, exact changed proof, and a fresh protected-account result. Keep a recovery route and remove the test factor.

## Rule out false positives

A renamed label, intentional recovery process with adequate proof, or optional notification missing without any unauthorized factor change is insufficient.

## Playbook and command references

- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html)
- [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-webauthn-assertion-binding-failure"></a>

# WebAuthn assertion accepted for an invalid account or ceremony context

The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html) · [CWE-347](https://cwe.mitre.org/data/definitions/347.html)

## Test hypothesis

Start from a working local WebAuthn ceremony. Compare one consumed assertion, one invalid signature, and a validly signed fixture violating one server-side policy. For username-first login, check credential ownership; for discoverable login, check that the user handle and credential resolve to the same account.

## Evidence required

Expected relying-party policy, credential owner, altered validation condition, server acceptance, and resulting protected identity. Identify the verifier check that failed; editing signed bytes alone does not isolate semantic validation.

## Rule out false positives

Valid passwordless login to the credential owner, supported related origins, no attestation requirement, or a zero/non-increasing counter by itself does not prove bypass or cloning.

## Playbook and command references

- [MFA and passkeys: enrollment, proof, replacement, and recovery](#page-modules-authenticator-lifecycle) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [W3C WebAuthn Level 3 Recommendation, 25 August 2026](https://www.w3.org/TR/2026/REC-webauthn-3-20260825/)
- [Yubico WebAuthn Client Authentication](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Authentication.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-identity-verification-merge-confusion"></a>

# Verification or account merge preserves another actor's access

Registration, verification, email change, or federation merging transfers trust to an identity while retaining an unintended actor's usable credentials or session.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html)

## Test hypothesis

In the replica, create an unverified password account for an owned test inbox in profile A. Complete the legitimate verified/federated signup for that inbox in profile B. Check whether A's prior password/session remains usable against the now-verified private account. Test a stale email-verification link after a second owned email change separately.

## Evidence required

Before/after internal account IDs, verification state, linked issuer/subject, origin of the retained credential, and controlled private access after the transition.

## Rule out false positives

Aliases intentionally identifying one account, explicit authenticated linking, a duplicate-registration error, or an unverified account that gains no new protected access is not account takeover.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP Email Validation and Verification](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html)
- [OpenID Connect Core incorporating errata set 2](https://openid.net/specs/openid-connect-core-1_0.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-enforced-sso-alternate-login-bypass"></a>

# Enforced SSO bypass through an alternate login path

A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.

**Candidate CWE:** [CWE-288](https://cwe.mitre.org/data/definitions/288.html)

## Test hypothesis

Use a disposable tenant and recovery administrator. Establish normal federated access, enable its enforcement policy, then try each observed password, magic-link/reset, or alternate-client entry once with a controlled member. Request one synthetic private tenant object; compare the normal federated and logged-out controls.

## Evidence required

Saved tenant enforcement setting, applicable exceptions, actual authentication method/session, exact alternate entry point, and protected tenant access.

## Rule out false positives

Login to an account shell without access to the protected tenant, documented break-glass administrators, or independently scoped service credentials may be intended.

## Playbook and command references

- [Authentication, recovery, federation, and session lifecycle](#page-modules-identity-session) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.
- [OAuth, OIDC, and SAML: transaction binding and token trust](#page-modules-federation-token-trust) — Separate browser transaction binding, issuer trust, token purpose, and identity linking using controlled federation fixtures.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Mobile](#page-mobile) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-288 alternate authentication path](https://cwe.mitre.org/data/definitions/288.html)
- [OWASP authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-process-argument-option-injection"></a>

# Argument or option injection without shell interpretation

A value-only input changes options or mode of the intended executable, even when no shell is used.

**Candidate CWE:** [CWE-88](https://cwe.mitre.org/data/definitions/88.html)

## Test hypothesis

In the local product wrapper, compare a normal data argument with a harmless documented mode switch. Capture the final argument array and show that the untrusted caller can select an operation beyond the intended input contract.

## Evidence required

Exact executable, argument vector, source entry point, expected value-only contract, and the resulting protected mode or operation. Keep the canary free of filesystem writes, extra process execution, and network access.

## Rule out false positives

A process intentionally exposing that option, inert argument text, a validation error, or only changing a tool banner does not establish a security consequence. Shell syntax interpretation belongs to CWE-78.

## Playbook and command references

- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Desktop & extensions](#page-desktop) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [CWE-88 argument injection](https://cwe.mitre.org/data/definitions/88.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-request-parser-value-conflict"></a>

# Parameter or JSON parser disagreement crosses a security check

Validation or authorization uses one interpretation of a request value while the protected operation uses another.

**Candidate CWE:** [CWE-436](https://cwe.mitre.org/data/definitions/436.html)

## Test hypothesis

With A-readable O1 and B-only O2, capture allowed/denied scalar controls. Send one duplicated parameter or literal repeated JSON name in both orders through the normal local ingress. Trace exactly which value each security and execution layer consumes.

## Evidence required

Preserved raw bytes, parse/type/precedence behavior at each component, O1 being authorized, and O2 being consumed with a forbidden controlled result. Include a consistent-parser or strict-schema negative control.

## Rule out false positives

Duplicate acceptance, last-value parsing, a supported multivalue API, or different error text without a violated permission or input contract is insufficient.

## Playbook and command references

- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [RFC 8259 JSON object names and numeric interoperability](https://www.rfc-editor.org/rfc/rfc8259.html)
- [OWASP WSTG 4.2 HTTP parameter pollution](https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution)
- [CWE-436 interpretation conflict](https://cwe.mitre.org/data/definitions/436.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-downstream-parameter-injection"></a>

# Server-side parameter pollution in a constructed request

An outer input injects or alters parameters in a server-created downstream request.

**Candidate CWE:** [CWE-235](https://cwe.mitre.org/data/definitions/235.html)

## Test hypothesis

Trace an observed service call to a local stub. Submit one outer value containing a controlled delimiter marker and compare the downstream request with normal and correctly encoded controls. Use a source-confirmed synthetic field to establish changed policy semantics.

## Evidence required

Outer request bytes, decoding and concatenation order, actual downstream parameter map, and a controlled action/data boundary crossed. Distinguish input delimiter injection from merely providing a documented extra top-level parameter.

## Rule out false positives

A marker remaining inside one correctly encoded value, an intentionally supported parameter, or changed output without an observed downstream request boundary is not enough.

## Playbook and command references

- [Request values: duplicate parameters, parser conflicts and downstream queries](#page-modules-request-value-parsing) — Trace the value a security layer validates through to the value the application or downstream service actually consumes.
- [Trace input into queries, commands, and templates](#page-modules-injection-tracing) — Prove interpretation at a specific sink using small paired experiments instead of payload spraying.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PortSwigger server-side parameter pollution](https://portswigger.net/web-security/api-testing/server-side-parameter-pollution)
- [CWE-235 improper handling of extra parameters](https://cwe.mitre.org/data/definitions/235.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-webhook-event-authenticity-failure"></a>

# Unverified or tampered webhook causes a protected effect

An event is processed with privileged consequences without establishing the required sender and content authenticity.

**Candidate CWE:** [CWE-345](https://cwe.mitre.org/data/definitions/345.html)

## Test hypothesis

Capture a genuine controlled event, then test missing signature, invalid signature, and changed body with the unchanged signature in the local replica. Inspect the final worker effect as well as the immediate response, and compare an official-verifier control.

## Evidence required

Expected verification contract, exact signed bytes and metadata, reachable receiver path, rejected-versus-accepted controls, and the unauthorized synthetic state transition. Explain a realistic attacker delivery path.

## Rule out false positives

A public informational webhook intentionally needing no authenticity, a 2xx no-op, or the ability to sign events only because the tester installed the lab key does not prove a production forgery.

## Playbook and command references

- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [GitHub validating webhook deliveries](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries)
- [Stripe webhook verification, ordering and duplicate handling](https://docs.stripe.com/webhooks)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-webhook-provider-tenant-binding"></a>

# Authentic integration event applied to the wrong tenant or object

A valid provider event is misbound to a local tenant, installation, mode or resource the event is not authorized to modify.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use two controlled provider accounts/installations and local tenants. Deliver valid sandbox events through their normal route and compare trusted account mapping with any user-controlled routing metadata. Inspect a single reversible effect on the other controlled tenant.

## Evidence required

Signature verification result, authenticated provider identity, local mapping, attacker-controlled input, before/after state, and why the event lacks authority for the affected object. A valid signature alone is not the ownership check.

## Rule out false positives

An administrator deliberately sharing one integration across tenants, an intended account-wide event, or a mock event whose meaningful fields the real attacker cannot control is not a demonstrated cross-tenant flaw.

## Playbook and command references

- [Webhooks and integration events: authenticity, tenant binding and replay](#page-modules-webhook-event-integrity) — Verify the event signature, provider-to-tenant binding and durable worker effect together across retries and out-of-order delivery.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Stripe webhook verification, ordering and duplicate handling](https://docs.stripe.com/webhooks)
- [GitHub webhook best practices](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-gitlab-job-token-boundary"></a>

# GitLab job token crosses an unintended project boundary

A contribution-controlled job acquires access to a private receiving-project resource beyond the CI integration contract.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Use two owned projects and one private synthetic artifact. Compare the same resource request from the intended job context and a disallowed controlled project/actor. Record receiving-project allowlist, feature visibility, fine-grained restrictions, and triggering-user permissions; do not assume allowlisting alone grants access.

## Evidence required

Pipeline and job IDs, source/receiving project IDs, trigger actor, exact canary and allowed/denied results, with token values redacted.

## Rule out false positives

Intentionally public artifacts, an expired token, a denied endpoint, or access deliberately granted to the triggering user and originating project.

## Playbook and command references

- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.
- [CI and releases: trace untrusted input into privileged work](#page-modules-supply-chain-ci) — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [GitLab job-token permissions](https://docs.gitlab.com/ci/jobs/ci_job_token/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ci-runner-cross-job-state"></a>

# Shared CI runner exposes private state across jobs

A job reaches a previous job's private filesystem or image material despite the runner's promised isolation.

**Candidate CWE:** [CWE-668](https://cwe.mitre.org/data/definitions/668.html)

## Test hypothesis

Use two owned fixture jobs on a disposable runner. Create one known synthetic marker or private fixture image in the first context; test only that predetermined resource from the restricted second job. Compare a fresh isolated runner and record cache/mount/pull policy.

## Evidence required

Runner/executor version, job identities, host/mount or image boundary, marker result and clean-runner comparison. Prove the promised isolation and the lower-trust job's attainable scheduling conditions.

## Rule out false positives

Deliberately shared cache data, identical trust domains, an intentionally preinstalled public image, or a marker made public by the fixture itself.

## Playbook and command references

- [GitLab pipelines: contribution, job token and runner boundaries](#page-modules-gitlab-pipeline-boundaries) — Trace GitLab execution context, included configuration, downstream inputs, job-token permissions and runner reuse using private synthetic fixtures.
- [Container and Kubernetes isolation](#page-modules-container-kubernetes) — Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [GitLab runner security](https://docs.gitlab.com/runner/security/)
- [CWE-668: unintended resource sphere](https://cwe.mitre.org/data/definitions/668.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-extension-message-authority"></a>

# Page message borrows unintended browser-extension authority

An ordinary web page reaches a privileged extension action through insufficient message sender or argument validation.

**Candidate CWE:** [CWE-441](https://cwe.mitre.org/data/definitions/441.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Capture one intended page-to-extension action; repeat through the same shipped listener from a second controlled origin or with one changed synthetic resource. Observe the protected marker or reversible action and compare a rejected sender control.

## Evidence required

Preserve installed ID/version, real page entry, browser-provided sender metadata, body fields, permission grants, final API call and receiving principal.

## Rule out false positives

Broad host permissions, an external messaging entry or extension-console access alone is not the flaw. Public data and deliberately delegated page actions may be intended.

## Playbook and command references

- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.
- [Desktop IPC, Electron bridges and native protocols](#page-modules-desktop-ipc) — Follow page, file and local-process inputs into privileged desktop capabilities with a realistic caller.
- [Browser execution, cross-origin reads, and forged actions](#page-modules-browser-trust) — Use real browser behavior to distinguish XSS, CSRF, CORS, and messaging failures from header-only leads.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Chrome extension message passing](https://developer.chrome.com/docs/extensions/develop/concepts/messaging)
- [Chrome cross-origin request security](https://developer.chrome.com/docs/extensions/develop/concepts/network-requests)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-extension-document-reply-confusion"></a>

# Delayed extension result reaches a different document

An asynchronous extension operation reuses stale tab/frame authority after navigation and exposes a protected result to another document.

**Candidate CWE:** [CWE-367](https://cwe.mitre.org/data/definitions/367.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Pause a local mock response after authorizing the original page, navigate the same tab to another controlled origin, then release it. Compare unchanged-document and denied-origin controls.

## Evidence required

Record initiating and receiving origin/document IDs, event order, original grant, response route and the seeded private marker received by the unintended document.

## Rule out false positives

Dropped messages, responses retained only by the original authorized document, and intentionally public data do not show disclosure. Confirm the browser version supports the metadata used in the claim.

## Playbook and command references

- [Browser extensions: message authority and document lifetime](#page-modules-extension-message-boundaries) — Trace real page messages into extension capabilities and test sender identity, navigation races, permission changes and worker restarts.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Desktop & extensions](#page-desktop) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [Chrome MessageSender identity](https://developer.chrome.com/docs/extensions/reference/api/runtime#type-MessageSender)
- [Chrome document-targeted tab messaging](https://developer.chrome.com/docs/extensions/reference/api/tabs#method-sendMessage)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-ai-persistent-state-ownership"></a>

# Agent conversation, checkpoint or memory crosses ownership boundaries

Persisted agent state or its resume/export path is accessible or mutable by a principal outside its intended owner or sharing grant.

**Candidate CWE:** [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Seed private state under A/B; prove owner access and direct cross-owner denial. As A, substitute the known B handle in an actual state, resume or export API and record the completed result.

## Evidence required

Save state ownership, effective worker principal, exact handle path, expected grant and newly returned canary or unauthorized mutation. Separate queue acceptance from completed effect.

## Rule out false positives

Intentionally shared threads, an authorized service performing delegated work, and content already provided by the caller do not establish a cross-owner violation.

## Playbook and command references

- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [Object, function, and property authorization](#page-modules-authz-matrix) — Turn identities, tenants, objects, roles, and lifecycle transitions into a reproducible permission matrix.
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [LangGraph persistence: checkpointers and stores](https://docs.langchain.com/oss/python/langgraph/persistence)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mcp-resume-state-integrity"></a>

# MCP resumed state changes authorization or request meaning

An MRTR server trusts modified or context-mismatched requestState when it affects a protected resumed operation.

**Candidate CWE:** [CWE-345](https://cwe.mitre.org/data/definitions/345.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

In a version-matched local fixture, compare untouched state with a single alteration, cross-principal state and changed originating arguments. Exercise a harmless protected operation.

## Evidence required

Preserve protocol/version, state digest, issuer and presenting principals, original/resumed argument digests, validation result and unauthorized stub effect.

## Rule out false positives

A parser failure, state that affects only request failure, or an implementation using another protocol era is not this finding. Do not assume client instructions to keep state opaque constrain a hostile client.

## Playbook and command references

- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MCP 2026-07-28 multi round-trip requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-mcp-private-cache-context"></a>

# Private MCP result is reused across authorization contexts

A shared cache delivers caller-specific protocol data outside the authorization context that produced it.

**Candidate CWE:** [CWE-524](https://cwe.mitre.org/data/definitions/524.html) · [CWE-863](https://cwe.mitre.org/data/definitions/863.html)

## Test hypothesis

Warm a private owned B resource; repeat the same operation as A and compare with cold-cache denial. Separately inspect whether state-bearing MRTR retry results are incorrectly cached.

## Evidence required

Record method/parameters, authorization-context fingerprints, cache hints, cache hit/miss and the newly exposed private marker.

## Rule out false positives

Identical public tool lists, hints without a demonstrated shared result, or private content legitimately accessible to both callers do not prove exposure.

## Playbook and command references

- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [RAG isolation: ingestion, retrieval, citations and revocation](#page-modules-rag-tenant-isolation) — Trace document authorization through vector search, generated answers, citation downloads, caches and sharing changes.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MCP 2026-07-28 caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-agent-retry-duplicate-effect"></a>

# Agent retry commits a protected single-use action twice

A response-loss or resume path duplicates an operation whose application contract requires at-most-once effect.

**Candidate CWE:** [CWE-841](https://cwe.mitre.org/data/definitions/841.html)

## Test hypothesis

In the local stub adapter commit one harmless operation, lose its response, then retry exactly once. Compare business operation IDs and committed events with the normal single-delivery baseline.

## Evidence required

Show the at-most-once contract, retry trigger, same authorized operation, persisted completion state and two distinct committed effects; distinguish request IDs from business identity.

## Rule out false positives

Intentionally repeatable calls or two independently authorized operations are expected. A duplicate displayed answer or repeated proposal without a committed side effect is insufficient.

## Playbook and command references

- [AI state: memory, resumed work, retries and private caches](#page-modules-ai-state-lifecycle) — Test persistent context, task ownership, MCP request-state integrity, duplicate effects and caches across identities and time.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [Web & API](#page-web-api) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [MCP HTTP response loss and retries](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-client-private-ui-disclosure"></a>

# Private client content leaks through a lower-trust display or sharing channel

A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.

**Candidate CWE:** Map the actual root cause once established.

## Test hypothesis

Seed a private/public fixture pair and compare lock, background and account-switch states through the normal OS UI. Obtain the marker with only the stated observer privileges.

## Evidence required

Capture exact app/OS version, privacy settings, content ownership, reader prerequisites, state transition and the smallest marker exposure. Classify the actual display, notification, clipboard or sharing-channel mechanism; confidentiality loss alone does not establish a specific CWE root cause.

## Rule out false positives

Missing screenshot flags, intended account-owner display, explicitly granted accessibility authority, or a deliberate user-enabled notification preview may not violate the product's security contract.

## Playbook and command references

- [Client storage, logs, backup and transport trust](#page-modules-client-storage-transport) — Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.
- [iOS signing capabilities, links and protected data](#page-modules-ios-boundaries) — Connect entitlements and application groups to actual callers, URL transitions and protected key use.
- [Android components, intents and deep links](#page-modules-android-components) — Trace ordinary-app inputs through exported components, URI grants and links to one protected operation.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Mobile](#page-mobile) · [Desktop & extensions](#page-desktop)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP MASVS-STORAGE-2: unintended data leakage](https://mas.owasp.org/MASVS/controls/MASVS-STORAGE-2/)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-model-artifact-unsafe-loading"></a>

# Untrusted model artifact reaches executable deserialization or custom code

An attacker-controlled artifact reaches a loader whose execution trust exceeds the uploader's intended data-only authority.

**Candidate CWE:** [CWE-502](https://cwe.mitre.org/data/definitions/502.html) · [CWE-829](https://cwe.mitre.org/data/definitions/829.html)

## Test hypothesis

Trace the supported upload/import route into its actual loader. In a disposable credential-free local runtime, compare a harmless executable marker fixture with an ordinary tensor artifact and the intended rejection control.

## Evidence required

Record artifact hash, uploader rights, loader/runtime version and options, production-equivalent call path, marker side effect and isolation limitations. These CWE candidates are alternatives: CWE-502 requires unsafe deserialization; CWE-829 concerns loading functionality from an untrusted control sphere. Trace the actual loader and execution path rather than assigning both from a model filename.

## Rule out false positives

Explicitly opting into reviewed trusted repository code is a different trust contract. A risky loader name, static string, or an unsupported local loading path does not establish hosted impact.

## Playbook and command references

- [Source review: entry point to protected operation](#page-modules-source-dataflow) — Trace attacker control and authorization through handlers, services, queues, and sensitive operations; promote only reachable violations of a stated invariant.
- [OSS lab: pin, install, prove, reset](#page-modules-oss-lab-reproduction) — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
- [AI tools: input trust, execution identity and approvals](#page-modules-ai-tool-trust) — Prove when lower-trust content changes a protected tool action, then locate the missing authorization or consent boundary.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[AI, agents & MCP](#page-ai) · [OSS & self-hosted](#page-oss)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [PyTorch 2.14 serialization semantics](https://docs.pytorch.org/docs/2.14/notes/serialization.html)
- [Transformers custom model code](https://huggingface.co/docs/transformers/custom_models)
- [CWE-829 untrusted functionality](https://cwe.mitre.org/data/definitions/829.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-resource-allocation-limit-failure"></a>

# Unbounded resource allocation or request amplification

An operation consumes an unconstrained protected resource through input size, fan-out, queued work, output size or retries.

**Candidate CWE:** [CWE-770](https://cwe.mitre.org/data/definitions/770.html)

## Test hypothesis

In a faithful isolated deployment, lower a supported real limit to a tiny value and compare an accepted fixture, an at-limit case and a minimally over-limit case. Stub billed providers and count downstream jobs or operations. If no guard exists, trace the missing bound in source and a small instrumented fixture; do not attempt a live outage.

## Evidence required

Preserve the intended limit, actual configuration, actor/tenant budget key, exact input, accepted and rejected controls, committed work and cleanup. Select CWE-770 only when the cause is resource allocation without appropriate limits or throttling; distinguish an excessive-allocation request from a resource leak or unrelated slow dependency.

## Rule out false positives

A missing rate-limit header, a slow response or a few accepted requests below an unknown threshold does not prove unlimited consumption. Local amplification is not a measured production outage or bill.

## Playbook and command references

- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.
- [REST, GraphQL, gRPC, WebSocket, and SSE permission parity](#page-modules-api-protocols) — Carry the same permission invariant across protocols, nested fields, streams, and alternate API versions.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP API4:2023 resource consumption](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/)
- [CWE-770 resource allocation limits](https://cwe.mitre.org/data/definitions/770.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)


---

<a id="page-vulnerabilities-sensitive-flow-frequency-limit"></a>

# Sensitive business flow exceeds its permitted frequency or allocation

An actor exceeds an intended recipient, reservation, workflow or tenant allocation through repeated otherwise valid operations.

**Candidate CWE:** [CWE-799](https://cwe.mitre.org/data/definitions/799.html)

## Test hypothesis

Define the product rule and one synthetic recipient or allocation. In a local fixture with recording stubs, compare a permitted operation and the smallest sequence exceeding its configured limit; vary only one entry point, identity budget key, batch form or retry condition at a time.

## Evidence required

Record the intended allocation owner, all fixture identities, requests and committed effects, before/after counters and successful legitimate control. Explain the actual misuse rather than reporting missing automation friction. CWE-799 is a candidate when interaction frequency is the missing control.

## Rule out false positives

Automation, repeated valid actions, absent CAPTCHA or shared quotas may be intentional. Establish a prohibited business outcome; do not send real notifications, purchase scarce inventory or extrapolate unmeasured scale.

## Playbook and command references

- [Resource budgets and sensitive business flows](#page-modules-resource-budget-controls) — Trace request fan-out, retries, recipient limits and tenant quotas using tiny local limits, recording stubs and measured downstream effects.
- [Workflow invariants, replay, idempotency, and races](#page-modules-state-business-logic) — Find security consequences in workflow ordering and concurrency, with serial controls and durable-state evidence.

[Find the associated command snippets](#page-commands)

## Referenced by these target playbooks

[Web & API](#page-web-api) · [OSS & self-hosted](#page-oss) · [Cloud & containers](#page-cloud) · [AI, agents & MCP](#page-ai)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](#page-attack).

## Primary references

- [OWASP API6:2023 sensitive business flows](https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)
- [CWE-799 interaction frequency](https://cwe.mitre.org/data/definitions/799.html)

[Back to the complete vulnerability catalog](#page-vulnerabilities)