PoC Archive PoC Archive
Medium CVE-2026-20643 patched

WebKit Navigation API Cross-Port canIntercept Bypass (CVE-2026-20643)

by Fliv (flvin.com) · 2026-07-05

Severity
Medium
CVE
CVE-2026-20643
Category
web
Affected product
WebKit (Safari / WebKit-based browsers), Navigation API implementation
Affected versions
Pre-fix WebKit builds (fixed by the linked upstream WebKit commit)
Disclosed
2026-07-05
Patch status
patched

Archive entry

intelseclab/poc-archive

Metadata

FieldValue
Date Added2026-07-05
Last Updated2026-03
Author / ResearcherFliv (flvin.com)
CVE / AdvisoryCVE-2026-20643
Categoryweb
SeverityMedium
CVSS ScoreNot specified in source
StatusPoC
Tagswebkit, browser, navigation-api, same-origin-policy, cross-port, javascript, test-page, canintercept
RelatedN/A

Affected Target

FieldValue
Software / SystemWebKit (Safari / WebKit-based browsers), Navigation API implementation
Versions AffectedPre-fix WebKit builds (fixed by the linked upstream WebKit commit)
Language / PlatformHTML/JavaScript test page, runs in a WebKit-based browser
Authentication RequiredNo
Network Access RequiredYes (requires serving the page on two distinct ports)

Summary

The Navigation API’s navigate event exposes an event.canIntercept flag that browsers must set to false for navigations that cross a security boundary the page is not allowed to intercept — including navigations to a different port on the same host. This PoC serves a page that programmatically clicks a link pointing at the same hostname on a different port and inspects event.canIntercept inside the navigate listener. On an unpatched WebKit, canIntercept was incorrectly reported as true for such cross-port navigations, meaning a page could intercept and manipulate a navigation that should be treated as crossing an origin boundary. The fix is tied to a specific upstream WebKit commit that corrects the port-comparison logic feeding into canIntercept.

Vulnerability Details

Root Cause

WebKit’s Navigation API implementation did not correctly treat differing port numbers as an origin boundary when computing event.canIntercept, so cross-port navigations were (incorrectly) reported as interceptable just like same-origin navigations.

Attack Vector

  1. Host a malicious page on one port (e.g. :8800) that a victim visits.
  2. The page registers a navigate event listener on the navigation object and programmatically triggers (or waits for) a navigation to the same hostname on a different port (e.g. :8000).
  3. Because event.canIntercept incorrectly evaluates to true, the script can call event.preventDefault() / intercept and manipulate what should be a cross-origin-equivalent navigation, in violation of the boundary the Navigation API is supposed to enforce for differing ports.

Impact

Weakens the Navigation API’s origin-boundary guarantees, letting a page intercept/manipulate navigations to a different port on the same host that should have been treated as non-interceptable; primarily a security-boundary/logic flaw rather than memory corruption.

Environment / Lab Setup

Target:   WebKit-based browser (pre-fix build)
Attacker: Static file server capable of serving the same page on two different ports (e.g. :8000 and :8800)

Proof of Concept

PoC Script

See index.html (standalone repro with an on-page log) and navigate-event-canintercept-cross-port.html (formal web-platform-tests-style assertion, requires the standard WPT testharness.js/testharnessreport.js helper scripts) in this folder.

1
2

python3 -m http.server 8000 &
python3 -m http.server 8800 &

The page registers a navigate listener, then synthesizes a click on a link pointing at the same hostname on the other port. It logs event.canIntercept and flags the case where it is not false, which indicates the cross-port boundary is not being enforced.

Detection & Indicators of Compromise

Signs of compromise:

  • Pages registering navigate event listeners that inspect or act on event.canIntercept for navigations to other ports on the same host.
  • Unexpected interception/rewriting of navigations that should cross a port boundary.

Remediation

ActionDetail
Primary fixUpdate to a WebKit build including the upstream fix commit (850ce3163e55ebaa33f712d05681e5522b518806), which corrects canIntercept to be false for cross-port navigations
Interim mitigationKeep Safari/WebKit-based browsers up to date; avoid relying on Navigation API interception behavior for security-sensitive logic until patched

References

Notes

Mirrored from https://github.com/Fliv/CVE-2026-20643 on 2026-07-05.

navigate-event-canintercept-cross-port.html
html raw GitHub ↓ Download
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<!DOCTYPE html>
<meta charset="utf-8">
<title>Navigation API: canIntercept should be false for cross-port navigations</title>
<script src="resources/testharness.js"></script>
<script src="resources/testharnessreport.js"></script>
<body>
<script>
promise_test(async t => {
  const currentPort = location.port || (location.protocol === 'https:' ? '443' : '80');
  const otherPort = currentPort === '8800' ? '8000' : '8800';
  const targetURL = `${location.protocol}//${location.hostname}:${otherPort}/`;
  
  const navigatePromise = new Promise((resolve) => {
    navigation.addEventListener("navigate", t.step_func(event => {
      // Cross-port navigation should have canIntercept === false
      console.log(`event.canIntercept: ${event.canIntercept}`);
      assert_equals(event.canIntercept, false, 
        `canIntercept should be false when navigating from port ${currentPort} to port ${otherPort}`);
      
      // Prevent the actual navigation
      event.preventDefault();
      resolve();
    }), { once: true });
  });
  
  // Trigger the cross-port navigation
  const anchor = document.createElement('a');
  anchor.href = targetURL;
  document.body.appendChild(anchor);
  anchor.click();
  
  await navigatePromise;
}, "canIntercept should be false for cross-port navigations");
</script>
</body>