Export limit exceeded: 17725 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3904 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-86146 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| Inconsistent interpretation of HTTP requests (HTTP request/response smuggling) in the bundled HTTP/1.1 parser of Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to smuggle requests and inject headers when bRPC is deployed behind a proxy or load balancer that parses the same bytes differently. Root Cause: The bRPC fork of http-parser accepts and acts on several HTTP/1.1 header forms that a conforming front-end either rejects or interprets differently, so the framing or the header set of a message can differ between the front-end and bRPC: 1. A space before the colon of framing headers (e.g. Content-Length : 5) is accepted; the value still drives bRPC's framing while the reported field name contains the trailing space. 2. Interior spaces inside a Content-Length value (e.g. Content-Length: 1 3) are skipped, so bRPC reads 13 where a front-end reads 1 or rejects the message (same class as CVE-2022-32213 in Node.js). 3. Obsolete line folding (obs-fold, RFC 7230 3.2.4) of Content-Length and Transfer-Encoding values is accepted, so a folded framing value drives bRPC's framing while a front-end that does not unfold sees a different message. 4. Chunked trailer fields are fed to the same header callbacks as the header section and are merged into the header map like real headers. A front-end only inspects the header section, so any chunked request can smuggle fields such as Authorization or X-Forwarded-For past it. 5. Transfer-Encoding lists with optional whitespace after a comma (e.g. Transfer-Encoding: gzip, chunked) are not recognized as chunked: such requests are rejected, and responses are read until connection close instead of as chunked, causing response desync. Affected Scenarios: bRPC server or client communicating over HTTP/1.1 with a front proxy, load balancer, or any peer that parses the message independently. An attacker able to send requests through the front-end can desynchronize the two parsers to smuggle requests, forge headers (e.g. Authorization, X-Forwarded-For) via chunked trailers, or desynchronize responses. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3521 Note: After applying the fix, the four header forms above are rejected by default and chunked trailers are dropped instead of merged into the header map. Two gflags are provided for compatibility: http_allow_obs_fold=true restores acceptance of folded Content-Length/Transfer-Encoding values, and http_strict_header_token=true additionally rejects spaces inside any header field name (not only the ones that decide framing). Legitimate clients that do not use these obsolete forms are unaffected. | ||||
| CVE-2026-86147 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time. Root Cause: 1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory. 2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time. Affected Scenarios: Any Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3523 Note: After the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner. | ||||
| CVE-2026-86249 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| On a brpc::Server that sets both ServerOptions.auth and ServerOptions.internal_port, the HTTP built-in service exemption on internal_port can be abused to bypass authentication entirely. VerifyHttpRequest() returns true without checking any credential when a built-in service is requested on internal_port, and this verdict is not per - request: verification runs only for the first message of a connection and the result latches the connection. Sending a request such as GET /status to internal_port first authenticates the whole connection, after which every subsequent request dispatched on the same connection is handled without ever calling VerifyHttpRequest(). This lets a remote attacker reach ordinary (non-built-in, non-tabbed) authenticated services without supplying valid credentials whenever the server uses ServerOptions.internal_port together with an Authenticator. The fix restricts internal_port so that it carries only built-in and Tabbed services; requests for ordinary services sent to internal_port are rejected with EPREM / HTTP 403. Mitigation / Fix: upgrade to 1.18.0 or apply PR https://github.com/apache/brpc/pull/3525 . Users who rely on serving normal services on internal_port must move those requests to the port passed to Server::Start(). | ||||
| CVE-2026-87849 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The Discovery naming-service reply parser in Apache bRPC (versions < 1.18.0) calls RapidJSON object-only accessors (FindMember) on JSON values without first validating that those values are objects. A malformed Discovery response whose data/service members or instances list contain non-object entries (e.g. a bare integer) triggers the RapidJSON object-access precondition on the client, reading memory out of bounds and potentially crashing the bRPC client. Root Cause: In src/brpc/policy/discovery_naming_service.cpp, DiscoveryNamingService::GetServers() and DiscoveryNames::ListDiscoveryNodes() access JSON values with member functions on non-object values. RapidJSON only defines these operations for object types; invoking them on a non-object violates the class invariant and results in undefined behavior (out-of-bounds read), commonly crashing the process. Affected Scenarios: An operator-configured (or compromised) Discovery backend returns a malformed /discovery/nodes or /discovery/fetchs response whose data/service/instance entries are not JSON objects, crashing any bRPC client that refreshes its server list. How to Fix: 1. Upgrade bRPC to version 1.18.0 or later, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3533 The fix validates that the Discovery response data, per-service data, and instance entries are JSON objects (and skips non-object node/instance entries and rejects non-object data/service values) before calling member accessors. | ||||
| CVE-2026-90484 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The MySQL client response parser in Apache bRPC dereferences a null pointer when the server peer sends a zero-payload-length response packet. A response packet whose declared payload length is zero is accepted by the frame-length check (is_full_package), after which the parser reads the response type byte via an unbounded 5-byte fetch that returns nullptr, and type = p[4] dereferences it, crashing the client process. Root Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf, buf.fetch(header, 5) returns nullptr when the buffered data only holds the 4-byte header of a zero-length packet, then the code reads p[4] (and, in the fast-auth path, p2[4]) without checking for a null or zero-length packet. Affected Scenarios: A brpc MySQL client connecting to a malicious or compromised MySQL server (or a MITM) can be crashed by a zero-length server response packet, resulting in denial of service of the client. Fix: The fix rejects zero-length response packets (returning PARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type determination and after a fast-auth marker, before reading the type byte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch at https://github.com/apache/brpc/pull/3536. | ||||
| CVE-2026-103634 | 1 Apache | 1 Datasketches | 2026-10-22 | N/A |
| Out-of-bounds read and write in the Count-Min sketch deserialization of Apache DataSketches C++ (repo: datasketches-cpp). count_min_sketch::deserialize() did not include the preamble in its input size check, so a truncated sketch could cause a read of up to 16 bytes past the end of the input. In addition, the table size was computed from the serialized number of buckets and number of hash functions in 32-bit arithmetic. A crafted sketch could make it wrap to zero, so that the sketch deserialized with an empty table, and later updates and estimate queries read and wrote outside the heap allocation. This can corrupt heap memory, causing a crash and potentially enabling further exploitation. This issue affects Apache DataSketches C++: from 4.1.0 before 5.3.0. Only applications that deserialize Count-Min sketches from untrusted sources are affected. Users are recommended to upgrade to version 5.3.0, which fixes this issue. | ||||
| CVE-2026-59229 | 1 Apache | 1 Iotdb | 2026-10-22 | N/A |
| The Legacy Pipe receiver protocol (handshake / sendPipeData) uses a hardcoded SUPER_USER (root) identity when executing data loading and deletion operations. A user with only SYSTEM-level privileges (such as USE_PIPE or MAINTAIN) who does NOT have WRITE_DATA or DELETE_DATA permissions on target databases can send specially crafted PipeData messages through the Legacy Pipe API, resulting in data loading/deletion operations executed as root — effectively bypassing IoTDB's permission model entirely. This issue affects Apache IoTDB: from 2.0.0 before 2.0.11. Users are recommended to upgrade to version 2.0.11, which fixes the issue. | ||||
| CVE-2026-58663 | 1 Apache | 1 Iotdb | 2026-10-22 | N/A |
| An authentication bypass vulnerability exists in Apache IoTDB's Thrift RPC service This issue affects Apache IoTDB: from 2.0.0 before 2.0.11. Users are recommended to upgrade to version 2.0.11, which fixes the issue. | ||||
| CVE-2026-59562 | 1 Apache | 1 Iotdb | 2026-10-22 | N/A |
| Missing authentication for critical function vulnerability in Apache IoTDB. This issue affects Apache IoTDB: from 2.0.0 before 2.0.11. Users are recommended to upgrade to version 2.0.11, which fixes the issue. | ||||
| CVE-2026-105869 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it. When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim. As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required. Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role. In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider. This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients. | ||||
| CVE-2026-105926 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected. An authenticated client without any permission on the target topic, namespace or tenant could use these commands to: - read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed. - register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator. The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first. This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. | ||||
| CVE-2026-105927 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Apache Pulsar WebSocket service allows a WebSocket consumer to configure a dead letter policy through query parameters of the consumer endpoint, including the deadLetterTopic parameter that names the topic to which messages are written after the maximum number of redeliveries is exceeded. When authorization is enabled, the WebSocket service checks only that the connecting user holds the CONSUME permission on the subscribed topic. It does not check whether the user holds the PRODUCE permission on the topic named in deadLetterTopic. The dead letter messages are then written by the WebSocket service using its own broker client identity rather than the identity of the connecting user. As a result, an authenticated user who holds the CONSUME permission on at least one topic can cause messages to be written to a topic of their choosing in any existing namespace, including namespaces belonging to other tenants, provided the role used by the WebSocket service to connect to the brokers is authorized to produce to that topic and the topic accepts a producer that registers no schema. The dead letter producer created by the WebSocket service registers no schema, so it is rejected when the target topic has a schema and schema validation is enforced for that topic or its namespace; this setting is not enabled by default. The same user is refused when attempting to produce to that topic directly. Where automatic topic creation is enabled, which is the default, the named topic is created if it does not already exist. The issue can only be triggered when the WebSocket service is enabled, either in the broker (webSocketServiceEnabled, which is disabled by default) or as a standalone WebSocket proxy. The impact is unauthorized injection of messages into topics the user is not permitted to produce to. The user can determine the content of the injected messages when they also control the messages on the subscribed topic. The issue does not allow reading, modifying or deleting existing messages in the target topic. Injected messages carry the dead letter message properties and a dead letter producer name, so they can be distinguished from messages produced normally; however, the values of these properties are not authenticated and should not be relied upon to establish the origin of a message. Whether an injected message has further consequences depends on how the applications consuming the target topic process it. Repeated injection also consumes storage and backlog capacity in the target namespace. This issue affects Apache Pulsar versions from 2.3.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately and do not require the WebSocket service should disable it. Where the WebSocket service is required, restricting network access to it and limiting the permissions granted to the role the WebSocket service uses to connect to the brokers to the namespaces WebSocket clients are intended to access reduces the exposure. | ||||
| CVE-2026-105930 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| When package management is enabled, Pulsar Functions, Sources and Sinks can be registered or updated from a package stored in the Pulsar Packages Management Service by supplying a package URL. The Pulsar Functions worker authorized these requests only against the namespace in which the component was being registered or updated. It did not check whether the requesting user was permitted to access packages in the namespace that the package URL refers to, and it retrieved the package from the broker using the worker's own credentials. The permission check of the Packages Management Service was therefore applied to the worker's identity instead of the requesting user's. Package URLs of transform functions supplied when registering or updating a sink were handled in the same way. An authenticated user who is permitted to register or update functions, sources or sinks in any namespace of their own tenant could use this to obtain the contents of a package stored in a namespace of another tenant, without having the packages permission on that namespace. The impact is limited to disclosure of package contents, which may include application code, business logic or embedded credentials. The issue does not allow packages to be modified or deleted and does not affect availability. This issue only affects deployments that have authentication and authorization enabled and in which package management has been enabled: the broker setting enablePackagesManagement and, in current releases, the functions worker setting functionsWorkerEnablePackageManagement. Both settings are disabled by default. This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. | ||||
| CVE-2026-105931 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected. As a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement. The disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint's error response can reveal whether a named topic exists in another tenant. The impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration. This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately and do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker's admin HTTP endpoints to trusted administrative clients reduces the exposure. | ||||
| CVE-2026-111809 | 2 Apache, Apache Software Foundation | 3 Apache Traffic Server, Traffic Server, Apache Traffic Server | 2026-10-22 | 9.3 Critical |
| Apache Traffic Server allows request smuggling via HEAD requests that carry Content-Length or Transfer-Encoding. This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. | ||||
| CVE-2026-96806 | 1 Apache | 1 Airflow Keycloak Provider | 2026-10-21 | 5.8 Medium |
| The Apache Airflow Keycloak auth manager did not end the session on logout: the logout route revoked the presented token, but `KeycloakJWTMiddleware` then issued a new, unrevoked token on the same response, so the user stayed logged in. Deployments using the Keycloak auth manager are affected: after a user logs out, anyone with later access to the same browser (for example on a shared workstation) can continue to act as that user. Users of apache-airflow-providers-keycloak are recommended to upgrade to apache-airflow-providers-keycloak 0.11.1 or later. | ||||
| CVE-2026-92287 | 1 Apache | 2 Arrow C++, Pyarrow | 2026-10-21 | 4.7 Medium |
| Pass-through of unvalidated KMS URLs to KMS clients in Apache C++ Parquet and PyArrow versions 4.0.0 to 25.0.1. This affects users who read Parquet files and configure Parquet decryption properties with a KmsClient implementation. On the reader side, the KMS URL can be application-controlled (specified in the KmsConnectionConfig) or file-controlled. If the user does not leverage application control for this parameter, a file-controlled KMS URL is forwarded to a pluggable KmsClient implementation. If the KMS implementation does not perform host validation and makes use of the provided KMS URL, a KMS token can be sent to a malicious host set by an attacker in the file. Users are recommended to upgrade to version 26.0.0, which disables this behavior by default and requires that users opt-in to it by enabling the read_kms_url flag in the DecryptionConfiguration. Users of affected versions are recommended to either specify the KMS URL in the KmsConnectionConfig when reading files, or ensure any KmsClient implementations validate received KMS URLs. Users that opt-in to file-controlled KMS URLs in version 26.0.0 and later must ensure KmsClients validate KMS URLs. | ||||
| CVE-2026-56449 | 2 Apache, Redhat | 2 Http Server, Hummingbird | 2026-10-21 | 7.5 High |
| Out-of-bounds Write vulnerability in Apache HTTP Server's mod_proxy_html with crafted HTTP response bodies. This issue affects Apache HTTP Server version 2.4.68. | ||||
| CVE-2026-101296 | 3 Apache, Apache Software Foundation, Redhat | 4 Apache Tomcat, Tomcat, Tomcat and 1 more | 2026-10-21 | 7.4 High |
| A missing critical step in authentication vulnerability in Apache Tomcat when the JNDI realm was configured with with a non GSSAPI SASL authentication mechanism allowed attackers to authenticate without providing the correct password. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.26, from 10.1.0-M1 through 10.1.60, from 9.0.0.M1 through 9.0.122. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.27, 10.1.61 or 9.0.123, which fix the issue. | ||||
| CVE-2026-108743 | 2 Apache, Apache Software Foundation | 2 Apache Kylin, Apache Kylin | 2026-10-20 | 8.8 High |
| Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Apache Kylin. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted. This issue affects Apache Kylin: from 4.0.4 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue. | ||||