CVE-2025-15107: 
vulnerability analysis and mitigation

CVE-2025-15107 is a hard-coded cryptographic key vulnerability in the JWT Secret Handler component of actiontech SQLE, an open-source SQL audit platform. The vulnerability exists in sqle/utils/jwt.go where the JWTSecretKey argument defaults to the hard-coded value []byte("secret"), enabling remote attackers to forge authentication tokens. All versions up to and including 4.2511.0 are affected. It was disclosed on December 27, 2025, with the exploit publicly reported via a GitHub issue on December 9, 2025. The CVSS v3.1 base score is 8.1 (High), while the GitHub Advisory Database rates it Low (2.9) under CVSS v4.0 (Github Advisory, GitHub Issue).

The root cause is classified under CWE-321 (Use of Hard-coded Cryptographic Key) and CWE-798 (Use of Hard-coded Credentials). The JWT signing secret is hard-coded as []byte("secret") in sqle/utils/jwt.go, and a fully valid pre-signed JWT token (defaultDMSToken) is also embedded in the vendor dependency at vendor/github.com/actiontech/dms/internal/dms/pkg/constant/const.go. Because the JWT validation logic only checks the uid field (not additional claims), an attacker who knows the hard-coded secret can craft a token with the administrator UID (700200) to impersonate the admin account. The attack requires no privileges or user interaction but is rated high complexity due to the need to identify and leverage the known secret (GitHub Issue, Github Advisory).

Successful exploitation allows an unauthenticated remote attacker to forge valid JWT tokens and gain full administrative access to the SQLE backend, effectively achieving complete account takeover. Since SQLE is a database governance and SQL audit platform, an attacker with admin access could access sensitive database credentials, audit logs, and SQL execution history, and potentially issue unauthorized SQL operations against managed databases. The confidentiality, integrity, and availability of the SQLE instance and connected database assets are all at risk (GitHub Issue, Github Advisory).

A proof-of-concept exploit has been publicly disclosed via the GitHub issue tracker, demonstrating both JWT forgery using the known secret key and direct use of the hard-coded defaultDMSToken credential to access the admin backend (GitHub Issue). The EPSS score is approximately 0.032% (3rd percentile), indicating a currently low probability of widespread exploitation in the next 30 days. There is no evidence of active in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The CVSSv4 exploit maturity is rated as Proof-of-Concept (Github Advisory).

1. Reconnaissance: Identify internet-facing SQLE instances (version ≤ 4.2511.0) using tools like Shodan or Censys, searching for the SQLE web interface on common ports.
2. Obtain the hard-coded secret: The JWT signing key []byte("secret") is publicly known from the source code at sqle/utils/jwt.go. Alternatively, use the pre-signed defaultDMSToken embedded in the vendor dependency.
3. Forge an admin JWT: Using any JWT library or an online tool (e.g., jwt.io), craft a JWT payload with uid: 700200 (the known administrator UID) and sign it with the HMAC-SHA256 algorithm using the key secret.
4. Authenticate as administrator: Include the forged JWT in the Authorization header of HTTP requests to the SQLE API endpoints to gain full administrative access.
5. Alternatively, use the hard-coded token: Send the pre-built defaultDMSToken directly as the bearer token — it is valid on any default SQLE deployment and grants immediate backend access (GitHub Issue).

• Network: Unexpected API requests to SQLE administrative endpoints originating from unknown or external IP addresses; HTTP requests bearing the known hard-coded token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjMyNzI0MjEzNTMsImlzcyI6ImFjdGlvbnRlY2ggZG1zIiwidWlkIjoiNzAwMjAxIn0.45o27vHjHWslarkbovAim6oir3QlrvSDDuzfpGTn6Dk.
• Logs: SQLE access logs showing admin-level actions (UID 700200 or 700201) from IP addresses not associated with legitimate administrators; authentication events without a corresponding login flow.
• File System: No file-system artifacts are expected from token forgery alone, but watch for new user accounts, modified audit rules, or exported database credentials following unauthorized admin access.
• Process/Behavior: Unusual SQL audit rule changes, new data source connections added, or bulk export of audit logs shortly after an anomalous authentication event (GitHub Issue).

The fix is tracked under SQLE milestone v4.2512.0, which was closed on December 31, 2025; users should upgrade to a version beyond 4.2511.0 that includes this fix (GitHub Milestone). As an immediate workaround, restrict network access to the SQLE API to trusted IP ranges using firewall rules or a reverse proxy with authentication. Operators should also rotate any JWT secrets and invalidate existing sessions, and monitor for use of the known hard-coded defaultDMSToken in access logs. Until patched, consider implementing an API gateway that enforces additional authentication checks in front of SQLE.

The vulnerability was reported to the actiontech SQLE project via a GitHub issue on December 9, 2025, and the maintainers acknowledged it by assigning it to the v4.2512.0 milestone for remediation (GitHub Issue). The issue was noted on social platforms including Bluesky and Mastodon/infosec.exchange by automated CVE tracking accounts shortly after publication. No significant independent researcher commentary or major media coverage has been identified beyond standard vulnerability database aggregation.