CVE-2013-10075 is a critical flaw (CVSS 9.1) in Apache::Session for Perl, versions through 1.94. The File and DB_File session stores re-create deleted sessions, so a session meant to be gone can come back. The advisory suggests a DBI-based store; check for a fixed release.
What's affected
- Product: Apache::Session, a Perl session framework.
- Versions: through 1.94.
- Affected stores: Apache::Session::Store::File and Apache::Session::Store::DB_File. The advisory describes these as creating a session that does not exist.
- Fixed version: none named in the advisory I read. Check the project on CPAN or its repository.
- Workaround from the advisory: use a database store based on Apache::Session::Store::DBI.
- Weakness: CWE-672, operation on a resource after expiration or release.
- CVSS 9.1, vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
How to check if you're exposed
First find the module and its version, then find which store your code uses.
perl -MApache::Session -e 'print "$Apache::Session::VERSION\n"'
grep -rn "Apache::Session::File\|Apache::Session::DB_File\|Store::File\|Store::DB_File" /var/www /opt 2>/dev/null
Apache::Session ships several backends as separate classes, so a match on the File or DB_File names is the signal. If your code only uses the DBI based classes, the advisory's workaround already describes your setup.
What to do now
- Find every application that loads Apache::Session and note the version.
- Check which session store each one uses.
- Where File or DB_File stores are in use, move to a DBI based store, as the advisory suggests.
- Check CPAN for a release after 1.94 and read its notes before upgrading.
- Review the logic around logout and expiry. Confirm a deleted session ID no longer grants access.
- After the change, test logout in staging and confirm the old cookie is rejected.
Why it matters
Deleting a session is a security action. Users log out, administrators force a sign out, and expiry jobs clear old records. If a later request carrying the old session ID quietly creates a new session under that ID, the delete did not do its job, and data that was supposed to be gone can come back.
The record calls this a high confidentiality and integrity problem reachable over the network with no privileges, hence 9.1. The advisory dates the report to 21 February 2013 and credits the finder, Thomas Sibley. No exploitation is described and the CISA KEV flag is false.
Try it yourself
This walkthrough shows how a scan surfaces a weakness like this one and what the finding looks like.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to change anything if I use a DBI session store?
The advisory names the DBI based store as the workaround, so the File and DB_File problem it describes does not apply to that setup. Still confirm the version and read the project notes.
Is there a fixed version?
The advisory I read does not name one. Check CPAN and the project repository before making a claim to your own auditors.
Sources
Last reviewed: 19 October 2026.
