Google’s disclosure of CVE-2026-1861 — a
heap buffer overflow in libvpx — is small, but it matters: the bug was fixed in Chrome’s Stable channel (build 144.0.7559.132) and appears in multiple vendor tracking feeds, and Microsoft has listed the CVE in its Security Update Guide to document the status for Microsoft Edge (Chromium‑based).
Background
Chromium is not just Google’s project — it’s the open‑source engine that powers a wide range of browsers, including Microsoft Edge (the “new” Edge based on Chromium). When Google assigns a CVE to Chromium code and ships a fix in Chrome, downstream vendors that consume Chromium must merge, test, and ship that fix in their own product builds. Microsoft documents such upstream CVEs in the Security Update Guide to tell customers whether the latest Edge build has ingested the Chromium fix and is therefore no longer vulnerable. This is a deliberate transparency practice intended to help administrators and users map an upstream patch to Microsoft’s product lifecycle and patch cadence.
The technical summary is straightforward: CVE‑2026‑1861 is a heap buffer overflow in
libvpx (the VP8/VP9 codec library used by Chromium for video decoding/encoding). A malformed video or crafted HTML page that triggers Chromium’s libvpx path could overflow a heap buffer, causing memory corruption and, in the worst case, enabling remote code execution. Google fixed the issue in Chrome 144.0.7559.132; the CVE was publicly recorded on February 3, 2026.
What exactly is libvpx, and why is a libvpx bug dangerous?
libvpx in a nutshell
- libvpx is the open‑source reference implementation for VP8 and VP9 codecs. It handles the parsing and decoding of compressed video streams and is used in browsers for WebRTC, embedded video, and other media playback scenarios.
- Because libvpx processes untrusted input (video data from websites, attachments, or streaming sources), memory‑safety bugs in the library are attractive targets: an attacker can craft media that exercises a parser bug and cause unexpected behavior in the host process.
Why heap buffer overflows matter
A
heap buffer overflow occurs when more data is written to a heap‑allocated buffer than the buffer can hold. The consequences include:
- Denial of service — crashes that take the renderer process down.
- Memory corruption — which can be turned into remote code execution by skilled attackers chaining the overflow to other primitives.
- Exploitation feasibility — media parsers are often exploitable because the parsing paths are complex and attackers can supply a large range of inputs to influence heap layout.
CVE‑2026‑1861 was assigned a
High severity in published trackers, reflecting the serious potential impact if an attacker were able to weaponize the overflow.
Timeline and vendor coordination (what happened, when)
- Google identified and fixed the bug in Chromium and announced the Stable channel update on February 3, 2026 (Chrome 144.0.7559.132). The Chrome Releases post lists CVE‑2026‑1861 among the security fixes.
- Public CVE records and national vulnerability databases (for example NVD and various Linux distro trackers) published entries that reflect the Chrome fix and provide CVSS scoring metadata. These third‑party trackers list CVE‑2026‑1861 with a high CVSS rating (for example, Ubuntu/NVD pages reflect a CVSS base score consistent with a high‑severity heap overflow).
- Microsoft’s Security Update Guide included the CVE entry with the customary explanation used when an upstream Chromium CVE affects Edge customers: the CVE is being documented because Edge consumes Chromium OSS, and the entry’s purpose is to announce whether the latest Microsoft Edge build is vulnerable or not. Microsoft adds such entries so organizations that rely on the Security Update Guide can track status for Edge even when the primary fix originated upstream.
Note: At the time of publication, there was no authoritative public statement that the vulnerability was being actively exploited in the wild. Google’s release notes and mainstream reporting did not indicate known exploitation; vendor pages instead focused on patching and disclosure. Watch threat intel feeds and CISA/NSAs for later updates about exploitation.
Why Microsoft lists Chromium CVEs in the Security Update Guide — plain language
- Edge contains Chromium code. Microsoft ships Edge builds that are based on a particular Chromium baseline. That means many security fixes will originate from the Chromium project and must be ingested into Edge. Microsoft needs a way to show customers whether the upstream fix exists and whether it has been merged into the Edge build that’s shipped to customers.
- The Security Update Guide is the canonical record for Microsoft customers. Instead of forcing admins to hunt Chrome release notes and then map those to Edge builds, Microsoft records the CVE and supplies status in the same guide organizations use for all Microsoft products. The entry therefore serves a cross‑vendor tracking role.
- Avoids ambiguity for enterprise teams. Enterprises frequently require a single authoritative source for whether a product is affected. Documenting upstream CVEs in the Security Update Guide reduces ambiguity around “Is my Edge vulnerable?” and gives actionable information such as the Edge version that includes the fix (or a recommendation to update Edge).
This practice improves transparency but also causes confusion for some users who see a Chrome‑assigned CVE in Microsoft’s guide and expect Microsoft to have created the patch. The important distinction: Microsoft’s entry often points back to Chrome for the original fix and then documents Edge’s status after ingestion and testing.
How to determine whether your browser is vulnerable (step‑by‑step)
To decide whether CVE‑2026‑1861 affects your install, follow this three‑step workflow: find the fixed Chromium version, check your browser’s Chromium baseline, compare.
1) Confirm the upstream (Chrome/Chromium) fixed version
- Google’s Chrome Releases posts list the Chrome/Chromium build that contains each security fix. For CVE‑2026‑1861, the fix is in Chrome 144.0.7559.132. Use the Chrome Releases entry or NVD/CVE records as a corroborating source.
2) Find the Chromium baseline used by your browser
- Microsoft Edge (desktop): open Edge → Settings and more (three dots) → Help and feedback → About Microsoft Edge. The About page will show your Edge version and automatically trigger an update check. For the precise Chromium baseline number, open edge://version (type that in the address bar) — the page lists the Chromium version string that Edge was built on. Microsoft Support documents this workflow and Edge’s update behavior.
- Google Chrome (desktop): open Chrome → More (three dots) → Help → About Google Chrome. Alternatively, type chrome://version to see the detailed version string. Chrome will also check for and download updates when you visit About.
3) Compare numbers
- If the Chromium version shown in edge://version is greater than or equal to the Chromium build that fixes CVE‑2026‑1861 (for example, Chromium 144.0.7559.132 or later), your Edge build contains the upstream patch and is not vulnerable to that particular issue — assuming Microsoft did not reintroduce the problem in its downstream code. If your Chromium baseline is older, update Edge immediately.
Practical note: Edge release notes sometimes publish the mapping “Edge version X is based on Chromium Y”; if you manage many machines you can use that mapping to plan upgrades and scheduling. For enterprise fleets, patch management servers and endpoint management tools should be used to confirm the actual installed build on each host.
Quick, actionable steps for home users and sysadmins
- Home users (desktop): Open Edge → Help and feedback → About Microsoft Edge; if an update is available, choose Download and install and then Restart to finish. Use edge://version to check the Chromium baseline if you want to cross‑check against Chrome’s fixed build.
- Home users (Chrome): Open Chrome → Help → About Google Chrome (or chrome://version). Chrome usually updates automatically; relaunch after updates.
- Enterprise administrators:
- Query your fleet’s installed Edge versions using your management stack (SCCM/Intune, Jamf, Munki, etc.).
- Compare the reported “based on Chromium” number against Chrome’s fixed build (144.0.7559.132).
- If devices are behind, schedule a staged rollout of the updated Edge build — prioritize high‑risk endpoints and users who open untrusted media.
- Validate successful upgrade by sampling edge://version on endpoints or using telemetry from endpoint management.
Detection, mitigation, and hardening while you update
- Temporary mitigations: There are usually no reliable feature‑level mitigations for codec parser bugs beyond disabling the affected codec or restricting how untrusted content is handled. In practice, disabling autoplay, blocking untrusted sites, and enforcing content security policies in enterprise browsing can reduce the attack surface until updates are applied.
- Monitoring and detection: Monitor endpoint telemetry for unexplained renderer crashes, suspicious child process behavior, or high rates of corrupted media decoding. Correlate browser crashes with web page visits to identify potential malicious content. Run memory integrity and exploit mitigation tools (e.g., OS‑level mitigations, sandboxing) that raise the bar for successful exploitation.
- Vulnerability scanning: Update your vulnerability scanners to recognize CVE‑2026‑1861 and scan for vulnerable Chromium/Edge builds across your estate. Many scanning tools have already added checks for this CVE; ensure signatures are current.
Critical analysis — strengths, risks, and the supply‑chain angle
Strengths of Microsoft’s approach
- Unified tracking: Placing upstream CVEs in a single MSRC Security Update Guide helps customers avoid fragmented patch tracking. It reduces the time admins spend correlating Chrome release notes with Edge builds. This approach is particularly helpful for compliance and audit teams who need a single source of truth.
- Transparency: Microsoft’s practice of saying “this CVE originated upstream, here’s the fix status for Edge” is more transparent than simply ignoring upstream CVEs and waiting to label fixes as “Edge” only after rework.
Risks, friction, and possible misinterpretation
- Confusion for end users: Non‑technical users may interpret a Chromium CVE entry in Microsoft’s guide as a Microsoft bug, causing confusion over where to look for patches. The Security Update Guide includes explanatory copy, but the nuance can be lost. Communication must be clear: the CVE assignment is to the Chromium project; Microsoft documents it to show Edge impact and status.
- Supply‑chain lag windows: The time between a Chromium fix (Google release) and Microsoft shipping the fix in Edge creates a vulnerability window for Edge users who haven’t updated. Organizations must treat upstream patch announcements as triggers to verify downstream ingestion and plan immediate Edge updates where necessary.
- False sense of completeness: The Security Update Guide documents status, but it does not replace the need for active patch management. Organizations should not assume “listed = fixed in my environment” without verifying installed builds and performing the necessary restarts or staged rollouts.
Supply‑chain trust and open‑source dependency management
This CVE is a textbook example of how open‑source components create cross‑vendor security responsibilities. Chromium fixes must propagate through all downstream consumers. It underscores how critical it is for vendors and enterprises to have robust processes for tracking upstream repositories, automating ingestion where possible, and validating code changes in the downstream product to avoid regressions.
Detection rules and SIEM guidance (practical snippets)
If your team uses centralized logging, consider these detection heuristics while you patch:
- Alert on renderer process crashes correlated with visits to unknown or user‑uploaded media hosting domains.
- Create an event that flags edge.exe or chrome.exe child process exceptions (access violations/segfaults) with a high frequency per endpoint.
- Add CVE‑specific tags to vulnerability management systems for prioritized remediation workflows and link them to the date Google released Chrome 144.0.7559.132 for tracking.
FAQ — short answers
- Why is CVE‑2026‑1861 in Microsoft’s Security Update Guide?
- Because the CVE was assigned to Chromium code that Microsoft Edge consumes; Microsoft documents the CVE in the Guide to declare Edge’s status after ingesting upstream patches.
- How do I see my browser version?
- Edge: Settings and more (three dots) → Help and feedback → About Microsoft Edge, or type edge://version for the Chromium baseline. Chrome: More → Help → About Google Chrome or chrome://version.
- Am I vulnerable if I use Edge?
- Check your Edge’s Chromium version. If it’s built on Chromium 144.0.7559.132 or later, Edge contains the upstream fix. If not, update Edge immediately. Enterprise admins should verify at scale via their management tooling.
Final recommendations
- Don’t delay: Update browsers immediately on endpoints where users can access untrusted web content or media streams. For Edge, that means deploying the Edge release that contains Chromium 144.0.7559.132 or later.
- Verify at scale: Use your endpoint management system to confirm the Chromium baseline across your fleet; don’t rely solely on user reports.
- Harden browsing: Until updates are widespread, enforce safe browsing policies, block risky web content, and monitor for renderer crashes or suspicious media handling.
- Audit supply‑chain processes: Treat upstream security advisories as triggers to check downstream products. Improve automation for ingesting upstream fixes and accelerating testing so windows between upstream fixes and downstream releases shrink.
CVE‑2026‑1861 is a reminder that browser security is a chain: open‑source components, vendor maintenance, and enterprise patching policies all need to work in concert. Microsoft’s inclusion of Chromium CVEs in the Security Update Guide is a helpful transparency posture — but it’s only as effective as the detection, update, and verification processes organizations use to close the loop. If you’re responsible for browser security in your environment, treat Chrome/Chromium advisories as first‑class triggers and make sure Edge’s installed Chromium baseline matches the patched upstream build.
Source: MSRC
Security Update Guide - Microsoft Security Response Center