CVE-2026-11308 · Inappropriate implementation in Extensions in Google Chrome prior to 149.0.7827.53 allowed an attacker who convinced a user to install a mal

01 · The Real Story

Like a fake contractor badge that only matters after someone is already let into the building

CVE-2026-11308 is a privilege-escalation flaw in Chrome Extensions. Affected builds are Chrome versions prior to 149.0.7827.53; public release notes around the fix show 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and Mac as the patched train. The attack does not start from a webpage alone; the attacker must first get a user to install a malicious extension, then use crafted extension logic to cross a privilege boundary inside Chrome.

Vendor CVSS lands at MEDIUM 6.3, but that score overstates enterprise urgency because it treats "user installs attacker code as an extension" as a lightweight prerequisite. In real fleets, extension allowlisting, store restrictions, managed browsers, and plain user friction drastically cut reachable population. Chromium-adjacent reporting also labels this class as low-severity, which matches operational reality better than a generic network CVSS.

"This is a malicious-extension problem first, a Chrome bug second."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious extension

The attacker needs a weaponized Chrome extension and a delivery path such as phishing, fake productivity tooling, malvertising, or sideload instructions. The named weapon here is simply a crafted Chrome extension package; there is no evidence in the reviewed sources of a public exploit kit or mass PoC repo for this CVE.

Conditions required:

Target uses Chrome before 149.0.7827.53
User is allowed to install extensions or sideload them
Attacker can reach the user with convincing social engineering

Where this breaks in practice:

Many enterprises block non-approved extensions with Chrome Enterprise policies
Users must still choose to install the extension
Security teams often monitor new extension installs or permission prompts

Detection/coverage: Internet scanners will not find this. Detection comes from browser policy telemetry, extension inventory, EDR process lineage around browser installs, and email/web filtering on the delivery stage.

STEP 02

Get the user to approve install and permissions

Chrome still presents extension installation and permission UX, so the attacker must overcome visible prompts. Even if the extension appears benign, the victim has to complete an action chain that is much noisier than a drive-by browser exploit.

Conditions required:

User interaction is successful
Requested permissions are not blocked by policy
Extension source is reachable from the endpoint

Where this breaks in practice:

Managed Chrome can enforce extension allowlists and block force-installs from unknown sources
Permission prompts and store reputation checks reduce conversion
Awareness training specifically covers browser-extension abuse in many orgs

Detection/coverage: Good browser management platforms log install events, extension IDs, publishers, and policy violations. That is the best control point in the chain.

STEP 03

Trigger the extension privilege-escalation bug

Once the attacker controls extension code on a vulnerable Chrome build, the crafted extension can exploit the inappropriate implementation bug in Extensions to gain more privilege than intended inside the browser. The effective weaponized component is the malicious extension itself; this is not a separate remote service exploit.

Conditions required:

The installed extension contains exploit logic for CVE-2026-11308
Chrome version remains unpatched
The relevant vulnerable extension path is reachable from that extension context

Where this breaks in practice:

The attacker already had to land untrusted code in the browser
The blast radius is usually bounded to the user/browser context rather than instant OS-level compromise
Public technical details remain sparse, which slows opportunistic copycat abuse

Detection/coverage: Traditional vulnerability scanners have poor direct coverage here. Version inventory can flag vulnerable Chrome builds, but confirming exploitability depends on extension state and policy posture.

STEP 04

Abuse elevated browser access

Post-exploitation impact is browser-centric: data access, tampering, session abuse, or broader access within Chrome that the original extension should not have had. This can still be serious for an individual user, especially in SaaS-heavy environments, but it is not the same operational class as an unauthenticated RCE from the internet.

Conditions required:

Valuable browser-resident data or sessions exist
Attacker can operationalize the gained browser privileges
Downstream apps do not have compensating controls such as step-up auth

Where this breaks in practice:

MFA, device binding, and conditional access can blunt session abuse
The compromise is tied to the affected browser profile
Enterprise response can often remove the extension and invalidate sessions quickly

