fix-code-vulnerability

name	fix-code-vulnerability
description	Guidance for identifying and fixing security vulnerabilities in code. This skill should be used when asked to fix security issues, address CVEs or CWEs, remediate vulnerabilities like injection attacks (SQL, command, CRLF, XSS), or when working with failing security-related tests.

Fix Code Vulnerability

Overview

This skill provides a systematic approach for identifying, analyzing, and fixing security vulnerabilities in codebases. It covers common vulnerability types (injection attacks, input validation issues, etc.) and provides verification strategies to ensure fixes are complete and correct.

Workflow

Phase 1: Initial Reconnaissance

Start by understanding the scope and nature of the vulnerability:

1. Run existing tests first - Execute the test suite to identify any failing security-related tests. Failing tests often directly indicate what vulnerability needs to be fixed and what behavior is expected.

2. Read failing tests immediately - When security tests fail, read them first before exploring the broader codebase. Tests reveal:

   • The exact vulnerability type (CWE number, attack vector)
   • Expected defensive behavior
   • Specific inputs that should be blocked
   • The API or function under test

3. Identify the vulnerability type - Classify the vulnerability:

   • CWE-89: SQL Injection
   • CWE-78: OS Command Injection
   • CWE-79: Cross-Site Scripting (XSS)
   • CWE-93: CRLF Injection (HTTP Response Splitting)
   • CWE-22: Path Traversal
   • CWE-94: Code Injection
   • CWE-611: XML External Entity (XXE)

Phase 2: Code Analysis

Trace the vulnerable code path:

1. Follow the data flow - Trace from user input to the vulnerable operation:

   • Entry points (API endpoints, form handlers, file readers)
   • Data transformation functions
   • Output points (database queries, file operations, HTTP responses)

2. Identify the fix location - Prefer fixing at centralized helper functions rather than multiple call sites:

   • Look for utility functions that process the vulnerable data
   • Fixing a shared helper covers all callers automatically
   • Avoid scattered fixes that may miss edge cases

3. Read code in larger chunks - When analyzing related functions, read them together rather than making many small reads. This provides better context for understanding the code flow.

Phase 3: Implementing the Fix

Apply the appropriate defensive measure:

1. Input validation - For injection vulnerabilities:

   • Validate against dangerous characters (e.g., \n, \r, \0 for CRLF)
   • Use allowlists when possible (define what IS allowed vs. what is NOT)
   • Raise clear error messages that identify the issue

2. Output encoding - For XSS and similar:

   • Encode output appropriate to the context (HTML, URL, JavaScript)
   • Use framework-provided encoding functions

3. Parameterization - For SQL/command injection:

   • Use parameterized queries or prepared statements
   • Avoid string concatenation with user input

4. Error handling - Ensure the fix:

   • Raises appropriate exceptions with descriptive messages
   • Does not leak sensitive information in error messages
   • Fails securely (deny by default)

Phase 4: Verification

Confirm the fix is complete:

1. Run the full test suite - All tests should pass, including:

   • The originally failing security tests
   • Existing functionality tests (ensure no regressions)

2. Verify edge cases are covered - Check that the fix handles:

   • All variations of the attack (e.g., all control characters, not just \n)
   • Both direct and indirect attack paths
   • All methods that could trigger the vulnerability

3. Create a vulnerability report - Document:

   • Vulnerability type and CWE identifier
   • Affected code locations
   • Fix description and rationale
   • Test coverage confirmation

Common Pitfalls

Avoid These Mistakes

1. Incomplete character coverage - When blocking dangerous characters, ensure all variants are covered (e.g., both \r and \n for CRLF, not just one).

2. Fixing at wrong level - Don't patch individual call sites when a centralized fix is available. Find the common helper function.

3. Missing indirect paths - A function may be called through multiple code paths. Verify the fix covers all entry points.

4. Skipping test verification - Always run tests after applying fixes. Visual inspection is insufficient.

5. Overly broad fixes - Don't break legitimate functionality. Understand what valid inputs look like before blocking patterns.

Attack Scenarios to Consider

When fixing vulnerabilities, understand the attack:

• CRLF Injection (CWE-93): Attacker injects \r\n to split HTTP headers, enabling response splitting attacks
• SQL Injection (CWE-89): Attacker escapes string context to execute arbitrary SQL
• Command Injection (CWE-78): Attacker uses shell metacharacters to execute system commands
• Path Traversal (CWE-22): Attacker uses ../ sequences to access files outside intended directory

Process Efficiency Tips

1. Start with tests - Running tests first immediately reveals which security checks are failing and what behavior is expected.

2. Read tests before code - Security tests describe the vulnerability and expected fix more clearly than searching the codebase.

3. Fix centralized functions - Identify and fix shared helper functions to cover all code paths with minimal changes.

4. Verify once, comprehensively - Run the full test suite rather than individual tests to catch any regressions.

5. Document the vulnerability - Create a report that explains the vulnerability type, fix applied, and verification performed.