About WebKit Weekly

The WebKit repository lands hundreds of commits every week. Most are routine. A few are worth a closer look — a bug fix that hints at a class of vulnerabilities, a refactor that shifts an attack surface, an obscure change that later becomes a CVE.

Each week we pick a handful of those and publish an in-depth report: root cause, affected surface, why it matters for someone building or breaking WebKit. We deliberately keep the selection small so each report can go deep instead of skimming.

Featured picks each get a dedicated per-commit report. The structure isn't a rigid template — the depth of each section scales with the bug — but every deep-dive is built to answer the questions an exploit developer or auditor walks in with:

• The angle — the "so what" hook up front: one italicized paragraph stating the attack impact in the reader's terms (what a WebContent compromise could reach with this bug, what the escalation ceiling is, whether memory corruption is even required).
• Background — a primer on the WebKit subsystems the bug lives inside (the trust boundary being crossed, the classes and macros involved, the normal-flow diagram). Written so a reader who's never touched the code can still follow the analysis.
• Analysis — the root cause plus a reconstruction of how the fix works, walking the patched code and the attack chain end-to-end. Diff excerpts inline. Covers what the fix addresses and what it doesn't — adjacent residual risk, attacker positioning, prerequisites.
• Insight — the structural takeaway. Why did this bug survive? What invariant did the codebase assume that wasn't actually enforced? What would a fix-once-forever version of the same defect look like?
• Audit directions — a short list of concrete follow-up hunts. Each item has a narrow target (sibling files in the same subsystem to sweep), a wider pattern (the class of bug across WebKit), and a widest generalization (how the same shape appears in other codebases), plus a "match tell" — the grep-able pattern that identifies the next instance.

Each report cross-links the WebKit commit, the Bugzilla entry when public, and any assigned CVE.

Each week's meta page also carries an OSRC appendix — commits that are security-relevant but don't warrant a full deep-dive: obvious bounds checks, mechanical hardening, one-line UAF fixes whose exploit story is self-evident. Each appears as a one- or two-sentence bullet with component tag and commit link. It's the "you should know this landed" tier — quick to skim, no depth obligation.

Non-security commits an exploit developer would still want to see, selected on two overlapping criteria:

• Security-adjacent signal. Silent bounds checks in a perf commit, refactors that move a trust boundary, regressions in high-value components (JSC internals, GPU process, IPC) that reveal undocumented invariants.
• Development significance. Newly landed Web APIs, IPC messages, or WASM operations that create new attack surface; major architectural shifts (process boundary changes, IDL binding rewrites, storage partition redesigns); JIT / GC / compiler landmarks (new DFG/FTL nodes, GC algorithm changes, allocator redesigns); Web-platform spec milestones shipping.

Volume varies week to week — some weeks a single line, others half a dozen. Each item is a short link + one-sentence tag pointing to the commit; only picks with a per-commit report link back to a full deep-dive.

Every WebKit CVE we track has a report. Most fall out of the weekly picks naturally. Some commits aren't recognized as security issues until later — sometimes weeks or months after the fact, when a CVE is finally assigned. When that happens we go back and publish a dedicated report on the original commit under the same standards as the weekly picks, so the coverage stays complete regardless of when the CVE lands.

Every report we publish is generated by a multi-stage LLM pipeline. The pipeline is designed for the accuracy and editorial consistency browser security analysis demands. Each stage below solves a specific problem with a specific method.

1. Classification — narrowing the scope

The WebKit repository lands 300–500 commits every week. Deeply analyzing all of them is infeasible on both cost and signal-to-noise grounds — the result would be a report diluted by routine changes. The first stage ranks every commit by exploit relevance and passes only the top few percent to the analysis stages that follow. This keeps report scope disciplined and downstream LLM cost predictable.

2. Security analyst — top-tier deep analysis

