CVE-2026-6143: cc-switch ProxyServer RCE Vulnerability

CVE-2026-6143 Overview

A security flaw has been discovered in farion1231 cc-switch up to version 3.12.3. This vulnerability affects functionality within the file src-tauri/src/proxy/server.rs of the ProxyServer component. The manipulation results in a permissive cross-domain policy with untrusted domains, allowing attackers to bypass origin validation mechanisms. The attack can be executed remotely, and an exploit has been released to the public and may be used for attacks.

Critical Impact

Remote attackers can exploit the permissive cross-domain policy to bypass security boundaries, potentially enabling unauthorized access to resources or data exfiltration through cross-origin requests from untrusted domains.

Affected Products

• farion1231 cc-switch versions up to and including 3.12.3
• ProxyServer component (src-tauri/src/proxy/server.rs)
• Tauri-based desktop applications utilizing the affected proxy server functionality

Discovery Timeline

• April 13, 2026 - CVE-2026-6143 published to NVD
• April 13, 2026 - Last updated in NVD database

Technical Details for CVE-2026-6143

Vulnerability Analysis

This vulnerability is classified as CWE-346 (Origin Validation Error), which occurs when an application does not properly verify that the source of data or communication is valid. In the context of cc-switch, the ProxyServer component located in src-tauri/src/proxy/server.rs fails to properly validate cross-origin requests, implementing an overly permissive cross-domain policy that accepts requests from untrusted domains.

The vulnerability allows remote attackers to interact with the proxy server from any origin, bypassing the same-origin policy protections that should restrict cross-domain communications. This is particularly concerning in Tauri applications, which bridge web technologies with native desktop capabilities, as an attacker could potentially leverage the proxy functionality to access resources that should be restricted.

Root Cause

The root cause lies in improper implementation of origin validation within the ProxyServer component. The code fails to adequately restrict which domains are permitted to make cross-origin requests to the proxy server. This may stem from overly permissive CORS (Cross-Origin Resource Sharing) headers, missing origin checks, or accepting wildcard origins without proper domain validation. The affected file src-tauri/src/proxy/server.rs does not enforce strict origin policies, allowing untrusted domains to communicate with the proxy server.

Attack Vector

The attack is network-based and can be executed remotely. An attacker can craft malicious web content that makes cross-origin requests to a victim's running cc-switch application. Since the proxy server does not properly validate the origin of incoming requests, the attacker's malicious domain can interact with the proxy server as if it were a trusted origin.

The exploitation scenario involves hosting malicious content on an attacker-controlled domain that targets users running vulnerable versions of cc-switch. When a victim visits the attacker's website while cc-switch is running, the malicious page can make requests to the local proxy server, potentially allowing data exfiltration, configuration manipulation, or abuse of proxy functionality.

For technical details on the vulnerability mechanism and exploitation, see the GitHub Issue #1841 and the VulDB entry #357007.

Detection Methods for CVE-2026-6143

Indicators of Compromise

• Unexpected cross-origin requests to the local proxy server from untrusted external domains
• Unusual network traffic patterns originating from the cc-switch application to external endpoints
• Log entries showing requests with suspicious or unexpected Origin headers
• Web requests from unknown domains targeting the ProxyServer component

Detection Strategies

• Monitor network traffic for cross-origin requests to the cc-switch proxy server from untrusted domains
• Implement application-level logging to capture and analyze Origin headers on incoming requests
• Deploy browser-based security tools that alert on suspicious cross-origin communications
• Use network intrusion detection systems (IDS) to identify unusual traffic patterns associated with the proxy server

Monitoring Recommendations

• Enable verbose logging in the cc-switch application to capture all incoming proxy requests
• Monitor system logs for any anomalous behavior related to the Tauri application runtime
• Implement alerting for requests originating from unknown or suspicious domains
• Regularly review proxy server access logs for patterns indicating exploitation attempts

How to Mitigate CVE-2026-6143

Immediate Actions Required

• Update cc-switch to a version newer than 3.12.3 once a patched release becomes available
• Review the GitHub Pull Request #1915 which addresses this vulnerability
• Restrict network access to the cc-switch proxy server where possible using local firewall rules
• Consider disabling the ProxyServer component if it is not essential to your workflow

Patch Information

A fix for this vulnerability has been submitted via Pull Request #1915 on the cc-switch GitHub repository. Users should monitor the repository for the release of a patched version and update as soon as it becomes available. The patch addresses the origin validation issues in the src-tauri/src/proxy/server.rs file by implementing proper cross-domain policy restrictions.

For additional vulnerability intelligence and tracking, refer to VulDB #357007.

Workarounds

• Implement local firewall rules to restrict incoming connections to the proxy server to trusted sources only
• Avoid browsing untrusted websites while cc-switch is running
• If possible, configure the proxy server to bind only to localhost (127.0.0.1) to prevent remote exploitation
• Consider running cc-switch in an isolated environment or virtual machine to limit exposure

# Example: Restrict access to local proxy using iptables (Linux)
# Block external connections to the proxy server port (adjust port number as needed)
iptables -A INPUT -p tcp --dport <PROXY_PORT> ! -s 127.0.0.1 -j DROP

# Verify the rule is in place
iptables -L INPUT -n -v