Microsoft Edge Stable 151.0.4129.59 is the build Windows administrators should be targeting after a new Hong Kong Computer Emergency Response Team Coordination Centre advisory said versions earlier than that release are affected by multiple security vulnerabilities. The immediate operational message is straightforward: inventory Edge installations, trigger or approve the update where necessary, and verify the installed version after users restart the browser.
But the advisory’s long CVE list does not match Microsoft’s published record for the release. HKCERT’s August 3 bulletin labels the issue medium risk and associates Edge versions before 151.0.4129.59 with remote code execution, denial of service, information disclosure, security-restriction bypass, data manipulation, and spoofing. Microsoft’s own July 31 security release note confirms that Edge Stable 151.0.4129.59 contains Chromium security updates, yet explicitly says that CVE identifiers will be added when available.
That is more than a paperwork discrepancy. Until Microsoft publishes the actual CVE mapping, administrators cannot responsibly use HKCERT’s vulnerability count or individual identifiers to determine severity, exploitability, affected components, compensating controls, or whether a particular detection rule applies. Patch the browser; do not build an incident-response plan around an unverified identifier list.
Microsoft released Edge Stable 151.0.4129.59 on July 31, 2026. Its stable-channel release notes identify the build as the current major version 151 release, while Microsoft’s security notes say it incorporates the latest Chromium security updates. HKCERT’s bulletin, published three days later on August 3, uses the same version as its fixed baseline.
For Windows users, the practical test is uncomplicated. Open Edge’s About page through Settings and more > Help and feedback > About Microsoft Edge, allow the browser to check for updates, and restart it if prompted. The version displayed after restart must be 151.0.4129.59 or newer to meet the advisory’s stated threshold.
The important qualifier is that downloading an update is not the same as running the protected build. Edge frequently stages its update while the browser remains open, especially on machines with long-lived sessions, kiosk use, or persistent background processes. Asset reports should therefore collect the executable version after the restart window, not merely report that Microsoft Edge Update successfully contacted its service.
Microsoft’s release documentation also says Stable-channel releases are delivered progressively over several days. A device set for automatic updates may therefore remain on an earlier build temporarily even when the update has been announced publicly. Microsoft says that security releases with critical fixes use a faster rollout cadence, but the company has not assigned a severity rating to the underlying CVEs for this build because it has not yet published them.
Microsoft’s July 31 Edge security release note does not list any of those CVEs. Instead, beneath the entry for version 151.0.4129.59, Microsoft states that CVEs will be added as soon as they are available. That makes the HKCERT list impossible to validate against the vendor’s published release record at the time of writing.
The mismatch is significant for several reasons. A CVE number by itself does not establish that Edge is affected, that a fix shipped in a particular build, or that a vulnerability has the impact category assigned by a third-party bulletin. Those details depend on the vendor’s advisory: affected product and platform, severity, attack vector, exploitation status, and the update or mitigation that resolves it.
HKCERT’s stated impacts span almost every major browser-security outcome, including remote code execution and security-feature bypass. Yet its bulletin does not map any individual CVE to an impact, component, severity score, or exploit status. Microsoft has likewise not said that any vulnerability fixed in 151.0.4129.59 is being exploited in the wild.
Administrators should treat the bulletin as a valid prompt to update to the specified build, but not as evidence of 385 separately confirmed Edge flaws. The number and identifiers may turn out to be accurate once Microsoft completes its disclosure, but the primary record has not caught up. That distinction should be preserved in vulnerability-management tickets, executive reporting, and SOC detection work.
Taken literally, HKCERT’s statement that every Edge version before 151.0.4129.59 is affected would include all current Extended Stable installations. Microsoft, however, has not published a July 31 Extended Stable security entry corresponding to 151.0.4129.59, nor has its current security note identified an Extended Stable fixed build for the vulnerabilities it says are incorporated from Chromium.
That does not prove Extended Stable is exposed. Chromium fixes are often backported to supported browser branches, and an Extended Stable patch may be covered by a different build number. But neither HKCERT’s generic version threshold nor Microsoft’s still-pending CVE list establishes that relationship.
Organizations using Extended Stable should not respond by abandoning their deployment channel blindly. They should open a vendor support case or monitor Microsoft’s Edge security release notes for a specific Extended Stable statement, then document the decision. The present public record leaves a gap: the advisory flags versions below 151, while Microsoft’s supported managed channel remains on 150.
Microsoft’s lifecycle documentation says Extended Stable is intended for managed environments that need a longer major-release rhythm, with servicing on an eight-week cycle. That makes precise backport information especially important; these customers cannot use a Stable version threshold as a substitute for a channel-specific fixed-version declaration.
This is where a broad “all systems auto-update Edge” assumption fails. Check
Microsoft also draws a practical distinction between enterprise delivery mechanisms. Intune-managed deployments participate in Microsoft’s progressive rollout, meaning some devices may receive the build over the following few days. WSUS and Configuration Manager deployments are administered by the organization; Microsoft says those tools make the update available from the start, but an administrator still has to approve, package, or deploy it.
A short validation sweep should include:
The unresolved part is the vulnerability inventory. Microsoft has acknowledged the release’s Chromium security content but has not yet published the CVEs; HKCERT has published 385 identifiers without the vendor’s corresponding per-CVE details. Until that record is completed, the right status is “patched to the current Stable build” rather than “remediated CVE-by-CVE.”
For Extended Stable estates, the next concrete milestone is Microsoft publishing a channel-specific security update or CVE mapping. Until then, version 150.0.4078.110 should be treated as a population requiring explicit vendor clarification, not a population that can be cleared—or condemned—by a one-line threshold intended for Edge Stable.
That is more than a paperwork discrepancy. Until Microsoft publishes the actual CVE mapping, administrators cannot responsibly use HKCERT’s vulnerability count or individual identifiers to determine severity, exploitability, affected components, compensating controls, or whether a particular detection rule applies. Patch the browser; do not build an incident-response plan around an unverified identifier list.
Edge 151.0.4129.59 is the confirmed remediation target
Microsoft released Edge Stable 151.0.4129.59 on July 31, 2026. Its stable-channel release notes identify the build as the current major version 151 release, while Microsoft’s security notes say it incorporates the latest Chromium security updates. HKCERT’s bulletin, published three days later on August 3, uses the same version as its fixed baseline.For Windows users, the practical test is uncomplicated. Open Edge’s About page through Settings and more > Help and feedback > About Microsoft Edge, allow the browser to check for updates, and restart it if prompted. The version displayed after restart must be 151.0.4129.59 or newer to meet the advisory’s stated threshold.
The important qualifier is that downloading an update is not the same as running the protected build. Edge frequently stages its update while the browser remains open, especially on machines with long-lived sessions, kiosk use, or persistent background processes. Asset reports should therefore collect the executable version after the restart window, not merely report that Microsoft Edge Update successfully contacted its service.
Microsoft’s release documentation also says Stable-channel releases are delivered progressively over several days. A device set for automatic updates may therefore remain on an earlier build temporarily even when the update has been announced publicly. Microsoft says that security releases with critical fixes use a faster rollout cadence, but the company has not assigned a severity rating to the underlying CVEs for this build because it has not yet published them.
HKCERT lists 385 CVEs; Microsoft says the list is pending
HKCERT’s advisory contains 385 CVE identifiers. Most conspicuously, it includes a continuous sequence from CVE-2026-17650 through CVE-2026-18019, followed by 15 additional identifiers in the CVE-2026-65802, CVE-2026-65804, and CVE-2026-66310 through CVE-2026-66326 ranges.Microsoft’s July 31 Edge security release note does not list any of those CVEs. Instead, beneath the entry for version 151.0.4129.59, Microsoft states that CVEs will be added as soon as they are available. That makes the HKCERT list impossible to validate against the vendor’s published release record at the time of writing.
The mismatch is significant for several reasons. A CVE number by itself does not establish that Edge is affected, that a fix shipped in a particular build, or that a vulnerability has the impact category assigned by a third-party bulletin. Those details depend on the vendor’s advisory: affected product and platform, severity, attack vector, exploitation status, and the update or mitigation that resolves it.
HKCERT’s stated impacts span almost every major browser-security outcome, including remote code execution and security-feature bypass. Yet its bulletin does not map any individual CVE to an impact, component, severity score, or exploit status. Microsoft has likewise not said that any vulnerability fixed in 151.0.4129.59 is being exploited in the wild.
Administrators should treat the bulletin as a valid prompt to update to the specified build, but not as evidence of 385 separately confirmed Edge flaws. The number and identifiers may turn out to be accurate once Microsoft completes its disclosure, but the primary record has not caught up. That distinction should be preserved in vulnerability-management tickets, executive reporting, and SOC detection work.
Extended Stable customers need a vendor answer, not an assumption
The version threshold in HKCERT’s advisory introduces a second problem for managed environments: Edge Extended Stable is currently on a different major version. Microsoft’s stable release notes list the current Extended Stable line as version 150.0.4078.110, released July 31, while Stable moved to version 151.0.4129.59.Taken literally, HKCERT’s statement that every Edge version before 151.0.4129.59 is affected would include all current Extended Stable installations. Microsoft, however, has not published a July 31 Extended Stable security entry corresponding to 151.0.4129.59, nor has its current security note identified an Extended Stable fixed build for the vulnerabilities it says are incorporated from Chromium.
That does not prove Extended Stable is exposed. Chromium fixes are often backported to supported browser branches, and an Extended Stable patch may be covered by a different build number. But neither HKCERT’s generic version threshold nor Microsoft’s still-pending CVE list establishes that relationship.
Organizations using Extended Stable should not respond by abandoning their deployment channel blindly. They should open a vendor support case or monitor Microsoft’s Edge security release notes for a specific Extended Stable statement, then document the decision. The present public record leaves a gap: the advisory flags versions below 151, while Microsoft’s supported managed channel remains on 150.
Microsoft’s lifecycle documentation says Extended Stable is intended for managed environments that need a longer major-release rhythm, with servicing on an eight-week cycle. That makes precise backport information especially important; these customers cannot use a Stable version threshold as a substitute for a channel-specific fixed-version declaration.
Update controls can leave machines behind the public release
Edge’s automatic updating is not universal. Microsoft’s update-policy documentation allows organizations to disable updates, allow only manual updates, or permit automatic silent updates. A machine governed by theUpdateDefault or channel-specific Update policy can remain on an older build by design, even though the public Stable release has moved on.This is where a broad “all systems auto-update Edge” assumption fails. Check
edge://policy on representative endpoints and review the Edge Update policy configuration in Group Policy or MDM. In particular, look for update suppression, a target-version prefix, target-channel settings, or an update policy set to disabled or manual-only.Microsoft also draws a practical distinction between enterprise delivery mechanisms. Intune-managed deployments participate in Microsoft’s progressive rollout, meaning some devices may receive the build over the following few days. WSUS and Configuration Manager deployments are administered by the organization; Microsoft says those tools make the update available from the start, but an administrator still has to approve, package, or deploy it.
A short validation sweep should include:
- Confirm that Windows Edge Stable endpoints report version 151.0.4129.59 or later after Edge has been closed and reopened.
- Identify policies that block automatic updates or pin devices to version 150 or an older major release.
- Separate Stable and Extended Stable populations in reporting rather than marking all version 150 devices compliant or vulnerable from the generic HKCERT threshold alone.
- Avoid assigning detection content, severity, or exploit status to the CVE list until Microsoft publishes the official mappings.
The useful conclusion is narrower than the bulletin suggests
The reliable part of this story is that Microsoft Edge Stable 151.0.4129.59 is a security-bearing release and that HKCERT has advised updating older Edge versions to it. On Windows endpoints following the Stable channel, that is sufficient reason to deploy and verify the update now.The unresolved part is the vulnerability inventory. Microsoft has acknowledged the release’s Chromium security content but has not yet published the CVEs; HKCERT has published 385 identifiers without the vendor’s corresponding per-CVE details. Until that record is completed, the right status is “patched to the current Stable build” rather than “remediated CVE-by-CVE.”
For Extended Stable estates, the next concrete milestone is Microsoft publishing a channel-specific security update or CVE mapping. Until then, version 150.0.4078.110 should be treated as a population requiring explicit vendor clarification, not a population that can be cleared—or condemned—by a one-line threshold intended for Edge Stable.
References
- Primary source: Hong Kong Computer Emergency Response Team Coordination Centre
Published: Mon, 03 Aug 2026 02:00:40 GMT
Microsoft Edge Multiple Vulnerabilities
Multiple vulnerabilities were identified in Microsoft Edge. A remote attacker could exploit some of these vulnerabilities to trigger denial of service condition, security restriction bypass, sensitive information disclosure, remote code execution, data mawww.hkcert.org - Related coverage: learn.microsoft.com
Microsoft Edge Update Policy Documentation | Microsoft Learn
Documentation for all policies supported by the Microsoft Edge Updaterlearn.microsoft.com - Related coverage: learn.microsoft.com
Microsoft Edge Browser Policy Documentation | Microsoft Learn
Windows and Mac documentation for all policies supported by the Microsoft Edge Browserlearn.microsoft.com
