# hackenproof-fix-verifier Verify that a security fix actually addresses the reported vulnerability without introducing new issues. Works with any local codebase — no MCP or bug bounty platform required. Trigger on "verify fix", "check fix", "is this fix correct", "review patch", "did this fix the bug". - **Kind:** skill - **Source:** https://github.com/hackenproof-public/skills - **Page:** https://forefy.com/skills/91d2bfd9-0d76-4d7e-9515-8e13e0b9ce5f - **API (JSON + files):** https://forefy.com/api/asr/91d2bfd9-0d76-4d7e-9515-8e13e0b9ce5f --- ## SKILL.md --- name: hackenproof-fix-verifier description: Verify that a security fix actually addresses the reported vulnerability without introducing new issues. Works with any local codebase — no MCP or bug bounty platform required. Trigger on "verify fix", "check fix", "is this fix correct", "review patch", "did this fix the bug". --- # Fix Verifier Verify that a code change actually fixes a reported vulnerability — and doesn't introduce new ones. ## When to Use - After applying a fix for a security finding - Before merging a security-related PR - When reviewing someone else's patch for a vulnerability - When a researcher reports that a fix is incomplete - Works on any codebase — no MCP connection or bug bounty platform required ## Inputs The user provides two things: 1. **The vulnerability** — one of: - A pasted vulnerability description or report text - A HackenProof report URL or ID (if MCP is connected) - A CVE ID or advisory description - A plain-English explanation of the bug 2. **The fix** — one of: - The current working tree changes (`git diff`) - A specific commit or commit range (`git diff ..`) - A branch comparison (`git diff main..fix-branch`) - A PR number (read diff from local git) - If not specified, use unstaged + staged changes in the current repo ## Workflow ### Phase 1: Understand the Vulnerability 1. Parse the vulnerability description to extract: - **Root cause** — what is fundamentally wrong (e.g., missing access check, unchecked return value, reentrancy) - **Attack vector** — how an attacker exploits it (e.g., call sequence, malicious input, frontrunning) - **Affected component** — which contract, function, endpoint, or module - **Impact** — what happens if exploited (e.g., fund loss, unauthorized access, DoS) 2. If the vulnerability references specific code (line numbers, function names), locate it in the codebase. 3. If MCP is connected and a report ID is given, fetch the full report with `get_report_details`. ### Phase 2: Analyze the Fix 4. Read the git diff to identify all changed files, functions, and lines. 5. For each change, classify it as: - **Direct fix** — directly addresses the root cause - **Supporting change** — necessary refactoring or test update to support the fix - **Unrelated change** — not connected to the vulnerability (flag for review) 6. Map the changes back to the root cause: - Does the fix address the root cause, or just a symptom? - Does the fix cover all code paths where the vulnerability exists? - Are there other locations with the same pattern that are NOT fixed? ### Phase 3: Check for Completeness 7. Run through the completeness checklist from `references/completeness-checklist.md`: - Root cause addressed (not just the specific exploit path) - All instances of the pattern fixed (not just the one mentioned in the report) - Edge cases covered (boundary values, empty inputs, max values) - Error paths handled (what if the fix itself fails or reverts) 8. If the vulnerability is in a smart contract, run the additional checks from `references/smart-contract-fix-checks.md`. ### Phase 4: Check for Regressions 9. Run through the regression checklist from `references/regression-checklist.md`: - Does the fix change any public interface or function signature? - Does the fix alter state transitions or storage layout? - Does the fix break any existing invariants? - Does the fix introduce new trust assumptions? - Could the fix cause a denial of service (e.g., new revert conditions)? - Does the fix introduce a new dependency or external call? 10. Search the codebase for callers of the modified functions — could any be affected? 11. If tests exist, check whether existing tests still pass conceptually (flag if test modifications look like they're weakening assertions rather than updating them). ### Phase 5: Verdict 12. Produce the verification report using the format from `references/verdict-template.md`. ## Output Rules - Always produce a clear **PASS / FAIL / NEEDS REVIEW** verdict. - Always explain the reasoning — never just say "looks good". - If FAIL, explain exactly what's wrong and suggest what to change. - If NEEDS REVIEW, explain what you're uncertain about and what the developer should manually verify. - If you find the same vulnerability pattern elsewhere in the codebase, report those locations even if the original fix is correct. - Keep the output actionable — developers should know exactly what to do next after reading the verdict. ## Quality Bar - Ground every assessment in the actual diff and codebase — never speculate about code you haven't read. - If you can't determine whether the fix is complete, say so and explain why, rather than guessing. - Treat the fix as suspicious by default — the goal is to find problems, not to rubber-stamp. - Consider both the happy path and adversarial conditions when evaluating the fix. ## references ``` ``` ## references/completeness-checklist.md # Completeness Checklist Run through every item. Mark each as PASS, FAIL, or UNKNOWN. ## Root Cause - [ ] The fix addresses the root cause, not just a symptom or a specific exploit path - [ ] If the root cause is a missing check, the check is now present on ALL relevant code paths (not just the one in the report) - [ ] If the root cause is a logic error, the corrected logic handles all input combinations ## Coverage - [ ] Search the codebase for the same pattern — are there other instances of the same vulnerability that are NOT fixed? - [ ] If the vulnerable function is called from multiple places, verify the fix works regardless of the caller - [ ] If the vulnerability spans multiple functions or contracts, verify all are patched ## Edge Cases - [ ] Zero/empty/null inputs — does the fix handle them? - [ ] Maximum values — does the fix handle uint256 max, max array length, etc.? - [ ] Boundary conditions — off-by-one, exactly-equal-to-threshold cases - [ ] Ordering — does the fix work regardless of call ordering or transaction sequencing? ## Error Handling - [ ] If the fix adds a new revert/require, is the error message descriptive? - [ ] If the fix adds a new revert condition, could it be triggered by legitimate users in normal operation? - [ ] If the fix modifies error handling, are errors still propagated correctly to callers? ## references/regression-checklist.md # Regression Checklist Check each item to verify the fix doesn't break existing functionality. ## Interface Changes - [ ] No public/external function signatures changed (unless intentional and documented) - [ ] No event signatures changed (would break indexers/subgraphs) - [ ] No error/revert message changes that downstream contracts depend on - [ ] Return values haven't changed type or meaning ## Behavioral Changes - [ ] Existing valid inputs still produce the same outputs - [ ] State transitions that worked before still work (no new unexpected reverts) - [ ] Gas consumption hasn't increased dramatically for normal operations - [ ] No new blocking conditions that could prevent legitimate operations ## Trust Assumptions - [ ] No new admin/privileged roles introduced - [ ] No new external dependencies added (oracles, other contracts) - [ ] No existing permission checks weakened or removed - [ ] Timelocks and delays not reduced or bypassed ## Integration Impact - [ ] Functions called by other contracts in the protocol still behave as expected - [ ] Functions called by external integrations (DEX routers, aggregators) still work - [ ] If a modifier was changed, all functions using it are still correct ## Test Integrity - [ ] If test files were modified, changes update expectations (not weaken assertions) - [ ] No test deletions without replacement - [ ] If new revert conditions were added, corresponding tests exist - [ ] If behavior changed, tests reflect the new expected behavior ## references/smart-contract-fix-checks.md # Smart Contract Fix Checks Additional checks for Solidity, Move, Rust (Solana/CosmWasm) and other smart contract fixes. ## Reentrancy - [ ] If the fix adds a reentrancy guard, verify it covers ALL external calls in the function, not just the one exploited - [ ] If the fix reorders state changes (checks-effects-interactions), verify the new order is correct for ALL state variables - [ ] Cross-function reentrancy: are there other functions that read the same state and could be called during reentrancy? - [ ] Cross-contract reentrancy: does the fix account for callbacks from other contracts in the protocol? ## Access Control - [ ] If the fix adds an access check, verify it uses the correct role/permission (not a weaker one) - [ ] Verify the access check cannot be bypassed via delegatecall, proxy, or initializer - [ ] If the fix restricts a function to a specific caller, verify that caller can't be manipulated ## Arithmetic - [ ] If the fix addresses an overflow/underflow, verify the fix covers all arithmetic in the function (not just the one line) - [ ] If using SafeMath or checked arithmetic, verify no unchecked block bypasses it - [ ] If the fix changes precision or decimal handling, verify rounding direction favors the protocol (not the attacker) ## State and Storage - [ ] If the fix modifies storage layout, verify it's compatible with existing proxy deployments - [ ] If the fix changes a mapping or array, verify no stale data can be read - [ ] If the fix adds a new state variable, verify initialization — especially behind proxies ## External Calls - [ ] If the fix changes how external calls are made, verify return values are checked - [ ] If the fix adds a new external call, verify it can't be used to manipulate state - [ ] If the fix adds a callback guard, verify it doesn't break legitimate integrations ## Token Handling - [ ] If the fix involves token transfers, verify it handles fee-on-transfer tokens (if applicable) - [ ] If the fix involves token approvals, verify no approval front-running is introduced - [ ] If the fix involves ETH transfers, verify it handles contracts that reject ETH (no receive/fallback) ## Upgrade Safety - [ ] If the contract is upgradeable, verify the fix doesn't break the storage layout - [ ] If the fix changes an initializer, verify it can't be called again on an existing deployment - [ ] If the fix changes a function selector, verify proxy routing still works ## references/verdict-template.md # Verdict Template Use this format for every fix verification. Do not skip any section. ```md # Fix Verification Report ## Verdict: {PASS | FAIL | NEEDS REVIEW} ## Vulnerability - **Root cause**: {one-line description of what was fundamentally wrong} - **Attack vector**: {how it could be exploited} - **Affected component**: {file:function or contract.function} ## Fix Analysis - **What the fix does**: {one-line description of the change} - **Root cause addressed**: {Yes/No — explain} - **All instances covered**: {Yes/No — list any unfixed instances} ## Completeness | Check | Status | Notes | |-------|--------|-------| | Root cause fixed | {PASS/FAIL} | {detail} | | All code paths covered | {PASS/FAIL} | {detail} | | Edge cases handled | {PASS/FAIL} | {detail} | | Error handling correct | {PASS/FAIL} | {detail} | ## Regressions | Check | Status | Notes | |-------|--------|-------| | No interface changes | {PASS/FAIL/N/A} | {detail} | | No behavioral regressions | {PASS/FAIL/N/A} | {detail} | | No new trust assumptions | {PASS/FAIL/N/A} | {detail} | | Integration impact | {PASS/FAIL/N/A} | {detail} | ## Similar Patterns Found {List any other locations in the codebase with the same vulnerability pattern, even if not in the original report. If none found, write "No additional instances found."} ## Recommendation {What should the developer do next? Merge as-is, apply additional changes, or investigate further. Be specific.} ``` ## Verdict Criteria - **PASS**: Root cause addressed, all instances covered, no regressions found, no similar patterns elsewhere - **FAIL**: Root cause not addressed, fix is incomplete, or fix introduces a regression. Always explain what's wrong. - **NEEDS REVIEW**: Fix looks correct but there are aspects you cannot fully verify (e.g., complex economic logic, external system behavior, production state dependencies). Always explain what needs manual review and why.