WaratekVRT Sign in

High Java CVEs

6,285 CVEs, 87 exploited, 693 protected by Waratek

Reset
More filters
Columns
Overview 6,285 matches · 690 protected · 87 exploited · 31 CISA KEV · 188 public PoC · 118 EPSS ≥ 0.5
6,285matches 690protected11.0% 87exploited1.4% 31CISA KEV0.5% 188public PoC3.0% 118EPSS ≥ 0.51.9%
Protected by Waratek 693 11.0% Rule in development 3 0.0% Mitigation candidate 116 1.8% No exploit published 5,473 87.1%
Critical 0 0.0% High 6,285 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 690 11.0% partly blocked 3 0.0% not blocked 5,590 88.9% not established 2 0.0% unrecorded 0 0.0%
Exploited 87 1.4% Working exploit published 86 1.4% Proof of concept only 272 4.3% Forecast only 25 0.4% No public exploit 5,815 92.5%
split by peak 2,799 / year
No exploit published: 5,473Mitigation candidate: 116Rule in development: 3Protected by Waratek: 693 High: 6,285 not established: 2not blocked: 5,590partly blocked: 3blocked by ARMR today: 690 No public exploit: 5,815Forecast only: 25Proof of concept only: 272Working exploit published: 86Exploited: 87
19961 No exploit published1 High1 not blocked1 No public exploit1 19970 19980 19992 No exploit published2 High2 not blocked2 No public exploit2 20005 Mitigation candidate2 No exploit published3 High5 not blocked5 Working exploit published2 No public exploit3 20017 Protected by Waratek1 No exploit published6 High7 blocked by ARMR today1 not blocked6 No public exploit7 200211 Protected by Waratek1 Mitigation candidate2 No exploit published8 High11 blocked by ARMR today1 not blocked10 Working exploit published2 No public exploit9 20039 Mitigation candidate2 No exploit published7 High9 not blocked9 Working exploit published2 No public exploit7 20046 Protected by Waratek1 No exploit published5 High6 blocked by ARMR today1 not blocked5 No public exploit6 200530 No exploit published30 High30 not blocked30 No public exploit30 200666 Protected by Waratek4 No exploit published62 High66 blocked by ARMR today4 not blocked62 Exploited1 No public exploit65 200768 Protected by Waratek3 Mitigation candidate1 No exploit published64 High68 blocked by ARMR today3 not blocked65 Working exploit published1 No public exploit67 200846 Protected by Waratek3 Mitigation candidate1 No exploit published42 High46 blocked by ARMR today3 not blocked43 Exploited1 Working exploit published1 No public exploit44 200952 Protected by Waratek3 Mitigation candidate4 No exploit published45 High52 blocked by ARMR today3 not blocked49 Exploited1 Working exploit published4 No public exploit47 201027 Protected by Waratek2 Mitigation candidate1 No exploit published24 High27 blocked by ARMR today2 not blocked25 Exploited1 Working exploit published1 No public exploit25 201120 Protected by Waratek1 Mitigation candidate4 No exploit published15 High20 blocked by ARMR today1 not blocked19 Working exploit published5 No public exploit15 201229 Protected by Waratek2 Mitigation candidate2 No exploit published25 High29 blocked by ARMR today2 not blocked27 Exploited1 Working exploit published1 No public exploit27 201345 Protected by Waratek12 Mitigation candidate4 No exploit published29 High45 blocked by ARMR today12 not blocked33 Exploited4 Working exploit published3 Proof of concept only1 No public exploit37 201430 Protected by Waratek9 Mitigation candidate3 No exploit published18 High30 blocked by ARMR today9 not blocked21 Exploited3 Working exploit published3 No public exploit24 201542 Protected by Waratek8 Mitigation candidate1 No exploit published33 High42 blocked by ARMR today8 not blocked34 Proof of concept only1 No public exploit41 2016134 Protected by Waratek19 Mitigation candidate7 No exploit published108 High134 blocked by ARMR today19 not blocked115 Exploited1 Working exploit published11 Forecast only2 No public exploit120 2017338 Protected by Waratek41 Mitigation candidate4 No exploit published293 High338 blocked by ARMR today39 partly blocked2 not blocked297 Exploited7 Working exploit published4 Proof of concept only1 Forecast only1 No public exploit325 2018302 Protected by Waratek70 Mitigation candidate7 No exploit published225 High302 blocked by ARMR today70 not blocked232 Exploited4 Working exploit published6 Proof of concept only1 No public exploit291 2019332 Protected by Waratek36 Mitigation candidate8 No exploit published288 High332 blocked by ARMR today35 partly blocked1 not blocked295 not established1 Exploited8 Working exploit published4 Proof of concept only4 Forecast only2 No public exploit314 2020386 Protected by Waratek64 Mitigation candidate8 No exploit published314 High386 blocked by ARMR today64 not blocked322 Exploited5 Working exploit published6 Proof of concept only8 Forecast only5 No public exploit362 2021346 Protected by Waratek47 Mitigation candidate9 No exploit published290 High346 blocked by ARMR today47 not blocked299 Exploited8 Working exploit published4 Proof of concept only5 Forecast only7 No public exploit322 2022330 Protected by Waratek76 Rule in development1 Mitigation candidate8 No exploit published245 High330 blocked by ARMR today76 not blocked254 Exploited9 Working exploit published5 Proof of concept only36 Forecast only3 No public exploit277 2023355 Protected by Waratek70 Mitigation candidate13 No exploit published272 High355 blocked by ARMR today70 not blocked284 not established1 Exploited10 Working exploit published9 Proof of concept only53 Forecast only3 No public exploit280 2024255 Protected by Waratek47 Mitigation candidate12 No exploit published196 High255 blocked by ARMR today47 not blocked208 Exploited11 Working exploit published6 Proof of concept only23 Forecast only2 No public exploit213 2025212 Protected by Waratek27 Rule in development2 Mitigation candidate3 No exploit published180 High212 blocked by ARMR today27 not blocked185 Exploited6 Working exploit published1 Proof of concept only31 No public exploit174 20262,799 Protected by Waratek146 Mitigation candidate10 No exploit published2,643 High2,799 blocked by ARMR today146 not blocked2,653 Exploited6 Working exploit published5 Proof of concept only108 No public exploit2,680
19961999200220052008201120142017202020232026
6,285 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed. ‹ prev page 1 of 63 next ›
CVE Severity Published▾ Status Exploitation Description
CVE-2026-92684 High 2026-11-10 No exploit published No public exploit Missing Authentication for Critical Function in aggregation queries in Neo4j @neo4j/graphql 5.0.0 before 5.12.17 and 7.0.0 before 7.6.8 allows remote attackers to read protected data via GraphQL aggregation queries. Field-level @authentication is not enforced on string aggregates, which can return stored values verbatim, and connection-root aggregates bypass an entity's AGGREGATE authentication requirement, allowing unauthenticated callers to obtain aggregate results.
CVE-2026-8372 High 2026-11-10 No exploit published No public exploit A vulnerability that could allow an attacker to gain unauthorized access.
CVE-2026-4762 High 2026-11-10 No exploit published No public exploit A vulnerability to perform a privilege escalation attack on the server as a non-admin user.
CVE-2026-12964 High 2026-11-10 No exploit published No public exploit A vulnerability allowing for privileged escalation of the viewer account to gain administrator privileges.
CVE-2026-12963 High 2026-11-10 No exploit published No public exploit A vulnerability that could allow a viewer account to gain unauthorized access to network attached storage devices on the server.
CVE-2026-12389 High 2026-11-10 Protected by Waratek No public exploit A vulnerability that could lead to a high privileged authenticated user performing a remote code execution attack.
CVE-2026-82440 High 2026-11-09 Protected by Waratek No public exploit Description Nimbus instantiates the class named by a topology's `topology.scheduler.strategy` when scheduling it. The allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as "allow any class" when unset, and it had no entry in the shipped `defaults.yaml`, so unset was the shipped state. An authenticated submitter could therefore cause Nimbus to instantiate any class on the Nimbus classpath that has a no-argument constructor. Storm's own production artifacts contain classes with side effects suitable for this: instantiating `org.apache.storm.testing.InProcessZookeeper` starts a ZooKeeper server with its own threads and sockets and nothing closes it, and `org.apache.storm.LocalCluster` behaves similarly. Repeated submissions therefore consume threads, sockets and memory in the most privileged daemon in the cluster. Mitigation Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class. Note that this is a behaviour change: a cluster running an out-of-tree scheduler strategy without an explicit allowlist will have those topologies refused until the class is added to `nimbus.scheduler.strategy.class.whitelist`. The rejection message names the refused class and the configuration key. Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to the strategies they intend to permit.
CVE-2026-82436 High 2026-11-09 No exploit published No public exploit Description `DefaultStateSerializer`, used to persist and restore stateful bolt checkpoints, configured Kryo with class registration disabled and an instantiation strategy that constructs objects without invoking their constructors, then deserialized whatever bytes the state store returned. A party able to write to the topology's keyspace in the state store, for example a co-tenant of a shared Redis instance or anyone with network access to it, could therefore place a serialized object graph that executes code inside the worker JVM when the state is restored. This requires the Redis-backed state provider, which is not the default. Write access to a state-store key is a data-plane privilege; code execution in the worker JVM is not, so the two are not equivalent. Mitigation Upgrade to 3.1.0, where the state serializer requires registered classes. Note that this is a behaviour change for existing state: checkpoints written by an affected version may fail to restore, and a migration step may be required. Users who cannot upgrade immediately should restrict network and credential access to the state store to the cluster itself. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
CVE-2026-12977 High 2026-11-09 No exploit published No public exploit A flaw was found in the deployment-operation family of WildFly Core. Certain handlers, such as upload-deployment-url, lack proper sensitivity classification, allowing an administrator with the restricted "Maintainer" role to read sensitive configuration files. This can lead to the exfiltration of credentials and full administrative control (SuperUser) of the server.
CVE-2026-123770 High 2026-11-09 No exploit published No public exploit Allocation of Resources Without Limits or Throttling vulnerability in Apache Axis2/Java. The multipart/form-data and application/x-www-form-urlencoded message builders read the request body directly from the transport stream with no size limit, so the servlet container's post-size limit did not apply, and multipart temporary files were not deleted. An unauthenticated caller could exhaust memory or disk. Version 2.0.2 bounds these bodies with configurable limits and deletes temporary files. This issue affects Apache Axis2/Java: through 2.0.1. Users are recommended to upgrade to version 2.0.2, which fixes the issue.
CVE-2026-120367 High 2026-11-09 No exploit published No public exploit Allocation of Resources Without Limits or Throttling vulnerability in Apache Axis2/Java. The JSON message builders, including the Gson, Moshi and HTTP/2 variants, buffered the entire request body with no size limit, so an unauthenticated caller could exhaust server memory with a large JSON request. Version 2.0.2 bounds JSON request bodies with the configurable jsonMaxRequestSize parameter. This issue affects Apache Axis2/Java: through 2.0.1. Users are recommended to upgrade to version 2.0.2, which fixes the issue.
CVE-2026-85111 High 2026-11-06 No exploit published No public exploit Allocation of Resources Without Limits or Throttling in Apache James Mime4J library prior version 0.8.15 allows Denial of Service upon parsing Mime messages. Users are recommended to upgrade to Apache James server 3.9.1 that relies on fixed MIME4J 0.8.15 which addresses the issue. See CVE-2026-85108 in Apache James MIME4J library.
CVE-2026-85108 High 2026-11-06 No exploit published No public exploit Allocation of Resources Without Limits or Throttling in Apache James Mime4J library prior version 0.8.15 allows Denial of Service upon parsing Mime messages. Users are recommended to upgrade to version 0.8.15 which fixes the issue by enforcing new limits and providing better defaults.
CVE-2026-97847 High 2026-11-05 No exploit published No public exploit A flaw was found in the protocol mapper and identity resolution components of Keycloak. The issue occurs when a client manager uses hardcoded-claim mappers to override identity claims in sessionless service-account tokens. Because these tokens lack a session ID, Keycloak may incorrectly resolve the token bearer as a different, highly privileged user based on the manipulated claims. This can allow an attacker with limited client management permissions to impersonate a realm administrator and gain full control over the realm.
CVE-2026-96453 High 2026-11-05 No exploit published No public exploit A flaw was found in the Keycloak Admin CLI kcadm tool, which is used by administrators to manage Keycloak servers from the command line. When a custom truststore is provided to verify the server identity, the tool incorrectly accepts any self-signed certificate as long as the hostname matches. This allows a network attacker to impersonate the Keycloak server, steal administrative credentials, and perform unauthorized management actions.
CVE-2026-93998 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML adapter component of Keycloak, which is used to secure applications with SAML-based authentication. The adapter fails to verify that the issuer of a signed SAML assertion matches the expected identity provider configured for the application. If multiple identity providers share the same trusted signing key, an attacker who controls one of those providers can create a validly signed assertion to log into the application as any user, potentially gaining full administrative control.
CVE-2026-92857 High 2026-11-05 No exploit published No public exploit Keycloak provides a Dynamic Client Registration feature that allows users with specific tokens to register their own applications. A flaw in how Keycloak validates these registration requests allows an attacker to create a malicious application that forges identity information. By mapping their own user profile details to protected fields like the user ID (sub) or intended audience (aud), an attacker can generate signed security tokens that make them appear to be a different user. This could allow an attacker to impersonate other users or gain unauthorized access to services that rely on these tokens for identity verification.
CVE-2026-92855 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML identity broker component of Keycloak, which is used to delegate authentication to external identity providers. The issue occurs because the broker fails to verify that a user actually possesses the private key associated with a holder-of-key assertion. An attacker who intercepts a victim signed assertion can replay it to gain unauthorized access and impersonate the victim without needing their private key.
CVE-2026-82965 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML implementation of Keycloak, an open-source identity and access management solution. The SAML Artifact Resolution and ECP SOAP endpoints do not properly limit the size or complexity of incoming XML requests. An unauthenticated remote attacker can exploit this by sending specially crafted, large XML messages that cause the server to consume excessive memory. This leads to the application running out of memory and crashing, resulting in a denial of service for all users.
CVE-2026-73095 High 2026-11-05 No exploit published No public exploit Allocation of Resources Without Limits or Throttling vulnerability in Apache Juneau. The MessagePack parser, which the REST server enables by default, sizes buffers from length values in the input. An unauthenticated client can send a few bytes that force a multi-gigabyte allocation and an OutOfMemoryError, causing denial of service. Related unbounded allocations in REST request handling (multipart uploads and request reader buffers) are fixed at the same time. This issue affects Apache Juneau: through 9.2.0. Users are recommended to upgrade to version 9.2.1, which fixes the issue.
CVE-2026-114232 High 2026-11-05 No exploit published No public exploit A flaw was found in the UserManagedPermissionService of the Keycloak authorization server. The UMA Protection API, which manages user permissions, fails to validate the resourceType field when a user creates a new policy. This allows an attacker to create a policy that applies to resources owned by other users, potentially leading to unauthorized access or modification of sensitive data across the entire realm.
CVE-2026-112208 High 2026-11-05 No exploit published No public exploit A flaw was found in the Organization identity-first login flow of the Keycloak authentication server. Keycloak is an open-source identity and access management solution used to secure modern applications and services. The issue occurs when an attacker who belongs to multiple organizations initiates a login and then switches to a registration or password reset path. During this process, a flag indicating a successful login is not properly cleared when the user is removed from the session. An attacker can then provide a victim's username, and the system incorrectly treats the stale flag as proof of the victim's identity. This allows the attacker to bypass authentication and gain full access to the victim's account and connected applications.
CVE-2026-110932 High 2026-11-05 No exploit published No public exploit A flaw was found in the theme resource endpoint of Keycloak, an open-source identity and access management solution. The issue occurs because the server fails to validate theme names before using them as keys for an on-disk gzip cache. An unauthenticated attacker can exploit this by sending many requests with unique, fabricated theme names, leading to persistent disk space exhaustion that survives server restarts and causes service disruptions.
CVE-2026-110931 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML 1.1 assertion parser of Keycloak, a tool used for identity and access management. The issue occurs when the parser handles a specific element called AuthorityBinding within an authentication statement. Due to an incomplete fix for a previous vulnerability, the parser can enter an infinite loop that consumes all available memory, causing the entire Keycloak service to crash and become unavailable to users.
CVE-2026-109408 High 2026-11-05 Protected by Waratek No public exploit vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0.
CVE-2026-107912 High 2026-11-05 No exploit published No public exploit A flaw was found in the management interface of the Quarkus framework, specifically within the quarkus-vertx-http component. The issue occurs when the framework incorrectly combines the management root path with specific permission rules, leading to a situation where security policies are applied to the wrong internal paths. As a result, an attacker can bypass intended authorization checks and gain unauthorized access to sensitive management endpoints.
CVE-2026-107602 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML 1.1 XML parsing logic of Keycloak, an open-source identity and access management solution. The issue occurs when the parser encounters unexpected elements within a security token's key information section, causing the processing thread to enter an infinite loop. An unauthenticated remote attacker could exploit this by sending specially crafted requests, leading to 100% CPU usage and a total denial of service that requires a server restart to resolve.
CVE-2026-107123 High 2026-11-05 No exploit published No public exploit A flaw was found in the SAML XML processing component of Keycloak, an open-source identity and access management solution. The issue occurs when the server parses XML documents containing excessively long dateTime or duration values. Because these strings are not properly validated before processing, the XML parser consumes excessive CPU time. An unauthenticated remote attacker can exploit this by sending specially crafted SAML requests to the server, leading to high CPU utilization and a denial of service for all users.
CVE-2026-103112 High 2026-11-05 No exploit published No public exploit A flaw was found in the authentication session handling of the keycloak-services component in Keycloak. The issue occurs because the system fails to verify if an authenticator is valid for the current authentication flow when switching between the standard authentication path and the reset credentials path. An authenticated attacker can exploit this by triggering a race condition during the credential reset process to associate their successful authentication state with another user's session. This can result in the attacker gaining full access to the victim's account and changing their password.
CVE-2026-115448 High 2026-11-04 No exploit published No public exploit Uncontrolled 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.
CVE-2026-111822 High 2026-11-04 No exploit published No public exploit Improper invalidation of cached authorizations vulnerability in Apache ActiveMQ, Apache ActiveMQ Runtime Config. After the runtime configuration plugin removes a principal's write grant on a destination, an authenticated connection opened before the change can keep sending to that destination, including through a new anonymous producer, while fresh connections and new explicit producers are denied. This issue affects Apache ActiveMQ: from 6.0.0 before 6.3.3, before 5.19.12; Apache ActiveMQ Runtime Config: from 6.0.0 before 6.3.3, before 5.19.12. Users are recommended to upgrade to version 6.4.0, 6.3.3 or 5.19.12, which fixes the issue.
CVE-2026-111821 High 2026-11-04 No exploit published No public exploit Improper input validation vulnerability in Apache ActiveMQ, Apache ActiveMQ KahaDB. A user can create a durable subscription with a clientId and subscription name that have a combined length > 65,535 (while separately being shorter) on a broker using KahaDB which can cause the broker to shutdown and be unrecoverable.  This issue affects Apache ActiveMQ: from 6.0.0 before 6.3.3, before 5.19.12; Apache ActiveMQ KahaDB: from 6.0.0 before 6.3.3, before 5.19.12. Users are recommended to upgrade to version 6.4.0, 6.3.3 or 5.19.12, which fixes the issue.
CVE-2026-106554 High 2026-11-04 No exploit published Proof of concept only One CBOR-parsing issue in jackson-dataformats-binary's CBOR module: an unbounded run of CBOR tags drives quadratic-time TagList growth (CPU/GC-exhaustion DoS, PoC-proven). PoC executed against com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.18.2; present in current 2.x and 3.x (tools.jackson.dataformat.cbor) HEAD. Distinct from the Avro and Smile/Protobuf advisories for this repo. Quadratic CPU/GC DoS from an unbounded chain of CBOR tags (PoC-proven). File: cbor/src/main/java/.../cbor/CBORParser.java (tag handling -> TagList). CBOR permits a data item to be preceded by any number of semantic tags. The CBOR parser accumulates them in a TagList whose backing array grows by a fixed increment (+8), not by doubling, and re-scans/copies on each growth. An attacker sends a value preceded by a long run of tag bytes; the fixed-increment growth makes accumulating N tags O(N^2) in time (plus GC pressure), with no cap on the number of stacked tags. PoC (executed, JDK 17): feeding a CBOR stream consisting of a long run of tag bytes (e.g. tag 0xC0+) before a trivial value forces quadratic CPU/GC; parse time grows super-linearly with the tag count, pinning a request thread with no configurable limit. Impact. Algorithmic-complexity denial of service (CWE-407): a modest input of stacked tags consumes quadratic CPU/GC, pinning a request thread; concurrent requests exhaust the pool. Fix. Grow TagList by doubling and/or cap the number of stacked tags (StreamReadConstraints-style).
CVE-2026-100302 High 2026-11-04 No exploit published No public exploit Allocation 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.
CVE-2026-100300 High 2026-11-04 No exploit published No public exploit Improper handling of exceptional conditions in the quota subsystem of Apache ZooKeeper allows an attacker able to write under the /zookeeper/quota subtree — unauthenticated on default deployments, where that subtree is world-writable — to crash the server's critical request-processing thread and render the on-disk data directory permanently unbootable. This issue affects Apache ZooKeeper up to and including 3.9.6. Users are recommended to upgrade to version 3.8.8 or 3.9.7, which fixes the issue.
CVE-2026-100252 High 2026-11-04 No exploit published No public exploit Improper Authorization vulnerability in Apache ZooKeeper. When SASL authentication is enabled on the client port, the server's SASL callback handler grants every authorization identity (authzid) that a client requests, without checking it against the principal the client authenticated as. The server then tries to replace the requested identity with a canonical form of the authenticated principal, derived from the zookeeper.security.auth_to_local rules. If no rule applies to the principal, canonicalization fails and the error is only logged. The client-requested authzid then becomes the session's SASL identity for all ACL checks. An authenticated client whose principal is not covered by the auth_to_local rules can therefore claim any SASL identity. With the default rules, this includes any Kerberos principal from a realm other than the server's default realm, such as a principal from a cross-realm trusted realm. The client then gets the permissions granted to that identity in sasl ACLs. If the requested identity matches a configured zookeeper.superUser, it gets superuser access to the whole data tree. Users are recommended to upgrade to version 3.8.8 or 3.9.7, which fixes the issue.
CVE-2025-11229 High 2026-11-04 No exploit published No public exploit The system fails to properly enforce scope authorization when the `authorize_all_scopes` configuration is enabled. This allows applications using the client credentials grant type to obtain all API scopes, including sensitive internal and console scopes, without requiring explicit authorization, bypassing intended access controls. Exploitation of this vulnerability can lead to privilege escalation, enabling unprivileged clients to perform unauthorized administrative actions, access confidential organizational data, and potentially achieve full account takeover in deployments where the `authorize_all_scopes` configuration deviates from its default disabled state.
CVE-2026-46487 High 2026-11-03 No exploit published No public exploit GeoNetwork is a catalog application to manage spatially referenced resources. From 4.0.0-alpha.1 until 4.2.16 and 4.4.11, the Elasticsearch-backed search proxy can skip GeoNetwork's access-control filter injection when a client request has an omitted query field. The request is then forwarded to Elasticsearch without group visibility, draft exclusion, record ownership, or portal-specific filtering. An unauthenticated remote attacker can use the affected public search API to retrieve the full indexed contents of metadata records that should not be publicly visible. This issue is fixed in versions 4.2.16 and 4.4.11.
CVE-2026-39379 High 2026-11-03 No exploit published No public exploit GeoNetwork is a catalog application to manage spatially referenced resources. From 3.0.0 until 4.2.15 and 4.4.10, requesting a nonexistent or unauthorized service URL can cause an error page to reflect attacker-controlled request content inside an AngularJS application without adequately neutralizing it for template evaluation. A remote attacker can induce a victim, including an administrator, to open a crafted link so the reflected value is evaluated as an AngularJS template expression. Combined with known AngularJS sandbox-escape techniques, this can execute arbitrary JavaScript in the victim's authenticated browser session, disclose information, or perform actions as the victim. This issue is fixed in versions 4.2.15 and 4.4.10.
CVE-2026-119724 High 2026-11-03 Protected by Waratek No public exploit ** UNSUPPORTED WHEN ASSIGNED ** Improper restriction of recursive entity references in DTDs ('XML entity expansion') vulnerability in Apache JClouds. This issue affects Apache JClouds: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
CVE-2026-118489 High 2026-11-03 No exploit published No public exploit In Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users — the documented pattern of a per-user `WebClientSession` over a shared caching client — a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking.
CVE-2026-118487 High 2026-11-03 No exploit published Proof of concept only In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service.
CVE-2026-2613 High 2026-11-02 Protected by Waratek No public exploit The Admin REST API accepts user-supplied input without adequately sanitizing it, allowing it to be included in the structure of SQL statements. A user with administrator privileges can exploit this by influencing the structure of executed SQL statements, enabling blind SQL injection to infer database information and potentially impact the availability of the database service.
CVE-2026-110535 High 2026-11-02 No exploit published No public exploit Improper Privilege Management vulnerability in Apache Syncope. AuthProfile self-updates allow non-admin users to configure impersonation for WA surrogate authentication. This issue affects Apache Syncope: from 3.0.12 through 3.0.16, from 4.0.0-M0 through 4.0.8, from 4.1.0-M0 through 4.1.3. Users are recommended to upgrade to version 4.0.9 / 4.1.4, which fix this issue.
CVE-2026-95863 High 2026-11-01 No exploit published No public exploit Improper neutralization of input during web page generation in Apache Wicket. Apache Wicket generates JavaScript that refers to the elements it renders, and writes into that JavaScript two values it derives itself: a component's markup id, and the input name of a form component, which is built from component ids. Both are placed inside single-quoted JavaScript string literals without being escaped for that context, so a value containing a single quote or a backslash ends the literal, and what follows is parsed as script and runs in the application's origin when the page loads. A markup id is the value passed to org.apache.wicket.Component#setMarkupId(String), or the id attribute written in the component's markup, or an id Wicket generates, in that order. The first two are supplied by the application in an HTML context, where both characters are legal and where Wicket escapes them correctly when it writes the same value into the id attribute of the element; a generated id cannot contain either. An input name is derived from the ids of the components between the form and the form component, and a component id was rejected only for ':' and '~'. In org.apache.wicket:wicket-core on 9.x and 10.x, org.apache.wicket.markup.head.OnEventHeaderItem#forMarkupId(String, String, CharSequence) quotes the id it is given into a Wicket.Event.add call, and components in both wicket-core and wicket-extensions reach it through #forComponent(Component, String, CharSequence). On every affected version, org.apache.wicket.markup.html.form.Form writes its markup id and the id of its hidden-fields container into such literals, org.apache.wicket.markup.html.form.FormComponentUpdatingBehavior writes an input name, and org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes two markup ids and an input name. On 8.x, Form also writes an input name into the action of a submitting link, and on 8.x and 9.x Form#appendDefaultButtonField writes an input name into a name attribute with no escaping at all, so a value containing a double quote escapes the attribute into markup. org.apache.wicket:wicket-extensions is affected in its own right and not only through wicket-core: AjaxEditableLabel, AjaxIndicatorAppender, AjaxDisableComponentListener, UploadProgressBar, KittenCaptchaPanel, Palette, FilterForm and, on 9.x and 10.x, TrapFocusBehavior and AjaxListPanel each build their own JavaScript containing a markup id. An application is affected where a markup id or a component id carries one of those characters. Wicket does not put one there itself, so the value comes from the application: an id set on a component, an id attribute in a template, or a component id derived from data. None of those is a JavaScript context from the application's point of view. The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does not prevent this. The generated script is written into a script element carrying the per-response nonce, so the injected code is part of a script the policy admits. The fixed versions check an id where it enters instead of escaping each place it is written. A component id and a markup id may no longer contain a quote, a backquote, a backslash, braces, angle brackets, a semicolon, an ampersand or a control character, and a markup id may not contain parentheses or square brackets either; a component constructed with such an id, or given such a markup id, fails with an exception. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-84231 High 2026-11-01 No exploit published No public exploit Improper neutralization of input during web page generation in Apache Wicket. org.apache.wicket.markup.html.link.ExternalLink builds a JavaScript click handler and writes it into the tag's onclick attribute whenever the markup tag the component is bound to is not an a, link or area element. The URL held in the component's model is concatenated into a single-quoted JavaScript string literal in that handler without being escaped for that context. The same happens on the neighbouring branch, taken when popup settings are attached, where the value is concatenated into the window.open() call built by org.apache.wicket.markup.html.link.PopupSettings#getPopupJavaScript(). The only escaping applied is the markup escaping that every attribute value receives as the tag is written, which replaces an apostrophe with a character reference. A browser decodes character references in an attribute value before it compiles the event handler, so the apostrophe is restored, closes the string literal, and the rest of the model value is executed as script in the application's origin. An application is affected where it binds an ExternalLink to a markup tag that is not an anchor, such as a button or a span, and the URL in the model holds data an attacker can influence, which is the ordinary use of the component rather than a misuse of it. Nothing runs until a user activates the element. This issue affects Apache Wicket: from 8.0.0 through 8.19.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, which fixes the issue.
CVE-2026-84170 High 2026-11-01 No exploit published No public exploit Allocation of resources without limits or throttling in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource is the server side of the form-less upload offered by FileUploadToResourceField, which posts the selected files to a separately mounted resource rather than through a Form. The resource is an application-wide singleton with no component to consult, so newResourceResponse() takes the three limits that bound the upload - the total request size, the maximum size of a single part and the maximum number of parts - from the request parameters maxSize, fileMaxSize and fileCountMax, and hands them to the multipart parser as they arrive. Nothing binds those numbers to the field that is supposed to be uploading. A request naming a very large maxSize is therefore parsed with no effective ceiling on the total size, and omitting fileMaxSize and fileCountMax leaves the per-part and part-count limits unset as well. The values the application configured through FileUploadToResourceField#setMaxSize(), #setFileMaxSize() and #setFileCountMax() are consulted only when the client omits the corresponding parameter, so against a client that supplies one they have no effect at all. Parts above the parser's in-memory threshold are spooled to the container's temporary directory, and the file parts are then copied into the folder the application's IUploadsFileManager owns, under a sub-folder the request names, where they remain. A part that is not a file is read into the heap in full while the request is parsed. One request, repeatable, can therefore consume as much disk or as much heap as the client chooses to send. The resource carries no authorization annotation and the default authorization strategy permits every resource request, so unless the application authorizes the resource itself the request needs no authentication, no session, no prior page view and no user interaction. An application is affected where it uses FileUploadToResourceField, or mounts FileUploadResourceReference itself. This is not the ordinary upload path: the resource is a singleton that has to be created and mounted deliberately. An application that configures no upload limit at all loses nothing, because Wicket applies no total-size limit of its own by default; what the defect removes is a limit the application set. Uploads through Form with FileUploadField, and through AjaxFileDropBehavior, are not affected, because both read their limits from the component rather than from the request. The upload resource does not exist in the 8.x line. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.9.1. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-83594 High 2026-11-01 No exploit published No public exploit Memory allocation with an excessive size value in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction. UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application. An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-83559 High 2026-11-01 No exploit published No public exploit Improper encoding or escaping of output in Apache Wicket. org.apache.wicket.core.util.string.JavaScriptUtils#escapeQuotes() replaces each single quote in its input with a backslash and a single quote, and each double quote with a backslash and a double quote, so that the value can be placed inside a JavaScript string literal. It does not escape the backslash, which is the character that has to be escaped, and escaped first, for the rest of that escaping to hold. A value that already holds a backslash immediately before a quote therefore ends up with two backslashes in front of that quote: the first escapes the second, the quote itself is left unescaped, and it closes the literal. Whatever the value carries after that point is no longer text but JavaScript, and it runs in the application's origin and in the session of the user looking at the page. The method is public, is not deprecated, and its documentation states that its result can be part of a JavaScript call such as an alert; the only limitation it notes concerns JSON values, which need different escaping. An application is affected wherever it calls the method itself and places the result inside a JavaScript string literal, from its own code or from a component of its own or of a third party, and the value it escapes holds data an attacker can influence. There is no further condition, and no component of Wicket has to be involved: the application is using the method for what its documentation offers, and the method does not deliver it. Two components shipped with Wicket Extensions pass a value through the method. org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel writes the editor's first error feedback message into a single-quoted JavaScript string literal in the Ajax response, so an application is affected through that component where the message shown for a failed edit holds data an attacker can influence, whether that is the submitted value itself or another variable the application sets on the validation error. A validation message can carry the submitted value, because input is a message variable that every form component supplies for its own validation errors, and the documentation shows overriding a validator's message to include it; none of the message bundles shipped with Wicket interpolates it, so an application that has not written such a message is not affected through this component. org.apache.wicket.extensions.ajax.markup.html.repeater.AjaxListPanel passes the serialized markup tag of an appended component through the method and is not affected: the tag comes from the panel's own markup file, and a quote in any of its attribute values, the component's markup id included, is written as a character reference by the tag serialization and cannot close the literal. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-83539 High 2026-11-01 No exploit published No public exploit Improper neutralization of input during web page generation in Apache Wicket. org.apache.wicket.extensions.markup.html.basic.SmartLinkLabel and org.apache.wicket.extensions.markup.html.basic.SmartLinkMultiLineLabel display a text value and turn any URL they find in it into a hyperlink. Both escape the model value and then hand the escaped text to org.apache.wicket.extensions.markup.html.basic.DefaultLinkParser, which searches it for anything of the form scheme://rest and wraps each match in an anchor whose href is the matched text, copied in as it is. The pattern accepts any scheme, and there is no list of permitted schemes anywhere on the path. A text value naming a scheme that executes script therefore becomes an anchor that executes it, in the application's origin and in the reader's own session, when the reader clicks the link. Rendering the page is not enough on its own; the link has to be activated. Escaping does not prevent this and is not the issue: the characters the payload needs are all valid in a URL and are ones that org.apache.wicket.util.string.Strings#escapeMarkup() leaves alone, and the value ends up in a URL rather than in element text, which is a context that escaping model data does not make safe. An application is affected where it renders text it received through either of these two components. That is what they are for: they exist to linkify email addresses and web URLs found in the data an application is displaying, so untrusted input is the purpose of the feature rather than a misuse of it, and no unusual configuration is involved. No other component uses this parser, and an application that uses neither SmartLinkLabel nor SmartLinkMultiLineLabel is not affected. On 9.x and 10.x the Content-Security-Policy Wicket sends by default admits script only from a source carrying a per-response nonce, and a URL whose scheme executes script cannot carry one, so that default policy stops the script from running. This is a property of the default policy and not of these components. An application that has weakened or disabled its Content-Security-Policy, for this or for any unrelated reason, is affected in full. Wicket 8.x has no Content-Security-Policy support at all and is affected as it stands. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-82956 High 2026-11-01 No exploit published No public exploit Improper neutralization of input during web page generation in Apache Wicket. org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior notices that a page instance has been opened in a second browser window or tab. It asks the browser for the value of window.name, which reaches the server as the request parameter windowName, and remembers what the browser reported in a field of the behaviour. That field is part of the page's serialized state, so the remembered value stays in the page store for as long as the page instance does. On every later render of that page instance the behaviour builds the precondition of its Ajax call by substituting the remembered value into a single-quoted JavaScript string literal, and Wicket writes that precondition into the page as raw JavaScript, because the precondition of an Ajax call listener is script supplied by the caller and is emitted without quoting or escaping. Nothing on that path escapes the value. The window name is client-supplied and Wicket applies no validation to it, so a remembered name containing a single quote ends the literal and the rest of it runs as script in the application's origin, every time that page instance is rendered. An application is affected only where it has explicitly added AjaxNewWindowNotifyingBehavior to a component. No part of the framework installs the behaviour, so an application that does not use it is not affected. The name the behaviour generates for itself, when the browser reports no name at all, is a random UUID and is not client-supplied. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-82840 High 2026-11-01 No exploit published No public exploit Session fixation in Apache Wicket. org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason. AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen. An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected. As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation. This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-111089 High 2026-11-01 No exploit published No public exploit Apache Wicket reads texts from the application's resource bundles — a localized label, a css class name — and writes some of them into the JavaScript and the markup it generates for a component. Those texts are placed inside single-quoted JavaScript string literals and inside quoted attribute values without being escaped for that context, so a text containing a quote ends the literal or the attribute, and what follows is parsed as script or as markup in the application's origin when the page loads. A resource bundle entry is authored for the application and does not say where the framework will write it. The same key is read by the framework into element text, where Wicket escapes it, and into the contexts below, where it did not. A text containing an apostrophe, which is ordinary in several languages, is enough to break the page; a text under the influence of another party is enough to run script. In org.apache.wicket:wicket-core, org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes the org.apache.wicket.mfu.delete message into a JavaScript string literal, and org.apache.wicket.markup.html.form.Form writes the hidden-fields css class into the class attribute of the container it renders for its hidden fields; on 8.0.0 through 8.19.0 and 9.0.0 through 9.24.0 Form#appendDefaultButtonField writes the same css class into a second container. In org.apache.wicket:wicket-extensions, UploadProgressBar writes its UploadProgressBar.starting text into a JavaScript string literal, FilterForm writes the hidden-fields css class into the class attribute of its hidden input markup, and on 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 TrapFocusBehavior writes its current css class into a JavaScript string literal. The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does not prevent the JavaScript cases: the generated script is written into a script element carrying the per-response nonce, so the injected code is part of a script the policy admits. It does prevent an inline event handler injected through the attribute cases. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
CVE-2026-120135 High 2026-10-31 No exploit published No public exploit Uncontrolled Recursion vulnerability in Apache Thrift Java bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue.
CVE-2026-63224 High 2026-10-30 Protected by Waratek Proof of concept only OpenRemote is an open-source internet-of-things platform. Prior to 1.26.0, the `datapoint export` API constructs `CSV crosstab` SQL by concatenating an `asset name` and `attribute name` into a `COPY` query that uses `crosstab` and streams `TO STDOUT`. The `asset name` enters both a double-quoted column identifier and a category query enclosed by the fixed `$cat$` delimiter. Escaping single quotes in one string context does not escape embedded double quotes in identifiers or protect that dollar-quote boundary. An authenticated user permitted to create or rename an asset and read/export datapoints for one of its attributes can store SQL metacharacters in the name and request a `crosstab` export, causing injected SELECT output to be returned in the normal ZIP/CSV response. This enables database exfiltration without direct database or filesystem access or token forgery. In a multi-tenant deployment it can expose other tenants' data if the manager's database role can read shared tables; integrity and availability effects are not established by the demonstrated read primitive. This issue is fixed in version 1.26.0.
CVE-2026-61586 High 2026-10-30 Protected by Waratek No public exploit Copernik XML Factory provides secure-by-default JAXP factory creation for Java. Prior to 0.1.2, Copernik XML Factory does not block XInclude resource resolution on the stock JDK provider after an application enables XInclude on a factory returned by `XmlFactories.newDocumentBuilderFactory()` or `XmlFactories.newSAXParserFactory()`, or on an `XMLReader` passed through `XmlFactories.harden()`. An application parsing untrusted XML can resolve attacker-controlled `xi:include` references to disclose local files or, through `http` references, reach internal network endpoints by server-side request forgery. Exploitation requires use of one of those factory/hardening APIs, the stock JDK provider with Apache Xerces absent from the classpath, explicit `setXIncludeAware(true)` or the equivalent reader feature, and XML from an untrusted source. The Xerces provider selected when Xerces is present and the Android provider are unaffected. This issue is fixed in version 0.1.2.
CVE-2026-46560 High 2026-10-30 No exploit published No public exploit Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the `RADIUS` authentication module opens an unconnected datagram socket and trusts the first UDP datagram received on the client source port. The receive path does not verify the source IP and port, match the response identifier to the outstanding request, or verify the RFC 2865 `Response Authenticator`; the RFC 2869 `Message-Authenticator` is neither sent nor required. Any non-Reject/non-Challenge packet is treated as success. On a deployment with a `RADIUS` module instance enabled on a login chain, an unauthenticated network attacker can race the real server on-path or spray forged `Access-Accept` packets off-path and obtain a session for any `RADIUS`-mapped username without knowing the shared secret. Unlike CVE-2024-3596, exploitation requires no MD5 chosen-prefix forgery because no response authenticator is checked. The resulting session carries the impersonated principal's privileges. This issue is fixed in version 16.1.1.
CVE-2026-45049 High 2026-10-29 No exploit published No public exploit Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, the `Cross-Domain Single Sign-On` (`CDSSO`) servlet allows a logged-in user's raw OpenAM session token to be POSTed to an attacker-controlled URL. An attacker who induces an authenticated victim to visit a crafted URL can receive the session credential and potentially hijack the session. Deployments must have `CDSSO` enabled, as is common in multi-domain deployments, and exploitation is additionally gated on a non-default configuration being absent. This issue is fixed in version 16.1.1.
CVE-2026-15564 High 2026-10-29 Protected by Waratek No public exploit Wildfly's IIOP listener may permit deserialization of input streams before authentication is performed. An attacker who can gain access to the IIOP port may be able to construct and send malicious objects and achieve deserialization, if the target EJB allows untyped method parameters, and depending on the potential gadget chains available in the running classpath.
CVE-2026-6647 High 2026-10-28 No exploit published No public exploit In deployments of WSO2 Identity Server configured with a case-insensitive user store and a case-sensitive database for identity data, mismatches in username case handling can occur. This inconsistency results in OAuth token revocation operations failing to correctly identify usernames containing mixed-case characters during certain lifecycle events, preventing tokens from being invalidated. A malicious actor can exploit this vulnerability by possessing a valid access or refresh token associated with a mixed-case username. In affected configurations, these tokens may not be revoked when expected. The actor can then leverage these unrevoked tokens, before their expiry, to continue performing actions that should have been restricted, effectively bypassing intended access controls.
CVE-2026-117624 High 2026-10-28 Protected by Waratek No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not consistently enforce the restriction on deserializing objects of types marked as storing their configuration in independent top-level configuration files as nested values, allowing attackers to bypass the root element check and potentially inject nested objects.
CVE-2026-117620 High 2026-10-28 No exploit published No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows attackers with Overall/Read permission to trigger warnings in the "Manage Old Data" feature that can be acted on by administrators to inject attacker-controlled data, overriding existing user account information, including login passwords.
CVE-2026-117619 High 2026-10-28 No exploit published No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows requests authenticated using HTTP Basic authentication, including with an API token, to obtain a "remember me" cookie, allowing attackers who have obtained a user's API token to retain access to Jenkins using a "remember me" cookie after the API token is revoked or expires.
CVE-2026-117618 High 2026-10-28 No exploit published No public exploit In Jenkins 2.587 and earlier, LTS 2.580.1 and earlier, the HTTP endpoint for creating the first user account does not check whether the setup wizard has been completed, resulting in a race condition that allows unauthenticated attackers to create an administrator account while the initial user account is being replaced.
CVE-2026-117617 High 2026-10-28 No exploit published No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier checks for symbolic links in the path of an extracted file only before creating its parent directories, not immediately before writing it, and allows symbolic links in artifacts to replace existing files or empty directories, allowing attackers with Item/Configure permission to write files to arbitrary locations on the Jenkins controller file system.
CVE-2026-117616 High 2026-10-28 Protected by Waratek No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier provides an HTTP endpoint that loads agents by name without validating the name, allowing attackers with Overall/Read permission to load any config.xml file on the controller file system as an agent configuration, and to overwrite an arbitrary config.xml file when that agent is saved, potentially resulting in arbitrary code execution.
CVE-2026-117614 High 2026-10-28 No exploit published No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier converts the launch commands in older agent configurations into launchers provided by the Command Agent Launcher Plugin without checking whether they have been approved by an administrator, allowing attackers with Agent/Configure permission to execute arbitrary code in the context of the Jenkins controller JVM.
CVE-2026-117612 High 2026-10-28 No exploit published No public exploit Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not apply its deserialization filter to classes referenced by the `resolves-to` attribute during XStream deserialization.
CVE-2026-116593 High 2026-10-28 No exploit published No public exploit Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations. Apache Kafka Connect also support Configuration Providers which enable to hide the values of sensitive configuration and only resolve them at runtime.  An attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker. Users are recommended to upgrade to version 4.2.2, 4.3.2, 4.4.0 or above, which fix this issue.
CVE-2026-115644 High 2026-10-28 No exploit published No public exploit Apache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property. When operators isolate the admin REST API by explicitly configuring the "admin.listeners" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration. While the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener. Impact: An unauthenticated attacker with network access to the admin listener can: 1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use. 2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability. Mitigation: Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the REST extensions specified via "rest.extension.classes" will also apply to "admin.listeners".
CVE-2026-111551 High 2026-10-28 Protected by Waratek No public exploit Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.
CVE-2026-110747 High 2026-10-28 No exploit published No public exploit ProtobufParser._readStringKey() reads the length prefix of a protobuf map entry's string key into an attacker-controlled int and then checks (_inputPtr + len) <= _inputEnd using signed arithmetic. For values near Integer.MAX_VALUE the addition overflows to a negative value and the check passes even when the input contains no key data. The parser then calls _finishShortText(len), which expands the text buffer to the declared length via TextBuffer.expandCurrentSegment and Arrays.copyOf, throwing OutOfMemoryError: Requested array size exceeds VM limit. An 8-byte malformed message containing a map entry with a declared key length of 0x7FFFFFFF is sufficient. Configured StreamReadConstraints, including maxStringLength, maxNameLength, maxDocumentLength and maxNestingDepth, do not prevent the failure. Applications running with -XX:+ExitOnOutOfMemoryError terminate the JVM. This is the same integer-overflow pattern addressed for other call sites in the remediation associated with CVE-2026-104016 and CVE-2026-104017; the map-key call site was corrected on the 3.x branches only, leaving the corresponding 2.x branches unguarded. Release lines 2.18, 2.19 and 2.20 do not contain _readStringKey() and are not affected by this vector. No privileges or user interaction beyond the ability to submit data for parsing are required. The 3.0 release line and 3.1.0-3.1.5 / 3.2.0-3.2.1 do not contain _readStringKey() and are therefore not affected; the method first appears in 3.1.6 and 3.2.2, mirroring its introduction at 2.21.6 on the 2.x side.
CVE-2026-104895 High 2026-10-28 No exploit published No public exploit The asynchronous Smile parser (NonBlockingByteArrayParser) uses a raw-binary length prefix taken from untrusted input to allocate a byte[] before the body is read, with no upper bound and no overflow check. On the raw-binary marker 0xFD, _decodeVInt() computes (value << 6) + (i & 0x3F) without the (value >>> 25) != 0 overflow guard present in the blocking SmileParser._readUnsignedVInt, and _startRawBinary then allocates the declared length immediately. A Smile feed of roughly ten bytes can therefore force an eager allocation of approximately 2 GB, producing an OutOfMemoryError on reactive or asynchronous Smile endpoints. A VInt crafted to overflow int yields a negative length and a NegativeArraySizeException, a RuntimeException that is not a JacksonException and so escapes the parser contract. Either outcome crashes the request or processing thread. This is the same class of issue as CVE-2020-28491 in the CBOR parser of this library, which was fixed with a LONGEST_NON_CHUNKED_BINARY guard; the asynchronous Smile parser never received the equivalent guard. No privileges or user interaction beyond the ability to submit data for parsing are required.
CVE-2026-104016 High 2026-10-28 No exploit published No public exploit ProtobufParser parses length-prefixed protobuf string and bytes fields by checking (_inputPtr + len) <= _inputEnd and then, on the fast path, calling _finishShortText(len). Both use 32-bit signed integer arithmetic. When an attacker supplies a varint decoding to a length near Integer.MAX_VALUE, _inputPtr + len overflows to a negative value, the bounds check passes, and _finishShortText(len) reaches TextBuffer.expandCurrentSegment(len), which performs Arrays.copyOf with no cap and throws OutOfMemoryError: Requested array size exceeds VM limit. The JVM refuses arrays larger than Integer.MAX_VALUE - 8 before consulting available heap, so -Xmx tuning does not mitigate the issue. StreamReadConstraints.maxStringLength and maxDocumentLength do not gate this path: a 33-byte payload is far below any document-length cap and the string-length check does not fire before the allocation. This was confirmed empirically against shipping artifacts with maxStringLength, maxDocumentLength and maxNestingDepth all configured. A February 2026 hardening commit added the equivalent overflow guard to the packed-array-length and message-length paths but left the string-length call sites unguarded. No privileges or user interaction beyond the ability to submit data for parsing are required.
CVE-2025-14260 High 2026-10-28 No exploit published No public exploit Due to the improper implementation of access control rules, malicious actors could perform a Server Side Request Forgery (SSRF) attack on affected WSO2 Products. Exploiting this vulnerability allows a malicious actor to access both internal and external resources, available through the network or filesystem. This could potentially lead to unauthorized access to sensitive data and systems, regardless of whether these resources are located within a private network, as long as they are reachable by the WSO2 product.
CVE-2026-90885 High 2026-10-26 Protected by Waratek No public exploit Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.
CVE-2026-116541 High 2026-10-26 No exploit published No public exploit Netty netty-tcnative before 2.0.84.Final contains a denial of service vulnerability in the tcn_write_to_bytebuffer BIO write callback that overreports bytes consumed. Remote TLS 1.3 peers can provoke queued post-handshake records like NewSessionTicket or KeyUpdate to truncate flights, fail connections, or abort the JVM process.
CVE-2026-116540 High 2026-10-26 No exploit published No public exploit netty-tcnative 2.0.66.Final before 2.0.84.Final built against OpenSSL 3.x contains a use-after-free vulnerability in ssl_tlsext_ticket_key_cb during session ticket key rotation. Remote clients performing TLS handshakes while setSessionTicketKeys0 frees the shared key array cause OpenSSL to read freed HMAC keys, crashing or corrupting ticket processing.
CVE-2026-116539 High 2026-10-26 No exploit published Proof of concept only Netty netty-tcnative before 2.0.84.Final contains a heap buffer overflow vulnerability in the tcn_write_to_bytebuffer BIO callback caused by failing to wrap the non-application ring buffer write index. Remote TLS peers can drive handshake, renegotiation, or post-handshake messages into this buffer, triggering an out-of-bounds memcpy that crashes the JVM process.
CVE-2026-115748 High 2026-10-26 No exploit published No public exploit **UNSUPPORTED WHEN ASSIGNED**  Authorization bypass in Apache Vysper, all versions. Apache Vysper is an XMPP (Jabber) server library. Its XEP-0077 (In-Band Registration) implementation is missing an authentication check, allowing any authenticated user to compromise other accounts. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.
CVE-2026-115721 High 2026-10-26 No exploit published No public exploit **UNSUPPORTED WHEN ASSIGNED**  Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition. This issue affects all versions of Apache Vysper. Apache Vysper is an XMPP (Jabber) server library. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.
CVE-2026-107858 High 2026-10-23 No exploit published Proof of concept only Missing Origin Validation in WebSockets (CWE-1385) and Permissive Cross-domain Policy with Untrusted Domains (CWE-942) in the development web server (ADK Web) in Google Agent Development Kit (ADK) for Java (com.google.adk:google-adk-dev versions 0.1.0 before 1.13.0 and com.google.adk:google-adk-maven-plugin versions 0.3.0 before 1.13.0) allow a remote attacker to control a locally running agent and read its data via a malicious web page visited by a developer while the server is running. The /run_live WebSocket endpoint accepts connections from any origin by default (hardcoded via setAllowedOrigins("*") in versions 0.1.0 through 1.5.0, and defaulting to * via adk.web.cors.origins in versions 1.6.0 through 1.12.0), and since version 0.4.0 the REST API returns Access-Control-Allow-Origin: * by default. Because the server has no authentication and requests originate from the developer's browser (so binding to localhost does not prevent exploitation), a cross-origin page can send messages to the agent (triggering registered tools), stream agent responses, and list, read, create, or delete sessions and artifacts. In versions 1.6.0 through 1.12.0, users can mitigate the issue by setting the adk.web.cors.origins property to an explicit allowlist of trusted origins (such as http://localhost:8000). The vulnerability is fixed in version 1.13.0, which enforces a same-origin default for CORS and the /run_live WebSocket endpoint, and rejects DNS-rebinding requests over loopback.
CVE-2026-113582 High 2026-10-22 Protected by Waratek No public exploit UNSUPPORTED WHEN ASSIGNED Improper restriction of XML external entity references in Apache Abdera allows an attacker to access sensitive data or make server-side requests when an application parses attacker-controlled XML with Abdera. This issue affects Apache Abdera: all versions. Apache Abdera is retired and no longer supported, so we do not plan to release a version that fixes this issue. Users are recommended to migrate to a maintained alternative. Applications that cannot migrate should ensure that untrusted XML cannot reach the affected Abdera parser or JDBC adapter parsing paths. Actively maintained downstream products may still be impacted if they include an affected Abdera artifact. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
CVE-2026-59229 High 2026-10-21 No exploit published No public exploit 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-41114 High 2026-10-21 No exploit published No public exploit Uncontrolled Resource Consumption vulnerability in Apache IoTDB JDBC driver. This issue affects Apache IoTDB JDBC driver: from 1.3.3 before 2.0.11. Users are recommended to upgrade to version 2.0.11, which fixes the issue.
CVE-2026-111075 High 2026-10-21 Protected by Waratek No public exploit In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset` fields during `DataDescriptor` message deserialization. An unauthenticated remote attacker can send a crafted network payload that triggers an unsigned integer underflow in `DataDescriptor::getPayloadSize()` and `DataDescriptor::getNextDescriptor()`. This results in an out-of-bounds heap read and an immediate process crash (SIGSEGV), causing a denial of service.
CVE-2026-111074 High 2026-10-21 No exploit published No public exploit In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service. When processing the initial 4-byte length field of an incoming TCP connection, an integer overflow in `MessageBuffer::computeRequiredCapacity()` causes the receiving compilation worker thread to enter an infinite loop consuming ~100% CPU. An unauthenticated remote attacker can exploit this by opening a small number of crafted TCP connections to exhaust the entire worker thread pool, silently halting compilation services for all connected client JVMs.
CVE-2026-110938 High 2026-10-21 No exploit published No public exploit In Eclipse OpenJ9 versions up to 0.63.0, the JITServer component is vulnerable to denial of service due to improper boundary checks during protocol message and reply handling. An unauthenticated remote attacker or malicious JITServer can transmit malformed network payloads that cause out-of-bounds heap reads, immediately crashing the JITServer daemon or client JVM process via a segmentation fault (SIGSEGV).
CVE-2026-110803 High 2026-10-21 No exploit published No public exploit VaadinService.requestEnd() in Vaadin Framework 8 locks the session and then reads the v-uiId request parameter outside the block that releases the lock. A request carrying a non-numeric v-uiId makes Integer.parseInt throw while the session lock is held, so the lock is never released and the container thread returns to its pool still owning it. Every later request to that session then blocks forever in VaadinService.lockSession(), and repeating the request exhausts the thread pool and takes the application down. No authentication is required: a session cookie, which any client obtains with a single request, is enough. Vaadin 10 and later are not affected, because Flow releases the lock in a finally block and does not read that parameter there, and Vaadin Framework 7 is not affected either. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin Framework 8.16.0 - 8.32.1 Mitigation Upgrade to 8.32.2 Vaadin Framework 7 and Vaadin 10 and later do not carry this behaviour and need no upgrade for this issue. Artifacts Maven coordinates / Vulnerable versions / Fixed version com.vaadin:vaadin-server / 8.16.0 - 8.32.1 / >=8.32.2 com.vaadin:vaadin-server-mpr-jakarta / 8.18.0 - 8.32.1 / >=8.32.2
CVE-2026-107588 High 2026-10-21 No exploit published No public exploit Vaadin Charts renders charts with the Highcharts library and pins an exact version of it, 9.2.2 in Vaadin 22 to 24 and 12.2.0 in Vaadin 25, so an application cannot remove these vulnerabilities by upgrading Highcharts on its own. Highsoft disclosed several vulnerabilities in that library that are reachable through the chart configuration: writes to Object.prototype through dotted series.keys paths, and cross-site scripting through credits.href, through breadcrumbs.style, through HTML text parsing while printing, and through xlink:href attributes in exported charts. An application is affected where data an attacker controls reaches the chart configuration, for example through additionalOptions, through updateConfiguration(), or through text options that accept markup. The fixed Vaadin versions apply Highsoft's recommended workarounds to the bundled Highcharts when it loads, and keep the same Highcharts version. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin 22.0.0 - 23.6.15 Vaadin 24.0.0 - 24.4.23 Vaadin 24.5.0 - 24.7.15 Vaadin 24.8.0 - 24.9.22 Vaadin 24.10.0 - 24.10.10 Vaadin 25.0.0 - 25.2.9 Vaadin 25.3.0 Mitigation Upgrade to 23.6.16 Upgrade to 24.4.24 Upgrade to 24.7.16 Upgrade to 24.9.23 Upgrade to 24.10.11 Upgrade to 25.2.10 Upgrade to 25.3.1 or newer Please note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 23, 24, 25 version. Artifacts Maven coordinates / Vulnerable versions / Fixed version com.vaadin:vaadin / 22.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin / 24.0.0 - 24.4.23 / >=24.4.24 com.vaadin:vaadin / 24.5.0 - 24.7.15 / >=24.7.16 com.vaadin:vaadin / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin / 25.3.0 / >=25.3.1 com.vaadin:vaadin-charts-flow / 22.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin-charts-flow / 24.0.0 - 24.4.22 / >=24.4.24 com.vaadin:vaadin-charts-flow / 24.5.0 - 24.7.14 / >=24.7.15 com.vaadin:vaadin-charts-flow / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin-charts-flow / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin-charts-flow / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin-charts-flow / 25.3.0 / >=25.3.1 com.vaadin:vaadin-charts-flow-svg-generator / 21.0.0 - 23.6.15 / >=23.6.16 com.vaadin:vaadin-charts-flow-svg-generator / 24.0.0 - 24.4.22 / >=24.4.24 com.vaadin:vaadin-charts-flow-svg-generator / 24.5.0 - 24.7.14 / >=24.7.15 com.vaadin:vaadin-charts-flow-svg-generator / 24.8.0 - 24.9.22 / >=24.9.23 com.vaadin:vaadin-charts-flow-svg-generator / 24.10.0 - 24.10.10 / >=24.10.11 com.vaadin:vaadin-charts-flow-svg-generator / 25.0.0 - 25.0.13 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.1.0 - 25.1.13 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.2.0 - 25.2.9 / >=25.2.10 com.vaadin:vaadin-charts-flow-svg-generator / 25.3.0 / >=25.3.1 npm packages npm package / Vulnerable versions / Fixed version @vaadin/charts / 22.0.0 - 23.6.6 / >=23.6.7 @vaadin/charts / 24.0.0 - 24.4.18 / >=24.4.19 @vaadin/charts / 24.5.0 - 24.7.12 / >=24.7.13 @vaadin/charts / 24.8.0 - 24.9.18 / >=24.9.19 @vaadin/charts / 24.10.0 - 24.10.6 / >=24.10.7 @vaadin/charts / 25.0.0 - 25.0.13 / >=25.2.14 @vaadin/charts / 25.1.0 - 25.1.14 / >=25.2.14 @vaadin/charts / 25.2.0 - 25.2.13 / >=25.2.14 @vaadin/charts / 25.3.0 / >=25.3.1
CVE-2025-0326 High 2026-10-21 No exploit published No public exploit The system fails to invalidate existing access tokens associated with sub-organization users during sensitive account management operations such as password reset, role change, or sub-organization disablement. This oversight allows previously issued tokens to remain active even after the user's access context has been modified or revoked through administrative actions. The identified issue could lead to unauthorized access by a malicious actor, but only when all of the following conditions are met: previously issued access tokens remain active, and these tokens have been exposed to malicious actors.
CVE-2026-93446 High 2026-10-20 No exploit published No public exploit Incomplete cleanup vulnerability in Apache Tomcat could cause TLS 1.3 connections to fail intermittently. This issue affects Apache Tomcat: from 11.0.0-M21 through 11.0.26, from 10.1.25 through 10.1.60, from 9.0.90 through 9.0.122. Users are recommended to upgrade to version 11.0.27, 10.1.61 or 9.0.123, which fix the issue.
CVE-2026-91668 High 2026-10-20 No exploit published No public exploit Vulnerability in the Oracle Data Integrator product of Oracle Fusion Middleware (component: Dictionary Repository). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via SQL to compromise Oracle Data Integrator. Successful attacks of this vulnerability can result in takeover of Oracle Data Integrator. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
CVE-2026-91664 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Security). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Essbase. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Essbase. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
CVE-2026-91661 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Security). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Essbase. While the vulnerability is in Oracle Essbase, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Essbase accessible data. CVSS 3.1 Base Score 7.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
CVE-2026-91659 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Build). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Essbase. While the vulnerability is in Oracle Essbase, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Essbase accessible data. CVSS 3.1 Base Score 7.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).
CVE-2026-91653 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Essbase Web Platform). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Essbase. While the vulnerability is in Oracle Essbase, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Essbase accessible data as well as unauthorized update, insert or delete access to some of Oracle Essbase accessible data. CVSS 3.1 Base Score 8.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N).
CVE-2026-91651 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Essbase Web Platform). The supported version that is affected is 21.8.3.0.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Essbase. While the vulnerability is in Oracle Essbase, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle Essbase. CVSS 3.1 Base Score 8.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H).
CVE-2026-91647 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Security). The supported version that is affected is 21.8.3.0.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Essbase. Successful attacks of this vulnerability can result in takeover of Oracle Essbase. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
CVE-2026-91642 High 2026-10-20 No exploit published No public exploit Vulnerability in Oracle Essbase (component: Security). The supported version that is affected is 21.8.3.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Essbase. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Essbase accessible data as well as unauthorized read access to a subset of Oracle Essbase accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Essbase. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L).
‹ prev page 1 of 63 next ›