crowdsecurity/crowdsec · critical

GOARCH %s has no wasm compiler backend

Error message

GOARCH %s has no wasm compiler backend

What it means

compilerSupported rejects architectures for which wazero's compiler backend does not exist in this build (it explicitly checks amd64 SSE4.1 and falls back to an error for other GOARCH values). newWazeroRuntime wraps it as 'wasm compiler mode unavailable'. The AppSec challenge runtime cannot start in compiler mode on this platform.

Source

Thrown at pkg/appsec/challenge/challenge.go:356

	return compiledMod, nil
}

// compilerSupported mimics the check performed by wazero for SSE4.1
// We cannot rely in wazero on the wazero check, as it is used to choose whether to use the compiler or interpreter mode
// If we force the compiler mode, and it's not supported, we will crash with SIGILL on the 1st instruction.
// Compiler mode is required as interpreter mode is way too slow for the obfuscation (measured as being at least 60 times slower)
func compilerSupported() error {
	switch runtime.GOARCH {
	case "arm64":
		return nil
	case "amd64":
		if !cpu.X86.HasSSE41 {
			return errors.New("CPU lacks SSE4.1")
		}

		return nil
	default:
		return fmt.Errorf("GOARCH %s has no wasm compiler backend", runtime.GOARCH)
	}
}

func newWazeroRuntime(ctx context.Context) (wazero.Runtime, error) {
	if err := compilerSupported(); err != nil {
		return nil, fmt.Errorf("wasm compiler mode unavailable: %w", err)
	}

	var r wazero.Runtime
	var err error

	func() {
		// wazero checks for executable memory, and panics if it cannot allocat it.
		// Catch the panic and return an error instead, so we can provide a more helpful message to the user.
		defer func() {
			if rec := recover(); rec != nil {
				err = fmt.Errorf("failed to create wasm runtime in compiler mode: %v "+
					"(the kernel likely denied an executable memory mapping: check W^X hardening, seccomp or SELinux policy)", rec)

View on GitHub (pinned to 909b515798)

Solutions

1. Run on a supported architecture: linux/amd64 (with SSE4.1) or arm64.
2. Check your CPU supports SSE4.1 on amd64: grep sse4_1 /proc/cpuinfo.
3. Use an official crowdsec build for your platform rather than a self-compiled cross-build.
4. If you must run on an unsupported arch, raise an upstream issue to add an interpreter-mode fallback.

Example fix

// before
GOOS=linux GOARCH=386 go build ./cmd/crowdsec
// after
GOOS=linux GOARCH=amd64 go build ./cmd/crowdsec

// Guard before initializing AppSec challenge support
if runtime.GOARCH != "amd64" && runtime.GOARCH != "arm64" {
    // challenge runtime compiler backend unavailable; disable appsec or use interpreter mode
}

When it happens

Trigger: Building/running on GOARCH other than amd64/arm64 (e.g. 386, arm, riscv64) where newWazeroRuntime calls compilerSupported and hits the default case.

Common situations: Running crowdsec on 32-bit ARM boards (Raspberry Pi OS armv6/armv7), i386 builds, or unusual architectures; building with GOARCH overrides for embedded devices.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• failed to create gzip reader for obfuscator wasm: %w
• failed to decompress obfuscator wasm: %w
• failed to compile obfuscator wasm module: %w
• wasm compiler mode unavailable: %w
• failed to create wasm runtime in compiler mode: %v (the kern

AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06). Data as JSON: /api/errors/2491e28dbe65620b. Report an issue: GitHub.