CVE-2026-7992 in the Chrome OS could allow an attacker to take control of a district Chromebook if a student visits a malicious website.

Community

A newly disclosed Chrome OS vulnerability — CVE-2026-7992 — lets an attacker take full control of a district Chromebook the moment a student lands on a malicious website.

No phishing email. No downloaded file. Just a bad URL and your device is compromised.

That's the attack surface for every school running a 1:1 Chromebook program, which at this point is most of you. Students browse constantly — Google searches, YouTube rabbit holes, random links from Discord. Any one of those clicks could be the trigger. And unlike a staff laptop, a student device might not get reported as "acting weird" for days.

Here's what makes this one sting: Chromebooks are supposed to be the low-maintenance, low-risk option. Verified Boot, sandboxing, auto-updates — the whole pitch is that ChromeOS handles security for you. CVE-2026-7992 punches directly at that assumption. If the exploit can survive the sandbox, the entire device is in play, and depending on your MDM configuration, that could mean access to network credentials, enrollment tokens, or whatever the student was authenticated into at the time.

The update chain matters here. Google will push a patch through the standard ChromeOS release cycle, but not every device picks it up instantly. Devices that are offline, in a cart, or set to a delayed update channel are sitting exposed. If your district uses the Stable channel with a forced reboot policy, you're in a better position. If you've got a loose update policy or a pile of devices that haven't been powered on in two weeks, you've got a problem to chase down.

Check your Google Admin Console now for update compliance across your device fleet. Pull anything that's significantly behind and push updates before those devices go back into students' hands.

Bottom line: Force a ChromeOS update sweep across your fleet today — any device that isn't current is a drive-by exploit waiting to happen.

Canvas: things to do

Community · 1 min read

A thread on r/k12sysadmin is circulating a blunt incident-response checklist for Canvas outages or security events — and the community is pushing back hard on trusting Canvas's status page as a reliable source of truth. The checklist hits the essentials fast: kill API connections to your SIS, Google, and Microsoft integrations; drop SSO; block traffic at the firewall; then call your insurance carrier and state agency before you let anyone back in. If you manage Canvas, this is the kind of field-tested protocol your runbook should already have. Google Classroom, Teams, and yes, paper are all named as short-term fallbacks.

Bottom line: Pull your Canvas API tokens and SSO config now, document the kill-switch steps, and make sure you — not a vendor status page — are the one deciding when it's safe to reconnect.

Digital Resilience for K–12: Planning for Cloud Outage Continuity

News & Industry · 1 min read

Cloud outages from ransomware, weather, and provider failures are forcing districts to rethink operational continuity — and the answer isn't building a local replica of your cloud stack. Experts push contingency plans and backup systems that keep learning running during partial or full outages, not offline mirrors of your LMS or SIS. If your continuity plan assumes internet access, it's not a continuity plan. Note: Quotes in this piece come from Microsoft and Arista Networks representatives — vendor perspectives worth filtering accordingly.

Bottom line: Audit your outage playbook now and identify which critical systems can function without cloud connectivity.

CISA Adds One Known Exploited Vulnerability to Catalog

Cybersecurity · 1 min read

CISA added CVE-2026-42208, a SQL injection flaw in BerriAI LiteLLM, to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. LiteLLM is an AI gateway tool showing up in more district environments as schools experiment with LLM integrations — if you've deployed it, patch now. SQL injection vulnerabilities in internet-facing tools are a reliable ransomware entry point, and "we're not a federal agency" has never stopped attackers from using a federal watchlist as a target list.

Bottom line: Audit your AI toolchain for LiteLLM instances and apply fixes before this one lands in an exploit kit.

What has your role been in creating AI policy/guidelines for your district?

Community · 1 min read

A thread on r/k12sysadmin is asking how much of the AI policy work is actually landing on IT shoulders — and the responses reveal IT directors are often driving the whole document, not just advising a committee. If you're waiting for curriculum or admin to take the lead, many of your peers already stopped waiting. No hard data here, just a useful gut-check: if your district has no AI guidelines yet, someone has to own the first draft, and that someone is probably you.

Bottom line: Open the thread, steal a framework, and start writing.

Tech Tip of the Week

GAM for Beginners

GAM is a free, open-source command-line tool that lets you manage Google Workspace from your terminal. No clicking through the Admin Console. Just fast, scriptable commands.

Install it in five steps:

2. Download the installer for your OS (Windows, Mac, or Linux)

3. Run the installer — it handles Python dependencies automatically

4. Follow the prompts to authorize GAM against your Google Workspace domain (you'll need Super Admin credentials)

5. Run your first command: gam info domain

If you see your domain details return cleanly, you're live.

From here, you can pull user lists, reset passwords, manage licenses, and push calendar resources — all from one terminal window.

Start small. Run gam print users and export your first user report. Once you see how fast it is, you won't go back to clicking.

Pass This Along

If a colleague or coworker in K12 IT would find this useful — forward it. They can subscribe free and get their own copy every Friday.

Keep Reading