GHSA-2gc4-cqfq-p2gv: High severity npm/engine.io vulnerability

Published Sep 29, 2026
·
Updated

Impact

A denial-of-service vulnerability exists in Engine.IO / Socket.IO servers that allow transport upgrades.

The Engine.IO protocol revision is negotiated during the initial handshake and stored on the session, but a newly-created transport, including a WebSocket upgrade transport, could independently derive a different protocol revision from the upgrade request query parameters. The server did not verify that the protocol revision of an upgrade request matched the protocol revision of the existing session.

A malicious client could exploit this mismatch by establishing a valid Engine.IO session and then sending an upgrade request with a different, or omitted, EIO query parameter. This could cause the server to attach a transport using a parser and heartbeat behavior inconsistent with the session. Under some conditions, a crafted heartbeat packet could trigger an uncaught exception and terminate the Node.js process.

Servers using the default Engine.IO v4 protocol are impacted. The issue can be triggered even when Engine.IO v3 compatibility is disabled, because an omitted EIO parameter is interpreted as protocol v3 on the affected transport path.

The impact is denial of service through process crash.

Affected versions:

- engine.io >= 6.6.0, < 6.6.10

Patches

The issue was fixed in:

- engine.io 6.6.10

Users should upgrade to engine.io@6.6.10 or later.

If using Socket.IO packages that depend on Engine.IO, users should update to a Socket.IO release that includes the patched Engine.IO version.

Workarounds

If upgrading is not immediately possible, users can reduce exposure by disabling transport upgrades:

javascript const io = new Server(httpServer, { allowUpgrades: false });

or by allowing only a single transport, for example WebSocket only:

javascript const io = new Server(httpServer, { transports: ["websocket"] });

These mitigations avoid the vulnerable upgrade path, but they may affect client compatibility and connection behavior.

As an additional temporary mitigation, deployments may reject Engine.IO requests for an existing sid when the EIO query parameter is missing or does not match the protocol revision used during the initial handshake. This is best done at the application proxy or middleware layer only if the deployment can reliably track the session’s negotiated protocol.

Upgrading remains the recommended fix.

Affected Software

1 affected componentFixes available
npm/engine.io>=6.6.0<6.6.10
6.6.10

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/engine.io to a version that resolves this vulnerability.

    Fixed in 6.6.10
  2. Upgrade

    Upgrade engine.io to a version that resolves this vulnerability.

    Fixed in 6.6.10
  3. Configuration

    Disable transport upgrades by setting allowUpgrades: false; alternatively allow only a single transport such as transports: ["websocket"].

    Engine.IO allowUpgrades = false
  4. Compensating control

    At the application proxy or middleware layer, reject Engine.IO requests for an existing sid when the EIO query parameter is missing or does not match the protocol revision negotiated during the initial handshake.

Event History

Sep 29, 2026
Advisory Published
via GitHub·11:44 PM
Data Sourced
via GitHub·11:44 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to this denial-of-service condition?

Engine.IO / Socket.IO servers that allow transport upgrades and use the default Engine.IO v4 protocol are impacted. Disabling Engine.IO v3 compatibility does not prevent exposure.

2

What does an attacker need to do to trigger the issue?

An unauthenticated attacker can establish a valid Engine.IO session, then send an upgrade request whose EIO query parameter differs from the session protocol revision or is omitted. Under some conditions, a crafted heartbeat packet can then cause an uncaught exception that terminates the Node.js process.

3

Why is omitting the EIO parameter significant?

On the affected upgrade path, an omitted EIO parameter is interpreted as protocol v3. This can create a protocol mismatch even when the existing session negotiated the default v4 protocol and v3 compatibility is disabled.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203