CVE-2025-10228 | Session Fixation in Rolantis Agentis Framework (< v4.44)

Published: October 14, 2025
Researcher: Onurcan Genç Independent Security Researcher
CVE: CVE-2025-10228
USOM Advisory: TR-25-0336

Summary

Background

During a routine visit to gidello.com a travel ticketing platform built on the Rolantis Agentis Framework I noticed a behavioral anomaly in how the application handled user sessions. What started as checking holiday tickets turned into a security finding that resulted in a published CVE.

Agentis is a PHP-based CMS/framework powering multiple web applications. Its technology stack includes:

• Frontend: Bootstrap 3.3.4 + jQuery 1.10.2
• Backend: PHP with PHPSESSID cookie-based session management
• Framework bundle: libs.2.0.1.js served via CDN (cdn.trav3l.net)

Vulnerability Description

The application fails to regenerate the session identifier (PHPSESSID) after a successful authentication event. This is a textbook Session Fixation vulnerability (CWE-384).

An attacker can exploit this in two ways:

Scenario A: Session Fixation (pre-auth):

1. Attacker obtains a valid session ID from the application (e.g., by visiting the login page)
2. Attacker tricks the victim into using that same session ID (via URL parameter, XSS, or network-level manipulation)
3. Victim authenticates with the pre-set session ID
4. Attacker now controls an authenticated session without ever knowing the victim's credentials

Scenario B: Session Hijacking (post-auth):

1. Attacker intercepts or obtains the victim's PHPSESSID value (via network sniffing, XSS, or physical access)
2. Attacker copies the cookie value into their own browser
3. On page reload, the attacker is fully authenticated as the victim

I demonstrated Scenario B directly:

1. Logged into gidello.com with my own account
2. Observed the PHPSESSID cookie in browser DevTools → Application → Cookies
3. Opened a second browser (no active session)
4. Manually set the PHPSESSID cookie to the value from step 2
5. Refreshed the page, the second browser was now fully authenticated as my account

No credentials were required in the second browser.

Technical Analysis

Root Cause

PHP applications must call session_regenerate_id(true) immediately after verifying user credentials. Agentis did not implement this, meaning the same session token was valid before and after authentication.

// Vulnerable pattern (simplified):
session_start();
if (authenticate($username, $password)) {
    // Session ID is NOT regenerated here vulnerable
    $_SESSION['user_id'] = $user['id'];
}

Cookie Security Flags

Additionally, the PHPSESSID cookie was missing critical security flags:

The combination of missing session_regenerate_id() and absent cookie flags creates a compounded attack surface.

Proof of Concept

Note: This PoC was conducted exclusively on my own account in a production environment, using non-destructive read-only verification. No other user accounts were accessed. Immediately reported to USOM under responsible disclosure.

Step 1: Normal Login

Logged into the application. The PHPSESSID cookie was set in the browser.

Step 2: Observe Session Cookie

Cookie: PHPSESSID=<session_value>

Captured via Browser DevTools → Application → Cookies.

Step 3: Second Browser (No Session)

Opened a fresh browser profile. No active session.

Step 4: Transfer Cookie

Set the same PHPSESSID value in the second browser via DevTools.

Step 5: Result

Refreshed the page in the second browser. Full authenticated access was granted no username, no password required.

Impact

• Session Hijacking: Any user whose session ID is intercepted can be fully impersonated
• Authentication Bypass: Attacker can bypass the login form entirely if they can influence the victim's session ID pre-authentication
• Account Takeover: Full access to the victim's account including personal data, booking history, and payment information
• CVSS 8.8 High reflects the high confidentiality and integrity impact, with no privileges required for the attacker

Remediation

Primary Fix: Regenerate Session ID After Login

// login.php
session_start();

if ($auth_success) {
    session_regenerate_id(true); // true = delete old session
    $_SESSION['user_id'] = $user['id'];
}

Secondary Fix: Clean Session Before Login

session_start();
session_unset();
session_destroy();
session_start();

This ensures every visitor to the login page starts with a fresh session ID.

Logout: Fully Destroy Session

session_unset();
session_destroy();
setcookie(session_name(), '', time() - 3600, '/');

Cookie Security Flags

session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'domain'   => '.gidello.com',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Strict',
]);
session_start();

Timeline

Disclosure

This vulnerability was discovered and reported in full compliance with responsible disclosure principles. The finding was submitted exclusively to USOM (TR-CERT) the appropriate national authority before any public disclosure. No user data was accessed or exfiltrated. The PoC was limited to the researcher's own account.

References

• NVD: CVE-2025-10228
• USOM Advisory TR-25-0336
• CWE-384: Session Fixation
• CWE-1004: Sensitive Cookie Without HttpOnly Flag
• OWASP: Session Fixation

About the Author

Onurcan Genç: Offensive Security Researcher
Security+, eWPT, eWPTXv3, C-AI/MLPen
6 published CVEs via MITRE and USOM

• GitHub: github.com/onurcangnc
• LinkedIn: linkedin.com/in/onurcangenc
• Blog: blog.onurcangenc.com.tr