CVE-2026-48933

Published Jun 26, 2026

Last updated 18 days ago

CVSS high 7.5
Tls

Overview

Description
A flaw in Node.js WebCrypto implementation can crash the process if the input of `subtle.encrypt()` is a multiple of 2GiB. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**.
Source
support@hackerone.com
NVD status
Modified
Products
node.js

Risk scores

CVSS 3.1

Type
Secondary
Base score
7.5
Impact score
3.6
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Severity
HIGH

CVSS 3.0

Type
Secondary
Base score
7.5
Impact score
3.6
Exploitability score
3.9
Vector string
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Severity
HIGH

Weaknesses

support@hackerone.com
CWE-190
0b0ca135-0b70-47e7-9f44-1890c2a1c46c
CWE-770

Social media

Hype score
Not currently trending

  1. After analyzing 66% of vulnerabilities from past week, CVE-2026-48933 has 9 articles published from different internet sources, no other cve has these many articles. More information here: https://t.co/SyyDujjO8C #vulnerability #CyberSecurity #ThreatIntel #CVE #SecurityAlert

    @stooee_

    4 Jul 2026

    34 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. ⚠️ Vulnerabilidades en productos Node.js ❗ CVE-2026-48933 ❗ CVE-2026-48618 ➡️ Más info: https://t.co/T7ozh8Eldm https://t.co/HuO8PJ3WnA

    @CERTpy

    2 Jul 2026

    206 Impressions

    1 Retweet

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Node.js、2026年6月のセキュリティリリースで12件の脆弱性を修正(CVE-2026-48933,CVE-2026-48618)他 https://t.co/9aJi3HQB4i #セキュリティ対策Lab #security #securitynews

    @securityLab_jp

    22 Jun 2026

    90 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. 🚨 Node.js patched all active LTS lines on June 18. CVE-2026-48618: IPv6 dots bypass TLS wildcard certs. CVE-2026-48933: WebCrypto AES crash, remote process abort. Patch to 22.23.0 / 24.17.0 / 26.3.1. How long before your team ships this?

    @dartilesm

    21 Jun 2026

    33 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. Node.js shipped 22.23.0, 24.17.0 and 26.3.1 on June 18, fixing 13 CVEs. Two are rated HIGH: CVE-2026-48933, a WebCrypto AES integer overflow that aborts the process, and CVE-2026-48618, a TLS wildcard-depth check fooled by a Unicode dot separator. Which release line do you run?

    @canartuc

    19 Jun 2026

    41 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. Node.jsが複数の深刻な脆弱性を修正。WebCrypto AESの整数オーバーフローCVE-2026-48933とTLSのホスト名取扱におけるUnicode中点の取扱不備CVE-2026-48618。その他脆弱性複数も修正されている。 https://t.co/mt8onCMwN7

    @__kokumoto

    18 Jun 2026

    412 Impressions

    0 Retweets

    2 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  7. Protect your servers with the latest Node.js security updates. Patch critical vulnerabilities like CVE-2026-48933 to secure your infrastructure today. #NodeJS #SecurityUpdates #Cybersecurity #CVE #WebSecurity https://t.co/NyM9rB2X29 https://t.co/gAz8IUJpzm

    @Daily_CyberSec

    18 Jun 2026

    345 Impressions

    1 Retweet

    3 Likes

    1 Bookmark

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16317
  2. The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16318
  3. In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.•CVE-2026-63978
  4. Bypass to the fix for CVE-2026-34916. Variants of such vectors have been also reported by phucrio and offsetmd. The fix can be bypassed either by sending a disallowed but otherwise valid plugin identifier as `type`, or using the `ox.setChannelTargeting` XML-RPC API method.•CVE-2026-50741
  5. A flaw in Node.js Permission API can cause a file metadata to be modified even on a path that was set as read-only with e.g. `--allow-fs-read`. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**.•CVE-2026-48935

References

Sources include official advisories and independent security research.