The scriptable txMozillaXSLTProcessor::ImportStylesheet entry point could be invoked repeatedly on the same processor instance, but it never reset the state left behind by a previous compilation attempt. If an earlier operation had populated mEmbeddedStylesheetRoot or left mCompileResult holding a stale value, a subsequent ImportStylesheet call would begin compiling a new stylesheet while inconsistent bookkeeping still pointed at nodes tied to the prior document, whose lifetime the processor no longer controlled. This violated the invariant that a fresh import starts from a clean compile state, so a later transform could dereference freed or reused DOM nodes reachable through the stale root, producing a use-after-free.

The fix asserts mEmbeddedStylesheetRoot is empty at entry to catch the invalid state in debug builds and unconditionally sets mCompileResult = NS_OK, ensuring the new compilation’s success/failure tracking cannot be poisoned by residue from a previous call. With the compile result forced to a defined baseline before the new stylesheet is processed, the transform path no longer proceeds on the basis of stale, dangling state.

An attacker who can run script in a content process gains a use-after-free during XSLT processing, giving them a potentially exploitable crash and a primitive that, with heap grooming, could be escalated toward memory disclosure or code execution within that content process. Exploitation requires only that the page perform a sequence of XSLTProcessor operations with attacker-controlled XSLT data, so no special privileges or user interaction beyond visiting a malicious page are needed. The defect is rated high impact because it is reachable directly from untrusted web content through standard DOM APIs.