Fastly outage history and live incidents

What happened?

Domainr verifies domain status by connecting directly to registries. Following a routine certificate rotation, the new certificate no longer includes the client authentication component that some registries require to accept these connections. This reflects a public certificate authority (CA) change that took place earlier this year.

For the affected TLDs, Domainr can't verify status directly with the registry. It falls back to resellers, DNS, or WHOIS where available. In situations where none are available, the API returns an "unknown" or “non-authoritative” status.

The API continues to operate normally and returns successful (200) responses. Domain status data for affected TLDs may be less accurate or incomplete.

What’s next? What do I have to do?

There is no workaround, and no action is required on your part. Our Engineering team has already reached out to affected registries to partner with them on supporting and installing compatible certificates. Resolution depends on both this partnership and the completion of necessary system updates by the affected registries. Fastly Support is available to answer questions you may have and provide updates if available.

We sincerely apologize for not providing earlier notice. We will update this status page as we receive more information.

Customers with any other questions or concerns may engage with our Support team through https://support.fastly.com or by contacting your designated account management team members.

A security disclosure regarding php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) was published on October 21, 2026. In addition to implementing certain mitigations, we published a blog post about this disclosure for all customers. The post explains how we responded and shares steps you can take to protect your services. Additionally, we have published a second deep dive blog post to help you navigate and implement your own fixes.

What happened?

A set of critical vulnerabilities affecting all maintained PHP versions (php2shell) was disclosed, involving how the PHP engine handles fatal errors like memory exhaustion, timeouts, and dropped connections. To help protect customer environments, Fastly’s Security Research team, in collaboration with OpenAI and community partners, has developed a Virtual Patch for CVE-2026-109618 and CVE-2026-109619. To learn more about this vulnerability and our proactive protections, please read the blog posts linked in the reference section below.

What you can do

We strongly advise taking the following recommended actions:

• Apply Virtual Patching: Fastly Next-Gen WAF customers are strongly encouraged to apply the Virtual Patch for CVE-2026-109618 and CVE-2026-109619 across all vulnerable Edge and on-prem services. Opting in ensures you automatically receive updates as the rule is refined.

• Audit Application Servers: Identify all application servers running mod_php or php-fpm and treat all PHP applications as potentially vulnerable.

• Patch PHP Upstream: Apply official upstream patches. Patches are available in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 . For PHP 7.4, 8.0, and 8.1, or older versions, verify available patches with your Linux/package distributor.

Fastly is actively monitoring for exploitation and new variants. Please stay aware of any further updates as this situation develops.

Customers with any questions, requiring emergency WAF onboarding, or needing support may engage with our Support team through [email protected] or by contacting your designated account management team members.

Reference:

• Critical RCE Vulnerabilities Discovered in Core PHP: CVE-2026-109618 and CVE-2026-109619
  

• Fastly’s Proactive Protection for PHP2Shell, Critical React RCE CVE-2026-109618 and CVE-2026-109619

What’s changing?

Fastly is decommissioning the Milan (MXP) POP. Beginning October 26, 2026, and concluding by November 2, 2026, Fastly will gradually redirect shield traffic for the mxp-milan-it shield location to our Milan (BGY) POP.

During this migration period, Compute services that reference mxp-milan-it will be redirected to bgy-milan-it. After the migration period ends, mxp-milan-it will no longer be a valid shield location, and Compute services that still reference it will get an error when creating the shield. How your service behaves after that depends on how your code handles that error.

What’s next? What do I have to do?

Compute services

If your Compute service uses mxp-milan-it as a shield location, update it to bgy-milan-it before November 2, 2026. We recommend making this change as soon as possible.

1. Find every place your service sets mxp-milan-it as a shield location, including shield names in your code and any values your code loads from a config store.

2. Replace mxp-milan-it with bgy-milan-it.

3. If you changed your code, build and deploy a new version of your service. If the shield name comes from a config store, update the stored value.

4. If you manage your service with Terraform or other automation, update the shield name there too, so a later deployment doesn’t restore mxp-milan-it.

For details on Compute services, see our Shielding documentation.

Varnish Configuration Language (VCL) services

If your VCL service uses standard shielding configuration, no action is required. Fastly will redirect your shield traffic to Milan (BGY) automatically.

If your custom VCL or VCL snippets reference mxp-milan-it or the MXP POP in your own logic, update those references to bgy-milan-it before November 2, 2026.

You can also switch your shield location to “bgy-milan-it” yourself in the Fastly control panel. See our Shielding documentation.

When you switch to bgy-milan-it, your origin servers may see a temporary increase in requests while the cache fills in Milan (BGY).

If you have any questions, please contact our Support team through https://support.fastly.com or your account team.

Varnish Configuration Language (VCL) services using standard shielding configurations remain unaffected and no action is required.