CVE WatchNov 4, 2026

CVE-2026-97701

Zulip is an open-source team collaboration tool. In Zulip Server versions through 12.1, the authenticated POST /messages/render endpoint ren

CVSS

6.5

Medium

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Nov 4, 2026 · Last modified: Nov 4, 2026 · CWE-770

EPSS · 30d

Not enough EPSS history yet.

Technical description

Zulip is an open-source team collaboration tool. In Zulip Server versions through 12.1, the authenticated POST /messages/render endpoint renders the content parameter without enforcing the normal message length limit used by message send and edit operations. An authenticated user can submit Markdown up to the server body-size limit, causing disproportionate backend CPU consumption, and repeated or concurrent requests can degrade Markdown rendering performance or backend availability for other users. This issue is fixed in version 12.2.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-553677.5 HIG

—

———h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit 4212ce114506a073505fd389db16ad2ba4e582a0, a client could send an incomplete CONNECT-UDP Capsule with an excessively large declared length, causing H2O to keep buffering received bytes without a per-Capsule limit while waiting for the remainder. Deployments that enabled proxy.connect-udp and accepted CONNECT-UDP requests could exhaust server memory and lose availability. This vulnerability is fixed with commit 4212ce114506a073505fd389db16ad2ba4e582a0.7h CVE-2026-118391—

—

———Allocation of Resources Without Limits or Throttling vulnerability in elixir-ecto ecto allows an unauthenticated remote attacker to exhaust memory in the application and in the database server by sending requests with distinct JSON keys or list lengths where the application interpolates them into json_extract_path/2, field[^key] or splice/1. Ecto caches prepared queries per repository in an ETS table with no size limit and no eviction. Interpolated JSON path elements become part of the query expression instead of its parameters, and splice/1 expands into one placeholder per element, so every distinct key or list length creates a new cache entry. With ecto_sql each entry is also a new prepared statement on the database connection that runs it. None of this memory is released until the processes restart. This issue affects ecto: from 3.4.0 before 3.14.3.15h CVE-2026-115448—

—

——0Uncontrolled recursion in Apache ZooKeeper. The server serializes its data tree to a snapshot by recursing one stack frame per znode level, with no depth bound. A client permitted to create znodes (the default root ACL is open) can build a chain of nested znodes deep enough that taking a snapshot exhausts the JVM stack and kills the snapshot thread; sizes stay within jute.maxbuffer, so existing limits do not prevent it. This is a denial of service that becomes persistent: on restart the server rebuilds the deep tree from its transaction log and fails again while taking the startup snapshot, so it does not return to service, and recovery can entail data loss. The same log affects a leader and its followers, so it can spread across an ensemble. This issue affects Apache ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6. Users are recommended to upgrade to 3.8.8 or 3.9.7, which fix the issue. As a workaround, use ACLs and authentication to restrict znode creation rather than relying on the default open root ACL.13h CVE-2026-100302—

—

——0Allocation of Resources Without Limits or Throttling in the multiRead request handler of Apache ZooKeeper allows a remote attacker to crash the server (denial of service) with a single small request. The multiRead handler places no limit on the number of bundled read operations or on the cumulative size of the response it builds in memory. Because each operation's result is fully materialized and retained before serialization, a request that is small on the wire — within the jute.maxbuffer limit — but that references a large znode many times can force the server to allocate far more heap than the request size implies, exhausting the JVM heap and terminating the server with an OutOfMemoryError. Neither jute.maxbuffer nor largeRequestMaxBytes prevents this, as both bound only the inbound request, not the response. This issue affects Apache ZooKeeper from 3.7.0 through 3.9.6. Users are recommended to upgrade to version 3.9.7, which enforces configurable limits on the multiRead operation count and cumulative response size.13h CVE-2026-621267.5 HIG

—

——0Allocation of Resources Without Limits or Throttling vulnerability in miniOrange SAML SP Single Sign On miniorange-saml-20-single-sign-on allows HTTP DoS.This issue affects SAML SP Single Sign On: from n/a through 6.1.0.13h CVE-2026-110944—

—

——0Resource exhaustion vulnerability in the HTTP request handling of the QHttpServer component of Qt HTTP Server.21h