[BUG] fatal error: concurrent map writes in MultiPartForm.Decode during fuzzing

[yusei-wy]

Is there an existing issue for this?

• I have searched the existing issues.

Current Behavior

When running fuzzing templates with concurrency > 1 against targets with multipart/form-data bodies, MultiPartForm.Decode in pkg/fuzz/dataformat/multipart.go causes fatal error: concurrent map writes. This is unrecoverable — the Go runtime kills the process immediately.

Expected Behavior

Fuzzing with multipart/form-data bodies should work correctly under concurrent execution without crashing.

Steps To Reproduce

func TestMultiPartFormDecode_RaceCondition(t *testing.T) {
    mpf := dataformat.NewMultiPartForm()

    boundary := "boundary123"
    body := "--" + boundary + "\r\n" +
        "Content-Disposition: form-data; name=\"file\"; filename=\"test.txt\"\r\n" +
        "Content-Type: text/plain\r\n\r\n" +
        "file content\r\n" +
        "--" + boundary + "--\r\n"

    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mpf.ParseBoundary("multipart/form-data; boundary=" + boundary)
            mpf.Decode(body)
        }()
    }
    wg.Wait()
}

Run with go test -race ./pkg/fuzz/dataformat/...

Relevant log output

fatal error: concurrent map writes

goroutine N [running]:
github.com/projectdiscovery/nuclei/v3/pkg/fuzz/dataformat.(*MultiPartForm).Decode(...)
    pkg/fuzz/dataformat/multipart.go:222
github.com/projectdiscovery/nuclei/v3/pkg/fuzz/component.(*Body).parseBody(...)
    pkg/fuzz/component/body.go:87
github.com/projectdiscovery/nuclei/v3/pkg/fuzz/component.(*Body).Parse(...)
    pkg/fuzz/component/body.go:68
github.com/projectdiscovery/nuclei/v3/pkg/fuzz.(*Rule).Execute(...)
    pkg/fuzz/execute.go:106

Environment

• OS: linux (Cloud Run), also reproducible on macOS
• Nuclei: v3.6.2 (also affects dev branch)
• Go: 1.25.5

Anything else?

Root Cause: MultiPartForm is registered as a singleton in dataformat.init() and shared across all goroutines via dataformat.Get(). Its Decode() method writes to the filesMetadata map and ParseBoundary() writes to the boundary field, both without synchronization.

Proposed Fix: Create a fresh MultiPartForm instance per parse in Body.parseBody instead of reusing the singleton, since MultiPartForm is the only stateful DataFormat implementation.

This is similar to the fix in #6828 which addressed concurrent map writes in evaluateVarsWithInteractsh.

[dwisiswant0]

Could you share at least the real steps to reproduce this from the CLI or SDK? Thanks!

[yusei-wy]

Reproduction (unit test with race detector)

We encountered this crash while using the nuclei SDK with LoadTargetsWithHttpData to scan targets that include multipart/form-data POST requests (from proxify/crawl output).

Minimal reproduction

The root cause is that MultiPartForm is registered as a singleton via dataformat.init() / dataformat.Get(), but it stores mutable state (boundary, filesMetadata). When multiple goroutines fuzz concurrently, they all write to the same map → fatal error: concurrent map writes.

This test demonstrates the issue by sharing a single MultiPartForm instance across goroutines (same pattern as the singleton):

package dataformat

import (
	"sync"
	"testing"
)

func TestMultiPartFormDecode_SharedSingleton_Race(t *testing.T) {
	mpf := NewMultiPartForm()

	boundary := "boundary123"
	body := "--" + boundary + "\r\n" +
		"Content-Disposition: form-data; name=\"file\"; filename=\"test.txt\"\r\n" +
		"Content-Type: text/plain\r\n\r\n" +
		"file content\r\n" +
		"--" + boundary + "--\r\n"

	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			_ = mpf.ParseBoundary("multipart/form-data; boundary=" + boundary)
			_, _ = mpf.Decode(body)
		}()
	}
	wg.Wait()
}

Race detector output (before fix)

$ go test -race -count=1 -run TestMultiPartFormDecode_SharedSingleton_Race ./pkg/fuzz/dataformat/

