EUVD-2026-93711
GHSA-9p29-6whr-c3j2
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to crafted HTML page
-
ExploitOverlay or disguise PermissionElement UI
-
ExecutionTrick user into clicking spoofed control
-
ImpactGrant unintended permission or spoofed action
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V3 - Web Frontend Security Clickjacking prevention, X-Frame-Options
|
| Exploitation Conditions | Exploitation requires the victim to visit an attacker-controlled crafted HTML page and to actively interact with it (UI:R), with success depending on social engineering to defeat visual cues around Chrome's PermissionElement. It affects Chrome versions prior to 155.0.8059.39 on default configurations, so the primary limiting factors are the mandatory user interaction, the need for a convincing lure, and the fact that updated/auto-updated Chrome installs are not affected; no authentication or special browser configuration is required. |
| Impact | This is a genuine but modest-priority issue, consistent with its Medium rating. The CVSS 5.4 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L) indicates a network-reachable, low-complexity, unauthenticated flaw, but exploitation is gated by required user interaction (UI:R) and reliance on social engineering, which materially lowers real-world risk. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The scope is unchanged and impacts are limited (C:L/I:N/A:L), matching a clickjacking/UI-spoofing weakness (CWE-1021) rather than code execution. Note a minor signal tension: the input Tags include 'XSS', but the description and CWE-1021 describe clickjacking/UI spoofing, not cross-site scripting - treat the XSS tag as mislabeled. Overall this is a high-prevalence-product, low-severity issue best handled via routine browser auto-update rather than emergency patching. |
| Exploit ScenarioDerived | A remote attacker crafts a malicious HTML page that visually overlays or disguises Chrome's PermissionElement so that a victim, lured to the page, is tricked into interacting with a spoofed UI control. Because user interaction is required (UI:R) and no public exploit is identified, success depends on convincing social engineering rather than an automatable drive-by. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Clickjacking in Google Chrome's PermissionElement lets remote, unauthenticated attackers spoof browser UI through a crafted HTML page, so a victim who visits the page may be misled about which control they are actually interacting with and could disclose information or take an unintended action. Only Chrome builds prior to 155.0.8059.39 on default configurations are affected, and exploitation requires the victim to both visit the attacker-controlled page and actively click or interact with it (UI:R), meaning a convincing social-engineering lure is the primary precondition rather than any missing browser hardening. Google has shipped a stable-channel fix, no public exploit code has been identified at time of analysis, and the issue is rated Medium with a base CVSS of 5.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N per independent assessment).
RemediationAI
Apply the vendor fix by upgrading Google Chrome to 155.0.8059.39 or later (Vendor-released patch: 155.0.8059.39); the simplest path is to allow Chrome's auto-update to complete and then confirm the version on chrome://version, and to restart the browser so the new build is actually running rather than merely downloaded. Enterprise administrators who manage Chrome through Google Update or an MDM can push the stable-channel update policy so that all managed endpoints land on the fixed build without relying on user action, and should verify fleet-wide version compliance afterward since a relaunch may be required for the patch to take effect. Because the weakness is a clickjacking/UI-spoofing condition in the client, there is no server-side or proxy mitigation that removes the risk; if immediate upgrading is impossible, the practical compensating controls are behavioral and administrative rather than technical - instruct users not to grant permissions or act on unexpected permission prompts originating from pages they did not intentionally seek out, and, where acceptable, use enterprise URL blocklisting or Safe Browsing policies to restrict access to untrusted or newly registered domains, accepting the trade-off that this slows legitimate browsing and generates administrative overhead. Disabling the relevant permission features via browser policy would remove the spoofable surface but also break legitimate sites that rely on that capability, so it should be considered only as a short-term stopgap. Full details and the patch reference are in the Chrome release advisory at https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause class is CWE-1021 (Improper Restriction of Rendered UI Layers or Frames), the classic clickjacking weakness. Chrome's PermissionElement is a browser-rendered control that sites embed in page content to present a permission request (for example for capabilities such as geolocation, camera, or notifications) in a native-looking form. Because this element draws privileged-looking browser chrome inside a page's rendering context, insufficient isolation between the page's own layers and the element's rendered layers allows an attacker to stack transparent iframes, CSS overlays, or repositioned content over or around the element so that the visual presentation a user sees does not match what is actually clicked. The result is UI spoofing rather than direct memory corruption or code execution: the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N shows a network-reachable, unauthenticated issue with unchanged scope and only low confidentiality and integrity impact, all gated behind mandatory user interaction. Chromium's own triage classified it as Medium severity, and the source tags (XSS, Google) reflect the crafted-HTML-page delivery mechanism used to induce the interaction. The fix lives in the Chromium rendering/permission-element code and is noted in the Chromium issue tracker entry referenced by the advisory.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
Remote crafted page, no auth, but mandatory user interaction (UI:R); clickjacking spoofs UI to deceive the user (I:L/C:L) with no availability impact.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
4DescriptionCVE.org
Clickjacking in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium)
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB