CVE-2026-35467

Executive Summary

CVE-2026-35467 is a client-side cryptographic credential disclosure vulnerability affecting a product attributed to certcc, an unknown vendor/application. The CNA reports that API keys stored in the browser's IndexedDB are not flagged as non-extractable, allowing a malicious JavaScript context to retrieve these encryption credentials. The vulnerability has a CVSS score of 7.5 (High severity) despite the lack of detailed vector data, and the attack surface is exclusively the end-user's browser session. There is currently no Known Exploited Vulnerability (KEV) status from CISA, no public proof-of-concept, and no exploit code available, but the vulnerability class — extractable cryptographic keys in browser storage — is a well-understood attack vector that requires the victim to already run untrusted code in the same origin.

Technical Analysis

The flaw described in CVE-2026-35467 pertains to browser client-side storage, specifically the IndexedDB API. The NVD description states that "the stored API keys in temporary browser client is not marked as protected allowing for JavaScript console or other errors to allow for extraction of the encryption credentials." This maps directly to the Web Crypto API concept of extractable versus non-extractable keys. When a CryptoKey object is created with extractable: true, or when cryptographic material is stored as plaintext in IndexedDB rather than as a wrapped, non-extractable CryptoKey, any JavaScript executing in the same origin — including injected scripts, malicious browser extensions, or XSS payloads — can read and exfiltrate those keys.

The technical vulnerability class here is client-side cryptographic key mismanagement rather than a traditional network-exploitable flaw. At the mechanism level:

1. The application generates or stores API keys associated with temporary client encryption.
2. The storage object (in IndexedDB, which may be used as a backing store for Web Crypto or for direct plaintext keys) is created without the protected flag.
3. Because the keys are extractable or stored in plaintext, the browser's same-origin security model provides no additional protection once script execution is achieved in that origin.

The attack does not require a network-level exploit or malformed request. Rather, it is a post-compromise data-at-rest disclosure issue that turns an existing script-execution primitive (XSS, malicious extension, or open browser console — the latter requiring user interaction) into cryptographic key theft. The description also references "JavaScript console or other errors" as exposure surfaces, meaning an error message or dev-tools introspection could reveal the credentials.

Insufficient technical detail is available regarding the specific product name, the exact API implementation, or the precise key names. The CNA title and NVD description only provide the storage mechanism (IndexedDB) and the consequence (extraction of encryption credentials). The affected vendor is listed as certcc with no expanded product name, and the affected versions list is empty.

Exploitation Scenarios

No public PoC or exploit code is available; the following attack chain is inferred from the vulnerability class (extractable client-side keys in browser storage) and the strict contents of the NVD description.

Attack Scenario 1 — Cross-Site Scripting (XSS) to Key Exfiltration:

1. Reconnaissance / Target Identification: The attacker identifies a site using the vulnerable certcc component that establishes temporary client-side API keys (potentially used for session encryption between browser and server). The target is a user with an active session on that site.
2. Flaw Class Trigger: The attacker first needs a way to execute JavaScript in the target origin — for example, a stored XSS issue, a compromised third-party script loaded in the page, or a malicious browser extension with permission to that origin. Because the API keys are stored as extractable in IndexedDB, no Web Crypto non-extractable boundary protects them.
3. Payload / Execution Method: The attacker executes JavaScript (via console, injected script, or extension) that opens the indexedDB storage, enumerates object stores, and reads the record(s) containing the API keys / encryption credentials. The browser exposes these values directly to script because they were not marked as protected.
4. Post-Exploitation Impact: With the API keys in hand, the attacker makes authenticated API calls on the victim's behalf — reading sensitive data the cryptography was supposed to protect, potentially decrypting previously captured ciphertext if the key is symmetric or has a corresponding use, or hijacking the user's account/workspace.

Attack Scenario 2 — Local Console / Error Disclosure:

1. The victim (or an attacker with physical or remote access to the unlocked browser) opens the developer console.
2. Due to the non-protected flag, console errors, debug logs, or direct inspection of stored objects reveals the encryption credentials.
3. The attacker captures the keys and uses them offline to decrypt traffic or stored payloads associated with the temporary browser client.

Given the reliance on CSP (Content Security Policy) violations, browser extension permissions, or the user's own console, the exploitation scenario is fundamentally a client-side supply-chain / misconfiguration attack, not a remote unauthenticated network attack. The CVSS score of 7.5 is plausible if the component integrates with sensitive data and the attacker can combine it with common web weaknesses; the missing CVSS vector data prevents precise subscore attribution.

Impact Assessment

• Business Impact: High for organizations whose web applications rely on this certcc component to handle temporary client-side encryption of sensitive data, API interactions, or user workflows. If the component is used in regulated sectors (healthcare, finance), the exposure of encryption credentials could constitute a reportable breach of confidentiality controls.
• Affected Systems: The client-side attack surface — browsers running the certcc application code. No server-side component appears directly exposed, but the trust boundary is broken because the server assumed client-side cryptographic protection for what is effectively plaintext-in-browser-storage data.
• Blast Radius: The immediate breach is limited to one user's session at a time, because IndexedDB storage is origin-scoped and per-browser-profile (no cross-user or cross-tenant leakage). However, a widespread XSS campaign or a popular malicious extension could scale the attack to all concurrent users, yielding broad account compromise and decryption of data-in-transit if the intercepted traffic relied on those client-generated keys.
• Availability/Integrity: CVSS 7.5 places the issue in the High severity band, implying significant confidentiality impact. Without a vector string, it is not possible to state precise subscore values, so this report refrains from fabricating AV/AC/PR/UI derived metrics.

Detection Guidance

The detection challenge for CVE-2026-35467 is distinct from network-exploitable flaws because the vulnerability manifests as JavaScript executing in the browser and reading IndexedDB. Network- and host-based detection is weaker than for server-side vulnerabilities. The practical detection avenues are: (a) monitoring for anomalous client-side script behavior via session replay / client telemetry, (b) identifying injected origins or unexpected domains receiving outbound requests containing credentials, (c) logging console errors that leak credential material.

Sigma Rule

The following Sigma rule targets client-side telemetry / browser logs producing evidence of scripts accessing IndexedDB and immediately performing outbound HTTP requests — an indicator of credential exfiltration from browser storage.

title: Suspicious IndexedDB Key Access Followed by Outbound Exfiltration
id: e4f9c1a2-3b5d-4e6f-8a9b-0c1d2e3f4a56
status: experimental
description: Detects client-side telemetry (e.g., browser log, EDR with browser module) where a script opens an IndexedDB database for key storage and performs an outbound web request with API-key-like content within a short window, indicative of extractable-key theft (CVE-2026-35467).
logsource:
    category: browser_extension
    product: chrome_or_firefox_storage
detection:
    selection_key_access:
        EventID: 4662
        Operation: 'indexedDB_open'  # adjust per actual telemetry provider
        ObjectName: '*key*'
    selection_exfil:
        EventID: 5156
        ApplicationName: '*chrome*'
        DestinationPort: 80 OR 443
    condition: selection_key_access AND selection_exfil
    timeframe: 1m
falsepositives:
    - Legitimate web apps that store API keys client-side for config purposes
    - Browser sync operations
level: high
fields:
    - DestinationIp
    - SourceIp
    - ObjectName
tags:
    - attack.t1555.005
    - cve.2026.35467

YARA Rule

The YARA rule below targets JavaScript payloads or snippets that attempt to programmatically enumerate IndexedDB object stores, iterate records, and exfiltrate content. It is best suited for scanning cached script files (CSP reports, service-worker caches) or injected script content captured by EDR/next-gen AV. This rule is experimental because the code patterns are generic across web applications.

rule CVE_2026_35467_IndexedDB_Key_Theft
{
    meta:
        author = "valtersit Threat Intel"
        description = "Detects JavaScript that pattern-matches enumeration of IndexedDB stores and transmission of resulting keys (CVE-2026-35467 extractable API key disclosure)"
        cve = "CVE-2026-35467"
        date = "2026-01-01"
        severity = "high"
        reference = "CNA: Private Key stored as extractable in browser IndexedDB"

    strings:
        $idx_db = "indexedDB" ascii nocase
        $open_db = "open(" ascii
        $obj_store = "objectStore(" ascii
        $get_all = "getAll(" ascii  // reading all records
        $iterate = "onsuccess" ascii
        $cursor = "openCursor" ascii
        $web_api = "CryptoKey" ascii
        $extractable = "extractable" ascii
        $fetch_out = "fetch(" ascii
        $xhr_open = "XMLHttpRequest" ascii

    condition:
        // must reference IndexedDB + open operation + access to keys plus outbound transmission
        uint16(0) == 0x0A0D or uint16(0) == 0x0D0A  // ASCII text file for HTML/JS
        and $idx_db and $open_db and ($get_all or $cursor)
        and ($fetch_out or $xhr_open)
        and #extractable >= 1  // marker of non-protected key operation
        and filesize < 2MB
}

Suricata IDS Rule

