DEV Community: dsly

The Canvas breach and the cost of multi-tenant blast radius

dsly — Mon, 11 May 2026 00:15:56 +0000

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

Date	Event
Apr 29	Instructure detects unauthorized activity
May 1	Public disclosure
May 2	Instructure says breach contained
May 3	ShinyHunters posts ransom note on Ransomware.live, claims 275M records
May 5	8,809 affected schools published, including Harvard, Princeton, entire NC K-12 system
May 7	Canvas login pages defaced with second ransom note
May 12	ShinyHunters' stated negotiation deadline

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:

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.
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.
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.

SOC 2 Type II readiness is an evidence-velocity problem

dsly — Mon, 27 Apr 2026 05:00:17 +0000

Originally published on arkensec.com

My last SOC 2 Type II kickoff call lasted 82 minutes. The auditor asked for seven specific artifacts in the first ten, and I had four of them. The other three — evidence of vulnerability scan cadence on a defined schedule, documented remediation SLAs with timestamps, and a current third-party penetration test report — cost three weeks and $14,000 to produce mid-engagement.

I've now sat in twelve of these kickoffs across both sides of the table. The same thing breaks every time.

Evidence velocity, not documentation, is what blocks Series A SaaS from SOC 2 Type II. Closing the velocity gap saves six months and $20K–$50K.

What "evidence velocity" actually means

SOC 2 Type II readiness means your control environment can produce timestamped, auditor-legible evidence of every in-scope control operating consistently across a multi-month observation period — typically six months on a first audit, twelve on subsequent ones.

Readiness is not whether your policies exist. It's whether the artifacts those policies promise can be sampled at any random week and handed over in under five minutes.

Auditors don't review your entire observation period sequentially. They sample. They pick week 12, week 23, week 31, and ask you to produce evidence that each control fired on those specific dates. If you can produce it for week 12 but not week 23, the control fails.

That's the velocity problem. Not "do you have a scanner." But "does the scanner produce a retained, timestamped artifact on a fixed cadence, automatically, every single time."

Type I vs. Type II: what actually changes

Type I is a snapshot. Type II is a recording. The enterprise buyer blocking your deal wants the recording.

Dimension	Type I	Type II
Question answered	Are controls designed correctly today?	Did controls operate effectively over the observation window?
Observation period	Point-in-time	3–12 months (6 is typical first audit)
Evidence required	Policies, configs, sample artifacts	Continuous artifacts across the full window
Auditor sampling	Once	Random weeks across the period
Buyer credibility	Limited	Required for most enterprise procurement
Typical cost	$10K–$20K	$25K–$60K (audit fee + readiness + tooling)
Failure mode	Missing policy	Missing artifact for sampled week

Enterprise procurement teams stopped accepting Type I as a substitute around 2022. If you're going through the work, plan for Type II from day one.

The three Trust Services Criteria that eat Series A teams

The AICPA publishes five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Almost every Series A SaaS scopes the first audit to Security only — right call. Inside Security, auditors walk roughly sixty points of focus across nine Common Criteria.

Three of those produce most of the pain:

CC6.1 — logical and physical access controls
CC7.1 — detection of security events
CC7.2 — system monitoring for vulnerabilities and malicious code

Every other criterion has a policy answer. These three demand continuous evidence. That's where readiness dies.

First readiness assessments for 25-person SaaS teams typically return 40–80 gaps. Roughly three-quarters follow the same pattern: the control is written into the policy, it's occasionally enforced in practice, and nobody has collected evidence of continuous operation across the observation window.

What auditor-acceptable evidence looks like (with examples)

A useful rule: if you can't produce the evidence in under five minutes from a cold start, it doesn't exist for audit purposes.

Format that works	Format that fails
Immutable logs with timestamps (CloudTrail, GitHub audit log, Okta system log to a dated S3 bucket)	"We have logging on"
Tool-generated reports with scan-date header, retained for the full observation window	Screenshots saved to someone's laptop
Ticket artifacts with state transitions (Jira/Linear: opened → assigned → remediated → closed, each timestamped)	"We can regenerate the report"
Reviewer-signed artifacts (named reviewer clicks approval on a defined schedule)	A Slack thumbs-up emoji
Cron-driven scan output landing in a write-once retention bucket on a fixed cadence	"We scan when we deploy"

Let me show you what the right side of that table looks like in practice.

Wiring CloudTrail to S3 with immutable retention

This is the foundation for CC6.1 and CC7.1 evidence. CloudTrail logs API calls; the S3 bucket with Object Lock makes them tamper-evident.

# Create a dedicated audit evidence bucket with versioning + Object Lock
aws s3api create-bucket \
  --bucket your-company-soc2-evidence \
  --region us-east-1 \
  --object-lock-enabled-for-bucket

# Enable versioning (required for Object Lock)
aws s3api put-bucket-versioning \
  --bucket your-company-soc2-evidence \
  --versioning-configuration Status=Enabled

# Set a default retention policy (COMPLIANCE mode, 365 days)
aws s3api put-object-lock-configuration \
  --bucket your-company-soc2-evidence \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 365
      }
    }
  }'

Then create a CloudTrail trail that writes to that bucket:

aws cloudtrail create-trail \
  --name soc2-audit-trail \
  --s3-bucket-name your-company-soc2-evidence \
  --include-global-service-events \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail start-logging --name soc2-audit-trail

--enable-log-file-validation is the part most people skip. It creates SHA-256 digest files that let you prove the logs weren't modified after the fact. Auditors who know what they're looking at will ask for this.

Pulling the Okta system log to a dated evidence path

For CC6.1 access reviews, you need the IdP log retained with a timestamp path an auditor can navigate. Here's a minimal Python script that pulls the Okta system log daily and writes it to a dated S3 prefix:

import boto3
import requests
import json
from datetime import datetime, timedelta, timezone

OKTA_DOMAIN = "https://your-org.okta.com"
OKTA_API_TOKEN = "your-api-token"  # use Secrets Manager in prod
S3_BUCKET = "your-company-soc2-evidence"

def pull_okta_log(date: datetime) -> list:
    since = date.replace(hour=0, minute=0, second=0, microsecond=0)
    until = since + timedelta(days=1)

    headers = {
        "Authorization": f"SSWS {OKTA_API_TOKEN}",
        "Accept": "application/json"
    }
    params = {
        "since": since.isoformat(),
        "until": until.isoformat(),
        "limit": 1000
    }

    events = []
    url = f"{OKTA_DOMAIN}/api/v1/logs"

    while url:
        resp = requests.get(url, headers=headers, params=params)
        resp.raise_for_status()
        events.extend(resp.json())
        # Okta paginates via Link header
        url = resp.links.get("next", {}).get("url")
        params = {}  # params only on first request

    return events

def upload_to_s3(events: list, date: datetime):
    s3 = boto3.client("s3")
    key = f"okta-logs/{date.strftime('%Y/%m/%d')}/system-log.json"

    s3.put_object(
        Bucket=S3_BUCKET,
        Key=key,
        Body=json.dumps(events, indent=2),
        ContentType="application/json"
    )
    print(f"Uploaded {len(events)} events to s3://{S3_BUCKET}/{key}")

if __name__ == "__main__":
    yesterday = datetime.now(timezone.utc) - timedelta(days=1)
    events = pull_okta_log(yesterday)
    upload_to_s3(events, yesterday)

Run this as a Lambda on a daily EventBridge schedule. The S3 path structure (okta-logs/2025/01/15/system-log.json) is what makes the auditor's job easy — they can navigate directly to the date they sampled.

# EventBridge rule to trigger daily at 01:00 UTC
aws events put-rule \
  --name okta-log-daily \
  --schedule-expression "cron(0 1 * * ? *)" \
  --state ENABLED

CC7.2: the highest evidence-velocity gap

CC7.2 requires you to monitor systems for vulnerabilities and respond on a defined timeline. What auditors want:

A scanning cadence documented in policy (weekly external, monthly internal is the most defensible default)
A documented remediation SLA aligned to NIST SP 800-40r4: 30 days for critical, 60 for high, 90 for medium
Evidence that findings are triaged against the SLA and closed or risk-accepted in writing, for every scan across the entire window

The CISA Known Exploited Vulnerabilities catalog is the cleanest external benchmark for which findings warrant the tight end of the SLA. If a CVE is in KEV, treat it as critical regardless of your internal CVSS scoring.

The failure mode isn't having the scanner. It's running the scanner manually, inconsistently, and never retaining the reports against a sampling schedule.

Automating vulnerability scan evidence with a cron job and S3

If you're running Nuclei against your external perimeter, here's a minimal wrapper that produces a timestamped, retained artifact on every run:

#!/bin/bash
# scan-and-retain.sh
# Run this on a fixed cron schedule that matches your written policy exactly.
# If your policy says "weekly every Monday at 02:00 UTC", this cron runs
# weekly every Monday at 02:00 UTC. Not "roughly weekly." Exactly.

set -euo pipefail

TARGET="${1:-your-domain.com}"
BUCKET="your-company-soc2-evidence"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
DATE_PATH=$(date -u +"%Y/%m/%d")
REPORT_FILE="/tmp/nuclei-${TIMESTAMP}.json"

echo "[+] Starting scan of ${TARGET} at ${TIMESTAMP}"

# Run Nuclei with severity filter and JSON output
nuclei \
  -target "https://${TARGET}" \
  -severity critical,high,medium \
  -json-export "${REPORT_FILE}" \
  -silent \
  -tags cve,exposure,misconfiguration

# Add scan metadata envelope
METADATA=$(jq -n \
  --arg target "$TARGET" \
  --arg timestamp "$TIMESTAMP" \
  --arg policy_cadence "weekly" \
  --arg scanner "nuclei" \
  '{
    scan_metadata: {
      target: $target,
      scan_timestamp: $timestamp,
      policy_cadence: $policy_cadence,
      scanner: $scanner,
      soc2_control: "CC7.2",
      nist_reference: "SP 800-40r4"
    }
  }')

# Merge metadata with findings
jq -s '.[0] * {findings: .[1]}' \
  <(echo "$METADATA") \
  "${REPORT_FILE}" > "/tmp/final-${TIMESTAMP}.json"

# Upload to dated S3 path
aws s3 cp "/tmp/final-${TIMESTAMP}.json" \
  "s3://${BUCKET}/vulnerability-scans/${DATE_PATH}/nuclei-${TIMESTAMP}.json"

echo "[+] Evidence retained at s3://${BUCKET}/vulnerability-scans/${DATE_PATH}/"

# Cleanup
rm -f "${REPORT_FILE}" "/tmp/final-${TIMESTAMP}.json"

The cron entry, if your policy says weekly on Mondays:

0 2 * * 1 /opt/scripts/scan-and-retain.sh your-domain.com >> /var/log/soc2-scans.log 2>&1

The metadata envelope is the part most people skip. When an auditor pulls the artifact for week 23, they need to see the scan timestamp, the target, and the control it satisfies — without you having to explain it verbally. Put it in the artifact itself.

Tracking remediation SLAs in Jira with automation

The other half of CC7.2 evidence is showing that findings get triaged and closed within the documented SLA. Here's a Jira automation rule (in JSON, importable via the automation library) that sets a due date on vulnerability tickets based on severity:

{
  "name": "Set CC7.2 remediation due date by severity",
  "trigger": {
    "component": "TRIGGER",
    "type": "jira.issue.created",
    "conditions": [
      {
        "component": "CONDITION",
        "type": "jira.issue.fields.condition",
        "field": "labels",
        "condition": "CONTAINS",
        "value": "vulnerability"
      }
    ]
  },
  "actions": [
    {
      "component": "ACTION",
      "type": "jira.issue.edit.fields",
      "fields": {
        "duedate": {
          "expression": "{{#if issue.priority.name == 'Critical'}}{{now.plusDays(30)}}{{else if issue.priority.name == 'High'}}{{now.plusDays(60)}}{{else}}{{now.plusDays(90)}}{{/if}}"
        },
        "customfield_soc2_control": "CC7.2",
        "customfield_nist_sla": "SP 800-40r4"
      }
    }
  ]
}

The state transitions (opened → assigned → remediated → closed) are what the auditor samples. Every transition is timestamped by Jira automatically. The due date field makes SLA compliance visible in a single query:

labels = vulnerability 
  AND duedate < now() 
  AND status != Done 
ORDER BY priority DESC

Run this query weekly and screenshot the result to your evidence bucket. Zero results is the evidence. Non-zero results need a risk acceptance artifact.

CC7.1: security event detection without a full SOC

CC7.1 requires monitoring for anomalous events with a documented response process. Most Series A teams do this by accident — CloudWatch alarms, Sentry, a dedicated Slack channel, maybe PagerDuty. The gap is usually the absence of a defined severity taxonomy and any artifact showing triage actually happened.

Vercel's April 2026 disclosure is the worst-case version of CC7.1 failing silently: roughly 22 months between OAuth compromise and detection. Same evidence-velocity lesson, different control. I wrote that one up separately.

What works at Series A scale: a lightweight log aggregator (Panther, Wazuh, or a structured SNS → Lambda → S3 pipeline), a one-page

Vercel's April 2026 Breach Was an OAuth Supply-Chain Attack

dsly — Tue, 21 Apr 2026 04:38:01 +0000

Originally published on arkensec.com

Most post-mortems this week will frame the Vercel breach as a PaaS story. That's the wrong frame. Next.js wasn't compromised. Turbopack wasn't compromised. Vercel's build pipeline and edge infrastructure did their jobs. What got compromised was a single OAuth grant in a corporate Google Workspace, and the blast radius reached customers because "encrypted at rest" doesn't help when the attacker is holding a live admin session.

The breach sat undetected for roughly 22 months — mid-2024 to April 19, 2026 — because an OAuth supply-chain attack through an AI SaaS routed around Vercel's hosting defenses entirely.

What actually happened, in order

The chain, stitched together from Vercel's bulletin, CEO Guillermo Rauch's disclosure thread, Context.ai's own advisory, and early independent write-ups:

Step 1 — The infostealer.
A Context.ai employee was infected with Lumma Stealer in early 2026. The infostealer harvested Google Workspace credentials plus keys for Supabase, Datadog, and Authkit. Nothing in that initial pile was Vercel-specific. The attacker pivoted from there into Context.ai's consumer product — the "AI Office Suite" — and got their hands on OAuth tokens that consumer users had granted to the suite.

Step 2 — The pivot.
One of those consumer users was a Vercel employee, signed up using their corporate Vercel Google Workspace identity, who had clicked "Allow All" on the OAuth consent screen. The attacker used that token to move into Vercel's Workspace, took over the employee's account, and from there reached Vercel's internal environments. They read customer environment variables that weren't flagged "sensitive."

Step 3 — The exposure window.
Public timelines put the initial OAuth compromise at roughly mid-2024. That's a ~22-month detection gap. Stolen data was listed on BreachForums for $2M by an account claiming the ShinyHunters name; the real ShinyHunters have denied involvement. Attribution is still shaking out.

The MITRE ATT&CK mapping here is pretty clean: initial access via T1078.004 (Valid Accounts: Cloud Accounts), credential access via T1555.005 (Credentials from Password Stores: Password Managers — infostealer category), and lateral movement through T1550.001 (Use Alternate Authentication Material: Application Access Token).

Why "not marked sensitive" is doing so much work

