Cryptographically weak random number generation in github.com/dinever/golf

The golf web framework for Go generated Cross-Site Request Forgery (CSRF) tokens using the math/rand package, which is not a cryptographically secure random number generator [1]. This design flaw made token values predictable, as the output of math/rand can be reverse-engineered with a relatively small number of observations, enabling attackers to forge valid tokens without legitimate access to the session [1].

An attacker can exploit this vulnerability by observing a few CSRF tokens from a legitimate user—for example, by luring them to a malicious site that triggers requests and captures the tokens—and then using the predictable pattern to generate future tokens. Since the tokens are tied to user sessions, the attacker can craft requests that appear to originate from the victim, bypassing the framework's CSRF protection [1].

Successful exploitation allows an attacker to perform actions on behalf of the victim, such as modifying account settings, submitting forms, or executing state-changing operations, all without the victim's knowledge. This effectively undermines the security model that CSRF tokens are meant to enforce [1][3].

The vulnerability was addressed in golf release v0.3.0, which switched to a cryptographically secure random generator for token creation [2]. Users should upgrade to v0.3.0 or later to mitigate the risk. The issue is also tracked as Go vulnerability GO-2020-0045, providing additional guidance [3]. As of this writing, no widespread exploitation in the wild has been reported, but the predictable token generation remains a serious risk for unpatched instances.