| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| altcha-lib | npm | < 1.4.1 | 1.4.1 |
| altcha-org/altcha | composer | < 1.3.1 | 1.3.1 |
| github.com/altcha-org/altcha-lib-go | go | < 1.0.0 | 1.0.0 |
| org.altcha:altcha | maven | < 1.3.0 | 1.3.0 |
| altcha | rubygems | < 1.0.0 | 1.0.0 |
| altcha | pip | < 1.0.0 | 1.0.0 |
| altcha | erlang | < 1.0.0 | 1.0.0 |
The vulnerability, identified as GHSA-6gvq-jcmp-8959, is a cryptographic semantic binding flaw across multiple ALTCHA libraries. The core issue lies in the createChallenge (or equivalent) function in each library. This function is responsible for generating a proof-of-work challenge. The salt parameter within this challenge was not being properly delimited. This allowed an attacker to perform 'challenge splicing' by appending their own parameters to the salt. Since the HMAC signature did not unambiguously bind the intended challenge parameters, an attacker could have a valid proof-of-work submission reinterpreted with a modified expiration value, enabling replay attacks.
The patches across all affected libraries (Go, Java, Ruby, JavaScript/TypeScript, PHP, and Elixir) address this by ensuring the salt string always ends with an ampersand (&). This acts as a delimiter, preventing an attacker from adding new parameters that would be misinterpreted by the server. The analysis of the provided commits confirms that the createChallenge function (and its equivalents) is the primary vulnerable function, as it is responsible for the insecure construction of the salt. In some libraries, the corresponding extractParams function was also updated to align with the new, correct salt format.
org.altcha.altcha.Altcha.createChallengesrc/main/java/org/altcha/altcha/Altcha.java
createChallengealtcha.go
Altcha.create_challengelib/altcha.rb
createChallengelib/index.ts
extractParamslib/index.ts
BaseChallengeOptions::__constructsrc/BaseChallengeOptions.php
Altcha::extractParamssrc/Altcha.php
Altcha.create_challengelib/altcha.ex