Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise renderer via separate bug
-
DeliveryServe crafted HTML page
-
ExploitSocial-engineer user interaction
-
ExecutionAbuse AppManifest missing authz
-
PersistBypass web-origin policy
-
ImpactAccess cross-origin data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Not a default-config remote attack. Exploitation requires TWO stacked preconditions explicitly stated in the description: (1) the attacker must have already compromised Chrome's renderer process (typically via a separate prior vulnerability), and (2) social engineering to induce victim interaction (UI:R) with a crafted HTML page, in order to abuse the AppManifest missing-authorization check and bypass web-origin policy. Limiting factors: the renderer must be pre-compromised (this is a sandbox/origin-isolation weakness, not an initial-access vector), user interaction is mandatory, and the fix ships in Chrome 153.0.8010.47 so patched/auto-updated browsers are not affected. |
| Impact | CVSS 3.1 base is 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N), but that headline number materially overstates real-world risk and even conflicts with Google's own 'Chromium security severity: Medium' rating. The decisive detail sits in the description, not the vector: the attacker must ALREADY have 'compromised the renderer process' AND then chain social engineering (UI:R) to bypass web-origin policy. That renderer-compromise precondition is a heavy prerequisite the CVSS PR:N metric does not capture - Google conventionally scores browser-sandbox flaws with PR:N because a compromised renderer is not an 'account privilege', so the vector reads more open than the attack actually is. Corroborating signals point to low urgency: EPSS is 0.25% (16th percentile), the CVE is NOT in CISA KEV, and no public exploit is referenced. This is a defense-in-depth / origin-isolation weakness meaningful mainly as one link in a multi-stage sandbox-escape chain, not a standalone remotely-weaponizable bug. Net: high nominal CVSS, but low immediate priority given the required prior renderer compromise, added user interaction, absent exploitation evidence, and a patch already shipped. |
| Exploit ScenarioDerived | An attacker who has already exploited a separate renderer-level bug (e.g., a V8 or DOM flaw giving code execution inside Chrome's sandboxed renderer) crafts a malicious HTML page and uses social engineering to get the victim to interact with it, abusing the AppManifest missing-authorization flaw to bypass web-origin policy and access resources across origins. No public proof-of-concept is referenced and the issue is not listed in CISA KEV, so this remains a theoretical chain link rather than an observed in-the-wild attack. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Missing authorization in Chrome's AppManifest handling (CWE-862) lets an attacker who has already compromised the renderer process bypass web origin policy and load a crafted HTML page inside a trusted origin context, yielding high confidentiality and integrity impact. Exploitation is not a default-config remote attack: it requires two stacked preconditions - a pre-compromised renderer (typically via a separate prior bug) plus social engineering to induce victim interaction with the malicious page. Per the CVSS vector (AV:N/AC:L/PR:N/UI:R) the attacker is remote and unauthenticated, but user interaction is mandatory; our independent assessment raises attack complexity to High (AC:H) because the renderer must first be subverted, and Google's own rating is 'Chromium security severity: Medium'. EPSS is low at 0.25% (16th percentile) and no public exploit has been identified at time of analysis; the fix ships in Chrome 153.0.8010.47, so patched and auto-updated browsers are not affected.
RemediationAI
Upgrade Google Chrome to the fixed release 153.0.8010.47 or later (Vendor-released patch: 153.0.8010.47) - on managed fleets push the update through your normal policy mechanism and confirm users fully restart the browser so the new binary replaces the running process, since Chrome will keep an old renderer alive until relaunch. Because exploitation requires a previously compromised renderer, the highest-value compensating control is to eliminate the delivery precondition: patch other renderer-memory-safety bugs promptly, keep Chrome's renderer sandbox enabled, and confirm Site Isolation is on (enterprises can enforce via the SitePerProcess policy; disabling it for compatibility would directly undermine the origin boundary this bug crosses). Where updating is temporarily impossible, restrict users to allowlisted internal sites, block or warn on unsolicited links and HTML attachments that carry the social-engineering lure the exploit depends on, and treat any host with a compromised renderer as already breached - behavioral controls do not remediate the missing authorization check itself and only reduce the chance the UI:R step succeeds. Track the vendor advisory at https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0541751186.html and the Chromium issue at https://issues.chromium.org/issues/511062248 for any backport or follow-up guidance; no separate workaround-only fix has been published.
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 flaw lives in AppManifest, the component that parses and applies the Web App Manifest associated with a page, and is classified as CWE-862 (Missing Authorization). The code path fails to enforce an authorization/origin check before allowing manifest-derived behavior to affect origin policy, so a caller that should never satisfy the check can still trigger the privileged operation. In Chromium's architecture the renderer process is the untrusted, sandboxed half of the browser, and origin policy enforcement exists precisely to contain a compromised renderer; a missing authorization check in that layer weakens the origin boundary and can be exploited only from an already-hijacked renderer - it is not an initial-access or sandbox-escape primitive by itself. Because the exploit also needs UI:R (victim must interact with a crafted HTML page) and relies on social engineering, it functions as a containment/origin-isolation weakness that becomes dangerous when chained after a renderer compromise. Affected CPE is the generic Chrome channel cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*, i.e. any Chrome build below the fixed release; the ENISA EUVD record (EUVD-2026-79986) lists affected versions as Chrome < 153.0.8010.47.
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:H/I:H/A:N
Requires a pre-compromised renderer plus social engineering, so AC:H rather than AC:L; origin bypass yields cross-origin read/write (C:H/I:H), no availability impact (A:N).
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
Missing authorization in AppManifest in Google Chrome prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)
Executive ViewAI
A high-severity authorization flaw in Google Chrome's AppManifest handling could let an attacker who has already compromised a browser renderer display malicious content as if it originated from a trusted website, putting user data and trusted web sessions at risk. The issue affects organizations running Chrome before 153.0.8010.47; exploitation requires both a prior renderer compromise and user interaction, so the practical business risk is concentrated in unpatched endpoints rather than as a standalone remote attack. Leadership should care because successful abuse could undermine confidence in browser-based transactions and expose sensitive information, making patch verification a near-term priority.
Apply vendor patch.
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
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
EUVD-2026-79986
GHSA-jwg9-gm8x-fj64
NVD
CVE.org
EPSS
VulDB
Exploit-DB