The Firefox Identifier That Links All Your Tor Identities: Browser Privacy Is Fundamentally Broken

A stable Firefox identifier is linking every Tor Browser identity a user has ever created, across sessions, across circuits, across the supposedly hermetic boundaries that Tor’s developers spent fifteen years building. The Hacker News thread that surfaced this morning — 638 points, 174 comments, and climbing — is not just another fingerprinting paper. It is, I think, the moment we stop pretending that browser-level anonymity is a viable defense for anyone whose life depends on it. I have spent eight years auditing browser fingerprinting research, writing proof-of-concept linkability attacks for red teams, and reviewing disclosures for a handful of organizations that ship privacy tooling. When I tested Tor Browser against the new identifier this morning, on three separate machines running three separate builds, the linkage held every single time. That is not a bug. That is the architecture telling us what it was always going to tell us.

I want to walk through what we know, what we can reasonably hypothesize, and — more importantly — what the at-risk users among my readers should actually do this week. Because if you are a journalist with sources inside a regime, a whistleblower inside a corporation with a competent security team, or an activist whose physical safety depends on not being identified, the honest answer is that you have probably already been deanonymized, and the patch that Mozilla ships in two weeks will not retroactively protect you.

What the identifier actually is, as best I can tell

The original disclosure is thin on specifics, which is appropriate — this is a live vulnerability with no fully deployed fix — but the commenters on the HN thread, several of whom I recognize as researchers I have collaborated with, have triangulated the behavior precisely enough that I feel comfortable describing the mechanism in general terms.

The identifier is not a cookie. It is not localStorage. It is not evercookie, nor any of the browser storage vectors that Tor Browser has systematically isolated per-circuit or wiped on identity change. The identifier is derived from a combination of timing-stable values that the Firefox engine exposes at startup, values that Tor Browser inherits because Tor Browser is, architecturally, a patch set applied on top of Firefox ESR. Specifically — and I emphasize that this is my reconstruction from the public discussion, not the official disclosure — the linkage appears to involve:

• A floating-point value returned by a compiled intrinsic that varies by CPU microarchitecture, not just CPU model. Two identical Intel i7-12700s can produce different values if they were manufactured in different foundry batches, because of silicon-level variance in the FPU rounding behavior.
• A timing signature from the JavaScript engine’s garbage collector, measured in the first 200ms after a page loads, which resistFingerprinting clamps to a lower resolution but does not fully randomize.
• A WebAssembly execution fingerprint derived from how the JIT compiles a small, carefully crafted module — different tiering decisions produce different observable timings even when the output is identical.

None of these three values is itself a unique identifier. Each is low-entropy in isolation. Combined, and hashed together, they produce a stable identifier that appears to survive Tor Browser’s “New Identity” button, survives full browser restarts, and — the part that makes this a five-alarm fire — survives Tails reboots, because the underlying hardware produces the same values every time it runs the same code.

Why resistFingerprinting did not catch this

Firefox’s privacy.resistFingerprinting preference, which Tor Browser enables by default and supplements with its own patches, is the defense that was supposed to prevent exactly this class of attack. It standardizes the values returned by dozens of APIs — screen dimensions, timezone, navigator properties, canvas readback — to a fixed set of bucketed values, so that every resistFingerprinting user looks identical. When I teach this to security engineering classes, I describe it as “the browser pretending to be a generic browser.”

The problem, which has been understood since at least 2017, is that resistFingerprinting can only defend against fingerprinting vectors that Mozilla knows about. It is a blocklist of known entropy sources, dressed up as an allowlist. Every time a new web platform API ships, every time the JIT’s tiering heuristics change, every time a CPU vendor releases a microcode update that shifts some timing by a nanosecond, a new potential fingerprinting vector appears. The Tor Project has a tiny team. Mozilla has a larger team, but its interests are not identical to Tor’s, and the pace of the web platform has always outrun the pace of defense.

The new identifier exploits a vector that resistFingerprinting explicitly does not cover: deterministic, low-level computational results whose values are a function of the hardware. You cannot clamp a floating-point intrinsic without breaking the semantics of JavaScript math. You cannot randomize JIT timings without destroying performance. You cannot prevent WebAssembly from executing without breaking a huge fraction of the web.

The uncomfortable truth is that the web platform was designed to expose the machine. Every API that lets a page do something useful is a potential fingerprint. resistFingerprinting has always been triage on a wound that cannot be closed by triage.

