admidio/admidio · Admidio has CSRF on Admin Preferences that Triggers Unauthorized Backup, .htaccess Write, and Email Send
Affects admidio/admidioSource GCVE Database
Not known to be exploited · CVSS 3.5 Low : upgrade to 5.0.9 when convenient.
Data as of 27 Oct 2026, 00:07 UTC
- Patch
- Available – fixed in 5.0.9
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 7 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade admidio/admidio to 5.0.9.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Packagistadmidio/admidio | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
## 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/modules/preferences.php?mode=backup';</script> </body> </html> ``` When an administrator visits this page, the browser navigates to the Admidio backup URL with full session cookies. The server generates a database dump and serves it as a download to the victim's browser. Note: the backup downloads to the victim's machine, not to the attacker. The attacker cannot read the response cross-origin. For `htaccess` mode, the CSRF overwrites the `.htaccess` file on the server, disrupting the application. For `test_email` mode, it triggers email sends from the server, which an attacker can abuse for spam or to probe internal email infrastructure. ## Impact An attacker tricks an Admidio administrator into visiting a malicious page that triggers state-changing operations on the server: - **Backup creation**: forces the server to generate a full database dump. The backup downloads to the victim's browser, not to the attacker. However, repeated backup triggers can cause disk I/O and storage pressure on the server. - **htaccess modification**: overwrites the server's `.htaccess` file, breaking URL routing or disabling security headers. - **Test email**: fires email sends from the server, usable as a spam relay or to probe internal mail configuration. The core issue is that state-changing operations run via unprotected GET requests. The victim only needs to visit a single attacker-controlled page while logged in. ## Recommended Fix 1. Change `backup`, `test_email`, and `htaccess` operations to require POST requests. 2. Add CSRF token validation using the existing `getFormObject()` mechanism. 3. As defense in depth, set `SameSite=Strict` on session cookies or add a confirmation step for destructive operations like database backup. --- *Found by [aisafe.io](https://aisafe.io)*