Google fixed CVE-2026-13795 in Chrome for iOS 150.0.7871.47. Only Chrome for iOS versions earlier than 150.0.7871.47 are listed as affected. Windows desktop Chrome is not part of the affected NVD configuration. The required action is to update the Chrome app on affected iPhones.
The vulnerability allows a remote attacker to use crafted HTML to bypass navigation restrictions. It is not described as a memory-corruption flaw, remote code-execution vulnerability, sandbox escape, data-theft issue, or operating-system compromise. Chromium rates it High severity, while NVD and CISA-ADP assign a CVSS 3.1 base score of 6.5 Medium.
For Windows administrators, the immediate operational lesson is platform-aware vulnerability matching: do not apply this finding to Windows endpoints merely because they have a product named Google Chrome. Match the application version and operating system together, then locate and update the affected iOS installations.
The most important scope detail is that CVE-2026-13795 affects Chrome on iOS, not Chrome on every supported platform. The NVD affected configuration pairs Google Chrome with Apple’s iPhone operating system and identifies Chrome versions earlier than 150.0.7871.47 as vulnerable.
That configuration does not list Chrome on Windows. A Windows computer running Chrome should therefore not be marked affected by this CVE solely on the basis of the Chrome product name or a comparison with the iOS version threshold.
This distinction matters because a vulnerability-management process may normalize software into broad product families. If a matching rule considers only “Google Chrome” and ignores the operating-system condition, it could produce an incorrect Windows finding. That is a potential matching failure administrators should test for, not a demonstrated behavior of every scanner or inventory platform.
The same rule applies in the other direction. Checking Windows Chrome installations does not determine whether an organization’s iPhones are protected. Administrators need mobile application inventory that reports the installed Google Chrome version on managed iOS devices.
The supported scope is narrow and concrete:
That wording supports a limited technical conclusion. A restriction that Chrome for iOS was expected to enforce could be bypassed through hostile web content. The public record does not explain which navigation feature was involved, how the crafted page reached the vulnerable path, or what destination could be reached after the restriction was bypassed.
It also does not state that the attacker could:
The CVSS 3.1 vector provides a more structured description of the assessed conditions: the attack is network-accessible, has low attack complexity, requires no privileges, requires user interaction, does not change scope, has no assigned confidentiality impact, has High integrity impact, and has no assigned availability impact.
In ordinary language, an attacker can place the trigger in web content without first obtaining an account or privileged position. The assessment nevertheless requires user interaction. The public record does not specify the exact interaction, so defenders should not substitute an imagined click sequence, prompt, redirect, frame, pop-up, URL type, parser difference, or application-launch action for the missing technical details.
The High integrity impact is consistent with the stated policy-enforcement failure. The affected behavior is a navigation decision that Chrome was supposed to restrict. The scoring does not characterize the vulnerability as direct disclosure of protected information or destruction of service availability.
That makes CVE-2026-13795 a policy-integrity issue rather than a conventional memory-safety vulnerability. The operational response should remain tied to what is disclosed: update affected Chrome for iOS installations and do not claim additional attack effects that the record does not establish.
A vendor severity rating reflects the vendor’s view of a flaw within its own product and security model. CVSS applies a standardized set of metrics intended to make vulnerabilities easier to compare across products and organizations.
For this CVE, several CVSS factors limit the numerical score. User interaction is required, scope is unchanged, and the vector assigns no direct confidentiality or availability impact. The factors increasing the score are remote reachability, low attack complexity, no privilege requirement, and High integrity impact.
Chromium’s High label should not be converted into a claim of remote code execution, device takeover, or attacks in the wild. Conversely, the CVSS Medium rating should not be treated as a reason to ignore an update that repairs a security restriction.
CISA-ADP’s SSVC record lists exploitation as none as of July 1, 2026. That statement should be read only as the value recorded in the SSVC assessment on that date. It should not be generalized into a broader assertion that no exploitation evidence existed anywhere, nor does it mean that the vulnerability could not be exploited.
The same SSVC information characterizes automation as no and technical impact as partial. Those fields provide prioritization context, but they do not replace the basic remediation decision. Devices running an affected version should be updated.
Updating iOS by itself should not be used as proof that CVE-2026-13795 is fixed. The remediation threshold is an application version, so administrators need the installed Chrome version rather than only the iOS release number.
For an individual iPhone user, the update procedure is:
Organizations should instead verify compliance through managed application inventory, which can report the installed application version consistently across enrolled devices.
A practical managed-fleet workflow is:
Administrators should also distinguish among several states that can otherwise look identical in a summary dashboard:
The NVD pairing supports a clear matching rule:
This should be implemented as an operational recommendation rather than an assumption about how an unnamed scanner behaves. Administrators can test their own tools by reviewing the evidence attached to a detection and asking four questions:
False positives can consume analyst time and make remediation reporting less reliable. More importantly, a desktop-centered review can miss the actual affected assets if the organization does not inventory third-party applications on managed iPhones.
The corrective action is not a permanent exception labeled “Chrome CVE not applicable.” It is a platform-sensitive rule that retains the finding for qualifying iPhones while excluding nonmatching Windows systems.
The available material does not disclose the full policy source, protected destination, internal component sequence, or exact attack procedure. It therefore does not support detailed claims about server-side state, external protocols, application handlers, authentication transitions, or particular deployment controls.
Administrators do not need those undisclosed details to patch correctly. The application-and-version boundary is sufficient to identify affected devices and validate remediation.
The public description does not define that interaction. It would be speculative to describe a particular tap, confirmation, prompt, page sequence, or social-engineering message as part of the exploit. The defensible statement is simply that exploitation requires interaction with attacker-controlled or crafted HTML content.
That requirement can inform remediation tempo. CVE-2026-13795 is not described as a no-interaction device compromise, and the SSVC assessment does not characterize it as automatable. Organizations can use those facts alongside device exposure, update availability, and normal mobile patching policies.
They should not, however, use user interaction as a reason to leave an affected version installed indefinitely. Interaction with web content is an ordinary browser activity, and the fixed version is available. The proportionate response is to move affected iPhones to the corrected release and verify the result through application inventory.
Defenders should avoid asserting that the flaw affected:
The supported conclusion is narrower: on affected Chrome for iOS versions, crafted HTML could bypass navigation restrictions. The update restores the relevant enforcement in version 150.0.7871.47.
Maintaining that boundary between disclosed facts and plausible interpretation helps administrators communicate accurately. It also prevents a mobile application update from being misrepresented as a confirmed bypass of unrelated management, safety, operating-system, or identity controls.
NVD publication and enrichment: NVD published and enriched the entry with a CVSS 3.1 score of 6.5 Medium and a configuration pairing Google Chrome with Apple’s iPhone operating system. That pairing supplies the key rule for excluding Windows desktop systems.
CISA-ADP enrichment: CISA-ADP added the same CVSS 3.1 vector, CWE-602, and SSVC prioritization fields.
July 1, 2026 SSVC status: CISA-ADP’s SSVC record lists exploitation as none, automatable as no, and technical impact as partial as of July 1, 2026.
The sequence explains why a vulnerability feed may initially contain less context than the later enriched record. Organizations should refresh imported CVE data so that platform conditions and version ranges added during enrichment become part of their matching rules.
The timeline does not change the remediation threshold. Regardless of when each enrichment field entered a downstream system, Chrome for iOS versions earlier than 150.0.7871.47 are the affected installations identified in the material.
For Windows administrators, the valuable lesson is not that Windows Chrome needs an emergency response. It is that modern software names cross operating-system boundaries, while individual vulnerabilities may not. Reliable vulnerability management must match the product, version, and platform together.
Use the complete NVD configuration to avoid Windows false positives, query managed iPhones for the installed Chrome version, deploy the update through the established mobile application channel, and verify compliance after device check-in. That approach keeps remediation focused on the devices actually within the affected range without minimizing the importance of the security fix.
The vulnerability allows a remote attacker to use crafted HTML to bypass navigation restrictions. It is not described as a memory-corruption flaw, remote code-execution vulnerability, sandbox escape, data-theft issue, or operating-system compromise. Chromium rates it High severity, while NVD and CISA-ADP assign a CVSS 3.1 base score of 6.5 Medium.
For Windows administrators, the immediate operational lesson is platform-aware vulnerability matching: do not apply this finding to Windows endpoints merely because they have a product named Google Chrome. Match the application version and operating system together, then locate and update the affected iOS installations.
A Mobile-Only Flaw Hiding Behind the Chrome Name
The most important scope detail is that CVE-2026-13795 affects Chrome on iOS, not Chrome on every supported platform. The NVD affected configuration pairs Google Chrome with Apple’s iPhone operating system and identifies Chrome versions earlier than 150.0.7871.47 as vulnerable.That configuration does not list Chrome on Windows. A Windows computer running Chrome should therefore not be marked affected by this CVE solely on the basis of the Chrome product name or a comparison with the iOS version threshold.
This distinction matters because a vulnerability-management process may normalize software into broad product families. If a matching rule considers only “Google Chrome” and ignores the operating-system condition, it could produce an incorrect Windows finding. That is a potential matching failure administrators should test for, not a demonstrated behavior of every scanner or inventory platform.
The same rule applies in the other direction. Checking Windows Chrome installations does not determine whether an organization’s iPhones are protected. Administrators need mobile application inventory that reports the installed Google Chrome version on managed iOS devices.
The supported scope is narrow and concrete:
- Affected product: Google Chrome for iOS
- Affected versions: Earlier than 150.0.7871.47
- Remediation floor: 150.0.7871.47
- Required action: Update the Chrome app on iPhones
- Windows desktop Chrome: Not included in the NVD affected configuration
The Boundary That Failed Was Navigation, Not Memory Safety
Google’s description is concise: insufficient policy enforcement allowed a remote attacker to bypass navigation restrictions using a crafted HTML page.That wording supports a limited technical conclusion. A restriction that Chrome for iOS was expected to enforce could be bypassed through hostile web content. The public record does not explain which navigation feature was involved, how the crafted page reached the vulnerable path, or what destination could be reached after the restriction was bypassed.
It also does not state that the attacker could:
- Execute arbitrary code
- Escape the browser sandbox
- Read passwords, cookies, or protected files
- Install software
- Compromise iOS
- Crash the device or make Chrome unavailable
- Obtain control of another application
The CVSS 3.1 vector provides a more structured description of the assessed conditions: the attack is network-accessible, has low attack complexity, requires no privileges, requires user interaction, does not change scope, has no assigned confidentiality impact, has High integrity impact, and has no assigned availability impact.
In ordinary language, an attacker can place the trigger in web content without first obtaining an account or privileged position. The assessment nevertheless requires user interaction. The public record does not specify the exact interaction, so defenders should not substitute an imagined click sequence, prompt, redirect, frame, pop-up, URL type, parser difference, or application-launch action for the missing technical details.
The High integrity impact is consistent with the stated policy-enforcement failure. The affected behavior is a navigation decision that Chrome was supposed to restrict. The scoring does not characterize the vulnerability as direct disclosure of protected information or destruction of service availability.
That makes CVE-2026-13795 a policy-integrity issue rather than a conventional memory-safety vulnerability. The operational response should remain tied to what is disclosed: update affected Chrome for iOS installations and do not claim additional attack effects that the record does not establish.
“High” and 6.5 Medium Are Not a Contradiction
Chromium rates CVE-2026-13795 High, while NVD and CISA-ADP calculate a CVSS 3.1 base score of 6.5 Medium. The two labels can coexist because they come from different assessment systems.A vendor severity rating reflects the vendor’s view of a flaw within its own product and security model. CVSS applies a standardized set of metrics intended to make vulnerabilities easier to compare across products and organizations.
For this CVE, several CVSS factors limit the numerical score. User interaction is required, scope is unchanged, and the vector assigns no direct confidentiality or availability impact. The factors increasing the score are remote reachability, low attack complexity, no privilege requirement, and High integrity impact.
Chromium’s High label should not be converted into a claim of remote code execution, device takeover, or attacks in the wild. Conversely, the CVSS Medium rating should not be treated as a reason to ignore an update that repairs a security restriction.
CISA-ADP’s SSVC record lists exploitation as none as of July 1, 2026. That statement should be read only as the value recorded in the SSVC assessment on that date. It should not be generalized into a broader assertion that no exploitation evidence existed anywhere, nor does it mean that the vulnerability could not be exploited.
The same SSVC information characterizes automation as no and technical impact as partial. Those fields provide prioritization context, but they do not replace the basic remediation decision. Devices running an affected version should be updated.
Application Version Determines Remediation
The NVD configuration expresses the affected range as Chrome versions earlier than 150.0.7871.47 when paired with Apple’s iPhone operating system. The practical interpretation is straightforward:| Chrome for iOS state | Version range | CVE status | Required action |
|---|---|---|---|
| Older installation | Earlier than 150.0.7871.47 | Affected | Update Chrome through the App Store or the organization’s managed application channel |
| Remediation floor | 150.0.7871.47 | Outside the affected range | No further action for this CVE after inventory confirms the version |
| Newer installation | Later than 150.0.7871.47 | Outside the affected range | Retain normal update enforcement and inventory checks |
| Chrome on Windows | Any version | Not in the listed affected configuration | Do not assign this CVE based solely on the Chrome product name |
For an individual iPhone user, the update procedure is:
- Open the App Store.
- Tap the profile icon.
- Review Available Updates.
- Find Chrome.
- Tap Update.
Organizations should instead verify compliance through managed application inventory, which can report the installed application version consistently across enrolled devices.
Concrete Actions for Managed iPhone Fleets
Administrators should treat this as a mobile application version-control task rather than a general desktop Chrome emergency.A practical managed-fleet workflow is:
- Query managed iOS devices for the installed Google Chrome application version.
- Flag every Chrome installation reporting a version earlier than 150.0.7871.47.
- Require or deploy the current Chrome release through the organization’s MDM or managed App Store deployment channel.
- Allow devices to check in and process the application update.
- Re-query the managed iOS inventory after device check-in.
- Confirm that previously flagged devices now report 150.0.7871.47 or later.
- Investigate devices that remain below the threshold, have not recently checked in, or no longer return application inventory.
- Close the finding only after the application version is verified, not merely after an update command is issued.
Administrators should also distinguish among several states that can otherwise look identical in a summary dashboard:
- An affected device that has not received the update
- A device that received an update command but has not checked in
- A device that checked in but failed to install the update
- A device that no longer has Chrome installed
- A device with missing or stale application inventory
- A compliant device running 150.0.7871.47 or later
- A Windows endpoint incorrectly associated with the iOS-only configuration
Platform-Aware Matching Prevents Windows False Positives
For WindowsForum readers, CVE-2026-13795 is a useful example of why vulnerability matching must include the complete affected configuration.The NVD pairing supports a clear matching rule:
A Windows endpoint fails the operating-system condition and should not match. An iPhone without Chrome also fails the application condition. An iPhone running Chrome 150.0.7871.47 or later fails the vulnerable-version condition.
This should be implemented as an operational recommendation rather than an assumption about how an unnamed scanner behaves. Administrators can test their own tools by reviewing the evidence attached to a detection and asking four questions:
- Did the tool identify the endpoint as an iPhone or as a Windows computer?
- Did it identify the installed Chrome application rather than only a generic Chrome product family?
- Did it collect an exact Chrome version?
- Did its vulnerability rule require both the iOS platform and a version below 150.0.7871.47?
False positives can consume analyst time and make remediation reporting less reliable. More importantly, a desktop-centered review can miss the actual affected assets if the organization does not inventory third-party applications on managed iPhones.
The corrective action is not a permanent exception labeled “Chrome CVE not applicable.” It is a platform-sensitive rule that retains the finding for qualifying iPhones while excluding nonmatching Windows systems.
The NVD Record Is Precise Where Administrators Need It Most
The NVD material provides the core facts required for remediation:- The affected application is Google Chrome.
- The affected platform condition is Apple’s iPhone operating system.
- Versions earlier than 150.0.7871.47 are vulnerable.
- The vulnerability can be reached remotely through crafted HTML.
- User interaction is required.
- The assessed impact is concentrated in integrity.
- NVD and CISA-ADP assign CVSS 3.1 scores of 6.5 Medium.
- Chromium assigns a vendor severity of High.
- CISA-ADP’s SSVC record lists exploitation as none as of July 1, 2026.
The available material does not disclose the full policy source, protected destination, internal component sequence, or exact attack procedure. It therefore does not support detailed claims about server-side state, external protocols, application handlers, authentication transitions, or particular deployment controls.
Administrators do not need those undisclosed details to patch correctly. The application-and-version boundary is sufficient to identify affected devices and validate remediation.
User Interaction Affects Priority, Not Applicability
The CVSS vector requires user interaction. This separates the flaw from vulnerabilities assessed as exploitable without any action by a user.The public description does not define that interaction. It would be speculative to describe a particular tap, confirmation, prompt, page sequence, or social-engineering message as part of the exploit. The defensible statement is simply that exploitation requires interaction with attacker-controlled or crafted HTML content.
That requirement can inform remediation tempo. CVE-2026-13795 is not described as a no-interaction device compromise, and the SSVC assessment does not characterize it as automatable. Organizations can use those facts alongside device exposure, update availability, and normal mobile patching policies.
They should not, however, use user interaction as a reason to leave an affected version installed indefinitely. Interaction with web content is an ordinary browser activity, and the fixed version is available. The proportionate response is to move affected iPhones to the corrected release and verify the result through application inventory.
Avoid Expanding the CVE Beyond Its Disclosed Scope
Security advisories often create pressure to explain precisely how a bug works even when the technical issue remains restricted. In this case, the available description does not support a reconstructed attack chain.Defenders should avoid asserting that the flaw affected:
- Kiosk systems
- Parental controls
- Application allow-listing
- Supervised browsing
- Managed workflows
- Authentication flows
- A specific external-application launch
- Special URL destinations or schemes
- Frames, pop-ups, or redirects
- Encoded or alternate URL forms
- Different parsers
- Particular application-controlled actions
The supported conclusion is narrower: on affected Chrome for iOS versions, crafted HTML could bypass navigation restrictions. The update restores the relevant enforcement in version 150.0.7871.47.
Maintaining that boundary between disclosed facts and plausible interpretation helps administrators communicate accurately. It also prevents a mobile application update from being misrepresented as a confirmed bypass of unrelated management, safety, operating-system, or identity controls.
Disclosure and Enrichment Timeline
The public record developed in stages, with the Chrome-authored information establishing the affected product and fixed version before NVD and CISA-ADP added standardized configuration, scoring, weakness, and prioritization data.Timeline
Chrome record: The Chrome-authored CVE information identified Google Chrome for iOS versions earlier than 150.0.7871.47 as affected and assigned Chromium severity High.NVD publication and enrichment: NVD published and enriched the entry with a CVSS 3.1 score of 6.5 Medium and a configuration pairing Google Chrome with Apple’s iPhone operating system. That pairing supplies the key rule for excluding Windows desktop systems.
CISA-ADP enrichment: CISA-ADP added the same CVSS 3.1 vector, CWE-602, and SSVC prioritization fields.
July 1, 2026 SSVC status: CISA-ADP’s SSVC record lists exploitation as none, automatable as no, and technical impact as partial as of July 1, 2026.
The sequence explains why a vulnerability feed may initially contain less context than the later enriched record. Organizations should refresh imported CVE data so that platform conditions and version ranges added during enrichment become part of their matching rules.
The timeline does not change the remediation threshold. Regardless of when each enrichment field entered a downstream system, Chrome for iOS versions earlier than 150.0.7871.47 are the affected installations identified in the material.
Administrator Checklist
Scope and matching
- [ ] Confirm that the finding is attached to an iPhone, not a Windows endpoint.
- [ ] Confirm that Google Chrome is installed on the device.
- [ ] Collect the exact installed Chrome application version.
- [ ] Mark versions earlier than 150.0.7871.47 as affected.
- [ ] Exclude Chrome 150.0.7871.47 and later from the affected range.
- [ ] Review any Windows detection for incomplete platform matching.
- [ ] Do not infer that Safari, WebKit generally, Android Chrome, or desktop Chrome is affected.
Deployment
- [ ] Require or deploy the current Chrome release through the organization’s MDM or managed App Store channel.
- [ ] Allow devices to check in and receive the application update.
- [ ] Re-query application inventory after check-in.
- [ ] Confirm that every remediated device reports 150.0.7871.47 or later.
- [ ] Follow up on stale, offline, unenrolled, or nonreporting devices.
- [ ] Do not close the finding solely because an update command was sent.
User action
- [ ] Tell individual users to open the App Store.
- [ ] Tell them to tap the profile icon.
- [ ] Direct them to Available Updates.
- [ ] Have them locate Chrome and tap Update.
- [ ] Avoid publishing an unverified Chrome in-app version-check path.
Communications
- [ ] Describe the flaw as a crafted-HTML bypass of navigation restrictions.
- [ ] State that user interaction is required.
- [ ] State that Chromium rates it High and CVSS 3.1 rates it 6.5 Medium.
- [ ] State precisely that CISA-ADP’s SSVC record lists exploitation as none as of July 1, 2026.
- [ ] Do not broaden that SSVC field into a claim about all public exploitation evidence.
- [ ] Do not describe the issue as code execution, sandbox escape, data theft, or iOS compromise.
- [ ] Do not identify speculative deployment scenarios or attack mechanisms as confirmed.
The WindowsForum Takeaway
CVE-2026-13795 is operationally straightforward once its platform and version conditions are preserved. It affects Chrome for iOS versions earlier than 150.0.7871.47, and the fix is to update the iOS Chrome application.For Windows administrators, the valuable lesson is not that Windows Chrome needs an emergency response. It is that modern software names cross operating-system boundaries, while individual vulnerabilities may not. Reliable vulnerability management must match the product, version, and platform together.
Use the complete NVD configuration to avoid Windows false positives, query managed iPhones for the installed Chrome version, deploy the update through the established mobile application channel, and verify compliance after device check-in. That approach keeps remediation focused on the devices actually within the affected range without minimizing the importance of the security fix.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:59-07:00
NVD - CVE-2026-13795
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:59-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: chromium.googlesource.com
- Related coverage: chromereleases.googleblog.com
Chrome Releases: Chrome Stable for iOS Update
Hi everyone! We've just released Chrome Stable 150 (150.0.7871.34) for iOS; it'll become available on App Store in the next few hours. This ...chromereleases.googleblog.com
- Related coverage: security.snyk.io
CVE-2026-13795 in chromium | CVE-2026-13795 | Snyk
CVE-2026-13795 in chromium | CVE-2026-13795security.snyk.io - Related coverage: cvefeed.io
CVE-2026-13795 - Google Chrome iOS Navigation Restriction Bypass
Insufficient policy enforcement in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: High)cvefeed.io
- Related coverage: issues.chromium.org
Chromium
issues.chromium.org
- Related coverage: developer.chrome.com
Debugging websites in Chrome on iOS 16.4+ | Blog | Chrome for Developers
Learn how to use Safari Web Inspector debugging for Chrome on iOS.
developer.chrome.com
