CVE-2025-12435: How Edge Chrome Patch Chromium Omnibox Spoofing

Chromium’s recent CVE entry for an “Incorrect security UI in Omnibox” (CVE‑2025‑12435) is not a mystery when you understand how Chromium, Chrome and Microsoft Edge are interrelated — and why Microsoft documents upstream Chromium bugs in its Security Update Guide. In short: Chromium is the open‑source engine that powers Google Chrome and many other browsers (including Microsoft Edge), so when a security issue lands in Chromium or Chrome, Microsoft tracks and records it to tell Edge users whether their Edge build remains affected. This article explains what CVE‑2025‑12435 actually is, why it appears in Microsoft’s Security Update Guide, how downstream patching works, and precise, practical steps you can use to check whether your browser build is protected — whether you run Chrome, Microsoft Edge (Chromium‑based), or manage fleets in an organization.

Background / Overview​

Chromium is the open‑source project that implements the rendering engine, JavaScript engine and much of the browser plumbing used by Google Chrome and several other browsers. Vendors — Google and Microsoft among them — take Chromium’s source code, add proprietary bits, testing and packaging, then ship a branded browser. Because many vendors share the same upstream code, a security bug discovered in Chromium or in Google Chrome frequently affects multiple browsers.
When an upstream bug is found and assigned a CVE, Google typically publishes a Chrome release that contains the fix and a Chromium changelist that documents the actual patch. Downstream vendors then absorb that fix into their own builds and ship updates. Microsoft uses its Security Update Guide to record that process: an entry for a Chromium/Chrome CVE will show up to indicate the vulnerability’s existence and to document whether Microsoft Edge (Chromium‑based) is affected and, importantly, whether a given Edge build has already ingested the upstream fix.
This is why you will sometimes see CVE entries in Microsoft’s update catalog for vulnerabilities that originated in Chromium: the entry is a status, not necessarily an admission that Microsoft introduced the bug. It tells administrators and end users whether the Edge versions they run are still vulnerable, and it gives the authoritative word on remediation status for Edge.

---

What CVE‑2025‑12435 is — the technical picture​

CVE‑2025‑12435 is classified as an “Incorrect security UI in Omnibox” issue. In plain terms, this family of bugs affects the information the browser shows in the omnibox (the combined address/search bar). A successful exploit could cause the omnibox to display misleading content — for example, showing a trusted site URL or padlock visual when the user is actually on a malicious page — which in turn makes phishing and spoofing attacks significantly easier.
Key technical points about this sort of defect:

• The omnibox is a primary authenticity indicator for users. If its contents can be spoofed, user judgment about site trustworthiness can be compromised.
• These flaws are typically UI or rendering validation issues: untrusted HTML, script or state changes are rendered or shown without proper normalization or sanitization.
• Exploiting an omnibox spoofing bug often requires user interaction (for example, visiting a crafted page or clicking a link), so many of these vulnerabilities are rated with user interaction required, but that does not make them harmless — successful phishing with a spoofed omnibox can lead to credential theft or fraud.

For CVE‑2025‑12435, the fix was rolled into a Chrome stable update that Google published; the patched Chrome builds for desktop include version 142.0.7444.59/60. The fix was credited to an external reporter (the public disclosure lists the researcher as Hafiizh).
Note: Omnibox UI bugs are a recurring class of issues; historically, several CVEs across multiple years have dealt with Omnibox or navigation UI weaknesses. The remediation pattern is consistent: patch the Chromium UI logic, publish a Chrome release, and downstream vendors absorb and ship their own updates.

---

Why Microsoft includes Chrome/Chromium CVEs in the Security Update Guide​

Microsoft’s Security Update Guide (SUG) is a single place for enterprises and administrators to see which Microsoft products are affected by which vulnerabilities, and whether a patch is available. When Chromium or Chrome has a CVE that could affect Edge, Microsoft records that CVE in SUG and then shows the Edge status for that CVE.
Microsoft includes Chromium/Chrome CVEs in SUG for these reasons:

• Downstream consumption: Microsoft Edge (Chromium‑based) uses Chromium as its core. A Chromium security fix is therefore relevant to Edge; documenting the CVE clarifies Edge’s exposure and mitigation status.
• Transparency for admins: Enterprises review SUG to determine whether their managed endpoints are vulnerable and what update they must deploy. Listing Chromium CVEs with Edge’s ingest status reduces guesswork.
• Compliance and tracking: Many organizations mandate that all CVEs affecting installed software must be tracked in a central console. Microsoft’s SUG entry provides the authoritative statement that Edge’s latest build is (or is not) vulnerable.
• Clarifying responsibility: The SUG entry distinguishes between the origin of the issue (Chromium/Chrome) and whether Microsoft’s Edge product was affected or required an additional fix. That distinction is important for legal, regulatory and operational reasons.

In short: a Chrome CVE appears in Microsoft’s guide so you can immediately check whether Microsoft Edge has the same exposure and whether your Edge build includes the upstream patch. It’s a protective, downstream confirmation — not a suggestion that Microsoft created the issue.

