WebGPU importExternalTexture bypasses cross-origin video pixel protection

Summary

WebKit enforced cross-origin pixel protection on the Canvas2D path but not on the WebGPU external-texture path. A cross-origin <video> element that Canvas2D correctly refused to expose could be imported as a GPU external texture through GPUDevice.importExternalTexture(), sampled in a shader, and read back — disclosing pixel data from an origin the page had no right to read.

Apple describes the impact as: “A malicious website may exfiltrate data cross-origin.” The issue was addressed with improved checks.

The inconsistency

Loading a cross-origin video without CORS approval taints it. The Canvas2D path honours that taint — drawing the video to a canvas and calling getImageData() throws a SecurityError, and this has been true for many years.

The WebGPU external-texture path reached the same underlying decoded frames without applying the equivalent check. The protection was a property of one API surface rather than of the media resource, so a second consumer of the same frames inherited none of it.

Where the pixels land

The severity of this class depends on more than the pixel read itself. In WebKit’s process model, WebGPU work is not performed in the WebContent sandbox — it is serviced by a separate GPU process, com.apple.WebKit.GPU.

Enumerating that process’s entitlements on the affected build shows a sink considerably more privileged than the renderer that requested the work:

$ codesign -d --entitlements - \
  /System/Library/Frameworks/WebKit.framework/Versions/A/\
  XPCServices/com.apple.WebKit.GPU.xpc

com.apple.aneuserd.private.allow
com.apple.private.disable.screencapturekit.alert
com.apple.private.coremedia.allow-fps-attachment
com.apple.developer.videotoolbox.client-sandboxed-decoder
com.apple.avfoundation.allow-system-wide-context
com.apple.QuartzCore.webkit-end-points

This is entitlement enumeration of the process that receives the cross-origin data, not a demonstrated escalation. No privilege escalation was proven, and none is claimed. It is included because it establishes which boundary the untrusted data actually crosses, which is the relevant question when weighing a cross-origin read that terminates in the GPU process rather than the renderer.

Timeline

• ReportedSubmitted to Apple Security Bounty against Safari 26.1 (26621.2.7.11.6) on macOS Tahoe 26 (build 26A5615), Apple Silicon M1, GPU process WebKit 624.2.5.
• AcknowledgedReproduced by Apple; fix scheduled.
• FixedAddressed with improved checks in Safari 26.5.2, iOS and iPadOS 26.5.2, macOS Tahoe 26.5.2, tvOS 26.6, visionOS 26.6, and watchOS 26.6.
• 2026-07-21 · VerifiedIndependently re-tested against the shipped build. The import now fails closed.

Verification

On patched Safari 26.5.2, the external-texture import is rejected at the boundary:

SecurityError: GPUDevice.importExternalTexture:
  Cross origin external videos are not allowed in WebGPU

The adjacent sinks were re-tested at the same time and also fail closed: GPUQueue.copyExternalImageToTexture(), the VideoFrame constructor, createImageBitmap() into a canvas, and WebGL texImage2D() followed by readPixels(). The cross-origin video read class is closed on this build, not merely the single reported entry point.

Credit

Reported by Merrick Hare, Enterprise Hare LLC. Apple credited multiple independent reporters for this issue in the Safari 26.5.2 security release.

References

• NVD — CVE-2026-43735
• Apple — About the security content of Safari 26.5.2

No proof-of-concept code is published. The fix is generally available, but unpatched builds remain in use, and the writeup above is sufficient to understand the class.