Admidio is an open-source user management solution. Prior to version 5.0.9, several administrative operations in Admidio's preferences module (database backup, test email, htaccess generation) fire via GET requests with no CSRF token validation. Because SameSite=Lax cookies travel with top-level GET navigations, an attacker forces an authenticated admin to trigger these actions from a malicious page. This issue has been patched in version 5.0.9.

Affected: Packagist: admidio/admidio

## Summary

Several administrative operations in Admidio's preferences module (database backup, test email, htaccess generation) fire via GET requests with no CSRF token validation. Because `SameSite=Lax` cookies travel with top-level GET navigations, an attacker forces an authenticated admin to trigger these actions from a malicious page.

## Details

In `modules/preferences.php`, the `backup`, `test_email`, and `htaccess` modes accept GET parameters with no CSRF token check:

```php // modules/preferences.php - backup mode case 'backup': // Creates full database dump and serves as download // No CSRF token validation $backupFile = $gDb->backup(); // ... sends file to client break;

case 'test_email': // Sends test email from the server // No CSRF token validation break;

case 'htaccess': // Writes .htaccess file to disk // No CSRF token validation break; ```

The `save` mode in the same file validates CSRF via `getFormObject()`, confirming the developers intended CSRF protection but did not apply it to these other modes.

Because these are GET requests, `SameSite=Lax` browsers include session cookies on top-level cross-origin navigations, making CSRF exploitation trivial.

## Proof of Concept

Simplified attacker page (`csrf.html` hosted on attacker origin):

```html <html> <body> <h1>Loading...</h1> <!-- Trigger backup creation on victim's browser --> <script>window.location = 'https://target-admidio.example.com/adm_program/modu…