Google Chrome fixed CVE-2026-13799, a high-severity use-after-free flaw in its QUIC networking code, in the desktop Stable Channel update published June 30, 2026, with Chrome versions before 150.0.7871.47 listed as vulnerable by the Chrome CVE record and the National Vulnerability Database. The bug is not the loudest item in Chrome 150’s security rollup, but it is one of the most interesting for defenders because it sits below the page, below JavaScript, and inside the browser’s network plumbing. In plain English: this is the kind of vulnerability that reminds administrators that the browser is not merely an application users open; it is a constantly exposed protocol engine. The practical answer is simple — get to Chrome 150.0.7871.47 or later — but the security story is more complicated than a version number.
CVE-2026-13799 is described by Chrome and NVD as a use after free in QUIC that could allow a remote attacker to exploit heap corruption through malicious network traffic. CISA’s ADP enrichment assigns it a CVSS 3.1 score of 8.1, with network attack vector, no privileges required, no user interaction required, high attack complexity, and high impact to confidentiality, integrity, and availability. NVD itself had not yet supplied its own CVSS score when the entry was last modified on July 2, 2026.
That “no user interaction” field deserves attention, but not panic. Browser vulnerability language often compresses a messy chain of preconditions into a few vector values. A victim system still has to be running a vulnerable build and receiving attacker-controlled traffic in a way that reaches the faulty QUIC code path; CISA’s high attack complexity rating is a strong hint that this is not a trivial spray-and-pray bug.
Still, the location matters. QUIC is the UDP-based transport protocol underpinning HTTP/3, designed to reduce connection setup latency, improve mobility, and move transport-layer evolution out of the operating system kernel and into user space. That architecture has been a win for web performance, but it also means modern browsers carry more protocol complexity themselves. A flaw in that machinery can be security-relevant even before a page has rendered anything suspicious.
As PCWorld and Born’s IT and Windows Blog noted in their coverage of Chrome 150, this release was unusually large, with hundreds of security fixes across the browser. CVE-2026-13799 sits among that pile as a high-severity memory-safety flaw rather than as a confirmed zero-day. Google’s advisory does not say it is being exploited in the wild, and CISA’s SSVC field lists exploitation as “none.” That makes this a patch-now issue, not a breach-assumption issue.
The messy part is the configuration data. NVD’s change history shows an initial NIST analysis adding a CPE configuration for Google Chrome versions up to, but excluding, 150.0.7871.46, combined with operating-system CPEs for Windows, Linux, and macOS. That sits awkwardly beside the CVE description and Chrome CNA affected-version data, both of which use 150.0.7871.47 as the fixed threshold.
So yes, there appears to be a CPE/version-boundary inconsistency worth watching. If the vulnerability record says “prior to 150.0.7871.47” but the CPE range excludes only up to 150.0.7871.46, scanners may interpret exposure differently depending on whether they trust the CPE configuration, the CNA affected block, or their own vendor-advisory mapping. For vulnerability-management teams, that is not pedantry; it is the difference between a clean dashboard and a missed endpoint.
This is also why CVE records should not be treated as a single immutable truth table. NVD enrichment often trails vendor publication, and early CPE mappings can be revised as analysts normalize version strings across platforms. In this case, the conservative operational reading is simple: anything below 150.0.7871.47 should be considered exposed for CVE-2026-13799 unless your vendor-specific tooling proves otherwise.
What makes CVE-2026-13799 notable is its placement in QUIC rather than in the usual high-profile suspects such as V8, Blink, WebGPU, or media codecs. QUIC operates at the transport layer, handling connection state, packet sequencing, congestion control, encryption integration, stream multiplexing, and recovery behavior. A malformed or strategically timed stream of network traffic can exercise code paths a user never sees.
That does not automatically mean remote code execution from across the Internet is sitting one UDP packet away. Chrome’s architecture, memory allocator hardening, process separation, and sandboxing all raise the bar. But it does mean defenders should avoid dismissing the issue merely because it lacks the drama of a JavaScript engine zero-day. Protocol bugs can be quieter, harder to reason about, and harder to reproduce.
The “high attack complexity” element in CISA’s vector is doing a lot of work here. It suggests exploitability depends on timing, state, layout control, or a specific QUIC interaction rather than a simple malformed request. For enterprise risk, however, high complexity is not the same as low priority. Attackers who specialize in browser exploitation are patient, and Chrome’s market share makes even difficult bugs attractive research targets.
Managed fleets have rings, deferrals, virtual desktops, golden images, kiosk systems, app-control policies, and occasionally ancient update assumptions hiding in group policy. A user may have downloaded the update but not restarted the browser. A packaged installer may be staged but not applied. A non-persistent VDI pool may revert to a vulnerable image every morning.
This is where CVE-2026-13799 becomes a practical Windows admin story. The relevant question is not “Did Google ship the fix?” It is “Can I prove that every Chrome instance that touches untrusted networks is running 150.0.7871.47 or later?” That includes secondary browsers installed by developers, lab machines, unmanaged BYOD laptops, and browsers bundled into test automation environments.
The same logic extends to Chromium-derived browsers, but with caution. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium-based browsers do not necessarily use Google Chrome’s version numbers, release timing, or feature flags. Administrators should check each vendor’s security release notes rather than blindly mapping the Chrome version threshold onto another product. Chromium lineage matters; vendor integration details matter too.
That creates a familiar blind spot in Windows shops. Many organizations have strong processes for Windows cumulative updates and weaker processes for browser channel drift. Edge updates may arrive through EdgeUpdate, WSUS-adjacent catalog entries, Configuration Manager, Intune, or a third-party patch platform. Chrome may be managed through Google Update policies or simply left to auto-update. In mixed fleets, the result is often a patchwork of good intentions.
CVE-2026-13799 is a reminder that browser patching belongs in the same operational tier as endpoint protection updates and VPN client fixes. A transport-layer browser vulnerability does not wait for next month’s maintenance window just because it is not a Windows kernel CVE. If a browser processes hostile Internet traffic every day, its security baseline is part of the perimeter.
That does not mean every Chromium CVE instantly applies to Edge in the same form. Microsoft may ship a patched Chromium base under a different Edge build, may disable or modify relevant code paths, or may document the issue through a security advisory rather than mirroring Chrome’s CVE table line for line. The correct enterprise posture is to monitor both Chrome’s upstream security releases and Microsoft’s Edge security release notes, then let inventory tell you where exposure remains.
The absence of an NVD score can frustrate dashboards that rank remediation by NVD base score alone. It can also create odd reporting gaps where a vulnerability looks unscored in one tool and high in another. Mature programs should already be resilient to this. CNA text, vendor advisories, CISA enrichment, known exploitation status, asset exposure, and product criticality all matter.
In fact, this is one of the places where blind CVSS sorting can mislead. A browser bug with no known exploitation but high potential impact may deserve faster action than a lower-scored local bug on a rarely used component. Conversely, the high attack complexity and absence of observed exploitation argue against emergency theater. The right response is accelerated browser patch validation, not a weekend-long incident response bridge.
The scoring also reinforces why NVD’s CPE oddity matters. Vulnerability scanners often use CPEs and CVSS scores as the machinery behind executive reports. If the metadata lags or contains a version-boundary mismatch, the organization may get a distorted picture. Human review is still required, especially during the first days after publication.
That shift has benefits. QUIC can evolve faster than TCP, handle connection migration more gracefully, and reduce latency through tighter integration with TLS 1.3. It also gives browser vendors more control over performance tuning and deployment. But security responsibility follows complexity, and complexity has a habit of producing edge cases.
For defenders, this means network-facing browser components deserve the same attention as content engines. Blocking malicious pages is not enough if malformed transport behavior can prod a vulnerable code path. Similarly, network monitoring may not give easy visibility into encrypted QUIC traffic, and simply allowing UDP/443 everywhere can complicate inspection strategies.
Some organizations disable HTTP/3 or QUIC for compatibility, monitoring, or control reasons. CVE-2026-13799 will probably renew that conversation in a few security teams. But disabling a modern protocol as a standing workaround is not a substitute for patching, and it can introduce performance or application-compatibility tradeoffs. The cleaner answer is to keep the browser current and use protocol policy as a risk-management tool, not as an excuse to run stale code.
This creates a familiar tension for defenders. Security teams want technical detail so they can assess exposure and detection options. Vendors withhold detail to prevent easy exploit development. Both positions are rational, and both make the first week after a browser security release an exercise in disciplined uncertainty.
In the absence of exploit details, administrators should avoid overclaiming. There is no public evidence in the supplied NVD data that CVE-2026-13799 is being actively exploited. There is also no basis for assuming it is harmless simply because the bug details are private. The correct middle ground is to patch promptly, verify versions, and watch for vendor or CISA updates.
Researchers will eventually learn more from Chromium commits, downstream advisories, and any later disclosure notes. If the bug turns out to require rare connection-state choreography, it will fade into the long tail of important but unexploited browser fixes. If researchers find a reliable path from malicious network traffic to controlled heap corruption, the risk profile could change quickly.
A scanner that keys only on the NVD CPE range may under-report or misclassify CVE-2026-13799 if the version boundary is interpreted incorrectly. A scanner that keys on the CNA affected data may do better, but only if it understands Chrome’s actual installed version. A patch platform may mark the update deployed while the browser process remains un-restarted and still running vulnerable code.
That last point is especially important. Browser updates often require a restart to complete. In real fleets, users keep sessions alive for days, developers pin browsers during testing, and shared workstations may run with long-lived processes. Inventory should distinguish between installed version, running process version, and effective protection.
There is also the problem of Chromium embedded in unexpected places. Electron applications, WebView-based software, and bundled Chromium runtimes do not automatically inherit Chrome’s desktop update. CVE-2026-13799 is specifically a Google Chrome CVE as published, so administrators should not automatically declare every embedded Chromium runtime vulnerable. But the broader lesson remains: the Chromium ecosystem is larger than the browser icon on the taskbar.
That scale can numb users and administrators. When every Chrome release includes dozens or hundreds of fixes, individual CVEs blur together. The risk is that organizations treat browser patching as background noise until a zero-day appears in CISA’s Known Exploited Vulnerabilities catalog.
CVE-2026-13799 argues against that complacency. It is not known to be exploited, but it affects a network protocol implementation in the world’s dominant browser family. It has high potential impact. It has early metadata friction. It is exactly the sort of bug that should be remediated before it graduates from advisory text to exploit chatter.
The velocity of Chrome’s security work is both reassuring and sobering. Reassuring, because Google’s fuzzing, bug bounty, and internal security machinery keep finding and fixing memory-safety flaws. Sobering, because the bug count shows how much attack surface a modern browser carries. The patch cadence is not an inconvenience layered on top of the web; it is one of the things keeping the web survivable.
Chrome’s Networking Layer Is Now Part of the Attack Surface
CVE-2026-13799 is described by Chrome and NVD as a use after free in QUIC that could allow a remote attacker to exploit heap corruption through malicious network traffic. CISA’s ADP enrichment assigns it a CVSS 3.1 score of 8.1, with network attack vector, no privileges required, no user interaction required, high attack complexity, and high impact to confidentiality, integrity, and availability. NVD itself had not yet supplied its own CVSS score when the entry was last modified on July 2, 2026.That “no user interaction” field deserves attention, but not panic. Browser vulnerability language often compresses a messy chain of preconditions into a few vector values. A victim system still has to be running a vulnerable build and receiving attacker-controlled traffic in a way that reaches the faulty QUIC code path; CISA’s high attack complexity rating is a strong hint that this is not a trivial spray-and-pray bug.
Still, the location matters. QUIC is the UDP-based transport protocol underpinning HTTP/3, designed to reduce connection setup latency, improve mobility, and move transport-layer evolution out of the operating system kernel and into user space. That architecture has been a win for web performance, but it also means modern browsers carry more protocol complexity themselves. A flaw in that machinery can be security-relevant even before a page has rendered anything suspicious.
As PCWorld and Born’s IT and Windows Blog noted in their coverage of Chrome 150, this release was unusually large, with hundreds of security fixes across the browser. CVE-2026-13799 sits among that pile as a high-severity memory-safety flaw rather than as a confirmed zero-day. Google’s advisory does not say it is being exploited in the wild, and CISA’s SSVC field lists exploitation as “none.” That makes this a patch-now issue, not a breach-assumption issue.
The Version Boundary Is Clearer Than the CPE Metadata
The user-facing fix line is straightforward: Chrome before 150.0.7871.47 is affected, and Chrome 150.0.7871.47 or later contains the fix for this CVE. The Chrome CVE record supplied to NVD says exactly that, and the NVD page repeats the same description. The Chrome Releases blog entry for the June 30 Stable Channel update is the vendor advisory NVD points to.The messy part is the configuration data. NVD’s change history shows an initial NIST analysis adding a CPE configuration for Google Chrome versions up to, but excluding, 150.0.7871.46, combined with operating-system CPEs for Windows, Linux, and macOS. That sits awkwardly beside the CVE description and Chrome CNA affected-version data, both of which use 150.0.7871.47 as the fixed threshold.
So yes, there appears to be a CPE/version-boundary inconsistency worth watching. If the vulnerability record says “prior to 150.0.7871.47” but the CPE range excludes only up to 150.0.7871.46, scanners may interpret exposure differently depending on whether they trust the CPE configuration, the CNA affected block, or their own vendor-advisory mapping. For vulnerability-management teams, that is not pedantry; it is the difference between a clean dashboard and a missed endpoint.
This is also why CVE records should not be treated as a single immutable truth table. NVD enrichment often trails vendor publication, and early CPE mappings can be revised as analysts normalize version strings across platforms. In this case, the conservative operational reading is simple: anything below 150.0.7871.47 should be considered exposed for CVE-2026-13799 unless your vendor-specific tooling proves otherwise.
A Use-After-Free in QUIC Is Not Just Another Browser Bug
Use-after-free vulnerabilities are old, familiar, and still dangerous. They occur when software continues to reference memory after it has been released, creating an opportunity for an attacker to influence what occupies that memory later. In a browser, where multiple parsers, protocol handlers, sandboxes, and allocators are all operating at high speed, that class of bug remains a major source of exploitable memory corruption.What makes CVE-2026-13799 notable is its placement in QUIC rather than in the usual high-profile suspects such as V8, Blink, WebGPU, or media codecs. QUIC operates at the transport layer, handling connection state, packet sequencing, congestion control, encryption integration, stream multiplexing, and recovery behavior. A malformed or strategically timed stream of network traffic can exercise code paths a user never sees.
That does not automatically mean remote code execution from across the Internet is sitting one UDP packet away. Chrome’s architecture, memory allocator hardening, process separation, and sandboxing all raise the bar. But it does mean defenders should avoid dismissing the issue merely because it lacks the drama of a JavaScript engine zero-day. Protocol bugs can be quieter, harder to reason about, and harder to reproduce.
The “high attack complexity” element in CISA’s vector is doing a lot of work here. It suggests exploitability depends on timing, state, layout control, or a specific QUIC interaction rather than a simple malformed request. For enterprise risk, however, high complexity is not the same as low priority. Attackers who specialize in browser exploitation are patient, and Chrome’s market share makes even difficult bugs attractive research targets.
The Patch Is Easy; Proving Deployment Is the Hard Part
For individual users, the fix is mundane: open Chrome’s About page, let it update, and restart the browser. Chrome’s updater is good enough that many consumer systems will already have moved beyond the vulnerable build by the time a CVE page becomes widely read. But enterprises do not live in that idealized world.Managed fleets have rings, deferrals, virtual desktops, golden images, kiosk systems, app-control policies, and occasionally ancient update assumptions hiding in group policy. A user may have downloaded the update but not restarted the browser. A packaged installer may be staged but not applied. A non-persistent VDI pool may revert to a vulnerable image every morning.
This is where CVE-2026-13799 becomes a practical Windows admin story. The relevant question is not “Did Google ship the fix?” It is “Can I prove that every Chrome instance that touches untrusted networks is running 150.0.7871.47 or later?” That includes secondary browsers installed by developers, lab machines, unmanaged BYOD laptops, and browsers bundled into test automation environments.
The same logic extends to Chromium-derived browsers, but with caution. Microsoft Edge, Brave, Vivaldi, Opera, and other Chromium-based browsers do not necessarily use Google Chrome’s version numbers, release timing, or feature flags. Administrators should check each vendor’s security release notes rather than blindly mapping the Chrome version threshold onto another product. Chromium lineage matters; vendor integration details matter too.
Edge Administrators Should Track Chromium, Not Just Patch Tuesday
For WindowsForum readers, the Edge angle is unavoidable. Microsoft Edge is Chromium-based, and Microsoft’s release notes routinely state when Edge incorporates Chromium security updates. But Edge is not Chrome with a blue icon. Microsoft maintains its own update channel, version numbering, policy surface, enterprise controls, and sometimes timing.That creates a familiar blind spot in Windows shops. Many organizations have strong processes for Windows cumulative updates and weaker processes for browser channel drift. Edge updates may arrive through EdgeUpdate, WSUS-adjacent catalog entries, Configuration Manager, Intune, or a third-party patch platform. Chrome may be managed through Google Update policies or simply left to auto-update. In mixed fleets, the result is often a patchwork of good intentions.
CVE-2026-13799 is a reminder that browser patching belongs in the same operational tier as endpoint protection updates and VPN client fixes. A transport-layer browser vulnerability does not wait for next month’s maintenance window just because it is not a Windows kernel CVE. If a browser processes hostile Internet traffic every day, its security baseline is part of the perimeter.
That does not mean every Chromium CVE instantly applies to Edge in the same form. Microsoft may ship a patched Chromium base under a different Edge build, may disable or modify relevant code paths, or may document the issue through a security advisory rather than mirroring Chrome’s CVE table line for line. The correct enterprise posture is to monitor both Chrome’s upstream security releases and Microsoft’s Edge security release notes, then let inventory tell you where exposure remains.
NVD’s Missing Score Is Less Important Than CISA’s Signal
At the time reflected in the NVD change history, NIST had not provided its own CVSS 4.0, 3.x, or 2.0 score for CVE-2026-13799. CISA-ADP did provide a CVSS 3.1 score of 8.1 High and an SSVC assessment indicating no known exploitation, no automatable exploitation, and total technical impact. That combination says “serious, but not currently burning down the house.”The absence of an NVD score can frustrate dashboards that rank remediation by NVD base score alone. It can also create odd reporting gaps where a vulnerability looks unscored in one tool and high in another. Mature programs should already be resilient to this. CNA text, vendor advisories, CISA enrichment, known exploitation status, asset exposure, and product criticality all matter.
In fact, this is one of the places where blind CVSS sorting can mislead. A browser bug with no known exploitation but high potential impact may deserve faster action than a lower-scored local bug on a rarely used component. Conversely, the high attack complexity and absence of observed exploitation argue against emergency theater. The right response is accelerated browser patch validation, not a weekend-long incident response bridge.
The scoring also reinforces why NVD’s CPE oddity matters. Vulnerability scanners often use CPEs and CVSS scores as the machinery behind executive reports. If the metadata lags or contains a version-boundary mismatch, the organization may get a distorted picture. Human review is still required, especially during the first days after publication.
QUIC Makes the Browser Feel More Like Infrastructure
QUIC’s rise has changed the browser’s role in the network stack. Historically, much of transport security felt like operating-system territory: TCP in the kernel, TLS libraries shared across applications, and browsers largely focused on document and script handling. HTTP/3 and QUIC moved more of that complexity into browser-controlled user-space code.That shift has benefits. QUIC can evolve faster than TCP, handle connection migration more gracefully, and reduce latency through tighter integration with TLS 1.3. It also gives browser vendors more control over performance tuning and deployment. But security responsibility follows complexity, and complexity has a habit of producing edge cases.
For defenders, this means network-facing browser components deserve the same attention as content engines. Blocking malicious pages is not enough if malformed transport behavior can prod a vulnerable code path. Similarly, network monitoring may not give easy visibility into encrypted QUIC traffic, and simply allowing UDP/443 everywhere can complicate inspection strategies.
Some organizations disable HTTP/3 or QUIC for compatibility, monitoring, or control reasons. CVE-2026-13799 will probably renew that conversation in a few security teams. But disabling a modern protocol as a standing workaround is not a substitute for patching, and it can introduce performance or application-compatibility tradeoffs. The cleaner answer is to keep the browser current and use protocol policy as a risk-management tool, not as an excuse to run stale code.
The Public Bug Is Still Behind a Curtain
Google’s Chromium issue tracker entry for this CVE is referenced by NVD, but access to detailed bug information is restricted. That is normal for Chrome security bugs shortly after release. Google commonly limits details until most users have received the fix, reducing the chance that attackers can weaponize a patch diff before deployment catches up.This creates a familiar tension for defenders. Security teams want technical detail so they can assess exposure and detection options. Vendors withhold detail to prevent easy exploit development. Both positions are rational, and both make the first week after a browser security release an exercise in disciplined uncertainty.
In the absence of exploit details, administrators should avoid overclaiming. There is no public evidence in the supplied NVD data that CVE-2026-13799 is being actively exploited. There is also no basis for assuming it is harmless simply because the bug details are private. The correct middle ground is to patch promptly, verify versions, and watch for vendor or CISA updates.
Researchers will eventually learn more from Chromium commits, downstream advisories, and any later disclosure notes. If the bug turns out to require rare connection-state choreography, it will fade into the long tail of important but unexploited browser fixes. If researchers find a reliable path from malicious network traffic to controlled heap corruption, the risk profile could change quickly.
The Scanner Gap Is Where Real Risk Hides
The user’s question about missing CPE data goes to the heart of vulnerability management in 2026. Enterprises increasingly rely on automated scanners to translate CVEs into action. But browser release trains, vendor-specific builds, staged rollouts, and NVD enrichment timing all conspire to make that translation imperfect.A scanner that keys only on the NVD CPE range may under-report or misclassify CVE-2026-13799 if the version boundary is interpreted incorrectly. A scanner that keys on the CNA affected data may do better, but only if it understands Chrome’s actual installed version. A patch platform may mark the update deployed while the browser process remains un-restarted and still running vulnerable code.
That last point is especially important. Browser updates often require a restart to complete. In real fleets, users keep sessions alive for days, developers pin browsers during testing, and shared workstations may run with long-lived processes. Inventory should distinguish between installed version, running process version, and effective protection.
There is also the problem of Chromium embedded in unexpected places. Electron applications, WebView-based software, and bundled Chromium runtimes do not automatically inherit Chrome’s desktop update. CVE-2026-13799 is specifically a Google Chrome CVE as published, so administrators should not automatically declare every embedded Chromium runtime vulnerable. But the broader lesson remains: the Chromium ecosystem is larger than the browser icon on the taskbar.
Chrome 150’s Giant Security Rollup Is the Context, Not the Footnote
CVE-2026-13799 arrived inside Chrome 150, a release that drew coverage because of the sheer number of security fixes. PCWorld reported that Chrome 150 fixed nearly 400 security flaws, including multiple critical issues, while Born’s IT and Windows Blog counted an even larger total in its German-language write-up of the release. The exact headline number varies depending on which platforms and components are counted, but the direction is unmistakable: modern browser security updates are massive.That scale can numb users and administrators. When every Chrome release includes dozens or hundreds of fixes, individual CVEs blur together. The risk is that organizations treat browser patching as background noise until a zero-day appears in CISA’s Known Exploited Vulnerabilities catalog.
CVE-2026-13799 argues against that complacency. It is not known to be exploited, but it affects a network protocol implementation in the world’s dominant browser family. It has high potential impact. It has early metadata friction. It is exactly the sort of bug that should be remediated before it graduates from advisory text to exploit chatter.
The velocity of Chrome’s security work is both reassuring and sobering. Reassuring, because Google’s fuzzing, bug bounty, and internal security machinery keep finding and fixing memory-safety flaws. Sobering, because the bug count shows how much attack surface a modern browser carries. The patch cadence is not an inconvenience layered on top of the web; it is one of the things keeping the web survivable.
The Fix Is a Version Number, but the Lesson Is an Inventory Discipline
CVE-2026-13799 is not a reason to rip out QUIC, abandon Chrome, or declare every Chromium derivative compromised. It is a reason to treat browser networking code as mission-critical software and to demand better precision from asset and vulnerability data. The short-term job is updating; the long-term job is knowing what is actually running.- Chrome installations should be updated to 150.0.7871.47 or later, and administrators should confirm that users have restarted the browser after the update is staged.
- Vulnerability teams should treat the “prior to 150.0.7871.47” wording from the Chrome CVE record as the conservative exposure boundary while watching for NVD CPE corrections.
- Security dashboards should not wait for a final NVD score when CISA-ADP, the vendor advisory, and the CVE description already establish high-severity risk.
- Edge and other Chromium-based browsers should be checked against their own vendor release notes rather than assumed safe or vulnerable solely from Chrome’s version number.
- Organizations that restrict or inspect QUIC should still patch, because protocol policy is a compensating control, not a durable fix for memory corruption.
- Fleet reports should distinguish installed browser version from running browser version, especially on systems where users keep sessions open for days.
References
- Primary source: NVD / Chromium
Published: 2026-07-03T07:00:00-07:00
NVD - CVE-2026-13799
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-03T07:00:00-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: cvefeed.io
CVE-2026-13799 - Google Chrome QUIC Use-After-Free
Use after free in QUIC in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to potentially exploit heap corruption via malicious network traffic. (Chromium security severity: High)cvefeed.io