-
Notifications
You must be signed in to change notification settings - Fork 4
Using‐Filter‐Vuln‐Flag
The --filter-vuln flag intelligently filters AtDork results to show only actual vulnerable web applications, eliminating false positives, honeypots, and non-applicable results.
python main.py -q "your-dork-query" --filter-vuln [PLATFORM]Supported Platforms:
-
wordpress– Detect vulnerable WordPress instances -
joomla– Detect vulnerable Joomla instances (planned) -
drupal– Detect vulnerable Drupal instances (planned)
python main.py -q "inurl:wp-admin" -r 50Results include:
- ✅ Real WordPress installations
- ❌ Honeypots (fake targets)
- ❌ Parked domains
- ❌ Redirects & CDNs
- ❌ Non-WordPress pages with "wp-admin" keyword
Problem: 30-40% false positives that waste your time
python main.py -q "inurl:wp-admin" -r 50 --filter-vuln wordpressResults include:
- ✅ Verified WordPress installations
- ✅ Active admin panels
- ✅ Potentially vulnerable endpoints
- ❌ Honeypots (automatically removed)
- ❌ Decoys (automatically removed)
- ❌ Non-WordPress pages (automatically removed)
Result: 80%+ accuracy with actionable targets
The WordPress vulnerability filter identifies:
- Detects WordPress core files (wp-content, wp-includes)
- Verifies active database connections
- Confirms responsive admin panels
- Confirms wp-login.php is accessible
- Validates authentication forms
- Checks for redirects/protections
- Outdated WordPress versions (in HTTP headers)
- Vulnerable plugin directory listings
- Exposed configuration files
- XML-RPC availability (brute-force vector)
- Removes honeypots (intentional traps)
- Removes parked domains
- Removes CDN/proxy responses
- Removes non-WordPress pages with matching keywords
python main.py -q "inurl:wp-admin" -r 100 --filter-vuln wordpressExpected output: Real WordPress login pages only
python main.py -q "WordPress 5.0" -r 50 --filter-vuln wordpressExpected output: WordPress 5.0 installations (released 2018, has known CVEs)
python main.py -q "inurl:xmlrpc.php" -r 50 --filter-vuln wordpress --strict-filterExpected output: Active XML-RPC endpoints on WordPress sites
# Create dorks file
cat > wordpress_dorks.txt << EOF
inurl:wp-admin
inurl:xmlrpc.php
"WordPress Version"
site:example.com inurl:wp-content
EOF
# Run with vulnerability filtering
python main.py --batch-file wordpress_dorks.txt \
--filter-vuln wordpress \
--concurrency 3 \
--format json \
--output-dir assessment_results \
--strict-filterFor highest quality results:
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--strict-filterThis combination:
- ✅ Removes honeypots
- ✅ Requires valid snippets
- ✅ Enforces minimum title length
- ✅ Validates URL format
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--format json \
-o wordpress_vulns.jsonExample JSON output:
[
{
"title": "My Website › WordPress Admin",
"href": "https://example.com/wp-admin/",
"body": "Login",
"vulnerability_score": 0.87,
"vuln_type": "wordpress_admin_exposed",
"detected_version": "5.0.1",
"confidence": "high"
}
]python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--format csv \
-o wordpress_report.csvFor anonymous scanning:
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--tor \
--strict \
--delay 3To avoid detection:
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--delay 5 \
--retries 2 \
--timeout 15Each result includes a vulnerability score (0.0 - 1.0):
-
0.9+ – Critical: Immediate action required
- Active, accessible admin panel
- Potentially exploitable
-
0.7-0.8 – High: Investigate further
- WordPress detected
- Possible vulnerabilities
-
0.5-0.6 – Medium: May require additional verification
- Indirect WordPress detection
- Needs manual verification
- high – Strong evidence of vulnerability (>90% confidence)
- medium – Moderate evidence (70-90% confidence)
- low – Weak evidence, manual verification recommended (<70% confidence)
python main.py -q "inurl:wp-admin" -r 100 \
--filter-vuln wordpress \
--format json \
-o initial_scan.json# Filter JSON for high confidence results
cat initial_scan.json | grep -i '"confidence": "high"'Visit top results to confirm:
- Real WordPress installation
- Login page is accessible
- No WAF/IDS protections
- Version information
# Create final report
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--strict-filter \
--format json \
-o final_assessment_$(date +%Y%m%d_%H%M%S).jsonDuckDuckGo is faster but less comprehensive:
# Fast but less data
python main.py -q "inurl:wp-admin" -r 50 \
--backend duckduckgo \
--filter-vuln wordpressGoogle is slower but more comprehensive:
# Slower but more results
python main.py -q "inurl:wp-admin" -r 100 \
--backend google \
--filter-vuln wordpresspython main.py --batch-file queries.txt \
--filter-vuln wordpress \
--concurrency 5 \
--format json \
--output-dir results# Faster scan
python main.py -q "inurl:wp-admin" -r 20 --filter-vuln wordpress
# Comprehensive scan (slower)
python main.py -q "inurl:wp-admin" -r 100 --filter-vuln wordpressPossible causes:
- Query is too specific (try broader dork)
- All results were false positives (expected with some queries)
- Backend service is rate-limiting
Solution:
# Try different backend
python main.py -q "inurl:wp-admin" -r 50 \
--backend google \
--filter-vuln wordpress \
--delay 2Possible causes:
- Honeypots fool both automated and manual detection
- Need additional manual verification
Solution:
# Use manual verification
python main.py -q "inurl:wp-admin" -r 50 \
--filter-vuln wordpress \
--strict-filter \
--format json -o results.json
# Then manually review each result
cat results.json | jq '.[] | .href'- ✅ Always use
--filter-vuln wordpresswith WordPress dorks - ✅ Combine with
--strict-filterfor highest quality - ✅ Use
--delayto avoid detection - ✅ Document your findings
- ✅ Only scan authorized targets
- ❌ Don't disable vulnerability filtering without good reason
- ❌ Don't scan without authorization
- ❌ Don't exploit vulnerabilities you find
- ❌ Don't disclose findings publicly without responsible disclosure
- ❌ Don't use results for malicious purposes
Using --filter-vuln to identify vulnerabilities is legal ONLY when:
- ✅ You have written authorization from the target
- ✅ It's part of authorized security research
- ✅ It's within bug bounty programs
- ✅ It's for authorized penetration testing
Unauthorized vulnerability scanning is illegal in most jurisdictions.
- Learn more about WordPress-specific dorks
- Explore Advanced Filtering Options
- Review Legal & Ethical Guidelines
Version: 1.0
Last Updated: June 2026
Maintainer: amnottdevv