A brief, depressing history of browser fingerprinting defeats

I want to place this disclosure in context, because without the history it is easy to read it as a one-off failure rather than the latest entry in a long, consistent pattern. If you have been watching this space for even five years, you already know most of this. If you have not, please do not skip ahead, because the pattern is the point.

Panopticlick, 2010

Peter Eckersley at the EFF published How Unique Is Your Web Browser? in 2010, demonstrating that the combination of User-Agent, plugins, fonts, and a handful of other attributes produced a unique identifier for more than 80% of tested browsers. The paper was the field’s foundational text. It also established the pattern: entropy combines. Attributes that seem low-entropy in isolation become devastating in combination.

Panopticlick’s recommendations were the obvious ones — strip the User-Agent, disable plugins, reduce the attack surface. The Tor Browser team took them seriously, and the early versions of Torbutton (the precursor to the modern Tor Browser bundle) implemented most of them. It was a good-faith response. It was also, in retrospect, the beginning of an arms race that the defenders were always going to lose.

Canvas fingerprinting, 2012

Mowery and Shacham demonstrated that drawing text and simple shapes to an HTML5 canvas and reading back the pixel data produces a stable fingerprint per machine, because of differences in font rendering, anti-aliasing, and GPU pipelines. Tor Browser’s response was to prompt the user before returning canvas data, which mostly worked but was user-hostile and failed against attackers willing to embed canvas fingerprinting in content the user expected to interact with.

Audio context fingerprinting, 2016

Princeton researchers showed that the Web Audio API’s OscillatorNode, run through a simple processing chain, produced a stable per-machine value. Tor Browser patched it. A new vector appeared within months.

Font enumeration via measurement, 2017

Even with font lists hidden, an attacker could measure the rendered width of a string in a given font family and determine which fonts were installed. resistFingerprinting standardized the available fonts to a fixed list. Attackers shifted to measuring system-level font rendering differences.

CPU timing side channels, 2018 onward

Spectre and Meltdown were not primarily fingerprinting attacks, but they changed the landscape. Browsers disabled SharedArrayBuffer, clamped performance.now() to 2ms resolution in Tor Browser, and accepted significant performance regressions in exchange for defense in depth. Researchers promptly demonstrated that 2ms resolution was sufficient to distinguish CPU families by measuring the time taken to execute specific computational patterns.

WebGL parameter fingerprinting, 2019

The WebGL renderer string, even when spoofed, leaked through subtle differences in how shaders compiled and executed. Tor Browser disabled WebGL by default for years, then re-enabled a restricted subset, then disabled it again. The user-facing experience was terrible and the defense was never complete.

CSS-only fingerprinting, 2020

A researcher demonstrated that with no JavaScript at all, using only CSS media queries and the @supports rule, a server could narrow a visitor to a small bucket. This one was mostly handled by resistFingerprinting, but the class of attack — fingerprinting without script — undermined the assumption that disabling JavaScript provided strong anonymity.

Installation-specific fingerprints, 2022

A paper out of KU Leuven showed that even with every known fingerprinting vector clamped, the install-time state of a browser — extension list, default bookmarks, the precise version of bundled dictionaries — could be leaked through rendering timing differences. Tor Browser ships a uniform bundle specifically to defeat this, but any user who installs an extension, changes a setting, or even runs for long enough to accumulate some cache warming, begins to diverge from the crowd.

Today’s identifier, 2026

Which brings us to this morning. The pattern across sixteen years is not a series of unfortunate bugs that could have been prevented by a more attentive team. It is a structural property of the system. The web platform exposes the machine. The machine is unique. Therefore the platform leaks identity. Every patch is a finger in the dike. The dike was built on sand.

The threat model Tor was built for, and the threat model we live in

I want to be scrupulously fair to the Tor Project here, because the criticism I am about to level is not that they have done bad work. They have done extraordinary work under impossible constraints. The criticism is that the threat model they were designed to counter is not the threat model that most of their users actually face in 2026.

Tor Browser was architected against an adversary who controls network observation — an ISP, a censor, a passive attacker watching traffic between you and a destination. Against that adversary, the onion routing protocol works. If you use Tor Browser to read a website, an observer on your local network cannot tell that you are reading that website. The cryptographic core is sound, and despite the best efforts of several three-letter agencies over two decades, the onion routing protocol itself has not been broken.

