On October 27, 2026, NVD published two CVEs fixed in Google Chrome 156.0.8078.73: CVE-2026-118337 in the Forms component and CVE-2026-118333 in the Video component. Both lead to the same outcome: a crafted HTML page can bypass the browser's web origin policy, the rule that stops one site from reading another site's data.
As with Chrome 155 earlier this month, the sources disagree on severity. The gap is less extreme this time, though: the Chromium team rates both "High", not "Low".
| CVE | Component | Weakness | CVSS 3.1 (NVD) | CVSS 3.1 (Google) | Chromium severity | NVD status |
|---|---|---|---|---|---|---|
| CVE-2026-118337 | Forms | Improper access control (CWE-284) | 9.3 | 5.4 | High | Modified |
| CVE-2026-118333 | Video | Missing authorization (CWE-862) | 9.3 | 5.4 | High | Modified |
Neither is in the CISA KEV catalog at the time of writing, and the NVD data mentions no exploitation.
What the descriptions say
The two NVD entries read almost the same, apart from the component:
- CVE-2026-118337: improper access control in Forms let a remote attacker bypass web origin policy through a crafted HTML page;
- CVE-2026-118333: missing authorization in Video allowed the same thing.
That is all that is public. Chromium bug reports stay restricted for several weeks after a fix ships, until most browsers have updated.
The origin policy is one of the Web's core boundaries. When it fails, a page open in one tab can potentially read or tamper with data from another site the user is logged into: webmail, intranet, an admin console. In both cases the user has to visit the malicious page, which is the UI:R in the vector.
9.3 versus 5.4: two readings of the same bug
The two scores published in NVD differ on just two metrics:
- NVD:
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N(9.3); - Google:
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N(5.4).
NVD treats an origin policy bypass as a scope change (S:C: the attack leaves the attacker's site and reaches another one) with high confidentiality and integrity impact. Google, which has seen the bug and the fix, scores a limited impact within the original scope.
Chromium's "High" label sits between the two, and it is arguably the most useful signal, since it comes from the team that knows the real exploitation conditions. That is my reading, not something NVD states. Either way, the answer does not change: update.
Affected versions
NVD ties both CVEs to Google Chrome before 156.0.8078.73 (excluded bound in the CPE configuration). 156.0.8078.73 is therefore the first fixed version, and anything later is fixed too.
Chromium-based browsers (Edge, Brave, Opera, Vivaldi and others) pick up these fixes on their own schedule. NVD does not list them, so check each vendor's advisory.
Detection
- Deployed version:
chrome://versionon a single machine, or your management console inventory (Chrome Browser Cloud Management, Intune, Jamf, Group Policy) to find endpoints below 156.0.8078.73. - Browsers that never restart: Chrome downloads updates in the background but only applies them on relaunch. A machine can have the update staged and still run the old build.
- Other Chromium browsers: inventory Edge and the rest separately.
Mitigation
- Roll out Chrome 156.0.8078.73 or later to every endpoint.
- Force a relaunch with the
RelaunchNotification(andRelaunchNotificationPeriod) policies if you manage the fleet. - Track Edge and other Chromium browsers: their fix may not land the same day.
- Do not triage on CVSS alone: a scanner that reads NVD will flag these as critical, one that reads Google's score as medium. The installed version is what settles it.
Why continuous monitoring of your browsers matters
The browser is the most exposed software on any fleet, and its CVEs arrive every week with scores that vary by source. Knowing which version actually runs on each machine is what lets you prioritize without relying on a single scale.
With cveo.tech, register your browsers with their versions and get an alert as soon as a critical CVE affects them.