Dependency-Check is an open source tool performing a best effort analysis of 3rd party dependencies;
false positives and false negatives may exist in the analysis performed by the tool. Use of the tool and
the reporting provided constitutes acceptance for use in an AS IS condition, and there are NO warranties,
implied or otherwise, with regard to the analysis or its use. Any use of the tool and the reporting provided
is at the user’s risk. In no event shall the copyright holder or OWASP be held liable for any damages whatsoever
arising out of or in connection with the use of this tool, the analysis performed, or the resulting report.
A DFA/NFA (finite-state automata) implementation with
Unicode alphabet (UTF16) and support for the standard regular
expression operations (concatenation, union, Kleene star) and a number
of non-standard ones (intersection, complement, etc.)
The Bouncy Castle Java APIs for CMS, PKCS, EAC, TSP, CMP, CRMF, OCSP, and certificate generation. This jar contains APIs for JDK 1.5 and up. The APIs can be used in conjunction with a JCE/JCA provider such as the one provided with the Bouncy Castle Cryptography APIs.
The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. This jar contains JCE provider and lightweight API for the Bouncy Castle Cryptography APIs for JDK 1.5 and up.
Lesser General Public License, version 3 or greater: http://www.gnu.org/licenses/lgpl.html
Apache Software License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0
File Path: /home/jenkins/.mvnrepository/com/github/fge/btf/1.2/btf-1.2.jar MD5: 5c91cd1157e0bb99e77a33b6f42a457c SHA1: 9e66651022eb86301b348d57e6f59459effc343b SHA256:38a380577a186718cb97ee8af58d4f40f7fbfdc23ff68b5f4b3c2c68a1d5c05d Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Checker Qual is the set of annotations (qualifiers) and supporting classes
used by the Checker Framework to type check Java source code. Please
see artifact:
org.checkerframework:checker
License:
The MIT License: http://opensource.org/licenses/MIT
File Path: /home/jenkins/.mvnrepository/org/checkerframework/checker-qual/2.5.2/checker-qual-2.5.2.jar MD5: 04acc78b24bbd365423da357da003cf0 SHA1: cea74543d5904a30861a61b4643a5f2bb372efc4 SHA256:64b02691c8b9d4e7700f8ee2e742dce7ea2c6e81e662b7522c9ee3bf568c040a Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
The Apache Commons Codec package contains simple encoder and decoders for
various formats such as Base64 and Hexadecimal. In addition to these
widely used encoders and decoders, the codec package also maintains a
collection of phonetic encoding utilities.
License:
https://www.apache.org/licenses/LICENSE-2.0.txt
File Path: /home/jenkins/.mvnrepository/commons-codec/commons-codec/1.14/commons-codec-1.14.jar MD5: e9158e0983096d3df09236f7b53125aa SHA1: 3cb1181b2141a7e752f5bdc998b7ef1849f726cf SHA256:a128e4f93fabe5381ded64cf2873019e06030b718eb43ceeae0b0e5d17ad33e9 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Apache Commons Compress software defines an API for working with
compression and archive formats. These include: bzip2, gzip, pack200,
lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4,
Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.
License:
https://www.apache.org/licenses/LICENSE-2.0.txt
File Path: /home/jenkins/.mvnrepository/org/apache/commons/commons-compress/1.21/commons-compress-1.21.jar MD5: 2a713d10331bc4e13459a3dc0463f16f SHA1: 4ec95b60d4e86b5c95a0e919cb172a0af98011ef SHA256:6aecfd5459728a595601cfa07258d131972ffc39b492eb48bdd596577a2f244a Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
The Apache Commons IO library contains utility classes, stream implementations, file filters,
file comparators, endian transformation classes, and much more.
License:
https://www.apache.org/licenses/LICENSE-2.0.txt
File Path: /home/jenkins/.mvnrepository/commons-io/commons-io/2.7/commons-io-2.7.jar MD5: 87709c85b69a685ddba69c65fe6dd6f9 SHA1: 3f2bd4ba11c4162733c13cc90ca7c7ea09967102 SHA256:4547858fff38bbf15262d520685b184a3dce96897bc1844871f055b96e8f6e95 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Apache Commons Lang, a package of Java utility classes for the
classes that are in java.lang's hierarchy, or are considered to be so
standard as to justify existence in java.lang.
License:
https://www.apache.org/licenses/LICENSE-2.0.txt
File Path: /home/jenkins/.mvnrepository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar MD5: fa752c3cb5474b05e14bf2ed7e242020 SHA1: 0122c7cee69b53ed4a7681c03d4ee4c0e2765da5 SHA256:de2e1dcdcf3ef917a8ce858661a06726a9a944f28e33ad7f9e08bea44dc3c230 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Contains
com.google.common.util.concurrent.internal.InternalFutureFailureAccess and
InternalFutures. Most users will never need to use this artifact. Its
classes is conceptually a part of Guava, but they're in this separate
artifact so that Android libraries can use them without pulling in all of
Guava (just as they can use ListenableFuture by depending on the
listenablefuture artifact).
GraalVM is an ecosystem for compiling and running applications written in multiple languages.
GraalVM removes the isolation between programming languages and enables interoperability in a shared runtime.
License:
Universal Permissive License, Version 1.0: http://opensource.org/licenses/UPL
File Path: /home/jenkins/.mvnrepository/org/graalvm/sdk/graal-sdk/21.0.0/graal-sdk-21.0.0.jar MD5: 03e0a151a091a1fa7bfb3a1744f11c1b SHA1: 0cf16fefccc8defcc2d196a9923155647a595274 SHA256:b51768a0aedae3c3e4a6bcb359a507e399524d709fecd23976552f4d16880ad7 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Lesser General Public License, version 3 or greater: http://www.gnu.org/licenses/lgpl.html
Apache Software License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0
File Path: /home/jenkins/.mvnrepository/com/github/fge/jackson-coreutils/1.6/jackson-coreutils-1.6.jar MD5: 26a6b351813e2895cba18e0ee4abe5b7 SHA1: 9e6af56eb7cc2a65700b289abc7ee2bd170fd231 SHA256:d84b416924fb061a26c48a5c90e98cf4d4e718179eb1df702aa8f1021163eed6 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Add-on module for Jackson (http://jackson.codehaus.org) to support
introspection of method/constructor parameter names, without having to add explicit property name annotation.
Jakarta Interceptors defines a means of interposing on business method invocations
and specific events—such as lifecycle events and timeout events—that occur on instances
of Jakarta EE components and other managed classes.
JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7386) implementation in Java
License:
Lesser General Public License, version 3 or greater: http://www.gnu.org/licenses/lgpl.html
Apache Software License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0
File Path: /home/jenkins/.mvnrepository/com/github/fge/json-patch/1.9/json-patch-1.9.jar MD5: 9df773c8904f39b05b6a8a6848804c96 SHA1: 0a4c3c97a0f5965dec15795acf40d3fbc897af4b SHA256:2d6acbda3675e6f25b7b4ab338317006865a8416a69c2b5e1cfa8b8209fc10a1 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
An empty artifact that Guava depends on to signal that it is providing
ListenableFuture -- but is also available in a second "version" that
contains com.google.common.util.concurrent.ListenableFuture class, without
any other Guava classes. The idea is:
- If users want only ListenableFuture, they depend on listenablefuture-1.0.
- If users want all of Guava, they depend on guava, which, as of Guava
27.0, depends on
listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
version number is enough for some build systems (notably, Gradle) to select
that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
conflict with the copy of ListenableFuture in guava itself. If users are
using an older version of Guava or a build system other than Gradle, they
may see class conflicts. If so, they can solve them by manually excluding
the listenablefuture artifact or manually forcing their build systems to
use 9999.0-....
File Path: /home/jenkins/.mvnrepository/com/google/guava/listenablefuture/9999.0-empty-to-avoid-conflict-with-guava/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar MD5: d094c22570d65e132c19cea5d352e381 SHA1: b421526c5f297295adef1c886e5246c39d4ac629 SHA256:b372a037d4230aa57fbeffdef30fd6123f9c0c2db85d0aced00c91b974f33f99 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Lesser General Public License, version 3 or greater: http://www.gnu.org/licenses/lgpl.html
Apache Software License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0
File Path: /home/jenkins/.mvnrepository/com/github/fge/msg-simple/1.1/msg-simple-1.1.jar MD5: b0d8d70468edff2e223b3d2f07cc5de1 SHA1: f261263e13dd4cfa93cc6b83f1f58f619097a2c4 SHA256:c3c5add3971a9a7f1868beb7607780d73f36bb611c7505de01f1baf49ab4ff75 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Java command line parser with both an annotations API and a programmatic API. Usage help with ANSI styles and colors. Autocomplete. Nested subcommands. Easily included as source to avoid adding a dependency.
License:
The Apache Software License, version 2.0: http://www.apache.org/licenses/LICENSE-2.0.txt
File Path: /home/jenkins/.mvnrepository/info/picocli/picocli/4.6.1/picocli-4.6.1.jar MD5: f09461a45f8d0591e6625bc4ecba5ced SHA1: 49a67ee4b4d9722fa60f3f9ffaffa72861c32966 SHA256:2a6e03310db149f8a11eb058aa78e775c229ef816333c9687379762d22833ad6 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
The entry point for production applications using the custom ClassLoader.
This contains the production ClassLoader code and must not have any non
parent first dependencies.
File Path: /home/jenkins/.mvnrepository/io/quarkus/quarkus-bootstrap-runner/1.13.7.Final/quarkus-bootstrap-runner-1.13.7.Final.jar MD5: 57a3e39a45aedcde95858e0426223058 SHA1: e1f2ee0ec42fcffa417f1d49ff3edded25212528 SHA256:da8b7f5dfd7403a180df34dd482bb8abf0b3aec836f7c9d02b41185535e744e7 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
This module only exists as a separate module to house the configuration that needs to be present on the runtime classpath when the kubernetes extension is used
File Path: /home/jenkins/.mvnrepository/io/quarkus/quarkus-kubernetes-client-internal/1.13.7.Final/quarkus-kubernetes-client-internal-1.13.7.Final.jar MD5: 92ccbbaeb0a1092dd925eb6c8076d4a7 SHA1: 96bc4ec35a82f92db48620f7971305411363e766 SHA256:58601b9a5ed6fe782979d258fcba31025909075ab736b80925f509f747592025 Referenced In Project/Scope:Entando K8S Controller for Entando App Deployments:compile
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
A vulnerability was found in Keycloak before 11.0.1 where DoS attack is possible by sending twenty requests simultaneously to the specified keycloak server, all with a Content-Length header value that exceeds the actual byte count of the request body.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0, where it is possible to force the server to call out an unverified URL using the OIDC parameter request_uri. This flaw allows an attacker to use this parameter to execute a Server-side request forgery (SSRF) attack.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0, where it is possible to add unsafe schemes for the redirect_uri parameter. This flaw allows an attacker to perform a Cross-site scripting attack.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0 where an external identity provider, after successful authentication, redirects to a Keycloak endpoint that accepts multiple invocations with the use of the same "state" parameter. This flaw allows a malicious user to perform replay attacks.
CWE-294 Authentication Bypass by Capture-replay
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in keycloak, where path traversal using URL-encoded path segments in the request is possible because the resources endpoint applies a transformation of the url path to the file path. Only few specific folder hierarchies can be exposed by this flaw
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
It was found that Keycloak before version 12.0.0 would permit a user with only view-profile role to manage the resources in the new account console, allowing access and modification of data the user was not intended to have.
CWE-269 Improper Privilege Management
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in all versions of Keycloak before 10.0.0, where the NodeJS adapter did not support the verify-token-audience. This flaw results in some users having access to sensitive information outside of their permissions.
CWE-732 Incorrect Permission Assignment for Critical Resource
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 11.0.0, where the code base contains usages of ObjectInputStream without type checks. This flaw allows an attacker to inject arbitrarily serialized Java Objects, which would then get deserialized in a privileged context and potentially lead to remote code execution.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak before version 13.0.0. In some scenarios a user still has access to a resource after changing the role mappings in Keycloak and after expiration of the previous access token.
CWE-863 Incorrect Authorization
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in all versions of Keycloak where, the pages on the Admin Console area of the application are completely missing general HTTP security headers in HTTP-responses. This does not directly lead to a security issue, yet it might aid attackers in their efforts to exploit other problems. The flaws unnecessarily make the servers more prone to Clickjacking, channel downgrade attacks and other similar client-based attack vectors.
CWE-1021 Improper Restriction of Rendered UI Layers or Frames
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.
CWE-295 Improper Certificate Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0 where it is possible to update the user's metadata attributes using Account REST API. This flaw allows an attacker to change its own NameID attribute to impersonate the admin user for any particular application.
CWE-250 Execution with Unnecessary Privileges
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions prior to 13.0.0. The client registration endpoint allows fetching information about PUBLIC clients (like client secret) without authentication which could be an issue if the same PUBLIC client changed to CONFIDENTIAL later. The highest threat from this vulnerability is to data confidentiality.
CWE-287 Improper Authentication
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions before 13.0.0. A Self Stored XSS attack vector escalating to a complete account takeover is possible due to user-supplied data fields not being properly encoded and Javascript code being used to process the data. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. Directories can be created prior to the Java process creating them in the temporary directory, but with wider user permissions, allowing the attacker to have access to the contents that keycloak stores in this directory. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-377 Insecure Temporary File
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. The new account console in keycloak can allow malicious code to be executed using the referrer URL. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak-model-infinispan in keycloak versions before 14.0.0 where authenticationSessions map in RootAuthenticationSessionEntity grows boundlessly which could lead to a DoS attack.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in Keycloak before 11.0.1 where DoS attack is possible by sending twenty requests simultaneously to the specified keycloak server, all with a Content-Length header value that exceeds the actual byte count of the request body.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0, where it is possible to force the server to call out an unverified URL using the OIDC parameter request_uri. This flaw allows an attacker to use this parameter to execute a Server-side request forgery (SSRF) attack.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0, where it is possible to add unsafe schemes for the redirect_uri parameter. This flaw allows an attacker to perform a Cross-site scripting attack.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0 where an external identity provider, after successful authentication, redirects to a Keycloak endpoint that accepts multiple invocations with the use of the same "state" parameter. This flaw allows a malicious user to perform replay attacks.
CWE-294 Authentication Bypass by Capture-replay
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in keycloak, where path traversal using URL-encoded path segments in the request is possible because the resources endpoint applies a transformation of the url path to the file path. Only few specific folder hierarchies can be exposed by this flaw
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
It was found that Keycloak before version 12.0.0 would permit a user with only view-profile role to manage the resources in the new account console, allowing access and modification of data the user was not intended to have.
CWE-269 Improper Privilege Management
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in all versions of Keycloak before 10.0.0, where the NodeJS adapter did not support the verify-token-audience. This flaw results in some users having access to sensitive information outside of their permissions.
CWE-732 Incorrect Permission Assignment for Critical Resource
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 11.0.0, where the code base contains usages of ObjectInputStream without type checks. This flaw allows an attacker to inject arbitrarily serialized Java Objects, which would then get deserialized in a privileged context and potentially lead to remote code execution.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak before version 13.0.0. In some scenarios a user still has access to a resource after changing the role mappings in Keycloak and after expiration of the previous access token.
CWE-863 Incorrect Authorization
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in all versions of Keycloak where, the pages on the Admin Console area of the application are completely missing general HTTP security headers in HTTP-responses. This does not directly lead to a security issue, yet it might aid attackers in their efforts to exploit other problems. The flaws unnecessarily make the servers more prone to Clickjacking, channel downgrade attacks and other similar client-based attack vectors.
CWE-1021 Improper Restriction of Rendered UI Layers or Frames
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.
CWE-295 Improper Certificate Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0 where it is possible to update the user's metadata attributes using Account REST API. This flaw allows an attacker to change its own NameID attribute to impersonate the admin user for any particular application.
CWE-250 Execution with Unnecessary Privileges
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions prior to 13.0.0. The client registration endpoint allows fetching information about PUBLIC clients (like client secret) without authentication which could be an issue if the same PUBLIC client changed to CONFIDENTIAL later. The highest threat from this vulnerability is to data confidentiality.
CWE-287 Improper Authentication
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions before 13.0.0. A Self Stored XSS attack vector escalating to a complete account takeover is possible due to user-supplied data fields not being properly encoded and Javascript code being used to process the data. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. Directories can be created prior to the Java process creating them in the temporary directory, but with wider user permissions, allowing the attacker to have access to the contents that keycloak stores in this directory. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-377 Insecure Temporary File
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. The new account console in keycloak can allow malicious code to be executed using the referrer URL. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak-model-infinispan in keycloak versions before 14.0.0 where authenticationSessions map in RootAuthenticationSessionEntity grows boundlessly which could lead to a DoS attack.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in Keycloak before 11.0.1 where DoS attack is possible by sending twenty requests simultaneously to the specified keycloak server, all with a Content-Length header value that exceeds the actual byte count of the request body.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0, where it is possible to force the server to call out an unverified URL using the OIDC parameter request_uri. This flaw allows an attacker to use this parameter to execute a Server-side request forgery (SSRF) attack.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0, where it is possible to add unsafe schemes for the redirect_uri parameter. This flaw allows an attacker to perform a Cross-site scripting attack.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before 13.0.0 where an external identity provider, after successful authentication, redirects to a Keycloak endpoint that accepts multiple invocations with the use of the same "state" parameter. This flaw allows a malicious user to perform replay attacks.
CWE-294 Authentication Bypass by Capture-replay
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in keycloak, where path traversal using URL-encoded path segments in the request is possible because the resources endpoint applies a transformation of the url path to the file path. Only few specific folder hierarchies can be exposed by this flaw
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
It was found that Keycloak before version 12.0.0 would permit a user with only view-profile role to manage the resources in the new account console, allowing access and modification of data the user was not intended to have.
CWE-269 Improper Privilege Management
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in all versions of Keycloak before 10.0.0, where the NodeJS adapter did not support the verify-token-audience. This flaw results in some users having access to sensitive information outside of their permissions.
CWE-732 Incorrect Permission Assignment for Critical Resource
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 11.0.0, where the code base contains usages of ObjectInputStream without type checks. This flaw allows an attacker to inject arbitrarily serialized Java Objects, which would then get deserialized in a privileged context and potentially lead to remote code execution.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak before version 13.0.0. In some scenarios a user still has access to a resource after changing the role mappings in Keycloak and after expiration of the previous access token.
CWE-863 Incorrect Authorization
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A vulnerability was found in all versions of Keycloak where, the pages on the Admin Console area of the application are completely missing general HTTP security headers in HTTP-responses. This does not directly lead to a security issue, yet it might aid attackers in their efforts to exploit other problems. The flaws unnecessarily make the servers more prone to Clickjacking, channel downgrade attacks and other similar client-based attack vectors.
CWE-1021 Improper Restriction of Rendered UI Layers or Frames
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak in versions before 10.0.0, where it does not perform the TLS hostname verification while sending emails using the SMTP server. This flaw allows an attacker to perform a man-in-the-middle (MITM) attack.
CWE-295 Improper Certificate Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in Keycloak before version 12.0.0 where it is possible to update the user's metadata attributes using Account REST API. This flaw allows an attacker to change its own NameID attribute to impersonate the admin user for any particular application.
CWE-250 Execution with Unnecessary Privileges
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions prior to 13.0.0. The client registration endpoint allows fetching information about PUBLIC clients (like client secret) without authentication which could be an issue if the same PUBLIC client changed to CONFIDENTIAL later. The highest threat from this vulnerability is to data confidentiality.
CWE-287 Improper Authentication
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak in versions before 13.0.0. A Self Stored XSS attack vector escalating to a complete account takeover is possible due to user-supplied data fields not being properly encoded and Javascript code being used to process the data. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. Directories can be created prior to the Java process creating them in the temporary directory, but with wider user permissions, allowing the attacker to have access to the contents that keycloak stores in this directory. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-377 Insecure Temporary File
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak. The new account console in keycloak can allow malicious code to be executed using the referrer URL. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
CWE-20 Improper Input Validation
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
A flaw was found in keycloak-model-infinispan in keycloak versions before 14.0.0 where authenticationSessions map in RootAuthenticationSessionEntity grows boundlessly which could lead to a DoS attack.
CWE-770 Allocation of Resources Without Limits or Throttling
Notes: These are generally serverside vulnerabilities. The entando-k8s containers that use Keycloak run as
background processes that do not expose services. We also do not have a version of Keycloak to upgrade to
beyond 9.0.3 because this is the official version used in Red Hat SSO
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executing the client code.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Notes: A whole lot of false positives based on K8S's internals that have nothing to do with our CRDs
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
The entry point for production applications using the custom ClassLoader.
This contains the production ClassLoader code and must not have any non
parent first dependencies.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Improper validation of URL redirection in the Kubernetes API server in versions prior to v1.14.0 allows an attacker-controlled Kubelet to redirect API server requests from streaming endpoints to arbitrary hosts. Impacted API servers will follow the redirect as a GET request with client-certificate credentials for authenticating to the Kubelet.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.
CWE-732 Incorrect Permission Assignment for Critical Resource
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.12.9, versions prior to 1.13.6, versions prior to 1.14.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The Kubernetes kube-apiserver mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges). Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.7, 1.8, 1.9, 1.10, 1.11, 1.12.
The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port. The go pprof endpoint is exposed over the Kubelet's healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service. Versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10 are affected. The issue is of medium severity, but not exposed by the default configuration.
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected.
The Kubernetes kubectl cp command in versions 1.1-1.12, and versions prior to 1.13.11, 1.14.7, and 1.15.4 allows a combination of two symlinks provided by tar output of a malicious container to place a file outside of the destination directory specified in the kubectl cp invocation. This could be used to allow an attacker to place a nefarious file using a symlink, outside of the destination tree.
CWE-59 Improper Link Resolution Before File Access ('Link Following')
The Kubernetes kube-controller-manager in versions v1.0-v1.17 is vulnerable to a credential leakage via error messages in mount failure logs and events for AzureFile and CephFS volumes.
CWE-209 Information Exposure Through an Error Message
The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7 and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML.
The Kubernetes API server component in versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.
CWE-770 Allocation of Resources Without Limits or Throttling
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
The Kubernetes kube-controller-manager in versions v1.0-1.14, versions prior to v1.15.12, v1.16.9, v1.17.5, and version v1.18.0 are vulnerable to a Server Side Request Forgery (SSRF) that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master's host network (such as link-local or loopback services).
The Kubernetes kubelet component in versions 1.1-1.16.12, 1.17.0-1.17.8 and 1.18.0-1.18.5 do not account for disk usage by a pod which writes to its own /etc/hosts file. The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.
The Kubelet and kube-proxy components in versions 1.1.0-1.16.10, 1.17.0-1.17.6, and 1.18.0-1.18.3 were found to contain a security issue which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. Such a service is generally thought to be reachable only by other processes on the same host, but due to this defeect, could be reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service.
The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.6 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
In Kubernetes clusters using VSphere as a cloud provider, with a logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log. This affects < v1.19.3.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
This module only exists as a separate module to house the configuration that needs to be present on the runtime classpath when the kubernetes extension is used
Improper validation of URL redirection in the Kubernetes API server in versions prior to v1.14.0 allows an attacker-controlled Kubelet to redirect API server requests from streaming endpoints to arbitrary hosts. Impacted API servers will follow the redirect as a GET request with client-certificate credentials for authenticating to the Kubelet.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.
CWE-732 Incorrect Permission Assignment for Critical Resource
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.12.9, versions prior to 1.13.6, versions prior to 1.14.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The Kubernetes kube-apiserver mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges). Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.7, 1.8, 1.9, 1.10, 1.11, 1.12.
The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port. The go pprof endpoint is exposed over the Kubelet's healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service. Versions prior to 1.15.0, 1.14.4, 1.13.8, and 1.12.10 are affected. The issue is of medium severity, but not exposed by the default configuration.
The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine. If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path on the user’s machine when kubectl cp is called, limited only by the system permissions of the local user. Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.1, 1.2, 1.4, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12.
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The Kubernetes client-go library logs request headers at verbosity levels of 7 or higher. This can disclose credentials to unauthorized users via logs or command output. Kubernetes components (such as kube-apiserver) prior to v1.16.0, which make use of basic or bearer token authentication, and run at high verbosity levels, are affected.
The Kubernetes kubectl cp command in versions 1.1-1.12, and versions prior to 1.13.11, 1.14.7, and 1.15.4 allows a combination of two symlinks provided by tar output of a malicious container to place a file outside of the destination directory specified in the kubectl cp invocation. This could be used to allow an attacker to place a nefarious file using a symlink, outside of the destination tree.
CWE-59 Improper Link Resolution Before File Access ('Link Following')
The Kubernetes kube-controller-manager in versions v1.0-v1.17 is vulnerable to a credential leakage via error messages in mount failure logs and events for AzureFile and CephFS volumes.
CWE-209 Information Exposure Through an Error Message
The Kubernetes API Server component in versions 1.1-1.14, and versions prior to 1.15.10, 1.16.7 and 1.17.3 allows an authorized user who sends malicious YAML payloads to cause the kube-apiserver to consume excessive CPU cycles while parsing YAML.
The Kubernetes API server component in versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.
CWE-770 Allocation of Resources Without Limits or Throttling
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
The Kubernetes kube-controller-manager in versions v1.0-1.14, versions prior to v1.15.12, v1.16.9, v1.17.5, and version v1.18.0 are vulnerable to a Server Side Request Forgery (SSRF) that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master's host network (such as link-local or loopback services).
The Kubernetes kubelet component in versions 1.1-1.16.12, 1.17.0-1.17.8 and 1.18.0-1.18.5 do not account for disk usage by a pod which writes to its own /etc/hosts file. The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.
The Kubelet and kube-proxy components in versions 1.1.0-1.16.10, 1.17.0-1.17.6, and 1.18.0-1.18.3 were found to contain a security issue which allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. Such a service is generally thought to be reachable only by other processes on the same host, but due to this defeect, could be reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service.
The Kubernetes kube-apiserver in versions v1.6-v1.15, and versions prior to v1.16.13, v1.17.9 and v1.18.6 are vulnerable to an unvalidated redirect on proxied upgrade requests that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
In Kubernetes clusters using VSphere as a cloud provider, with a logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log. This affects < v1.19.3.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CWE-378 Creation of Temporary File With Insecure Permissions, CWE-379 Creation of Temporary File in Directory with Incorrect Permissions
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
Notes: Not much we can do about this one except implementing Quarkus 2 which will require significant effort.
A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.
CWE-209 Information Exposure Through an Error Message
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A reflected Cross-Site Scripting (XSS) flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final, where it did not properly handle URL encoding when calling @javax.ws.rs.PathParam without any @Produces MediaType. This flaw allows an attacker to launch a reflected XSS attack. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.
CWE-209 Information Exposure Through an Error Message
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A reflected Cross-Site Scripting (XSS) flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final, where it did not properly handle URL encoding when calling @javax.ws.rs.PathParam without any @Produces MediaType. This flaw allows an attacker to launch a reflected XSS attack. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.
CWE-209 Information Exposure Through an Error Message
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A reflected Cross-Site Scripting (XSS) flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final, where it did not properly handle URL encoding when calling @javax.ws.rs.PathParam without any @Produces MediaType. This flaw allows an attacker to launch a reflected XSS attack. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.
CWE-209 Information Exposure Through an Error Message
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A reflected Cross-Site Scripting (XSS) flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final, where it did not properly handle URL encoding when calling @javax.ws.rs.PathParam without any @Produces MediaType. This flaw allows an attacker to launch a reflected XSS attack. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.
CWE-209 Information Exposure Through an Error Message
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.
A reflected Cross-Site Scripting (XSS) flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final, where it did not properly handle URL encoding when calling @javax.ws.rs.PathParam without any @Produces MediaType. This flaw allows an attacker to launch a reflected XSS attack. The highest threat from this vulnerability is to data confidentiality and integrity.
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Notes: Not much we can do about this one except for wait for Keycloak 8. We can only update the client if the
server is updated.