Zum Inhalt springen

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

Security Advisory

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