WebGPU importExternalTexture bypasses cross-origin video pixel protection.

On June 3, 2026, I reported a WebKit issue involving GPUDevice.importExternalTexture(). The function did not perform the same origin-clean validation already used by GPUQueue.copyExternalImageToTexture().

This matters because cross-origin video can be displayed by a page without making its pixels available for arbitrary inspection. The browser needs to keep that distinction intact when media moves into GPU resources.

What I found

The existing helper in GPUQueue.cpp already handled the relevant source types. For an HTML video element, it checks whether the video taints the current security origin:

static bool isOriginClean(const auto& source, ScriptExecutionContext& context)
{
    return WTF::switchOn(source,
        [&](const Ref<ImageBitmap>& imageBitmap) -> ResultType {
            return imageBitmap->originClean();
        },
        [&](const Ref<HTMLVideoElement>& videoElement) -> ResultType {
            return !videoElement->taintsOrigin(*protect(context.securityOrigin()).get());
        },
        // ... checks for all source types
    );
}

That helper is correctly called by copyExternalImageToTexture(). An unsafe source returns a SecurityError instead of being copied:

if (!isOriginClean(source.source, context))
    return Exception { ExceptionCode::SecurityError,
        "GPUQueue.copyExternalImageToTexture: Cross origin external images are not allowed in WebGPU" };

The corresponding import path in GPUDevice.cpp did not make the same call before passing the descriptor to the backing implementation:

GPUDevice::importExternalTexture(GPUExternalTextureDescriptor&& descriptor)
{
    // No call to isOriginClean() here.
    RefPtr texture = m_backing->importExternalTexture(
        descriptor.convertToBacking());
    // ...
}

So the issue was not that WebKit lacked the right security helper. The helper existed and was already used in one WebGPU operation. The problem was that the external-texture import path did not apply the same check.

In practice, that creates a path for cross-origin video to enter WebGPU without the same origin protection enforced by Canvas2D and the copy operation. The security impact is cross-origin pixel exposure: media that should remain display-only can become available to GPU processing in a way the browser did not intend.

Report status

I reported the issue under OE1106482654518. Apple marked it addressed, assigned CVE-2026-43735, and listed tvOS 26.6 and visionOS 26.6 as addressed releases. The report also indicated that additional releases were being addressed and that the submission was under review for Apple Security Bounty eligibility.

The fix is to apply the same isOriginClean() validation to GPUDevice::importExternalTexture() before the external texture is imported.

The useful lesson is simple: when a browser has multiple APIs that move pixels across an origin boundary, every entry point needs to enforce the same policy.