Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to crafted HTML page
-
ExploitAbuse PermissionElement to spoof UI
-
ExecutionVictim misled by fake UI element
-
ImpactUser grants permission or trusts content
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V3 - Web Frontend Security UI security representation
|
| Exploitation Conditions | Exploitation requires the victim to visit an attacker-crafted HTML page and to be deceived by the spoofed UI - i.e., active user interaction plus successful social engineering (UI:R in the vector). The specific affected feature is Chrome's PermissionElement, so the flaw manifests in the browser's permission-prompt UI rendering. Limiting factors: no attacker-controlled technical compromise occurs without human deception, exploitation cannot be automated (SSVC Automatable:no), and the affected product is any Google Chrome build prior to 155.0.8059.39; patched versions are not affected. |
| Impact | This is a genuine-but-low-priority issue. All exploitation signals point the same direction: CVSS is only 5.4 (Medium), the Chromium team rated severity Medium, and CISA SSVC scores it Exploitation:none, Automatable:no, Technical Impact:partial - a consistent picture with no conflict. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L) confirms network-reachable, low-complexity, unauthenticated exploitation but critically requires user interaction (UI:R), which aligns with the description's dependence on social engineering. No EPSS score was provided in the input, so exploitation probability cannot be quantified. There is no CISA KEV listing and no public exploit identified, so this is not actively exploited. The core limiter is that this is a UI-spoofing/misrepresentation flaw (CWE-451) whose harm depends entirely on successfully tricking a human, not on automatable technical compromise - so despite the network attack vector it is realistically a low operational risk that should be remediated via the routine Chrome auto-update cycle rather than as an emergency. |
| Exploit ScenarioDerived | A remote attacker crafts a malicious HTML page that abuses the PermissionElement to visually misrepresent or spoof browser UI (e.g., a permission prompt), then lures a victim via phishing or a malicious link to visit it. The spoofed UI could mislead the user into granting a permission or trusting content they otherwise would not. No public exploit code was identified at time of analysis, and success depends on the victim interacting with the crafted page. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 06, 2026
UI misrepresentation in Google Chrome's PermissionElement allows remote attackers to spoof browser-rendered permission UI through a crafted HTML page, deceiving a user who visits that page into acting on a false prompt; the assessed impact is limited to low confidentiality (C:L/I:N/A:N) with no integrity or availability impact. The issue is unauthenticated at the network layer (PR:N) but requires the victim to both load the attacker's page and be successfully social-engineered by the spoofed interface (UI:R), so exploitation is not automatable (SSVC Automatable: no). No public exploit code has been identified and there is no evidence of active exploitation (not in CISA KEV); Google has released a fixed build, Chrome 155.0.8059.39, so this is a genuine but low-priority issue.
RemediationAI
Vendor-released patch: upgrade to Google Chrome 155.0.8059.39 or later, distributed via the Stable Channel update described at https://chromereleases.googleblog.com/2026/10/stable-channel-update-for-desktop_086471744.html; on managed fleets this can be enforced through Chrome Browser Cloud Management or your standard browser update policy, and on individual endpoints through chrome://settings/help, which triggers the update and requires a browser restart (the only real trade-off being a brief interruption). Because the remaining exposure is a deception primitive rather than a technical bypass, compensating controls are necessarily user- and policy-side: restrict or profile untrusted pages that can render permission prompts, keep enterprise permission policies (for example, default-denying camera, microphone, and geolocation prompts for untrusted origins) so that a spoofed prompt has no real capability behind it, and train users not to act on unexpected in-page permission prompts; each of these reduces the payoff of the spoof but does not remove the rendering flaw, so patching remains the primary fix. Organizations running other Chromium-based browsers should confirm with those vendors whether an equivalent PermissionElement fix has been backported, since the provided data only covers Google Chrome.
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-451 (User Interface Misrepresentation of Critical Information), a rendering/presentation flaw rather than a memory-safety or injection bug. The affected component is Chromium's PermissionElement, the browser-provided element used to render standardized permission prompts (for capabilities such as geolocation, camera, and microphone) so that the consent UI is drawn by the browser rather than by page script. When that element can be misrepresented, a page can make browser chrome or a prompt appear to convey something other than what it actually does, undermining the trust users place in browser-rendered consent UI. The affected CPE resolves only to Google Chrome (cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*), i.e. all builds prior to 155.0.8059.39; Chromium security severity is Medium, ENISA EUVD tracks it as EUVD-2026-93713, and CISA's SSVC decision data rates it Exploitation: none, Automatable: no, Technical Impact: partial. Because the weakness depends on deceiving a human rather than bypassing a technical control, the CVSS vector carries UI:R with scope unchanged, and the authoritative assessment caps impact at low confidentiality with no integrity or availability effect.
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 with no auth (AV:N/AC:L/PR:N) but needs user deception (UI:R); impact is limited UI spoofing that may expose information (C:L), with no genuine integrity or availability loss.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
4DescriptionCVE.org
UI misrepresentation 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
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-93713
GHSA-m9jc-rx8x-h2g2
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB