OBJECTIVE: Perform a security-focused code review to identify HIGH-CONFIDENCE security vulnerabilities that could have real exploitation potential. This is not a general code review - focus ONLY on security implications.

CRITICAL INSTRUCTIONS:

1. MINIMIZE FALSE POSITIVES: Only flag issues where you're >80% confident of actual exploitability
2. AVOID NOISE: Skip theoretical issues, style concerns, or low-impact findings
3. FOCUS ON IMPACT: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise
4. EXCLUSIONS: Do NOT report the following issue types:
   • Denial of Service (DOS) vulnerabilities, even if they allow service disruption
   • Secrets or sensitive data stored on disk (these are handled by other processes)
   • Rate limiting or resource exhaustion issues

SECURITY CATEGORIES TO EXAMINE:

Input Validation Vulnerabilities:

• SQL injection via unsanitized user input
• Command injection in system calls or subprocesses
• XXE injection in XML parsing
• Template injection in templating engines
• NoSQL injection in database queries
• Path traversal in file operations

Authentication & Authorization Issues:

• Authentication bypass logic
• Privilege escalation paths
• Session management flaws
• JWT token vulnerabilities
• Authorization logic bypasses

Crypto & Secrets Management:

• Hardcoded API keys, passwords, or tokens
• Weak cryptographic algorithms or implementations
• Improper key storage or management
• Cryptographic randomness issues
• Certificate validation bypasses

Injection & Code Execution:

• Remote code execution via deseralization
• Pickle injection in Python
• YAML deserialization vulnerabilities
• Eval injection in dynamic code execution
• XSS vulnerabilities in web applications (reflected, stored, DOM-based)

Data Exposure:

• Sensitive data logging or storage
• PII handling violations
• API endpoint data leakage
• Debug information exposure Additional notes:
• Even if something is only exploitable from the local network, it can still be a HIGH severity issue

ANALYSIS METHODOLOGY:

Phase 1 - Repository Context Research (Use file search tools):

• Identify existing security frameworks and libraries in use
• Look for established secure coding patterns in the codebase
• Examine existing sanitization and validation patterns
• Understand the project's security model and threat model

Phase 2 - Comparative Analysis:

• Compare new code changes against existing security patterns
• Identify deviations from established secure practices
• Look for inconsistent security implementations
• Flag code that introduces new attack surfaces

Phase 3 - Vulnerability Assessment:

• Examine each modified file for security implications
• Trace data flow from user inputs to sensitive operations
• Look for privilege boundaries being crossed unsafely
• Identify injection points and unsafe deserialization

SEVERITY GUIDELINES:

• HIGH: Directly exploitable vulnerabilities leading to RCE, data breach, or authentication bypass
• MEDIUM: Vulnerabilities requiring specific conditions but with significant impact
• LOW: Defense-in-depth issues or lower-impact vulnerabilities

CONFIDENCE SCORING:

• 0.9-1.0: Certain exploit path identified, tested if possible
• 0.8-0.9: Clear vulnerability pattern with known exploitation methods
• 0.7-0.8: Suspicious pattern requiring specific conditions to exploit
• Below 0.7: Don't report (too speculative)

FINAL REMINDER: Focus on HIGH and MEDIUM findings only. Better to miss some theoretical issues than flood the report with false positives. Each finding should be something a security engineer would confidently raise in a PR review.

IMPORTANT EXCLUSIONS - DO NOT REPORT:

• Denial of Service (DOS) vulnerabilities or resource exhaustion attacks
• Secrets/credentials stored on disk (these are managed separately)
• Rate limiting concerns or service overload scenarios. Services do not need to implement rate limiting.
• Memory consumption or CPU exhaustion issues.
• Lack of input validation on non-security-critical fields. If there isn't a proven problem from a lack of input validation, don't report it.

Begin your analysis now. Use the repository exploration tools to understand the codebase context, then analyze the PR changes for security implications.