wasm-unsafe-eval support was introduced in bug 1740263, initially with it being included in the default CSP of MV2 extensions for backwards-compatibility (decision documented at bug 1766027).
Shortly thereafter, we started to receive bug reports about broken extensions (e.g. bug 1770468 and bug 1770667), which had overridden that default CSP.

To offer more time to extensions to migrate, bug 1770468 was resolved by ignoring 'wasm-unsafe-eval' CSP violations: when an extension has set a custom CSP without 'wasm-unsafe-eval' in its script-src directive, violations are permitted and only reported (to the console, and observable to extensions via the securitypolicyviolation event).

Eventually we should remove this exception from bug 1770468, so that the CSP is properly enforced. The CSP feature and exception was introduced in Firefox 102, so we will need at least a few releases (consistent with WebExtensions/DeprecationPolicy) before deprecation.

Advice to extension developers

This only affects extensions that use WebAssembly and specify a custom content_security_policy, whether in manifest.json or in an extension page.
Extensions that wish to use WebAssembly AND specify a custom CSP should update script-src, to add 'wasm-unsafe-eval'.

Side note: Unlike MV2, 'wasm-unsafe-eval' is not included in the default CSP of MV3 extensions, so MV3 extensions that use WebAssembly must specify 'wasm-unsafe-eval' in their content_security_policy in manifest.json.

This only affects extensions that use WebAssembly and specify a custom content_security_policy, whether in manifest.json or in an extension page. Extensions that wish to use WebAssembly AND specify a custom CSP should update script-src, to add 'wasm-unsafe-eval'.

:TheOne FYI + any thoughts on how to communicate this change to affected developers? We know that many extensions have custom CSP but probably a tiny fraction of them use WASM..

(In reply to William Durand [:willdurand] from comment #1)

This only affects extensions that use WebAssembly and specify a custom content_security_policy, whether in manifest.json or in an extension page. Extensions that wish to use WebAssembly AND specify a custom CSP should update script-src, to add 'wasm-unsafe-eval'.

:TheOne FYI + any thoughts on how to communicate this change to affected developers? We know that many extensions have custom CSP but probably a tiny fraction of them use WASM..

I am not sure we have that capability at the moment. For are more precise list, one would have to download all versions of all add-ons that override the CSP and inspect each for the use of wasm.

Once we have that, communication itself is not a problem. We can do that through Acoustic, we only need the fxa_ids of these developers.