CVE-2025-68113: 
JavaScript vulnerability analysis and mitigation

CVE-2025-68113 is a cryptographic semantic binding flaw in ALTCHA libraries — a privacy-first captcha and bot protection solution — that enables challenge payload splicing and replay attacks. The vulnerability was disclosed on December 14, 2025, and published to the GitHub Advisory Database on December 16, 2025. It affects multiple language implementations: altcha (RubyGems, pip, Erlang) < 1.0.0, altcha-lib (npm) < 1.4.1, altcha-org/altcha (Composer) < 1.3.1, github.com/altcha-org/altcha-lib-go (Go) < 1.0.0, and org.altcha:altcha (Maven) < 1.3.0. The CVSS v3.1 base score is 6.5 (Medium) (GitHub Advisory).

The root cause is a missing semantic delimiter in the HMAC computation over challenge parameters (CWE-115: Misinterpretation of Input; CWE-347: Improper Verification of Cryptographic Signature). Specifically, the HMAC signature computed over the salt value does not unambiguously separate the salt from appended query parameters such as ?expires=<time>, allowing an attacker to craft a modified salt string that the server misinterprets as a different but still-valid parameter binding. For example, a salt of abc?expires=100 followed by a nonce is indistinguishable from abc?expires=10 with 0 prepended to the nonce, enabling an attacker to reinterpret a legitimately solved proof-of-work with a manipulated expiration value. The fix enforces explicit semantic separation by appending an & delimiter to the salt before HMAC computation, preventing parameter boundary ambiguity (GitHub Advisory, Go fix commit, Java fix commit).

Successful exploitation allows an attacker to reuse a previously solved ALTCHA proof-of-work challenge beyond its intended expiration, effectively bypassing time-based replay protections. The primary impact is on abuse-prevention mechanisms such as rate limiting and bot mitigation — an attacker could automate form submissions or API requests that would otherwise be throttled by the captcha system. The vulnerability does not directly affect data confidentiality or integrity, and there is no risk of unauthorized data access or system compromise (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2025-68113. The EPSS score is approximately 0.069% (21st percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to first legitimately solve a proof-of-work challenge and then craft a modified payload with a manipulated salt/expiration value, making it a low-complexity but targeted attack against bot mitigation infrastructure (GitHub Advisory).

1. Obtain a valid challenge: Submit a legitimate request to a target application using ALTCHA for bot protection, receiving a challenge payload containing salt, challenge, algorithm, and signature fields.
2. Solve the proof-of-work: Complete the proof-of-work computation to obtain a valid number (nonce) that satisfies the challenge hash, producing a valid signed payload.
3. Craft a spliced payload: Modify the salt field by appending characters that shift the boundary between the salt and the expires parameter (e.g., change abc?expires=1000 to abc?expires=100 with 0 absorbed into the nonce interpretation), while reusing the original signature.
4. Submit the replayed payload: Send the modified payload to the server after the original challenge's expiration time. Due to the HMAC binding ambiguity, the server may accept the reinterpreted payload as valid.
5. Bypass rate limiting: Repeat the submission to bypass bot mitigation controls, enabling automated form submissions or API abuse that the captcha was intended to prevent (GitHub Advisory).

• Logs: Server-side application logs showing repeated successful ALTCHA challenge verifications from the same client IP or session, particularly with identical or near-identical signature values across multiple requests.
• Network: High-frequency form submissions or API calls that pass ALTCHA verification without corresponding proof-of-work computation delays; requests with ALTCHA payloads where the salt field contains unusual trailing characters or malformed parameter boundaries.
• Application Behavior: Rate limiting or bot mitigation controls being bypassed despite ALTCHA being enabled; unusual spikes in form submission volume from automated sources that should be blocked by the captcha system.

Users should upgrade to the patched versions: altcha (RubyGems, pip, Erlang) 1.0.0, altcha-lib (npm) 1.4.1, altcha-org/altcha (Composer) 1.3.1, github.com/altcha-org/altcha-lib-go (Go) 1.0.0, and org.altcha:altcha (Maven) 1.3.0. As an immediate workaround without upgrading, implementations can append an & delimiter to the end of the salt value prior to HMAC computation (e.g., <salt>?expires=<time>&), which prevents parameter boundary ambiguity and is backward-compatible with existing deployments. Additionally, implementing robust server-side replay detection (e.g., storing and rejecting previously seen challenge signatures) provides defense-in-depth regardless of this vulnerability (GitHub Advisory, Erlang fix commit).