Overview 13,598 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 77 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
13,598
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
13,598
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
460
3.4%
Forecast only
64
0.5%
No public exploit
13,074
96.1%
split by
peak 4,120 / year
19961
No exploit published1
High1
not blocked1
No public exploit1
19970
19980
19992
No exploit published2
High2
not blocked2
No public exploit2
20006
No exploit published6
High3
Medium3
not blocked6
No public exploit6
200110
No exploit published10
High6
Medium4
not blocked10
No public exploit10
200226
No exploit published26
High8
Medium15
Low3
not blocked26
Forecast only2
No public exploit24
200330
No exploit published30
High7
Medium18
Low5
not blocked30
No public exploit30
200424
No exploit published24
High5
Medium16
Low3
not blocked24
No public exploit24
200575
No exploit published75
Critical1
High30
Medium39
Low5
not blocked75
No public exploit75
2006121
No exploit published121
High62
Medium48
Low11
not blocked121
No public exploit121
2007134
No exploit published134
High64
Medium60
Low10
not blocked134
No public exploit134
2008120
No exploit published120
High42
Medium71
Low7
not blocked120
No public exploit120
2009181
No exploit published181
High45
Medium115
Low21
not blocked181
No public exploit181
2010162
No exploit published162
High24
Medium118
Low20
not blocked162
Forecast only1
No public exploit161
2011178
No exploit published178
High15
Medium132
Low31
not blocked178
No public exploit178
2012278
No exploit published278
High25
Medium177
Low76
not blocked278
No public exploit278
2013305
No exploit published305
High29
Medium225
Low51
not blocked305
Forecast only1
No public exploit304
2014282
No exploit published282
High18
Medium215
Low49
not blocked282
No public exploit282
2015285
No exploit published285
Critical1
High33
Medium205
Low46
not blocked285
No public exploit285
2016465
No exploit published465
Critical32
High108
Medium292
Low33
not blocked465
Forecast only1
No public exploit464
2017682
No exploit published682
Critical41
High293
Medium326
Low22
not blocked682
Forecast only1
No public exploit681
2018697
No exploit published697
Critical34
High225
Medium428
Low10
not blocked697
No public exploit697
2019756
No exploit published756
Critical43
High288
Medium405
Low20
not blocked756
Forecast only2
No public exploit754
2020898
No exploit published898
Critical61
High314
Medium496
Low27
not blocked898
Proof of concept only2
Forecast only8
No public exploit888
2021649
No exploit published649
Critical54
High290
Medium291
Low14
not blocked649
Proof of concept only4
Forecast only22
No public exploit623
2022895
No exploit published895
Critical67
High245
Medium570
Low13
not blocked895
Proof of concept only53
Forecast only11
No public exploit831
2023876
No exploit published876
Critical153
High272
Medium440
Low11
not blocked876
Proof of concept only141
Forecast only9
No public exploit726
2024617
No exploit published617
Critical78
High196
Medium320
Low23
not blocked617
Proof of concept only55
Forecast only6
No public exploit556
2025723
No exploit published723
Critical35
High180
Medium471
Low36
None1
not blocked723
Proof of concept only77
No public exploit646
20264,120
No exploit published4,120
Critical745
High2,170
Medium1,053
Low150
None2
not blocked4,120
Proof of concept only128
No public exploit3,992
19961999200220052008201120142017202020232026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-95616 | High | 2026-09-30 | No exploit published | No public exploit | An integer overflow in WSS4J's DER bounds check lets an oversized allocation pass validation. An unauthenticated attacker can send a SOAP message carrying an X.509 certificate whose SubjectKeyIdentifier extension declares a length of 0x7FFFFFFF; WSS4J decodes this while resolving the signature's key reference, before the message is authenticated, so an eleven-byte extension triggers a 2 GB allocation. Repeated requests exhaust server memory. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-94053 | Critical | 2026-09-30 | No exploit published | No public exploit | Authentication bypass via LDAP injection in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5. Apache MINA SSHD is a Java library for client-side and server-side SSH. The optional sshd-ldap component provides support for integrating password and publickey authentication on the server side with an LDAP server. sshd-ldap is an optional component. SSH servers implemented with Apache MINA SSHD are affected only if they use sshd-ldap and do configure it to be used for password of public key authentication. Other Apache MINA SSHD servers are not affected. Lack of escaping LDAP filter metacharacters enabled successful authentication with username "*" and password "*". Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue by properly escaping filter parameters according to RFC 4515. |
| CVE-2026-94052 | Critical | 2026-09-30 | No exploit published | No public exploit | A missing check in LdapPasswordAuthenticator in component sshd-ldap in Apache MINA SSHD versions 1.2.0 to 2.19.0 or 3.0.0-M1 to 3.0.0-M5 bypassed authentication checks. Apache MINA SSHD is a Java library for client-side and server-side SSH. The optional sshd-ldap component provides support for integrating password and publickey authentication on the server side with an LDAP server. sshd-ldap is an optional component. SSH servers implemented with Apache MINA SSHD are affected only if they use sshd-ldap and do configure an LdapPasswordAuthenticator to be used for password authentication. Normal password authentication via the built-in mechanisms in sshd-core is _not_ affected by this vulnerability, which concerns only LdapPasswordAuthenticator. Users are recommended to upgrade affected applications to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| CVE-2026-94029 | Medium | 2026-09-30 | No exploit published | No public exploit | Server-side memory exhaustion in Apache MINA SSHD 1.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5, component sshd-sftp, in the SFTP v6 check-file-name/check-file-handle extension. Apache MINA SSHD is a Java library for client-side and server-side SSH. Using a very small "block size" (for instance 256, which is the minimum) on a huge file generates many (file size / block size) hashes. The resulting SFTP reply message was accumulated fully in memory server-side, which could, with a suitably large (possibly sparse) file exhaust the server-side memory, taking down the server. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue by imposing a maximum limit on the size of the reply. Many SFTP implementations have a general limit on the size of SFTP messages anyway; typically 256kB as in OpenSSH or also in Apache MINA SSHD. |
| CVE-2026-94002 | High | 2026-09-30 | No exploit published | No public exploit | Possible memory exhaustion in SFTP clients (DefaultSftpClient) in component sshd-sftp in Apache MINA SSHD versions 0.9.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5. Apache MINA SSHD is a Java library for client-side and server-side SSH. The sshd-sftp component provides support for SFTP. The SFTP client implementation, when receiving a reply, did not check that this reply corresponded to a request sent earlier. Unsolicited replies would be stored but never consumed. A malicious server could keep sending unsolicited replies until available memory in the client was exhausted. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| CVE-2026-93996 | Medium | 2026-09-30 | No exploit published | No public exploit | Uncontrolled resource consumption in component ssd-scp in Apache MINA SSHD versions up to 2.19.0 or 3.0.0-M1 to 3.0.0-M5. Apache MINA SSHD is a Java library for client-side and server-side SSH. Component sshd-scp of Apache MINA SSHD provides a Java implementation of SCP. The SCP command protocol is line-oriented with LF-terminated lines. The protocol handler in sshd-scp did not impose any limit on the length of such protocol lines. A malicious peer just sending a junk command containing a never-ending sequence of characters but never a LF would cause the receiver to allocate memory to store this whole junk command, exhausting memory and crashing the application with an OutOfMemoryError. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue by enforcing an upper limit on the length of SCP protocol lines. |
| CVE-2026-93995 | Medium | 2026-09-30 | No exploit published | No public exploit | Improper input validation in sshd-git in Apache MINA SSHD, versions up to 2.19.0 and 3.0.0-M1 to 3.0.0-M5. Apache MINA SSHD is a Java library for client-side and server-side SSH. Component org.apache.sshd:sshd-git provides though class GitPgmCommandFactory a way to configure an Apache MINA SSHD server such that authenticated SSH clients can remotely execute git commands via the JGit library on git repositories stored on the server. In CVE-2026-58624 this mechanism was restricted to only a few git commands, including "git archive" without "--output" or "-o" options such that the resulting archive would not be written on the server but instead sent back to the client over the SSH connection. The fix done for CVE-2026-58624 was insufficient as it missed removing the single-argument "-o=file.zip" version of the command parameter from the "archive" command. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| CVE-2026-93994 | High | 2026-09-30 | No exploit published | No public exploit | Apache MINA SSHD is a Java library for client-side and server-side SSH. SSH servers can be configured to require multi-authentication schemes, for instance two different public keys, not just one. In OpenSSH, this would be done by setting in sshd_config AuthenticationMethods "publickey,publickey". Apache MINA SSHD provides an equivalent configuration mechanism. In Apache MINA SSHD versions up to 2.19.0 and 3.0.0-M1 to 3.0.0-M5 the server code in component sshd-core does not enforce that the two public keys presented are different. A user can thus successfully authenticate with only one of the two key pairs required by presenting this single key twice. This is a partial authentication bypass. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| CVE-2026-93547 | Medium | 2026-09-30 | No exploit published | No public exploit | A missing authorization check in the Vaadin Spreadsheet component allows an authenticated user of an application that renders a spreadsheet to add or replace cell comments on a sheet that has protection enabled, including on cells that are locked. Writing a comment to a cell that does not exist yet also creates the row and the cell. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin 23.1.0 - 23.6.13 Vaadin 24.0.0 - 24.9.21 Vaadin 24.10.0 - 24.10.9 Vaadin 25.0.0 - 25.1.11 Vaadin 25.2.0 - 25.2.6 Vaadin Framework 7 and 8 with the Spreadsheet add-on 2.0.0 - 3.1.0 Mitigation Upgrade to 23.6.14 Upgrade to 24.9.22 Upgrade to 24.10.10 Upgrade to 25.1.12 Upgrade to 25.2.7 or newer Upgrade the Spreadsheet add-on to 3.1.1 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 23.1.0 - 23.6.13 >=23.6.14 com.vaadin:vaadin 24.0.0 - 24.9.21 >=24.9.22 com.vaadin:vaadin 24.10.0 - 24.10.9 >=24.10.10 com.vaadin:vaadin 25.0.0 - 25.1.11 >=25.1.12 com.vaadin:vaadin 25.2.0 - 25.2.6 >=25.2.7 com.vaadin:vaadin-spreadsheet-flow 23.1.0 - 23.6.13 >=23.6.14 com.vaadin:vaadin-spreadsheet-flow 24.0.0 - 24.9.21 >=24.9.22 com.vaadin:vaadin-spreadsheet-flow 24.10.0 - 24.10.9 >=24.10.10 com.vaadin:vaadin-spreadsheet-flow 25.0.0 - 25.1.11 >=25.1.12 com.vaadin:vaadin-spreadsheet-flow 25.2.0 - 25.2.6 >=25.2.7 com.vaadin:vaadin-spreadsheet 2.0.0 - 3.1.0 >=3.1.1 |
| CVE-2026-92899 | Medium | 2026-09-30 | No exploit published | No public exploit | Apache WSS4J remembers the Nonce of each UsernameToken it accepts, so a captured token cannot be reused. It stored the Nonce as raw base64 text, but authentication decodes that text and uses the bytes.The same bytes can be written as base64 in several ways. An attacker who captured an authenticated request could re-send it with a space added to the Nonce: the password digest still verified, but the token no longer matched the remembered one, so the replay was accepted. Since a UsernameToken does not cover the message body, the captured token could then be reused on requests of the attacker's choosing until it expired. Affects deployments with a nonce replay cache configured, as Apache CXF has by default, and only tokens using a password digest. The cache is now keyed on the decoded Nonce. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-92121 | High | 2026-09-30 | No exploit published | No public exploit | In the WSS4J streaming (StAX) code, a signature reference using the WS-Security STR-Transform leaves an internal "inside signed content" flag permanently set. The WS-SecurityPolicy enforcer uses that flag to decide whether an element needs checking, so it stops evaluating SignedParts and SignedElements for the rest of the message. A policy requiring the SOAP Body to be signed is then satisfied even when the Body carries no signature, removing the protection against XML Signature Wrapping. Signature verification itself is unaffected. The DOM code is not affected. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4 which fix this issue. |
| CVE-2026-89238 | Critical | 2026-09-30 | No exploit published | No public exploit | WSS4J EncryptedHeader child confusion could promote an attacker-controlled plaintext element as the decrypted header, leading to incorrect confidentiality coverage and possible policy bypass. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-88920 | Critical | 2026-09-30 | No exploit published | No public exploit | An authentication bypass in the DOM security processor in Apache WSS4J allows unauthenticated remote attackers to forge authenticated SOAP messages via a crafted unsigned SAML sender-vouches assertion containing an attacker-controlled key. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-87830 | Critical | 2026-09-30 | No exploit published | No public exploit | In the StAX streaming WS-SecurityPolicy validator, certain relative or unsupported XPath expressions can be converted into paths that never match the actual XML element path. A remote SOAP peer may therefore send a required element without the expected signature or encryption. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-85532 | High | 2026-09-30 | No exploit published | No public exploit | Apache WSS4J accepted attacker-controlled derived-key lengths and offsets without adequate bounds. This could permit cryptographically weak keys or excessive CPU and memory consumption when processing crafted WS-Security messages. The fixes enforce a minimum key length of 16 bytes, a maximum length of 512 bytes, and a maximum offset of 4096 bytes. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. |
| CVE-2026-77185 | Critical | 2026-09-30 | No exploit published | No public exploit | Authentication bypass in sshd-core in Apache MINA SSHD versions 2.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5 for a certain (presumed rare) way to implement an SSH server. Apache MINA SSHD is a Java library for client- and server-side SSH. In the server part of the library, a mechanism to perform "asynchronous authentication" exists. A server implemented with Apache MINA SSHD must contain explicit code to make use of this feature. The implementation of this feature was flawed and could potentially lead to skipping checking the signature in public-key or hostbased authentication, or returning a wrong result. Users are recommended to upgrade to Apache MINA SSHD 2.20.0 or 3.0.0-M6, which fix the logic error and which additionally forbid the use of this "asynchronous authentication" mechanism with the public-key or hostbased authentication schemes: if used, the SSH session will be closed and the server will log an entry indicating that asynchronous authentication may be used only with password or keyboard-interactive authentication. |
| CVE-2026-102509 | High | 2026-09-30 | No exploit published | No public exploit | Memory Allocation with Excessive Size Value, Allocation of Resources Without Limits, and Uncontrolled Recursion in the Java implementation of Apache PLC4X (PLC4J) allow a malicious or impersonated device to exhaust the memory or stack of the client application, causing a denial of service. In the OPC UA driver these defects are reachable before authentication: the offending data is parsed while the secure channel and session are being established, before the server's identity has been bound to it. Configuring a trusted server therefore does not prevent exploitation by an attacker who can impersonate it. The individual defects are: - Length-prefixed byte strings are allocated at the size claimed on the wire before the length is checked against the data actually received (0.10.0 through 0.13.1). - Array fields in generated protocol parsers pre-allocate a list with the element count claimed on the wire, allowing a single count field to trigger a multi-gigabyte allocation. This parser is shared by all PLC4J drivers; the OPC UA driver is the verified pre-authentication path (0.10.0 through 0.13.1). - The OPC UA driver accumulates message chunks without enforcing the negotiated maximum chunk count and message size (0.12.0 through 0.13.1). - The OPC UA driver pre-allocates collections using element counts received from the server (0.10.0 through 0.13.1). - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Go implementation is covered by CVE-2026-102510 https://cveprocess.apache.org/cve5/CVE-2026-102510 . This issue affects Apache PLC4X: from 0.10.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. |
| CVE-2026-102508 | Critical | 2026-09-30 | No exploit published | No public exploit | Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client. The defect manifests differently depending on the version: - In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password. - In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default. - In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint. Users checking only for one of these mechanisms may wrongly conclude they are unaffected. This issue affects Apache PLC4X: from 0.9.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the connection if the negotiated security policy is weaker than the configured one. |
| CVE-2026-81569 | Medium | 2026-09-29 | No exploit published | No public exploit | An improper authorization vulnerability exists in the handling of sub-workflow tasks. An authenticated user who does not have permission to access a target project can reference and invoke a workflow belonging to that project through a sub-workflow task. The system does not properly verify whether the user has permission to execute the referenced workflow or access its project. As a result, the user can bypass project-level authorization controls and cause workflows in unauthorized projects to be executed. Successful exploitation may allow unauthorized execution of workflow tasks and access to the resources or data available to the target workflow. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-78214 | Medium | 2026-09-29 | No exploit published | No public exploit | An authentication bypass vulnerability exists in the protection of Actuator endpoints. The application determines whether authentication is required by matching the incoming request path against protected Actuator paths. By sending a specially crafted request containing a percent-encoded path, a remote unauthenticated attacker can cause the security check to fail to recognize the request as targeting a protected endpoint. As a result, the attacker may bypass authentication and access otherwise restricted Actuator endpoints. Successful exploitation may expose operational or configuration information and, depending on the enabled endpoints and application configuration, allow access to sensitive management functionality. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-71899 | Medium | 2026-09-29 | No exploit published | No public exploit | A missing authorization vulnerability exists in the `query-dynamic-sub-workflows` API of Apache DolphinScheduler. The API does not properly verify whether the authenticated user has permission to access the workflows being queried. An authenticated user who does not have permission to access a specific project can invoke the API with parameters referencing workflows belonging to that project and retrieve workflow information. This allows users to access workflow data outside their authorized project scope, resulting in unauthorized information disclosure. This issue affects Apache DolphinScheduler: from 3.2.0 before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-71898 | Medium | 2026-09-29 | No exploit published | No public exploit | An incorrect authorization check in Apache DolphinScheduler allows an authenticated user with only read permission for a project to modify a workflow instance in that project through the PUT /projects/{projectCode}/workflow-instances/{id} endpoint. The endpoint does not enforce the write permission required for this operation, allowing the user to make unauthorized changes to workflow instances. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-71897 | Medium | 2026-09-29 | No exploit published | No public exploit | An improper authorization check in Apache DolphinScheduler allows an authenticated user to use the batch-copy and batch-move endpoints to operate on workflows in projects for which they lack the required permissions. This may allow the user to copy or move workflows from unauthorized projects. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-66083 | Medium | 2026-09-29 | No exploit published | No public exploit | The /datasources/unauth-datasource endpoint does not properly enforce data source authorization. An authenticated user can invoke this endpoint to obtain information about data sources they are not authorized to access. This may expose data source configuration and other sensitive metadata, depending on the fields returned by the endpoint. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-102497 | High | 2026-09-29 | No exploit published | No public exploit | The Apache XmlSchema walker (xmlschema-walker) doesn't detect cycles in type derivation, substitution groups, model groups or attribute groups. A malicious schema with such a cycle can make the walker recurse until the stack overflows, causing a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| CVE-2026-102496 | High | 2026-09-29 | No exploit published | No public exploit | Apache XmlSchema doesn't limit how deeply schema structures can be nested when it builds its schema model, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| CVE-2026-102495 | High | 2026-09-29 | No exploit published | No public exploit | Apache XmlSchema doesn't limit how deeply schema imports and includes can be nested, so a malicious schema can make parsing recurse until the stack overflows. This causes a denial of service. Users are recommended to upgrade to version 2.3.3, which fixes this issue. |
| CVE-2026-100834 | High | 2026-09-27 | No exploit published | No public exploit | http4k's Digest authentication module (org.http4k:http4k-security-digest) before versions 6.48.0.0, 5.42.0.0 and 4.51.0.0 defaults the nonceVerifier parameter of ServerFilters.DigestAuth and DigestAuthProvider to { true }, so every nonce is accepted regardless of its value, age, or prior use. Applications relying on this default have no replay protection on Digest authentication: an attacker who can capture a valid 'Authorization: Digest' response (for example by observing network traffic or reading logs) can replay it indefinitely against the same protected resource. |
| CVE-2026-100725 | High | 2026-09-27 | No exploit published | No public exploit | http4k (Maven artifact org.http4k:http4k-core) before 6.48.0.0, 5.42.0.0, and 4.51.0.0 ships a BasicCookieStorage (client-side cookie store used by ClientFilters.Cookies) that does not enforce RFC 6265 scoping rules for the cookie domain, path, and Secure attributes. When a single BasicCookieStorage instance is used to talk to more than one origin or scheme, cookies stored for one origin can be sent to other origins, and cookies marked Secure can be sent over plain HTTP, potentially disclosing session cookies or other sensitive values to unauthorized hosts or network observers. Clients that use a storage instance for a single origin are not affected. |
| CVE-2026-100724 | Medium | 2026-09-27 | No exploit published | No public exploit | http4k (Maven package org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 uses substring (Contains) matching on the Host header by default in reverseProxy() and reverseProxyRouting() when dispatching to configured virtual hosts. If these functions are deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, a remote attacker can supply a Host header that merely contains a configured vhost name (for example Host: admin.evil.com for a vhost configured as "admin") and be routed to that vhost, bypassing routing-based authorization. The intended outbound-dispatch and test-time uses, where the Host value is set by the calling application, are not affected. |
| CVE-2026-100666 | Medium | 2026-09-26 | No exploit published | Proof of concept only | Netty's HttpServerCodec (io.netty:netty-codec-http) in versions 4.2.0.Final through 4.2.16.Final and in versions up to and including 4.1.136.Final pairs each outbound response with an inbound request by calling pollMethod() once per response, including for 1xx informational responses. If a client pipelines an HTTP/1.1 GET carrying an Expect: 100-continue header followed by a HEAD request, the 100 Continue response consumes the queued GET method, so the subsequent 200 OK for the GET is paired with HEAD and its body is dropped, while the following 200 OK for the HEAD request is written with a body. This desynchronizes HTTP parsing on the connection: the GET entity is never delivered and the HEAD response body is interpreted as the GET body, resulting in response splitting and unsafe connection reuse. Fixed in 4.2.17.Final and 4.1.137.Final. |
| CVE-2026-100665 | High | 2026-09-26 | No exploit published | Proof of concept only | Netty versions from 4.2.11.Final before 4.2.18.Final contain an incomplete hostname verification fix in the QUIC certificate verification path when using a plain X509TrustManager. The BoringSSLCertificateVerifyCallback discards the SSLEngine for plain trust managers, preventing endpoint identification from running even when HTTPS verification is configured. Attackers on the network path can present a certificate chain for the wrong hostname that the plain trust manager accepts, bypassing hostname authentication for QUIC clients. |
| CVE-2026-100664 | High | 2026-09-26 | No exploit published | No public exploit | Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final builds the HTTP/3 :authority pseudo-header from the HTTP/1 Host header before considering the authority of an absolute-form HTTP/1 request-target. In HttpConversionUtil.toHttp3Headers(HttpMessage, boolean) — reached via Http3FrameToHttpObjectCodec(false) — a non-empty Host header takes precedence over the request-target authority, contrary to the HTTP/1.1 rule that a server receiving an absolute-form request-target must ignore the Host header. In a Netty-based HTTP/1-to-HTTP/3 gateway, proxy, or protocol bridge, a remote client can send a request such as "GET https://trusted.example/admin HTTP/1.1" with "Host: attacker.example", causing components that validate, authorize, or route on the RFC-defined request-target authority to reach a different decision than the upstream HTTP/3 peer, which receives :authority derived from the conflicting Host header. This authority confusion can affect virtual-host routing, allow-list checks, backend selection, cache keys, and URL generation. The advisory reports integrity impact only (no code execution, memory corruption, or availability impact). Fixed in 4.2.18.Final. |
| CVE-2026-100663 | High | 2026-09-26 | No exploit published | Proof of concept only | Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets when converting HTTP/1 messages to HTTP/3 in HttpConversionUtil.toHttp3Headers. The authority-form target (e.g., "CONNECT trusted.example:443") is parsed as a URI, so its host is emitted as :scheme, :path is set to "/", and the HTTP/1 Host header is used as :authority; if no Host header is present the CONNECT target is dropped. In a Netty-based HTTP/1-to-HTTP/3 proxy or gateway, a remote client can send a CONNECT request whose Host header names a different authority than the request-target, producing a malformed HTTP/3 CONNECT whose tunnel :authority is attacker-controlled. This can bypass tunnel allow-lists, egress policy, backend selection, or audit controls that validate the HTTP/1 CONNECT request-target before forwarding over HTTP/3. The issue is fixed in 4.2.18.Final. |
| CVE-2026-100662 | High | 2026-09-26 | No exploit published | Proof of concept only | Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain an uncontrolled resource consumption vulnerability in the QPACK encoder-stream instruction decoder (QpackEncoderHandler, installed on the peer-initiated unidirectional QPACK encoder stream, type 0x02). The handler accepts an attacker-declared string-literal length of up to Integer.MAX_VALUE (~2 GiB) for the Name Length and Value Length fields of the "Insert With Literal Name" instruction (RFC 9204 §4.3.3), with no per-instruction or per-literal length cap and no cumulation-size limit; the existing HTTP/3 limits (maxHeaderListSize, maxUnknownFramePayloadLength, DEFAULT_MAX_FIELD_SECTION_SIZE) are not applied to this handler. A remote, unauthenticated peer with an established HTTP/3 connection to a default Netty HTTP/3 server can declare a very large literal length and then trickle fewer bytes than declared, causing the ByteToMessageDecoder MERGE cumulator to retain and grow the per-connection buffer, and ultimately triggering a large byte-array allocation. This leads to unbounded per-connection heap growth and OutOfMemoryError, resulting in denial of service. Fixed in 4.2.18.Final. |
| CVE-2026-100661 | High | 2026-09-26 | No exploit published | No public exploit | Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain a denial-of-service vulnerability in the QPACK prefixed-integer decoder (QpackUtil.decodePrefixedInteger), which does not bound the number of continuation bytes it will process. A remote, unauthenticated peer can open a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and send a first byte with all prefix bits set (e.g. 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix) followed by an endless run of 0x80 continuation bytes. The decoder returns -1 ('need more bytes'), so callers never consume the input, the ByteToMessageDecoder cumulator grows without bound, and each decode() invocation re-scans the whole accumulated buffer, yielding O(N^2) CPU cost. The result is unbounded per-connection heap growth (OutOfMemoryError) and event-loop CPU starvation, reachable in every configuration. Fixed in 4.2.18.Final. |
| CVE-2026-100660 | High | 2026-09-26 | No exploit published | Proof of concept only | Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.0.Final through 4.2.17.Final retains unbounded per-stream QPACK encoder state. QpackEncoder stores a queue and a dynamic-table index tracker for every encoded field section that references the QPACK dynamic table, keyed by the peer-controlled QUIC stream ID, and these entries are released only when the remote decoder sends a Section Acknowledgment or Stream Cancellation instruction — not when the HTTP/3 stream completes. There is no limit on the number of tracked streams, field sections, or retained bytes. A remote, unauthenticated HTTP/3 client can advertise a non-zero QPACK dynamic-table capacity, acknowledge the table insertion so the server reuses a dynamically indexed response header, and then omit all mandatory Section Acknowledgments while issuing sequential requests over a single QUIC connection, bypassing concurrent-stream limits and causing unbounded heap growth until the server exhausts memory (denial of service). Fixed in 4.2.18.Final. |
| CVE-2026-100659 | Medium | 2026-09-26 | No exploit published | No public exploit | Netty's HTTP/3 codec (io.netty:netty-codec-http3) in versions 4.2.0.Final through 4.2.17.Final does not enforce the RFC 9114 requirement that the :authority pseudo-header field and a literal host header field, when both present, carry the same value. A remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values; the request is accepted and delivered to the application with two conflicting authorities, allowing routing, virtual-host, and access-control decisions to be bypassed when different components in the request path consult different fields. This issue is fixed in 4.2.18.Final. |
| CVE-2026-92609 | Critical | 2026-09-25 | No exploit published | No public exploit | Session fixation in HTTP management authentication allows remote attackers to gain unauthorized access to an authenticated management session via reuse of a session identifier retained across successful authentication. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-92608 | High | 2026-09-25 | No exploit published | No public exploit | Improper handling of property-encoding exceptions in AMQP 1.0-to-AMQP 0-10 message conversion allows authenticated message producers to disrupt delivery to AMQP 0-10 consumers via message properties that the target encoder does not handle correctly. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-92573 | Medium | 2026-09-25 | No exploit published | No public exploit | Improper handling of compressed data in the shared GZIP decompressor used for AMQP 0-8/0-9/0-9-1 and AMQP 0-10 message delivery, message conversion and HTTP management JSON rendering allows authenticated message producers to exhaust memory and disrupt broker availability via processing without a decompressed-output limit. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-92564 | High | 2026-09-25 | No exploit published | No public exploit | A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-92560 | High | 2026-09-25 | No exploit published | No public exploit | A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-92550 | High | 2026-09-25 | No exploit published | No public exploit | A pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service. This issue affects Apache Qpid Broker-J: through 10.1.0. Users are recommended to upgrade to version 10.1.1, which fixes the issue. |
| CVE-2026-97176 | Medium | 2026-09-24 | No exploit published | No public exploit | A flaw was found in the Level of Authentication enforcement mechanism of Keycloak, an identity and access management solution. The issue occurs when a client specifically requires a higher security level for a user who already has an active session at a lower level. Due to a logic error in how session re-evaluations are handled, Keycloak may incorrectly issue a token at the lower security level instead of enforcing the required higher level, potentially allowing unauthorized access to sensitive resources that rely on these security claims. |
| CVE-2026-57590 | High | 2026-09-24 | No exploit published | No public exploit | A missing authorization vulnerability exists in the Task Group APIs of Apache DolphinScheduler. The affected APIs do not properly verify whether the authenticated user has permission to access the project associated with the target Task Group. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-95848 | Critical | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, when a configured authenticator or authorizator class cannot be loaded, Server.initializeAuthenticator and Server.initializeAuthorizatorPolicy treat the failure as though no custom class was configured and fall back to AcceptAllAuthenticator or PermitAllAuthorizatorPolicy. A misspelled class name, missing dependency, constructor failure, or classpath problem can therefore start the broker with authentication or authorization disabled even though the operator configured those controls. This issue is fixed in version 0.18.1. |
| CVE-2026-95847 | High | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, H2PersistentQueue derives a session's message-map name as queue_ plus the client ID and its metadata-map name as queue_ plus the client ID plus _meta. A durable session whose client ID ends in _meta can therefore make its message map collide with another client's metadata map. The colliding sessions read and write the same H2 MVStore map with incompatible value types, which can corrupt queue head and tail data and cause message loss, misdelivery, failed queue reloads, or exposure of queued content across sessions. This issue is fixed in version 0.18.1. |
| CVE-2026-95846 | High | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.publishWill publishes a client's Last-Will message without applying the canWrite authorization and reserved-topic checks used for a normal PUBLISH. A client can configure a Will for a topic that the client is not permitted to write and cause the broker to publish the unauthorized message when the client disconnects unexpectedly. This issue allows unauthorized message injection into restricted topics. This issue is fixed in version 0.18.1. |
| CVE-2026-95845 | High | 2026-09-23 | No exploit published | No public exploit | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, the broker does not enforce a maximum length for pending per-session message queues. When a fast publisher sends messages to a slow subscriber whose in-flight window is full, queued messages can accumulate without bound in memory or persistent storage. Remote clients can use this condition to exhaust broker resources and cause a denial of service. This issue is fixed in version 0.18.1. |
| CVE-2026-95844 | High | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, Moquette does not limit the depth of topic names and topic filters before processing them through recursive CTrie insertion and matching operations. A remote client can publish or subscribe with a deeply nested topic, causing a StackOverflowError that disrupts session processing and can deny service to broker clients. This issue is fixed in version 0.18.1. |
| CVE-2026-95843 | High | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.subscribe parses a shared-subscription filter through SharedSubscriptionUtils.extractShareName before validating the complete $share/{shareName}/{topicFilter} structure. A remote client can send a filter such as $share/grp without a topic-filter portion, causing a StringIndexOutOfBoundsException while calculating the share name. The exception terminates command handling on the shared session event loop and can deny service to other client sessions assigned to that loop. This issue is fixed in version 0.18.1. |
| CVE-2026-95842 | High | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, SessionEventLoop.run catches only InterruptedException, and SessionEventLoopGroup does not restart a terminated loop. An MQTT command that raises an uncaught exception can terminate an event loop shared by multiple client sessions, preventing every co-located client from processing PUBLISH, SUBSCRIBE, PUBACK, and other commands. An attacker can select client IDs that map across the available loops to disrupt session processing for the entire broker. This issue is fixed in version 0.18.1. |
| CVE-2026-91777 | High | 2026-09-23 | No exploit published | Proof of concept only | Forward-reference completion for @JsonIdentityInfo object IDs in FasterXML jackson-databind performs a linear scan of the pending-reference accumulator for every resolved ID. The affected paths are CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference() and the equivalent implementation in MapDeserializer. When a document first creates N unresolved object-ID references in an identity-enabled collection or map and then defines those same IDs in reverse order, completion performs on the order of N * (N + 1) / 2 identity comparisons, so a shallow document whose size grows linearly causes quadratic CPU work during deserialization. The reporter instrumented equals() calls on the ID class and measured exactly 2,003,000 comparisons at N = 2,000, against zero comparisons in the pending-reference lookup path for an equally sized control in which every reference was already resolved. The input requires no deep nesting and no syntactically unusual JSON. Exploitation requires an application that deserializes attacker-influenced JSON into an identity-enabled collection or map. The fix replaces the repeated linear lookup with a keyed pending-reference structure. |
| CVE-2026-91776 | High | 2026-09-23 | No exploit published | Proof of concept only | TypeDeserializerBase._findDeserializer() in FasterXML jackson-databind caches the resolved deserializer under the raw, attacker-supplied type ID. When name-based polymorphism is configured with a fallback, for example @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every distinct unrecognized type ID resolves to the same fallback deserializer but is retained as its own key in the _deserializers map. That map has no configurable bound and lives for the lifetime of the type deserializer, so an attacker who can repeatedly supply fresh unknown type IDs causes monotonic memory retention across requests. The reporter observed 10,000 retained entries from 10,000 distinct unknown IDs, against a single entry for a control that repeated one unknown ID the same number of times, isolating attacker-controlled key cardinality from request volume. Exploitation requires an application that enables name-based polymorphism with a defaultImpl or equivalent fallback, accepts attacker-influenced type IDs, and reuses a long-lived ObjectMapper across requests. The fix stops caching fallback resolutions for unrecognized IDs and bounds both the number of cached entries and the length of a cacheable type ID. |
| CVE-2026-89425 | High | 2026-09-23 | No exploit published | Proof of concept only | UTF8DataInputJsonParser._reportInvalidToken() in FasterXML jackson-core builds the offending-token text for its error message by appending Java identifier characters to a StringBuilder in a loop that has no upper bound. Unlike the three sibling parser implementations, including UTF8StreamJsonParser, it never consults ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). A malformed token supplied to a parser created through JsonFactory.createParser(DataInput) is therefore accumulated in full. No StreamReadConstraints setting mitigates this: maxDocumentLength cannot be applied to DataInput sources at all, and maxStringLength does not cover this path because the accumulation bypasses ReadConstrainedTextBuffer. The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token on the DataInput path, against 367 characters for identical input on the InputStream path. Scaling the payload drives the StringBuilder, which also incurs byte-to-char expansion and internal array doubling, to many times the raw payload size and can trigger OutOfMemoryError for the whole JVM. UTF8DataInputJsonParser was introduced in 2.8.0 together with createParser(DataInput); releases before 2.8.0 do not contain the affected class. |
| CVE-2026-87022 | High | 2026-09-23 | No exploit published | No public exploit | Improper handling of length parameter inconsistency vulnerability in Apache Tomcat allows WebSocket message smuggling when per-message-deflate is used. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0.M1 through 9.0.121. The following versions were EOS at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.56 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.1.22, which fix the issue. |
| CVE-2026-86350 | Critical | 2026-09-23 | No exploit published | No public exploit | Inconsistent interpretation of HTTP/2 requests ('HTTP Request/Response smuggling') vulnerability in Apache Tomcat caused by a regression in fix for CVE-2026-41293 can trigger request header mix-up. This issue affects Apache Tomcat: from 11.0.22 through 11.0.25, from 10.1.55 through 10.1.59, from 9.0.118 through 9.0.121. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-86248 | Critical | 2026-09-23 | No exploit published | No public exploit | CLIENT_CERT authentication does not fail as expected for some scenarios when soft fail is disabled vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M14 through 11.0.25, from 10.1.22 through 10.1.59, from 9.0.92 through 9.0.121. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-85724 | Critical | 2026-09-23 | No exploit published | Proof of concept only | Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, when pattern-based ACL rules are configured, AuthorizationsCollector.canDoOperation substitutes client ID and username values directly into rules containing %c or %u and then treats the result as an MQTT topic filter. A client that uses + or # in either identity can broaden the substituted filter and gain cross-tenant read and write access. A # identity can also produce an invalid filter that triggers a NullPointerException in Topic.match and disrupts session processing. This issue is fixed in version 0.18.1. |
| CVE-2026-79677 | High | 2026-09-23 | No exploit published | No public exploit | Missing release of resource after effective lifetime, Comparison using wrong factors vulnerability in Apache Tomcat allows a denial of service as a result of lost time outs for asynchronous WebSocket writes. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0.M1 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.43 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-78437 | High | 2026-09-23 | No exploit published | No public exploit | Incomplete cleanup vulnerability in Apache Tomcat allows a malformed request to potentially (depends on timing) cause one request from another user to fail. This issue affects Apache Tomcat: from 11.0.19 through 11.0.25, from 10.1.53 through 10.1.59, from 9.0.116 through 9.0.121. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-78383 | High | 2026-09-23 | No exploit published | No public exploit | Allocation of resources without limits or throttling vulnerability in Apache Tomcat allows an unauthenticated AJP request to pin an AJP processing thread leading to denial of service. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0.M1 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-77791 | High | 2026-09-23 | No exploit published | No public exploit | Uncontrolled Resource Consumption vulnerability in Apache Tomcat during sending of WebSocket close message enabled a DoS attack. This issue affects Apache Tomcat: from 11.0.0-M5 through 11.0.25, from 10.1.8 through 10.1.59, from 9.0.74 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.88 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-77762 | High | 2026-09-23 | No exploit published | No public exploit | Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Tomcat allows an attacker to inject trailer fields into another HTTP/2 request. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.39 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.59 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60, 9.0.122, which fix the issue. |
| CVE-2026-77756 | Low | 2026-09-23 | No exploit published | No public exploit | Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in Apache Tomcat caused by processing the transfer-encoding header for an HTTP/1.0 request may allow an attacker to cause one request from another user to fail when Tomcat is located behind a reverse proxy. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.47 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.67 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-77422 | High | 2026-09-23 | No exploit published | Proof of concept only | JLine is a Java library for handling console input. From 3.0.0 until 3.30.15 and 4.3.1, the JLine built-in grep command in builtins/src/main/java/org/jline/builtins/PosixCommands.java accepts a user-controlled regular expression in grep(...) and, unless line-regexp mode is used, automatically adds a dot-star prefix and suffix before compiling it with Java's backtracking regular expression engine. The wrapping expands the backtracking search space, so a short nested-quantifier expression evaluated against non-matching input can consume excessive CPU and indefinitely block a command worker, including in remotely exposed shell sessions. This issue is fixed in versions 3.30.15 and 4.3.1. |
| CVE-2026-77421 | Medium | 2026-09-23 | No exploit published | No public exploit | JLine is a Java library for handling console input. From 3.0.0 until 3.30.15 and 4.3.1, the JLine built-in nano editor's regex search mode passes a user-controlled search term from doSearch(String text) in builtins/src/main/java/org/jline/builtins/Nano.java to Java's backtracking regular expression engine without a timeout or backtracking bound. A nested-quantifier expression evaluated against non-matching buffer content can consume excessive CPU and indefinitely block the editor session thread, and remote multi-user deployments can lose a worker thread for each affected session. This issue is fixed in versions 3.30.15 and 4.3.1. |
| CVE-2026-77420 | Medium | 2026-09-23 | No exploit published | Proof of concept only | JLine is a Java library for handling console input. From 3.0.0 until 3.30.15 and 4.3.1, DefaultHistory.matchPatterns(String patterns, String line) in reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java converts the HISTORY_IGNORE configuration value into a Java regular expression while escaping only part of its syntax, allowing other regex metacharacters to reach the backtracking engine. An attacker who can control application or user configuration can supply a nested-quantifier expression that is reevaluated whenever a command is added to history, consuming excessive CPU and indefinitely blocking the reader thread. This issue is fixed in versions 3.30.15 and 4.3.1. |
| CVE-2026-76183 | Critical | 2026-09-23 | No exploit published | No public exploit | Authentication Bypass by Alternate Name vulnerability in Apache Tomcat allowed the security constraints for any WebSocket endpoint to be bypassed. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0.M1 through 9.0.121. The following versions were EOS at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.43 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60 or 9.0.122, which fix the issue. |
| CVE-2026-75973 | High | 2026-09-23 | No exploit published | No public exploit | Improper Authentication vulnerability in Apache Tomcat. When Jakarta Authentication was configured with SimpleAuthConfigProvider as the default provider and multiple web application used that provider, the realm for the first web application to authenticate a request would be used for all web applications. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0.M4 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.60, 9.0.122, which fixes the issue. |
| CVE-2026-73581 | Medium | 2026-09-23 | No exploit published | No public exploit | Improper Check for Certificate Revocation vulnerability in Apache Tomcat. Both the OpenSSL and OpenSSL-FFM TLS implementations ignore CRLs when certificate uses a keystore. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0-M1 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.59, 9.0.122, which fixes the issue. |
| CVE-2026-61814 | High | 2026-09-23 | No exploit published | No public exploit | Jawn is an open source JSON parser. Prior to 1.7.0, Jawn's AsyncParser can perform quadratic work when a single JSON token is delivered across many small chunks because each absorb call rescans the incomplete token from the start. A remote attacker who controls untrusted JSON input and its chunk sizes can exhaust CPU resources and cause denial of service in applications using AsyncParser. This issue is fixed in version 1.7.0. |
| CVE-2026-59990 | High | 2026-09-23 | No exploit published | No public exploit | Jawn is an open source JSON parser. Prior to 1.7.0, Jawn parse methods accept arbitrarily deep JSON array and object nesting without a depth limit, allowing a remote attacker who can submit untrusted JSON to grow parser contexts until the JVM heap is exhausted. The resulting java.lang.OutOfMemoryError is a fatal Scala error that is not ordinarily handled by scala.util.Try or cats.effect.IO, causing denial of service. This issue is fixed in version 1.7.0. |
| CVE-2026-95503 | Medium | 2026-09-22 | No exploit published | No public exploit | A flaw was found in the Kerberos federation provider of Keycloak, an open-source identity and access management solution. When Kerberos password authentication is used without SPNEGO, the system fails to verify the identity of the Key Distribution Center (KDC) by requesting a server ticket. This allows an attacker on the same network to spoof the KDC and bypass the authentication process, potentially gaining unauthorized access to user accounts. |
| CVE-2026-89407 | High | 2026-09-22 | No exploit published | Proof of concept only | NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-validates "stringified numbers" with two regular expressions: PATTERN_FLOAT ([+-]?[0-9]*[\.]?[0-9]+([eE][+-]?[0-9]+)?), present since 2.17.0, and PATTERN_FLOAT_TRAILING_DOT, added in 2.17.2. PATTERN_FLOAT places adjacent quantifiers over the same character class -- an optional [0-9]* run, an optional dot, then a required [0-9]+ run -- so input that ultimately fails to match forces Java's backtracking engine to retry every possible split point of the digit run. Matching cost therefore grows with the square of the input length. An attacker who can supply JSON that an application deserializes into a numeric target type reaches this method through jackson-databind's default String-to-number coercion (StdDeserializer and NumberDeserializers for BigDecimal, BigInteger, Double and Float). Because StreamReadConstraints.maxStringLength defaults to 20,000,000 characters, no constraint bounds the input before it reaches the regex. Testing by the reporter confirmed O(n^2) growth across five consecutive input-size doublings, with a single 160,000-character string consuming roughly 74 seconds in one call; a small number of concurrent requests of ordinary body size can therefore exhaust a server's request-handling thread pool. The affected method does not exist before 2.17.0, so 2.16.x and earlier releases are not affected. The fix replaces both regular expressions with a hand-rolled single-pass scan. |
| CVE-2026-91867 | Medium | 2026-09-21 | No exploit published | No public exploit | When Neethi fetches a remote policy reference, it only limits the time per read, not the whole transfer, so a server that trickles bytes slowly can keep the fetch alive indefinitely and tie up the calling thread (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. |
| CVE-2026-91866 | High | 2026-09-21 | No exploit published | No public exploit | A specially crafted pair of WS-Policy documents can force Neethi's policy-intersection to do exponential amounts of work, pinning the CPU for a long time (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. |
| CVE-2026-91865 | High | 2026-09-21 | No exploit published | No public exploit | A small WS-Policy document using repeated policy references can force Neethi to re-expand the same references exponentially during normalization, consuming huge amounts of CPU and memory (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. |
| CVE-2026-91864 | High | 2026-09-21 | No exploit published | No public exploit | A specially crafted WS-Policy document can pack unlimited content inside a policy assertion, which Neethi copies into memory without counting it against its size limits, exhausting the heap (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. |
| CVE-2026-91863 | High | 2026-09-21 | No exploit published | No public exploit | A specially crafted WS-Policy document with deeply nested policy elements can bypass Neethi's nesting-depth limit and exhaust the thread stack, crashing the parser (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue. |
| CVE-2026-69190 | Medium | 2026-09-21 | No exploit published | No public exploit | Graylog is a free and open log management platform. From 6.3.0 until 6.3.14, 7.0.9, and 7.1.4, the view update API for saved searches and dashboards permits a user with edit permission but without entity ownership to include a shareRequest that grants owner permissions to an arbitrary account. The selected account can then delete the saved search or dashboard or remove the original owner's access. Graylog Cloud was patched before the advisory was published. This issue is fixed in versions 6.3.14, 7.0.9, and 7.1.4. |
| CVE-2026-47321 | High | 2026-09-21 | No exploit published | No public exploit | The CompressionFilter class uses ZLib to deflate and inflate data sent and received. When we inflate incoming data, the filter does not control the resulting size, and create a buffer no matter what. Some compressed data may have a compression ration greater than 1 thousand, leading to an exhaustion of the application memory, as we don't control the deflated size. The fix adds such a control by allowing the application developer to provide a fixed size limit, which when reached throws an exception. It also allows the user to provide a compression ratio that should not be exceeded, protected the application from small inflated files that inflate in gigantic files, but with a grace limit for the resulting size (1Mb) to avoid false positive (like a very small file inflating with a high ratio, but resulting with a acceptable size, like a few thousands bytes) For application using this feature, it is highly recommended to create the CompressionFilter and to pass the maximum limit as a forth constructor parameter, maxDecompressedSize: public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize)Optionally one can also provide a maxDecompressRatio fifth parameter, and a decompressRatioMinSize sixth parameter to allow small inflated files with a high compression ratio to still be accepted. Here are the additional constructor: public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize, final long maxDecompressRatio, final long decompressRatioMinSize) Also note that a fluent API has been added to spare the users the pain to call a constructor with that many parameters: CompressionFilter compressionFilter = new CompressionFilter() .setCompressionLevel(Zlib.COMPRESSION_MAX) .setMaxDecompressedSize(1_000_000) .setMaxDecompressRatio(100). .setDecompressRatioMinSize(100_000); Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance. |
| CVE-2026-94001 | Medium | 2026-09-19 | No exploit published | No public exploit | A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The endpoint used for deleting user credentials does not correctly check for fine-grained reset-password permissions. This allows a delegated administrator, who should be restricted from resetting passwords, to delete a user's password credentials, resulting in the user being unable to log in. |
| CVE-2026-94000 | Medium | 2026-09-19 | No exploit published | No public exploit | A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The issue occurs in the group-membership endpoints where the system fails to check if a group grants administrative privileges before allowing a user to be added. This allows a delegated administrator with limited permissions to add themselves to a high-privilege group, potentially gaining full control over the entire realm. |
| CVE-2026-93999 | Medium | 2026-09-19 | No exploit published | No public exploit | A flaw was found in the OIDC protocol implementation of Keycloak, an open-source identity and access management solution. The issue occurs during the token refresh process when the server restores requested audiences from stored client IDs. Keycloak fails to verify if the target audience client is still enabled before issuing a new access token. This allows an application with an existing refresh token to continue obtaining valid access tokens for a disabled client, potentially bypassing administrative access controls for resource servers that rely on offline JWT validation. |
| CVE-2026-93579 | Medium | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's HTTP/2 stack. This vulnerability allows a remote attacker to inject prohibited characters, such as NUL, Line Feed, and Carriage Return, into HTTP/2 header field values due to insufficient validation. When these values cross an HTTP/2 to HTTP/1.1 translation boundary, they can be exploited for request smuggling, header injection, or response splitting. This could lead to unauthorized access, data manipulation, or other security bypasses. |
| CVE-2026-93576 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty netty-codec-smtp. The component does not properly validate Carriage Return (CR) and Line Feed (LF) characters in the SMTP command-name field. A remote attacker, if an application routes untrusted input into this field, can embed CR/LF characters to inject arbitrary SMTP commands. This can lead to SMTP command smuggling, allowing for unauthorized email relay or spoofing of sender/recipient addresses. While the impact is significant, the real-world exploitability is considered lower as applications typically do not place user-controlled data in the command-name field. |
| CVE-2026-93575 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's MqttDecoder. An unauthenticated remote attacker can exploit this vulnerability by sending a specially crafted MQTT CONNECT packet. The decoder fails to properly validate the 'Properties Length' against the 'Remaining Length', allowing an attacker to bypass size limits. This leads to excessive memory and CPU consumption, resulting in a denial of service (DoS) due to an OutOfMemoryError. |
| CVE-2026-93574 | Medium | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's `netty-codec-http` component. A remote attacker could exploit this vulnerability by sending a specially crafted HTTP/1.1 chunk-size token that includes post-digit whitespace. This incorrect parsing of the chunk size can lead to HTTP request smuggling. This allows an attacker to bypass security controls or access unauthorized resources in proxy/backend deployments. |
| CVE-2026-93573 | Medium | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's HTTP/1.1 decoder. This vulnerability allows a remote attacker to bypass `Transfer-Encoding` header validation by splitting the `Transfer-Encoding` field across multiple headers, with the last field containing a non-final transfer coding like `gzip` or `deflate`. This bypass can lead to HTTP request smuggling, enabling attackers to bypass security controls, desynchronize request processing, or cause requests to be processed in an unintended context. |
| CVE-2026-93572 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's `RedisArrayAggregator` component. A remote attacker can exploit this vulnerability by sending specially crafted nested Redis (RESP) array headers. This can cause the `RedisArrayAggregator` to eagerly preallocate a large amount of heap memory, leading to heap memory exhaustion and a Denial of Service (DoS) for applications using `RedisDecoder` with `RedisArrayAggregator` on untrusted traffic. |
| CVE-2026-93569 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty. A remote unauthenticated attacker can exploit a vulnerability in Netty's HTTP/1 to HTTP/2 conversion process. When an HTTP/1 request includes both an absolute-form request-target and a conflicting Host header, Netty incorrectly prioritizes the Host header for the HTTP/2 :authority field, discarding the original request-target authority. This inconsistency can allow an attacker to bypass security controls in Netty-based proxies or gateways, potentially leading to unauthorized access, cache poisoning, or misrouting of requests. |
| CVE-2026-93568 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty. A remote attacker could exploit this vulnerability by sending specially crafted HTTP/2 or HTTP/3 Extended CONNECT requests. Netty's HTTP-object conversion path incorrectly processes these requests as regular HTTP/1.1 CONNECT requests, leading to a loss of critical protocol and path information. This misinterpretation can allow attackers to bypass security policies, such as routing or authorization logic, in applications that rely on Netty for HTTP/2 or HTTP/3 communication, resulting in integrity loss. |
| CVE-2026-93567 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's HTTP/2 codec. When converting HTTP/1 CONNECT requests to HTTP/2, the component incorrectly uses the Host header instead of the CONNECT authority-form request-target for the tunnel authority. A remote attacker can exploit this by supplying a different Host header, leading to a malformed HTTP/2 CONNECT request. This can bypass security controls such as tunnel allow-lists or egress policies, resulting in integrity loss. |
| CVE-2026-93566 | Medium | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty. A remote attacker could exploit this by sending a specially crafted HTTP request that includes control characters within the chunk-size line. This bypasses the intended strict validation, allowing the attacker to inject arbitrary HTTP requests. This vulnerability can lead to HTTP request smuggling, potentially resulting in information disclosure or other unauthorized actions. |
| CVE-2026-93565 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty RtspDecoder. The `RtspMethods.valueOf()` function incorrectly strips trailing control bytes from method tokens in Real-Time Streaming Protocol (RTSP) requests. A remote attacker can exploit this by sending a specially crafted RTSP request, leading to method-token smuggling. This vulnerability allows an attacker to bypass method-based access controls and can also be used to launder malicious requests through Netty-based RTSP proxies, making them appear legitimate to backend systems. |
| CVE-2026-93564 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty. A reference-count leak in the HAProxy PROXY-v2 message decoder allows a remote, unauthenticated attacker to send specially crafted PROXY-protocol v2 headers. This can lead to memory exhaustion, resulting in a Denial of Service (DoS) for the affected system. |
| CVE-2026-93563 | High | 2026-09-18 | No exploit published | No public exploit | A flaw was found in Netty's `SmtpResponseDecoder` component. A remote attacker, acting as a malicious or man-in-the-middle (MITM) SMTP server, could exploit this by sending a specially crafted, unbounded multi-line SMTP response without a terminator. This vulnerability leads to unbounded memory accumulation within the client's Java Virtual Machine (JVM) heap, causing an `OutOfMemoryError` and a denial of service (DoS) due to a process crash. |
| CVE-2026-93562 | Medium | 2026-09-18 | No exploit published | Proof of concept only | A flaw was found in Netty's HTTP/1 decoder. Incomplete validation of malformed Transfer-Encoding headers allows a remote attacker to perform HTTP request smuggling. By sending specially crafted HTTP requests, an attacker can inject arbitrary HTTP requests, potentially bypassing security controls or accessing unauthorized resources. |