agentleFS
ajtazerajtazer/heckit/skills/cve-hunting/cross-pollination/SKILL.md

cross-pollination

Skill2 starsChanged 2 months agoMITView on GitHub

Cross-pollination multiplier technique: find a vulnerability in one package, then search for the same pattern across all similar packages to multiply findings.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After confirming a vulnerability in package-A, use this technique to find the same vulnerable pattern in packages B through Z.

    line 20
  2. Distinctive:

    Before cross-pollinating, ensure the original finding is confirmed:

    line 38
  3. Distinctive:

    Start with a specific pattern, then broaden if too few results

    line 65
  4. Distinctive:

    Look at file context, not just the matching line

    line 67
  5. Distinctive:

    If you have multiple repos cloned locally:

    line 123
  6. Distinctive:

    When grep.app returns 50+ matches:

    line 134
  7. Distinctive:

    Second pass: Check for existing CVEs (skip if already reported)

    line 137
  8. Distinctive:

    Third pass: Verify user input reaches the pattern

    line 138

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cross-Pollination -- Multiplying Findings

When to Use

After confirming a vulnerability in package-A, use this technique to find the same vulnerable pattern in packages B through Z. One finding can multiply into 5-20 findings.

The Multiplier Effect

Starting FindingPatternTypical Yield
Entity expansion in XML parser AAll XML parsers with no entity limit3-8 findings
Zip Slip in archive lib AAll archive extraction libs2-5 findings
Proto pollution in merge lib AAll deep merge/clone libs5-10 findings
ReDoS in validator AAll validators using same regex pattern3-7 findings
Code injection in schema validator AAll schema validators with code gen2-5 findings
Recursion DoS in serializer AAll recursive serializers5-15 findings
Method clobbering in parser AAll parsers creating objects from input3-8 findings

Process

Step 1: Confirm the Original Finding

Before cross-pollinating, ensure the original finding is confirmed:

  • PoC works
  • fp-check passes
  • Submitted or ready to submit

Step 2: Extract the Vulnerable Pattern

Identify the core vulnerable code pattern as a regex:

# Example: recursive function without depth limit
Pattern: function\s+\w+\(.*\)\s*\{.*\w+\(  (self-call without depth check)

# Example: new Function with template literal
Pattern: new\s+Function\s*\(.*\$\{

# Example: path.join without startsWith check
Pattern: path\.join\(.*req\.(params|body|query)

Step 3: Search via grep.app

https://grep.app/search?q=PATTERN&regexp=true&filter[lang][0]=JavaScript

Tips:

  • Start with a specific pattern, then broaden if too few results
  • Filter by language to reduce noise
  • Look at file context, not just the matching line
  • Skip node_modules, test files, documentation

Step 4: Evaluate Each Match

For each match:

  1. Is this a different package? (not a fork/copy of the original)
  2. Does user input reach this code? (trace the data flow)
  3. Is the pattern actually vulnerable in this context? (check for mitigations)
  4. Does the package have enough usage to warrant a CVE? (check downloads)
  5. Does a CVE already exist for this package? (check NVD)

Step 5: Submit Findings

For each confirmed vulnerable package:

  1. Apply fp-check
  2. Build PoC adapted to this package
  3. Submit via appropriate channel (GHSA, email, HackerOne)

grep.app Usage

URL Format

https://grep.app/search?q=QUERY&regexp=true&filter[lang][0]=LANGUAGE

Parameters

  • q: Search query (URL-encoded)
  • regexp: true/false for regex mode
  • filter[lang][0]: Language filter (JavaScript, Python, Go, Ruby, etc.)
  • page: Pagination

Useful Regex Patterns

# new Function with interpolation
new\s+Function\s*\(.*\$\{

# eval with concatenation
eval\s*\(.*\+

# Recursive function without depth
function\s+\w+.*\{[^}]*\1\(

# path.join with user input
path\.join\(.*req\.(params|body|query)

# XML parser without entity config
new\s+XMLParser\s*\(\s*\)

# Deep merge without proto check
function\s+\w*merge.*for.*in.*source.*\[key\]

Local Cross-Repo Search

If you have multiple repos cloned locally:

# Search across all cloned repos
rg "PATTERN" targets/ --type js --glob '!node_modules'

# Count matches per repo
rg "PATTERN" targets/ --type js --glob '!node_modules' --count

Scaling: Processing Many Matches

When grep.app returns 50+ matches:

  1. First pass: Quick filter by download count (skip < 100K weekly)
  2. Second pass: Check for existing CVEs (skip if already reported)
  3. Third pass: Verify user input reaches the pattern
  4. Fourth pass: Build PoC for confirmed cases
  5. Batch submit: Submit findings in batches, not all at once

References

  • Category Mapping -- Package families by vuln class
  • grep.app Usage -- Detailed search guide

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.