Security vulnerability in v3 TypeScript SDK

The Inngest team recently identified a critical security vulnerability in the inngest TypeScript SDK that potentially allows the exposure of environment variables through an application's serve endpoint for affected SDK versions. We have notified all affected users.

If you use an inngest TypeScript SDK version >= 3.22 and <= 3.53.1, please upgrade to v3.54.0 or greater and rotate your environment variables. See below for additional details.

In addition to this patch, we have shipped several additional changes to mitigate issues like this in the future as well as coordinated with other providers in an attempt to secure user's applications. We're sharing the full details of what happened, who is affected, steps you can take, and actions that we've taken to mitigate the issue.

What happened

On April 20th, 2026, an Inngest customer responsibly disclosed a vulnerability in the Inngest TypeScript SDK which could be leveraged to expose environment variables from an application. The Inngest team discovered the the issue originated in the v3.22.0 release version and was present through v3.53.1.

Within the Inngest SDK, the serve API is designed to handle GET, POST, and PUT methods to enable Inngest's servers to trigger actions within your application.

Each http method performs a specific action, otherwise a generic handler returned diagnostic information. v3.22.0 introduced a change that aimed to fix other issues by retaining a reference to environment variables (process.env) required later in the lifecycle of a request. The reference to these variables was linked to the diagnostic information object returned from the generic handler. This resulted in environment variables being potentially exposed through PATCH , OPTIONS , or DELETE http method responses from the serve endpoint.

View CVE-2026-42047 on Github.

Who is affected

Your application is current vulnerability if all of the below apply:

• Your application uses Inngest TypeScript SDK >= 3.22.0 and <= 3.53.1
• Your application has a serve endpoint
• Your application's serve endpoint is configured to handle PATCH, OPTIONS, or DELETE http methods.

Typically, any framework adapter that passes all http methods to the serve handler is vulnerable, but frameworks that use explicit mapping to http methods, like the Next.js App Router, are safe. We have included a few quick references for the most popular frameworks that are used with Inngest:

// Filename: /pages/api/inngest.js
// 🔴 Your application is affected w/ >= v3.22 && <= 3.52.1
export default serve({
  client: inngest,
  functions: [myFn],
});

// 🟢 Make your application safe
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  if (!["GET", "POST", "PUT"].includes((req.method || "").toUpperCase())) {
    return res.status(405).end(`Method ${req.method} Not Allowed`)
  }

  return serve({
    client: inngest,
    functions,
  })
}

// Filename: src/app/api/inngest/route.ts
// 🟢 Your application is safe
export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [myFn],
});

// 🔴 Your application is affected w/ >= v3.22 && <= 3.52.1
app.use("/api/inngest", serve({ client: inngest, functions: [myFn] }));

// 🟢 Your application is safe
app.use("/api/inngest", (req, res) => {
  if (!["POST", "GET", "PUT"].includes(req.method)) {
    return res.status(405).json({ message: "Method not allowed" });
  }
  return serve({ client: inngest, functions: [myFn] })
});

// 🟢 Your application is safe
const handler = serve({ client: inngest, functions: [myFn] });
app.get("/api/inngest", handler);
app.post("/api/inngest", handler);
app.put("/api/inngest", handler);

// 🔴 Your application is affected w/ >= v3.22 && <= 3.52.1
export default {
  fetch: serve({
    client: inngest,
    functions: [myFn],
    servePath: "/api/inngest",
  }),
};

// 🔴 Your application is affected w/ >= v3.22 && <= 3.52.1
app.use("/api/inngest", serve({ client: inngest, functions: [myFn] }));

Please note: Your framework may not be listed above, but you may be vulnerable, please review your code and what HTTP methods are used for your application.

Regardless of your framework, we strongly suggest you update your SDK.

Remediations

Update to v3.54.0 or greater of the SDK (npm link). This is backwards compatible with the 3.x line of releases, and is safe to roll out. v4.0 or greater does not have this issue.

Rotate environment variable secrets: We strongly recommend rotating all sensitive environment variables that may have been used in your application when you may have been running an affected version. This includes non-Inngest environment variables.

Rotate Inngest keys: In addition to all sensitive environment variables that are used in your application, we also strongly recommend rotating Inngest's signing key for all environments and event keys used in your application:

• Rotating keys
• Creating event keys
• Managing signing keys

Additional mitigations:

• Log analysis: If you have access to request logs, you may be able to search for any PATCH, DELETE or OPTIONS requests to your Inngest endpoint(s). This may allow you to assess if any malicious actor has exploited the vulnerability.
• Providers with long-lived deployments: If your hosting provider offers long-lived deployments that always exist at publicly accessible URLs, we strongly recommend taking precautions to either delete these previous deployments or enabling security features which some providers provide like “deployment protection” or firewall rules.
• Firewall rules: Inngest offers a list of IPs that you can use to configure your firewall, load balancer, or reverse proxy to allow list requests from Inngest servers, while denying all other traffic. The lists are provided at URLs on our website and will be updated as we add more IP ranges:
  • https://www.inngest.com/ips-v4
  • https://www.inngest.com/ips-v6

Response

Immediately upon report of the vulnerability, our engineers identified the root cause, verified the affected version range, developed a fix for the vulnerability, and published it to npm as v3.54.0. The team additionally investigated common patterns, identifying what frameworks or approaches would or would not be vulnerable.

While assessing the scope of impact across our user base, we decided to identify any user that may have ever deployed the affected version, even if these versions were not identified to still be in production usage. While many of these users may not have been vulnerable, e.g. by use of the App Route with serve, we could not confirm their approach used in their codebase, so we aimed to cast a wide net to inform users.

Throughout the next 48 hours we sent our a series of communications to our user base, prepped a live page to inform users of updates and coordinated with integration and marketplace partners in an effort to protect shared users. We also deployed new methods of notifying users through in-app banners and new alert emails.

Additional details

• The vulnerability was responsibly disclosed by an Inngest customer on Monday, April 20, 2026.
• Developers explicitly exposing only the 3 http methods leveraged by Inngest were not vulnerable.
• Only the Inngest TypeScript SDK was impacted. Python and Go SDKs were unaffected.
  • TypeScript SDK v4 is not affected.
• We are not aware of any known exploit. Server logs from users are the only way to be certain if your systems were ever exploited. If you have any report of this, please email security@inngest.com .
• We reached out to several partners who quickly offered support our analysis and mitigation efforts to protect our mutual users. Our partners deployed additional mitigations including automatically breaking builds with affected SDK versions and deployed firewall measures to block vulnerable http requests. We are grateful for their swift and effective response as partners.
• For the avoidance of doubt, the vulnerability never granted unauthorized access to Inngest's systems.
• The discovery is credited to Ben Hylak, an independent security researcher, who discovered and responsibly disclosed the vulnerability.

What we've changed to reduce future vulnerabilities

Security is Inngest's top priority, and we're constantly refining our processes to keep your applications and users protected.

• In addition to the vulnerability identified, our team performed an in-depth analysis of all of our SDKs, including Python and Go to determine any other potential security improvements. Additional mitigations have been released for the TypeScript SDK over the last few days.
• We have conducted an incident post-mortem and are making improvements to our processes both internally with security auditing and external security contractors.
• We have refreshed our security best practices in order to recommend best practices including Inngest IP allow lists for use with firewalls.
• We are expanding our existing vulnerability disclosure policy to add a structured bug bounty program to further incentivize reports.
• We have created new API endpoint for programmatically syncing apps. Additionally, we have introduced a new type of API key to enable you to sync apps from CI securely without
• This week we will be introducing a new audit trails feature, which will log actions on your account that you can view and search directly in the Inngest dashboard.

Closing

We truly apologize for the impact that this has caused our users. We're grateful for the response from our users so far and are dedicated to support you all in any way possible.

Our support team is available to answer any questions that you may have. Please don't hesitate to reach out to hello@inngest.com or create a support ticket.