Three changes in the new major version of Anthropic's Go SDK alter what your service sends without touching your request code. Version 2.0.0 came out on October 21 together with Claude API version 2026-10-21. It sends anthropic-version: 2026-10-21, which rejects temperature, top_p and top_k. It moves your API key from X-Api-Key to Authorization: Bearer. And a client that is given two credentials now fails every request instead of sending both.

v2 lives at a new module path, so none of this applies until you change your imports. go get -u ./... leaves a service on v1.84.0, the last v1 release, which still sends 2023-06-01. As of October 29 the versions page lists no retirement date for 2023-06-01, so you can choose when to move. The examples below run one small program against v1.84.0 and v2.4.0 (the current release). All requests went to an httptest server that returns a canned Messages response, so nothing was sent to Anthropic and no claim below is about how the real API answered.

Compile errors after changing the import path

The migration guide says to change every import of github.com/anthropics/anthropic-sdk-go, including subpackages such as option, to start with github.com/anthropics/anthropic-sdk-go/v2, then run go get github.com/anthropics/anthropic-sdk-go/v2. We did that to a v1 program that built its request like this:

params := anthropic.MessageNewParams{
	Model:       "claude-opus-5-5",
	MaxTokens:   64,
	Temperature: anthropic.Float(0.2),
	Messages: []anthropic.MessageParam{{
		Role:    anthropic.MessageParamRoleUser,
		Content: []anthropic.ContentBlockParamUnion{anthropic.NewTextBlock("Hello")},
	}},
}

With only the import lines changed, Go 1.27.3 stops at four errors:

./main.go:48:3: unknown field Temperature in struct literal of type anthropic.MessageNewParams
./main.go:50:4: unknown field Role in struct literal of type anthropic.MessageParam
./main.go:50:23: undefined: anthropic.MessageParamRoleUser
./main.go:51:4: unknown field Content in struct literal of type anthropic.MessageParam

The first error comes from the API change. 2026-10-21 returns a 400 for any request that sends temperature, top_p or top_k, even at the default value, and the SDK removed the fields so you can't send them by accident. The guide notes that Claude 4.7 and later models already accept only the defaults, so on those models deleting the field changes nothing. On an older model that accepts other values, such as Sonnet 4.6, a request that lowered temperature loses that effect, and no other setting replaces it.

The other three come from MessageParam, which is now a union with one type per role: OfUser, OfAssistant and OfSystem. NewUserMessage, NewAssistantMessage and Message.ToParam work as before, so the smallest fix is to stop writing the struct by hand:

params := anthropic.MessageNewParams{
	Model:     "claude-opus-5-5",
	MaxTokens: 64,
	Messages: []anthropic.MessageParam{
		anthropic.NewUserMessage(anthropic.NewTextBlock("Hello")),
	},
}

Where you do need a literal, name the role's type and leave Role out, because each type marshals its own. Code that read message.Role checks which pointer is set instead, or calls GetRole(), which returns a *string:

history := []anthropic.MessageParam{
	params.Messages[0],
	{OfAssistant: &anthropic.AssistantMessageParam{
		Content: []anthropic.ContentBlockParamUnion{anthropic.NewTextBlock("Hi")},
	}},
}
for _, m := range history {
	fmt.Printf("  role=%s user=%v assistant=%v\n", *m.GetRole(), m.OfUser != nil, m.OfAssistant != nil)
}

  role=user user=true assistant=false
  role=assistant user=false assistant=true

Because the union holds pointers, copying a MessageParam no longer copies the message, and the compiler won't flag it. Code that trims or rewrites a copy of the history, which is common in agent loops that shorten old tool results, now edits the original:

copied := history[1]
copied.OfAssistant.Content = nil
fmt.Printf("  after clearing the copy, original has %d blocks\n", len(history[1].OfAssistant.Content))

  after clearing the copy, original has 0 blocks

In v1, setting copied.Content changed only the copy. If you keep a canonical history and derive trimmed requests from it, allocate a new AssistantMessageParam for anything you change.

The JSON body is unchanged. Both versions sent {"content":[{"text":"Hello","type":"text"}],"role":"user"} for the message; the only difference in our request body was the missing "temperature":0.2.

The API key moved to the Authorization header

This change produces no compile errors. Our stub server received these headers for a plain request from each version:

v1.84.0
  anthropic-version: 2023-06-01
  x-api-key:         <key>
  authorization:     -
