CVE-2026-8446
published 2026-08-05CVE-2026-8446: IBM Langflow OSS 1.0.0 through 1.10.3 contain an authentication bypass vulnerability in the Model Context Protocol (MCP) composer endpoint when…
PriorityP349high7.5CVSS 3.1
AVNACLPRNUINSUCHINAN
EPSS
0.28%
20.6th percentile
IBM Langflow OSS 1.0.0 through 1.10.3 contain an authentication bypass vulnerability in the Model Context Protocol (MCP) composer endpoint when mcp_composer_enabled=true (default) and projects are configured with auth_type=oauth .
Affected
4 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| github.com | refraction-networking_utls | >= 0 < 1.7.0 | 1.7.0 |
| github.com | refraction-networking_utls | >= 1.0.0 < 1.7.0 | 1.7.0 |
| ibm | langflow_oss | 1.0.0 – 1.10.3 | — |
| langflow | langflow | >= 1.0.0 < 1.11.0 | 1.11.0 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls
osv·2025-04-24
CVE-2026-26994 ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls
Before version 1.7.0, utls did not implement the TLS 1.3 downgrade protection mechanism specified in RFC 8446 Section 4.1.3 when using a utls ClientHello spec. This allowed an active network adversary to downgrade TLS 1.3 connections initiated by a utls client to a lower TLS version (e.g., TLS 1.2) by modifying the ClientHello message to exclude the SupportedVersions extension, causing the server to respond with a TLS 1.2 ServerHello (along with a downgrade canary in the ServerHello random field). Because utls did not check the downgrade canary in the ServerHello random field, clients would accept the downgraded connection without detecting the attack. This attack could also be u
GHSA
uTLS ServerHellos are accepted without checking TLS 1.3 downgrade canaries
ghsa·2025-04-23
CVE-2026-26994 [MEDIUM] CWE-693 uTLS ServerHellos are accepted without checking TLS 1.3 downgrade canaries
uTLS ServerHellos are accepted without checking TLS 1.3 downgrade canaries
### Description
Before version 1.7.0, utls did not implement the TLS 1.3 downgrade protection mechanism specified in RFC 8446 Section 4.1.3 when using a utls ClientHello spec. This allowed an active network adversary to downgrade TLS 1.3 connections initiated by a utls client to a lower TLS version (e.g., TLS 1.2) by modifying the ClientHello message to exclude the SupportedVersions extension, causing the server to respond with a TLS 1.2 ServerHello (along with a downgrade canary in the ServerHello random field). Because utls did not check the downgrade canary in the ServerHello random field, clients would accept the downgraded connection without detecting the attack. This attack could also be used by an active net
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-72330 kernel: net/tls: Consume empty data records in tls_sw_read_sock()
bugzilla·2026-08-15·CVSS 7.5
CVE-2026-72330 [HIGH] CVE-2026-72330 kernel: net/tls: Consume empty data records in tls_sw_read_sock()
CVE-2026-72330 kernel: net/tls: Consume empty data records in tls_sw_read_sock()
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Consume empty data records in tls_sw_read_sock()
A peer may send a zero-length TLS application_data record; TLS 1.3
explicitly permits these as a traffic-analysis countermeasure (RFC
8446, Section 5.1). After decryption such a record has full_len ==
0. tls_sw_read_sock() hands it to the read_actor, which has no
payload to consume and returns zero. The loop treats a zero return
as backpressure (used <= 0), requeues the skb at the head of
rx_list, and stops. rx_list is serviced head-first on the next
call, so the empty record is dequeued, fails the same way, and is
requeued again; every later record on the connection is blocked
behin
Bugzilla
CVE-2026-55953 erlang/otp: Erlang/OTP ssl client: Authentication bypass via unoffered anonymous cipher suite acceptance
bugzilla·2026-07-27·CVSS 9.1
CVE-2026-55953 [CRITICAL] CVE-2026-55953 erlang/otp: Erlang/OTP ssl client: Authentication bypass via unoffered anonymous cipher suite acceptance
CVE-2026-55953 erlang/otp: Erlang/OTP ssl client: Authentication bypass via unoffered anonymous cipher suite acceptance
The Erlang/OTP ssl TLS 1.2 (and earlier) and DTLS client does not verify that the cipher suite selected by the server in ServerHello was among the suites offered by the client in ClientHello. The client-side tls_handshake:hello/5 handler validates the negotiated protocol version and the downgrade sentinel but hands the server-chosen suite directly to ssl_handshake:handle_server_hello_extensions/9, which installs it without a membership check. The TLS 1.3 client path performs this check (per RFC 8446), so it is not affected.
An on-path attacker between the client and the intended server can respond with a ServerHello selecting an anonymous key exchange suite such as TLS_
Bugzilla
CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records [epel-all]
bugzilla·2026-07-22·CVSS 6.5
CVE-2026-16317 [MEDIUM] CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records [epel-all]
CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records [epel-all]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
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
Bugzilla
CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records
bugzilla·2026-07-21·CVSS 6.5
CVE-2026-16317 [MEDIUM] CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records
CVE-2026-16317 s2n-tls: s2n-tls: Undetectable data loss via man-in-the-middle attack on TLS 1.3 records
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
2026-08-05
Published