==================
WARNING: DATA RACE
Write at 0x00c00000e108 by goroutine 17:
  ...MultiPartForm).ParseBoundary()
      pkg/fuzz/dataformat/multipart.go:146 +0x78

Previous write at 0x00c00000e108 by goroutine 8:
  ...MultiPartForm).ParseBoundary()
      pkg/fuzz/dataformat/multipart.go:146 +0x78
==================
--- FAIL: TestMultiPartFormDecode_SharedSingleton_Race (0.00s)
    testing.go:1617: race detected during execution of test
FAIL

In production this manifests as:

fatal error: concurrent map writes

goroutine N [running]:
github.com/projectdiscovery/nuclei/v3/pkg/fuzz/dataformat.(*MultiPartForm).Decode(...)
    pkg/fuzz/dataformat/multipart.go:222
github.com/projectdiscovery/nuclei/v3/pkg/fuzz/component.(*Body).parseBody(...)
    pkg/fuzz/component/body.go:87

After fix (separate instances per parse)

$ go test -race -count=1 -run TestMultiPartFormDecode_ConcurrentWithSeparateInstances ./pkg/fuzz/dataformat/

ok  	github.com/projectdiscovery/nuclei/v3/pkg/fuzz/dataformat	1.270s

SDK usage that triggers the crash

ne, _ := nuclei.NewNucleiEngineCtx(
    context.Background(),
    nuclei.WithTemplatesOrWorkflows(nuclei.TemplateSources{
        Templates: []string{"multipart-fuzz-template.yaml"},
    }),
    nuclei.DisableUpdateCheck(),
)
defer ne.Close()

// Load targets with multipart/form-data POST bodies (from proxify/crawl)
ne.LoadTargetsWithHttpData("input.proxify.yaml", "yaml")
ne.ExecuteCallbackWithCtx(ctx, callback)
// → fatal error: concurrent map writes

Root cause trace

ExecuteCallbackWithCtx
  → engine.ExecuteScanWithOpts (concurrent goroutines)
    → Body.Parse()
      → parseBody("multipart/form-data", req)
        → dataformat.Get("multipart/form-data")  // returns singleton
        → singleton.ParseBoundary(...)            // writes to singleton.boundary  ← race
        → singleton.Decode(...)                   // writes to singleton.filesMetadata map
                                                  // ← fatal error: concurrent map writes

MultiPartForm is the only stateful DataFormat implementation (stores boundary and filesMetadata), but is shared as a singleton via dataformat.Get().

Fix

PR incoming — the fix creates a fresh MultiPartForm instance per parseBody call instead of reusing the singleton, since MultiPartForm is the only stateful DataFormat.

[dwisiswant0]

How's the multipart-fuzz-template.yaml template looks like?

[yusei-wy]

@dwisiswant0 Here's the template and full reproduction steps.

Template (multipart-fuzz.yaml)

This is a simplified version of integration_tests/fuzz/fuzz-body-multipart-form-sqli.yaml (removed the contains(path, "/user") scope filter):

id: multipart-fuzz

info:
  name: multipart form body fuzzing
  author: pdteam
  severity: info

http:
  - pre-condition:
      - type: dsl
        dsl:
          - method != "GET"
          - method != "HEAD"
          - contains(content_type, "multipart/form-data")
        condition: and

    payloads:
      injection:
        - "'"
        - "\""
        - ";"

    fuzzing:
      - part: body
        type: postfix
        mode: single
        fuzz:
          - '{{injection}}'

    stop-at-first-match: true
    matchers:
      - type: word
        words:
          - "ok"

Proxify input (input.proxify.yaml)

A multipart/form-data POST request in proxify YAML format:

timestamp: 2024-01-01T00:00:00+00:00
url: http://localhost:8080/upload
request:
  header:
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
    method: POST
    path: /upload
    host: localhost:8080
  raw: |+
    POST /upload HTTP/1.1
    Host: localhost:8080
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="file"; filename="test.txt"
    Content-Type: text/plain

    file content
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="description"

    test upload
    ------WebKitFormBoundary7MA4YWxkTrZu0gW--
