GHSA-2jf5-6wwv-vhxx

# Summary

A 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 affected

An 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.

# Remediation

1. Upgrade 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. 2. Rotate any secrets that were presence in environment variables (`process.env`) within affected environments including Inngest signing keys and event keys 3. Search 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 recommendations

Users 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-v6

### Workarounds

If 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.

### Resources

- Rotating Inngest keys: https://www.inngest.com/docs/platform/manage/rotating-keys - Inngest signing keys: https://www.inngest.com/docs/platform/signing-keys - Inngest event keys: https://www.inngest.com/docs/events/creating-an-event-key - Inngest security best practices: https://www.inngest.com/docs/learn/security

### Credits

- Ben Hylak - an independent security researcher, discovered and responsibly disclosed the vulnerability.