Last week I wrote up how the Chrome Releases blog is functionally broken — 81 seconds of main thread lock because Blogger serves jQuery 1.11.3 synchronously and its WidgetManager chokes on 433 CVE entries. I also built a small CLI called unjam that pulls the CVE data without touching a browser. Extraction takes about a second.
A few folks asked whether this could work as an agent skill — something you invoke from OpenCode or Claude Code when you need Chrome CVE data without leaving your terminal or waiting 81 seconds for a browser tab to finish wrestling with a decade-old JavaScript library.
It can. And now it does.
The Skill
The chrome-cve-analysis-skill wraps unjam’s CVE extraction into a single shell pipeline: discover the latest Chrome release post from the Atom feed, extract structured CVE JSON, and generate a categorized markdown report. The whole thing runs in a few seconds.
You can point it at a specific URL:
./chrome-cve-analysis-skill/scripts/analyze_chrome_cve.sh \
"https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_..."Or let it auto-discover the latest Stable Channel Update from the Atom feed:
./chrome-cve-analysis-skill/scripts/analyze_chrome_cve.shThe script finds the most recent Stable Channel Update for Desktop post, hits it with unjam --cve, then feeds the JSON into a Python report generator that classifies vulnerability types, maps component areas, tallies bounties, credits external researchers, and writes a markdown report with frontmatter metadata.
The report covers:
- Executive summary with severity distribution and bounty pool total
- Vulnerability type breakdown (Use After Free, Heap Buffer Overflow, Type Confusion, etc.)
- Component area distribution (V8, Blink, GPU, Extensions, and 70+ more classifiers)
- Bounty analysis sorted by dollar amount
- External researcher credits
- Critical and high severity breakdown
- Reporting timeline by date
There’s a rendered example report in the README if you want to see what the output looks like before committing.
The Tool Behind It
unjam is the core extraction engine — a Deno CLI that connects directly to a Blogger page and pulls out the widget configuration data (the _WidgetManager._SetDataContext inline script) and, with --cve, any Chrome release CVE entries baked into the HTML. It handles single-quoted strings, \xNN hex escapes, and True/False/None keywords that break standard JSON parsers (because ofc it does). No browser required, no jQuery dependency, and it finishes before the Blogger page would even hit domInteractive.
There’s also a hosted web interface at unjam-chrome.val.run if you want to browse recent releases and generate reports without installing anything.
So What?
The Chrome Releases blog isn’t some curiosity. Security teams, vulnerability managers, and threat researchers depend on it for CVE data. Every Chrome stable release ships with a batch of security fixes, and knowing what’s in them — severity, affected component, whether there was a bounty, who reported it — feeds directly into risk assessment and patching priority.
Before unjam, getting that data meant either waiting out the 81-second jQuery death march in a browser, or writing a one-off scraper that’d break the next time Google sneezes on the Blogger template. Neither is a good use of anyone’s time.
The skill takes it a step further by making extraction repeatable and agent-invocable. There’s no manual URL hunting or copy-paste involved. An agent can auto-discover the latest release, extract every CVE with structured metadata, and produce a categorized report — all in the time it takes the actual blog page to halfway render.
If you’re running any kind of Chrome vulnerability monitoring, this should save you from timing out on Blogger at least once a week. That’s a low bar, but here we are.
Installing
You need unjam (prebuilt binaries for macOS, Linux, and Windows are in the repo), curl, and Python 3. Clone the skill repo, make sure unjam is on your PATH, and run the script.
The skill’s designed to load as an OpenCode or Claude Code agent skill, but nothing stops you from running the shell script directly in CI or cron. Both work fine.