Intro

A severe local credential security flaw has emerged in Google Chrome for macOS. Discovered by Cisco Talos, this vulnerability allows a malicious process running with the same user privileges to silently overwrite Chrome’s encryption keys stored within the system keychain. This write access breaks the cryptographic foundation safeguarding stored credentials, session tokens, and financial data without requiring elevated root permissions or generating additional user authentication prompts.

CVE Context

– Products & versions affected: Google Chrome version 148.0.7778.216 on Mac arm64 architectures.
– Disclosure timeline: Initial vendor contact occurred on June 15, 2026. Vendor disclosure proceeded on June 15, 2026, followed immediately by public release on June 16, 2026.
– Attack vector, auth level, impact: Local attack vector requiring low-privileged user account access. No user interaction is needed. The flaw compromises confidentiality and integrity by letting unprivileged local software swap out the master cryptographic secret used for user profile encryption.

CVSS Metric Breakdown (v3.1) - CVE-2026-6312 (Chrome Safe Storage ACL Overwrite)
Attack Vector (AV): L
Attack Complexity (AC): L
Privileges Required (PR): L
User Interaction (UI): N
Confidentiality Impact (VC): L
Integrity Impact (VI): L
Availability Impact (VA): L
Scope Changed (SC): U
Safety Impact (SI): N
Automation (SA): N
Exploit Maturity: P
Base Score: 5.3 (Medium)

– Exploit tools, payloads observed, confirmed victims, global exposure count if known: Custom macOS Objective-C/Swift binaries or scripts making direct SecItemAdd API calls targeting specific service definitions. No global exploitation metrics or in-the-wild campaigns have been formally reported yet, but standard local execution scripts can trivially automate the payload injection.

EPSS Scoring

EPSS Probability: 0.00219
EPSS Percentile: 0.12212

The Exploit Prediction Scoring System (EPSS) rating estimates the likelihood of a vulnerability being exploited within the next 30 days. A probability score of 0.00219 indicates a relatively low immediate threat coefficient in generalized wild scanning, while the percentile score of 0.12212 means this vulnerability ranks above roughly 12% of all tracked vulnerabilities in terms of observed exploit weaponization characteristics. This profile is typical for local exploit primitives requiring pre-existing endpoint access.

Exploitation Detail

– Step-by-step breakdown: Chrome creates its secure storage credential by invoking its AddGenericPassword wrapper. When generating the initial entry via SecItemAdd, it configures standard parameters but omits explicit access control entries like kSecAttrAccess or kSecAttrAccessControl. The operating system assigns a default Access Control List (ACL). Under default macOS keychain policies, entry 0 governs the ‘encrypt’ authorization and defaults to an unrestricted application attribute array. This allows any process executing under the same UID to call SecItemAdd or SecItemUpdate and push an arbitrary 24-character base64-encoded password value directly into the “Chrome Safe Storage” service record, replacing the legitimate keying material.
– Where it lives: It lives inside the crypto/apple/keychain_v2.mm component logic during its initialization and update routines.

