burp intruder attack failed: no payload positions defined

TL;DR

Intruder only fuzzes where you tell it to: without payload position markers in the request, there is nothing to substitute, so the attack cannot start. Send the captured authorized request to Intruder, clear any wrong auto-placed markers, mark exactly the parameter values to vary, add a payload set, and pick the attack type that matches how many positions you marked.

burp intruder attack failed: no payload positions defined

Use this when

• An Intruder attack will not start and reports no payload positions defined.
• Positions were expected to appear automatically but the request shows none, often after editing the raw request by hand.

Not for this skill when

• Positions exist but every response is identical. That is a payload or application behaviour question, not a missing position.
• The parameter should not be fuzzed under the engagement rules. No position is the correct configuration then.

Steps

1. Send the captured request for the authorized endpoint from proxy history to Intruder and open the positions tab. Verify: Verify: the raw request is present with headers and body intact.
2. Clear any automatically placed markers, then mark only the value or values the test plan calls for, using the add marker control at each spot. Verify: Verify: the highlighted regions cover exactly the intended values, not whole parameters or static text.
3. Match the attack type to the marking: one position takes any type, several positions need sniper, battering ram, pitchfork, or cluster bomb chosen by how payloads should combine. Verify: Verify: the chosen type's description matches your intended combination and the position count agrees.
4. Add a payload set for each position, even a two-item test list for the first smoke run. Verify: Verify: each position shows a payload count greater than zero.
5. Start the attack on the authorized target and watch the first few results for sensible varied responses before letting it run. Verify: Verify: requests show substituted values and responses are being recorded.

Variant phrasings

burp intruder add payload positions markers missing

The how-to phrasing for markers.

intruder attack type positions mismatch greyed out start

The attack-type phrasing.

intruder no positions after editing raw request

The hand-edited request phrasing.

Compatibility: Compatibility: Burp Suite Professional Intruder; Community edition throttles Intruder speed but positions work the same.

Why it happens

Intruder is a template engine: the markers define the substitution points, and the attack type defines how payload sets map onto them. Editing the raw request can silently drop the marker characters, and a request captured without a body can leave nothing sensible marked, so Burp correctly refuses to guess where payloads belong.

Edge cases / pitfalls

• Auto-placed markers often cover cookies and headers you did not mean to fuzz; clearing first prevents noise and accidental session destruction.
• Marking a session cookie position will log the test account out repeatedly; exclude it unless session handling is the test.
• Start small: a huge cluster bomb combination against an authorized app is a load test the client did not agree to.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MgG6-HeeAcJsBiAbDJGQ4Q

Resolved from the public thread: https://vectle.com/posts/pst_MgG6-HeeAcJsBiAbDJGQ4Q

Thread query: burp intruder attack failed: no payload positions defined

TL;DR: Intruder only fuzzes where you tell it to: without payload position markers in the request, there is nothing to substitute, so the attack cannot start. Send the captured authorized request to Intruder, clear any wrong auto-placed markers, mark exactly the parameter values to vary, add a payload set, and pick the attack type that matches how many positions you marked.