A longstanding vulnerability in Ruby on Rails’ cross-site request forgery (CSRF) protections has resurfaced, as security researchers have demonstrated that all current versions, as well as those released since the 2022–2023 security “fix,” remain exposed to practical bypass techniques.
The Rails framework’s implementation, meant to defend web applications from CSRF attacks, mistakenly undermines its own protection by mishandling how “authenticity tokens” are composed and validated.
Serious Vulnerability Discovered in Rails’ Masked Authenticity Tokens
Rails’ CSRF defense mechanism relies on generating what’s called a “masked authenticity token,” intended as a per-request random value to prevent attackers from exploiting predictable tokens.
This token is constructed by generating a random “one-time pad” (OTP), which is then XORed with a “raw token” derived either globally or per-form (the latter as an HMAC of the session, action path, and method).
Crucially, Rails concatenates the OTP and the XORed result (the masked token), encodes this pair, and ships it to the browser as a single, base64-encoded CSRF token.
The critical flaw lies in the inclusion of both the OTP and the “ciphertext” (masked token) within the delivered token.
Because the OTP is present, anyone intercepting the token can trivially recompute or recover the original raw token by simply reversing the XOR operation.
This undermines the intended secrecy and essentially renders the masking ineffective.
Attackers with access to any valid CSRF token can use the known OTP and masked segment to extract the raw token, forge tokens with new OTPs, or replay the original tokens-defeating critical CSRF protections entirely.
JavaScript Tool Shows How to Forge Valid CSRF Tokens
Recent proof-of-concept JavaScript code, circulating among security researchers, automates this attack.
The tool decodes any given Rails CSRF token, extracts the OTP and masked token, reconstructs the raw token, and can then repackage it into a new, valid CSRF token using any chosen OTP value.
Since the application only checks if the unmasked raw token is valid, and not the OTP or masked token, this forgery works even with newly generated OTPs, making session hijacking or unauthorized data modification attacks straightforward for those able to capture tokens.
At the core of the problem are a series of Rails methods, particularly mask_token and related helpers in the request_forgery_protection.rb code.
By XORing the one-time pad with the raw token and concatenating the two, the framework inadvertently gives away both the key and the ciphertext, defeating the purpose of the masking approach.
According to the Seclists Report, this design, originally intended to mitigate SSL compression attacks like BREACH, falls short of providing effective CSRF protection.
The security community is now urging Rails maintainers to reconsider the masking token construction, as simply encoding and transmitting the key alongside the protected value nullifies the cryptographic goals of the scheme.
In the meantime, web application operators are strongly advised to review their CSRF protection assumptions and monitor for upstream patches or alternative mitigations.
This incident underscores the importance of not only implementing cryptographic defenses but ensuring they are robust in practice and not compromised by subtle design oversights.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant updates
 protections has resurfaced, as security researchers have demonstrated.){kind=link}