Postmortem: Incorrect "Cookies Not Enabled" Messaging Blocking Website Access

Incident Date: June 5–6, 2026
Severity: Major Outage
Status: Resolved

Summary

Between June 5, 2026, at 5:00 PM and June 6, 2026, at 7:26 PM, users attempting to access websites hosted on the MyForum platform experienced widespread access failures. Affected visitors were incorrectly presented with a "Cookies are not enabled" message despite having cookies enabled in their browsers.

The issue impacted MyForum, MyForum SSO, MyForum Web, the deprecated Dev SDK, and several related services. During the incident, many websites became inaccessible, preventing users from accessing forums and associated web applications.

The incident was traced to an external DDoS attack affecting our hosting provider's network infrastructure and browser verification systems. No customer data was compromised.

Impact

Customer Impact

• Visitors were unable to access affected websites.

• Users were redirected through a browser verification sequence before ultimately reaching an erroneous "Cookies are not enabled" page.

• Login and authentication flows relying on MyForum SSO were disrupted.

• Community forums and hosted applications experienced extended downtime.

Services Affected

• MyForum

• MyForum SSO

• MyForum Web

• Dev SDK on MyForum (deprecated)

• Related services utilizing the affected hosting infrastructure

Duration

• Major service disruption: June 5, 2026, 5:00 PM – June 6, 2026, 7:26 PM

• Full resolution confirmed: June 6, 2026, 10:23 PM

Timeline

June 5, 2026

5:00 PM

• Reports begin arriving that websites are displaying a "Cookies are not enabled" message.

• Investigation initiated.

• Initial assessment identifies issue originating from hosting provider infrastructure.

June 6, 2026

10:29 AM

• Incident officially escalated for active investigation.

10:30 AM

• Network administration team engaged.

• Communication issued regarding extended response times due to after-hours staffing.

10:47 AM

• Additional diagnostics completed.

• Confirmed issue affects multiple domains across the hosting network.

• Browser redirects observed through verification endpoints (?i=1, ?i=2, ?i=3) before redirecting users to a cookie error page.

• Testing confirmed issue occurs across multiple browsers, private browsing sessions, and independent websites.

7:25 PM

• Engineering identifies corrective action and begins deployment.

7:26 PM

• Fix implemented.

• Services begin recovering.

• Monitoring phase initiated.

10:23 PM

• Hosting provider confirms the underlying DDoS attack has subsided.

• Incident resolved.

• Services operating normally.

Root Cause

The incident was caused by a DDoS attack targeting infrastructure operated by our web hosting provider.

The attack interfered with the provider's browser verification and cookie validation mechanisms. As a result, legitimate users were incorrectly classified as failing browser validation checks and were redirected to a generic "Cookies are not enabled" page.

Because the issue occurred within the provider's network protection systems rather than within MyForum applications themselves, multiple independent domains and services were affected simultaneously.

Resolution

The hosting provider implemented mitigations to address the attack and restore normal verification behavior. Once the mitigation was deployed, websites began serving content normally and authentication systems resumed operation.

Users who continued to experience issues after service restoration were advised to:

1. Clear browser cache and cookies.

2. Open the website in a new browser tab or window.

3. Report affected URLs if problems persisted.

What Went Well

• The issue was quickly identified as external to customer websites.

• Cross-domain diagnostics helped isolate the problem to provider infrastructure.

• Regular status updates were communicated throughout the incident.

• Service functionality returned immediately following mitigation deployment.

What Could Be Improved

• Earlier visibility into provider-side verification failures.

• Faster escalation paths for after-hours infrastructure incidents.

• Improved monitoring for abnormal browser verification redirects.

• More detailed customer-facing diagnostics during the investigation phase.

Preventive Actions

To reduce the likelihood and impact of similar incidents in the future, we will:

• Implement additional monitoring for unexpected redirect patterns and verification failures.

• Improve alerting around authentication and browser validation anomalies.

• Review escalation procedures with infrastructure providers.

• Evaluate additional redundancy and mitigation options for externally hosted services.

• Enhance incident communication templates for provider-related outages.

Closing

We understand that this outage disrupted access to community forums and hosted services, and we sincerely apologize for the inconvenience. We appreciate the patience of our users while our team and hosting provider worked to identify and resolve the issue.

We will continue to review this incident and implement improvements to strengthen reliability and incident response processes going forward.

From iFastNet's team:

Hey all,

Back with another update.

This issue was not caused by a bug in the system (Yay to no “ship it on Friday and leave”!) but rather a DDoS attack with some weird effects.

The attack has subsided as I write this message, so sites should begin working again (Although if the attacker continues their actions it could happen again).

To answer the question of does the team work weekends - yes. I believe they operate with limited numbers, but there are staff on site to address issues.

If your site is not working and displays the cookie message as described by so many here, please do the following:

• Clear your cache and cookies

• Load your site in a new tab/window

If it still does not work, please post your URL below this post.

Thank you for your patience with this issue!

We checked Network (Fetch/XHR) They were pretty normal.

Additional diagnostic information

We can confirm this issue is affecting multiple domains hosted on the iFastNet network, including:

1. myforum.mydiscussion.net

Observed behavior:

👉 Visiting the website loads normally at first.

👉 The browser is automatically redirected through:

• /?i=1

• /?i=2

• /?i=3

👉 After the third redirect, the site is redirected to:

• https://sv101.ifastnet.com/cookies.html

The “Cookies are not enabled” page appears even though cookies are enabled.

Diagnostics performed:

• Tested on multiple browsers.

• Tested in Incognito/Private mode.

• Disabled browser extensions.

• Cleared cookies/cache.

• Issue affects all hosted subdomains, not a single website.

• Network tab shows normal page loads followed by the automatic ?i=1 → ?i=2 → ?i=3 verification sequence and then a redirect to cookies.html.

Conclusion:

The issue appears to occur within the iFastNet browser verification or cookie validation system rather than the hosted website itself, since multiple independent domains and subdomains are affected in the same way.

The network administration team is aware of the issue. Please note that this team is located in Europe where it is currently outside normal working hours. Therefore, it may take slightly longer before a resolution is reached.

Thank you for your patience!