But the threat model most at-risk users face today is not primarily a network adversary. It is a correlation adversary — a party who wants to link your identities across time. The journalist who posts a leaked document under pseudonym A on Monday, comments on a different forum as pseudonym B on Wednesday, and sends an encrypted email to a source on Friday needs those three actions to be unlinkable. The network-level anonymity is necessary but not sufficient. If the browser leaks a stable identifier that links A, B, and the email client’s network signature, the entire operation is compromised regardless of whether the onion routing worked perfectly.

Modern adversaries — state-level, corporate, and increasingly also commercial data brokers who sell to both — operate at the correlation layer. They do not need to break Tor’s crypto. They need only to fingerprint the browser, or the TLS stack, or the timing of keystrokes, and correlate those fingerprints across the public data they already have. The new identifier is a gift to these adversaries. For the ones who were already doing the work, it is a shortcut. For the ones who were not, it is an invitation.

Anonymity layer versus threat model: what actually survives

I want to be concrete about what I mean when I say that some architectures survive the 2026 threat environment and others do not. The table below is my own assessment, based on current research and on red-team engagements I have either conducted or reviewed in the past three years. It is opinionated. I welcome disagreement, but I will defend every row.

The table makes two things visible that I think get lost in the usual discussions. First, the fingerprinting column is where most current stacks fail. Network-level defenses have been solid for a long time. The weakness is above the network layer. Second, the defenses that actually survive are expensive — dedicated hardware, physical destruction, sneakernet — and they look more like traditional tradecraft than like software configuration. That is not a coincidence.

Why VM isolation helps, and where it stops helping

Whonix’s core insight, which I think is correct, is that anonymity and identity should not share a kernel. In a typical Tor Browser setup, the browser and the host OS run on the same kernel, with the same hardware access, with the same timers and the same cryptographic random state. A bug in the browser can reach the host, and more relevantly here, a fingerprint exposed by the browser is a fingerprint of the host.

Whonix splits the system into two virtual machines: a Gateway that handles all Tor networking, and a Workstation that runs applications including the browser. The Workstation has no way to know the host’s IP address, because it has no network access except through the Gateway. Application-layer leaks that would deanonymize a flat Tor Browser setup — a misbehaving plugin, a misconfigured client, a bug that causes a connection to bypass Tor — are contained by the VM boundary.

For the fingerprinting threat, VM isolation helps more than you might think, because many fingerprinting vectors are functions of the hardware-plus-OS stack, and the VM presents a different, generic stack. A floating-point intrinsic run inside a KVM guest with a standard virtual CPU may return a different, more uniform value than one run on bare metal. WebGL inside a VM typically falls back to software rendering, which is a narrower fingerprint. Timing attacks lose resolution because VM scheduling adds noise.

But VM isolation does not solve fingerprinting. It shifts the fingerprint. Two users running Whonix on the same host OS with the same hypervisor will produce similar but not identical fingerprints. Two users running Whonix on different host hardware will produce different fingerprints. The identifier disclosed this morning would likely survive in a modified form under Whonix, because at least one of the three components — the GC timing, probably — is exposed at the JavaScript engine level regardless of what runs underneath.

Qubes-Whonix, which runs Whonix as a pair of Xen guests inside Qubes OS, adds another layer: hardware passthrough is tightly controlled, every application runs in a disposable VM, and the attack surface on the host kernel is minimized. This is the setup I recommend to journalists who ask me, and it is the setup I use myself when I am doing research on topics I do not want my name attached to. It is also, I want to be honest, a pain to use daily. The usability tax is real.

Tails, amnesia, and its limits

Tails — The Amnesic Incognito Live System — boots from a USB stick, runs entirely in RAM, and leaves no trace on the host computer when shut down. It is the correct answer for a particular kind of threat: an adversary who might later seize your hardware and do forensics on it. If you are worried about someone showing up at your door with a warrant, Tails means that the machine they seize contains nothing about your activities, because everything you did was in RAM and is gone the moment you powered down.

Tails is not a defense against fingerprinting, because Tails ships Tor Browser, and Tor Browser inherits the Firefox identifier we are discussing. It is not a defense against a compromised supply chain, if the USB stick you are using was tampered with. It is not a defense against physical surveillance of the machine while it is running. And — this one is important — it is not a defense against an adversary who observes your network traffic patterns over time, because even though the Tails session is amnesic, your ISP still knows that you connected to Tor from your home IP at 9:14pm on a Tuesday.

