Repository navigation
BotKit security updates: 0.4.11 and 0.5.8 #62
dahlia
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
If you use BotKit, update to a patched release now. GHSA-r48c-xx2h-fv4g is a DNS rebinding vulnerability in Fedify, which BotKit uses for federation. An attacker could bypass its server-side request forgery (SSRF) protection and cause your bot's server to reach internal services. Deno deployments need additional network restrictions; upgrading BotKit alone does not close the vulnerability on Deno.
Fedify checked that a hostname resolved only to public addresses, then let
fetch()resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection. This affects remote document loading, both anonymous and authenticated, as well as outbound activity delivery, NodeInfo lookups, and WebFinger lookups. Redirects and alternate-document links were subject to the same gap.On Node.js and Bun, the fix makes connections only to addresses that passed validation. Bun deployments that set
HTTP_PROXY,HTTPS_PROXY, orALL_PROXY, including their lowercase forms, should use Bun 1.4.3 or later. Alternatively, unset those variables for the bot process or configure the proxy to refuse private destinations. Earlier Bun versions can send requests through a proxy that resolves the hostname again. With the fix applied, HTTPS requests to non-default ports fail on Bun versions before 1.3.11 because those versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance.Deno's
fetch()cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented--deny-netlist covering private IPv4 ranges,[::1], and[::], and listen on a Unix domain socket behind a reverse proxy, since the deny list also blocks listening on those IP addresses. Private IPv6 ranges also need network-level restrictions. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation for the full deny list and deployment requirements.BotKit 0.4.x versions through 0.4.10 and BotKit 0.5.x versions through 0.5.7 include affected Fedify versions. The first releases containing the fix, and the current recommended releases, are BotKit 0.4.11 and 0.5.8, which upgrade Fedify to 2.1.31 and 2.3.15, respectively. These are the two supported BotKit lines under the security policy; users on older lines should move to a supported release.
For BotKit 0.5.x, install
@fedify/botkit0.5.8 using the command for your package manager:For BotKit 0.4.x, install
@fedify/botkit0.4.11:Check the installed or locked versions:
@fedify/botkitshould be 0.4.11 or 0.5.8. The affected Fedify packages,@fedify/fedify,@fedify/vocab-runtime, and@fedify/webfinger, should resolve to at least 2.1.31 on the 2.1.x line, 2.2.20 on 2.2.x, 2.3.15 on 2.3.x, or 2.4.5 on 2.4.x. Update any direct dependencies on those packages too. If you use a routine update command instead, check that your declared dependency range allows a patched release and change it explicitly if needed. Apply the runtime mitigations above and redeploy all web and worker processes.The full GitHub Security Advisory is GHSA-r48c-xx2h-fv4g. See also Fedify's own announcement.
Thanks to @finalchild for reporting the DNS rebinding issue to the Fedify project.
If anything is unclear, feel free to ask on GitHub Discussions or Matrix.
All reactions