Vercel's environment variable model has two tiers. Variables flagged sensitive are encrypted at rest and unreadable even from internal admin sessions — not even Vercel support can read them back. Everything else is readable by anyone with sufficient control-plane access.

That second bucket is where most teams leave their secrets, because nobody reads the onboarding docs that closely.

Database URLs. Stripe secret keys. OpenAI and Anthropic tokens. Webhook signing secrets. S3 access keys. On the seed-stage SaaS teams I've looked at, the split skews heavily toward the non-sensitive tier. Most founders I've asked didn't know the sensitive flag existed until this week.

I'll say the thing other write-ups won't: Vercel's non-sensitive tier is a UX footgun. The default should be encrypted-at-rest, opt-out to read. Anything else assumes every operator understands the threat model before they paste a key into a form field, and most don't.

If a credential lived in a non-sensitive Vercel env var any time before April 19, 2026, it was readable from within a compromised admin session. Whether yours specifically was read is what Vercel is still investigating. Whether it could have been is already settled.

How to check if you were exposed

Vercel has been contacting affected customers directly. If you haven't heard from them, you're probably in the unaffected majority. "Probably" is not "confirmed" on a breach with a 22-month exposure window.

Here's what to run tonight.

1. Pull the Vercel audit log

Team → Settings → Audit Log. Filter for env.read, env.list, and env.getSensitive events from IPs or user agents you don't recognize, especially across March and April 2026.

Vercel's audit log exports as JSON. If you want to grep it locally:

# Download from Vercel dashboard as JSON, then:
cat vercel-audit-log.json | jq '.[] | select(
  .type == "env.read" or
  .type == "env.list" or
  .type == "env.getSensitive"
) | {time: .createdAt, user: .user.email, ip: .meta.ipAddress, type: .type}'

Anything from an IP that isn't your office range or a known CI/CD provider is worth investigating.

2. Check provider-side logs for every credential that ever lived in Vercel

For AWS — look up any access key that was ever in a Vercel env var:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --start-time 2024-06-01 \
  --end-time 2026-04-20 \
  --query 'Events[].{
    Time:EventTime,
    EventName:EventName,
    Source:EventSource,
    IP:CloudTrailEvent
  }' \
  --output table

For Stripe, pull recent API key usage from the dashboard under Developers → Logs, and filter for requests from unexpected IPs or unusual user agents. Stripe's API also exposes this:

curl https://api.stripe.com/v1/events \
  -u sk_live_YOUR_KEY: \
  -d "type=api_key.created" \
  -d "created[gte]=1717200000" \
  -G | jq '.data[].created'

3. Grep your repo history for leaked artifacts

.vercel/ directories sometimes slip past .gitignore. So do env files that got committed once and then deleted — deletion doesn't remove them from git history.

# Check for .vercel/ artifacts in history
git log --all --full-history --oneline -- ".vercel/*"

# Search for Vercel tokens committed anywhere in history
git log -p --all -S "VERCEL_TOKEN" -- .

# Broader search for any env-style secrets
git log -p --all --grep="NEXT_PUBLIC_" -- .

# Check if .env was ever committed
git log --all --full-history --oneline -- ".env" ".env.local" ".env.production"

If any of those return results, the secret was public the moment that commit was pushed, regardless of what happened with Vercel.

4. Check for NEXT_PUBLIC_ variables that shipped to the browser

This one catches people off guard. Any variable prefixed NEXT_PUBLIC_ gets bundled into your client-side JavaScript and served to every visitor. It doesn't matter whether it was marked sensitive in Vercel — it was already public.

# In your built output
grep -r "NEXT_PUBLIC_" .next/static/ | grep -v ".map" | head -20

# Or check what's actually in your production bundle
curl -s https://yourdomain.com/_next/static/chunks/main-*.js | \
  grep -oP 'NEXT_PUBLIC_\w+' | sort -u

If you find API keys in there, rotate them immediately. That's a separate problem from the Vercel breach, but it's the same class of exposure.

The actual fix: lock down your Google Workspace OAuth grants

The check that would have caught this breach upstream isn't a Vercel setting. It's a Google Workspace admin review.

Open your Workspace admin console: Security → API Controls → App access control.

You'll see every third-party app that has OAuth access across your organization. For each one, ask:

Do I have a written justification for why this app has these scopes?
Is this app still actively used?
Did an admin approve this, or did an employee click through a consent screen?

Revoke anything you can't justify. Then set new OAuth grants to require admin approval:

Admin Console → Security → API Controls → App access control → Settings → Require admin approval for all third-party apps

That single config change closes the vector that caught Vercel. It's annoying — employees will file tickets when their new AI tool doesn't connect — and that friction is the point.

For apps you do approve, enforce least-privilege scopes. "Allow All" is never a reasonable choice for a corporate identity. An AI writing assistant doesn't need https://mail.google.com/ scope. If it's asking for it, that's a red flag about the vendor's architecture, not just their consent screen copy.

You can also enumerate current OAuth grants programmatically with the Admin SDK:

# Requires domain-wide delegation and admin credentials
# List all third-party apps with OAuth access
gam all users show tokens

GAM is the open-source Google Workspace admin CLI — if you're managing Workspace at any scale and you're not using it, you're doing it the hard way.

What to change this week, in order

1. Rotate and re-flag credentials.
Every deploy token, API key, and database credential that ever lived as a non-sensitive Vercel env var needs rotation. When replacements go back in, mark them sensitive. The flag exists for a reason.

# Vercel CLI — set a sensitive env var
vercel env add DATABASE_URL production --sensitive

# Or via API
curl -X POST "https://api.vercel.com/v10/projects/YOUR_PROJECT_ID/env" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "DATABASE_URL",
    "value": "postgres://...",
    "type": "sensitive",
    "target": ["production"]
  }'

2. Lock down Google Workspace OAuth.
Admin Console → Security → API Controls → App access control. Revoke apps without written justifications. Require admin approval for future grants. Do this before you do anything else.

3. Turn on deploy notifications.
Vercel → Project Settings → Git → Deploy Notifications. Connect Slack or email — whichever you actually read. If an attacker pushes to production in your name, you want to know in minutes, not when an upstream provider flags a leaked key a week later.

4. Scan your external perimeter.
The Vercel breach exposed secrets stored internally. A separate class of problem is secrets that are already public from your own application — NEXT_PUBLIC_ variables in your JS bundle, unauthenticated webhook endpoints, forgotten staging subdomains. Run a free external scan against your production domain at arkensec.com/scan — 17 checks, about two minutes, no signup. It won't tell you whether Context.ai's attacker touched your specific keys, but it will tell you what's reachable from your perimeter right now.

The shape of the next one

The same attack class — OAuth grant to a third-party SaaS with over-broad scopes, infostealer hits one of their employees, attacker pivots through the token, customer blast radius widens — will keep landing until platform defaults stop treating "Allow All" as a reasonable user choice.

The next breach in this shape won't be Vercel. It'll be whatever agentic AI tool half your engineering team connected to Workspace last quarter. Scattered Spider ran a version of this playbook against Okta in 2023. The tooling got cheaper and the AI SaaS attack surface got much larger. The math isn't complicated.

Some Vercel customers got upstream leaked-credential alerts from GitHub secret scanning and Stripe days before Vercel's official disclosure. The hosting platform was the last to know. That's not a knock on Vercel specifically — it's structural. Your credential providers see anomalous usage before your hosting provider sees anything. Set up those alerts if you haven't.

I got one thing wrong in my initial read of this incident: I assumed the 22-month gap meant the attacker was being careful about access patterns to avoid detection. The more likely explanation is simpler — nobody was looking at the audit log. env.read events from an unfamiliar IP in a control plane most teams never open. That's not sophisticated evasion. That's just a blind spot.

Run the audit log query above. Check your Workspace OAuth grants. Rotate the credentials. Two hours of work is cheaper than finding out about your exposure through someone else's incident report.