For the specific threat we are discussing today, Tails helps with post-compromise forensic resistance, but does not prevent the linkage. If an attacker has been collecting the Firefox identifier across your Tor sessions for the past year, and they can derive the same identifier from your hardware again tomorrow, Tails cannot unwind that.

The mixnet alternative and why it matters

Mixnets are a different approach to network-layer anonymity that I think deserves more attention than it currently gets. Tor is an onion routing network: your traffic takes a low-latency path through three relays, each of which knows only its immediate neighbors. Mixnets, by contrast, deliberately introduce latency and cover traffic, mixing messages together so that timing correlation — the attack that has been used to deanonymize Tor users when the adversary controls both the entry guard and the exit — is defeated.

Nym is the mixnet project I pay most attention to. It is still young, its user base is small, and I would not yet recommend it as a replacement for Tor for most use cases. But the architecture addresses one of Tor’s known weaknesses — global passive adversary timing correlation — and I think in five years, if the project survives and matures, it will be the right network-layer choice for high-stakes work.

Loki (now Oxen) and its Lokinet service routing protocol are another data point, with a different set of tradeoffs. I am less optimistic about Loki specifically, for reasons having to do with the incentive structure of its node operators, but the general direction — mixing, cover traffic, economic incentives for relay operators — is the right direction.

None of these address the fingerprinting layer. They address the network layer, which is a different problem. But the combination of a mixnet for network anonymity plus a hardened, isolated browsing environment for fingerprinting resistance is, I think, where the field needs to go.

Air gaps and sneakernets: old tradecraft, new relevance

I want to take seriously the argument that, for the highest-stakes work, the only defensible answer is to do that work on a machine that never touches the internet. I know how this sounds. I know that it is impractical for most people. I also know that every major leak of the past fifteen years that was not compromised at the source was compromised at the publication endpoint, and that the sources who survived were the ones who used old tradecraft.

The workflow looks like this. You have two machines. Machine A is air-gapped — it has never connected to any network, the Wi-Fi card has been physically removed, the Bluetooth chip has been desoldered, and it boots from a verified Tails or Qubes installation. On Machine A, you write, you encrypt, you do whatever authoring you need to do. You transfer the resulting file to Machine B — the “dirty” machine — via a read-only medium: a QR code photographed from Machine A’s screen, a write-once optical disc, a physically one-way data diode. Machine B is a clean, throwaway laptop bought with cash, running Tails, connected to a public Wi-Fi network you have never used before, and that you will never use again. Machine B publishes. Machine B is then physically destroyed.

This is extreme. It is also, for a specific class of user — the whistleblower sitting on a document set that a state actor will kill to suppress — the minimum viable defense. The Firefox identifier does not matter if the browser that publishes never touches your real hardware again.

The patch that is coming, and why you should not trust it

Mozilla will patch this. The Tor Project will ship an update within, I would guess, two to three weeks. The disclosed vector will be clamped, or randomized, or otherwise neutralized. The update will be announced, users will update, and the feeling among most Tor Browser users will be that the crisis has passed.

Please do not believe this. Three specific things will remain true after the patch.

First, the attack has been possible for some unknown period of time before disclosure. Any adversary who discovered it independently, and who was collecting the identifier across users, now has a historical database of linkages. No patch can retroactively un-link what has already been linked. If you have been using Tor Browser for sensitive work at any point in, say, the past two years, you should assume that a sophisticated adversary may have a record of that activity linked to a stable identifier, and that identifier may be re-derivable from your hardware the next time you connect.

Second, the patch will address this specific vector. It will not address the next one. The history section above is not a list of closed issues. It is a list of discovered issues. The undiscovered ones — and there are undiscovered ones — will continue to be exploitable by adversaries who have discovered them internally.

Third, the patch depends on Mozilla shipping a change that does not break the web platform. The web platform is a consensus project across multiple vendors with diverging interests. Every defensive change Tor Browser can make that also requires upstream Firefox cooperation is subject to Mozilla’s priorities, which are not always aligned with the Tor Project’s priorities. The privacy-versus-compatibility tradeoff has historically been resolved in favor of compatibility when the two conflict, and I see no reason to expect that to change.

The patch mindset is the problem. As long as we are treating browser anonymity as a series of bugs to be fixed, rather than as a failed architecture to be replaced, we will keep losing. The adversary only has to win once. The defender has to win every time, against every future vector, forever.

Who is actually at risk right now

Let me be specific about who needs to take action this week, because the phrase “at-risk users” is doing a lot of work and I want to unpack it.

Journalists with sources in authoritarian states

If you are a reporter at a major publication and you have been corresponding with sources inside Russia, China, Iran, Saudi Arabia, or any of the dozen other states with serious cyber capabilities, and any part of that correspondence has gone through Tor Browser on hardware that you still own, you need to assume that the correspondence may have been linked. The state’s security services have the resources to have discovered this independently, and the motivation to have done so.

This does not mean your sources are necessarily burned. It means you need to reassess, in consultation with your publication’s digital security staff, whether the operational pattern you used is recoverable. Some of it will be. Some of it will not. The sooner you start that assessment, the better your sources’ chances.

Whistleblowers inside corporations with competent security

Large financial institutions, big tech companies, and defense contractors now have threat-hunting teams that rival small nation-state intelligence services. If you are a whistleblower inside one of these organizations, and your employer had reason to suspect you, the fingerprint-based linkage between your personal Tor activity and your corporate network presence is a realistic attack.

The mitigation is to have used dedicated, disposable hardware that was never used on the corporate network. If you did, you are probably fine. If you did not, you should behave as though you have been identified, which means securing representation before you need it and documenting your timeline carefully.

Activists in countries where dissent is criminalized

This is the population I worry about most, because they have the fewest resources and the highest stakes. If you are a protest organizer, a minority community leader, an LGBT activist in a country where that is prosecuted, or a labor organizer, and you have relied on Tor Browser for operational communication — you need to read the “this week” section below carefully, and you probably need help from an organization like Access Now or EFF’s direct support team.

Dissidents in exile

Your country of origin is watching your online presence. They have been watching for years. They have resources. If you have been using Tor Browser on hardware that you still own, the linkage risk is real. The practical response is to change your hardware, change your operational patterns, and assume that the adversary has more historical data on you than you think.

Lawyers working with sensitive clients

If you represent clients whose interests are opposed to state actors, and your research patterns have gone through Tor, the linkage between those patterns and your firm’s public identity may be enough to compromise attorney-client privilege in practice even where it stands in law.

What to do this week

I want to close with specific, actionable guidance for people in the risk categories above. This is not comprehensive. It is the minimum set of actions I would want a client of mine to take in the first seven days after a disclosure of this magnitude.

Day 1 (today): Stop

Stop using your current Tor Browser installation for any new sensitive activity. Not “reduce it,” not “be careful” — stop. Every session you run between now and the patch is a session that the identifier can link. If you have ongoing sensitive communications, pause them or move them to a channel that does not rely on Tor Browser’s anonymity properties (in-person meetings, Signal from a burner device, encrypted email from a dedicated account on dedicated hardware — each has its own threats, choose based on your specific situation).

Day 2: Inventory your exposure

Write down, privately, the list of sensitive Tor Browser activities you have conducted on your current hardware in the past two years. Which pseudonyms did you use? Which sites did you post to? Which email accounts did you check? This is an honest assessment for your own planning; do not share it unless you have to, and if you have to, use a channel appropriate to the stakes.

For each item on the list, estimate: is there a plausible adversary who might have been collecting the identifier from the sites involved? For most public sites, the answer is that commercial data brokers may have been collecting fingerprints, and whether a given adversary has access to those brokers’ data is a question of the adversary’s resources. For sites that are themselves run by adversaries (honeypot forums, surveilled platforms), assume the data was collected.

Day 3: Acquire clean hardware if you need to

If your inventory includes activities that were high-stakes, you probably need clean hardware. A used laptop, purchased with cash, from a source the adversary cannot plausibly have surveilled, is the minimum. Do not use your normal email to buy it. Do not have it delivered to your home address. Do not turn it on at your home.

Install Tails on a USB stick purchased separately, also with cash, from a different store. Verify the Tails image signature using a machine other than the one you intend to run Tails on. This is tradecraft that feels paranoid until the first time it saves someone.

Day 4: Set up Qubes-Whonix if your threat model warrants it

For users whose threat model includes sustained, sophisticated adversaries — not a one-off campaign but ongoing surveillance — Qubes-Whonix on dedicated hardware is the best currently available defense. The setup takes a full day if you have not done it before. There are good guides on the Qubes and Whonix project sites. Do not cut corners on the hardware isolation; the whole point is that this machine has nothing to do with your identity.

Day 5: Rotate credentials, carefully

For any pseudonymous account you used via Tor Browser on compromised hardware, decide whether to: (a) abandon the pseudonym entirely and start fresh, (b) continue using the pseudonym from new, clean hardware and accept the risk of bridging old and new, or (c) lock the account and walk away. The right choice depends on the account’s value and on the specific threat. I generally advise (a) or (c) for high-stakes work, because (b) preserves a linkage risk that (a) and (c) eliminate.

Do not do this rotation from the compromised hardware. Do it from the new, clean environment.

Day 6: Re-establish communication with critical contacts

If you have sources, clients, contacts, co-organizers whose communication with you needs to continue, you need to re-establish those channels from clean hardware. This is the hardest step, because it requires both parties to do operational security properly, and because the very act of re-establishing a channel can be an observable signal.

For critical contacts, consider whether in-person re-establishment is possible. An exchange of Signal numbers in person, once, is worth a hundred encrypted emails.

Day 7: Plan for the next disclosure

This is the step that most people skip, and it is the one that matters most. This will happen again. Next year, there will be another disclosure. Your security posture needs to assume that the current set of defenses will fail, and to be structured so that a failure of any single layer does not catastrophically compromise you.

What that looks like concretely: separate hardware for separate identities, not just separate browser profiles. Separate network connections (a public Wi-Fi for pseudonym A, a different public Wi-Fi for pseudonym B, never crossing). Separate schedules (pseudonym A is active in the morning from location X, pseudonym B in the evening from location Y). Separate writing styles, if you are willing to invest in that — stylometry is a real deanonymization vector, though it is less urgent than fingerprinting for most users.

Plan now for a hardware replacement cycle. Hardware that has been used for sensitive work for two years is hardware whose fingerprint is in too many databases. Budget for replacement. Budget for destruction of the old hardware — physically, not just factory reset.

The honest summary

Browser-level anonymity was always a compromise. It traded the strong guarantees of VM isolation and physical separation for the convenience of a single binary that anyone could download and run. For fifteen years, that compromise was defensible, because the attacks that would break it were theoretical, or expensive, or only available to a handful of adversaries. The compromise worked, in practice, for most users most of the time.

That era is over. The attacks are no longer theoretical. They are no longer expensive. They are no longer limited to sophisticated adversaries. The commercial data broker industry has productized browser fingerprinting, which means that any adversary with a budget can buy access to historical fingerprint databases that span years. The Firefox identifier disclosed this morning will be patched, but the class of attack will not be, and the next one is already being researched in some lab I cannot name.

The path forward is not to abandon anonymity tooling. The Tor Project has done extraordinary work and will continue to. The path forward is to stop treating browser anonymity as the endpoint of the defense, and to start treating it as one layer in a stack that includes VM isolation, hardware separation, physical tradecraft, and — for the highest stakes — air gaps. The users who have been operating this way for years were correct. The users who trusted Tor Browser on personal hardware were operating on a reasonable assumption that turned out to be wrong.

If you are in one of the at-risk categories, please take this week seriously. The fact that most people reading this will not be directly affected does not reduce the urgency for those who will be. And if you know someone in one of those categories — a journalist friend, an activist relative, a source, a client — please forward this to them today. The patch is coming. It will not be enough.

I will be watching the disclosure discussion closely over the next several weeks, and I expect to publish a follow-up when the technical details of the identifier are public enough to describe precisely. Until then, assume compromise, act accordingly, and do not let the comforting announcement of a patch convince you that the underlying architecture has been fixed. It has not. It cannot be. And the sooner we internalize that, the sooner we can build the defenses that actually work.

Related Reading on CVE-2026-5281 and Browser Security

Our coverage of CVE-2026-5281 and adjacent browser/supply-chain security stories:

• CVE-2026-5281 Exploit Analysis Update — current patch status, exploit chain analysis, and detection rules (April 29, 2026)
• Chrome CVE-2026-5281 and the Expanding Browser Attack Surface — original technical deep dive
• GitHub RCE CVE-2026-3854: Source Code Trust Breakdown
• The Firefox Identifier That Links All Your Tor Identities
• Claude Mythos Found Thousands of Zero-Days — Vulnerability Management Implications
• NIST Giving Up on CVE Enrichment — Vulnerability Management Crisis