Patching a browser sounds simple until an organization tries to prove which browser actually ran during the working day. CVE-2026-113265 affects Google Chrome before 156.0.8078.47. The Chrome CNA describes memory corruption in BFCache that can lead to code execution inside the sandbox after a crafted HTML page is processed. A package inventory can show the right installer while a long-running process still uses the vulnerable binary.
The CVE was published on October 20, 2026. CISA's CVSS 3.1 enrichment assigns 8.8 with network delivery, low complexity, no privileges, and user interaction. Chrome labels the issue Medium in its release note. The difference in labels is a reason to define enterprise severity by potential impact and patch exposure, not by copying one vendor label without context.
The affected build
The Chrome CNA lists versions before 156.0.8078.47 as affected. A browser reporting that build or a later build has crossed the fixed boundary in the published record. The release note is the vendor source for the update, while the CVE record supplies the vulnerability identity and the public technical description.
The CERT-BUND rollup also mentions Microsoft Edge. The selected Chrome CNA does not provide an Edge build number, so a Chrome version check does not verify an Edge deployment. Organizations running Edge should use Microsoft's advisory and their own Edge inventory. Do not issue a blanket "Chromium is fixed" statement based only on the Chrome binary.
Why the running process matters
Browser update systems often download a new binary and wait for a restart. Users may keep the same browser process open for days. A configuration-management report can show that the package version changed while the active process still holds the old code in memory.
Build an assurance check around three observations:
- 1.
The installed package or application version is 156.0.8078.47 or later.
- 2.
The running browser process reports a version at or above the fixed build.
- 3.
The endpoint has restarted the browser or the operating system after the update became active.
These checks are operational controls, not claims about the CVE mechanism. They reduce the chance that an old process remains exposed after a successful deployment.
Patch-policy risks
Managed environments can delay browser updates for compatibility testing, update rings, or bandwidth limits. Those constraints may be necessary, but they are not neutral. A 2026 browser flaw with a public CVE can be exploited against users who continue browsing with the old build.
Review exceptions for high-risk users first: security operations staff, administrators, finance staff, executives, and anyone who regularly opens external links or untrusted attachments. Also check virtual desktop images and remote-work systems where a persistent session may survive a patch cycle.
Exposure evidence
ZoomEye returned 825 matches for the query product="Chrome" on November 4, 2026. The CVE-specific filter returned 0, and the narrower application and full product-name queries returned 0. The 825 result is a broad product fingerprint count. It does not prove that any host is running a vulnerable Chrome version or that a user has visited a malicious page.
The more relevant enterprise metric is the percentage of managed endpoints reporting the fixed build and a restarted process. External search services can help put a product family on the map, but they cannot replace endpoint inventory for a desktop browser.
Remediation and validation
Deploy Chrome 156.0.8078.47 or later. Verify the version on a sample of endpoints in each update ring, then expand to full coverage. Include browser processes that started before the update and were never restarted. Remove installers or golden images that would reintroduce the vulnerable build.
Preserve renderer crash and endpoint telemetry during the rollout. A crash is not proof of exploitation, but a new cluster during a browser security update deserves review. No source-backed BFCache workaround was identified; the vendor update is the supported technical response in the reviewed record.
Once remediation is complete, record the verification date, build number, affected user groups, exceptions, and the evidence used to confirm the running process. That record matters when a later vulnerability release asks whether the organization can move fast and prove it.