洪 民憙 (Hong Minhee)

the cyberpunk present is weird as fuck: the latest Shai Hulud malware wave contains an LLM prompt to create biological weapons and nuclear weapons, with the purpose to trip LLM safety refusals so that LLM-based code scanning wont see the malware

https://socket.dev/blog/mini-shai-hulud-miasma-and-hades-worms-target-bioinformatics-and-mcp-developers-via-malicious

@silverpill Yeah, I think that is a fair distinction. Documentation and multicast ranges are not the main practical SSRF targets here, especially for ordinary HTTP fetching.

The practical risk is clearer for ranges like 100.64.0.0/10, 198.18.0.0/15, and IPv6 translation/tunneling prefixes, which can map to provider, VPN, lab, Kubernetes, or enterprise-internal networks. A request made by the Fedify server may reach something the attacker cannot reach directly.

For documentation ranges, the “in theory” case would be a non-compliant internal network using TEST-NET addresses. For multicast, I would mostly treat it as a correctness/fail-closed issue rather than a likely standalone exploit.

The security bug is that validatePublicUrl() was an SSRF boundary but did not enforce public/global address semantics. At that boundary, I do not think we should maintain a list of “non-public but probably harmless” exceptions. If it is not globally routable public address space, the fetch should be rejected.

@silverpill The dangerous case is not that every one of those ranges is equally exploitable. For example, the documentation ranges are mostly a correctness signal.

The real concern is that this function is an SSRF boundary. Once Fedify decides “this URL is public enough to fetch,” the request is made from the server's network, not from the attacker's network.

A realistic example would be a Fedify server running in an environment where 100.64.0.0/10 is used for provider, VPN, Kubernetes, or internal service networking. If an attacker can put a URL like https://100.64.0.10/... in a remote ActivityPub object or media URL, and Fedify classifies that address as public, the Fedify server may send a request to something only reachable from inside that deployment. That could be an internal HTTP service, proxy, metadata endpoint, admin panel, or just a host that reveals reachability through timing or errors.

Similar reasoning applies to ranges like 198.18.0.0/15 in lab or benchmarking networks, and to IPv6 translation/tunneling prefixes where an address can map back to a private IPv4 destination.

So I would not phrase it as “documentation or multicast addresses are always practical SSRF targets.” The issue is that a security check whose job is to allow only public internet destinations was accepting addresses that are not public internet destinations. For SSRF mitigation, that should fail closed: allow globally routable public addresses, reject the rest.

BotKit security updates: 0.3.4 and 0.4.3

If you use BotKit, update to a patched release now. CVE-2026-50131 affects Fedify's SSRF protection for remote document and media loading, and BotKit inherits the exposure through its dependency on Fedify.

Fedify validates remote ActivityPub document and media URLs before fetching them, including direct IP literals and hostnames resolved through DNS, to protect against Server-Side Request Forgery (SSRF). The vulnerable path is validatePublicUrl(): affected versions rejected common private and local addresses, but still treated several special-use IPv4 ranges—including carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks—as public internet destinations. An attacker could use these special-use IP address ranges to bypass Fedify's SSRF protections and cause a BotKit server to initiate requests to non-public or special-use network destinations, depending on the deployment environment and network routing.

The fix makes Fedify validate resolved addresses against public-network expectations instead of relying on the incomplete denylist. It rejects additional special-use IPv4 ranges before remote document or media fetching proceeds.

All versions of BotKit up to 0.3.3 (in the 0.3.x branch) and 0.4.2 (in the 0.4.x branch) are affected. Patched releases are 0.3.4 and 0.4.3.

For BotKit 0.4.x, update @fedify/botkit:

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

For BotKit 0.3.x, update @fedify/botkit:

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

After updating, redeploy. The GitHub Security Advisory is GHSA-xw9q-2mv6-9fr8, and the CVE ID is CVE-2026-50131. See also fedify-dev/fedify#796 for Fedify's own announcement.

Thanks to Chaitanya Vilas Garware for the report and responsible disclosure.

If anything is unclear, feel free to ask on GitHub Discussions or Matrix.

Hollo security updates: 0.7.18, 0.8.7, and 0.9.4

If you run Hollo, update to a patched release now. CVE-2026-50131 affects Fedify's SSRF protection, and Hollo depends on Fedify for ActivityPub federation.

Fedify guards against SSRF (Server-Side Request Forgery) when fetching remote ActivityPub objects, documents, and media by validating that the resolved destination is a public IP address. The previous SSRF fix (GHSA-p9cg-vqcc-grcx) blocked common private and local ranges such as 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, and 192.168.0.0/16, but the validation was incomplete—it still treated several special-use IPv4 ranges as public destinations that should have been rejected. These include carrier-grade NAT (100.64.0.0/10), benchmarking and internal testing networks (198.18.0.0/15), multicast (224.0.0.0/4), reserved (240.0.0.0/4), IETF protocol assignments (192.0.0.0/24), and documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).

An attacker who controls a remote ActivityPub object or media URL could therefore cause a Hollo instance to initiate outbound requests to non-public or special-use network ranges, depending on the deployment environment and network routing.

For full technical details of the underlying vulnerability, see the Fedify security advisory and the Fedify security announcement.

All Hollo versions up to and including 0.7.17, 0.8.6, and 0.9.3 are affected. Patched releases are 0.7.18 for the 0.7.x series, 0.8.7 for the 0.8.x series, and 0.9.4 for the 0.9.x series.

For 0.7.x deployments, update to 0.7.18:

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

For 0.8.x deployments, update to 0.8.7:

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

For 0.9.x deployments, update to 0.9.4:

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

After pulling the new image, restart your Hollo container. If you deploy from source, pull the corresponding release tag and restart.

Thanks to Chaitanya Vilas Garware for the report and responsible disclosure to the Fedify project.

If anything is unclear, ask below.

Fedify security updates: 1.9.12, 1.10.11, 2.0.20, 2.1.16, and 2.2.5

If you use Fedify, update to a patched release now. CVE-2026-50131 affects Fedify's public URL validation for remote document and media loading. An attacker could use special-use IP address ranges to bypass Fedify's SSRF protections and cause a Fedify server to initiate requests to non-public or special-use network destinations, depending on the deployment environment and network routing.

Fedify validates remote ActivityPub document and media URLs before fetching them, including direct IP literals and hostnames resolved through DNS. The vulnerable path is validatePublicUrl(): affected versions rejected common private and local addresses, but still treated several special-use IPv4 ranges as public internet destinations. That gap could allow outbound requests to ranges such as carrier-grade NAT, benchmarking, multicast, reserved, and documentation networks.

The fix makes Fedify validate resolved addresses against public-network expectations instead of relying on the incomplete denylist. It rejects additional special-use IPv4 ranges and IPv6 translation or tunneling prefixes, including NAT64, Teredo, and 6to4 addresses, before remote document or media fetching proceeds.

Current patched releases are 1.9.12, 1.10.11, 2.0.20, 2.1.16, and 2.2.5. The GitHub Security Advisory is GHSA-xw9q-2mv6-9fr8, and the CVE ID is CVE-2026-50131.

Update @fedify/fedify:

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

If your project depends directly on @fedify/vocab-runtime, update that package too.

After updating, redeploy. If you run other Fedify-based servers, update those too.

Thanks to Chaitanya Vilas Garware for the report and responsible disclosure.

If anything is unclear, ask below.

I wish Deno would keep doing what it does best by @hongminhee https://lobste.rs/s/cpyxnw #javascript
https://hackers.pub/@hongminhee/2026/i-wish-deno-would-keep-doing-what-it-does-best

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.

Just merged the commit graph feature branch

#Gitte

聯合宇宙(연합우주) 처음 始作(시작)한 건 아마 2017年頃(년경)? 트剩餘(잉여)에 計定(계정) 만들었다가 잘 適應(적응) 못 하고, mastodon.social로 갔던 것 같다. 그 뒤로 國漢文(국한문)으로 글 쓰는데 사람들이 읽기 不便(불편)하다고 하니까 國漢文(국한문)에 自動(자동)으로 <ruby>로 한글 讀音(독음) 붙게 하는 機能(기능)이 必要(필요)해서 直接(직접) ActivityPub 소프트웨어 具顯(구현)할 생각을 했고… 그 뒤로는…

聯合宇宙(연합우주) 처음 始作(시작)한 건 아마 2017年頃(년경)? 트剩餘(잉여)에 計定(계정) 만들었다가 잘 適應(적응) 못 하고, mastodon.social로 갔던 것 같다. 그 뒤로 國漢文(국한문)으로 글 쓰는데 사람들이 읽기 不便(불편)하다고 하니까 國漢文(국한문)에 自動(자동)으로 <ruby>로 한글 讀音(독음) 붙게 하는 機能(기능)이 必要(필요)해서 直接(직접) ActivityPub 소프트웨어 具顯(구현)할 생각을 했고… 그 뒤로는…

