Ladybird vulnerabilities

In the Ladybird browser prior to commit 209579c, FinalizationRegistry::cleanup() removed a dead record, retained an iterator to the next record, and then invoked attacker-controlled JavaScript through the cleanup callback. If that callback called unregister() for the next record, the retained iterator referenced a freed node, and the next iteration read its fields after free.

In the Ladybird browser prior to commit c0d68bd, CSSStyleSheet.cssRules, insertRule(), and deleteRule() did not enforce the stylesheet origin-clean flag with the required SecurityError, even though cross-origin imported stylesheets were correctly marked non-origin-clean. A malicious page could read rules and insert or delete rules in the victim stylesheet, bypassing the Same-Origin Policy.

Ladybird before commit 2f9dc7e contains a dangling-reference memory-safety flaw in its WebAssembly ESM-integration module loader. When a JavaScript function is imported into a WebAssembly module via the ESM path, WebAssemblyModule.cpp passes a stack-local Wasm::FunctionType by reference to create_host_function, whose host callback captures and later reads that reference; once the ESM link-loop iteration ends the FunctionType is destroyed, leaving the callback with a dangling reference. Stale result-type data lets the host callback return an empty result vector for a statically non-empty result, so the destination register retains an attacker-influenced value that is then consumed by the WASM-GC array.set handler, which bit-casts the reference low bits to an ArrayInstance pointer after only a null check, yielding an arbitrary write.