CVE-2025-24856

Executive Summary

CVE-2025-24856 is a pre-hijacking vulnerability in the TYPO3 OpenID Connect Authentication (oidc) extension prior to version 4.0.0. The flaw resides in the account linking logic, allowing an attacker to pre-register a frontend user account with a victim’s anticipated email address. When the victim subsequently authenticates via OIDC, the extension links the victim’s identity to the attacker-controlled account, resulting in an Account Takeover (ATO). The attack requires the attacker to know the victim’s email address in advance and have the ability to register a frontend user account before the victim’s first OIDC login. The IDP must also return an email field containing the victim’s email address. The CVSS score is 4.2 (Medium), with a low EPSS probability of 0.0%, indicating limited exploitation in the wild. No public exploit code or PoC is currently available.

Supply Chain & Package Security

This vulnerability affects the TYPO3 ecosystem via the third-party oidc extension. TYPO3 extensions are distributed through the TYPO3 Extension Repository (TER) and Composer. The vulnerable package is typo3-ter/oidc (or friendsoftypo3/oidc). Users should verify their extension version and update to 4.0.0 or later. No malicious packages have been reported in relation to this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 4.2 (Medium)
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
• Attack Vector: Network (AV:N)
• Attack Complexity: High (AC:H) – requires attacker to know victim’s email and pre-register an account.
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) – limited to the victim’s OIDC-linked account data.
• Integrity Impact: Low (I:L) – attacker can modify account data.
• Availability Impact: None (A:N)

Threat Level: Medium. The attack is not trivial due to the prerequisite of knowing the victim’s email and the ability to pre-register. However, if successful, it leads to full account takeover within the TYPO3 frontend.

Deep Dive & Mechanics

The vulnerability is in the account linking logic of the oidc extension. When a user authenticates via OpenID Connect for the first time, the extension checks if a local frontend user account exists with the email address returned by the IDP. If such an account exists, the extension links the OIDC identity to that account. An attacker can exploit this by:

1. Anticipating the victim’s email address (e.g., victim@example.com).
2. Registering a frontend user account on the TYPO3 site using that email address before the victim’s first OIDC login.
3. Waiting for the victim to log in via OIDC. The IDP returns the email victim@example.com.
4. The extension finds the attacker-created account and links the victim’s OIDC identity to it.
5. The attacker can then log in using the attacker’s own OIDC credentials and access the victim’s linked account.

The flaw is that the extension does not verify whether the local account was created by the same user or if it is a pre-existing account. It simply matches on email.

Vulnerable vs. Patched Code

Vulnerable Code (oidc < 4.0.0): The account linking logic likely resembles:

// Vulnerable: Links to any existing account with matching email
$user = $GLOBALS['TYPO3_DB']->exec_SELECTgetSingleRow(
    '*',
    'fe_users',
    'email = ' . $GLOBALS['TYPO3_DB']->fullQuoteStr($oidcEmail, 'fe_users')
);
if ($user) {
    // Link OIDC identity to this user
    $this->linkOidcToUser($oidcToken, $user['uid']);
}

Patched Code (oidc >= 4.0.0): The patched version likely adds a check to ensure the local account was created by the same OIDC provider or is a fresh account:

// Patched: Only link if no existing OIDC-linked account or if account was created by this OIDC provider
$user = $GLOBALS['TYPO3_DB']->exec_SELECTgetSingleRow(
    '*',
    'fe_users',
    'email = ' . $GLOBALS['TYPO3_DB']->fullQuoteStr($oidcEmail, 'fe_users') .
    ' AND (oidc_provider = ' . $GLOBALS['TYPO3_DB']->fullQuoteStr($provider, 'fe_users') .
    ' OR oidc_provider IS NULL)'
);
if ($user) {
    // Only link if the account is not already linked to another OIDC provider
    $this->linkOidcToUser($oidcToken, $user['uid']);
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Knowledge of the victim’s email address.
• Ability to register a frontend user account on the TYPO3 site (e.g., via a registration form).
• The IDP must return an email claim.

Steps:

1. Pre-register account: Use the TYPO3 frontend registration form to create an account with the victim’s email (e.g., victim@example.com). Set a password you know.
2. Wait for victim: The victim logs in via OIDC (e.g., Google, Microsoft).
3. Takeover: The victim’s OIDC identity is linked to the attacker-created account. The attacker can now log in using the attacker’s OIDC credentials and access the victim’s account.

Lab Setup:

• Install TYPO3 v12 with oidc extension < 4.0.0.
• Configure an OIDC provider (e.g., Keycloak or Google).
• Create a test victim email.
• Register a frontend user with that email.
• Simulate victim OIDC login.
• Verify attacker can access the account.

Blue Team

Detection:

• Monitor for multiple frontend user registrations with the same email address.
• Alert on OIDC logins where the linked local account was created shortly before the OIDC login.
• Check for accounts with OIDC links that were created via frontend registration (not via OIDC).

Hunting:

• Query the fe_users table for accounts where oidc_provider is set but the account was created via a non-OIDC method (e.g., crdate before the first OIDC login).
• Look for patterns: same email, different creation timestamps.

Indicators of Compromise (IOCs)

• Network: OIDC authentication requests followed by account access from a different IP.
• Host: fe_users table entries with oidc_provider set but crdate significantly earlier than the first OIDC login timestamp.
• Logs: TYPO3 system log entries showing OIDC login linked to an existing account that was created via frontend registration.

Detection Engineering

YARA Rule

rule CVE_2025_24856_OIDC_AccountLinking {
    meta:
        description = "Detects vulnerable account linking logic in TYPO3 oidc extension"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-24856"
    strings:
        $vuln_func = "exec_SELECTgetSingleRow" nocase
        $vuln_query = "email = " nocase
        $vuln_link = "linkOidcToUser" nocase
    condition:
        all of them
}

Sigma Rule

title: TYPO3 OIDC Pre-Hijacking Account Takeover
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential pre-hijacking via OIDC account linking in TYPO3
author: Valters IT
date: 2025-04-10
logsource:
    product: typo3
    service: system_log
detection:
    selection:
        event: "OIDC login"
        details|contains: "linked to existing user"
    condition: selection
falsepositives:
    - Legitimate account linking for existing users
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-24856 TYPO3 OIDC Pre-Hijacking Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/typo3/"; http_uri; content:"oidc"; http_uri; content:"login"; http_uri; pcre:"/email=[^&]+/i"; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade the oidc extension to version 4.0.0 or later.
• If upgrade is not possible, disable the OIDC extension temporarily.

Long-term:

• Implement additional verification: require email confirmation before linking OIDC accounts.
• Monitor for anomalous account registrations and OIDC logins.
• Use Web Application Firewall (WAF) rules to block repeated registration attempts with the same email.

Workaround:

• Restrict frontend user registration to only allow registration via OIDC (disable manual registration).
• Implement CAPTCHA on registration forms to slow automated pre-registration.

Valters IT
DevSecOps & Cyber Threat Intelligence