CVE-2026-91732 is a missing authorization flaw in Chrome's AppManifest handling, fixed in version 153.0.8010.47. It requires an attacker who already controls a renderer process and uses social engineering. NVD scores it High (8.1), while Chromium rates it Medium. Update Chrome.
What's affected
Google's release notes for the stable channel on 15 September 2026 list 153.0.8010.47 and .48 for Windows and Mac and 153.0.8010.47 for Linux as the fixed builds. The NVD record says Chrome before 153.0.8010.47.
The weakness is CWE-862, missing authorization. The record's vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N.
The sources disagree on severity. NVD says 8.1 (High). Google's release notes list it as Medium, and the description says the attack needs a remote attacker who had compromised the renderer process and also used social engineering. That precondition is a large step, which the NVD vector does not express.
How to check if you're exposed
Check chrome://version for the version string, or use Help then About Google Chrome. Below 153.0.8010.47 means you are affected.
In managed environments, pull the installed version from your device management inventory and look for machines that update late, such as shared kiosks or laptops that rarely restart the browser.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Update Chrome to 153.0.8010.47 or later and restart it.
- Use your management tool to enforce a minimum browser version.
- Remind users that prompts to install apps or grant access from unfamiliar pages deserve caution, since the description mentions social engineering.
- Check other Chromium based software on your devices for updates.
Why it matters
Chrome splits work into processes with different privileges, so that a compromised page renderer cannot do whatever it wants. A missing authorization check on the browser side of that boundary weakens it: the browser process trusts a request it should have verified. Here the check was missing in the AppManifest feature.
That is why the description starts from a renderer that has already been compromised. By itself this bug does not give an attacker a way in; it removes a layer after a first compromise. The KEV flag in the record is false, and the release notes do not report exploitation.
Quick check
Can a web page trigger this alone?
The description says the attacker had compromised the renderer process and used social engineering, so it is a second-stage issue.
Is the fixed version the same as for CVE-2026-91719?
Both are fixed in the same stable update, 153.0.8010.47 or later.
Sources
Last reviewed: 18 October 2026.
