Google’s CVE-2026-13809 is a high-severity Safe Browsing side-channel flaw affecting Chrome on iOS before version 150.0.7871.47. According to the Chrome-supplied CVE description, a remote attacker who has already compromised the renderer can use a crafted HTML page to leak cross-origin data. The immediate action is straightforward: update Chrome on affected iPhones and iPads. For Windows-focused security teams, the distinctive challenge is equally clear—avoid assigning this mobile-only CVE to desktop Chrome while ensuring that mobile browser installations are not missing from inventory.
Security advisories often compress very different risks into similar language. Terms such as “remote attacker,” “crafted HTML page,” and “High” can resemble the outline of a self-contained drive-by compromise. CVE-2026-13809 has a more qualified public description.
According to the CVE record supplied by Chrome and presented through the National Vulnerability Database, the attacker must have compromised the renderer before using the Safe Browsing side channel. The vulnerability is therefore best understood as a follow-on capability: it can expose information across web-origin boundaries after another weakness or attack stage has established the required renderer foothold.
The prerequisite should not be minimized. Browser attacks can be assembled from multiple weaknesses, with each one contributing a different capability. A vulnerability that requires an existing foothold may still be valuable when paired with another flaw.
At the same time, reporting should stop at what the public description establishes. The record supports a renderer-compromise prerequisite, crafted HTML as the attack vehicle, and cross-origin data leakage as the result. It does not, by itself, establish the complete mechanics or consequences of a larger attack chain.
That distinction matters during triage. Teams should not dismiss the issue merely because it requires a prerequisite, but they also should not expand the record into unsupported claims about what happens before or after the leakage. The presence of an affected Chrome version establishes exposure to the documented condition; it does not establish that exploitation occurred.
The CISA-ADP CVSS vector provides additional context. The displayed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. It models a network-accessible issue with low attack complexity, no privileges required, user interaction required, unchanged scope, high confidentiality impact, and no stated integrity or availability impact.
The user-interaction field should also be interpreted carefully. The CVE description identifies a crafted HTML page, but the available material does not provide enough detail to define every action that the user or browser must take. Internal advisories should not invent a specific click sequence, navigation pattern, or delivery campaign.
The record does not establish whether the observable condition involves timing, requests, caching, resource use, state transitions, or another measurement. It also does not identify the precise data exposed, the number of observations required, or the circumstances under which the leakage becomes useful.
The associated Chromium issue is permission-restricted. That fact supports only the narrow conclusion that the underlying issue details are not publicly accessible through the referenced issue page. It should not be turned into a general claim about Google’s disclosure policy or its reasons for restricting access.
The phrase “cross-origin data” remains the key impact statement. Web origins form a central browser security boundary intended to prevent content associated with one origin from improperly reading information belonging to another. The CVE description says this vulnerability can leak data across that boundary after renderer compromise.
That does not establish that every type of browser data is exposed or that an attacker can retrieve every credential, page, account record, or session value. The volume, sensitivity, reliability, and practical value of the leaked information depend on technical details that are not contained in the supplied record.
CISA-ADP’s confidentiality assessment is nevertheless significant. Its CVSS contribution assigns high confidentiality impact while leaving integrity and availability unaffected. That is consistent with the stated information-leakage outcome, but the CVSS fields should not be treated as a substitute for technical details that have not been published.
Defenders therefore remain in patch-first mode. The record provides enough information to identify the affected product and version range, but not enough to build a CVE-specific detection method from the side channel’s undisclosed behavior.
Those labels come from different assessment processes. Chrome’s label is the vendor’s product-specific severity characterization. CVSS applies a standardized vector so that technical characteristics can be represented consistently across products.
The numerical score should be attributed correctly. The supplied NVD material displays the CISA-ADP CVSS contribution; it does not establish that NVD independently calculated the 6.5 score. Internal reports should therefore say “CISA-ADP scored the vulnerability 6.5 Medium,” not “NVD rated it 6.5.”
The renderer-compromise prerequisite also demonstrates why base-score sorting cannot replace record review. The CVSS vector captures the selected standardized metrics, while the prose description provides an important precondition that administrators need when explaining the risk.
Neither the High label nor the Medium score changes the affected-version boundary. Chrome on iOS before 150.0.7871.47 is within the CVE’s stated affected range. Version 150.0.7871.47 and later is outside that range for this vulnerability, without implying that such versions are unaffected by every other security issue.
That platform condition is critical for vulnerability-management accuracy. A scanner or ticketing rule that matches only the application name “Google Chrome” may incorrectly assign the CVE to Windows workstations. Administrators should verify that detection logic evaluates the operating system as well as the product and version.
Desktop false positives are not harmless paperwork. They consume remediation time, distort vulnerability counts, and weaken trust in browser findings. Windows teams should reject findings that lack the required iOS platform condition rather than launching a desktop Chrome campaign for this CVE.
The opposite error is a mobile-inventory blind spot. An organization can maintain detailed Windows browser reporting while having incomplete evidence for applications installed on managed iPhones and iPads. If mobile app versions are not collected, the organization cannot demonstrate whether Chrome is below or outside the stated affected range.
The correct response is not to speculate about how a particular management platform handles mobile applications. Capabilities differ. Instead, administrators should define the required outcome and then determine whether their chosen mobile device management platform supports the necessary inventory, notification, update, or enforcement functions.
WindowsForum’s practical takeaway is therefore two-sided:
That is enough to support remediation. It is not enough to support a detailed exploit walkthrough, a network signature, or a behavioral hunting rule tailored to the side channel.
The supplied material does not establish whether a public proof of concept or CVE-specific detection indicator exists. Reporting should simply avoid making either positive or negative claims on those points without an additional source.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization entry adds three exact decision values:
“Automatable: no” is likewise a record value, not a complete forecast of attacker behavior. An editorial interpretation is that the documented prerequisite may make broad, indiscriminate use less straightforward than exploitation of a self-contained vulnerability. That is an inference, not a fact stated by SSVC.
“Technical impact: partial” is the third recorded value. It can be discussed alongside the CVSS confidentiality impact and the absence of integrity and availability impact in the vector, but it should not be expanded into unsupported statements about browser, sandbox, or device control.
As an editorial prioritization judgment, the combination of a prerequisite, “exploitation: none,” and “automatable: no” does not suggest the same emergency posture as a confirmed, broadly automated attack. That judgment is not an SSVC fact and should not delay a direct, low-complexity remediation: updating the affected application.
Chrome supplied the vulnerability description and affected-version information. CISA-ADP contributed the displayed CVSS 3.1 assessment and SSVC values. NIST added affected-product configuration information that associates Chrome with Apple’s iPhone operating system.
The weakness metadata requires particularly careful wording. The supplied facts establish that Chrome is shown as the source for CWE-1300 and that CISA-ADP later removed a CWE entry. They do not support a precise claim that Chrome’s initial receipt added CWE-1300 in a particular event sequence, nor do they establish when CISA-ADP first added that weakness entry.
Administrators do not need to resolve every contributor-level metadata change before remediating the product. The load-bearing facts remain stable: the issue is in Chrome’s Safe Browsing component on iOS, versions before 150.0.7871.47 are affected, prior renderer compromise is required, crafted HTML is involved, and the stated consequence is cross-origin data leakage.
The broader lesson is that a field displayed by NVD is not necessarily authored or calculated by NVD. Vulnerability-management systems should preserve contributor provenance when importing severity, SSVC, weakness, and product-configuration fields.
This workflow is intentionally product-neutral. Whether an organization can force an application update, issue a user notification, mark a device noncompliant, or apply another enforcement action depends on the capabilities and configuration of its mobile device management platform.
An old version alone is also not evidence that cross-origin data was taken. It establishes that the application falls within the documented affected range. Incident-response escalation should be based on separate evidence of suspicious activity or compromise rather than version status alone.
The supplied sources do not verify a Chrome for iOS menu path that reliably displays the full installed version, so users should not be directed to an unconfirmed Settings, About, or version sequence. Nor should Chrome Safety Check be presented as the verification method: the supplied record and added official update guidance do not establish that Safety Check identifies this update on iOS.
The advisory does not provide a configuration workaround equivalent to updating. User communications should therefore concentrate on completing the App Store update rather than prescribing speculative changes to Safe Browsing or unrelated browser settings.
Administrators should also avoid issuing broad cleanup instructions that are not supported by the record. The CVE does not, by itself, establish that every user of an affected version suffered data exposure. Remediation notices should distinguish a vulnerable installation from a confirmed security incident.
A concise user message can say:
If the answer is no, the desktop ticket should not remain open solely because Google Chrome appears in the software inventory. Detection content should be corrected so that it requires the affected operating-system condition.
If the answer is unknown because mobile application data is absent, the finding exposes an inventory problem rather than a Windows Chrome problem. The appropriate next step is to involve the team responsible for managed iOS inventory and query for
This division of responsibility should not become a handoff into silence. Windows vulnerability teams often maintain the organization’s browser-risk reporting, while mobility teams hold the relevant device data. A durable process should connect those functions so that product scope, mobile inventory, remediation evidence, and ticket closure remain consistent.
For WindowsForum readers, that is the lasting lesson from CVE-2026-13809. Accurate vulnerability management requires more than recognizing a familiar product name. It requires matching the application, platform, complete version, and contributor-supplied conditions before assigning work.
The best outcome is not the largest possible remediation campaign. It is a precise one: remove unsupported desktop findings, identify the genuinely affected mobile installations, use whatever update controls the management platform actually supports, and preserve fresh version evidence when the work is complete.
The Renderer Prerequisite Changes the Entire Story
Security advisories often compress very different risks into similar language. Terms such as “remote attacker,” “crafted HTML page,” and “High” can resemble the outline of a self-contained drive-by compromise. CVE-2026-13809 has a more qualified public description.According to the CVE record supplied by Chrome and presented through the National Vulnerability Database, the attacker must have compromised the renderer before using the Safe Browsing side channel. The vulnerability is therefore best understood as a follow-on capability: it can expose information across web-origin boundaries after another weakness or attack stage has established the required renderer foothold.
The prerequisite should not be minimized. Browser attacks can be assembled from multiple weaknesses, with each one contributing a different capability. A vulnerability that requires an existing foothold may still be valuable when paired with another flaw.
At the same time, reporting should stop at what the public description establishes. The record supports a renderer-compromise prerequisite, crafted HTML as the attack vehicle, and cross-origin data leakage as the result. It does not, by itself, establish the complete mechanics or consequences of a larger attack chain.
That distinction matters during triage. Teams should not dismiss the issue merely because it requires a prerequisite, but they also should not expand the record into unsupported claims about what happens before or after the leakage. The presence of an affected Chrome version establishes exposure to the documented condition; it does not establish that exploitation occurred.
The CISA-ADP CVSS vector provides additional context. The displayed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. It models a network-accessible issue with low attack complexity, no privileges required, user interaction required, unchanged scope, high confidentiality impact, and no stated integrity or availability impact.
The user-interaction field should also be interpreted carefully. The CVE description identifies a crafted HTML page, but the available material does not provide enough detail to define every action that the user or browser must take. Internal advisories should not invent a specific click sequence, navigation pattern, or delivery campaign.
The Public Record Identifies a Side Channel, Not Its Mechanics
CVE-2026-13809 is described as a side-channel information leak in Chrome’s Safe Browsing component. Beyond that high-level identification, the supplied material does not explain the Safe Browsing design or the signal exposed by the vulnerability.The record does not establish whether the observable condition involves timing, requests, caching, resource use, state transitions, or another measurement. It also does not identify the precise data exposed, the number of observations required, or the circumstances under which the leakage becomes useful.
The associated Chromium issue is permission-restricted. That fact supports only the narrow conclusion that the underlying issue details are not publicly accessible through the referenced issue page. It should not be turned into a general claim about Google’s disclosure policy or its reasons for restricting access.
The phrase “cross-origin data” remains the key impact statement. Web origins form a central browser security boundary intended to prevent content associated with one origin from improperly reading information belonging to another. The CVE description says this vulnerability can leak data across that boundary after renderer compromise.
That does not establish that every type of browser data is exposed or that an attacker can retrieve every credential, page, account record, or session value. The volume, sensitivity, reliability, and practical value of the leaked information depend on technical details that are not contained in the supplied record.
CISA-ADP’s confidentiality assessment is nevertheless significant. Its CVSS contribution assigns high confidentiality impact while leaving integrity and availability unaffected. That is consistent with the stated information-leakage outcome, but the CVSS fields should not be treated as a substitute for technical details that have not been published.
Defenders therefore remain in patch-first mode. The record provides enough information to identify the affected product and version range, but not enough to build a CVE-specific detection method from the side channel’s undisclosed behavior.
“High” and 6.5 “Medium” Measure Different Things
The record contains two severity presentations: Chrome characterizes CVE-2026-13809 as High, while the CISA-ADP CVSS 3.1 contribution produces a base score of 6.5, categorized as Medium.Those labels come from different assessment processes. Chrome’s label is the vendor’s product-specific severity characterization. CVSS applies a standardized vector so that technical characteristics can be represented consistently across products.
The numerical score should be attributed correctly. The supplied NVD material displays the CISA-ADP CVSS contribution; it does not establish that NVD independently calculated the 6.5 score. Internal reports should therefore say “CISA-ADP scored the vulnerability 6.5 Medium,” not “NVD rated it 6.5.”
The renderer-compromise prerequisite also demonstrates why base-score sorting cannot replace record review. The CVSS vector captures the selected standardized metrics, while the prose description provides an important precondition that administrators need when explaining the risk.
Neither the High label nor the Medium score changes the affected-version boundary. Chrome on iOS before 150.0.7871.47 is within the CVE’s stated affected range. Version 150.0.7871.47 and later is outside that range for this vulnerability, without implying that such versions are unaffected by every other security issue.
| Deployment or version state | Status in the CVE record | Practical interpretation | Required response |
|---|---|---|---|
| Chrome on iOS before 150.0.7871.47 | Affected | The documented side-channel leakage may be available after renderer compromise | Update Chrome |
| Chrome on iOS at 150.0.7871.47 or later | Outside the stated affected range | The installation has crossed this CVE’s published version boundary | Record the version and continue normal update management |
| Chrome on Windows or another desktop platform | Not identified as affected | The supplied configuration is specific to Chrome on Apple’s iPhone operating system | Do not assign this CVE solely because Chrome is installed |
| Another browser on iOS | Not identified in the affected-product record | The CVE names Google Chrome rather than every iOS browser | Evaluate through that browser vendor’s own information |
| Chrome version unavailable or incomplete | Unresolved | Compliance with the affected boundary cannot be demonstrated | Collect fresh inventory evidence |
Platform Matching Is the WindowsForum Angle
CVE-2026-13809 applies to Google Chrome on iOS. NIST’s affected-product configuration combines the Chrome application with Apple’s iPhone operating-system platform. The record does not identify Chrome on Windows as an affected configuration.That platform condition is critical for vulnerability-management accuracy. A scanner or ticketing rule that matches only the application name “Google Chrome” may incorrectly assign the CVE to Windows workstations. Administrators should verify that detection logic evaluates the operating system as well as the product and version.
Desktop false positives are not harmless paperwork. They consume remediation time, distort vulnerability counts, and weaken trust in browser findings. Windows teams should reject findings that lack the required iOS platform condition rather than launching a desktop Chrome campaign for this CVE.
The opposite error is a mobile-inventory blind spot. An organization can maintain detailed Windows browser reporting while having incomplete evidence for applications installed on managed iPhones and iPads. If mobile app versions are not collected, the organization cannot demonstrate whether Chrome is below or outside the stated affected range.
The correct response is not to speculate about how a particular management platform handles mobile applications. Capabilities differ. Instead, administrators should define the required outcome and then determine whether their chosen mobile device management platform supports the necessary inventory, notification, update, or enforcement functions.
WindowsForum’s practical takeaway is therefore two-sided:
- Preserve the platform boundary so that desktop Chrome does not receive an unsupported CVE assignment.
- Close the mobile inventory gap so that affected Chrome installations on iOS are not overlooked.
The Private Chromium Issue Keeps Defenders in Patch-First Mode
The NVD record references Chromium issue 504222227, but access to that issue is permission-restricted. The public technical account is consequently limited to the CVE description and contributed metadata: a Safe Browsing side channel, prior renderer compromise, crafted HTML, cross-origin leakage, and the affected-version boundary.That is enough to support remediation. It is not enough to support a detailed exploit walkthrough, a network signature, or a behavioral hunting rule tailored to the side channel.
The supplied material does not establish whether a public proof of concept or CVE-specific detection indicator exists. Reporting should simply avoid making either positive or negative claims on those points without an additional source.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization entry adds three exact decision values:
- Exploitation: none
- Automatable: no
- Technical impact: partial
“Automatable: no” is likewise a record value, not a complete forecast of attacker behavior. An editorial interpretation is that the documented prerequisite may make broad, indiscriminate use less straightforward than exploitation of a self-contained vulnerability. That is an inference, not a fact stated by SSVC.
“Technical impact: partial” is the third recorded value. It can be discussed alongside the CVSS confidentiality impact and the absence of integrity and availability impact in the vector, but it should not be expanded into unsupported statements about browser, sandbox, or device control.
As an editorial prioritization judgment, the combination of a prerequisite, “exploitation: none,” and “automatable: no” does not suggest the same emergency posture as a confirmed, broadly automated attack. That judgment is not an SSVC fact and should not delay a direct, low-complexity remediation: updating the affected application.
The Record Was Enriched by Multiple Contributors
The CVE presentation combines information from Chrome, CISA-ADP, and NIST. Understanding that provenance prevents several common reporting errors.Chrome supplied the vulnerability description and affected-version information. CISA-ADP contributed the displayed CVSS 3.1 assessment and SSVC values. NIST added affected-product configuration information that associates Chrome with Apple’s iPhone operating system.
The weakness metadata requires particularly careful wording. The supplied facts establish that Chrome is shown as the source for CWE-1300 and that CISA-ADP later removed a CWE entry. They do not support a precise claim that Chrome’s initial receipt added CWE-1300 in a particular event sequence, nor do they establish when CISA-ADP first added that weakness entry.
Administrators do not need to resolve every contributor-level metadata change before remediating the product. The load-bearing facts remain stable: the issue is in Chrome’s Safe Browsing component on iOS, versions before 150.0.7871.47 are affected, prior renderer compromise is required, crafted HTML is involved, and the stated consequence is cross-origin data leakage.
Timeline
- Chrome-originated CVE information: Chrome supplied the vulnerability description, the affected-version boundary, the vendor reference, and the permission-restricted Chromium issue reference.
- CISA-ADP assessment: CISA-ADP contributed the CVSS 3.1 vector and 6.5 Medium base score, together with SSVC values of exploitation none, automatable no, and technical impact partial.
- NIST product analysis: NIST added the affected-product configuration connecting the relevant Chrome versions with Apple’s iPhone operating-system platform.
- Weakness-record change: The supplied history shows CISA-ADP removing a CWE entry, while the displayed weakness information identifies CWE-1300 with Chrome as the source. The available facts do not support a more exact chronology for when each contributor initially added that classification.
The broader lesson is that a field displayed by NVD is not necessarily authored or calculated by NVD. Vulnerability-management systems should preserve contributor provenance when importing severity, SSVC, weakness, and product-configuration fields.
Mobile Browser Inventory Is the Administrative Test
The technical remediation is simpler than the compliance task. Organizations must identify managed iOS devices with the Chrome application identifiercom.google.chrome, compare the complete installed version with 150.0.7871.47, take action on older installations, and then collect fresh evidence.This workflow is intentionally product-neutral. Whether an organization can force an application update, issue a user notification, mark a device noncompliant, or apply another enforcement action depends on the capabilities and configuration of its mobile device management platform.
Action checklist for administrators
- Query managed iOS devices for
com.google.chrome.
Collect the application identifier, complete installed version, device identifier, user or ownership record where appropriate, and inventory collection time. - Filter for versions below 150.0.7871.47.
Use the full four-part version. Do not compare only the major version, and do not treat missing or incomplete version data as compliant. - Separate desktop findings from mobile findings.
Confirm that CVE-2026-13809 is not being assigned to Windows Chrome merely because the product name matches. - Notify users or enforce the update through the organization’s MDM if supported.
Available notification, managed-app update, compliance, or enforcement functions depend on the management platform. Do not claim a capability until it has been verified in the organization’s product and deployment mode. - Re-query the managed iOS population.
Collect fresh application inventory after the remediation window rather than assuming that an issued command or user notice completed the update. - Keep unresolved devices open.
Devices reporting Chrome below 150.0.7871.47, stale inventory, no version, or conflicting results should remain in the remediation queue. - Close findings with evidence.
Record the observed Chrome version and collection time. For this CVE, a version of 150.0.7871.47 or later is outside the stated affected range. - Review later authoritative changes.
Monitor Chrome, NVD, and CISA information for changes in scope, exploitation status, or remediation guidance.
An old version alone is also not evidence that cross-origin data was taken. It establishes that the application falls within the documented affected range. Incident-response escalation should be based on separate evidence of suspicious activity or compromise rather than version status alone.
Users Need a Manual App Store Update
Apple’s documented procedure for manually updating an iPhone or iPad application provides the appropriate user-facing response:- Open the App Store.
- Tap the account or profile icon at the top of the screen.
- Scroll to the available or pending application updates.
- Find Google Chrome.
- Tap Update next to Chrome.
- After installation, confirm in the App Store’s recently updated list that Chrome completed the update.
The supplied sources do not verify a Chrome for iOS menu path that reliably displays the full installed version, so users should not be directed to an unconfirmed Settings, About, or version sequence. Nor should Chrome Safety Check be presented as the verification method: the supplied record and added official update guidance do not establish that Safety Check identifies this update on iOS.
The advisory does not provide a configuration workaround equivalent to updating. User communications should therefore concentrate on completing the App Store update rather than prescribing speculative changes to Safe Browsing or unrelated browser settings.
Administrators should also avoid issuing broad cleanup instructions that are not supported by the record. The CVE does not, by itself, establish that every user of an affected version suffered data exposure. Remediation notices should distinguish a vulnerable installation from a confirmed security incident.
A concise user message can say:
That message is accurate without claiming that every recipient has been attacked.
Windows Security Teams Must Keep the Platform Boundary Intact
Windows administrators may encounter CVE-2026-13809 in dashboards that also report desktop Chrome findings. Their first task is to inspect the match: Does the affected asset actually run iOS, and does it have Chrome below 150.0.7871.47?If the answer is no, the desktop ticket should not remain open solely because Google Chrome appears in the software inventory. Detection content should be corrected so that it requires the affected operating-system condition.
If the answer is unknown because mobile application data is absent, the finding exposes an inventory problem rather than a Windows Chrome problem. The appropriate next step is to involve the team responsible for managed iOS inventory and query for
com.google.chrome.This division of responsibility should not become a handoff into silence. Windows vulnerability teams often maintain the organization’s browser-risk reporting, while mobility teams hold the relevant device data. A durable process should connect those functions so that product scope, mobile inventory, remediation evidence, and ticket closure remain consistent.
For WindowsForum readers, that is the lasting lesson from CVE-2026-13809. Accurate vulnerability management requires more than recognizing a familiar product name. It requires matching the application, platform, complete version, and contributor-supplied conditions before assigning work.
The best outcome is not the largest possible remediation campaign. It is a precise one: remove unsupported desktop findings, identify the genuinely affected mobile installations, use whatever update controls the management platform actually supports, and preserve fresh version evidence when the work is complete.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:40:03-07:00
NVD - CVE-2026-13809
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:40:03-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromeenterprise.google
SafeBrowsingEnabled: Enable Safe Browsing | Chrome Enterprise
This policy is deprecated in Google Chrome 83, please use SafeBrowsingProtectionLevel instead. Setting the policy to Enabled keeps Chrome's Safe Browsing feature on. Setting the policy to Disabled keeps Safe Browsing off. If you set this policy, users can't change it or override the "Enable...chromeenterprise.google - Related coverage: chromium.googlesource.com
- Related coverage: chromereleases.googleblog.com
Chrome Releases: Stable Channel Update for Desktop
The Chrome team is delighted to announce the promotion of Chrome 150 to the stable channel for Windows, Mac and Linux. This will roll out ov...chromereleases.googleblog.com
