Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
Sources: National Vulnerability Database, CISA KEV, Exploit-DB
CVE-2025-9604 Overview
CVE-2025-9604 affects coze-studio versions up to 0.2.4. The vulnerability resides in the backend/domain/plugin/encrypt/aes.go file, where the application uses hard-coded cryptographic keys for the AuthSecretKey, StateSecretKey, and OAuthTokenSecretKey parameters. This weakness is tracked under CWE-320: Key Management Errors. An attacker with knowledge of the hard-coded keys can decrypt protected secrets or forge encrypted tokens remotely. The vendor acknowledged the issue on GitHub and stated that future releases will support user-defined key management through configuration.
Critical Impact
Hard-coded AES keys protecting authentication, state, and OAuth token secrets allow an attacker who knows the keys to decrypt or forge sensitive encrypted material in coze-studio deployments.
Affected Products
- coze-studio versions up to and including 0.2.4
- Component: backend/domain/plugin/encrypt/aes.go
- Secrets impacted: AuthSecretKey, StateSecretKey, OAuthTokenSecretKey
Discovery Timeline
- 2025-08-29 - CVE-2025-9604 published to NVD
- 2026-10-19 - Last updated in NVD database
Technical Details for CVE-2025-9604
Vulnerability Analysis
The flaw is a hard-coded cryptographic key weakness in the AES encryption module of coze-studio. The file backend/domain/plugin/encrypt/aes.go references fixed key material used to encrypt AuthSecretKey, StateSecretKey, and OAuthTokenSecretKey values. Because the keys ship with the open-source distribution, every deployment that uses defaults shares the same cryptographic secret. An attacker who reads the public repository obtains the key material directly. Exploitation requires sufficient context to locate encrypted blobs and apply the known key, which the advisory describes as high complexity and difficult to execute.
Root Cause
The root cause is static key material embedded in source code rather than loaded from an operator-controlled secret store. This violates key management best practices described by CWE-320. Without random salts or per-deployment keys, cryptographic separation between installations collapses.
Attack Vector
The attack vector is network-based and does not require authentication or user interaction. An attacker who obtains ciphertext from a vulnerable instance can derive plaintext for secrets protected by the hard-coded key. The practical reach of the attack depends on whether the attacker can observe encrypted material produced by the plugin encryption layer.
No verified proof-of-concept code is published. Refer to the GitHub Issue #505 and the related Pull Request #533 for maintainer discussion and the remediation approach.
Detection Methods for CVE-2025-9604
Indicators of Compromise
- Presence of coze-studio builds at or below version 0.2.4 running with default encryption configuration.
- Encrypted secret values in storage that match outputs produced by the upstream hard-coded key.
- Unexpected successful decryption or token acceptance from untrusted origins.
Detection Strategies
- Inventory running coze-studio instances and compare installed versions against the fixed release referenced in the vendor pull request.
- Review deployed aes.go and configuration manifests for use of upstream default key constants rather than operator-supplied values.
- Audit logs for anomalous OAuth token redemption or authentication flows that bypass expected session boundaries.
Monitoring Recommendations
- Alert on access to configuration files and environment variables that store encryption keys.
- Monitor outbound requests from coze-studio hosts that could indicate token theft or replay.
- Track upstream GitHub advisories and the VulDB entry #321780 for updates to exploitability status.
How to Mitigate CVE-2025-9604
Immediate Actions Required
- Upgrade coze-studio to a release that implements user-defined key management as described in the maintainer response.
- Replace any secrets previously encrypted under the hard-coded key by rotating AuthSecretKey, StateSecretKey, and OAuthTokenSecretKey values.
- Invalidate issued OAuth tokens and force re-authentication for all users once new keys are in place.
Patch Information
The maintainers addressed the issue through GitHub Pull Request #533. The vendor stated that scenarios requiring encryption will support user-defined key management through configuration and will use improved encryption utilities such as random salts. Operators should deploy the patched release and supply unique key material per installation.
Workarounds
- Restrict network exposure of coze-studio management and plugin endpoints to trusted networks until the patched release is deployed.
- Store encrypted secrets in an external secrets manager and avoid persisting ciphertext produced under the default keys.
- Rebuild coze-studio from source with locally generated key constants if upgrading is not immediately possible.
# Configuration example: generate per-deployment keys and inject via environment
openssl rand -base64 32 > auth_secret.key
openssl rand -base64 32 > state_secret.key
openssl rand -base64 32 > oauth_token_secret.key
export COZE_AUTH_SECRET_KEY="$(cat auth_secret.key)"
export COZE_STATE_SECRET_KEY="$(cat state_secret.key)"
export COZE_OAUTH_TOKEN_SECRET_KEY="$(cat oauth_token_secret.key)"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
Sources: National Vulnerability Database, CISA KEV, Exploit-DB