v2.4.0
  anthropic-version: 2026-10-21
  x-api-key:         -
  authorization:     Bearer <key>

The Claude API accepts a key in either header, so calls straight to api.anthropic.com keep working. What breaks is anything in between that looks for X-Api-Key: a corporate gateway, a logging proxy, a redaction rule in your log pipeline, a test stub that asserts on the header. If you run something like the logging proxy from our earlier article, check which header it reads and which it scrubs from logs before you upgrade its clients.

If the proxy can't change yet, the guide's workaround sets X-Api-Key yourself and removes the default Authorization header. Our stub received this:

proxied := anthropic.NewClient(
	option.WithBaseURL(srv.URL),
	option.WithHeader("X-Api-Key", "sk-test-key"),
	option.WithHeaderDel("Authorization"),
)

  x-api-key:         <key>
  authorization:     -

Code that used option.WithHeaderDel("X-Api-Key") to keep the key off one request, usually so an auth token would be the only credential, is affected too. On v1.84.0 that request arrived with no key. On v2.4.0 it arrives with the key anyway, because the key is no longer in that header:

2. WithHeaderDel("X-Api-Key") on the request
  anthropic-version: 2026-10-21
  x-api-key:         -
  authorization:     Bearer <key>

There is no error or warning, so search your code for WithHeaderDel("X-Api-Key") and WithHeader("X-Api-Key" before upgrading. The other old pattern, WithHeader("X-Api-Key", otherKey), now sends both keys. According to the guide, WithHeaderDel("Authorization") removes the key from a request, and option.WithAPIKey(otherKey) or option.WithAuthToken(token) on a request replaces the client's credential for that request.

Clients with two credentials

v1 sent both credentials when a client had an API key and an auth token, each in its own header. Our v1.84.0 client built with WithAPIKey and WithAuthToken delivered x-api-key: <key> and authorization: Bearer gateway-token. The same client on v2.4.0 never reached the server:

3. client with an API key and an auth token
  error: option: pass at most one of WithAPIKey, WithAuthToken, WithConfig, WithConfigQuiet, WithProfile and WithFederationTokenProvider; got WithAPIKey and WithAuthToken

anthropic.NewClient returns no error, so this shows up at the first call rather than at startup. NewClient already applies DefaultClientOptions(), so passing its result again means a key found in ANTHROPIC_API_KEY counts as a second credential next to the one you pass. A gateway setup that sent a gateway token plus an API key needs rewriting. The guide's version keeps WithAuthToken, sets X-Api-Key with option.WithHeader, and has the gateway strip its Authorization header before forwarding.

If you pass no credential, the order is the same as v1: ANTHROPIC_API_KEY, then ANTHROPIC_AUTH_TOKEN, then ANTHROPIC_PROFILE, workload identity federation and the active profile on disk.

Keeping one request on 2023-06-01

Issue 483, opened on October 27 and still unanswered when we checked, asks whether v2 drops support for 2023-06-01, since temperature is gone from the params. The guide's answer for the API is that a request relying on a non-default temperature can stay on 2023-06-01. In the SDK, both overrides are per-request options. We sent this from v2.4.0:

client.Messages.New(ctx, params,
	option.WithHeader("anthropic-version", "2023-06-01"),
	option.WithJSONSet("temperature", 0.2),
)

6. one request kept on 2023-06-01 with temperature
  anthropic-version: 2023-06-01
  x-api-key:         -
  authorization:     Bearer <key>
  body: {"max_tokens":64,"messages":[{"content":[{"text":"Hello","type":"text"}],"role":"user"}],"model":"claude-opus-5-5","temperature":0.2}

The header override replaced the default version and the field reached the body. We couldn't send it to the real API from here, and the SDK makes no promise that its v2 types fit the older version. Use it for the few requests on older models that need it; if a whole service needs 2023-06-01, stay on v1 for now.

Other breaking changes

These are smaller, and the compiler finds most of them:

• Go 1.25 or later is required.
• The Text Completions API is gone from the SDK.
• ModelListParams and ModelGetParams lost Betas. Call client.Beta.Models.List with BetaModelListParams to send beta headers.
• vertex.DefaultVersion and bedrock.DefaultVersion are removed. On Amazon Bedrock, 2026-10-21 works only with Claude 4.7 and later models, so services calling older Bedrock models should stay on v1.
• One-value enum types in the Managed Agents beta, such as BetaManagedAgentsTextBlockTypeText, became constants. Delete the Type field in requests and compare responses with the string.
• ClearAt and OutputConfig moved from BetaMessageParam to BetaSystemMessageParam.
• option.WithConfigQuiet now does what WithConfig does and is deprecated.
• v2 is licensed under Apache 2.0; v1 stays MIT. Update any license inventory you keep.

On the API side, two more request shapes return 400 on 2026-10-21 and compile without errors: a document block placed directly in an assistant message, and a text block with a non-empty citations array in a user message. Both usually come from agent code that replays earlier turns, so search the code that builds history as well as the code that builds new requests.

For the upgrade itself: change the imports, fix what the compiler reports, search for X-Api-Key in code, proxies and log filters, check that each client gets exactly one credential, and only then deploy. If your service also exports traces, the OpenTelemetry behaviour added in v1.81 carries over to v2, so the baggage check from that article still applies.

Originally published on ImportStatic. This article was drafted with AI assistance; every claim was checked against the sources linked in it and the code samples were compiled and run.

To find where a Go program is stuck, read the goroutine dump under fatal error: all goroutines are asleep - deadlock!. The word in square brackets after goroutine 1 is what that goroutine was waiting for, and the last main. frame is the line that blocked. The runtime prints the error and exits with status 2 when no thread is running Go code, every goroutine is blocked and no timer is pending, because at that point nothing can wake the program up.

The six causes below were reproduced with Go 1.27.3, and each fix was compiled and run. In most servers and under go test, the same mistakes hang forever instead of crashing, because a pending timer or a goroutine waiting on the network keeps the runtime from declaring a deadlock.

States in the goroutine dump

go vet reported nothing on any of the six programs.

Sending on an unbuffered channel with no receiver

func main() {
	ch := make(chan int)
	ch <- 1 // no receiver is running yet, so this send blocks forever
	fmt.Println(<-ch)
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/unbuffered/main.go:7 +0x38

The spec says a send on an unbuffered channel can proceed only "if a receiver is ready". The receive is on the next line of the same goroutine, so it never runs. Either send from another goroutine or give the channel room for the value:

	ch := make(chan int)
	go func() { ch <- 1 }() // the send runs in its own goroutine
	fmt.Println(<-ch)

	buf := make(chan int, 1) // or give the channel room for one value
	buf <- 2
	fmt.Println(<-buf)

With a buffer of one, a second send before anyone reads blocks again, so a buffer is a fix only when you know the number of values in advance.

A WaitGroup that never reaches zero

	var wg sync.WaitGroup
	for i := range 3 {
		wg.Add(1)
		go func() {
			if i == 1 {
				return // early return skips Done
			}
			fmt.Println("worker", i)
			wg.Done()
		}()
	}
	wg.Wait()

worker 2
worker 0
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [sync.WaitGroup.Wait]:
sync.runtime_SemacquireWaitGroup(0x1042b0210?, 0x30?)
	/Users/pike6/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.27.3.darwin-arm64/src/sync/waitgroup.go:114 +0x38
sync.(*WaitGroup).Wait(0xb2933396020)
	/Users/pike6/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.27.3.darwin-arm64/src/sync/waitgroup.go:206 +0xa4
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/waitgroup/main.go:20 +0xac

The two workers that printed have exited, so the dump shows only main waiting. The goroutine that returned early is gone too, which is why the trace can't point at it; count your Add and Done calls on every return path. defer wg.Done() at the top of the goroutine fixes it, and since Go 1.25 WaitGroup.Go does the Add and the deferred Done for you:

	for i := range 3 {
		wg.Go(func() { // Add(1) before the goroutine starts, Done when it returns
			if i == 1 {
				return
			}
			fmt.Println("worker", i)
		})
	}
	wg.Wait()

This printed both workers and then all done.

Ranging over a channel nobody closes

	ch := make(chan int)
	go func() {
		for i := range 3 {
			ch <- i
		}
		// missing close(ch)
	}()
	for v := range ch {
		fmt.Println(v)
	}

0
1
2
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/rangeopen/main.go:13 +0xc0

All three values arrive, then the for line waits for a fourth value or a close. A range over a channel only ends when the channel is closed. The goroutine that sends should close it, with defer close(ch) as its first line, so the loop ends after the last value. When several goroutines send on one channel, close it from a separate goroutine after a WaitGroup says all senders are done; closing it from a sender that finishes early makes the others panic on a closed channel.

A select where no case can ever be ready

	results := make(chan string)
	errs := make(chan error)
	go func() {
		fmt.Println("worker finished without sending")
	}()
	select {
	case r := <-results:
		fmt.Println(r)
	case err := <-errs:
		fmt.Println(err)
	}

worker finished without sending
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [select]:
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/selectnone/main.go:11 +0x8c

In real code the worker usually has a path that returns early, often an error path, without sending on either channel. Make every return path send on exactly one of them:

	go func() {
		r, err := work()
		if err != nil {
			errs <- err // every return path sends on one of the channels
			return
		}
		results <- r
	}()

An empty select {} blocks forever and, with nothing else running, dies with goroutine 1 [select (no cases)]. Servers put it at the end of main on purpose; there a goroutine blocked on a listener keeps the program alive, for the reason given under "When the same mistake hangs instead".

A channel that was never made

type Server struct {
	done chan struct{} // never initialised
}

func main() {
	s := &Server{}
	<-s.done // receive from a nil channel blocks forever
	fmt.Println("stopped")
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive (nil chan)]:
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/nilchan/main.go:11 +0x24

The zero value of a channel field is nil, and the spec says "Receiving from a nil channel blocks forever"; sending does too. The (nil chan) in the bracket identifies this case. Make the channel in a constructor (&Server{done: make(chan struct{})}) and don't build the struct with a literal elsewhere.

Locking a mutex you already hold

func (c *Counter) Get(k string) int {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.n[k]
}

func (c *Counter) Incr(k string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n[k] = c.Get(k) + 1 // Get locks c.mu again
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [sync.Mutex.Lock]:
internal/sync.runtime_SemacquireMutex(0x1044c9778?, 0xc0?, 0x10f2b9c04db8?)
	/Users/pike6/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.27.3.darwin-arm64/src/runtime/sema.go:95 +0x28
[... three frames inside internal/sync and sync ...]
main.(*Counter).Get(0x10f2b9c24020, {0x10440fc20, 0x1})
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/mutex/main.go:14 +0x84
main.(*Counter).Incr(0x10f2b9c24020, {0x10440fc20, 0x1})
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/mutex/main.go:22 +0xac
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/mutex/main.go:27 +0x70

sync.Mutex is not reentrant: Lock blocks until the mutex is free, even when the caller is the goroutine that holds it. Two frames from the same type, an outer one holding the lock and an inner one waiting for it, are the pattern to look for. The usual fix is an unexported helper that assumes the lock is held, called by both exported methods:

// get expects c.mu to be held by the caller.
func (c *Counter) get(k string) int { return c.n[k] }

func (c *Counter) Incr(k string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n[k] = c.get(k) + 1
}

RWMutex has a variant of this that we didn't reproduce: its documentation prohibits recursive read locking, because a second RLock waits behind any writer that queued up after the first one.

When the same mistake hangs instead

Adding this line at the top of main in the unbuffered-send program stops the error:

	time.AfterFunc(time.Hour, func() {})

The program hangs instead. Our driver killed it after three seconds; left alone it would sit there for an hour. We got the same hang with a goroutine blocked in ln.Accept() on a TCP listener, and with one blocked reading from stdin.

The check lives in checkdead in runtime/proc.go. It runs only when the number of threads running Go code drops to zero, then checks that every user goroutine is waiting, and then, before printing the error, returns early if any P has a timer in its heap. A pending timer means time could still wake something, so the runtime can't call it a deadlock. A goroutine waiting on the network poller keeps a thread parked inside netpoll in the scheduler's findRunnable instead of idle, and a blocking read on stdin keeps a thread in a system call. Either way the count of running threads never reaches zero.

That limits the error to small programs. A server has a listener, a ticker, a connection pool or an HTTP client with timeouts, and a deadlocked request handler there just stops responding.

Tests hit the timer rule too. go test arms an alarm for its -timeout flag (10 minutes by default), so a deadlocked test waits out the timeout and reports that instead:

panic: test timed out after 3s
	running tests:
		TestSend (3s)

With -timeout 0 the same test failed in 65 ms with fatal error: all goroutines are asleep - deadlock!, followed by a dump that included goroutine 19 [chan send] at the test's line. Setting a short -timeout while you debug gets you the same dump without the wait, since the timeout panic prints every goroutine as well.

Finding the line when nothing crashes

Send the hung process SIGQUIT (Ctrl+\ in the terminal it runs in, or kill -QUIT <pid>). The os/signal documentation says a Go program then exits with a stack dump. For the timer program the dump starts with runtime internals, and further down holds the same frame the fatal error would have shown:

goroutine 1 gp=0x6b40533aa1e0 m=nil [chan send]:
[... runtime.gopark and runtime.chansend frames ...]
main.main()
	/Users/pike6/work/project/website/importstatic/.work/go-deadlock/cases/timer/main.go:13 +0x50 fp=0x6b4053422ea0 sp=0x6b4053422e40 pc=0x100a077e0

In a server you'd rather not kill, net/http/pprof serves /debug/pprof/goroutine?debug=2, which its source describes as all goroutine stacks "in the same format as an unrecovered panic", and the process keeps running. If only some goroutines are stuck and the rest of the program is fine, it's a goroutine leak rather than a deadlock, and Go 1.27's goroutineleak profile lists the ones that can never run again.

For tests of concurrent code, testing/synctest gets around the timer rule. Its bubble has a fake clock, so pending timers don't count as a way out. We wrapped the same test, one-hour AfterFunc included, in synctest.Test, and it failed in 0.00s with panic: deadlock: all goroutines in bubble are blocked, the blocked send listed as [chan send (durable), synctest bubble 1].

Originally published on ImportStatic. This article was drafted with AI assistance; every claim was checked against the sources linked in it and the code samples were compiled and run.

The remote code execution in CVE-2026-111497 is in Google's C Brotli decoder, which most Go and Rust services never load. Two cases are worth checking anyway. A Go or Rust binary can link the C library through cgo or a -sys crate. And two popular frameworks, Fiber v2 in Go and actix-web in Rust, decompress Content-Encoding: br request bodies before your handler runs, with no configuration.

The advisory went public with the Node.js security release on October 21, 2026, and this article reflects what was published as of October 25, 2026. A Hacker News discussion of the follow-up write-up covered Node, Python and .NET and argued about how often servers decode compressed request bodies at all; it didn't get to Go or Rust.

Affected versions and ports

The GitHub advisory GHSA-9v8h-qqgm-4m35 puts the bug in c/dec/decode.c of Google Brotli 1.0.3 through 1.2.0, with fixes in 1.0.10, 1.1.1 and 1.2.1. GitHub scores it 9.2 (CVSS 4.0); the Node.js release notes rate it High and describe the cause: an invalid block switch was reported as "needs more input" instead of a format error, so the streaming decoder kept writing into an eight-byte internal buffer.

For ports to other languages, the disclosure site says code execution is only possible in the C decoder. It says the Go port github.com/andybalholm/brotli had the same logic error but would only have crashed, fixed on October 23, and that Rust's brotli-decompressor catches the condition and returns an error. That gives three groups to look for:

The andybalholm fix is commit 33c2a98, tagged v1.2.7. Its message says it ports upstream commit 0ed4268a, one of the four C fixes the advisory lists: the block-switch functions in decode.go now return a status, and an invalid switch becomes a BLOCK_SWITCH format error.

Go: net/http, Echo and Fiber

The standard library doesn't decode Brotli. We sent a valid Brotli body with Content-Encoding: br to an httptest server and fetched a Brotli response with the default client, on Go 1.27.3:

server: Content-Encoding="br", body 28 bytes, equals compressed: true
client sent Accept-Encoding="gzip"
client: Content-Encoding="br", Uncompressed=false, body equals compressed: true

The handler got the 28 compressed bytes, and the Transport only advertises and transparently decodes gzip. A plain net/http service decodes Brotli only where your code, or a middleware you added, calls a decoder. Echo's middleware.Decompress doesn't count either: in v4.16.2 it only acts when Content-Encoding is gzip.

Fiber v2 is different. In Fiber's ctx.go, Ctx.Body() reads Content-Encoding and calls fasthttp's BodyGunzip, BodyUnbrotli or BodyInflate for each listed coding; only BodyRaw() returns the bytes as sent. The test handler:

app.Post("/", func(c *fiber.Ctx) error {
	fmt.Printf("BodyRaw(): %d bytes\n", len(c.BodyRaw()))
	fmt.Printf("Body():    %d bytes %s\n", len(c.Body()), c.Body())
	return nil
})

BodyRaw(): 28 bytes
Body():    33 bytes {"msg":"hello hello hello hello"}

Which decoder that is depends on the fasthttp version. fasthttp v1.74.0, released September 7, 2026, replaced andybalholm/brotli with github.com/molecule-man/go-brrr, a separate pure-Go implementation. But Fiber v2.52.16's own go.mod only requires fasthttp v1.51.0, so a new project gets the old pair:

$ go get github.com/gofiber/fiber/v2@v2.52.16
$ go list -m github.com/valyala/fasthttp github.com/andybalholm/brotli
github.com/valyala/fasthttp v1.51.0
github.com/andybalholm/brotli v1.1.0

Don't count on govulncheck to point this out, just as it stayed quiet for the Go 1.27.3 certificate distrust at first. The Go vulnerability database has no report for andybalholm/brotli, and govulncheck v1.9.0 on that module listed an authorization bypass in fasthttp's path handling (GO-2026-4950, fixed in v1.70.0) and two module-level findings, nothing about Brotli. The same run is a reason to move fasthttp forward anyway:

go get github.com/valyala/fasthttp@latest      # v1.74.0+ no longer uses andybalholm/brotli
go get github.com/andybalholm/brotli@v1.2.7    # if anything else still imports it

After go get github.com/andybalholm/brotli@v1.2.7 the Fiber test above decoded the same body unchanged. Neither the disclosure site nor any advisory we found mentions go-brrr, so we have nothing to report about it.

The C path in Go is github.com/google/brotli/go/cbrotli. Its cgo.go links libbrotlicommon libbrotlidec libbrotlienc through pkg-config, so a binary built with it depends on the libbrotli on the build or runtime machine. The fix there is updating the OS or Homebrew package; go get won't change it.

To check binaries that are already deployed, read the module list Go embeds in them:

go version -m ./server | grep -E 'brotli|fasthttp|fiber'

On our Fiber test build that printed github.com/andybalholm/brotli v1.1.0 and github.com/valyala/fasthttp v1.51.0. A github.com/google/brotli/go/cbrotli dependency shows up in the same list.

Rust: actix-web decodes by default

The same test in Rust used 1.99.1 with actix-web 4.18.1 on its default features, plus axum 0.8 with and without tower-http's RequestDecompressionLayer:

compressed body:   28 bytes
actix-web handler: 33 bytes, decoded: true
(no layer)   axum handler:      28 bytes, decoded: false
(with layer) axum handler:      33 bytes, decoded: true

actix-web decompresses br request bodies with no configuration; axum does it only when you add the layer. Both use Dropbox's pure-Rust decoder:

$ cargo tree -i brotli-decompressor@6.0.1 -e normal
brotli-decompressor v6.0.1
└── brotli v9.0.0
    ├── actix-http v3.19.0
    │   └── actix-web v4.18.1
    │       └── rscheck v0.1.0
    └── compression-codecs v0.4.46
        └── async-compression v0.4.51
            └── tower-http v0.6.11
                └── rscheck v0.1.0

The disclosure site says this decoder returns an error for the malformed input, so the common Rust web stacks aren't in the code-execution group. Its repository has no CVE-related commit since disclosure, which is consistent with that.

In Rust, the exposure is in the C bindings. brotlic 0.8.2, the latest release (January 2024), depends on brotlic-sys 0.2.2, whose build.rs always compiles the bundled C sources with cc, and the bundled version.h says #define BROTLI_VERSION 0x1000009, which is Brotli 1.0.9, inside the affected range. There's no system-library option to fall back on, so replacing the crate or patching the vendored source is the fix until a new release ships. The older brotli-sys 0.3.2 (2017) bundles Brotli 0.6.0, which predates the advisory's 1.0.3 lower bound, though a snapshot from 2017 is worth replacing for its own sake.

Find either one with:

cargo tree -i brotlic-sys
cargo tree -i brotli-sys

HTTP clients

The decoder also runs on responses your service fetches from other hosts, not only on request bodies. In Go, the default client doesn't decode br (see the net/http run above), so check for code that wraps a response body in a Brotli reader. In Rust, look for the same crates in the dependency tree of your HTTP client. If the decoder is a pure Go or Rust port, apply the version bumps above. If it is the C library in any form, it needs 1.0.10, 1.1.1 or 1.2.1 or later.

Originally published on ImportStatic. This article was drafted with AI assistance; every claim was checked against the sources linked in it and the code samples were compiled and run.