A couple days ago, Google shipped Chrome 150 with 433 security fixes. Of the 433 entries in the release notes, 401 list Google as the reporter. Just 32 credit outside researchers.
Buried deep was one of ours:
CVE-2026-14077: Incorrect security UI in Select. Reported by pwn.ai.
During a leisure run, Pwn received one deliberately broad objective: find a strange privacy or browser-boundary bug in Chrome. That was the full extent of the human direction. Pwn, using an open source LLM base, chose where to look, explored the browser's native UI surfaces, found the primitive, built the PoC, and developed the exploit chain autonomously.
There was no memory corruption, no renderer escape, and no heroic heap feng shui. There was just an HTML <select>, placed a little too high on the page.
A <select> Is Not Just Page Content
HTML normally cannot draw over Chrome's toolbar. A page can create the best fake address bar in the world, but it remains inside the page. The real omnibox stays above it, on the other side of what browser-security people call the line of death.
A native <select> breaks that clean model. The page supplies the control, its options, and its geometry. Chrome or the operating system supplies the popup that appears when it opens. That popup cannot be clipped to the element's box normal dropdowns need to extend beyond their controls so Chrome hands its rectangle to an external UI surface.
That handoff was the bug. The renderer supplied a rectangle. The popup trusted it.
Chrome already rejected selects that were completely outside the visual viewport. Pwn used the state between “inside” and “outside”: a control that began above the viewport but was tall enough to still intersect it.
The PoC defaults made the geometry unusually obvious:
--sel-left: 134px;
--sel-top: -35px;
--sel-w: 1580px;
--sel-h: 10000px;
The select started at y = -35, but continued for another 10,000 pixels. Its rectangle therefore satisfied:
select.top < viewport.top < select.bottom
Chrome's visibility check saw the intersection and allowed the picker to open. The external popup still received geometry derived from the negative anchor. On macOS, it followed that anchor upward, left the web contents, and entered the toolbar.
The other numbers were not random either. The 1,580-pixel width covered the complete omnibox so there was no two-tone seam between real and fake UI. The left offset began over Chrome's site-information icon. A live calibration panel adjusted the position, width, font, letter spacing, and colors for the current window and display scale.
At this point Pwn had attacker-programmed UI above the line of death. That was the primitive. It was not yet the exploit.
Building an Omnibox Inside the Popup
The original report used a simple version of the spoof. history.replaceState() changed the local URL to:
http://127.0.0.1:8765/spoofing.html?https://accounts.google.com/download/chrome
The native popup covered the truthful prefix, leaving the Google-shaped suffix visible. This was enough to prove that renderer-influenced UI could hide the real origin.
Then Pwn made it much better.
Instead of merely using the popup as a curtain, v2 used the popup as the omnibox renderer. The trusted-looking URL was painted inside Chrome's picker itself.
The first strategy kept the classic native select. The control was transparent and stretched across the toolbar. Its single option carried the fake URL, with its foreground and background matched to the current omnibox theme:
<select>
<option> accounts.google.com/download/chrome</option>
</select>
Setting selectedIndex = -1 before opening the picker removed the native checkmark. The leading spaces cleared the gutter where that checkmark would normally appear. Making the option span the entire omnibox removed the obvious boundary between Chrome's pixels and the popup's pixels.
That was already convincing, but the native popup retained a few things CSS could not remove: its pill shape, shadow, and rounded corners.
Chrome's customizable select path provided a second strategy:
select, ::picker(select) {
appearance: base-select;
}
#floating-select {
anchor-name: --omni;
width: 1px;
height: 1px;
opacity: 0;
}
::picker(select) {
position-anchor: --omni;
top: anchor(top);
left: anchor(left);
margin-top: var(--sel-top);
border: 0;
padding: 0;
background: transparent;
box-shadow: none;
}
Now the select itself was only an invisible one-pixel anchor. Its picker was fully styleable, and Pwn pulled that picker upward into the toolbar with a negative margin.
The option contained an actual fake omnibox: Chrome 147's tune icon drawn as SVG, the scheme omitted exactly as Chrome omits it, accounts.google.com in the primary text color, /download/chrome in the dimmed path color, and typography calibrated to the real address bar. Light and dark themes were both supported.
<span class="host">accounts.google.com</span><span class="path">/download/chrome</span>
Chrome did not merely hide the real URL. It carried the replacement URL into browser chrome on a popup surface the page was allowed to program but was never supposed to position there.
The <select> was the escape primitive. The exploit was the omnibox compositor Pwn built inside it.
Spending One Click Five Times
The rest of the exploit was choreography. Chrome requires a real user activation for showPicker(), and downloads are more credible when they begin directly after a click. Pwn spent the same Continue click on the entire chain:
replaceAddress();
document.body.classList.add("armed");
forceDownload();
openNativePicker();
setTimeout(freezeRenderer, 60);
startRedirect();
replaceAddress() called history.replaceState(). This did not and could not change the origin; it made the real address state consistent with the Google-shaped path and supported the original crop-based version.
forceDownload() created a hidden iframe whose response used Content-Disposition: attachment. No second click or visible download link was needed.
openNativePicker() cleared the selection, focused the control, and called showPicker() while the transient user activation was still live.
Then came a small but important reliability trick. Sixty milliseconds after the picker opened, the PoC blocked the renderer for 8.5 seconds:
const end = performance.now() + 8500;
while (performance.now() < end) {
// keep the renderer busy after the external popup has painted
}
The picker was already on screen. Freezing the renderer held that external UI state in place instead of letting the page immediately repaint or advance. Under it, the document had already switched to Follow the Installation to Continue. After the hold, the countdown completed and the page redirected to the real google.com, neatly closing the story.
The report sent to Google kept the payload harmless: localhost, no credentials, and a text marker named ChromeSetup-demo.txt. After the CVE became public, Pwn extended the demonstration. v2 downloads ChromeSetup.sh; when the victim manually executes it, Calculator opens.
That last step is not drive-by RCE or a Chrome sandbox escape. The browser does not execute the file. The exploit attacks the decision immediately before execution by making Chrome's strongest origin signal say the file came from somewhere it did not.
Every individual operation looked permitted:
- The select intersected the viewport.
- The picker opened from a real user activation.
replaceState()remained same-origin.- The iframe response was allowed to become a download.
- The page was allowed to replace its own contents.
The exploit lived in their composition.
Chrome Fixed the Rectangle
“This seems legitimate; we're seeing a lot of cases where UI generated by a renderer can eclipse important parts of the browser UI.”
The first Chromium fix clipped the popup anchor to the visual viewport before handing it to the external UI:
CHECK(viewport_rect.Intersects(rect_in_viewport));
rect_in_viewport.Intersect(viewport_rect);
The missing Intersect() was only one line. Everything after it: the calibrated popup, checkmark suppression, fake site-information icon, URL typography, history update, download, renderer freeze, install page, and redirect was the exploit work that turned one bad rectangle into a believable Google Chrome download.
Pwn later connected the result to a P1/S2 URL spoof reported in 2017. That bug used an omnibox timing trick and a modal dialog. This one used picker geometry. Different mechanism, same broken invariant: page-triggered UI must not cover the browser UI that identifies which page triggered it. Chrome assigned CVE-2026-14077 and credited pwn.ai in the Chrome 150 release.
Pwn began with no hint about selects, native widgets, URL spoofing, downloads, or the 2017 bug. It found the coordinate bug, turned the escaped picker into a drawing primitive, removed the visual tells, and assembled the complete one-click flow autonomously.
Fun bug. hopefully you enjoyed the read.