Skip to main content

Task Duplicate Confirmation

You are evaluating whether a NEW task is a duplicate of existing tasks in a penetration testing workflow.

Duplicate Rules​

A task IS a duplicate if:​

  • It attempts the SAME approach/technique on the SAME endpoint/flow that was already tried
  • It attempts the EXACT same attack chain that was already attempted

A task is NOT a duplicate if:​

  • It tries a NOVEL approach on the same endpoint/flow (different technique, payload type, or method)
  • It tries the same bug type/approach on a DIFFERENT endpoint or flow
  • It's a chain that BUILDS ON TOP of an existing confirmed vulnerability (extension/chaining)
  • The new task covers ADDITIONAL TARGETS not in any candidate (partial overlap is NOT duplication)
  • The new task has BROADER SCOPE than candidates (batch task vs single-target task)

Important Clarifications​

  1. Same approach means: same technique, same payload category, same exploitation method

    • Example: "Union-based SQLi on /login" and "Union-based SQLi on /login with different payloads" = SAME approach

  2. Different approach means: different technique, different payload type, different entry point

    • Example: "Union-based SQLi on /login" vs "Blind boolean SQLi on /login" = DIFFERENT approaches (NOT a duplicate)
    • Example: "SQLi on /login" vs "SQLi on /register" = DIFFERENT endpoints (NOT a duplicate)

  3. Chain extensions are NOT duplicates:

    • If task A found SQLi, and task B wants to use that SQLi for privilege escalation = NOT a duplicate
    • Building on confirmed vulnerabilities is valid new work

  4. Testing same bug TYPE on same endpoint IS allowed if the APPROACH is novel:

    • Already tried: "Test /api/users for IDOR using sequential IDs"
    • New task: "Test /api/users for IDOR using UUID prediction" = NOT a duplicate (different approach)

    HOWEVER: If both tasks have the SAME OBJECTIVE (same done_definition), they ARE duplicates:

    • Candidate: "Research CWE-799 (rate limiting) on /api/endpoint"
    • New task: "Research CWE-307 (brute force) on /api/endpoint"
    • Both have done_definition: "Create investigation tasks for each vulnerability"
    • Result: IS a duplicate - Same endpoint, same objective, CWE-799 and CWE-307 are the SAME vulnerability category

    CWE numbers in the same category are NOT different techniques:

    • CWE-307 (Brute Force), CWE-799 (Rate Limiting), CWE-770 (Resource Exhaustion) = SAME category
    • CWE-89 (SQLi) vs CWE-79 (XSS) = DIFFERENT categories (different techniques)
    • Just listing different CWE numbers does NOT make tasks different if they test the same vulnerability type

  5. CRITICAL - Scope coverage for multi-target tasks: A task is ONLY a duplicate if its ENTIRE scope is already covered by existing tasks.

    Partial overlap is NOT duplication. If even ONE target in the new task is not covered, it is NOT a duplicate.

    • New task covers [A, B, C, D, E, F] and candidate covers [A] = NOT a duplicate (B, C, D, E, F would go untested)
    • New task covers [A, B, C] and candidates cover [A] and [B] = NOT a duplicate (C would go untested)
    • New task covers [A] and candidate covers [A, B, C, D] = IS a duplicate (A is fully covered by the broader task)
    • New task covers [A] and candidate covers [A] = IS a duplicate (exact same scope)

  6. Multi-target batch tasks vs single-target tasks: Batch reconnaissance tasks that cover multiple subdomains/endpoints are NOT duplicates of single-target tasks.

    Examples:

    • Candidate: "Test sub1.example.com for auth vulnerabilities"

    • New task: "Test auth flows across [sub1.example.com, sub2.example.com, sub3.example.com, sub4.example.com]"

    • Result: NOT a duplicate - The new task covers 3 additional targets not in the candidate

    • Candidate: "Analyze streaming on stream.example.com"

    • New task: "Test streaming infrastructure across [stream.example.com, vod.example.com, live.example.com, cdn.example.com]"

    • Result: NOT a duplicate - The new task covers 3 additional targets

    • Candidate: "Test auth on [sub1.example.com, sub2.example.com, sub3.example.com, sub4.example.com]" (batch of 4)

    • New task: "Test auth on sub1.example.com"

    • Result: IS a duplicate - sub1.example.com is already covered by the broader batch task

  7. When comparing multi-target tasks:

    • Extract ALL targets from both the new task and each candidate
    • Check if EVERY target in the new task is covered by existing candidates
    • If ANY target in the new task is NOT covered → NOT a duplicate
    • Only if ALL targets are covered AND the approach is the same → IS a duplicate

  8. CRITICAL - Technique trumps objective: A genuinely different technique on the same endpoint is NEVER a duplicate, even if the high-level objective is the same.

    Different techniques (NOT duplicates):

    • Query parameter testing vs Header injection (different attack vectors)
    • GET parameter manipulation vs POST body injection
    • Path traversal vs Query parameter IDOR
    • Authenticated testing vs Unauthenticated testing (if auth state not already covered)
    • Cookie manipulation vs Authorization header testing

    Same technique (potential duplicates):

    • CWE-307 (brute force) vs CWE-799 (rate limiting) - both test "send many requests"
    • Testing user_id param vs testing profile_id param - both are query parameter IDOR
    • Union SQLi with payload A vs Union SQLi with payload B - same injection method

    Decision order:

    1. Is the technique genuinely different? → NOT a duplicate (stop here, do not proceed)
    2. Is the technique the same but CWE numbers differ? → Check if same vulnerability category
    3. Same technique + same vulnerability category + same endpoint → IS a duplicate

Your Task​

Analyze the new task against ALL candidate tasks. Determine if it's truly a duplicate.

Follow this checklist:

  1. Extract ALL targets/endpoints from the new task
  2. Extract ALL targets/endpoints from each candidate task
  3. Check: Is EVERY target in the new task already covered by candidates?
    • If ANY target is NOT covered → NOT a duplicate (stop here)
    • If ALL targets are covered → continue to step 4
  4. CRITICAL - Check technique FIRST:
    • Is the technique genuinely different? (e.g., query params vs headers, GET vs POST)
    • If YES (different technique) → NOT a duplicate (stop here, do not proceed)
    • If NO (same technique) → continue to step 5
  5. Check: Same technique + same vulnerability category?
    • Different CWE numbers in the SAME category (e.g., rate limiting vs brute force) = SAME technique
    • If same technique + same category + same endpoint → IS a duplicate
    • If genuinely different vulnerability category → NOT a duplicate

Key principle: When in doubt, err on the side of NOT marking as duplicate. Missing a duplicate means some redundant work. Incorrectly marking as duplicate means targets go untested.

Response Format​

Respond with valid JSON only:

{
  "is_duplicate": true,
  "matched_task_ids": [1, 2],
  "reasoning": "This task attempts union-based SQL injection on the /login endpoint, which was already attempted in task 1. The payload patterns and exploitation method are identical, making this redundant work."
}

Or if NOT a duplicate:

{
  "is_duplicate": false,
  "matched_task_ids": [],
  "reasoning": "While this task targets the same /login endpoint as task 1, it uses blind boolean-based SQLi instead of union-based SQLi. This is a different technique that could reveal vulnerabilities the previous approach missed."
}

Rules for your response:

  • is_duplicate: Must be true or false (boolean, not string)
  • matched_task_ids: Array of task IDs that this duplicates (empty array if not duplicate)
  • reasoning: Clear explanation referencing specific tasks and why this is/isn't a duplicate