Suricata cannot decode JavaScript semantics (IndexedDB is a browser-internal API, not a wire protocol). However, an effective detection vector is the HTTP response containing script and the subsequent client-initiated TLS/HTTP transmission payload carrying credential-like output — modeled below as a content-match on GET/POST that appears initiated from a page that previously loaded vulnerable code. Since Suricata cannot inspect encrypted HTTPS payloads, this rule is best paired with TLS-decryption/mitm or placed in front of plain HTTP deployments. The rule is intentionally broad; treat alerts as indicators requiring correlation.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2026-35467 - Potential Client-Side IndexedDB Key Exfil POST"; flow:to_server,established; content:"POST"; http_method; content:"/api/"; http_uri; pcre:"/(key|token|credential|apikey|secret)/i"; http_client_body; content:"="; http_client_body; reference:cve,2026-35467; classtype:attempted-user; sid:202635467; rev:1;)

Explanation: Because CVE-2026-35467 exists purely within browser storage APIs, the strongest network-side signature is the outbound beacon carrying the keys to an attacker-controlled endpoint, which typically contains query parameters or body fields referencing key, token, or apikey. Bypasses are trivial (unique naming, base64, TLS), so tune per your application's legitimate API traffic.

Elastic Detection

The following EQL rule (to be placed in Elastic Security) searches for browser process activity accessing the IndexedDB storage directory followed by a network connection to a new/unusual external IP on the same host, which is behaviorally consistent with CVE-2026-35467 exploitation.

sequence by process.entity_id
  with maxspan=10s
  [ file where process.name : ("chrome.exe", "firefox.exe", "msedge.exe", "brave.exe",
      "chromium", "safari") and file.path : (
        "*\\IndexedDB\\*", "*/IndexedDB/*", "*\\Local Storage\\leveldb\\*") ]
  [ network where process.name : ("chrome.exe", "firefox.exe", "msedge.exe", "brave.exe",
      "chromium", "safari") and destination.ip.is_private == true and
      destination.ip not in ("127.0.0.1", "::1", "0.0.0.0") ]

Note: This EQL rule will generate FPs whenever the user visits legitimate IndexedDB-heavy websites (e.g., Google Docs, Outlook Web). For an enterprise SOC, restrict the file.path to the specific vulnerable certcc application's origin where the CNA identifies a known database name. In the absence of such detail, alert on correlation with API-key formatted content in network.data.

Splunk SPL Query

The SPL below detects Windows Defender / Sysmon / EDR events indicating a browser process accessed IndexedDB and then initiated an HTTP POST to an external IP within a short window, or any process (including the browser) initiating a DNS lookup to a new domain directly after an IndexedDB file handle event.

(index=browser OR index=endpoint) sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
| search EventCode=11 (TargetFilename="*\\IndexedDB\\*" OR TargetFilename="*Local Storage*")
   OR EventCode=3 (DestinationPort=80 OR DestinationPort=443)
| transaction host maxspan=15s endswith=(EventCode=3)
    startswith=(EventCode=11 AND TargetFilename="*IndexedDB*")
| where like(DestinationIp, "10.%") OR like(DestinationIp, "192.168.%") OR like(DestinationIp,
    "172.16.%") OR dest_host NOT IN ["*.valtersit.com", "*.trusted-domain.internal"]
| stats count by host, user, Image, DestinationIp, TargetFilename
| rename Image as "Browser Process", TargetFilename as "Accessed Storage File",
    DestinationIp as "Exfil Target IP"
| where count > 0
| table _time, host, user, "Browser Process", "Accessed Storage File", "Exfil Target IP"
| sort - _time

This query requires Sysmon (or equivalent) process file-access logging (Event 11) plus network connection logging (Event 3). Without the latter, browser-built TLS prevents payload inspection; this detection is entirely behavioral with high FP rate and should be scoped to the known origin when implemented.

Wazuh OSSEC Rule

The Wazuh rule below is designed for FIM/log-collection mode to trigger when a browser downloads a script that is subsequently executed and makes a network request in a pattern typical of post-exploitation. Because OSSEC typically inspects server logs rather than browser-internal APIs, the rule matches on a specific server-side log entry indicating an out-of-band web request to an external IP carrying API-key parameters (captured by a reverse proxy or application-layer WAF feeding OSSEC).

