The vulnerable code path was PdfStreamConverter.prototype.getConvertedType, which selected the PDF.js viewer for a response without accounting for the case where the underlying channel was an nsIMultiPartChannel. When a server returned a multipart/x-mixed-replace response containing a PDF part, the stream converter would still route the multipart channel to the PDF.js viewer, and the viewer document ended up loaded under the privileged resource://pdf.js origin while an attacker retained influence over subsequent parts of the same channel. This violated the invariant that only a single, well-formed PDF response should be promoted into the resource://pdf.js viewer context, allowing attacker-controlled content to run script in that privileged origin and read cross-origin PDF data.

The fix adds an explicit type check at the top of getConvertedType: if aChannel instanceof Ci.nsIMultiPartChannel, it throws Components.Exception with Cr.NS_ERROR_NOT_IMPLEMENTED, refusing to convert multipart responses at all. Because PDF.js was never designed to handle the sequential-replacement semantics of multipart channels, rejecting them outright removes the confused-deputy behavior rather than trying to sanitize each part.

An attacker gains arbitrary JavaScript execution under the privileged resource://pdf.js origin, enabling theft of cross-origin PDF content. On desktop this is constrained to “same site” documents by Site Isolation, while on Android full cross-origin access is possible. The only precondition is that the victim loads an attacker-controlled URL that returns a specially crafted multipart/x-mixed-replace response.