The most exploit-relevant picks each get a deep analysis decomposed into four explicit fields: root cause, exploit primitive, attack surface, and audit direction. Enforcing the schema solves two problems endemic to free-form analysis. First, it prevents specific angles (audit direction, say) from being present in one report and absent in another. Second, it makes reports comparable — reading only the attack surface of a commit, or comparing many commits by primitive type, are patterns that work only on top of a stable schema.

3. Development digest — the non-security track

New Web API landings, JIT/GC architectural shifts, spec milestones — commits with low exploit relevance but genuine engine-development significance — are handled in a separate dev-digest stage that produces the "Notable Development" section. A different prompt and a different quality bar apply here (accuracy-focused, no exploit narrative), producing shorter prose than the deep-dive tier.

4. Minor security digest — the appendix tier

Security-relevant commits that don't make the deep-dive cut are processed in a separate stage into one-to-three-sentence summaries and placed in the report's "Other Security-Relevant Changes" appendix. The goal of this tier is scannability — recording that the commit exists rather than analyzing it in depth. It's the compromise that keeps editorial effort concentrated on the top tier without dropping security signal entirely.

5. Curator — Featured selection

Among the analyst's output, a separate stage chooses which picks become the report's first visual entry point. It elevates a few candidates to the Featured tier based on primitive novelty, surprise factor, and audit implications, and drafts a short hook line for each. Isolating this "magazine cover" editorial judgment as its own stage lets us manage analytical precision and first-impression editorial punch independently.

6. Report composition — assembling the prose

The outputs of the preceding stages — analyst schemas, dev digest, minor digest, curator's Featured list — are structured data, not reader-ready prose. The writer stage composes them into a single report by applying editorial rules for opening tone, section structure, concept onboarding for WebKit newcomers, and diagram placement. Separating analytical logic from editorial logic keeps the analysis schema stable while the report's readability improves incrementally.

7. Localization — Korean generation

Once the English report is finalized, a separate stage regenerates it in Korean. Translation runs section by section and reassembles, with technical-term localization rules (avoiding certain literal translations, handling brand and product names) managed explicitly in the prompt. The result is two language versions that share editorial structure and citation relationships.

8. Verification loops — catching LLM errors

LLM output can fabricate details or invert causality. Each of the four content-producing stages (analyst, dev digest, minor digest, writer) has a dedicated fact-checker that compares the output against the source diff and surrounding code and flags problems. When verification fails, a revise pass runs with the checker's specific citations, repeating up to 10 iterations until it passes.

9. Context expansion — grounding the analysis

There are cases where the diff alone is insufficient — bugs rooted in a framework's lifecycle contract or in caller/callee conventions, for example. When the analyst identifies such a gap, the pipeline fetches the relevant caller/callee code via GitHub Code Search and re-runs the analysis. This lets us reach bugs that live outside the diff itself but in the actual runtime context.

10. Fixed taxonomy — label consistency

Every security-fix commit is classified into one of 13 fixed labels (UAF, OOB, TypeConfusion, Race, AuthBypass, and 8 more). Free-form labeling makes cross-report filtering and week-over-week trend comparison impossible. A fixed taxonomy is the substrate on which cross-week indexes like /bug-types/UAF and the landing page's distribution chart can work at all.

11. Contributor profile synthesis — the parallel pipeline

Separately from the weekly report, each contributor's profile page carries a tagline and summary paragraph synthesized from their commit history by an LLM. Summaries are created for contributors with at least 3 commits and auto-refresh whenever 4 weeks have passed or 10 new commits have landed since the last summary. The text on /contributors pages is the output of this stage.

12. Prompt versioning — reproducibility and accountability

A prompt change materially changes report style and tone. Prompts are managed with v1.x.y semantic versioning, and each report is stamped with the version active at generation time. All changes are published in /prompt-changelog, so readers can trace which editorial rules were in effect for any given report.

13. Editorial selectivity — the discipline made visible

WebKit Weekly's editorial identity lives in the narrowness of the curation. Of the 300–500 commits each week, only 1–2% become deep-dive picks; the rest are summarized or dropped. The selectivity ratio is published live on the landing page scatter chart, keeping the editorial discipline under self-observation over time.