CVE-2025-3200

Published Apr 28, 2025

Last updated 3 months ago

CVSS critical 9.1
SSL
Port (443)
Tls

Overview

Description
An unauthenticated remote attacker could exploit the used, insecure TLS 1.0 and TLS 1.1 protocols to intercept and manipulate encrypted communications between the Com-Server and connected systems.
Source
info@cert.vde.com
NVD status
Deferred

Risk scores

CVSS 3.1

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

Weaknesses

info@cert.vde.com
CWE-327

Social media

Hype score
Not currently trending

  1. Com-Server++ の深刻な脆弱性 CVE-2025-3200 が FIX：TLS 1.0／1.1 に対する中間者攻撃 https://t.co/6BU7Nt19dO Wikipedia で TLS のバージョンを調べてみたところ、TLS 1.0 は 1999年、1.1 は 2006年に制定され、最新の TLS 1.3 は

    @iototsecnews

    12 May 2025

    104 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. CVE-2025-3200 (CVSS:9.1, CRITICAL) is Awaiting Analysis. An unauthenticated remote attacker could exploit the used, insecure TLS 1.0 and TLS 1.1 protocols to intercept and manipupdate.

    @dufyijirkosa

    6 May 2025

    8 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  3. CVE-2025-3200 (CVSS:9.1, CRITICAL) is Awaiting Analysis. An unauthenticated remote attacker could exploit the used, insecure TLS 1.0 and TLS 1.1 protocols to intercept and manip..https://t.co/pIflke8jDO #cybersecurityawareness #cybersecurity #CVE #infosec #hacker #nvd #mitre

    @cracbot

    3 May 2025

    6 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-3200 - CRITICAL (9.1) - Wiesemann & Theis - Com-Server++. Unfortunately, the use of naughty crypto algorithms is still a thing 🔓🔑 https://t.co/ftODv7nKob https://t.co/KA1rZPfvfe

    @gothburz

    28 Apr 2025

    1 Impression

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 CVE-2025-3200 ⚠️🔴 CRITICAL (9.1) 🏢 Wiesemann & Theis - Com-Server++ 🏗️ 0.0.0 🔗 https://t.co/EMiI8TCRVo #CyberCron #VulnAlert #InfoSec https://t.co/5QTVilESyt

    @cybercronai

    28 Apr 2025

    30 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. [CVE-2025-3200: CRITICAL] Vulnerable TLS 1.0 and TLS 1.1 protocols could allow hackers to intercept and manipulate encrypted communications between Com-Server and connected systems.#cve,CVE-2025-3200,#cybersecurity https://t.co/iS4Xy0i1tc https://t.co/ECxYJ84E0m

    @CveFindCom

    28 Apr 2025

    57 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. �� CVE-2025-3200 - ZyXEL NBG6817 - HIGH 🚨 🗓️ Date published 2025-04-28 10:15:16 UTC #ZyXELNBG6817 #CyberSecurity #InfoSec #Vulnerability #TechNews https://t.co/jyTvX1tAwq

    @vulns_space

    28 Apr 2025

    29 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

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. SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability•CVE-2026-15409
  5. Microsoft SharePoint Deserialization of Untrusted Data Vulnerability•CVE-2026-58644

References

Sources include official advisories and independent security research.