Optimizely Configured Commerce before 5

CVE-2025-22385 affects Optimizely Configured Commerce before 5.2.2408. The flaw is simple: the B2B application would create newly requested accounts without requiring email confirmation first. That means an unauthenticated remote user can automate account signups at scale, creating junk accounts or accounts tied to third-party email addresses. The vendor frames the likely impact correctly: database growth, operational clutter, and unsolicited storefront accounts rather than data theft or privilege gain.

The vendor's MEDIUM 5.9 baseline is slightly generous in real enterprise conditions. Yes, the bug is network-reachable and unauthenticated, but the blast radius is mostly storage/ops noise, and exploitation usually depends on a public self-registration flow actually being enabled on the storefront. No evidence surfaced of KEV listing, active exploitation, or a public weaponized PoC. For most 10,000-host environments this is a cleanup-and-upgrade issue, not an incident-response issue.

Why this verdict

• Vendor baseline starts at 5.9 MEDIUM because the bug is remote and unauthenticated, but that overstates the business impact for most deployments.
• Requires a public registration path — if the storefront does not expose anonymous signup, the attack chain dies before it starts. That implies a much smaller reachable population than a typical edge-service CVE.
• Impact is mostly ops pain, not compromise — the published CVSS already shows no confidentiality or integrity loss, and the vendor advisory describes database/storage pressure and unsolicited account creation rather than takeover.
• Modern controls should catch volume abuse — WAF, CDN bot controls, rate limits, and registration anomaly monitoring all apply here and materially raise attacker effort.
• Threat telemetry is cold — no KEV entry, no reviewed evidence of in-the-wild exploitation, and no obvious public PoC ecosystem push this downward again.

Why not higher?

This is not a perimeter-breaker, auth bypass to sensitive data, or privilege-escalation chain. The attacker gets nuisance account creation and possible slow-burn storage pressure, not immediate tenant compromise. Requiring public self-registration also cuts down the exposed population versus always-on admin or edge services.

Why not lower?

It is still remotely reachable on some public storefronts and requires no credentials. In organizations with open signup and weak anti-automation, mass account creation can create tangible operational cost, user confusion, and avoidable support load.

1. Rate-limit registration — Apply CDN/WAF throttling and bot controls to account-creation endpoints to make mass signup economically unattractive. For a LOW verdict there is no SLA (treat as backlog hygiene), but if the storefront is public you should still deploy this during the next normal change window.
2. Disable anonymous signup where unnecessary — If your business model does not need self-service registration, turn it off or gate it behind approved customer onboarding. That removes the primary prerequisite for exploitation and can be done ahead of the eventual patch.
3. Alert on signup spikes — Create detections for bursts of account creation, repeated POSTs to registration endpoints, and large numbers of dormant new accounts. This helps catch abuse early and limits the only realistic impact path.
4. Prune dormant junk accounts — Review for no-activity accounts and clusters created in very small time windows, matching the vendor's mitigation guidance. Use this as routine hygiene until the platform is upgraded.

Run this on an auditor workstation, CI job, or admin jump box where Python 3 is available. Invoke it as python verify_cve_2025_22385.py 5.2.2407 or feed versions from CMDB/SBOM export; no elevated privileges are required because this script validates the known deployed Configured Commerce version, not live exploitability.

#!/usr/bin/env python3
# verify_cve_2025_22385.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / bad input
#
# Usage:
#   python verify_cve_2025_22385.py 5.2.2407
#   python verify_cve_2025_22385.py 5.2.2408
#
# This script compares an observed Optimizely Configured Commerce version
# against the fixed version for CVE-2025-22385.

import re
import sys

FIXED = (5, 2, 2408)


def parse_version(v):
    if not v:
        return None
    # Accept forms like 5.2.2408, 5.2.2408.123, 5.2.2408+sts, 5.2.2408+lts
    m = re.match(r'^\s*(\d+)\.(\d+)\.(\d+)(?:[.+-].*)?\s*$', v)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN: provide exactly one version argument, e.g. 5.2.2408')
        sys.exit(2)

    raw = sys.argv[1]
    parsed = parse_version(raw)
    if parsed is None:
        print(f'UNKNOWN: unable to parse version: {raw}')
        sys.exit(2)

    if parsed < FIXED:
        print(f'VULNERABLE: {raw} is earlier than fixed version 5.2.2408')
        sys.exit(1)
    else:
        print(f'PATCHED: {raw} is at or above fixed version 5.2.2408')
        sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. Optimizely advisory COM-2024-05
2. NVD CVE-2025-22385
3. Optimizely Configured Commerce release schedule
4. Optimizely go-live guidance
5. Optimizely install Configured Commerce + CMS 12
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview