Skip to main content
CVE-2026-41663VulnerabilityPublished Updated

admidio/admidio · Admidio has CSRF on Admin Preferences that Triggers Unauthorized Backup, .htaccess Write, and Email Send

Affects admidio/admidioSource GCVE Database

0
Authoritative record:CVE-2026-41663· Low 3.5

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

CVSS 3.1 base score
3.5Low
How severe the flaw is on the 0–10 CVSS scale.
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:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 7 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
Packagistadmidio/admidioAffected
  • <5.0.9
Fixed in
  • 5.0.9

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)*

References

Community reviews

Loading reviews…