# Repository-Wide High-Impact Families

Use this reference with `repository-wide-scan.md` for family-specific repository-wide security review.

## General Family Rules

- Run one frontier pass across every applicable high-impact shard before prolonged validation or build work on any single shard.
- Continue fan-out from a validated high-impact sink pattern to sibling routes, templates, handlers, models, and config files until that high-impact surface is exhausted.
- Do not merge distinct high-impact sink or impact families into one finding solely because they share a route, wrapper, or helper. For example, command execution, SSRF, path traversal/file write, XML parser behavior, and authorization bypass in the same flow should remain separate when they have distinct sinks, controls, or impacts.
- Treat data exposure, hardcoded secrets, weak session/cookie flags, CSRF, rate limits, and generic security configuration as secondary unless they directly enable code execution, injection, privilege escalation, meaningful auth bypass, or sensitive cross-boundary impact.
- For each suppressed or safe-looking nearby path, record exact counterevidence. Suppression must be per-instance, not per-family.

## Fan-Out Families

- RCE and injection: shell/process calls, Python/Ruby/JS eval or exec, dynamic imports, template execution, recursive placeholder/template expansion, SQL/NoSQL/LDAP/XPath queries, header injection, and expression-language sinks.
- For command/action runner RCE, enumerate argument type validators and execution modes as separate shards: UI widgets, webhook/API argument ingestion, type-safety maps, unsafe-type denylists, template rendering, shell wrapping, and direct exec. Do not suppress shell injection because one mode uses direct exec or because some unsafe types are blocked; nil/no-op validators for `password`, `checkbox`, `confirmation`, choice-like, or custom argument types remain root controls when their values can render into a shell command.
- Unsafe parsing and execution: pickle/yaml/xml/deserializer sinks, XXE, SSTI, template/source rendering, upload processors, and archive/file extraction.
- Server-side request and file impact: SSRF, callback fetches, path traversal, arbitrary file read/write/delete, unsafe file upload, open redirect with callback or credential impact.
- For SSRF and callback-fetch families, split `downloadFrom`, URL import, webhook, callback, preview/render, redirect-following, and metadata/cloud/LAN destination controls into separate shards. Intended outbound-fetch functionality, optional operator allow/deny lists, empty default filters, and pre-request-only checks are not suppression evidence; preserve the row until the exact destination parser, redirect policy, scheme/host/IP canonicalization, and final network sink are proven to enforce the boundary.
- Privilege and boundary impact: missing authentication, missing authorization, IDOR/BOLA, tenant/object isolation, token/assertion/federation validation, protocol/version gating, and mass assignment when they expose protected objects or privileged state changes.
- Platform/agent impact: reachable vulnerable dependencies, IaC/Kubernetes exposure/RBAC that enables privilege or data-boundary impact, MCP/agent untrusted content to privileged tool/action paths.

## Parser, Protocol, And File Format