Detection/coverage: Look for suspicious extension IDs, unusual browser permission grants, session anomalies in SaaS logs, and managed-browser telemetry showing out-of-policy extensions.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No evidence found in reviewed sources of active exploitation, and not listed in CISA KEV.
Proof-of-concept availability	No public PoC repo or researcher write-up for `CVE-2026-11308` was found in the reviewed sources. The practical weapon is a malicious extension, which already requires attacker-controlled code execution in browser context.
EPSS	`0.00014` (~`0.014%`) per the intel you provided, which is extremely low and consistent with limited opportunistic abuse.
KEV status	Not KEV-listed as of the reviewed CISA catalog page.
CVSS vector reality check	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L` captures the user-interaction requirement, but it still undervalues the real friction of "convince user to install attacker extension" in managed fleets.
Affected versions	Chrome prior to `149.0.7827.53`; release advisories describe patched desktop trains as `149.0.7827.53/.54` for Windows/Mac and `149.0.7827.53` for Linux.
Fixed versions	Upgrade to at least `149.0.7827.53`. On some desktop channels the published patched builds are `149.0.7827.53/.54`.
Scanning / exposure data	This is not Shodan/Censys/FOFA-friendly because there is no internet-facing service to census. Exposure must be measured through endpoint inventory and Chrome policy telemetry, not external attack-surface scans.
Disclosure date	`2026-06-05`.
Researcher / reporter	Public sources reviewed do not clearly identify an external reporter. One reviewed source attributes the issue to Google/Chromium-side reporting metadata, but not to a named third-party researcher.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to LOW (3.2/10)

The decisive factor is the attacker position requirement: this bug is only useful after the attacker gets a user to install a malicious extension, which sharply narrows real-world reach. In managed enterprise Chrome deployments, extension controls and visible install friction collapse the exposed population far below what a generic MEDIUM browser CVSS suggests.

HIGH Affected version window and patched train

MEDIUM Operational exploitability in enterprise fleets

MEDIUM Post-exploitation impact scope due to sparse public root-cause detail

Why this verdict

Major friction: requires malicious extension install. This is not unauthenticated drive-by web exploitation; the attacker must persuade a user to install attacker code as a browser extension first.
Reachable population is much smaller than all Chrome users. Enterprises with Chrome policy, extension allowlists, or blocked sideloading remove a large fraction of practical targets before the CVE even matters.
No exploitation signal. No KEV entry, no reviewed public campaign reporting, and a very low EPSS all push the score down from the vendor MEDIUM baseline.

Why not higher?

To justify MEDIUM or HIGH here, you would want either active exploitation, a one-click web-only attack path, or evidence that the bug reliably turns a low-friction extension install into broad tenant or OS compromise. None of that is present in the reviewed material. The exploit chain begins with a strong social-engineering prerequisite and a browser-policy bypass opportunity that many enterprises already constrain.

Why not lower?

It is not IGNORE because browser extensions are a real abuse channel, and some enterprises still allow users to install them freely. If you have unmanaged Chrome populations, contractor devices, or weak extension governance, this bug can still convert a bad extension into more browser power than intended.

05 · Compensating Control

What to do — in priority order.

Enforce an extension allowlist — Use Chrome Enterprise policy to allow only approved extension IDs and block sideloading or unknown publishers. For a LOW verdict there is no formal mitigation SLA, so treat this as backlog hygiene and deploy in the next browser-policy cycle if not already in place.
Block developer-mode and external installs — Disable extension developer mode where feasible and prevent off-store installation paths that are commonly used in social-engineering chains. For LOW, there is no mitigation SLA; fold this into standard hardening work rather than emergency change.
Inventory extension permissions — Continuously review installed extensions for high-risk permissions such as broad host access, cookies, tabs, and scripting. This reduces blast radius if a malicious or compromised extension lands before Chrome is patched.
Alert on new extension installs — Send managed-browser telemetry to your SIEM and generate detections for newly installed, unapproved, or suddenly re-permissioned extensions. This is the most reliable operational choke point because external vulnerability scanning cannot see the issue.
Invalidate SaaS sessions after extension cleanup — If you find a malicious extension on a vulnerable host, remove it and rotate browser-backed sessions for sensitive apps because the likely impact is session or data abuse inside the browser. Handle this through normal incident-response workflow; no separate LOW-tier mitigation SLA applies.

What doesn't work

A WAF or perimeter IPS will not solve this because the exploit precondition is an installed malicious extension, not a server-side inbound request.
A Shodan/Censys exposure review will not help because Chrome desktops are not meaningfully internet-censused for this condition.
A generic Chrome auto-update assumption is not enough in restricted or VDI environments where browser versions can lag and unmanaged extensions persist.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management agent. Invoke it as python3 check_cve_2026_11308.py or specify a browser binary explicitly, for example python3 check_cve_2026_11308.py --chrome /usr/bin/google-chrome; standard user privileges are usually enough, though Windows registry access may work more reliably with normal logged-in user context.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# check_cve_2026_11308.py\n# Output: VULNERABLE / PATCHED / UNKNOWN\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport shutil\nimport subprocess\nimport sys\n\nFIXED = (149, 0, 7827, 53)\n\ndef norm(v):\n    nums = [int(x) for x in re.findall(r'\\d+', v)]\n    while len(nums) < 4:\n        nums.append(0)\n    return tuple(nums[:4])\n\ndef cmp_ver(a, b):\n    return (a > b) - (a < b)\n\ndef run_cmd(cmd):\n    try:\n        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)\n        out = (p.stdout or '') + ' ' + (p.stderr or '')\n        return out.strip()\n    except Exception:\n        return ''\n\ndef extract_version(text):\n    m = re.search(r'(\\d+\\.\\d+\\.\\d+\\.\\d+)', text)\n    return m.group(1) if m else None\n\ndef candidate_paths():\n    system = platform.system().lower()\n    paths = []\n\n    if system == 'windows':\n        local = os.environ.get('LOCALAPPDATA', '')\n        program_files = os.environ.get('ProgramFiles', '')\n        program_files_x86 = os.environ.get('ProgramFiles(x86)', '')\n        paths += [\n            os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n            os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),\n        ]\n    elif system == 'darwin':\n        paths += [\n            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',\n            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),\n        ]\n    else:\n        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:\n            p = shutil.which(name)\n            if p:\n                paths.append(p)\n        paths += [\n            '/opt/google/chrome/chrome',\n            '/usr/bin/google-chrome',\n            '/usr/bin/google-chrome-stable',\n            '/usr/bin/chromium',\n            '/usr/bin/chromium-browser',\n        ]\n\n    dedup = []\n    for p in paths:\n        if p and p not in dedup:\n            dedup.append(p)\n    return dedup\n\ndef get_windows_registry_version():\n    cmds = [\n        ['reg', 'query', r'HKCU\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n        ['reg', 'query', r'HKLM\\Software\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n        ['reg', 'query', r'HKLM\\Software\\WOW6432Node\\Google\\Chrome\\BLBeacon', '/v', 'version'],\n    ]\n    for cmd in cmds:\n        out = run_cmd(cmd)\n        v = extract_version(out)\n        if v:\n            return v\n    return None\n\ndef main():\n    explicit = None\n    if '--chrome' in sys.argv:\n        idx = sys.argv.index('--chrome')\n        if idx + 1 < len(sys.argv):\n            explicit = sys.argv[idx + 1]\n\n    version = None\n    checked = []\n    system = platform.system().lower()\n\n    if system == 'windows':\n        version = get_windows_registry_version()\n\n    paths = [explicit] if explicit else candidate_paths()\n\n    if not version:\n        for path in paths:\n            if not path:\n                continue\n            checked.append(path)\n            if os.path.exists(path) or shutil.which(path):\n                out = run_cmd([path, '--version'])\n                version = extract_version(out)\n                if version:\n                    break\n\n    if not version:\n        print('UNKNOWN: could not determine Chrome version; checked=' + ', '.join(checked or paths))\n        sys.exit(2)\n\n    current = norm(version)\n    if cmp_ver(current, FIXED) < 0:\n        print(f'VULNERABLE: Chrome version {version} is older than 149.0.7827.53')\n        sys.exit(1)\n    else:\n        print(f'PATCHED: Chrome version {version} is at or above 149.0.7827.53')\n        sys.exit(0)\n\nif __name__ == '__main__':\n    main()\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning: do not treat this like an emergency browser zero-day. Query your fleet for Chrome versions older than 149.0.7827.53, prioritize unmanaged populations and business units that permit user-installed extensions, and make sure extension allowlisting is in place where it is missing. Because this is a LOW reassessment, there is no noisgate mitigation SLA and no mitigation SLA — go straight to backlog hygiene plus the patch track; complete Chrome upgrades within the noisgate remediation SLA for LOW issues, meaning treat it as normal maintenance rather than a time-bound fire drill.

Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously

Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.