Cross-site GET reached the authenticated post-preview path on bitcointalk.org
By Sylvain Rey (0xSly), independent security researcher ·
- Target
- bitcointalk.org (SMF 1.1.19, heavily customized)
- Class
- Missing session/CSRF check (CWE-352) on a state-rendering endpoint
- Status
- Remediated by the operator on 2026-09-01; bounty paid
- Testing
- Non-destructive, GET only, no content posted or saved, no user data accessed
Timeline
| Date (UTC) | Event |
|---|---|
| 2026-08-30 | Initial report sent to the Bitcointalk security contact under its bounty program |
| 2026-08-31 | Operator confirmed the SMF 1.1.20 checkSession() was not present in the preview path, and pointed to output escaping and SameSite=Lax cookies as mitigations |
| 2026-09-01 | Follow-up report with live evidence that SameSite=Lax does not stop the GET vector |
| 2026-09-01 | Operator removed the ability to set message and subject via GET and paid a bounty |
Background
Upstream, SMF 1.1.20 added a checkSession() call in Post2() immediately before handing off to the preview handler. The 1.1.19 code path returns to the preview without verifying the session token. The SMF changelog links the change to forged-form attacks involving HTML content.
bitcointalk.org runs a substantially modified SMF 1.1.19 with selected backports. The question was whether this specific guard, or an equivalent, was present in production.
Finding
The preview path accepted request parameters without a session token, and those parameters could be supplied through a plain GET.
From a cross-site origin, a normal top-level link to the Post2 preview URL was followed in Chrome. Because top-level GET navigations carry SameSite=Lax cookies, the authenticated session was retained, and the forum rendered the attacker-supplied preview for the logged-in user without a session-verification error.
This means an attacker could make a victim’s authenticated session render attacker-controlled preview content on bitcointalk.org, initiated from any external page.
What limited the impact
- For ordinary accounts, both raw HTML and
[html]-wrapped HTML were escaped in the rendered preview. No HTML element was created in the preview DOM in testing. - Upstream SMF 1.1.19 has a separate
admin_forumbranch that un-escapes[html]content. Testing it required an administrator account, so live script execution was not claimed. The operator stated this branch is disabled in their customized code.
The confirmed issue is therefore the tokenless cross-site path into an authenticated preview, not stored or reflected script execution.
Remediation
The operator removed the ability for message and subject to be set through GET requests, which closes the cross-site vector described above, and paid a bounty for the report.
Recommended in addition, for SMF 1.1.x deployments generally: restore the session check before the preview hand-off, or an equivalent anti-CSRF token on the preview action.
Method
- Source comparison of SMF 1.1.19 and 1.1.20
Post2(). - Live tests limited to GET requests from a local cross-site origin against my own account.
- DOM inspection of
#preview_bodyfor created elements versus escaped text. - Evidence files were shared with the operator with SHA-256 checksums.
More on our work
Backend engineering and systems integration · Blockchain systems and protocol design · All articles