Skip to main content
HIGH7.5CVE-2019-11253
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Affected projects
kubernetes
Disclosed
Last updated

Affected versions

ProjectVulnerable range
kubernetesv1.0.0-1.12.x
kubernetesv1.13.0-1.13.11
kubernetesv1.14.0-1.14.7
kubernetesv1.15.0-1.15.4
kubernetesv1.16.0-1.16.1

Patched versions

ProjectFixed in
kubernetesv1.13.12
kubernetesv1.14.8
kubernetesv1.15.5
kubernetesv1.16.2

References

Summary

CVE-2019-11253 is a denial-of-service vulnerability in the kube-apiserver affecting Kubernetes v1.0.0 through v1.16.1. Authorized users — and, in clusters running versions prior to v1.14.0 or upgraded from such versions without a policy update, unauthenticated users — could send malicious YAML or JSON payloads containing recursive anchor references (a "Billion Laughs" style attack) to cause the kube-apiserver to consume excessive CPU or memory, potentially crashing it and rendering the cluster unavailable.

Impact

The kube-apiserver parses YAML and JSON from API requests without adequate resource limits on recursive anchor expansion. A malicious payload — for example, a ConfigMap containing deeply nested YAML anchors — causes exponential memory and CPU consumption during parsing. Prior to v1.14.0, the default RBAC policy authorized anonymous users to submit such requests, meaning the attack surface extended beyond authenticated principals. Clusters upgraded from a pre-v1.14.0 release retain the more permissive RBAC policy by default unless manually updated, even after the binary is patched.

Detection

Monitor kube-apiserver CPU and memory metrics for sudden unexplained spikes, particularly following the application of ConfigMap, Secret, or other YAML-heavy resource submissions. Review API server audit logs for requests originating from anonymous or unexpected principals targeting resource-creation endpoints. After applying the mitigation, check whether the system:basic-user ClusterRoleBinding retains the rbac.authorization.kubernetes.io/autoupdate=false annotation if your cluster was upgraded from a pre-v1.14.0 release, as this indicates the restrictive policy was intentionally pinned. Refer to the upstream issue for additional context.

Mitigation

Upgrade to the patched releases for your release branch: v1.13.12, v1.14.8, v1.15.5, or v1.16.2. All four patch releases were made available simultaneously.

Additionally, apply the more restrictive RBAC policy that removes anonymous access, which is required both as a pre-upgrade mitigation and as supplementary hardening for already-upgraded clusters that were originally running a version prior to v1.14.0:

kubectl auth reconcile -f rbac.yaml --remove-extra-subjects --remove-extra-permissions

Note: this command removes the ability for unauthenticated users to use kubectl auth can-i. If running a version prior to v1.14.0, also disable autoupdate on the affected ClusterRoleBinding to prevent the policy from being reverted on API server restart:

kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=false

After upgrading to v1.14.0 or later, the annotation can be removed to re-enable autoupdate:

kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=true

References