ffuf "ERROR: too many errors" during authorized directory fuzzing

TL;DR

Ffuf aborts when too many requests fail: usually connection resets from an overloaded target or a WAF pushing back. Slow down with -rate, raise -timeout, confirm the target is healthy by hand, and get allowlisted if a WAF is resetting you.

ERROR: too many errors

Use this when

• Ffuf stops with ERROR: too many errors before finishing the wordlist.
• Manual requests to the target work fine.
• The engagement allows rate tuning.

Not for this skill when

• The run completes but finds nothing. That is a filtering problem.
• The target is down for everyone. Confirm with the client contact.
• The engagement caps your request rate below what ffuf needs. Respect the cap.

Steps

1. Hand-check the target: curl -s -o /dev/null -w "%{http_code}" YOUR_TARGET_HOST/ several times. Verify: the app responds consistently.
2. Slow the run: ffuf -u YOUR_TARGET_HOST/FUZZ -w wordlist -rate 50 -timeout 10 -t 10. Verify: the error count drops.
3. Check for WAF resets: look for connection resets vs clean HTTP errors in -v output. Verify: you know whether it is resets (WAF/network) or HTTP errors (app).
4. If a WAF is resetting connections, ask the client to allowlist your egress IP. Verify: manual requests stop resetting.
5. Rerun at the sustainable rate and let it take longer. Verify: the run completes the wordlist.

Variant phrasings

ffuf too many errors abort

Compact phrasing.

ffuf error rate threshold

The mechanism-oriented search.

ffuf connection reset fuzzing

The network-flavored search.

Compatibility: ffuf v1/v2. -rate, -timeout, -t flags are stable across versions.

Why it happens

Ffuf treats repeated request failures as a signal that something is deeply wrong (dead target, aggressive WAF, exhausted file descriptors) and aborts rather than burning the whole wordlist into errors. The threshold is doing its job; the fix is to remove the cause of the errors.

Edge cases / pitfalls

• Raising the error threshold instead of fixing the rate just produces a longer, junkier run. Fix the rate.
• File descriptor exhaustion on the tester box looks like target errors. Check ulimit -n on long runs.
• A WAF that resets only fuzz-looking requests will pass your hand checks and fail the run. Compare -v output carefully.
• Document the sustainable rate in your notes; the client may ask why the scan took that long.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1kUVXDd6fbPE3fWCMAwQ2g