- For parser, protocol, and file-format packages, inventory the operation/helper classes in that boundary package before broad keyword sweeps. Searches may seed the review, but the boundary package should be checked as a unit so a shared helper or operation class is not replaced by an adjacent caller-only finding.
- For each parser/helper, deserializer, auth/token/assertion, protocol/version, and polymorphic-operation shard, run targeted control-hazard searches inside the boundary package before finalizing the shard. Use repository-appropriate patterns; examples include subclass/override declarations, concrete codec/converter/input-handler/validator/filter/guard/resolver classes, `super.` calls, `split`, `parse`, `parseInt`, `matches`, `find`, `startsWith`, `equals`, `URL`, `URI`, `get(0)`, `cloneNode`, `registerConverter`, deny/allow lists, and validator/comparator method pairs.
- Every matching root-control line that is in a reachable boundary package must be closed in the ledger as reportable, suppressed with exact counterevidence, or deferred.
- For file-format object models such as PDF/COS, XML/DOM, YAML nodes, archive entries, protobuf/message fields, image/font tables, or binary protocol records, run a primitive-helper sweep over array, dictionary, node, token, numeric, and iterator helpers before closing the parser shard. Search method shapes such as `to*Array`, `get*`, `getObject`, `toFloat`, `toInt`, `parse*`, `iterator`, `size`, unchecked casts, and loops over attacker-controlled collection sizes; these helpers are root controls when they convert, cast, recurse, or allocate from untrusted document structure.
- When ranking or deep review identifies a central first-party object-model package for an untrusted file or message format, the coverage ledger must contain rows for that package's array, dictionary, node, collection, and primitive conversion helpers before the parser shard can close.
- Object-model helper sweeps create mandatory coverage rows first, not automatic findings. Promote a helper row only when malformed or adversarial input can plausibly reach the helper and the missing type, size, shape, recursion, numeric, or conversion guard can cause crash, denial of service, parser confusion, authorization bypass, or another concrete security impact.
- Deterministic malformed-input crashes are security-relevant when untrusted remote, protocol, document, archive, or package input reaches a missing parser/helper guard and can abort a service, request worker, parser pipeline, or security negotiation. Do not suppress these as generic robustness unless exact containment evidence shows caller-side recovery, equivalent prevalidation, or a non-security-only boundary for that instance.
- For advisory, release-note, or security-test seeded parser/file-format DoS rows, a bespoke runtime harness is not always required when checked-out code plus existing tests or deterministic code reasoning make the untrusted source, broken helper control, and impact directly evident. Record a missing harness as a confidence limit; otherwise keep the row deferred rather than substituting seed text for local proof.
- For XML/parser/deserializer review, enumerate each exposed parser factory, converter, validator, transformer, unmarshal, parse, and handler entrypoint separately. A hardened sibling parser is useful negative control, but it does not suppress a different default factory or converter path.
- XML parser hardening is complete only when the parser fails closed or every needed feature/resolver is enforced on the exact parser instance used by the sink. Swallowed, logged, or best-effort `setFeature` failures, custom caller-supplied parser factories/readers, and `FEATURE_SECURE_PROCESSING` without entity/DTD controls are not suppression evidence for XXE or XML parser injection.

## Polymorphic Operations And Deserialization

- For polymorphic handlers, operation classes, converters, filters, validators, or strategy objects, fan out across subclasses and overrides in the boundary package before finalizing. If an override or request-selected concrete operation transforms, validates, canonicalizes, selects, or reinterprets attacker input before a shared sink/control, keep that concrete implementation line addressable alongside the shared sink/control.
- For structured patch/edit/apply APIs such as JSON Patch, Graph Patch, document edits, or config mutations, enumerate concrete operations like add, remove, replace, move, copy, and test; operation-specific path transforms or special cases such as array append or wildcard selection are root controls when they feed the shared evaluator or object binder.
- When a concrete operation has a branch-specific path such as append, wildcard, fallback, copy/move `from`, default-value, or type-resolution handling, preserve the branch predicate and branch-local transform as root-control evidence if that branch bypasses, narrows, or feeds the shared validator differently from the common path.
- After finding a shared parser, deserializer, template, or auth control, run a boundary-package root-control sweep over concrete codecs, converters, input handlers, validators, guards, filters, allow/deny resolvers, class filters, and operation subclasses before closing the shard.
- For deserialization and object-construction review, identify the repository's serializer/deserializer wrapper, converter registry, allow/deny controls, and default loader behavior before scanning scattered callsites. Preserve the wrapper/control line when it implements the broken security behavior.
- For parser/deserializer registries, enumerate concrete codec, converter, deserializer, and container handlers registered for arrays, collections, maps, beans, enums, throwables, and generic object values. Array or container codecs are root controls when they recursively invoke parsing, type resolution, conversion, object construction, or unbounded traversal on attacker-controlled structures.
- Global serializer/deserializer wrappers and deny/allow controls are themselves high-impact control points when they protect multiple config, import, plugin, remoting, or persisted-state paths. Do not suppress a broken shared loader/control solely because one observed caller requires permission; validate whether the wrapper is reused from another attacker-controlled, privilege-bearing, or cross-boundary path, and carry unresolved wrapper risk forward with explicit confidence/preconditions.
- In deserializer wrapper initialization, treat missing or misordered deny/allow entries, converter priorities, default reflection converters, class-loader selection, and type-tag handling as root controls when the wrapper can construct attacker-named or stored cross-boundary types.
- Class-resolution controls such as class filters, allowlists, denylists, blacklists, whitelists, and resolver predicates are primary affected controls when any deserialization, remoting, plugin, import, or stored-state path reaches them. A transport finding may prove reachability, but it should not replace the shared resolver/control line.

