ChromeOS LTS 138.0.7204.298: what changed, what to patch, how to roll it out

This LTS update matters because it ships security fixes, not because the version number looks new.

I’ve watched teams push “upgrade immediately” to a 3,000-device school fleet, then spend Monday morning un-bricking kiosk logins. LTS deserves a calmer playbook. ChromeOS LTS 138.0.7204.298 (platform 16295.83.0) looks straightforward, but you should still stage it, measure it, then roll it out.

What actually changed in 138.0.7204.298 (platform 16295.83.0)

The thing nobody mentions is that the official post usually tells you more through the CVE list than through any “stability improvements” sentence.

• Version and platform: ChromeOS LTS moved to 138.0.7204.298 on platform version 16295.83.0 (per the Chrome Releases post).
• Security fixes you can point to in a change review: the official notes list multiple CVEs, including high-severity V8 type confusion issues (CVE-2025-13224 and CVE-2025-13223) plus additional CVEs (for example: CVE-2025-21700, CVE-2025-21702, CVE-2025-21703, CVE-2025-21756, CVE-2025-21836, CVE-2025-21971, CVE-2025-37798, CVE-2025-37756, CVE-2025-37752, CVE-2024-27397).
• What I can’t prove from the short notes: specific “system stability improvements.” If you need that level of detail for a CAB ticket, you will probably have to follow the linked Chromium issues and your own pilot telemetry.

If your org treats V8 high-severity fixes as “patch fast,” do not debate it for two weeks. Patch it, but stage it.

Should you upgrade right now, or stage it?

Depends.

If you run proctored testing, retail kiosks, or anything that turns into a helpdesk fire when login breaks, stage first. Some folks skip canaries for patch releases. I don’t, but I get it when the fleet sits in low-risk offices and you can tolerate a few reboots.

• Move faster if: your threat model cares about browser RCE-class bugs, you allow broad web browsing, or you have a history of users installing sketchy extensions.
• Move slower if: you run kiosk apps, Managed Guest Sessions, or you depend on one crusty extension that only one staff member knows how to update.
• Ignore this advice if it’s a dev lab: just yolo it on Friday and see what breaks.

A rollout plan that won’t ruin your week

Here’s the pattern that keeps you out of trouble.

Pick a small pilot OU that matches reality, not your nicest devices. Include one kiosk, one shared cart, one staff laptop with too many extensions, and one device that lives on bad Wi‑Fi. I wish I had a cleaner way to say this, but the “representative sample” argument always feels correct right up until your first kiosk stops auto-launching.

• Stage 0 (lab): 10 devices for 48 hours. Verify sign-in, printing, your top 3 extensions, and any kiosk auto-launch flows.
• Stage 1 (pilot): 1% of your fleet for 72 hours. Pause if update failures cross 5% or you see repeat login loops.
• Stage 2 (ramp): 10% for 7 days. Watch helpdesk tickets. A ticket spike beats any “no known issues” line.
• Stage 3 (fleet): roll the remaining devices in waves. Schedule reboots outside class hours or shift changes.

How to upgrade (manual) and what to check after

Keep it boring.

On a single device, go to Settings, About ChromeOS, then Check for updates. Install, reboot, then go back to About ChromeOS and confirm 138.0.7204.298 and platform 16295.83.0. After that, open your two most critical web apps and do one full login flow, including MFA, because that’s where weirdness shows up first.

• Pre-check: confirm the device sits on the LTS channel you expect, not Stable or a pinned version.
• Post-check: verify critical extensions load, kiosk apps auto-launch, and captive portals do not trap users in a loop.

Known issues (what the notes say, and what reality says)

Official notes do not list any known issues for this release.

I still don’t trust “known issues: none” from any project, including the ones I like. Treat it as “none reported yet,” then let your pilot tell you the truth. Other stuff in this release: dependency bumps, some image updates, the usual.

Official notes and the one link you should keep

Read the upstream post for the authoritative version and CVE list, then paste that link into your change ticket so nobody argues about where the numbers came from.

• Chrome Releases (official): Long Term Support Channel Update for ChromeOS (lists version, platform, and CVEs).
• ChromeOS LTS documentation: LTS cadence and admin guidance for how Google intends orgs to run these updates.

Admin Console and CLI commands for fleet rollout

If you manage ChromeOS devices through Google Admin Console, here are the commands that matter for verifying this LTS update.

# On-device verification via crosh (Ctrl+Alt+T)
# Check platform version:
cat /etc/lsb-release | grep CHROMEOS_RELEASE
# Expected:
# CHROMEOS_RELEASE_VERSION=16295.83.0
# CHROMEOS_RELEASE_CHROME_MILESTONE=138

# Check Chrome browser version:
cat /etc/lsb-release | grep BROWSER
# Expected includes: 138.0.7204.298

# Using Chrome Management API to verify fleet versions
# List ChromeOS devices with version info:
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  "https://www.googleapis.com/admin/directory/v1/customer/my_customer/devices/chromeos?projection=FULL&fields=chromeosdevices(serialNumber,osVersion,platformVersion,lastSync)" \
  | jq '.chromeosdevices[] | select(.osVersion | contains("138.0.7204")) | {serial: .serialNumber, os: .osVersion, platform: .platformVersion, lastSync: .lastSync}'

CVE verification for your change ticket

The high-severity CVEs in this release (CVE-2025-13224, CVE-2025-13223) are V8 type confusion bugs. Here’s how to document them for a change advisory board:

# Quick lookup of the CVEs mentioned in this release
# Using the NVD API:
for cve in CVE-2025-13224 CVE-2025-13223 CVE-2025-21700 CVE-2025-21702; do
  echo "=== $cve ==="
  curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=$cve" \
    | jq '.vulnerabilities[0].cve | {id: .id, severity: .metrics.cvssMetricV31[0].cvssData.baseSeverity, score: .metrics.cvssMetricV31[0].cvssData.baseScore, description: .descriptions[0].value[:100]}'
done

# For a CAB ticket, include:
# - CVE IDs with severity ratings
# - Affected component (V8 engine, kernel)
# - Remediation: Update to ChromeOS LTS 138.0.7204.298
# - Rollback plan: Previous LTS version via Admin Console

# Admin Console: Force update via organizational unit
# Path: Admin Console > Devices > Chrome > Settings > Device settings
# Set "Auto-update settings" for the target OU:
#   - Target version: 138.0.7204.298
#   - Rollout: Staged (recommended)
#   - Scatter: Over 7 days
#
# To pin the LTS channel specifically:
# Admin Console > Devices > Chrome > Settings > Device settings
#   - Release channel: Long-term support channel

Look up CVE details for all your technologies with the CVE Dashboard, or track ChromeOS release health with Chrome version health badges. The Chrome Releases blog is the authoritative source for all ChromeOS updates.

Chrome LTS Resources

• Chrome Web Platform documentation – official guides for the web APIs, DevTools features, and enterprise policies shipped across Chrome releases.
• Chrome Platform Status roadmap – the living tracker for feature rollouts, deprecations, and LTS branch points.

For teams managing the cookie transition, we have a detailed Chrome cookie migration guide.

Related Reading

• Chrome 144 breaking changes
• Chrome geolocation changes
• Chrome version health badges