Vulnerabilities

Privilege escalation in Checkmk versions 2.5.0 before 2.5.0p9, 2.4.0 before 2.4.0p34, 2.3.0 before 2.3.0p49, and 2.2.0 (EOL) allows a local unprivileged user to execute arbitrary commands as root by starting a process crafted to look like a SAP HANA instance. Without an explicit database configuration, the mk_sap_hana agent plugin derives instance identifiers from the process list and uses them to build a command executed with elevated privileges (requires the plugin to run as root with RUNAS=agent).

The fix for CVE-2026-0716 (commit 6ff7ef0, libsoup 3.6.6) placed the integer overflow guard inside the if (masked) block, leaving unmasked server-to-client frames unprotected. A malicious WebSocket server can send a crafted unmasked frame with a payload length near UINT64_MAX to trigger an OOB read in a libsoup-based client when max_incoming_payload_size is set to 0.

A vulnerability has been identified in COMOS V10.4.5 (All versions

In Eclipse Jetty, an HTTP URI of this form:<br /> <br /> <br /> <br /> <br /> <br /> /public;/../admin/secret.txt<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> results in an unresolved path of:<br /> <br /> <br /> <br /> <br /> <br /> /public/../admin/secret.txt<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> instead of the expected:<br /> <br /> <br /> <br /> <br /> <br /> /admin/secret.txt<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Jetty itself is not affected, as it will not serve the secret.txt file because it will not pass the alias checker (only resolved resources are served).<br /> <br /> <br /> <br /> <br /> However, web applications that rely on resolved paths being provided by Jetty may be confused when receiving an unresolved path.

Eclipse Kura versions prior to 5.6.2 trust the client-supplied X-Forwarded-For HTTP header as the authoritative source of the client IP address in audit log entries. The org.eclipse.kura.web2 (Web Console) and org.eclipse.kura.rest.provider (REST API) components use this header as the primary IP source when initializing audit context, and org.eclipse.kura.jetty.customizer unconditionally installs Jetty&amp;#39;s ForwardedRequestCustomizer on all HTTP/HTTPS connectors, causing HttpServletRequest.getRemoteAddr() to reflect the attacker-controlled header value. An unauthenticated remote attacker can exploit this vulnerability to bypass IP-based brute-force protections — such as fail2ban — by spoofing the logged IP address to a non-routable value, allowing a brute-force attack to proceed undetected, or to cause a denial of service against a third party by injecting a victim&amp;#39;s IP address and triggering a ban on that address.

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP server to exhaust memory on the client host and cause a denial of service.<br /> <br /> The Mint.HTTP1.decode_headers/5 and Mint.HTTP1.decode_trailer_headers/4 functions in lib/mint/http1.ex accumulate every parsed response header and chunked-trailer field into a per-request list that persists across incoming TCP segments as request.headers_buffer, and only clear it when the terminating blank line is received. The section has no cap on the number of headers or on total bytes, and the underlying :erlang.decode_packet(:httph_bin, binary, []) parser is invoked with an empty option list so its per-line and per-packet size limits also default to unlimited.<br /> <br /> A malicious HTTP server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can stream complete header lines (or, after a chunked body, complete trailer lines) indefinitely without ever emitting the terminating blank line. The connection state grows without bound until the BEAM node is killed by the operating system&amp;#39;s out-of-memory handler, taking down the entire application that uses Mint as an HTTP client.<br /> <br /> This issue affects mint: from 0.1.0 before 1.9.2.

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.<br /> <br /> The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.<br /> <br /> A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.<br /> <br /> This issue affects mint: from 0.1.0 before 1.9.2.

In Eclipse BaSyx Java Server SDK versions 2.0.0-milestone-05 to 2.0.0-milestone-12, deployments using the MongoDB backend are vulnerable to an unauthenticated arbitrary file write through the AAS thumbnail API.<br /> <br /> <br /> <br /> <br /> The AAS thumbnail upload path accepted a client-controlled fileName request parameter and passed it through repository file handling as both a repository key and, during thumbnail retrieval, a local filesystem path. With the MongoDB file repository, the supplied filename was treated as an opaque GridFS key and was not normalized or restricted as a filesystem path. A remote attacker could upload thumbnail content using an absolute or traversal-style filename, then trigger thumbnail retrieval so that the uploaded bytes were written to the attacker-chosen path on the server filesystem.<br /> <br /> <br /> <br /> <br /> This could allow writing files anywhere the Java process has permission to write and may lead to remote code execution. The default InMemory backend is not affected by this specific path because it normalizes and restricts file paths to its temporary directory.<br /> <br /> <br /> <br /> <br /> The issue is fixed in Eclipse BaSyx Java Server SDK 2.0.0-milestone-13.

Insufficient Technical Documentation vulnerability in Apache Tomcat since the requirements to securely configure the EncryptInterceptor were not clearly documented.<br /> <br /> This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.23, from 10.1.0-M1 through 10.1.56, from 9.0.13 through 9.0.119, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109. Other versions that have reached end of support may also be affected.<br /> <br /> Users are recommended to upgrade to version 11.0.24, 10.1.57 or 9.0.120 which fix the issue.

Improper Handling of URL Encoding (Hex Encoding) vulnerability in Apache Tomcat&amp;#39;s rewrite valve allowed security constraint bypass for some configurations.<br /> <br /> This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.23, from 10.1.0-M1 through 10.1.56, from 9.0.0.M1 through 9.0.119, from 8.5.0 through 8.5.100. Other versions that have reached end of support may also be affected.<br /> <br /> Users are recommended to upgrade to version 11.0.24, 10.1.57 or 9.0.120, which fix the issue.

In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).<br /> <br /> <br /> <br /> <br /> This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).<br /> <br /> <br /> <br /> <br /> This mismatch can cause a number of problems that may be classified as vulnerabilities such as:<br /> <br /> <br /> <br /> * <br /> <br /> URI constructions (for example, for redirects -- this is typical for login pages)<br /> <br /> * <br /> <br /> Virtual host selection<br /> <br /> * <br /> <br /> Reverse proxying<br /> <br /> * <br /> <br /> Misleading logs<br /> <br /> * <br /> <br /> Etc.<br /> <br /> <br /> <br /> <br /> <br /> <br /> Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.

Multiple input validation vulnerabilities in the Snowflake Spark Connector (spark-snowflake) versions prior to 3.2.1 can allow attackers to exfiltrate OAuth client credentials, execute arbitrary SQL with the connector&amp;#39;s Snowflake role, or redirect COPY operations to attacker-controlled storage. An attacker could exploit these vulnerabilities by supplying a crafted OAuth token request URL, placing malicious files in an ingestion pipeline, injecting SQL via staging options in a shared Spark environment , or issuing runtime SET commands in a shared Spark-SQL session to inject arbitrary SQL into the SnowflakeFallbackCatalog&amp;#39;s option map, which executes under the cluster admin&amp;#39;s JDBC credentials. Successful exploitation may result in credential theft, unauthorized access to Snowflake account data, or privilege escalation within connected infrastructure.