<group name="certcc_cve_2026_35467,">
  <rule id="100467" level="12">
    <if_sid>41000</if_sid>  <!-- parent: HTTP ACCESS LOG -->
    <field name="url">\.(php|aspx?|jsp|do)\?*(key|apikey|token|encryption_key|cred)\.*=</field>
    <description>CVE-2026-35467 attempt: HTTP request containing credential-named parameter from a client. Possible IndexedDB key exfiltration pattern.</description>
    <group>web_application_attack,cve_2026_35467,</group>
    <mitre>
      <id>T1555.005</id>
    </mitre>
  </rule>

  <rule id="100468" level="15">
    <if_sid>100467</if_sid>
    <field name="srcip">!^10\.|!^192\.168\.|!^127\.</field>
    <description>External-source request with credential exfil signature (CVE-2026-35467)</description>
    <group>cve_2026_35467,</group>
  </rule>
</group>

Caveat: This is a generic API-key-in-URL exfiltration signature suitable for OSSEC monitoring of web-server access logs. Detection accuracy is low without application-specific context; use as a high-severity alert requiring analyst triage.

Mitigation & Patch Guidance

Patch confidence for CVE-2026-35467 is 2/4 (CLAIMED — a single source, the CNA, claims a patch exists, but it is not independently confirmed). The Affected Versions list is empty and no vendor fix or workaround has been documented at publication time. The affected vendor is certcc, which cannot be reliably mapped to a known software product.

1. Immediate Mitigations (until patch verification):

• Deploy a Content Security Policy (CSP) that disallows inline scripts and restricts script-src to trusted origins. This raises the bar for the XSS prerequisite needed to execute the IndexedDB read in the first place.
• Restrict browser extension permissions by policy (Chrome/Edge enterprise policy, Firefox enterprise policy) to prevent extensions with all_urls host permissions from reading the target origin's IndexedDB.
• If the application stores sensitive material client-side, instruct users to avoid developer tools and log out of sessions on shared/public machines.
• Monitor application logs for unusual API rate or access from unexpected geo-locations, as the stolen keys would trigger such activity.

2. Patch / Upgrade Steps:

• Contact the vendor (certcc) to obtain the claimed patch or fixed-version details; as of this writing, no version number was published in the CVE entry.
• Upon patch release, review the CNA claim by validating that CryptoKey objects are now created/generated with extractable = false, and no credential is written as a raw string to any IndexedDB object-store.

3. Long-Term Hardening:

• The application should use non-extractable CryptoKey objects managed exclusively by the Web Crypto API; any symmetric keys needing server access should be wrapped (encrypted with a wrapping key whose private half never leaves the server).
• API keys meant for session-bound temporary use should be stored in memory only (not persisted to IndexedDB), or passed via HttpOnly cookies and sent in Authorization headers without exposure to JavaScript.
• Enforce Subresource Integrity (SRI) on all third-party scripts to prevent supply-chain script substitution.
• Because the CNA title explicitly calls out "extractable in browser IndexedDB", developer training should stress the browser security boundary is not equivalent to server-side storage.

References

As of this report (and per the CVE intelligence data provided), no vendor advisory, researcher write-up, or CISA KEV listing is available. The authoritative references below reflect the CVE record itself and general Web Crypto/IndexedDB hardening material that apply to this class of vulnerability.

1. NVD Entry (CVE-2026-35467) — (once populated: https://nvd.nist.gov/vuln/detail/CVE-2026-35467) — Current metadata: CNA Title "Private Key stored as extractable in browser IndexedDB"; CVSS 7.5; no vector; EPSS 0.00232%.
2. CNA advisory — via the CVE record assigned by the certcc CNA (no direct URL provided in supplied data).
3. OWASP HTML5 Security Cheat Sheet / Web Storage section — details on IndexedDB risks with XSS and the CryptoKey.extractable property: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
4. W3C Web Cryptography API Recommendation — documentation of the extractable attribute and key handling requirements: https://www.w3.org/TR/WebCryptoAPI/
5. MITRE ATT&CK Technique T1555.005 — Credentials from Web Browsers (specifically browser storage including IndexedDB): https://attack.mitre.org/techniques/T1555/005/

Exploit-in-the-Wild Status: None reported. CISA KEV: No. Public PoC/exploit code: None. Nuclei template: No. No known threat-actor campaigns have been attributed to CVE-2026-35467 as of this writing.

Report Conventions: This report was generated from the CVE intelligence data supplied. Where the provided data lack detail (notably the missing CVSS vector string, empty affected-version list, unknown product lineage, and unconfirmed patch), the report states the absence of those specifics rather than manufacturing them. All behavior detection rules (§Detection Guidance) are derived from the vulnerability class ("extractable key in browser storage") and should be customized with knowledge of the actual certcc application once that identity is clarified.