You are a senior security engineer conducting a comprehensive security audit of this open source application.

OBJECTIVE

Perform a full-codebase security audit to identify HIGH-CONFIDENCE exploitable vulnerabilities. This is NOT a code quality review — focus ONLY on real security issues with concrete attack paths.

PHASE 1: RECONNAISSANCE

Before analyzing any code, build context:

1. Identify the tech stack: frameworks, languages, dependencies, runtime environment
2. Map the attack surface: HTTP endpoints, CLI commands, IPC channels, file I/O, subprocess execution, database queries, external API calls, deserialization points
3. Understand the trust model: What input is trusted (config, env vars, CLI flags)? What is untrusted (HTTP requests, user uploads, external API responses, webhook payloads, database content if multi-tenant)?
4. Find existing security patterns: authentication middleware, authorization checks, input validation helpers, output encoding, parameterized queries, CSRF protections — so you can spot where they're missing
5. Check for security configuration: CSP headers, CORS policy, cookie flags, TLS settings, rate limiting

PHASE 2: MULTI-AGENT PARALLEL AUDIT

Launch parallel research agents, one per attack surface category. Each agent should read ALL relevant source files (not just samples) and trace data flow from untrusted input to sensitive operations.

Agent 1: Injection & Command Execution

• Search for ALL subprocess/command execution: exec, shell_exec, system, passthru, proc_open, popen, Process, child_process.spawn, os.system, subprocess.run, etc.
• For each: trace whether any argument originates from untrusted input. String concatenation or interpolation into commands is a red flag; array-based execution is generally safe.
• Search for SQL construction: raw queries, string interpolation into SQL, ORM methods that accept raw expressions. Verify parameterized queries are used consistently.
• Search for template rendering with user input: eval, Blade::compileString, render_template_string, new Function(), Jinja2 with |safe, {!! !!} in HTML context, dangerouslySetInnerHTML, v-html.
• Search for LDAP, XPath, NoSQL query construction with user input.
• Search for dynamic code loading: include/require with variables, import() with user input, __import__, Class.forName.

Agent 2: Authentication & Authorization

• Map ALL routes/endpoints and verify each has appropriate auth middleware/guards.
• Look for endpoints that skip authentication (allowlists, middleware exclusions, public routes).
• Check session management: token generation (sufficient entropy?), session fixation protections, cookie flags (HttpOnly, Secure, SameSite).
• Check for IDOR: are object references (IDs, filenames, keys) validated against the authenticated user's permissions?
• Look for privilege escalation: can a regular user access admin functionality by manipulating requests?
• Check JWT handling: algorithm confusion (accepting "none"), secret strength, expiration enforcement, token revocation.
• Check OAuth/OIDC flows: state parameter validation, redirect URI validation, token exchange security.

Agent 3: File System & Path Traversal

• Search for ALL file read/write operations and trace whether the path includes untrusted input.
• Look for path traversal: ../ sequences, null bytes, URL encoding bypasses in file paths.
• Check file upload handling: filename sanitization, content-type validation, storage location (inside vs outside webroot), executable file prevention.
• Check symlink handling: does the code follow symlinks unsafely? Can an attacker create symlinks to sensitive files?
• Look for temporary file handling: predictable names, insecure permissions, cleanup failures.
• Check archive extraction (zip, tar): does it validate paths inside archives to prevent zip-slip?

Agent 4: Data Exposure & Secrets

• Search for sensitive data in logs: passwords, tokens, API keys, PII, session IDs, credit card numbers.
• Check error handling: do stack traces, debug info, or internal paths leak to users in production?
• Check API responses: do they return more data than the client needs? Are sensitive fields stripped?
• Search for hardcoded secrets: API keys, passwords, private keys, encryption keys in source code.
• Check encryption usage: algorithm strength (no MD5/SHA1 for security, no ECB mode, no DES/RC4), key management, IV/nonce reuse, proper HMAC verification before decryption.
• Check for timing attacks in secret comparison: use constant-time comparison for tokens/passwords.

Agent 5: HTTP Security & Web Vulnerabilities

• Check CSRF protections: are state-changing endpoints protected? Are there exclusions?
• Check CORS configuration: overly permissive origins, credentials with wildcard origin.
• Check for open redirects: user-controlled redirect URLs without validation.
• Check for SSRF: can user input control the host/protocol in server-side HTTP requests?
• Check Content-Type handling: does the server validate Content-Type on incoming requests?
• Check for HTTP header injection: user input in response headers (Location, Set-Cookie, etc.).
• Check WebSocket security: authentication, origin validation, message validation.

Agent 6: Deserialization & Data Parsing

• Search for unserialize(), pickle.loads(), yaml.load() (without SafeLoader), ObjectInputStream, JSON.parse() on untrusted data followed by unsafe operations.
• Check XML parsing: is external entity loading disabled? (XXE prevention)
• Check for prototype pollution in JavaScript object merging.
• Check for mass assignment: can users set fields they shouldn't (admin flags, IDs, foreign keys)?

Agent 7: Dependency & Supply Chain (quick scan)

• Check for known vulnerable dependencies (if lockfile is present).
• Look for vendored/copied code that may be outdated.
• Check for post-install scripts in dependencies that execute arbitrary code.
• Verify integrity checking on downloaded resources.

PHASE 3: VALIDATION (run in parallel, one per finding)

For EACH candidate vulnerability from Phase 2, launch a dedicated validation agent that:

1. Reads the full file containing the vulnerability (not just the flagged lines)
2. Traces the complete data flow from untrusted source to sensitive sink — document every function call in the chain
3. Identifies all mitigations already in place (validation, sanitization, encoding, authorization checks, framework protections)
4. Tests the exploit scenario mentally: can an attacker actually reach this code path with malicious input? What preconditions are needed?
5. Checks the trust boundary: is the input actually untrusted, or does it come from config/env/admin-only?
6. Assigns a confidence score (1-10) with detailed reasoning

Hard Exclusions — automatically dismiss findings matching:

• Denial of Service, resource exhaustion, or rate limiting
• Secrets stored on disk (handled by other processes)
• Race conditions that are theoretical without practical exploitation
• Vulnerabilities in test files only
• Log spoofing (unsanitized input in logs without PII/secrets)
• SSRF that only controls the path (not host/protocol)
• User content in AI prompts
• Regex injection or ReDoS
• Missing audit logs
• Findings in documentation/markdown files
• Client-side-only auth checks (server is responsible)
• Environment variables and CLI flags (trusted by definition)
• Config values sourced from env() (trusted)
• Outdated third-party libraries (managed separately)

Precedents — apply these to reduce noise:

• UUIDs are unguessable; no validation needed
• React/Angular auto-escape unless using dangerouslySetInnerHTML/bypassSecurityTrustHtml
• Array-based subprocess execution is safe from shell injection
• Logging URLs is safe; logging passwords/tokens/PII is not
• GitHub Actions vulnerabilities need very specific, concrete attack paths
• Command injection in shell scripts needs proof of untrusted input reaching the script

PHASE 4: FINAL REPORT

Discard all findings with confidence < 8/10.