Optimizely Configured Commerce before 5

CVE-2025-22383 is an input-sanitization flaw in Optimizely Configured Commerce affecting the Contact Us workflow. In versions before 5.2.2408, user-supplied content submitted through the public contact form can be forwarded in outbound email with unfiltered HTML markup in some scenarios, meaning the payload lands in a mailbox rather than directly executing in the storefront itself.

The raw bug is real, but the practical attack chain is weaker than the label suggests. The attacker still has to reach a human recipient, rely on that recipient's mail client to render the content in a useful way, and usually push the victim into a click or trust decision; modern mail clients, secure email gateways, link rewriting, and staff workflow all add friction, so this is below a normal enterprise MEDIUM patch priority despite being internet-reachable.

Why this verdict

• Downshift for user interaction: the chain requires a recipient to open and trust the generated email, which is materially weaker than a browser-side stored XSS hitting ordinary site visitors.
• Downshift for control plane location: the payload lands in a mailbox, not in the live storefront response path, so modern SEG, Safe Links, Outlook/Gmail HTML handling, and browser controls all get chances to break the chain.
• Downshift for narrow business context: this is a niche enterprise B2B platform and a single workflow (Contact Us), not a mass-market browser-trigger bug with wormable characteristics.
• No upward pressure from threat intel: no KEV listing, no public exploitation evidence, and a very low EPSS score keep this out of urgent territory.
• Small upward pressure for exposure: the form is commonly public-facing, so unauthenticated outsiders can reach it without prior compromise; that is why this stays above IGNORE.

Why not higher?

If this were a true stored XSS executing in storefront browsers or an admin console, the score would jump fast. But here the practical chain is diluted by email rendering behavior, recipient handling, and downstream phishing defenses, so the vendor's medium label already feels generous in enterprise reality.

Why not lower?

This is still an externally reachable input channel into internal staff communications, which gives attackers a cheap path to spoofed content delivery. On organizations with weak mail rendering controls or over-trusting support workflows, it can still create real credential-theft or social-engineering risk, so completely ignoring it would be sloppy.

1. Force safe mail rendering — Ensure the mailbox receiving Contact Us submissions uses clients and policies that suppress active content and aggressively rewrite or detonate links. For a LOW verdict there is no noisgate mitigation SLA; handle this as backlog hygiene, but verify the setting during the next normal messaging-control review.
2. Gate or disable public Contact Us where nonessential — If the storefront does not actually need anonymous contact intake, disable the page/widget or place it behind stronger anti-abuse controls such as CAPTCHA, rate limiting, or a case-management front end. For LOW, fold this into routine hardening rather than emergency change activity.
3. Alert on HTML-heavy contact submissions — Add simple detections in WAF, application logging, or mail pipeline rules for Contact Us submissions containing tags, external links, or obfuscated markup. This is cheap coverage for a public form abuse path and can be deployed in the next standard monitoring sprint.
4. Harden the recipient workflow — Train the business owners of the mailbox that Contact Us messages are untrusted external content and should be handled like phishing-susceptible intake. For LOW, this belongs in the next awareness refresh and operating procedure update.

Run this on the Windows IIS host serving Configured Commerce, or on an admin workstation with read access to the deployed web root. Invoke it as powershell -ExecutionPolicy Bypass -File .\check-CVE-2025-22383.ps1 -WebRoot 'C:\inetpub\wwwroot\InsiteCommerce'; read access is enough, but local admin may be needed if the site path is restricted.

# check-CVE-2025-22383.ps1

# Purpose: best-effort local version check for Optimizely Configured Commerce before 5.2.2408

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


param(
    [Parameter(Mandatory=$true)]
    [string]$WebRoot
)

$ErrorActionPreference = 'Stop'
$fixedVersion = [version]'5.2.2408.0'

function Write-Result {
    param(
        [string]$State,
        [string]$Message,
        [int]$Code
    )
    Write-Output "$State - $Message"
    exit $Code
}

try {
    if (-not (Test-Path -LiteralPath $WebRoot)) {
        Write-Result -State 'UNKNOWN' -Message "Web root not found: $WebRoot" -Code 2
    }

    $binPath = Join-Path $WebRoot 'bin'
    if (-not (Test-Path -LiteralPath $binPath)) {
        Write-Result -State 'UNKNOWN' -Message "bin directory not found under $WebRoot" -Code 2
    }

    # Candidate assemblies seen across Configured Commerce deployments/docs.

    $candidateNames = @(
        'InsiteCommerce.Web.dll',
        'Insite.Commerce.Public.Web.dll',
        'InsiteCommerce.WebCore.dll',
        'Extensions.dll'
    )

    $found = @()
    foreach ($name in $candidateNames) {
        $matches = Get-ChildItem -LiteralPath $binPath -Filter $name -File -Recurse -ErrorAction SilentlyContinue
        if ($matches) { $found += $matches }
    }

    if (-not $found -or $found.Count -eq 0) {
        Write-Result -State 'UNKNOWN' -Message 'No candidate Configured Commerce assemblies found; verify WebRoot points to the deployed storefront.' -Code 2
    }

    $versionEvidence = @()
    foreach ($file in $found | Sort-Object FullName -Unique) {
        try {
            $fvi = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($file.FullName)
            $raw = $fvi.ProductVersion
            if (-not $raw) { $raw = $fvi.FileVersion }
            if (-not $raw) { continue }

            # Extract first numeric dotted version, normalize to four-part version.

            $m = [regex]::Match($raw, '(\d+)\.(\d+)\.(\d+)(?:\.(\d+))?')
            if (-not $m.Success) { continue }

            $parts = @($m.Groups[1].Value, $m.Groups[2].Value, $m.Groups[3].Value)
            if ($m.Groups[4].Success) { $parts += $m.Groups[4].Value } else { $parts += '0' }
            $ver = [version]($parts -join '.')

            $versionEvidence += [pscustomobject]@{
                Path = $file.FullName
                ParsedVersion = $ver
                RawVersion = $raw
            }
        }
        catch {
            continue
        }
    }

    if (-not $versionEvidence -or $versionEvidence.Count -eq 0) {
        Write-Result -State 'UNKNOWN' -Message 'Candidate assemblies were found but no parseable product versions were available.' -Code 2
    }

    # Use the highest discovered version as best evidence of deployed base code.

    $best = $versionEvidence | Sort-Object ParsedVersion -Descending | Select-Object -First 1

    if ($best.ParsedVersion -lt $fixedVersion) {
        Write-Result -State 'VULNERABLE' -Message ("Detected version {0} from {1}; fixed baseline is {2}" -f $best.ParsedVersion, $best.Path, $fixedVersion) -Code 1
    }
    else {
        Write-Result -State 'PATCHED' -Message ("Detected version {0} from {1}; meets or exceeds fixed baseline {2}" -f $best.ParsedVersion, $best.Path, $fixedVersion) -Code 0
    }
}
catch {
    Write-Result -State 'UNKNOWN' -Message $_.Exception.Message -Code 2
}

Sources

1. NVD CVE-2025-22383
2. Optimizely Configured Commerce Security Advisory COM-2024-03
3. Optimizely Contact Us page documentation
4. Optimizely Get started with Configured Commerce
5. Optimizely Go-live with Configured Commerce
6. Optimizely Configured Commerce release schedule
7. CISA Known Exploited Vulnerabilities Catalog
8. Feedly CVE page with FIRST-derived EPSS display