There's a Matrix room for #Fedify contributors, open to anyone curious about how development happens. Feel free to drop in or lurk; small questions are fine too.

#fedify-contributors:matrix.org

@edolnx Looks fine. Thanks!

@NigelGreenway Oh, Redmine! It's been so long to hear this name! Thanks for suggesting it.

Are there any F/OSS alternatives to issue trackers like JIRA or Linear? I'd like something that's easy to use and works well for both engineering and non-engineering teams.

사회복무요원이라 오픈소스 컨트리뷰션 아카데미 참여 꺼리신분들 참고하시면 좋겠습니다. 복무기관에 겸직허가만 되면 원활하게 참여 가능하다고 합니다.

Due to recent regulation changes (전기통신사업법), the South Korean government is requiring internet communities and forum owners to scan every user uploaded images and videos on their website, by AI.The hardware to run these AI models are also not provided by government, website owners have to buy datacenter grade Nvidia GPUs by themselves, putting financial pressure to small businesses and forums.

Websites will need to implement these hardware and software features, starting immediately from July 1st, which is just next month.

Here is the original image provided from Korean government, specifying the hardware requirements for AI models. I also added English translated image, made with nano banana (sorry for using ai for this...)

Related article (in Korean):

https://www.gameple.co.kr/news/articleView.html?idxno=215562

Post from Korean forum/news website(루리웹) owner, after listening briefing from Korean government, expressing how ridiculous the situation is:

https://bbs.ruliweb.com/community/board/300143/read/75437741?search_type=member_srl&search_key=7219

This feels really dystopian, even for South Korean standards.

Small fedi badge update: the service has moved to a new domain. Please update your badges to use fedi-badge.minhee.org instead of fedi-badge.deno.dev. The old domain will stop working in July.

I also shipped a couple of related changes. Badges can now show the logo of the software an instance is running, like Mastodon, Misskey, Pleroma, and a few others, detected via NodeInfo. If the software isn't recognized, it falls back to the generic fediverse logo.

The service also moved from Deno Deploy Classic, which is sunsetting, to Cloudflare Workers.

카라 불법 위탁처 엄중 수사 서명을 받고있는데 서명이 기대보다 저조합니다.
서명 아직 못하셨다면 서명 꼭 부탁드립니다.

https://buly.kr/1wVIbt

#카라노조 #카라지회 #동물권행동카라 #KARA #서명

Small fedi badge update: the service has moved to a new domain. Please update your badges to use fedi-badge.minhee.org instead of fedi-badge.deno.dev. The old domain will stop working in July.

I also shipped a couple of related changes. Badges can now show the logo of the software an instance is running, like Mastodon, Misskey, Pleroma, and a few others, detected via NodeInfo. If the software isn't recognized, it falls back to the generic fediverse logo.

The service also moved from Deno Deploy Classic, which is sunsetting, to Cloudflare Workers.

Tmw at the #gpn24 I will talk about what cool and awesome Activitpub/Fediverse project which are NOT (Social) Media or blogging (in german).
Some of the projects I will talk about will be:
https://codeberg.org/flohmarkt/flohmarkt
@manyfold
https://github.com/open-wanderer/wanderer
@encyclia
@fitpub
https://codeberg.org/54GradSoftware/menuverse

Do you have any other projects one should mention in the talk?
I only have 20min but I will try my best.

#fediverse #activitypub

VoidZero is joining Cloudflare

なるほど。漢語の「旅券」という表現が公式にはより好まれる一方、日常的にはカタカナの「パスポート」のほうが好まれるのですね。理解しました。

参考までに、韓国では「旅券(여권)」という表現だけを使い、「패스포트(パスポート)」と言っても普通は意味は通じますが、韓国語ではなく英語だという認識が強いです。

日本政府の公式名称は「旅券」です。問題なく通じます。ただ、公務員でない人達は知らないかもしれません。なにしろ旅券の普及率が低い国なので…。

んや、FediLUGの名前は残したいね

FediLUGもFediDev JPにしよかな

旅券でも通じる人はいるけれど、パスポートならまず通じるはず

@hongminhee あんまり使わないですね。旅券でも通じますが、一瞬チケットと混同します