You Are Safe — A Note About the Canvas Breach

You have probably seen the headlines about the Canvas breach this week. We are writing to tell you, plainly, that your Cubite-hosted Open edX environment is not affected, to explain exactly why, and to share what we are actively doing on your environment between now and the May 12 ransom deadline.

What happened (the 60-second version)

On April 30, 2026, attackers gained initial access to Instructure, the company that runs Canvas. Instructure confirmed the incident on May 1. On May 7 at roughly 4:41 PM, the criminal group ShinyHunters defaced Canvas login pages worldwide and Instructure took Canvas into maintenance mode. The group has set a ransom deadline of end of day, May 12, 2026.

ShinyHunters claims to have stolen roughly 275 million records from approximately 9,000 organizations, including names, email addresses, user/student ID numbers, and messages between users, per TIME and Wikipedia's incident page. Instructure has stated that there is no evidence that passwords, dates of birth, government identifiers, or financial information were exposed.

According to threat intelligence from Mandiant, reported by TechRadar, ShinyHunters' typical entry vector is voice phishing combined with fake, company-branded login pages that harvest employee credentials at the targeted vendor. We mention this because it shapes part of our response.

Why your Cubite-hosted environment is not affected

Three reasons, in plain terms.

1. Architectural isolation. Every Cubite managed-hosting customer runs on dedicated, isolated infrastructure: a separate network, a separate application database, separate object storage, and separate encryption keys. There is no shared application database across customers. A compromise of any other Cubite customer environment cannot cross into yours, because there is no shared surface to cross from.

2. We do not share infrastructure with Instructure. Cubite does not run on Instructure systems, does not integrate with Canvas at the platform layer, and does not share an admin plane, identity provider, or operational tooling with Instructure. The Canvas attack surface and your Open edX environment are entirely separate systems, operated by entirely separate companies, on entirely separate clouds. A compromise at Instructure has no path into your environment.

3. Open edX runs its own security pipeline, separate from Canvas. Open edX is open source. Vulnerabilities are tracked, disclosed, and patched on the Open edX security release cadence by the platform's maintainers — not by Instructure. Recent upstream security releases (Ulmo line, 2026-03-27 and 2026-04-02) and the recently disclosed CVE-2026-35404 (an Open edX CSRF / open-redirect issue) are being applied across Cubite-hosted environments on a verified rolling cadence; the exact patch date for your environment is available in the audit log. <>

We want to be honest about the third point: Open edX is not invulnerable. Every platform of any complexity has CVEs, and Open edX is no exception. The reason Canvas's incident does not become your incident is the combination of

• Tenancy isolation that contains the blast radius of any single CVE to a single tenant
•  a known patch cadence we hold ourselves to
• Monitoring that catches anomalies before they become incidents.

What we are doing on your environment this week

Each item is something we have either done or are actively doing right now.

• Threat-intel watch. We are monitoring published ShinyHunters indicators of compromise (IoCs) at our edge, identity, and admin layers.
• Heightened login-anomaly alerting on admin and instructor accounts in your environment.
• Patch verification across every customer environment. We are re-confirming that the Ulmo 2026-03-27 and 2026-04-02 Open edX security releases are applied, and that CVE-2026-35404 is closed.
• Credential rotation review for all admin tokens, API keys, deploy keys, and CI secrets touching your environment. Anything stale gets rotated this week regardless of policy schedule.
• Backup integrity check. We have verified that recent backups are present, restorable, and stored separately from the primary environment.
• Third-party dependency audit. We are reviewing every external service in your stack for any residual exposure stemming from the Instructure incident.

If you would like the environment-specific audit log for any of the above on your tenant, reply to this note (or open a ticket via your usual channel) and we will send it as quickly as we can — typically within one business day.

What we are not going to claim

We are not telling you that you cannot be breached. No vendor honestly can.

We are telling you that the Canvas-class blast radius — one vendor incident exposing thousands of organizations on shared infrastructure — is structurally not possible on this architecture. Different threat. Different shape. Different containment.

We are also reminding you that security is shared. The pieces inside your control are: enforcing MFA on your own admin and instructor accounts, rotating any shared or service credentials your team holds, and reviewing your access list for accounts that no longer need access. We can help with all three. Just ask.

For your board or leadership

If you need a paragraph to forward up the chain, this is the one:

You are welcome to paste this verbatim, or to attribute it to us by name.

A quiet word about the architecture you already chose

The thing you are reading about in the news this week is, in part, an architectural property of multi-tenant SaaS. You already chose differently. You chose dedicated infrastructure, dedicated keys, your own region, and a provider that patches on a known cadence and answers the phone.

We do not take that decision lightly, and this week our job is to earn the trust behind it. The list above is what that looks like in practice.