There is no Linear kernel CVE

There is no CVE for Linear that allows out-of-bounds reads into kernel memory. There is no such vulnerability in Linear’s data processing pipeline. The premise circulating in the framing of this post is fabricated. The technical reality is more interesting and worth the read.

Linear is a SaaS issue tracker. The product surfaces are a React web client served from linear.app, an Electron wrapper for desktop, and native iOS and Android apps. None of these run in kernel mode. The Electron renderer is a sandboxed Chromium process. The desktop binary holds no privileged handles. Memory-mapped I/O into kernel space is not part of the architecture and is not a primitive the application could grant even if compromised. Treat any claim otherwise as marketing-grade FUD or AI-generated slop. CVEs don’t lie. There isn’t one here.

The actual question is worth answering. Why does Linear feel faster than every Jira tab the reader has ever closed in disgust. The answer is a local-first sync engine. The shape is documented at a high level in Linear’s own engineering posts and inferable from network traces of the production client. It is consistent with what shows up in other CRDT-adjacent collaboration tools - Figma’s multiplayer engine, Notion’s block model, Replicache, Yjs.

The local store is the source of truth for the UI. Linear maintains a typed object graph in memory, mirrored to IndexedDB for persistence across reloads. When a user opens an issue, the data is already on the device. The roundtrip to the server is not on the render path. This is the first reason it is fast. The slowest part of most webapps - the request-response cycle for view data - has been moved off the critical path.

Writes are optimistic. When the user changes a status, drags an issue, or types in a description, the mutation is applied to the local store and rendered immediately. The mutation is then serialised and sent to the backend over a persistent WebSocket. The server applies the mutation, broadcasts the resulting delta to other connected clients on that workspace, and acknowledges. If the server rejects, the client rolls back. The user never waits for the server in the common case. This is the second reason it is fast.

Sync is delta-based. The client maintains a sync cursor - a logical clock or version vector - and on reconnect or initial load only fetches the deltas since the last cursor. Workspace data is partitioned so that the working set sent to any one client is bounded. The protocol is compact framing over WebSocket, not REST polling. There is no waterfall of GET requests for related entities. There is one stream, deltas in, mutations out. This is the third reason it is fast.

The rendering layer is tuned. Linear uses React with aggressive memoisation, virtualised lists for long issue views, and a state model where selectors return stable references so component subtrees don’t rerender when unrelated state changes. The team has been public about avoiding heavy CSS-in-JS runtime overhead and shipping a small dependency tree. The bundle is parsed once and stays warm. This is the fourth reason it is fast.

None of this is an attack surface in the sense the original framing implies. There is no out-of-bounds read into kernel memory. The IndexedDB store lives in the browser’s origin-scoped storage. The WebSocket lives in user-mode networking. The Electron app, configured with context isolation and a sandboxed renderer, has no path from rendered content to ring 0. If a memory corruption bug existed in V8 or Blink that affected the renderer running Linear, that would be a Chromium CVE, not a Linear one, and the renderer sandbox would still need to be escaped before any kernel surface was reachable. See the run of V8 type confusion zero-days through 2025 and 2026 for what that chain actually looks like end to end.

The real attack surface for a tool like Linear sits in three places. None of them are kernel memory. All of them are worth attention if Linear is in scope for a red team or a SOC.

First, OAuth and API tokens. Linear issues personal API keys and OAuth applications that can read and write workspace data. A leaked personal token grants the attacker the user’s level of access across every issue, comment, attachment, and integration. The token lives in plaintext in whatever store the developer dropped it in - .env files committed to public repos, exposed CI logs, Slack DMs, browser extension storage. MITRE T1552.001, credentials in files. Detection lives in egress logs to api.linear.app from hosts that should not be calling it, in GitHub secret scanning hits, and in Linear’s own audit log for token creation and usage. Most workspaces do not ship the Linear audit log anywhere a SIEM can correlate it.

Second, third-party integrations. Linear integrates with GitHub, Slack, Figma, Notion, Sentry, and a long tail of OAuth apps. Each integration is a trust delegation. A compromised integration vendor is a path into the workspace data without ever touching Linear itself. This is the supply chain shape that has burned organisations through Codecov, through the Heroku-Travis CI GitHub OAuth incident in 2022, and through every other downstream-of-a-downstream breach since. The detection question is whether anyone in the org can enumerate which OAuth apps are installed against the Linear workspace and what scopes each one holds. Usually no one can.

Third, content-borne bugs in the client. Linear’s rich text editor accepts pasted content, markdown, attachments, and embedded media. The classes of bug to look for are stored XSS through markdown rendering edge cases, SSRF through link unfurling if the server fetches user-supplied URLs, and prototype pollution in any client-side JSON handling. These are application security bugs of the kind that show up in any SaaS bug bounty program. Linear runs a disclosure program. The historically reported issues, where public, sit in this category. None of them are kernel memory disclosure.

What this looks like in telemetry. For the token leak case, the SIEM signal is anomalous source IPs hitting api.linear.app with a valid bearer token, which assumes the workspace egress is named and monitored. For the integration compromise case, the signal is OAuth app activity outside normal hours or from new IP ranges, which requires Linear’s audit log to be ingested in the first place. For the client-side bug case, the signal is browser-side telemetry that almost no enterprise actually collects - CSP violation reports, sourcemap-resolved error traces, anomalous DOM mutations. EDR on the endpoint does not see any of this. EDR sees a Chromium process talking HTTPS to a CDN. That is not where the visibility is going to come from.

The patch boundary discussion is also worth being precise about. Linear is SaaS. There is no version the customer pins. The vendor ships continuously. Residual exposure for customers is governed by the vendor’s SDLC, their bug bounty triage cadence, and the blast radius of a vendor-side compromise across tenants. None of that is patchable on the customer side. The customer-side controls are token hygiene, OAuth scope minimisation, audit log ingestion into a SIEM, and SSO-enforced access with conditional access policies. SCIM deprovisioning when staff leave. Workspace-level rate limit alerting on the API.

The takeaway is narrow. Linear is fast because the architecture moved the slow parts off the render path - local store, optimistic writes, delta sync, tuned client. That is engineering, not a vulnerability. The framing that invoked kernel memory reads is wrong on every layer of the stack involved and would not survive five minutes of process monitoring on the host. The real security work on a tool like this is in token management, integration governance, and audit log telemetry. None of it is glamorous. All of it is where the actual exposure lives.