GPT-5.6 Pro Security Review Prompt

security-review.md

Audit the provided repository as an exploit-minded security engineer.

Your goal is to find real, reachable vulnerabilities—not style issues, generic hardening advice, or dependency advisories without a credible execution path.

Prioritize defects that can plausibly cause:

• Remote code execution
• Privilege escalation
• Authentication or authorization bypass
• Cross-tenant access
• Persistent account takeover
• SSRF
• SQL, command, template, or other injection
• Path traversal or arbitrary file access
• Sandbox escape
• Secret disclosure
• Supply-chain compromise
• Reliable denial of service

Treat every external boundary as hostile: requests, routes, actions, RPC methods, webhooks, queues, uploads, parsers, configuration, environment variables, database records, caches, storage metadata, third-party responses, CLI input, local files, redirects, protocol messages, and downloaded artifacts.

Operate only against the repository and authorized local or test environments. Avoid destructive testing against shared systems. Redact live secrets from all output.

PARALLEL EXECUTION

Use subagents aggressively when available.

Keep exactly six active while six independent, high-value workstreams remain. Close completed or stalled threads immediately and replace them with the next highest-value task.

Start with:

1. Attack-surface, architecture, and trust-boundary mapping
2. Authentication, authorization, object ownership, and tenant isolation
3. Injection, SSRF, filesystem, upload, archive, parser, and subprocess risks
4. Framework, routing, middleware, caching, rendering, and server/client boundaries
5. CLI, SDK, agent, local-state, update, and client-server protocol security
6. Dependencies, build system, CI, release process, deployment, and runtime hardening

Continuously redirect effort toward the most suspicious and highest-impact surfaces.

STACK DISCOVERY

Do not assume the language, framework, database, authentication system, package manager, runtime, router, transport, or deployment model.

Identify:

• Languages, frameworks, versions, runtimes, and build tools
• Public and internal entry points
• Authentication and session mechanisms
• Authorization and tenant models
• Databases, caches, queues, object storage, and background jobs
• External services and privileged SDKs
• CLIs, clients, agents, plugins, and update mechanisms
• CI, containers, infrastructure definitions, and deployment assumptions

Trace attacker-controlled data across trust boundaries until it reaches sensitive operations.

Distinguish security controls enforced by trusted server or privileged code from checks that exist only in UI state, client logic, middleware, schemas, types, documentation, or official-client behavior.

EXECUTION PROCESS

Build and run the repository from a clean state.

Use production or release builds where possible. Run existing tests, then enable stricter compiler, linter, race, sanitizer, and runtime checks supported by the detected stack.

Inspect generated and packaged output, including route manifests, API schemas, client bundles, source maps, generated clients, binaries, archives, container layers, and deployment artifacts.

Run suitable security tooling for the detected stack, including:

• Strict compilation and linting
• Security-focused static analysis
• CodeQL and Semgrep where supported
• Dependency and reachability analysis
• Secret scanning
• Container and infrastructure scanning
• Race detection and sanitizers
• Coverage-guided fuzzing and property-based testing

Write repository-specific static-analysis queries when broad rules miss important abstractions.

Do not claim a tool or check ran unless it completed successfully. Record failures and coverage gaps.

CORE REVIEW

Inspect every reachable route, action, handler, resolver, RPC method, webhook, message consumer, background job, command, plugin interface, and update path.

For each sensitive operation, verify:

• Authentication is required at the trusted boundary
• Authorization covers the exact object and function
• Tenant or ownership constraints reach the persistence layer
• Client-controlled identity, role, scope, owner, or tenant fields are rejected
• Validation and normalization occur before security decisions
• Side effects are protected against replay and duplicate execution
• Resource use is bounded
• Errors, logs, caches, and serialized responses do not disclose secrets

Hunt specifically for:

• IDOR and broken object-level authorization
• Broken function-level authorization
• Cross-tenant reads, writes, cache hits, exports, jobs, or storage access
• Session fixation, token substitution, replay, weak reset or invitation flows
• Missing token issuer, audience, expiry, nonce, state, or scope validation
• CSRF, login CSRF, open redirects, host-header poisoning, and origin confusion
• Middleware or route-matcher bypass
• User-specific data stored in shared caches or static output
• Secrets entering public bundles, source maps, logs, URLs, telemetry, or errors
• Unsafe dynamic queries, commands, templates, expressions, or property access
• SSRF through URLs, redirects, DNS behavior, proxies, or alternate address forms
• Path traversal, symlink abuse, archive escape, arbitrary overwrite, and unsafe temporary files
• Unsafe deserialization, parser differentials, schema coercion, and mass assignment
• Stored, reflected, or client-side script injection
• Terminal, log, CSV, formula, or downstream-parser injection
• Unbounded request bodies, pagination, decompression, nesting, recursion, regexes, retries, concurrency, or fan-out
• Race conditions, stale authorization, TOCTOU, duplicate execution, and partial writes
• Weak TLS handling, unsafe endpoint overrides, unsigned updates, or malicious-server behavior
• Build-script execution, dependency confusion, mutable dependencies, unsafe CI triggers, and release artifact substitution

FRAMEWORK AND RUNTIME BOUNDARIES

Treat routing, middleware, caching, rendering, serialization, and generated artifacts as security boundaries.

Test alternate methods and path representations, including encoded separators, duplicated parameters, trailing separators, Unicode normalization, rewrites, redirects, base paths, locale handling, internal headers, and proxy-derived headers.

Verify middleware is not the sole enforcement point for sensitive operations.

