CVE-2013-10075: Apache::Session Auth Bypass Vulnerability

CVE-2013-10075 Overview

CVE-2013-10075 affects the Apache::Session Perl module through version 1.94. The module re-creates deleted sessions when using the Apache::Session::Store::File and Apache::Session::Store::DB_File storage backends. An attacker who knows or guesses a previously-deleted session identifier can cause the session to be revived, potentially restoring data that was intended to be destroyed. The flaw maps to CWE-672: Operation on a Resource after Expiration or Release and is exploitable over the network without authentication or user interaction.

Critical Impact
Deleted sessions can be revived by clients that present an expired session ID, undermining logout, session expiration, and data deletion guarantees in Perl applications relying on Apache::Session.

Affected Products

Chorny Apache::Session for Perl, all versions through 1.94
Applications using the Apache::Session::Store::File backend
Applications using the Apache::Session::Store::DB_File backend

Discovery Timeline

2026-05-08 - CVE-2013-10075 published to the National Vulnerability Database
2026-05-08 - Public discussion on the OpenWall oss-security mailing list
2026-05-08 - Last updated in NVD database

Technical Details for CVE-2013-10075

Vulnerability Analysis

The Apache::Session module provides persistent session storage for Perl web applications. When a session is deleted, the calling application expects the corresponding record and any data it contained to be permanently removed. In versions through 1.94, the Apache::Session::Store::File and Apache::Session::Store::DB_File backends silently create a new on-disk session entry whenever a request references a session identifier that does not exist. A request supplying a previously-deleted session ID therefore causes the store to instantiate a fresh session under that same identifier instead of rejecting the request.

This behavior breaks the application's session lifecycle assumptions. Logout operations, administrative session purges, and timeout-driven deletions no longer guarantee that the session ID becomes unusable. The impact is most severe when application logic re-populates the revived session with cached data, user attributes, or authorization state that the developer believed had been discarded.

Root Cause

The storage backends do not distinguish between "create a brand-new session" and "load an existing session." Both operations resolve to a write path that materializes the session file or DB_File record on demand. There is no check that the supplied identifier corresponds to a session that was previously deleted, and no negative cache of revoked identifiers is maintained.

Attack Vector

An attacker captures or retains a session cookie issued by a vulnerable application. After the legitimate user logs out, or after an administrator deletes the session server-side, the attacker replays the same identifier in a new request. The Perl backend creates a session record keyed by that identifier, and the application treats the request as belonging to a valid, newly-initialized session. Where application code stores recoverable data tied to the session ID, the attacker may regain access to information that was intended to be purged. Refer to CPAN Bug Report #83525 and the OpenWall OSS Security Discussion for the upstream technical analysis.

Detection Methods for CVE-2013-10075

Indicators of Compromise

Session files appearing in the Apache::Session::Store::File directory with identifiers that were previously logged as deleted
DB_File session database entries re-appearing under identifiers that the application audit log marks as terminated
Authentication or activity events tied to a session ID after a corresponding logout event for the same ID

Detection Strategies

Correlate web server access logs against application logout and session-delete events to flag any request that presents a session cookie after its server-side deletion
Add instrumentation around Apache::Session::Store::File and Apache::Session::Store::DB_File write paths to log when a session file is created versus loaded
Review file system audit logs for the session store directory to identify session files that are recreated shortly after deletion

Monitoring Recommendations

Alert when the same session identifier is observed in HTTP traffic both before and after a logout event for that session
Monitor the session store directory for file creation events that are not preceded by a fresh login transaction
Track the version of the Apache::Session Perl module deployed on application servers and flag any host still running 1.94 or earlier

How to Mitigate CVE-2013-10075

Immediate Actions Required

Inventory all Perl applications that depend on Apache::Session and identify those using the File or DB_File store backends
Upgrade Apache::Session to a fixed release above 1.94 on every affected host
Invalidate and rotate all currently active session identifiers after the upgrade to ensure no revived sessions persist

Patch Information

Apply the fix tracked in CPAN Bug Report #83525. Updated releases of Apache::Session change the store behavior so that requests for non-existent session identifiers no longer cause new sessions to be materialized.

Workarounds

Switch to a different session store backend that performs an explicit existence check before loading, until upgrade is possible
Wrap session loading in application code with an existence check against a separately-maintained list of valid session IDs
Maintain a server-side revocation list of deleted session identifiers and reject any inbound request that presents a revoked ID
Shorten session cookie lifetimes and bind sessions to client attributes such as IP address or user agent to reduce the replay window

bash

# Upgrade Apache::Session via cpanm to a patched release
cpanm Apache::Session

# Verify the installed version is above 1.94
perl -MApache::Session -e 'print $Apache::Session::VERSION, "\n"'