Skip to main content
ALTCHA®

Security Advisory

Oct. 2, 2026: Java Library - Denial of service via quadratic-time parsing of large numbers in ALTCHA payloads

Vulnerability Summary

In altcha-lib-java before 2.1.1, an unauthenticated client can cause a denial of service. It does this by sending an ALTCHA payload that contains a very long number. The library parses the payload before it checks any signature. The parser handles large numbers in quadratic time, so one request of about 1 MB can use around 10 seconds of server CPU.

Impact

This affects any server that passes the client-submitted altcha payload as a string to verifySolution, verifyServerSignature, parsePayload or isServerSignaturePayload. Both the v1 and v2 APIs are affected. A few concurrent requests can use up all CPU cores and make the application unresponsive. The attacker needs no credentials, valid challenge or solved proof-of-work. Confidentiality and integrity are not affected.

Fix

Version 2.1.1 parses payloads in linear time. Version 2.1.0 fixed only the v2 API. If you can't upgrade right away, limit the size of the request body or the altcha field before passing it to the library. Legitimate payloads are well under 4 KB.

Status

PATCHED

Version: 2.1.1
GitHub Adivisory: https://github.com/altcha-org/altcha-lib-java/security/advisories/GHSA-7wvr-36h8-wq6c

Timeline

  • Oct. 2, 2026: Discovered and patched by ALTCHA, advisory published

Oct. 2, 2026: Python Library (v1) - Expired v1 challenges accepted via duplicate expires salt parameter

Vulnerability Summary

An incomplete fix for CVE-2025-68113 in the altcha Python library (versions ≤ 2.1.0) lets an attacker reuse expired challenges. verify_solution() in altcha/v1.py reads the challenge's expires value with one parser and recomputes the proof-of-work hash with a different one. If the salt contains a duplicate expires parameter, the two parsers pick different values. A crafted salt can therefore pass the expiry check and still match the original challenge signature. Only the Python library is affected.

Impact

An attacker with one valid solved payload can replay it after it has expired, as many times as they want. This defeats the anti-automation and rate-limiting protection the challenge provides, which is the same effect as CVE-2025-68113. It affects integrations that call verify_solution() without keeping server-side state and rely on expires to stop replays. Integrations that store used challenges and accept each one only once, such as django-altcha, are not affected.

Fix

verify_solution() now hashes the submitted salt exactly as received instead of parsing it and rebuilding it. Any change to the salt, including a duplicate expires, now produces a hash that doesn't match the challenge, so the payload is rejected.

Status

PATCHED

Version: 2.2.0
GitHub Adivisory: https://github.com/altcha-org/altcha-lib-py/security/advisories/GHSA-6wgr-g55c-ch37

