CVE-2026–64857 — Session Fixation in Tirreno Authentication

I recently discovered a session fixation vulnerability in the authentication flow of Tirreno, an open-source analytics platform

The issue was caused by the application keeping the same session identifier before and after a successful login

What was happening?

During login, Tirreno authenticated the user and stored the authenticated state in the existing session, but the session ID itself was not regenerated

In a secure authentication flow, the session identifier should be rotated after authentication

The relevant login flow was essentially:

// User authentication succeeds

$_SESSION['active_user_id'] = $user['id'];
$_SESSION['role'] = $user['role'];

// Session ID was not regenerated here

// User authentication succeeds

$_SESSION['active_user_id'] = $user['id'];
$_SESSION['role'] = $user['role'];

// Session ID was not regenerated here

Because the existing session remained active, an attacker who could get a victim to authenticate using a session identifier already known to the attacker could potentially reuse that session after login.

The affected component was:

app/Controllers/Pages/Login.php

app/Controllers/Pages/Login.php

Proof of Concept

I first compared the session identifier before and after authentication on the Tirreno demonstration environment

The result showed that the identifier remained unchanged:

Pre-auth Session ID : [same value]
Post-auth Session ID: [same value]

Result: Session ID unchanged after login

Pre-auth Session ID : [same value]
Post-auth Session ID: [same value]

Result: Session ID unchanged after login

This confirmed the underlying session fixation condition. The PoC used the application's public demonstration environment and did not access or modify any unrelated user data

Visual confirmation

Before login — session cookie

Then place:

PoC output

After the browser-level verification, I reproduced the behavior using a small Bash/cURL PoC

Then:

The uploaded PoC specifically compares PRE_SID and POST_SID and reports the session as vulnerable when they match

Why this matters

Session fixation becomes dangerous when an attacker can cause a victim to authenticate using a session identifier that the attacker already knows

After authentication, that same identifier can represent the victim's authenticated session

The important security boundary here is therefore the transition from:

Unauthenticated session → Authenticated session

That transition should always involve session ID rotation

Remediation

The fix is straightforward: regenerate the session identifier after successful authentication

For example:

session_regenerate_id(true);

session_regenerate_id(true);

This invalidates the previous session and creates a new identifier for the authenticated session

The recommended remediation in my original technical report was to regenerate the session ID during the login flow

Disclosure

The vulnerability was responsibly disclosed to Tirreno Technologies, and the issue was subsequently fixed

The vulnerability was published through GitHub Security Advisories as:

GHSA-gwcm-4p9m-9mvr and has now been assigned: CVE-2026–64857

🔗 CVE: CVE-2026–64857

🔗 GitHub Security Advisory: GHSA-gwcm-4p9m-9mvr

Final thoughts

This was a good reminder that authentication security is not only about correctly validating credentials. Session lifecycle management is equally important

A successful login should establish a new authenticated session, rather than simply upgrading an existing unauthenticated session

I'm glad to have contributed this finding to the security of an open-source project.

CVE-2026–64857 | CWE-384

Contents