Originally published on arkensec.com

Between April 29 and May 7, 2026, ShinyHunters claimed two consecutive breaches of Instructure — the company behind Canvas, the LMS running on 41% of North American higher ed. The group says it pulled 3.65 TB and 275 million records spanning 8,809 schools, then defaced Canvas login pages when Instructure shipped patches instead of negotiating.

No exotic CVE. No kernel exploit. The stated vector: "an issue related to its Free-For-Teacher accounts."

8,809 schools. One free-tier sign-up flow.

That number is the point of this post. I want to walk through what the breach shape tells us about multi-tenant API design, where the trust boundary likely failed, and what developers building SaaS on shared infrastructure can actually do about it — with code you can run today.

The timeline, briefly

What leaked: names, email addresses, student IDs, private messages. What didn't (per Instructure): passwords, DOBs, government IDs, financial data. That distinction matters less than institutions are framing it — I'll get to why.

Where the seam probably was

Instructure said the vector was "an issue related to its Free-For-Teacher accounts." FFT is a no-cost self-serve tier. Sign up with a teacher email, get a Canvas instance, no procurement process, no SSO mandate.

That description — free tier, self-serve, no institutional controls — points at a specific vulnerability class: BOLA (Broken Object Level Authorization), which sits at the top of the OWASP API Security Top 10.

Here's what BOLA looks like in a multi-tenant context. Imagine an API endpoint like this:

GET /api/v1/courses/{courseId}/students
Authorization: Bearer <fft_token>

If the server validates that the token is authentic but doesn't validate that the token's tenant scope owns courseId, a free-tier user can enumerate course IDs belonging to paid institutional tenants. The auth check passes. The object-level check doesn't exist.

A minimal Python script to demonstrate the enumeration pattern (against your own test environment — don't run this against systems you don't own):

import requests
import time

BASE_URL = "https://your-canvas-test-instance.instructure.com"
TOKEN = "your_fft_test_token_here"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Content-Type": "application/json"
}

# Enumerate course IDs sequentially — BOLA is often this simple
def probe_course_access(start_id, end_id):
    results = []
    for course_id in range(start_id, end_id):
        resp = requests.get(
            f"{BASE_URL}/api/v1/courses/{course_id}/students",
            headers=headers
        )
        if resp.status_code == 200:
            results.append({
                "course_id": course_id,
                "student_count": len(resp.json()),
                "status": "ACCESSIBLE"
            })
            print(f"[!] Course {course_id} accessible — {len(resp.json())} students")
        # Respect rate limits in testing
        time.sleep(0.1)
    return results

if __name__ == "__main__":
    probe_course_access(1000, 1050)

In a properly scoped multi-tenant API, that request should return 403 Forbidden the moment courseId belongs to a different tenant — regardless of whether the token is valid. The token proves identity. Tenant-scoped authorization proves permission. Those are two separate checks, and collapsing them is how you get 8,809 schools exposed through one free account.

I'm not claiming this is exactly what happened. Instructure hasn't published a post-mortem. But "FFT account issue → 9,000-school data pull" fits this shape precisely.

How to test your own API for BOLA

If you're building a multi-tenant SaaS, here's a practical checklist. Run this against your staging environment before you ship.

Step 1: Create two isolated test tenants

# Tenant A — simulates a free/low-trust tier
TENANT_A_TOKEN="token_for_tenant_a"
TENANT_A_RESOURCE_ID="resource_owned_by_tenant_a"

# Tenant B — simulates a paid/institutional tier
TENANT_B_TOKEN="token_for_tenant_b"
TENANT_B_RESOURCE_ID="resource_owned_by_tenant_b"

Step 2: Attempt cross-tenant object access

# Can Tenant A's token read Tenant B's resource?
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer $TENANT_A_TOKEN" \
  "https://your-api.example.com/api/v1/resources/$TENANT_B_RESOURCE_ID"

# Expected: 403
# Dangerous: 200

Step 3: Check for sequential ID enumeration

#!/bin/bash
# Probe a range of IDs with Tenant A's token
for id in $(seq 1 50); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer $TENANT_A_TOKEN" \
    "https://your-api.example.com/api/v1/resources/$id")
  if [ "$STATUS" = "200" ]; then
    echo "[BOLA] Resource $id accessible to wrong tenant — HTTP $STATUS"
  fi
done

Step 4: Test token namespace isolation

If your free tier and paid tier share a token issuer (common with OAuth), verify the token claims include tenant scope and that your middleware enforces it:

import jwt  # pip install PyJWT

def validate_tenant_scope(token: str, required_tenant_id: str) -> bool:
    """
    Decode token and verify tenant claim matches the resource being accessed.
    This check must happen on EVERY object-level request, not just at login.
    """
    try:
        # Use your actual secret/public key here
        payload = jwt.decode(token, options={"verify_signature": False})
        token_tenant = payload.get("tenant_id") or payload.get("org_id")

        if not token_tenant:
            print("[WARN] Token has no tenant claim — reject this request")
            return False

        if token_tenant != required_tenant_id:
            print(f"[BOLA] Token tenant {token_tenant} != resource tenant {required_tenant_id}")
            return False

        return True
    except jwt.DecodeError:
        return False

# In your request handler:
# if not validate_tenant_scope(request.token, resource.tenant_id):
#     return 403

The middleware pattern that actually prevents this — enforce tenant scope at the data layer, not just the route layer:

# Don't do this — tenant check only at the route level
@app.route("/api/v1/courses/<course_id>/students")
@require_auth
def get_students(course_id):
    # No tenant check here — BOLA waiting to happen
    return db.query("SELECT * FROM students WHERE course_id = ?", course_id)

# Do this — tenant scope enforced in the query itself
@app.route("/api/v1/courses/<course_id>/students")
@require_auth
def get_students(course_id):
    tenant_id = g.current_token.tenant_id  # Extracted from validated JWT
    students = db.query(
        "SELECT * FROM students WHERE course_id = ? AND tenant_id = ?",
        course_id, tenant_id  # Tenant scope baked into every query
    )
    if not students:
        abort(403)  # Don't leak whether the resource exists
    return jsonify(students)

That second pattern is the one that would have contained the blast radius. The query physically can't return data from another tenant because the tenant ID is a required predicate.

Why the leaked data is more dangerous than it looks

Instructure confirmed no passwords leaked. Universities are framing this as "limited exposure." I'd push back on that framing.

Names + school emails + student IDs is a complete targeting package for spear phishing. Canvas users are conditioned to click Canvas links. They get Canvas notifications constantly. A phishing email that says "Your Canvas submission was flagged — review here" sent to a real student email, referencing their real student ID, from a domain that looks like canvas-notifications-[school].com — that's a high-conversion attack.

The data that leaked is the data you need to make phishing believable. That's the threat model institutions should be briefing against right now.

What to run this week if you're on the affected list

Check whether your Canvas subdomain is still serving the defacement payload:

# Check for ShinyHunters signatures in the current login page
curl -sL -A "Mozilla/5.0" https://<your-school>.instructure.com/ \
  | grep -iE 'shinyhunters|negotiate a settlement|breached'

# Verify security headers haven't been tampered with
curl -sI https://<your-school>.instructure.com/login \
  | grep -iE 'set-cookie|strict-transport-security|x-frame-options|content-security-policy'

Expected output for a clean instance:

strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
set-cookie: _csrf_token=...; Secure; HttpOnly; SameSite=Lax

Missing Secure or HttpOnly on session cookies, or a missing Strict-Transport-Security header, means something changed. Investigate before assuming it's fine.

Check your DNS for subdomain takeover exposure (a common follow-on attack when attacker has your domain structure from leaked data):

# Check for dangling CNAME records pointing at unclaimed cloud resources
dig CNAME canvas.<your-school>.edu
dig CNAME lms.<your-school>.edu

# If the CNAME points at *.instructure.com and that tenant no longer exists,
# you have a subdomain takeover risk

Force SSO password rotation for Canvas-linked accounts. If your institution uses SSO (Shibboleth, Azure AD, Okta), the Canvas breach didn't expose those passwords directly — but users who set a local Canvas password and reused it elsewhere are exposed. Rotate anyway.

The broader pattern: sector-targeting is math

This is ShinyHunters' third edtech breach in 2026. Infinite Campus in the spring. McGraw Hill. Now Canvas. That's not random. That's a group that did the math on attacking one consolidated platform versus thousands of individual schools and picked the obvious answer.

Per Mandiant's M-Trends 2026, nearly 30% of CVEs get exploited within 24 hours of disclosure. Time-to-exploit has effectively gone negative — attackers are finding bugs before defenders finish reading the advisory. When you combine that with the consolidation of edtech into a handful of platforms, the attack surface math gets uncomfortable fast.

I wrote about the same compounding pattern after the Vercel OAuth supply chain breach in April. Different vector, same shape: one shared platform, one trust-boundary failure, every downstream customer holding the bill.

Your security posture isn't just your security posture. It's your posture multiplied by the weakest tenant boundary in every multi-tenant SaaS you depend on. Canvas just made that concrete for 8,809 institutions at once.

The fix isn't "better vendor selection"

I want to be honest about the limitation here. Telling institutions to "pick more secure vendors" is not actionable advice. Canvas is dominant because it works, it integrates with everything, and switching LMS platforms is a multi-year project that costs millions. The consolidation that created this blast radius is also the consolidation that made modern edtech functional.

The actual levers are:

1. Demand tenant isolation attestations from vendors. SOC 2 Type II covers a lot of things, but it doesn't specifically attest to BOLA-class API isolation. Ask vendors directly: how do you test cross-tenant object access? What's your API security testing cadence? If they can't answer that, you know something.

2. Treat vendor breaches as your breach for incident response purposes. Don't wait for the vendor to tell you what to do. The moment Canvas appeared on Ransomware.live, every institution should have started their own IR process — not waiting for Instructure's May 6 "back to normal" announcement.

3. Run your own external attack surface checks regularly. You can't control what's inside your vendor's perimeter. You can control what's visible on your own domain. Surface-level checks on DNS, TLS, exposed admin endpoints, and subdomain takeover risk take minutes and catch the adjacent exposures an attacker would chain off leaked data.

The free ArkenSec scan runs 17 checks across those categories, takes about two minutes, and doesn't require a signup. It won't tell you if your Canvas tenant was in the leaked dataset — only Instructure can tell you that. It will surface what an attacker with your domain name already sees.

The Canvas breach is a multi-tenant architecture problem that got dressed up as a vendor security failure. Both things are true. But the architectural problem is the one that scales — and the one that developers building SaaS today are in a position to actually fix.

Test your tenant boundaries. Enforce scope at the data layer. Don't collapse authentication and authorization into a single check. Those three things wouldn't have prevented ShinyHunters from finding the seam, but they would have made the seam a lot harder to walk through.