CVE-2025-56499: 
NixOS vulnerability analysis and mitigation

CVE-2025-56499 is an arbitrary file read vulnerability in mihomo (by MetaCubeX) v1.19.11 caused by incorrect access control in the rule-providers configuration parser. Authenticated attackers with low-level privileges can read arbitrary files with elevated privileges by exploiting missing path validation in the file-type rule provider, with leaked content surfacing through the /logs API. The vulnerability was published on November 18, 2025, and affects mihomo versions up to and including v1.19.11. It carries a CVSS v3.1 base score of 6.5 (Medium) (Feedly, Red Hat Bugzilla).

The root cause is classified as CWE-1230 (Exposure of Sensitive Information Through Metadata) and CWE-284 (Improper Access Control). In rules/provider/parse.go, the schema.Type == "file" branch calls C.Path.Resolve(schema.Path) to resolve the supplied path but never invokes C.Path.IsSafePath() or any equivalent whitelist/sandbox constraint — a check that is correctly applied in the http branch. An authenticated attacker with access to the external controller API (protected by a bearer token obtainable from the config file) can submit a crafted PUT /configs request embedding a malicious rule-providers entry with type: file and an arbitrary absolute path (e.g., /etc/shadow). Because mihomo commonly runs with root/administrator privileges, the service attempts to parse the target file as rule data, fails, and emits content fragments into in-memory logs that are then exposed via the /logs API endpoint (PoC Repo).

Successful exploitation results in high-impact information disclosure: an attacker can read any file accessible to the mihomo process, which frequently runs as root or an administrator. Sensitive files such as /etc/shadow, SSH private keys, application secrets, or configuration files containing credentials can be exfiltrated through the /logs endpoint. There is no integrity or availability impact, but the confidentiality breach can facilitate privilege escalation or lateral movement if harvested credentials are reused (Feedly, PoC Repo).

A public proof-of-concept exploit is available at the GitHub repository Cherrling/CVE-2025-56499, published around December 31, 2025, demonstrating the full exploitation flow with curl commands (PoC Repo). Exploitation requires low-level authenticated access (a bearer token), which can be obtained from the mihomo config file by an attacker with local read access or through other means. The EPSS score is approximately 0.018% (0.000180), indicating low automated exploitation probability at this time. No CISA KEV listing or active in-the-wild exploitation campaigns have been reported. No threat actor attribution is available.

1. Obtain the external controller bearer token: Access the mihomo configuration file (e.g., config.yaml) to retrieve the secret (API key) used to authenticate to the external controller API.
2. Start listening for logs: Open a streaming connection to the /logs endpoint to capture parser output:

   curl -X GET "http://localhost:9999/logs" -H "Authorization: Bearer <token>"

3. Inject a malicious rule-provider configuration: Submit a PUT /configs request with a crafted payload specifying type: file and the target sensitive file path:

   curl -X PUT "http://localhost:9999/configs" \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '{"payload": "{\"log-level\": \"debug\", \"rule-providers\": {\"pwn\": {\"type\": \"file\", \"behavior\": \"classical\", \"format\": \"text\", \"path\": \"/etc/shadow\"}}}" }'

4. Harvest leaked content: The service attempts to parse /etc/shadow as rule data, fails, and emits error messages containing file content fragments into the log stream captured in step 2.
5. Repeat for additional files: Iterate with different target paths (e.g., SSH keys, application secrets) to broaden data extraction (PoC Repo).

• Network: Unexpected PUT /configs requests to the mihomo external controller port (default 9090 or custom) containing rule-providers entries with type: file and absolute paths to sensitive system files; repeated GET /logs requests from unusual source IPs.
• Logs: Mihomo log output containing parse error messages with fragments of system files (e.g., lines resembling /etc/shadow hash entries or SSH key material); log entries referencing unexpected file paths such as /etc/shadow, /etc/passwd, /root/.ssh/id_rsa.
• File System: No direct file system artifacts from exploitation itself, but review mihomo config.yaml for unauthorized modifications to rule-providers sections.
• Process: Unusual API calls to the mihomo external controller from processes or IPs not associated with normal dashboard or management activity (PoC Repo).

The upstream fix is tracked in MetaCubeX/mihomo pull request #2177, which adds IsSafePath() enforcement to the file-type rule provider branch. Users should upgrade to a version of mihomo beyond v1.19.11 that includes this fix (v1.19.12 or later) (PoC Repo, mihomo repo). As a workaround, restrict access to the mihomo external controller API by binding it to localhost only, using strong/unique bearer tokens, and limiting which users or processes can read the config file containing the secret. Avoid running mihomo with root privileges where possible to reduce the impact of file read exposure.

Red Hat tracked the issue via Bugzilla (Bug 2415714) and assigned it a low severity/priority rating, noting it as an information disclosure issue (Red Hat Bugzilla). A brief mention appeared on Bluesky via automated CVE tracking accounts shortly after disclosure. No significant vendor statements, major media coverage, or notable researcher commentary beyond the PoC repository have been identified.