## Query, Template, Resource, And Auth Controls

- For query builders and database APIs, treat attacker control over query syntax as the security boundary. Do not suppress SQL, NoSQL, LDAP, XPath, or similar injection solely because the endpoint already accepts some user-controlled data, because the immediate operation is an insert/update, or because a later business check appears to limit the visible effect.
- First test or reason through quote/comment/boolean/union/operator/multi-statement variants, parser errors, row-set changes, write amplification, and whether the later guard is checking the same trusted object. If input can alter query structure or selector semantics, keep the instance as a validation candidate with any limiting preconditions, and promote it to a reportable finding only if validation confirms semantic change or a bypassable post-query guard for that exact instance.
- For template and placeholder engines, trace both the static template string and values resolved into the template. Recursive placeholder expansion, expression evaluation of placeholder names, helper/parser setup that enables recursive expansion, or re-parsing of resolved model/client/error values is a candidate injection sink when those values can come from request parameters, tenant/client metadata, stored configuration, exception messages, or other cross-boundary state.
- In framework or library code, stored client/application/tenant metadata, identity-provider attributes, externally supplied error descriptions, and imported configuration are cross-boundary values when the component later renders, evaluates, binds, or authorizes with them and the instance has a plausible runtime path from an application, tenant, identity provider, import, or other boundary.
- For resource-serving and static-file handlers, treat allowlist, path-matcher, canonicalization, URL decoding, and resource-selection lines as root controls. Do not replace a vulnerable legacy/deprecated handler or package API with a newer safe sibling handler; close each deployed or exported resource handler separately when path traversal or arbitrary file access is in scope.
- For filesystem-impact families, also sweep restore/import/export paths, backup/restore helpers, archive extraction and archive entry selection, file copy/move helpers, key/config download helpers, and temp-file promotion paths. Keep branch-local decode, join, strip-prefix, extension, canonicalization, and destination-selection lines addressable for each exported operation.
- For file-manager, theme/builder/media, asset, plugin-marketplace, and export/download controllers, treat request-supplied filenames, asset paths, theme names, package names, and builder resource ids as independent file-impact shards. Search route clusters around `FileManager`, `Theme`, `Builder`, `Asset`, `Marketplace`, `Package`, `download`, `zip`, `extract`, `filename`, `path`, and `allow_forward_slash`; do not close a seeded file-manager traversal because a neighboring theme/export traversal, SSRF, or package-install finding was reported.
- Shared path or parameter sanitizers that allow slashes, raw filenames, decoded paths, or optional canonicalization are root controls. When one controller calls `sanitize_params(... allow_forward_slash: true)` or equivalent, enumerate sibling services/controllers using the same helper before suppressing path traversal in a different API namespace.
- For base-controller or shared helpers named like sanitize_params, sanitize_path, clean_path, or safe_path, a boolean such as allow_forward_slash, allow_absolute_path, allow_path, or preserve_slashes is itself a root path-control shard. If request parameters later select config, script, target, plugin, storage, import/export, or file-manager resources, report the helper definition plus representative callers as a path traversal or arbitrary file-access finding; do not suppress it merely because the helper name sounds safe or because other storage/authz findings in the same subsystem are louder.
- For archive extraction and restore/import flows, the root control is the member-path containment proof before each filesystem write. If untrusted archive member names reach `extract`, `extractall`, tar extraction, temp-file materialization, or equivalent writes before exact containment validation, keep the row open even when later code only imports selected top-level files, copies into an approved root, or gates on UUID/manifest checks. Do not suppress with generic claims about standard-library safety; exact closure must reason through per-entry containment and any symlink, hardlink, metadata, or recursive-copy behavior that could still materialize attacker-controlled content inside an imported subtree. Escape outside the overall app/datastore root is not required; writes into trusted config files, peer-object directories, shared roots, or imported subtrees inside that root are still high-impact file writes.
- Treat archive-member decode, strip-prefix, and replacement filters such as removing `../` as root controls, not as proof of safety. Absolute paths, drive-prefixed paths, encoded separators, symlink or hardlink entries, and parser-preserved member names need exact containment proof before the write; a static trace from upload/package parsing to member write can keep the row alive with calibrated confidence when optional parser runtime is unavailable.
- If the same subsystem has both a file-impact row and an auth, secret, or config row, preserve both shards. A louder auth bypass or data-exposure issue is not suppression evidence for the path/file row unless it closes the same operation and control.
- In framework or library scans, deprecated, opt-in, or documented-dangerous APIs are still in-scope runtime surfaces when the repository ships them for downstream applications and the instance has a plausible cross-boundary source and runtime/deployment path. Treat deprecation/docs as reachability or deployment preconditions, not suppression evidence.
- For auth, token, assertion, federation, protocol, and version-gating controls, inspect the validator/control package before suppressing nearby candidates. Treat object-binding mistakes, partial string/prefix checks, URL/URI or host canonicalization hazards, regex match-vs-find mistakes, numeric/version parsing without complete validation, and validated-object vs consumed-object mismatches as first-class high-impact control failures when they cross an authentication, authorization, protocol, or trust boundary. For route-level auth, verify the exact global middleware and route-local decorator semantics; login-named, admin-looking, or restore/import endpoints remain anonymous attack surfaces when the wrapper is optional or only enforces auth after password/token config is enabled.
- In Java code, treat `URL.equals` and URL host equality as suspicious in issuer/callback/host security checks until canonicalization behavior is proven safe; prefer exact string/URI comparison rules from the protocol.
- In SSO/SAML/federation packages, keep response/assertion validators, claims authorizers, and generic method-authorization interceptors as separate shards. A generic authz or claims finding does not close a SAML SSO response validator row.
- For response validators, inspect assertion selection, list indexing, cloned DOM nodes, `getDOM`, `cloneNode`, signed-object lookup, subject confirmation, recipient, audience, destination, ACS URL, and issuer binding; preserve the exact line that chooses or returns the consumed assertion.
- If validator code iterates through candidate assertions/tokens/identities and sets a `foundValid*` flag, then later consumes a fixed-index, first/last, cloned, serialized, or separately looked-up object, keep that later selection as a candidate even when the loop itself contains strong checks.
- For auth/authz review, enumerate public or anonymous webhook/status/API endpoints that read protected objects, trigger jobs/builds, or mutate protected state separately from nearby credential-helper or configuration findings. When session, API-key, token, tenant, or identity parsing lets attacker-controlled input choose or misbind the consumed identity/object, carry both the root parser/control line and the protected object endpoint, and label the instance as authz/BOLA/IDOR when it controls object access.
- Keep external login/account-binding, self-service profile or SCIM update guards, invitation/password-reset flows, token/session validators, and protected object authorization as separate auth shards.
- For stateful authentication protocols such as LDAP, Kerberos, SAML, OAuth/OIDC, TLS-upgraded binds, and delegated identity providers, inspect the sequence that transitions from unauthenticated or pre-upgrade state to credentialed identity. Treat credential/principal/token installation, bind/reauthentication calls, issuer assignment, and validated-vs-consumed object selection as root controls when a missing rebinding or incomplete state check can authenticate the wrong identity.
- For self-service user, account, tenant, profile, SCIM, or settings update endpoints, inspect the guard or expression method that authorizes the update as a root control. Search route-adjacent predicates and helpers named like self, update, profile, allowed, guard, or policy, then compare attacker-provided request-body objects against the persisted object. Check immutable or security-sensitive scalar and collection aliases such as primary email versus email list, username, verified, active/disabled, origin/provider, tenant/zone, roles/groups, MFA state, and identifiers.
- For protocol/version gates, look for paired validator and parser/comparator helpers. If the parser/comparator splits or parses attacker-controlled protocol metadata without invoking the complete validator or enforcing equivalent bounds, keep that line as the broken control and validate protocol-security impact before suppressing it as mere input hygiene.
- In protocol-heavy repositories, include low-level version, capability, feature, and negotiation utility classes in the ledger even when the obvious findings are in web upload, REST, or admin surfaces.
