After the upgrade to Fedora 44 from 43, I’m having a crash when I try to build a website with Hugo (specifically, any website that uses webp features, like Resize). I’ve been able to reproduce this issue on two different machines, with the same error message on both. This crash doesn’t occur when I try to build the site with the pre-built binary from Hugo.

Here’s the exact versions of packages I have installed:
hugo-0.159.0-1.fc44
kernel-7.0.4-200.fc44
Fedora 44 (Workstation Edition) x86_64

Output of `hugo version`:
hugo v0.159.0+extended linux/amd64 BuildDate=2026-03-24T00:00:00+00:00 VendorInfo=Fedora:0.159.0-1.fc44


Reproducible: Always

Steps to Reproduce:
1.Create a hugo site that contains some sort of webp transformation, for example:

	<!-- load image -->
	{{ $image := resources.Get "images/test.png" }}
	<!-- resize and convert to webp -->
	{{ $image := $image.Resize "1000x webp q90" }}

2. Try to build/serve the site (via `hugo build` or `hugo server`; make sure to clear your `resources/_gen_` folder first).
Actual Results:
The site should build without any errors and successfully generate the transformed WebP files.

Expected Results:
Hugo crashes.

Additional Information:
It crashes with an error log. Here's the part that I think is relevant - I will attach the full log.

Start building sites … 
hugo v0.159.0+extended linux/amd64 BuildDate=2026-03-24T00:00:00+00:00 VendorInfo=Fedora:0.159.0-1.fc44

unexpected fault address 0x7f0b64df7000
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x2 addr=0x7f0b64df7000 pc=0x56089e77c006]

goroutine 38 gp=0x109ddfb343c0 m=12 mp=0x109ddef80808 [running]:
runtime.throw({0x56089fc111dc?, 0x109ddfb820e0?})
	/usr/lib/golang/src/runtime/panic.go:1229 +0x4a fp=0x109ddf6c53f0 sp=0x109ddf6c53c0 pc=0x56089e84a3ea
runtime.sigpanic()
	/usr/lib/golang/src/runtime/signal_unix.go:945 +0x285 fp=0x109ddf6c5450 sp=0x109ddf6c53f0 pc=0x56089e84c6e5
github.com/gohugoio/hugo/vendor/github.com/tetratelabs/wazero/internal/engine/wazevo.(*callEngine).callWithStack(0x109ddffec008, {0x5608a1423098, 0x109ddfb82000}, {0x5608a1c3bfe0, 0x0, 0x109ddffec008?})
	/builddir/build/BUILD/hugo-0.159.0-build/hugo-0.159.0/_build/src/github.com/gohugoio/hugo/vendor/github.com/tetratelabs/wazero/internal/engine/wazevo/call_engine.go:281 +0x267 fp=0x109ddf6c5820 sp=0x109ddf6c5450 pc=0x56089f303787
github.com/gohugoio/hugo/vendor/github.com/tetratelabs/wazero/internal/engine/wazevo.(*callEngine).Call(0x109ddffec008, {0x5608a1423098, 0x109ddfb82000}, {0x0?, 0x109ddf44b200?, 0x5608a1439800?})
	/builddir/build/BUILD/hugo-0.159.0-build/hugo-0.159.0/_build/src/github.com/gohugoio/hugo/vendor/github.com/tetratelabs/wazero/internal/engine/wazevo/call_engine.go:141 +0x134 fp=0x109ddf6c5890 sp=0x109ddf6c5820 pc=0x56089f303074
github.com/gohugoio/hugo/internal/warpc.newDispatcher[...].func4.1()
	/builddir/build/BUILD/hugo-0.159.0-build/hugo-0.159.0/_build/src/github.com/gohugoio/hugo/internal/warpc/warpc.go:688 +0xed2 fp=0x109ddf6c5f78 sp=0x109ddf6c5890 pc=0x56089f336592
github.com/gohugoio/hugo/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1()
	/builddir/build/BUILD/hugo-0.159.0-build/hugo-0.159.0/_build/src/github.com/gohugoio/hugo/vendor/golang.org/x/sync/errgroup/errgroup.go:93 +0x50 fp=0x109ddf6c5fe0 sp=0x109ddf6c5f78 pc=0x56089f1fa1b0
runtime.goexit({})
	/usr/lib/golang/src/runtime/asm_amd64.s:1771 +0x1 fp=0x109ddf6c5fe8 sp=0x109ddf6c5fe0 pc=0x56089e852001
created by github.com/gohugoio/hugo/vendor/golang.org/x/sync/errgroup.(*Group).Go in goroutine 146
	/builddir/build/BUILD/hugo-0.159.0-build/hugo-0.159.0/_build/src/github.com/gohugoio/hugo/vendor/golang.org/x/sync/errgroup/errgroup.go:78 +0x95



It looks like the crash occurs in the Wazero runtime. Since version v0.153.0, hugo has been using wasm to encode and decode webp files, which runs on Wazero (see PR: https://github.com/gohugoio/hugo/pull/14234).

Based on my digging, it looks like it might be related to new linker options in Fedora 44 added for security. I found an issue (https://github.com/wazero/wazero/issues/2469) on the Wazero repo (which links to other Fedora bugs). I’m not sure if this is the issue, just thought it might help. I've also made a post on the Fedora community first: https://discussion.fedoraproject.org/t/hugo-crash-after-upgrade-to-fedora-44/191076