The patch modifies PingLoader::sendPing() in Source/WebCore/loader/PingLoader.cpp, the code path that issues hyperlink auditing pings (the ping attribute on anchors, and related beacon-style POSTs).

Before the fix, sendPing() obtained the document and immediately called upgradeInsecureRequestIfNeeded() and built the POST request without ever consulting the document’s Content Security Policy about whether the ping destination was an allowed connection target.

The fix inserts, right after Ref document = *frame.document(), a guard: if (!document->checkedContentSecurityPolicy()->allowConnectToSource(pingURL)) return;. The violated invariant is that network requests initiated on behalf of a document must be vetted against that document’s CSP, and specifically that ping/auditing requests fall under the connect-src directive (the same directive governing fetch/XHR/WebSocket/beacon connections). Because sendPing() skipped allowConnectToSource(), a page could send a ping to a host that its own connect-src policy forbade, so CSP was not enforced for this request type. The added layout tests confirm the semantics precisely: connect-src-ping-allowed.html declares connect-src including localhost:8443 and expects the ping to proceed, while connect-src-ping-blocked.html omits localhost:8443 and expects the console message ‘Refused to connect to https://localhost:8443/ because it does not appear in the connect-src directive of the Content Security Policy.’

The fix restores the invariant by consulting CSP and returning early (silently dropping the ping) when the destination is not permitted, matching how other connect-src-governed loads are gated.

This is a security-policy enforcement bypass, not a memory-safety issue: the primitive is the ability to send a ping POST to a host that the page’s connect-src should have blocked, usable for tracking or small-scale exfiltration/beaconing and to defeat a CSP-based containment expectation. There is no memory corruption, no OOB/UAF, and no direct path to code execution; the impact is confined to weakening a policy control within the WebContent process’s networking on behalf of the document. Severity is medium precisely because it undermines a defense-in-depth control rather than granting new memory capabilities.