On October 13, 2026, an external security research team reported two IXCDN configuration-boundary issues that could be chained together. We isolated the relevant test accounts and configurations, reviewed the applicable logs, and fixed the account-verification, domain-ownership and certificate-publishing paths.

This notice describes the facts confirmed as of October 15, 2026. We will update it if later review produces information that changes these conclusions.

Sequence of events

After an environment policy change, the email-verification policy and persisted account state were not aligned. A small number of self-service accounts were incorrectly recorded as usable before completing verification. Login and session paths did not enforce that state consistently.

The researchers then found that DNS, CDN and static-site entry points maintained domain ownership separately instead of sharing one non-bypassable namespace boundary. An unverified account could therefore create pending records involving an IXCDN-owned domain or subdomain. The records did not pass verification or enter active DNS, CDN, site-publishing or certificate-issuance configuration. Allowing an ordinary tenant to create them was still a security-boundary gap.

Scope and impact

The researchers stopped at a proof of concept. The domain records did not pass ownership verification, and the test account did not gain permission to change existing customer configurations.

Our log and configuration review found no evidence that customer accounts or business data were accessed, exported or modified. We found no evidence that customer DNS records or CDN routes were changed.

During the review, www.ixcdn.com briefly presented a mismatched certificate. This was unrelated to the proof of concept and pending records. A separate renewal process had incorrectly split the apex and www hostname across two certificates. Traffic was not redirected to an origin controlled by the research team. We restored the correct certificate and reconciled the existing certificate groups.

Root cause

The issue was not one missing validation check. The same security state had different meanings at different layers: account state and request-time authentication interpreted email verification differently, while product entry points made separate domain-ownership decisions without one underlying boundary for IXCDN-owned domains and their subdomains.

Together, these conditions exposed a design gap in platform-owned asset protection and in the boundary between pending and publishable configuration.

Remediation completed

The remediation covers the underlying state and authorization boundaries, not only the test accounts and pending records:

  1. One verified-account lifecycle. Self-service accounts remain pending until email verification completes. Login, dynamic sessions, API keys and previously issued sessions all check current account and tenant status. Existing credentials become invalid when an account is suspended, disabled or no longer satisfies verification requirements. Security-sensitive settings are also covered by baseline validation and configuration-drift review.
  2. One domain-ownership boundary across products. DNS, CDN and static sites now share the same namespace and ownership rules. A verified apex protects its subdomains; IXCDN-owned domains are in a system-reserved scope that ordinary tenants cannot change; and concurrent claims involving an exact hostname, parent or child are serialized in one database transaction. Pending and nonconforming legacy records cannot enter DNS, routing or site-publishing configuration.
  3. A separate certificate-renewal fix. One certificate now covers both the apex and its www hostname by default, and renewal no longer splits them. Before publication, certificate SANs must cover the exact target hostname. Existing certificate groups have been reconciled, and related boundary checks, alerting and audit paths have been reviewed. This work addresses the separate renewal issue; it was not an impact of the red-team assessment.

These fixes are deployed. We continue to review operational and audit data.

Security contact and acknowledgment

We thank the researchers for limiting the assessment and providing reproducible findings promptly. A dedicated recognition award has been prepared; members of the team can contact noc@wlstack.com.

IXCDN accepts responsible disclosures conducted under its security testing policy. Reports should include scope, reproduction steps and the minimum request records required to investigate. Researchers should not access or retain data outside their test accounts.

— IXCDN Security Team

October 15, 2026