v1.28.2

A security patch for anyone using FCaptcha as a Node library. Upgrade if you require('@webdecoy/fcaptcha') and call the ScoringEngine API directly.

Security

The Node library could issue a token without a valid proof of work.

The HTTP servers treat the proof of work as a precondition: no valid proof, no token, whatever the score says. The exported ScoringEngine did not. It counted a missing or invalid proof as weighted evidence instead — and that evidence on its own stays below the allow threshold, so a request carrying no proof at all could still be issued a token.

The library now applies the same precondition as the servers: the token is withheld and the result reports pow_not_satisfied.

Affected: every version through 1.28.1, for integrations that import the package as a library.

Not affected: deployments running server.js, the Docker image, or the Helm chart. Those paths always enforced the precondition. The Go and Python servers were never affected.

What to do: upgrade to 1.28.2. There is no configuration change and no API change — verify() keeps its signature, and a call that already passed a valid proof behaves exactly as before. Only the no-proof and bad-proof paths change, and they change to refusing a token.

Node dependency advisories cleared. The dependency graph moves to patched versions, resolving the path-to-regexp, body-parser and qs denial-of-service advisories. npm audit --omit=dev reports zero vulnerabilities.

Fixed

• Docker Compose no longer starts a Redis service that nothing used.

Changed

• The deployment documentation now states plainly that challenges, replay guards, rate limits, suspicion history and idempotency are all process-local. A single instance is the supported topology — running multiple replicas gives them inconsistent challenge and replay state. REDIS_URL is marked reserved rather than functional, and the documented Go requirement matches go.mod.