---

How Chromium fixes make their way into Edge (the patch pipeline)​

Understanding the patch pipeline helps explain timing differences you might notice between Chrome and Edge updates.

• Patch lands upstream: A developer or researcher reports a bug to Chromium/Google, the Chromium team verifies and patches the code, and Google bundles the fix into a Chrome release.
• Chrome publishes: Google publishes Chrome release notes documenting the fixed CVEs and shipping version numbers.
• Downstream vendors ingest: Microsoft takes the Chromium source, merges upstream changes (often in batches or at scheduled points), performs its own testing and may add Edge‑specific fixes or policies.
• Edge release: Microsoft publishes an Edge build that “incorporates the latest Security Updates of the Chromium project,” and records the ingestion in its release notes and in the Security Update Guide.
• Administrators update: End users and organizations update Edge (manual or automatic), which results in the patched state.

Because Microsoft does testing and integration work, Edge may lag Chrome by days or occasionally weeks. That’s expected — it’s the tradeoff for Microsoft ensuring stability and compatibility with Edge’s features.

---

How to see whether your browser is the fixed version — step‑by‑step checks​

Below are precise, platform‑agnostic steps you can use to determine whether your browser is patched for a Chromium CVE such as CVE‑2025‑12435. The method is simple: check your browser’s exact version, compare it against the fixed upstream Chrome build, and then verify whether Microsoft’s Edge release notes / Security Update Guide list that CVE as “Mitigated” for the Edge build you have or the Edge build that you must reach.

1) Check the browser build (Microsoft Edge — GUI)​

• Open Microsoft Edge.
• Click the three‑dot menu in the top right corner, choose Settings, then choose About Microsoft Edge.
• Alternatively, paste edge://settings/help into the address bar and press Enter.
• Edge will automatically check for updates and display the full build number (for example, 142.0.7444.XX). Note the full version including the three‑part or four‑part version string.

2) Check the browser build (Google Chrome — GUI)​

• Open Google Chrome.
• Click the three‑dot menu > Help > About Google Chrome, or paste chrome://settings/help in the address bar.
• Chrome will show the exact version (for example, 142.0.7444.59). Note the complete build string.

3) Check the browser build (address bar shortcuts)​

• For Edge, type edge://version and press Enter.
• For Chrome, type chrome://version and press Enter.
• These pages give the full version string, the channel (Stable/Beta/Dev), and the underlying Chromium version.

4) Command‑line checks (Windows)​

• PowerShell: run Get‑ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall" | Where‑Object { $_.DisplayName -like 'Edge*' } | Select DisplayName, DisplayVersion
• winget: winget list --name Microsoft.Edge shows installed package and version.
• For Chrome: winget list --name Google.Chrome or inspect the file properties of chrome.exe in the installation folder.

5) Command‑line checks (macOS, Linux)​

• macOS: open the Edge/Chrome application bundle and check Info.plist, or use the browser GUI About page.
• Linux: check the package manager (apt, rpm) for the installed chromium/chrome package version.

6) How to compare versions safely​

• If the fixed Chrome build is 142.0.7444.59, you should have a browser build number equal to or greater than the fixed build to be considered patched for that upstream fix.
• For Edge, Microsoft may show a different Edge build number even if it contains Chromium 142. In that case, consult Microsoft’s Edge release notes and the Security Update Guide entry for that CVE: they will indicate which Edge build “incorporates the latest Security Updates of the Chromium project” that correspond to the Chrome fix.
• If your Edge build is older than the Edge build that ingested the Chromium fix, update Edge.

---

How to verify Microsoft’s status for a CVE (what to look for in the Security Update Guide)​

When you open the Security Update Guide entry for a Chrome/Chromium CVE (the page you provided), look for these elements:

• Affected Products / Versions: Microsoft lists whether Edge (or another Microsoft product) is affected. If Edge is listed, the page will show whether the issue is mitigated in a specific Microsoft Edge build.
• Status field: It will indicate “Mitigated” or “Not mitigated” for a particular Microsoft build. That is the authoritative statement for Microsoft deployments.
• Published/Updated dates: These tell you when Microsoft confirmed the ingest and when the guidance took effect.
• Mitigation guidance: There may be links or short instructions for updating Edge or for enterprise remediation policies.

Procedure:

• Check the CVE entry in Microsoft’s Security Update Guide.
• Note the Edge build number Microsoft reports as containing the fix (if present).
• Compare that Edge build number to your installed Edge version (from the About page).
• If your version number is equal to or higher than the Microsoft‑reported mitigation version, your Edge installation is no longer vulnerable.

If Microsoft does not yet show a mitigation for Edge in SUG, but Google has published a Chrome fix, expect a short delay while Microsoft ingests and tests upstream changes; monitor the Edge release notes and SUG for the update.

---

Enterprise patching and reporting considerations​

For organizations, a single desktop About page is not sufficient. Here are operational paths administrators should use:

• SCCM / ConfigMgr: Inventory installed Edge versions and create compliance rules that require the minimum Edge build indicated in Microsoft’s SUG.
• Intune / MEM: Use device compliance and app update policies to ensure Edge is updated to the required corporate baseline.
• WSUS / Microsoft Update Catalog: Validate whether the Edge update that incorporates the Chromium fix is published and approved to the environment.
• Security Information and Event Management (SIEM): Ingest inventory data and flag endpoints that fall below the mitigation build.
• Automated reporting: Script regular checks (for example via PowerShell and winget or registry queries) and produce compliance dashboards showing percentage of devices at or above the patched build.

If you manage a fleet, plan for the typical lag between Chrome shipping and Edge ingesting the upstream fix; but treat the Microsoft Security Update Guide as the authoritative statement for Edge.

---

Practical remediation: what to do now​

• Check your browser version immediately (use the steps above).
• Update to the latest available build through the browser About page or your enterprise patching system.
• If you run Microsoft Edge, rely on the Security Update Guide entry to confirm Edge’s mitigation status for CVE‑2025‑12435 and update to at least the Microsoft‑listed build.
• Enable automatic updates where possible. Most modern browser channels will update automatically; enterprise systems should schedule and monitor those updates.
• Harden UI indicators: Use built‑in browser security features — for Edge, enable enhanced security modes and strict site isolation features where available.
• User education: Remind users to double‑check context (e.g., do not rely on a shown URL alone when entering credentials) and to report suspicious pages.

---

Risk assessment and analysis​

CVE‑2025‑12435 was rated medium in the Chrome release documentation and the fix was included in Chrome 142. The risk model for an omnibox UI spoof hinges on these factors:

• Likelihood of exploit: UI‑spoofing bugs generally require user interaction (visiting a page), and often exploit complexity is low. That combination makes them suitable for phishing campaigns, which are easy and effective.
• Impact: While not typically a direct remote code execution vulnerability, the integrity impact is high for user trust indicators — a spoofed omnibox can lead to credential capture, fraud and further social engineering attacks.
• Exploitability in the wild: If public exploit details are limited and no active exploitation is reported, practical risk is reduced but not eliminated. Attackers frequently reuse UI spoofing techniques to amplify phishing effectiveness.
• Downstream risk surface: Because many browsers share Chromium, the patch surface is broad. If downstream vendors delay ingestion, a window exists where non‑patched Edge builds (or other Chromium builds) remain vulnerable even after Chrome’s release.

Bottom line: treating omnibox spoofing as a serious phishing enabler is prudent. Patch promptly and combine that with user training and anti‑phishing controls (browser‑level protections, DNS filtering, endpoint detection).

---

Common questions and clarifications​

• Q: Does Microsoft put Chrome bugs in SUG even when Edge wasn’t vulnerable?
  Microsoft lists CVEs that are relevant to Edge. If the underlying upstream bug could affect Edge or if Edge needed to ingest the upstream patch, Microsoft will record it. The presence of a CVE in SUG does not automatically mean Microsoft introduced the issue; it signals a tracking and mitigation record.
• Q: If Chrome is patched, does that mean Edge is automatically patched?
  No. Edge needs to ingest the Chromium change and ship its own build. Microsoft documents that ingest in release notes and SUG. Always confirm Edge’s mitigation status in Microsoft’s SUG or in Edge release notes.
• Q: What if my Edge version number doesn’t match Chrome’s build number?
  That’s normal. Edge’s version numbering is vendor‑specific even though it contains a Chromium baseline. Use Microsoft’s release notes and SUG to map Edge builds to the Chromium fixes they contain.
• Q: What if SUG shows Edge is not yet mitigated for a CVE that Chrome says it fixed weeks ago?
  Expect a short testing/ingestion window. If your environment cannot wait, consider hardening controls (for example, block or filter suspicious sites at the network layer) until Edge’s patched build is available.

---

Final takeaways — practical checklist​

• Check your browser version now: About page or address‑bar version pages provide the exact build string.
• Compare to fixed Chrome build: For CVE‑2025‑12435, Chrome’s fix ships in Chromium/Chrome 142.0.7444.59/60 — but don’t assume Edge is covered until Microsoft’s SUG or Edge release notes confirm ingestion.
• Use Microsoft’s Security Update Guide: It is the authoritative place to verify whether Microsoft Edge is mitigated for the CVE.
• Update promptly: Apply browser updates or enterprise patches as soon as your update process allows.
• Layer defenses: Combine patching with anti‑phishing controls and user awareness to reduce the realistic attack surface created by UI‑spoofing bugs.

---

CVE‑2025‑12435 is a reminder of how tightly interconnected modern browser ecosystems are: an upstream fix in Chromium ripples through Chrome and must be tracked and ingested by downstream vendors like Microsoft. Microsoft’s Security Update Guide performs a vital role by documenting that chain and telling admins and users when Edge has formally become not vulnerable. Checking your browser version and aligning with the SUG guidance is the fastest, most reliable way to confirm protection.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center