Timeline

  • Sep. 30, 2026: Reported by Kasif Shaikh (https://kasiflabs.dev)
  • Oct. 1, 2026: Confirmed and patched by ALTCHA
  • Oct. 2, 2026: This adivisory published

Jul. 30, 2026: Libraries - PoW v2 fallback verification does not enforce keyPrefix

Vulnerability Summary

In the fallback branch of verifySolution (used whenever a challenge has no keySignature, or the verifier doesn't have the matching hmacKeySignatureSecret), the derived key was checked only for equality against the value re-derived from the submitted counter. The required keyPrefix was never checked. This lets a client submit any counter with a single KDF execution and pass verification, entirely skipping the proof-of-work search the prefix is meant to enforce.

Impact

The fallback path covers:

  • Any probabilistic challenge.
  • Deterministic-mode challenges created without hmacKeySignatureSecret.
  • Deterministic-mode challenges where the verifier omits hmacKeySignatureSecret even though it was set at creation.

The recommended fast path (deterministic mode with a matching hmacKeySignatureSecret set on both creation and verification) was unaffected.

Fixes

  • Dart https://github.com/altcha-org/altcha-lib-dart: v0.3.1
  • Elixir https://github.com/altcha-org/altcha-lib-ex: v2.0.1
  • Java https://github.com/altcha-org/altcha-lib-java: v2.0.3
  • Python https://github.com/altcha-org/altcha-lib-py: v2.1.0
  • Ruby https://github.com/altcha-org/altcha-lib-ex: v2.0.1
  • Rust https://github.com/altcha-org/altcha-lib-rs: v0.2.0
  • TS/JS https://github.com/altcha-org/altcha-lib: v2.3.2

Go, PHP, C++ libraries are unaffected.

Status

PATCHED

Version: see versions above
GitHub Adivisory: https://github.com/altcha-org/altcha-lib/security/advisories/GHSA-rx38-p542-v527

Timeline

  • Jul. 27, 2026: Reported by Sebastian Sala (https://github.com/salasebas)
  • Jul. 27, 2026: Confirmed by ALTCHA
  • Jul. 27 - 30, 2026: Patches published for all affected libraries
  • Jul. 30, 2026: This adivisory published

Jul. 25, 2026: Go lib - Nil-map panic (pre-verification DoS) in v1 parseServerSignature on malformed VerificationData

Vulnerability Summary

parseServerSignature in the v1 module only initializes ServerSignatureVerificationData.Extra inside the if err == nil branch after url.ParseQuery(parsedPayload.VerificationData). Go's url.ParseQuery returns the successfully-parsed pairs together with a non-nil error when the query string contains a malformed percent-escape. A subsequent loop unconditionally writes unknown keys into Extra, regardless of err, causing a nil-map write panic (assignment to entry in nil map) whenever an attacker supplies a VerificationData string with a bad %-escape (e.g. x=1&%zz=2).

Impact

Any application calling VerifyServerSignature or VerifyServerSignatureSafe on unauthenticated input can be made to panic by submitting a crafted payload. Under standard net/http, the per-request goroutine panic is recovered and the request aborts (a log-flood / per-request DoS); it escalates to a full process crash if verification runs in an application-spawned goroutine or a non-recovering framework.

Fix

Extra is now initialized unconditionally before the url.ParseQuery error check, so it's always safe to write into regardless of parse errors.

Status

PATCHED

Version: v2.1.0
GitHub Adivisory: https://github.com/altcha-org/altcha-lib-go/security/advisories/GHSA-gfwj-45pc-w6r5

Timeline

  • Jul. 25, 2026: Reported by Arpit Jain (https://arpitjain.fyi/)
  • Jul. 25, 2026: Confirmed and patched by ALTCHA, patch published as v2.1.0
  • Jul. 25, 2026: This adivisory published

Jul. 2, 2026: PHP lib - verifySolution bypasses HMAC signature check when challenge signature is absent

Vulnerability Summary

In the PHP library v2, the verifySolution method skips HMAC signature verification when the signature field is absent from the challenge payload, even when hmacSignatureSecret is configured.

An attacker who strips the signature key from the challenge JSON passes the condition as false, bypassing tamper-detection entirely. The PoW solution check then runs against unverified parameters — allowing an attacker to self-issue a low-difficulty challenge, solve it trivially, and submit a payload that verifies as true.

Impact

Complete CAPTCHA bypass on any deployment that sets hmacSignatureSecret (the recommended production configuration).

Fix

The check was split so that a missing signature is explicitly rejected when a secret is configured.

Status

PATCHED

Version: v2.0.3
GitHub Adivisory: https://github.com/altcha-org/altcha-lib-php/security/advisories/GHSA-82w8-65qw-gch6

Timeline

  • Jul. 2, 2026: Reported by Markus Fasselt (https://fasselt.it)
  • Jul. 2, 2026: Confirmed and patched by ALTCHA, patch published as v2.0.3
  • Jul. 7, 2026: This adivisory published

Dec. 2025: Proof-of-Work Vulnerable to Challenge Splicing and Replay

Vulnerability Summary

ALTCHA libraries are affected by a cryptographic semantic binding flaw that enables challenge payload splicing, which can lead to replay attacks (CWE-115, CWE-347). The HMAC signature only binds to the concatenation of the salt string and the nonce, without clearly delimiting where challenge parameters end and the nonce begins. As a result, an attacker can reinterpret a previously valid payload by shifting digits between the expiration parameter and the nonce. For example, treating salt?expire=100987 as salt?expire=1009 with nonce 87.

This vulnerability can make a challenge appear valid for an arbitrarily long time, allowing it to be reused beyond its intended lifetime. In common server implementations that track used nonces only for a limited period and validate expiration using a simple expires > now check, this flaw enables repeated replay of previously solved challenges. An attacker can therefore amortize proof-of-work computation over time, progressively increasing effective throughput without performing additional work.

Impact

Medium. The effective impact depends on server-side replay handling and deployment assumptions. ALTCHA Sentinel versions prior to v1.16.0 are vulnerable.

Recommended Patch

Ensure explicit semantic separation between challenge parameters and the nonce by appending a delimiter to the end of the salt before HMAC computation. Specifically:

  • Before: <salt>?expires=<time>
  • After: <salt>?expires=<time>&

Adding the & delimiter prevents parameter–nonce splicing by clearly terminating the parameter list. This change is backward-compatible with existing implementations, as & is treated as a standard URL parameter separator and does not alter the meaning of previously defined parameters.

Status

PATCHED

GitHub Adivisory: https://github.com/altcha-org/altcha-lib/security/advisories/GHSA-6gvq-jcmp-8959

Timeline

  • Dec. 10, 2025: Reported by Yumechi

  • Dec. 11, 2025: Investigated by ALTCHA and vulnerability confirmed

  • Dec. 14, 2025: This adivisory published

    ALTCHA Sentinel patched in version v1.16.0

    Integration libraries patched in the following versions:

    • JS https://github.com/altcha-org/altcha-lib: v1.4.1
    • PHP https://github.com/altcha-org/altcha-lib-php: v1.3.1
    • Python https://github.com/altcha-org/altcha-lib-py: v1.0.0
    • Go https://github.com/altcha-org/altcha-lib-go: v1.0.0
    • Java https://github.com/altcha-org/altcha-lib-java: v1.3.0
    • Elixir https://github.com/altcha-org/altcha-lib-ex: v1.0.0
    • Ruby https://github.com/altcha-org/altcha-lib-ex: v1.0.0
    • Wordpress Plugin v2 https://github.com/altcha-org/altcha-wordpress-next: v2.3.1
    • Wordpress Plugin v1 https://github.com/altcha-org/wordpress-plugin: v1.26.3

  • Dec. 14, 2025: GitHub Adivisory published, CVE requested

  • Dec. 15, 2025: Customers and 3rd-party integrators notified

  • Dec. 16, 2025: Assigned CVE-2025-68113

Start typing to search...

↑ ↓ Navigate ↵ Select