Safeguard
Application Security•

Session Cookie and CSRF Defaults to Audit, From Cacti, Ghost and NocoDB

Three 2026 advisories: NocoDB shipped a cookie without Secure or SameSite, Cacti and Ghost never rotated the session ID at login. A short audit you can run on your own app.

Safeguard Security Team
3 min read

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. Without Secure, 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, secure on 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:

  1. Secure, HttpOnly and an explicit SameSite of Lax or Strict on every auth cookie. Do not rely on a browser default.
  2. The __Host- prefix for the session cookie, which requires Secure, Path=/ and no Domain, so a sibling subdomain cannot overwrite it.
  3. A new session ID at login and at any privilege change, with the old one destroyed.
  4. A CSRF token (synchronizer token, or signed double submit) on every state-changing request. OWASP treats SameSite as defense in depth, not a replacement.
  5. No state change on GET, because Lax still 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.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.