GHSA-r9vc-jfmh-6j48

TYPO3 frontend login vulnerable to Session Fixation

High Packagist

Severity: 7.1 / 10; High · CVSS 3.1
Exploit chance (EPSS): —; No score published
Known exploited: No; Not in CISA's catalog
Weakness: CWE-384 Session Fixation
Fix: 6.2.14; Upgrade typo3/cms to this version or later

Description

It has been discovered that TYPO3 is susceptible to session fixation. If a user authenticates while anonymous session data is present, the session id is not changed. This makes it possible for attackers to generate a valid session id, trick users into using this session id (e.g. by leveraging a different Cross-Site Scripting vulnerability) and then maybe getting access to an authenticated session.

Affected versions

Packagist

Package	Vulnerable	Fixed in
typo3/cms	`>= 6.2.0, < 6.2.14`	`6.2.14`
typo3/cms	`>= 7.0.0, < 7.3.1`	`7.3.1`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

typo3/cms Packagist → `6.2.14`

composer

composer require typo3/cms:^6.2.14

Severity breakdown

CVSS 3.1 7.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: Required
Scope: Unchanged
Confidentiality: Low
Integrity: High
Availability: None

Weakness

CWE-384: Session Fixation

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

How to prevent it

Architecture and Design: Invalidate any existing session identifiers prior to authorizing a new user session.
Architecture and Design: For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

References

Packages

github.com/TYPO3/typo3

Timeline

May 30, 2024 Published
Dec 5, 2024 Last updated by the source

Advisory	Severity	Why it's related
GHSA-f3wf-q4fj-3gxf TYPO3 Denial of Service in Online Media Asset Handling	Medium	Also affects typo3/cms
GHSA-6487-3qvg-8px9 TYPO3 Information Disclosure in Install Tool	Medium	Also affects typo3/cms
GHSA-f777-f784-36gm TYPO3 Security Misconfiguration in Install Tool Cookie	High	Also affects typo3/cms
GHSA-2rcw-9hrm-8q7q TYPO3 Cross-Site Scripting in Frontend User Login	Medium	Also affects typo3/cms
GHSA-7q33-hxwj-7p8v TYPO3 Cross-Site Scripting in Backend Modal Component	Medium	Also affects typo3/cms
GHSA-8m6j-p5jv-v69w TYPO3 Cross-Site Scripting in Online Media Asset Rendering	Medium	Also affects typo3/cms
GHSA-8h4m-r4wm-xj7r TYPO3 Arbitrary Code Execution via File List Module	High	Also affects typo3/cms
GHSA-g585-crjf-vhwq TYPO3 Denial of Service in Frontend Record Registration	High	Also affects typo3/cms

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor