洪 民憙 (Hong Minhee)

Hollo security updates: 0.8.16 and 0.9.24

If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.

For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.

For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.

For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.

For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.

Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.

The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.

The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.

For 0.8.x deployments, update to 0.8.16:

docker pull ghcr.io/fedify-dev/hollo:0.8.16

For 0.9.x deployments, update to 0.9.24:

docker pull ghcr.io/fedify-dev/hollo:0.9.24

After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.

If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.

Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.

If anything is unclear, ask below.

Hollo security updates: 0.8.16 and 0.9.24

If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.

For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.

For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.

For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.

For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.

Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.

The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.

The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.

For 0.8.x deployments, update to 0.8.16:

docker pull ghcr.io/fedify-dev/hollo:0.8.16

For 0.9.x deployments, update to 0.9.24:

docker pull ghcr.io/fedify-dev/hollo:0.9.24

After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.

If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.

Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.

If anything is unclear, ask below.

Hollo security updates: 0.8.16 and 0.9.24

If you run Hollo, update to 0.8.16 or 0.9.24 now. These releases fix GHSA-v2qh-w789-xxj6, a missing ownership check in status deletion, and include fixes for three vulnerabilities in Fedify that affect Hollo. They also include a fix for a fourth Fedify vulnerability whose affected API Hollo does not use.

For GHSA-v2qh-w789-xxj6, an authenticated client with the write:statuses scope could delete a post belonging to another local account or a cached remote post by its local UUID. The deletion response could also disclose the post's contents, including private content. This required an access token on the receiving Hollo instance. For remote posts, the affected record was Hollo's cached copy. The fix restricts both lookup and deletion to the account associated with the token and returns the existing not-found response for other accounts' posts. It first ships in 0.8.16 and 0.9.24; earlier releases on both supported lines, including 0.9.23, lack this check.

For GHSA-97w4-f4rq-mgqm, Fedify's document loaders followed alternate-document links from HTTP headers or HTML without preserving the redirect limit, visited-URL history, or cancellation signal. An unauthenticated inbox request pointing to an attacker-controlled signing-key URL could trigger an endless chain of outbound requests and DNS lookups, exhausting server resources. Alternate-document links now share the 20-hop limit and loop detection with HTTP redirects, and preserve cancellation. The first fixed Hollo releases were 0.8.13 and 0.9.20, incorporating Fedify 2.1.25 and 2.2.14. Earlier releases on those Hollo lines are affected.

For GHSA-4qhx-hhwf-8685, Fedify authenticated an incoming activity's actor but accepted an activity ID on a different origin. An attacker with an actor and signing key on a server they controlled could supply embedded objects claiming to live on another server. Depending on the application's own checks, those objects could be stored under forged IDs. Sending a forged activity with a genuine activity's ID first could also suppress the genuine delivery as a duplicate. No account on the receiving Hollo instance was required. The fix rejects activities whose IDs have a different origin from their actors before they enter the inbox queue or duplicate cache.

For GHSA-8863-8468-7hq7, Fedify checked whether an actor document listed a signing key, but did not require the document's ID to match the actor ID it requested. An attacker could have activities authenticated as a victim if fetching the victim's exact actor ID led to an actor document whose key the attacker controlled. This depended on the server hosting the victim's actor ID redirecting or serving that document; an arbitrary redirect elsewhere on the server was not enough. The fix requires an exact actor ID match. Hollo's built-in key cache automatically ignores entries stored under the weaker check and fetches and verifies those keys again, so operators do not need to clear it manually.

Both of these authentication fixes first reached Hollo in 0.8.15 and 0.9.23, incorporating Fedify 2.1.30 and 2.2.19. Earlier releases on the corresponding Hollo lines are affected. Install the newer 0.8.16 or 0.9.24 release to receive the status deletion fix too.

The other Fedify advisory, GHSA-39gj-rchc-q5m3, concerns Context.routeActivity(): after authenticating a fetched activity, it could queue or forward the caller's unverified copy. Hollo does not call this API, so its supported release lines are not exposed to this path. The dependency fix was nevertheless included in 0.8.14 and 0.9.21. For full technical details on the upstream issues, see the linked advisories and the October 4 Fedify announcement and October 16 Fedify announcement.

The supported Hollo release lines are 0.8.x and 0.9.x under the Hollo security policy. Operators on 0.7.x or earlier should move to a supported line.

For 0.8.x deployments, update to 0.8.16:

docker pull ghcr.io/fedify-dev/hollo:0.8.16

For 0.9.x deployments, update to 0.9.24:

docker pull ghcr.io/fedify-dev/hollo:0.9.24

After pulling the image, recreate your Hollo container using the new image. With Docker Compose, update the image tag in your Compose file and run docker compose up -d. For source deployments, check out the corresponding release tag, run pnpm install --frozen-lockfile with that tag's pinned pnpm version, run pnpm run build, and restart the server.

If you have a large 0.9.x database and are upgrading from a release before 0.9.20, follow the 0.9.20 index preparation instructions before starting the new version to avoid blocking writes during its automatic migration.

Thanks to Yami Odymel (@yamiodymel) for reporting the status deletion issue to Hollo, to Adel Zaitri (@adelzaitri) for reporting the alternate-document fetch chains to Fedify, and to ChanHaeng Lee (@2chanhaeng) for reporting the inbox activity origin mismatch to Fedify. The activity routing and actor document identity issues were found by the Fedify maintainers with AI assistance.

If anything is unclear, ask below.

If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in @fedify/fedify: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a flaw in the key ownership check that could authenticate activities as the wrong actor under specific actor-document configurations.

The releases containing both fixes are 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4. We recommend 2.4.4, or 2.3.14 if you are staying on the 2.3 line. Under the security policy, Fedify supports the latest two minor lines, currently 2.4 and 2.3. Backported fixes are also available in the releases listed above for 2.0, 2.1, and 2.2, but users on those older lines should plan to move to a supported line. Users on affected 1.x releases need to change their dependency to a supported 2.x release.

Inbox activity origin mismatch (GHSA-4qhx-hhwf-8685, medium, CVSS 6.5)

GHSA-4qhx-hhwf-8685 affects applications receiving activities through Fedify's inbox listeners. The inbox authenticated an activity's actor but accepted an activity id on an origin different from the actor's. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim.

Since version 1.9.0, Fedify's property accessors have trusted embedded objects whose IDs share the activity's origin. By choosing an activity ID on a victim server's origin, an attacker could make Create.getObject() and other accessors return forged objects claiming to live on that server without fetching them from it. Depending on the application's attribution and authorization checks, this could cause it to store or display forged content under another server's object ID.

The same missing check also let an attacker reserve a genuine activity's idempotency cache entry by submitting a forged activity with its ID first. The genuine delivery then received 202 Accepted but did not reach the listeners for one day. When a message queue was configured, the suppression applied across all inboxes on the receiving server. This behavior was confirmed in 1.8.15 and subsequent releases before the fixes; releases before 1.8 were not tested.

The first fixes shipped in 2.0.33, 2.1.29, 2.2.18, 2.3.13, and 2.4.3. Earlier releases on each of those 2.x lines are affected. Update to the newer releases recommended above to receive both fixes. The inbox now returns 401 Unauthorized for non-portable activities whose IDs have a different origin from their actors, before they reach listeners, the queue, or the idempotency cache. The same origin check applies to queued and manually routed activities. Setting skipSignatureVerification bypasses this protection along with signature verification.

Actor document identity mismatch (GHSA-8863-8468-7hq7, medium, CVSS 5.9)

GHSA-8863-8468-7hq7 lists the affected version range as <= 2.4.3, with fixes in 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 on their respective release lines. When confirming that a key belongs to an actor, Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested.

An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link to the attacker's document, including on another origin, or when the victim's server directly served a different same-origin actor's document. The attacker cannot normally arrange this: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. No account on the receiving Fedify server is required.

HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's id to exactly match the requested actor ID, in addition to the existing origin check. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Servers that normalize actor URLs should use the canonical actor ID as their keys' owner or controller and their activities' actor.

The built-in KvStore-backed key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If you supply a custom KeyCache implementation, clear it once when upgrading. Otherwise, previously cached false ownership claims can remain trusted after the upgrade. Downgrading to an earlier release is not safe.

Updating

Update @fedify/fedify using the command for your package manager:

npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify

Check the installed or locked version: it should be 2.0.34, 2.1.30, 2.2.19, 2.3.14, or 2.4.4 on the corresponding line. Update commands can stay within your declared dependency range. If that range excludes the recommended release, change it explicitly. For example, to move to 2.4.4:

npm  install @fedify/fedify@2.4.4
yarn add     @fedify/fedify@2.4.4
pnpm add     @fedify/fedify@2.4.4
bun  add     @fedify/fedify@2.4.4
deno add     jsr:@fedify/fedify@2.4.4

Clear any custom key cache as described above, then redeploy. If you run other Fedify-based servers, update those too.

The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7.

Thanks to @2chanhaeng for reporting the inbox activity origin mismatch. The actor document identity mismatch was found by the Fedify maintainers with AI assistance.

If anything is unclear, ask below.

DrFed is a web-based platform for developing and debugging ActivityPub implementations, built by the team behind Fedify.

Today we are releasing DrFed 0.1.0, our first release. It is an MVP: you can run DrFed locally, create test instances and actors, store test objects, and inspect incoming activity deliveries in the web UI.

To be honest, DrFed is not yet especially useful as an ActivityPub debugger. Much of the tooling we have planned is still ahead of us. We are releasing this version to make our progress visible and give you something you can install and try while development continues.

Install and sign in

DrFed 0.1.0 is available on npm as @drfed/drfed. You need Node.js 26 or newer. Install the package globally to make its four commands available on your PATH:

npm install --global @drfed/drfed@0.1.0

Create an account before starting the server, using the same data directory for both commands:

drfed-account create --data-path .pgdata \
  --email alice@example.com --name Alice
drfed-server --root-origin http://drfed.localhost:8888 \
  --data-path .pgdata --mail-log-content

Replace the email address and display name with your own. This example uses PGlite, so you do not need a separate database server. Account creation prepares the database, and the server applies pending migrations on startup. PGlite allows only one process to own its data directory, which is why account creation comes first.

Open http://drfed.localhost:8888, choose Sign in, and enter the email address you used above. The local example prints a login link in the terminal; follow it to sign in. The default mail transport does not deliver email, and --mail-log-content explicitly enables printing message contents for local testing. For a service deployment, configure SMTP or another supported mail transport instead.

The installation guide also covers installing into a local directory and running the commands with npx.

A workspace of test instances

After signing in, open Workspace and choose New instance. DrFed generates an identifier for the instance and gives it a subdomain of your configured root origin. Each instance runs as an ActivityPub server, with its own actors and inbox.

For example, with a root origin of https://drfed.example.com, an instance named example would live at https://example.drfed.example.com. The instance page lists its NodeInfo, WebFinger, and shared inbox endpoints, with copy buttons for using those URLs in your own tests.

The local setup above is useful for exploring the UI and making requests from your own machine. To receive requests from other servers, you need a publicly reachable deployment with wildcard DNS and HTTPS for the instance subdomains. A reverse proxy must preserve the original Host header. See the server README for the deployment details.

Generate actors and create objects

On an instance page, choose Actor and enter how many actors to generate. DrFed creates test identities with generated usernames. An actor's detail page shows its handle, identity, and federation endpoints, including its inbox and outbox. You can copy these addresses into requests from the ActivityPub application you are developing.

Choose Object on the instance page to create a Note or Article attributed to one of its actors. The form accepts an optional name, HTML content, and explicit ActivityPub addressing as JSON. For example, this addresses an object to Public:

{"to": ["https://www.w3.org/ns/activitystreams#Public"]}

The actor page lists its stored objects and shows their HTML as source text. Publicly addressed local objects and their Create activities are also available through ActivityPub, including the actor's outbox. Creating an object does not deliver it to remote servers. This is a way to prepare content for another implementation to fetch, rather than a general activity-sending tool.

Inspect incoming activity deliveries

When your application sends an activity to a DrFed instance's inbox, the instance's Activity log records the delivery. Each entry shows the activity type, status, sender and destination, and time. Expand an entry to inspect and copy the recorded JSON-LD; scroll up to load older entries.

This screenshot shows a deliberately unsigned test request. The inbox refused it with HTTP 401, and the log records it as unverified. Seeing a request in the log does not mean DrFed authenticated its sender or accepted its activity.

DrFed also stores eligible authenticated incoming Create activities containing Note or Article objects. Other activity types can be recorded without becoming stored objects. Delivery contents are restricted to instance members and administrators. The current UI lets you inspect recorded history; it does not yet provide live updates, search, or filters.

Four commands for running DrFed

The npm package includes the commands needed to run and maintain a deployment:

PGlite stores data in a local directory. You can instead select PostgreSQL with --postgres-url or its alias --database-url. Stop a PGlite server before using the account or migration commands against its data directory. To prepare and then check that database without starting the server:

drfed-migrate --data-path .pgdata
drfed-migrate --data-path .pgdata --check

All four commands accept an explicit TOML configuration file through --config, as well as the relevant DRFED_* environment variables. CLI options take precedence over environment variables, then TOML, then defaults. --print-config shows the effective settings and their sources with secrets redacted. See the configuration guide and CLI reference for the options, mail transports, and separate frontend setup.

Shell completions are available for Bash, zsh, fish, PowerShell, and Nushell. For example:

drfed-server completion bash > drfed-server-completion.bash
source ./drfed-server-completion.bash

Replace drfed-server with another command to generate its completion script. Installation does not activate completions automatically; the completion installation instructions explain persistent setup for each shell.

Current limits and documentation

This release has rough edges. Directly opening an instance detail page can terminate the installed server with a Seroval serialization error. We found this while preparing these notes and are tracking it in #132.

The broader debugging tools described in our project overview, such as a step-by-step signature debugger, JSON-LD comparison tools, and WebFinger/NodeInfo validators, are goals for the project. They are not available as dedicated tools in this release. The object creation form also does not yet send activities to arbitrary remote inboxes.

Our documentation is still incomplete and not yet organized into a systematic user guide. Some overview text describes the platform we intend to build, so it should not be read as a list of completed 0.1.0 features. For now, start with README.md, the CLI package README, and the installation and configuration pages under docs/.

In the next version, we will publish a Docker image alongside the npm packages, making it easier to run DrFed without setting up Node.js yourself.

Thanks, and what comes next

Thank you to the four people on the DrFed development team who have brought us to this first release, listed alphabetically:

• ChanHaeng Lee (@2chanhaeng)
• Hong Minhee (@hongminhee)
• Hyeonseo Kim (@gaebalgom)
• Jiwon Kwon (@z9mb1)

We also thank NLnet and the NGI0 Commons Fund for funding DrFed's development. Their support gives us time to build this free software tool for ActivityPub developers. You can read more on NLnet's DrFed project page.

We will keep working to make DrFed more useful for investigating federation failures. We hope you will follow the next stages of its development. Release history is kept in CHANGES.md.

The wall of configuration

For years I worked in Python and dreamed in Haskell on weekends. When I needed a script, Python. When I wanted the type system to hold me accountable, Haskell. Somewhere between the two sat TypeScript, and I knew it. Practical where Haskell is austere, typed where Python isn't. But I kept my distance. tsconfig.json, .eslintrc, .prettierrc, babel.config.js. Files you have to create before you've written a single line of actual code. Every time I thought about trying it, I looked at the list and gave up. The JavaScript ecosystem always felt to me like an amusement park where you have to wait in a long queue just to get inside.

Deno dissolved that queue. No configuration files, no node_modules, no agonizing over which package manager to use. Just deno run main.ts. The first time I actually wrote TypeScript properly, I couldn't understand why I'd put it off so long. What I'd been avoiding wasn't TypeScript. It was the ritual surrounding TypeScript.

What hooked me

At first I couldn't point to one killer feature. The appeal was that everything seemed to be pulling in the same direction. The fetch() I used in browsers worked the same way on the server. Web Crypto API was just there. MDN effectively became Deno's documentation. Instead of installing packages, you imported ESM by URL, thinking about dependencies in an entirely different way.

Having deno fmt, deno lint, deno test, deno bench, and deno check all in a single binary was part of the same logic. No installing ESLint, no wiring up Prettier, no untangling configuration conflicts between the two. That convenience had an attitude behind it.

The pattern was obvious enough: build on web standards, then ship the boring tools yourself.

Chasing Node.js

Today's Deno feels like it's drifting away from that.

npm: specifier support, node_modules back in play, node:* module compatibility. Then in Deno 2.8, deno add without a specifier now adds an npm package by default. JSR was introduced as an answer to npm's stagnation, as the future of JavaScript packaging. These decisions make that announcement look distant. I can understand each one in isolation. Put them together, though, and the shape is hard to ignore: Deno is spending more and more of its energy catching up to Node.js.

The OS/2 story comes to mind. IBM expected that building Windows compatibility into OS/2 would pull Windows users across. What actually happened was the opposite: developers realized they could target Windows and have it run on both platforms, so there was no reason to learn the OS/2 API separately. Deno pushing further toward Node.js compatibility has the same dynamic. The more compatible Deno becomes, the less reason library authors have to think about it specifically.

Meanwhile, Node.js has been walking toward Deno. TypeScript runs without flags as of v22. A permission model arrived in v20. fetch() and Web Crypto API are both there now. node:test and node:assert/strict have quietly become the best cross-runtime test harness for projects targeting Deno, Node.js, and Bun alike. The two runtimes are converging, but Deno seems to be doing more of the reaching.

Early Deno set the agenda. Web standards, the permission model, URL imports, JSR: Deno put these down and the ecosystem responded. What Deno is doing now runs in the opposite direction, catching up to what the ecosystem already has.

On the defensive

There's a more specific frustration here. Deno had a fight it could have led rather than chased.

What drove me away from the JavaScript ecosystem wasn't Node.js itself. It was the full combination: Node.js + npm + TypeScript + Vite + ESLint + Prettier + Vitest. That stack was the problem, and Deno was already doing well against it. deno fmt, deno lint, deno test, deno bench, deno check, and in 2.4, deno bundle came back. It had been deprecated once and then restored; that round trip is its own admission that the direction was right.

The most visible gap that remains is the dev server: HMR, live reload, an asset pipeline, and the plugin ecosystem that accumulates on top of all that. Fresh 2.0, Deno's own framework, chose not to fill that gap from within Deno and adopted Vite instead. That disappointed me. Making Vite run well on Deno and making Deno a self-sufficient development environment are two entirely different directions. Once your own framework makes that choice, you can't expect the wider ecosystem to go the other way.

But vertical integration alone might not have been enough. Individual component quality matters too. If deno lint and deno fmt were clearly better than ESLint and Prettier, developers would reach for them even in Node.js projects. That could have been the Trojan horse. Once enough projects are using Deno's tools without using the Deno runtime, the next question follows naturally. ESLint and Prettier seemed unmovable, and yet Biome and the Ox series (Oxlint, Oxfmt) are finding their footing. The market was always there. Better tools just weren't. Deno could have gotten there first.

The clock I keep thinking about

Why didn't Deno hold the course? This is speculation, but here's my read.

The integrated toolchain path required patience. Getting developers to feel the pain of configuration complexity, making Deno the place they move to, waiting for the ecosystem to grow comfortable with Deno's way of doing things. All of that takes time. Node.js is a community project under the OpenJS Foundation. There's no investor clock pushing it, and the project doesn't wobble if the ecosystem moves slowly.

Deno Land Inc. is different. A VC-backed company has a clock. How long that clock allows for a patient fight is not the same as what a community project can afford. Expanding Node.js compatibility produces visible results faster than the slow alternative. From the outside, I can't tell when I'm seeing a product decision and when I'm seeing a runway decision. What I can say is that the urgency Deno has been showing doesn't sit well with the direction it originally chose.

Even so

For all my griping, I still build most of my own libraries Deno-first. I publish to JSR even when I also publish to npm. I try to depend only on web standard APIs, and I use Deno's built-in tools for linting and formatting. I'm still rooting for Deno.

But even I have retreated in places. I now rely on node:test and node:assert/strict for testing, because it's the easiest way to run the same tests across Deno, Node.js, and Bun without any special dependencies. JSR was launched as an answer to npm's stagnation, and I've started to feel JSR stagnating too. I often catch myself wondering whether to drop it. I got excited about Deno KV and now I just use node:sqlite, which runs fine on Deno anyway.

If someone like me is already making these retreats, I wonder what Deno looks like to someone with no attachment to it at all. That worries me, because I still want Deno to win some version of this fight. I'm just less sure lately that Deno wants to win the same fight I signed up for.

We're making the Cloudflare developer platform the best place to run JavaScript, anywhere.

Big step toward that today: the Deno team is joining us to build what’s next.

https://blog.cloudflare.com/deno-joins-cloudflare

Two vulnerabilities have been fixed: GHSA-97w4-f4rq-mgqm, unbounded alternate-document fetch chains vulnerability and GHSA-39gj-rchc-q5m3, unverified activity routed after dereference verification vulnerability.

The patched releases are 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0. Both vulnerabilities affect the preceding releases on those lines: 2.0.28 and 2.0.29, 2.1.24 and 2.1.25, 2.2.13 and 2.2.14, 2.3.8 and 2.3.9. If you still use Fedify 1.x, change your dependency to patched 2.x release because package-manager update commands do not cross the declared major-version range.

Unbounded alternate-document fetch chains (GHSA-97w4-f4rq-mgqm, high, CVSS 7.5)

GHSA-97w4-f4rq-mgqm affects Fedify's document loaders when fetching remote keys and ActivityPub documents. Fedify follows alternate-document links supplied through HTTP Link headers and HTML, but following an alternate document reset the redirect counter and visited-URL history. An attacker could therefore make two URLs refer to each other as alternate documents and cause Fedify to fetch them indefinitely. Following an alternate link also dropped the caller's cancellation signal, so aborting the original operation did not stop the fetch chain.

An unauthenticated inbox request could exploit this by referencing an attacker-controlled signing-key URL. Resolving the key could then enter an unbounded alternate-document chain, continuously issuing HTTP requests and DNS lookups and eventually exhausting server resources. Both getDocumentLoader() and getAuthenticatedDocumentLoader() were affected, including their use in @fedify/vocab-runtime and @fedify/fedify.

The fix makes alternate-document links and ordinary HTTP redirects share the same 20-hop limit and visited-URL history. It also preserves the caller's cancellation signal throughout the entire fetch chain. This closes a gap left by the earlier redirect-loop fix for CVE-2026-34148.

Unverified activity routed after dereference verification (GHSA-39gj-rchc-q5m3, medium, CVSS 6.5)

GHSA-39gj-rchc-q5m3 has been present since Context.routeActivity() was introduced in Fedify 1.3.0. Context.routeActivity() verifies an activity before passing it to inbox listeners. When an activity has no verifiable Object Integrity Proof, Fedify dereferences its id and verifies the fetched copy. However, only the Activity object was replaced with the verified copy; the original, unverified JSON-LD document supplied by the caller was retained.

With an inbox queue configured, that unverified document was enqueued and later delivered to inbox listeners without being verified again. An attacker who knew the ID of any dereferenceable activity could therefore submit a document with the same ID but an actor, object, and addressing of their choice, causing the application to process attacker-controlled data as authenticated. Without a queue, listeners received the verified Activity object, but their InboxContext still contained the unverified document, which InboxContext.forwardActivity() could forward to other servers.

Applications that never call Context.routeActivity() are not affected. Activities successfully authenticated using an Object Integrity Proof are also unaffected, as is the HTTP inbox, which does not use this routing path.

The fix replaces both the Activity object and its JSON-LD document with the verified copy when Context.routeActivity() falls back to dereferencing. Inbox queues, InboxContext, and forwarding therefore all operate on the same document that was actually authenticated.

Updating

Update @fedify/fedify:

npm  update  @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update  @fedify/fedify
bun  update  @fedify/fedify
deno update  @fedify/fedify

Check if your resolved dependency versions are at least 2.0.30, 2.1.26, 2.2.15, 2.3.10, or 2.4.0 on the corresponding release line. Please redeploy every Fedify-based servers, after updating.

The full Github Security Advisories are GHSA-97w4-f4rq-mgqmand GHSA-39gj-rchc-q5m3.

Thanks to @adelzaitri for reporting unverified activity is routed after dereference verification issue.

Ask below if anything is unclear.