A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary SQL commands via a specific ArcGIS Feature Service operation. Successful exploitation can potentially result in unauthorized access, modification, or deletion of data from the underlying Enterprise Geodatabase.

An incorrect authorization vulnerability exists in Esri Portal for ArcGIS 11.4, 11.5 and 12.0 on Windows, Linux and Kubernetes that did not correctly check permissions assigned to developer credentials.

Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes have a missing authentication for critical function vulnerability allows a remote, unauthenticated attacker to access an unprotected API.

A Weak Password Recovery Mechanism for Forgotten Password exists in Esri Portal for ArcGIS versions 12.1 and earlier on Windows, Linux and Kubernetes. A remote, unauthorized attacker may assume ownership of a user’s account by manipulating this mechanism. ArcGIS Administrators should configure an email server with ArcGIS Enterprise to facilitate user self-service password recovery. The ability for an administrator to reset a user’s password remains unchanged.

A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.

A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.

The Kubernetes API server 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).

In kubelet v1.13.6 and v1.14.2, containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0.

A flaw was found kubernetes. The parsing of YAML manifests by the Kubernetes API server could lead to a denial-of-service attack leaving it vulnerable to an instance of a "billion laughs" attack. The highest threat from this vulnerability is to system availability.

A vulnerability exists in F5 BIG-IP Container Ingress Services that may allow excessive permissions to read cluster secrets.

A flaw was found in the Kubernetes API server, where it allows an attacker to escalate their privileges from a compromised node. This flaw allows an attacker who can intercept requests on a compromised node, to redirect those requests, along with their credentials, to perform actions on other endpoints that trust those credentials (including other clusters), allowing for escalation of privileges. The highest threat from this vulnerability is to confidentiality, integrity, and system availability.

A vulnerability exists in the NodeRestriction admission controller in Kubernetes clusters where node users can delete their corresponding node object by patching themselves with an OwnerReference to a cluster-scoped resource. If the OwnerReference resource does not exist or is subsequently deleted, the given node object will be deleted via garbage collection.

Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication.

Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system.

The Kubelet component in versions 1.15.0-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 the kubelet API, including the unauthenticated HTTP read-only API typically served on port 10255, and the authenticated HTTPS API typically served on port 10250.

A denial of service vulnerability was found in the kube-apiserver, allowing authorized users sending malicious YAML payloads to cause kube-apiserver to consume excessive CPU cycles while parsing YAML.

Upstream Issue:

https://github.com/kubernetes/kubernetes/issues/89535

A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. Clusters are only affected by this vulnerability if they run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object. Validating Admission Webhook does not observe some previous fields.

A flaw was found in kubernetes. Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different kind in the same API group they are not authorized to read.

Default access permissions for Persistent Volumes (PVs) created by the Kubernetes Azure cloud provider in versions 1.6.0 to 1.6.5 are set to "container" which exposes a URI that can be accessed without authentication on the public internet. Access to the URI string requires privileged access to the Kubernetes cluster or authenticated access to the Azure portal.

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.

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.

A security issue was discovered in Kubernetes where users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.

This issue affects kube-apiserver. Clusters are impacted by this vulnerability if: 1. The ImagePolicyWebhook admission plugin is used to restrict the use of certain images and 2. Pods using ephemeral containers.

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with ephemeral containers.

This issue affects kube-apiserver. Clusters are impacted by this vulnerability if:

1. The ServiceAccount admission plugin is used. Most clusters should have this on by default as recommended in https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount 2. The kubernetes.io/enforce-mountable-secrets annotation is used by a service account. This annotation is not added by default. 3. Pods using ephemeral containers.

A server side request forgery (SSRF) flaw was found in Kubernetes. The kube-controller-manager allows authorized users with the ability to create StorageClasses or certain Volume types to leak up to 500 bytes of arbitrary information from the master's host network. This can include secrets from the kube-apiserver through the unauthenticated localhost port (if enabled).

A flaw was found in kubernetes. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.

Kube-proxy on Windows can unintentionally forward traffic to local processes listening on the same port (“spec.ports[].port”) as a LoadBalancer Service when the LoadBalancer controller does not set the “status.loadBalancer.ingress[].ip” field. Clusters where the LoadBalancer controller sets the “status.loadBalancer.ingress[].ip” field are unaffected.

A flaw was found in Kubernetes, where the amount of disk space the /etc/hosts file can use is unconstrained . This flaw can allow attacker-controlled pods to cause a denial of service if they have permission to write to the node's /etc/hosts file.

A flaw was found in kubernetes. In Kubernetes, if the logging level is to at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials. This can occur with client tools like kubectl, or other components that use registry credentials in a docker config file.