Session handling failures in 2026 were not exotic. NocoDB (CVE-2026-46550, June 23) set a refresh-token cookie httpOnly but without Secure or SameSite. Cacti (CVE-2026-40082, June 25) never called session_regenerate_id() after login. Ghost (CVE-2026-70594, August 4) did not invalidate existing sessions on admin login.
What's affected
- NocoDB before 2026.04.1: without
SameSite, browsers attached the cookie to cross-site POSTs, enabling CSRF against the token-refresh endpoint. WithoutSecure, it could be intercepted over plain HTTP. Fixed in 2026.04.1. - Cacti 1.2.30 and prior: session fixation after login. The advisory notes the cookie was otherwise well configured (
httponly,samesite=Strict,secureon HTTPS), and that those flags do not prevent fixation through same-site vectors. Fixed in 1.2.31. - Ghost from 2.2.0 until 6.54.1: session fixation at admin login. The advisory says exploitation needed another vulnerability on the same domain. Fixed in 6.54.1.
What to do now
Upgrade those products if you run them, then audit your own app with a browser and one command:
curl -s -i -c jar.txt -X POST https://app.example.test/login -d 'user=test&pass=test' | grep -i '^set-cookie'
Check each of these, which follow the OWASP session management and CSRF cheat sheets:
Secure,HttpOnlyand an explicitSameSiteofLaxorStricton every auth cookie. Do not rely on a browser default.- The
__Host-prefix for the session cookie, which requiresSecure,Path=/and noDomain, so a sibling subdomain cannot overwrite it. - A new session ID at login and at any privilege change, with the old one destroyed.
- A CSRF token (synchronizer token, or signed double submit) on every state-changing request. OWASP treats SameSite as defense in depth, not a replacement.
- No state change on GET, because
Laxstill sends cookies on top-level GET navigations.
How this could have been avoided
- Test the cookie flags in CI against a running instance, with a failing check for any auth cookie missing an attribute.
- Add a test that logs in with a planted session ID and requires a different ID afterward.
- Use the framework's built-in session and CSRF middleware, and avoid hand-set cookies for tokens.
Try it yourself
On a staging copy of your app, open the login page and note the session cookie value before you sign in. Sign in and compare. If the value is the same, you have the Cacti and Ghost bug. Then read the Set-Cookie header and compare it against the list above.
Click through it at your own pace, or open it full screen.
Quick check
Why did Cacti's strong cookie flags not stop session fixation?
Fixation is about the session ID not changing at login, not about how the cookie is sent. The flags do not rotate the ID.