// Conceptual representation of a malicious payload overwriting the target service parameters
NSMutableDictionary *attributes = [[NSMutableDictionary alloc] init];
[attributes setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
[attributes setObject:@"Chrome Safe Storage" forKey:(id)kSecAttrService];
[attributes setObject:@"Chrome" forKey:(id)kSecAttrAccount];
[attributes setObject:[@"ATTACKER_CONTROLLED_BASE64_KEY_DATA==" dataUsingEncoding:NSUTF8StringEncoding] forKey:(id)kSecValueData];
OSStatus status = SecItemAdd((CFDictionaryRef)attributes, NULL);
if (status == errSecDuplicateItem) {
    NSMutableDictionary *query = [[NSMutableDictionary alloc] init];
    [query setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
    [query setObject:@"Chrome Safe Storage" forKey:(id)kSecAttrService];
    NSMutableDictionary *changes = [[NSMutableDictionary alloc] init];
    [changes setObject:[@"ATTACKER_CONTROLLED_BASE64_KEY_DATA==" dataUsingEncoding:NSUTF8StringEncoding] forKey:(id)kSecValueData];
    status = SecItemUpdate((CFDictionaryRef)query, (CFDictionaryRef)changes);
}

Attacker Behavior Snapshot

– What the attacker sends: A local execution script or binary compiled for macOS that makes raw Apple Security Framework API calls targeting the kSecClassGenericPassword class, specifying service “Chrome Safe Storage” and account “Chrome”.
– What the system does: The macOS Keychain Services API checks the existing ACL rules. Because the default ‘encrypt’ authorization rule permits unrestricted modification access from identical user context processes, the keychain updates the stored value with the attacker’s string without prompting the user for verification or passwords.
– What leaks back: On the next execution loop, Chrome reads this manipulated 16-byte base64 string, derives a 128-bit AES key via PBKDF2-HMAC-SHA1, and encrypts all newly saved data. The local attacker can now pull down and cleanly decrypt local application databases including Login Data, Cookies, and Web Data offline using their pre-positioned key configuration.

Why This Matters

This vulnerability highlights how legacy configurations become high-value targets. By trusting underlying platform defaults during API integration rather than enforcing strict explicit security controls, applications inadvertently inherit permissive configuration profiles. This creates a silent, reliable path for persistent credential harvesting within user space environments.

Exploitation results in:

• Full compromise of local credential storage and web browser password vaults
• Hijacking of active web sessions via exposed authentication tokens and tracking cookies
• Exfiltration of personal data, financial profiles, and cloud infrastructure API access keys

MITRE ATT&CK Mapping

Initial Access: T1190 – Exploit Public-Facing Application
Execution: T1059.003 – Command Shell
Persistence: T1505.003 – Server Software Component

Detection Rules

YARA Rule (Memory/Doc/PCAP)

rule MacOS_Chrome_Keychain_Overwrite_Hunting {
    meta:
        description = "Detects compiled strings and dictionary attributes typical of an exploit payload targeting the Chrome Safe Storage keychain entry."
        author = "Cyber Pulse Threat Research"
        date = "2026-06-24"
    strings:
        $service = "Chrome Safe Storage" ascii wide
        $account = "Chrome" ascii wide
        $ksec_class = "kSecClassGenericPassword" ascii
        $ksec_value = "kSecValueData" ascii
    condition:
        all of them
}

Suricata or Zeek (Network)

# Since this is a strictly local endpoint privilege execution flaw, traditional network signatures do not catch the exploit API calls. Monitor endpoint logs for suspicious outbound sync behavior.
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"EXPLOIT Local Host Exfiltration Activity Detected"; content:"Login Data"; nocase; sid:10002444; rev:1;)

Sigma Rule (SIEM/EDR)

title: Malicious Access or Update to Chrome Keychain Service
id: a7781b2e-0a56-4c74-8b6b-19d9b62a6312
status: experimental
description: Detects unexpected local processes invoking keychain utilities or writing modifications directly matching Chrome's unique Safe Storage parameters.
author: Cyber Pulse Threat Research
logsource:
    product: macos
    service: endpoint
detection:
    selection_process:
        Image|endswith:
            - '/security'
            - '/osascript'
    selection_args:
        CommandLine|contains:
            - 'Chrome Safe Storage'
    filter_chrome:
        Image|startswith: '/Applications/Google Chrome.app/'
    condition: (selection_process and selection_args) and not filter_chrome
falsepositives:
    - Manual administrative backup or specialized migration assistants executed by the user.
severity: medium

Detection Strategies

Network Detection:

• Monitor for anomalous outbound file transfers originating from user profiles towards unknown external cloud hosting providers.
• Detect unusual browser syncing or credential sync web traffic behaviors inconsistent with normal operations.
• Flag rapid, unexpected sessions or logins from multiple geographical coordinates using session cookies harvested from local machines.

Endpoint Detection:

• Monitor third-party binaries or native scripts querying or altering the macOS Keychain Services API for the specific ‘Chrome Safe Storage’ string identifier.
• Audit process hierarchy profiles to ensure no unauthorized sub-processes or unknown background daemons are querying local SQLite configuration stores.
• Look for unauthorized read attempts directed at internal profile folders located within the ~/Library/Application Support/Google/Chrome/ paths.

Splunk Query

index=security sourcetype=macos_secure (CommandLine="*Chrome Safe Storage*" OR process_name="security") 
| search NOT (process_path="/Applications/Google Chrome.app/*")
| stats count by host, user, process_name, CommandLine, process_path

SOC Detection Strategy

– Triage levels, log sources, alert logic: Treat any non-Chrome binary interacting directly with the “Chrome Safe Storage” service entry as a High-priority security incident. Collect process auditing data from endpoint tools alongside historical macOS execution events.
– How to tune and escalate: Filter out official application update hooks and internal Google updater utilities. Escalate immediately to the incident response tier if unexpected terminal interactions, un-signed tools, or administrative scripting paths are found accessing credential structures.
– What real-world alerts might look like: “Security Alert: Non-Standard Application Read/Write Action Detected targeting Chrome Safe Storage Attributes on Asset: MAC-WKSTN-04.”

Tools & Techniques

Tool | Usage
Sysmon | Detect parent-child anomalies
Velociraptor | Endpoint hunting for shell commands
Zeek | HTTP signature logging and anomaly detection
Sigma/YARA | Create detection rules for known web shell patterns

Mitigation & Response

– Patch info: Google explicitly states that this model does not violate its security posture assumptions because local malware execution already implies an underlying operating system user profile compromise. Users must ensure their browser profiles are continuously updated to the latest versions.
– Temporary mitigations (GPOs, ACLs, WAF): Apply Mobile Device Management (MDM) profile policies to lockdown runtime binary verification checks and enforce strict execution whitelisting on software applications.
– Config changes, credential rotation, MFA enforcement, registry edits: Enforce hardware token Multi-Factor Authentication across enterprise portals. If an endpoint compromise is suspected, administrators should trigger an immediate user session revocation, wipe local application cache storage files, and rotate all user secrets recorded within browser databases.

Incident Response Snippets

– Log queries (grep, Splunk, KQL): Run a swift local search across console structures to track potential keychain update histories via terminal tools:

log show --predicate 'eventMessage CONTAINS "Chrome Safe Storage"' --style syslog

– IR questions to ask: Did an unverified script execute within the user space context before the browser storage database changed? Are there secondary indicators of persistence on the workstation?
– Cleanup and movement checks: Clear out compromised local profiles, reset underlying user keychain configurations, and trace all internal host pathways to isolate and eliminate the source file that executed the local attack.

Suggested Reading & External References

– Official advisories: Chromium Security FAQ Document
– Trusted writeups: Cisco Talos Intelligence Group Vulnerability Reports

Final Thoughts

– One-sentence summary of exploit path: Unrestricted default ACL parameters on Chrome’s secure keychain service entries enable local applications to overwrite encryption keys silently and decrypt local user data vaults offline.
– Most effective action to take now: Mandate the deployment of strictly enforced application blocklists and hardware-backed multi-factor authentication policies to nullify stolen session tokens.
– Reminder that detection is field work.

Published: June 24, 2026