GHSA-2jf5-6wwv-vhxx Inngest TypeScript SDK exposes environment variables via serve() handler on unhandled HTTP methods
SummaryA vulnerability in the Inngest TypeScript SDK versions `3.22.0` through `3.53.1` allows unauthenticated remote attackers to exfiltrate environment variables from the host process via the `serve()` HTTP handler.The `serve()` handler implements `GET`, `POST`, and `PUT` methods. Requests using `PATCH`, `OPTIONS`, or `DELETE` fall through to a generic handler that returns diagnostic information. A change introduced in `v3.22.0` caused this diagnostic response to include the contents of `process.env`, exposing any secrets, API keys, or credentials present in the environment.Who is affectedAn application is vulnerable if **all** of the following are true:It uses `inngest` SDK version `>= 3.22.0, <= 3.53.1` (inclusive)Its `serve()` endpoint is reachable via `PATCH`, `OPTIONS`, or `DELETE` requests.Please check your framework's implementation for the serve handler ([documentation](https://www.inngest.com/docs/learn/serving-inngest-functions)) to asses whether it handles these HTTP methods. Common vulnerable configurations include:Next.js Pages Router, which forwards all HTTP methods to the handler.Express via `app.use('/api/inngest', serve(...))`, which routes `PATCH` and `OPTIONS` to the handler by default.The following are **not** affected:Next.js App Router handlers that explicitly export only `GET`, `POST`, and `PUT`.Applications using the `connect` worker method.SDK versions `< 3.22.0` and `>= 3.54.0`, including all `4.x` releases.The vulnerability was responsibly disclosed by an Inngest user. At this time, there are no known reports of exploitation.RemediationUpgrade to `inngest@3.54.0` or later. The fix is backwards compatible with the `3.x` release line. The `4.x` line is also unaffected.Rotate any secrets that were presence in environment variables (`process.env`) within affected environments including Inngest signing keys and event keysSearch logs for any requests to your `serve` endpoints using the `PATCH`, `OPTIONS`, `DELETE` http methods to assess if any environment variables may have been exposed.Additional recommendationsUsers on platforms with long-lived deployments (e.g. Vercel, Cloudflare Workers) should be aware that prior deployments remain reachable at their immutable URLs and may continue to expose the vulnerability even after a new deployment is promoted. For example, Vercel offers security features such as "[Deployment Protection](https://vercel.com/docs/deployment-protection#standard-protection)" and [the ability to delete older deployments](https://vercel.com/kb/guide/how-do-i-delete-an-individual-deployment) which can help immediately mitigate impact.For additional security, users can also adjust firewall or proxy rules to only allow requests to their `serve` endpoint from Inngest IP addresses available here: http://inngest.com/ips-v4, http://inngest.com/ips-v6WorkaroundsIf upgrading is not immediately possible, restrict the `serve()` endpoint at the framework or reverse-proxy layer to accept only `GET`, `POST`, and `PUT`. The Inngest `serve()` endpoint does not require any other HTTP methods.ResourcesRotating Inngest keys: https://www.inngest.com/docs/platform/manage/rotating-keysInngest signing keys: https://www.inngest.com/docs/platform/signing-keysInngest event keys: https://www.inngest.com/docs/events/creating-an-event-keyInngest security best practices: https://www.inngest.com/docs/learn/securityCreditsBen Hylak - an independent security researcher, discovered and responsibly disclosed the vulnerability.
CVSS v3.1 score: 8.6