As an infrastructure provider for businesses, IXCDN believes that dependable security comes from both rigorous internal engineering and responsible external scrutiny. We respect and appreciate white-hat and red-team researchers who work within authorized boundaries and disclose risks responsibly.

On October 13, 2026, an external security research team conducted a defensive security assessment of IXCDN and reported two configuration-boundary issues that could be chained together. Our security and engineering teams immediately began incident response, isolated the relevant test accounts and configurations, audited the complete set of applicable logs, and deployed systemic hardening across account, domain-ownership, and certificate-publishing workflows.

What happened

Following an environment policy change, the email-verification policy and the account’s persisted state were not fully aligned. A small number of self-service accounts were incorrectly recorded as usable before completing email verification, and enforcement was not consistent across every login and session path.

Using this as an entry point, the researchers found that our DNS, CDN, and static-site configuration surfaces had historically maintained domain ownership separately rather than enforcing one non-bypassable namespace boundary at the lowest layer. As a result, an unverified account could create pending records involving an IXCDN-owned domain or subdomain. Those records remained pending and did not enter active DNS, CDN, site-publishing, or certificate-issuance configuration. Allowing an ordinary tenant to create such records was nevertheless a security-boundary gap that should not have existed.

Scope and impact

The researchers stopped at a proof of concept and reported their findings promptly. The domain records did not pass ownership verification, and the 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 also found no evidence that customer DNS records or CDN routes were changed.

During the same review period, www.ixcdn.com briefly presented a mismatched certificate. Our investigation confirmed that this was unrelated to the red-team assessment or the pending domain records. It was caused by a separate certificate-renewal issue that incorrectly split the apex and www hostname into 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. We include this clarification to avoid incorrectly attributing two issues that occurred close together in time.

Root cause

The issues identified by the red team were not the result of a single missing validation check. Two security assumptions had not been closed into one consistent control path: email verification had different meanings in account state and request-time authentication, and domain-ownership checks were distributed across separate product surfaces without one underlying boundary covering IXCDN-owned domains and their subdomains.

Each issue had limited impact in isolation. Together, they exposed a design gap in the protection of platform-owned assets and in the boundary between pending and publishable configuration. We take responsibility for that gap.

Remediation completed

We went beyond removing the anomalous records or disabling the test accounts. We consolidated the relevant states and authorization boundaries at the lowest practical layers:

  1. A single verified-account lifecycle. Self-service accounts now remain pending until email verification is complete and become usable only after successful verification. Login, dynamic sessions, API keys, and previously issued sessions all perform live account and tenant status checks. Existing credentials become invalid immediately 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 domain 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, its parent, or its children are serialized and checked in the same database transaction. Pending and nonconforming legacy records cannot enter DNS, routing, or site-publishing configuration.
  3. Independent certificate remediation and a broader review. By default, a single certificate now covers both the apex and its www hostname, and renewal no longer splits the pair. Before publication, the certificate’s SANs must cover the exact target hostname. We have reconciled existing certificate groups and reviewed related boundary checks, alerting, and audit paths horizontally. This work addresses the separate renewal issue found during the review; it was not an impact caused by the red-team assessment.

These core remediations are deployed. We will continue to monitor operational and audit data. If our continuing review produces new facts that materially change this notice, we will update it.

Thanks and security contact

This issue was identified and closed early in large part because the research team carried out a high-quality, thoughtful, and restrained assessment. Professional and responsible security research makes our defenses stronger and helps protect everyone who trusts IXCDN. We offer the team our sincere thanks.

We have prepared a dedicated recognition award for the researchers who identified these issues. If you are part of the team, please contact us at noc@wlstack.com.

IXCDN, a Wulian Network service, welcomes responsible research from security professionals worldwide when conducted in accordance with our security testing policy. We look forward to working with the security community to build a more dependable infrastructure security ecosystem.

— IXCDN Security Team

October 15, 2026