response:
  header:
    Content-Type: text/plain
  raw: |+
    HTTP/1.1 200 OK
    Content-Type: text/plain

    ok

SDK reproduction code (main.go)

package main

import (
	"context"
	"fmt"
	"net/http"
	"net/http/httptest"

	nuclei "github.com/projectdiscovery/nuclei/v3/lib"
	"github.com/projectdiscovery/nuclei/v3/pkg/output"
)

func main() {
	// 1. Start a dummy server that accepts multipart POST and returns "ok"
	ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(200)
		fmt.Fprint(w, "ok")
	}))
	defer ts.Close()

	// 2. Create nuclei engine with the multipart fuzzing template
	ne, err := nuclei.NewNucleiEngineCtx(
		context.Background(),
		nuclei.WithTemplatesOrWorkflows(nuclei.TemplateSources{
			Templates: []string{"multipart-fuzz.yaml"},
		}),
		nuclei.DisableUpdateCheck(),
	)
	if err != nil {
		panic(err)
	}
	defer ne.Close()

	// 3. Load proxify input (multipart/form-data POST request)
	//    NOTE: update the url/host in input.proxify.yaml to point to ts.URL
	if err := ne.LoadTargetsWithHttpData("input.proxify.yaml", "yaml"); err != nil {
		panic(err)
	}

	// 4. Execute — crashes with "fatal error: concurrent map writes"
	if err := ne.ExecuteCallbackWithCtx(context.Background(), func(event *output.ResultEvent) {
		fmt.Printf("Result: %s\n", event.TemplateID)
	}); err != nil {
		panic(err)
	}
}

How to reproduce

# Save the 3 files above, then:
go run -race main.go

Or build nuclei CLI with the race detector:

CGO_ENABLED=1 go build -race -o nuclei-race ./cmd/nuclei
./nuclei-race -t multipart-fuzz.yaml -l targets.txt -im yaml -duc

Unit test (minimal, runs inside the repo)

You can also reproduce this directly in the repo without the SDK by placing this test in pkg/fuzz/dataformat/:

package dataformat

import (
	"sync"
	"testing"
)

// This simulates the singleton sharing pattern used by dataformat.Get().
// Multiple goroutines write to the same MultiPartForm instance concurrently.
func TestMultiPartFormDecode_SharedInstance_Race(t *testing.T) {
	mpf := NewMultiPartForm()

	boundary := "boundary123"
	body := "--" + boundary + "\r\n" +
		"Content-Disposition: form-data; name=\"file\"; filename=\"test.txt\"\r\n" +
		"Content-Type: text/plain\r\n\r\n" +
		"file content\r\n" +
		"--" + boundary + "--\r\n"

	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			_ = mpf.ParseBoundary("multipart/form-data; boundary=" + boundary)
			_, _ = mpf.Decode(body)
		}()
	}
	wg.Wait()
}

$ go test -race -count=1 -run TestMultiPartFormDecode_SharedInstance_Race ./pkg/fuzz/dataformat/

==================
WARNING: DATA RACE
Write at 0x00c00000e108 by goroutine 17:
  ...MultiPartForm).ParseBoundary()
      pkg/fuzz/dataformat/multipart.go:146 +0x78

Previous write at 0x00c00000e108 by goroutine 8:
  ...MultiPartForm).ParseBoundary()
      pkg/fuzz/dataformat/multipart.go:146 +0x78
==================
--- FAIL: TestMultiPartFormDecode_SharedInstance_Race (0.00s)
    testing.go:1617: race detected during execution of test
FAIL

Root cause

MultiPartForm is the only stateful DataFormat — it stores boundary (string) and filesMetadata (map). But it's registered as a singleton in dataformat.init() and shared via dataformat.Get(). When Body.parseBody() is called concurrently by multiple fuzzing goroutines, they all mutate the same instance:

ExecuteCallbackWithCtx / engine.ExecuteScanWithOpts (concurrent goroutines)
  → Body.Parse()
    → parseBody("multipart/form-data", req)
      → dataformat.Get("multipart/form-data")  // returns singleton
      → singleton.ParseBoundary(...)            // writes to singleton.boundary     ← race
      → singleton.Decode(...)                   // writes to singleton.filesMetadata ← fatal: concurrent map writes

The fix creates a fresh MultiPartForm per parseBody call instead of reusing the singleton.

[dwisiswant0]

The SDK snippet you shared is NOT reproducible, and the code that's supposedly buggy looks unreachable anyway.

func TestLoadTargetsWithHttpData_Crash_Via_MultiPartFormDecode(t *testing.T) {
	tmpTemplate, err := os.CreateTemp(t.TempDir(), "multipart-fuzz-*.yaml")
	require.NoError(t, err)

	// 1. Start a dummy server that accepts multipart POST and returns "ok"
	ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(200)
		fmt.Fprint(w, "ok")
	}))
	defer ts.Close()

	parsedURL, err := url.Parse(ts.URL)
	require.NoError(t, err)
	host := parsedURL.Host
	fullURL := ts.URL + "/upload"

	tmpInput, err := os.CreateTemp(t.TempDir(), "input.proxify.*.yaml")
	require.NoError(t, err)

	t.Cleanup(func() {
		_ = os.Remove(tmpTemplate.Name())
		_ = os.Remove(tmpInput.Name())
	})

	_, err = tmpTemplate.WriteString(`id: multipart-fuzz

info:
  name: multipart form body fuzzing
  author: pdteam
  severity: info

http:
  - pre-condition:
      - type: dsl
        dsl:
          - method != "GET"
          - method != "HEAD"
          - contains(content_type, "multipart/form-data")
        condition: and

    payloads:
      injection:
        - "'"
        - "\""
        - ";"

    fuzzing:
      - part: body
        type: postfix
        mode: single
        fuzz:
          - '{{injection}}'

    stop-at-first-match: true
    matchers:
      - type: word
        words:
          - "ok"`)
	require.NoError(t, err)
	require.NoError(t, tmpTemplate.Close())

	_, err = fmt.Fprintf(tmpInput, `timestamp: 2024-01-01T00:00:00+00:00
url: %s
request:
  header:
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
    method: POST
    path: /upload
    host: %s
  raw: |+
    POST /upload HTTP/1.1
    Host: %s
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="file"; filename="test.txt"
    Content-Type: text/plain

    file content
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="description"

    test upload
    ------WebKitFormBoundary7MA4YWxkTrZu0gW--
response:
  header:
    Content-Type: text/plain
  raw: |+
    HTTP/1.1 200 OK
    Content-Type: text/plain

    ok`, fullURL, host, host)
	require.NoError(t, err)
	require.NoError(t, tmpInput.Close())

	// 2. Create nuclei engine with the multipart fuzzing template
	opts := pkgtypes.DefaultOptions()
	// Templates with `fuzzing:` are treated as DAST-only and are excluded unless DAST is enabled.
	opts.DAST = true

	ne, err := nuclei.NewNucleiEngineCtx(
		context.Background(),
		nuclei.WithOptions(opts),
		nuclei.WithTemplatesOrWorkflows(nuclei.TemplateSources{
			Templates: []string{tmpTemplate.Name()},
		}),
		nuclei.DisableUpdateCheck(),
	)
	if err != nil {
		panic(err)
	}
	defer ne.Close()

	// 3. Load proxify input (multipart/form-data POST request)
	if err := ne.LoadTargetsWithHttpData(tmpInput.Name(), "yaml"); err != nil {
		panic(err)
	}

	// 4. Execute — crashes with "fatal error: concurrent map writes"
	if err := ne.ExecuteCallbackWithCtx(context.Background(), func(event *output.ResultEvent) {
		fmt.Printf("Result: %s\n", event.TemplateID)
	}); err != nil {
		panic(err)
	}
}

$ go test -v -run "^TestLoadTargetsWithHttpData_Crash_Via_MultiPartFormDecode$" ./lib
=== RUN   TestLoadTargetsWithHttpData_Crash_Via_MultiPartFormDecode
Result: multipart-fuzz
--- PASS: TestLoadTargetsWithHttpData_Crash_Via_MultiPartFormDecode (1.58s)
PASS
ok      github.com/projectdiscovery/nuclei/v3/lib       1.712s

Next time, have your agent confirm it's actually reproducible via CLI or SDK.