Review cache keys and static-generation behavior for omitted user, role, tenant, cookie, authorization, locale, query, or feature-state inputs.

Confirm privileged modules, credentials, environment variables, and server-only objects cannot reach client-visible output through imports, serialization, bundles, source maps, generated schemas, or error responses.

FILESYSTEM, NETWORK, AND EXECUTION SINKS

Trace attacker-controlled values into:

• Database and search queries
• Subprocesses and shells
• Dynamic code or template execution
• HTTP clients and URL fetchers
• Filesystem paths
• Archive extraction
• Upload processing
• Object-storage keys
• Native interfaces
• Plugin or module loading
• Update installation

Test normalization and parser differences between validation and execution.

For URL fetches, test redirects, private and link-local addresses, alternate IP forms, IPv6, embedded credentials, proxy inheritance, DNS rebinding, metadata services, and discrepancies between hostname checks and connection behavior.

For filesystem operations, test traversal, absolute paths, platform-specific separators, symlinks, hard links, race conditions, archive entries, case collisions, duplicate names, and writes outside the intended root.

For subprocesses, inspect shell use, argument injection, option injection, executable selection, environment inheritance, working-directory control, and attacker-controlled filenames interpreted as flags.

CLIENTS AND PROTOCOLS

Treat official clients as untrusted from the server’s perspective. Treat remote servers as hostile from the client’s perspective.

Attempt:

• Resource, tenant, role, and scope substitution
• Replay and version downgrade
• Malformed pagination and partial responses
• Duplicate requests and retry inconsistencies
• Cancellation races and state desynchronization
• Malformed, oversized, compressed, or infinite responses

Review endpoint discovery, proxies, redirects, TLS, token storage, configuration precedence, environment variables, stdin and terminal output, downloaded files, archive extraction, plugins, local permissions, temporary files, atomic writes, and update verification.

Determine whether a malicious server can read or overwrite arbitrary local files, execute commands, steal unrelated credentials, inject terminal control sequences, alter persistent configuration, replace executables, or compromise the update path.

FUZZING

Discover high-risk parsers and protocol boundaries automatically. Create harnesses without waiting for permission.

Prioritize:

• Authentication tokens and cookies
• Structured request bodies
• Multipart and uploads
• URLs and redirects
• Webhooks and RPC messages
• Configuration formats
• Archives and file formats
• Markup, templates, and search syntax
• Import and export formats
• Client protocol decoders
• Update manifests
• Any transformation from untrusted bytes into trusted state

Seed fuzzers from tests, fixtures, schemas, documentation, generated clients, sample requests, and valid minimal inputs.

Test empty, missing, duplicated, truncated, deeply nested, oversized, compressed, malformed, non-canonical, and concurrency-sensitive inputs.

Use explicit security invariants, such as:

• No crash or panic
• No unbounded CPU, memory, disk, connection, or thread growth
• No path escape
• No unauthorized state change
• No cross-tenant result
• No secret in output
• No unexpected network request
• No write outside the intended directory
• No duplicate irreversible action

Minimize failures, deduplicate root causes, preserve triggering inputs, and convert confirmed failures into deterministic regression tests.

VALIDATION STANDARD

Bias toward proof.

For every finding, establish:

• Exact file and line range
• Reachable entry point
• Attacker-controlled value
• Validation and authorization path
• Sensitive sink or security decision
• Triggering request, payload, command, file, or race
• Attack prerequisites
• Observed result
• Security impact
• Exploit limitations
• Discovery method
• Fix direction
• Regression-test strategy

Use minimal reproducible requests, commands, payloads, fuzz cases, or test harnesses.

Separate confirmed vulnerabilities from strong suspects.

A confirmed vulnerability requires a reproducible execution path and demonstrated security impact or exploit primitive.

A strong suspect requires concrete code evidence and a precisely identified missing runtime fact. State the missing link directly.

Deduplicate findings by root cause. Include secondary affected paths under the primary issue.

Do not report:

• Cosmetic or maintainability issues
• Generic missing controls without a reachable attack path
• Advisory lists without demonstrated dependency reachability
• Hypothetical vulnerabilities unsupported by code or runtime evidence
• Type or validation improvements with no security consequence

FINAL DELIVERABLE

Begin with a terse executive summary covering:

• Overall risk
• Most severe confirmed vulnerabilities
• Viable exploit chains
• Affected users, tenants, systems, or privilege levels
• Highest-confidence unresolved suspects

Then provide a ranked findings table with:

• ID
• Severity
• Confidence
• Bug class
• Exploitability
• Affected surface
• File and line range
• Trigger
• Evidence
• Impact
• Preconditions
• Fix direction

For each confirmed finding, include:

• Vulnerable execution path
• Root cause
• Minimal reproducer
• Observed result
• Impact
• Affected configurations
• Exploit constraints
• Discovery method
• Regression test

Include concise coverage sections for:

• Architecture and trust boundaries
• Routes, handlers, actions, RPC methods, and message consumers
• Authentication, authorization, and tenant isolation
• Framework, caching, rendering, and server/client boundaries
• Clients, CLIs, agents, and protocols
• Parsers, uploads, archives, storage, and filesystem operations
• Fuzzing and property testing
• Runtime, race, and sanitizer testing
• Static analysis
• Dependency and supply-chain reachability
• CI, deployment, and runtime hardening

State exactly what was built, run, scanned, fuzzed, instrumented, and manually reviewed. Include commands and relevant tool versions.

State what remains unexercised, why it remains unexercised, and the next highest-value targets.

Include only high-signal findings. Be direct, evidence-driven, adversarial, and exhaustive.