Common Weakness Enumeration

CWE-601

Allowed

URL Redirection to Untrusted Site ('Open Redirect')

Abstraction: Base · Status: Draft

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

2310 vulnerabilities reference this CWE, most recent first.

GHSA-9QXC-J46X-62M2

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:37
VLAI
Details

An Open Redirect vulnerability located in the webserver affects several Bosch hardware and software products. The vulnerability potentially allows a remote attacker to redirect users to an arbitrary URL. Affected hardware products: Bosch DIVAR IP 2000 (vulnerable versions: 3.10; 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.62.0019 and newer), Bosch DIVAR IP 5000 (vulnerable versions: 3.10; 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.80.0033 and newer). Affected software products: Video Recording Manager (VRM) (vulnerable versions: 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.70.0056 and newer; 3.81.0032 and newer), Bosch Video Management System (BVMS) (vulnerable versions: 3.50.00XX; 3.55.00XX; 3.60.00XX; fixed versions: 7.5; 3.70.0056).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-8951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-13T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An Open Redirect vulnerability located in the webserver affects several Bosch hardware and software products. The vulnerability potentially allows a remote attacker to redirect users to an arbitrary URL. Affected hardware products: Bosch DIVAR IP 2000 (vulnerable versions: 3.10; 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.62.0019 and newer), Bosch DIVAR IP 5000 (vulnerable versions: 3.10; 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.80.0033 and newer). Affected software products: Video Recording Manager (VRM) (vulnerable versions: 3.20; 3.21; 3.50; 3.51; 3.55; 3.60; 3.61; 3.62; fixed versions: 3.70.0056 and newer; 3.81.0032 and newer), Bosch Video Management System (BVMS) (vulnerable versions: 3.50.00XX; 3.55.00XX; 3.60.00XX; fixed versions: 7.5; 3.70.0056).",
  "id": "GHSA-9qxc-j46x-62m2",
  "modified": "2024-04-04T00:37:24Z",
  "published": "2022-05-24T16:45:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8951"
    },
    {
      "type": "WEB",
      "url": "https://media.boschsecurity.com/fs/media/pb/security_advisories/bosch-2019-0401bt-cve-2019-8951_security_advisory_vrm_open_redirect.pdf"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/Advisory/BOSCH-2019-0401.html"
    },
    {
      "type": "WEB",
      "url": "https://www.boschsecurity.com/xc/en/support/product-security/security-advisories.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RC6-8CJV-RCVX

Vulnerability from github – Published: 2026-06-26 23:05 – Updated: 2026-06-26 23:05
VLAI
Summary
Nezha Monitoring: OAuth2 Redirect URL — Host Header Injection
Details

1. Description

The getRedirectURL function in oauth2.go:22-29 constructs the OAuth2 callback URL by concatenating the request's Host header with a fixed path, with zero validation of the Host header:

func getRedirectURL(c *gin.Context) string {
    scheme := "http://"
    referer := c.Request.Referer()
    if forwardedProto := c.Request.Header.Get("X-Forwarded-Proto"); forwardedProto == "https" || strings.HasPrefix(referer, "https://") {
        scheme = "https://"
    }
    return scheme + c.Request.Host + "/api/v1/oauth2/callback"
}

File: cmd/dashboard/controller/oauth2.go:22-29

This function is called from oauth2redirect() at line 53:

func oauth2redirect(c *gin.Context) (*model.Oauth2LoginResponse, error) {
    // ...
    redirectURL := getRedirectURL(c)
    o2conf := o2confRaw.Setup(redirectURL)
    // ...
    url := o2conf.AuthCodeURL(state, oauth2.AccessTypeOnline)
    return &model.Oauth2LoginResponse{Redirect: url}, nil
}

The redirectURL is passed into o2confRaw.Setup(redirectURL) which configures the OAuth2 Config.RedirectURL field (oauth2config.go:22-33). This RedirectURL is sent to the OAuth2 provider (e.g., GitHub, Google, Microsoft) as the callback endpoint. The OAuth2 provider will redirect the user's browser — along with the authorization code — to this URL after the user authenticates.

The security issue is that c.Request.Host is directly user-controllable via the HTTP Host header. An attacker who can control which Host header reaches the oauth2redirect handler can:

  1. Set Host: evil.com
  2. getRedirectURL returns https://evil.com/api/v1/oauth2/callback
  3. The OAuth2 provider redirects the victim's auth code to evil.com
  4. The attacker's server at evil.com captures the auth code
  5. The attacker exchanges the code for an access token, binding the victim's OAuth identity to the attacker's dashboard account

The scheme detection (lines 24-27) uses X-Forwarded-Proto and the Referer header, both of which are also user-controllable in certain configurations, so the attacker can force https:// scheme in the redirect URL.

The oauth2callback handler at line 129 later uses state.RedirectURL (which is stored in singleton.Cache at line 65) when calling exchangeOpenId at line 152. The cached redirectURL was set during the initial oauth2redirect call, tying the attack flow together.

2. PoC

A conceptual attack (no Docker needed):

Scenario: OAuth2 provider has loose redirect URI validation
          (e.g., allows wildcard subdomain matching)

1. Attacker crafts a URL to the dashboard's OAuth2 login endpoint
   with a modified Host header:

   GET /api/v1/oauth2/github HTTP/1.1
   Host: attacker-controlled.com
   X-Forwarded-Proto: https

2. The dashboard responds with a redirect to:
   https://github.com/login/oauth/authorize?client_id=...&redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback&state=...

3. Victim clicks the attacker's link → authenticates with GitHub
   → GitHub redirects to https://attacker-controlled.com/api/v1/oauth2/callback?code=AUTH_CODE&state=...

4. Attacker captures the AUTH_CODE from their server logs

5. Attacker exchanges the code at the real dashboard's
   /api/v1/oauth2/callback endpoint (using the real Host header
   this time), binding the victim's OAuth identity to their
   dashboard account

Prerequisites for full exploit: - The victim must click the attacker's crafted link - The OAuth2 provider must accept the attacker's domain as a valid redirect URI (some providers accept https://*/* or allow wildcards; others are strict)

3. Impact

  • Account takeover: an attacker who intercepts the OAuth2 authorization code can bind the victim's OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim's access level and permissions
  • Privilege escalation: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment — access to all servers, credentials, and configuration
  • Persistence: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)

The attack complexity is higher than typical Host header injection scenarios because it requires: 1. The Host header to reach the dashboard's handler unmodified (bypassing reverse proxy normalization) 2. The OAuth2 provider to have loose redirect URL validation 3. User interaction (the victim must authenticate)

However, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (Host header) for a security-critical URL that participates in the OAuth2 authorization code flow.

4. Remediation

  1. Validate the Host header against a configured allowlist of known dashboard hostnames: go func getRedirectURL(c *gin.Context) string { host := c.Request.Host if !singleton.Conf.IsAllowedHost(host) { host = singleton.Conf.DashboardBaseURL // fallback } // ... }

  2. Pin the redirect URL to the configured dashboard URL from singleton.Conf instead of deriving it from the request Host header: go func getRedirectURL(c *gin.Context) string { return singleton.Conf.DashboardBaseURL + "/api/v1/oauth2/callback" }

  3. Remove Host header-based URL construction entirely — the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request

  4. Add Host header validation middleware for all OAuth2-related endpoints as defense-in-depth

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:05:19Z",
    "nvd_published_at": "2026-06-12T22:16:52Z",
    "severity": "MODERATE"
  },
  "details": "## 1. Description\n\nThe `getRedirectURL` function in `oauth2.go:22-29` constructs the OAuth2 callback URL by concatenating the request\u0027s `Host` header with a fixed path, with **zero validation** of the Host header:\n\n```go\nfunc getRedirectURL(c *gin.Context) string {\n    scheme := \"http://\"\n    referer := c.Request.Referer()\n    if forwardedProto := c.Request.Header.Get(\"X-Forwarded-Proto\"); forwardedProto == \"https\" || strings.HasPrefix(referer, \"https://\") {\n        scheme = \"https://\"\n    }\n    return scheme + c.Request.Host + \"/api/v1/oauth2/callback\"\n}\n```\n\n**File:** `cmd/dashboard/controller/oauth2.go:22-29`\n\nThis function is called from `oauth2redirect()` at line 53:\n```go\nfunc oauth2redirect(c *gin.Context) (*model.Oauth2LoginResponse, error) {\n    // ...\n    redirectURL := getRedirectURL(c)\n    o2conf := o2confRaw.Setup(redirectURL)\n    // ...\n    url := o2conf.AuthCodeURL(state, oauth2.AccessTypeOnline)\n    return \u0026model.Oauth2LoginResponse{Redirect: url}, nil\n}\n```\n\nThe `redirectURL` is passed into `o2confRaw.Setup(redirectURL)` which configures the OAuth2 `Config.RedirectURL` field (`oauth2config.go:22-33`). This `RedirectURL` is sent to the OAuth2 provider (e.g., GitHub, Google, Microsoft) as the callback endpoint. The OAuth2 provider will redirect the user\u0027s browser \u2014 along with the authorization code \u2014 to this URL after the user authenticates.\n\nThe security issue is that `c.Request.Host` is directly user-controllable via the HTTP `Host` header. An attacker who can control which Host header reaches the oauth2redirect handler can:\n\n1. Set `Host: evil.com`\n2. `getRedirectURL` returns `https://evil.com/api/v1/oauth2/callback`\n3. The OAuth2 provider redirects the victim\u0027s auth code to `evil.com`\n4. The attacker\u0027s server at `evil.com` captures the auth code\n5. The attacker exchanges the code for an access token, binding the victim\u0027s OAuth identity to the attacker\u0027s dashboard account\n\nThe scheme detection (lines 24-27) uses `X-Forwarded-Proto` and the `Referer` header, both of which are also user-controllable in certain configurations, so the attacker can force `https://` scheme in the redirect URL.\n\nThe `oauth2callback` handler at line 129 later uses `state.RedirectURL` (which is stored in `singleton.Cache` at line 65) when calling `exchangeOpenId` at line 152. The cached `redirectURL` was set during the initial `oauth2redirect` call, tying the attack flow together.\n\n## 2. PoC\n\nA conceptual attack (no Docker needed):\n\n```\nScenario: OAuth2 provider has loose redirect URI validation\n          (e.g., allows wildcard subdomain matching)\n\n1. Attacker crafts a URL to the dashboard\u0027s OAuth2 login endpoint\n   with a modified Host header:\n\n   GET /api/v1/oauth2/github HTTP/1.1\n   Host: attacker-controlled.com\n   X-Forwarded-Proto: https\n\n2. The dashboard responds with a redirect to:\n   https://github.com/login/oauth/authorize?client_id=...\u0026redirect_uri=https://attacker-controlled.com/api/v1/oauth2/callback\u0026state=...\n\n3. Victim clicks the attacker\u0027s link \u2192 authenticates with GitHub\n   \u2192 GitHub redirects to https://attacker-controlled.com/api/v1/oauth2/callback?code=AUTH_CODE\u0026state=...\n\n4. Attacker captures the AUTH_CODE from their server logs\n\n5. Attacker exchanges the code at the real dashboard\u0027s\n   /api/v1/oauth2/callback endpoint (using the real Host header\n   this time), binding the victim\u0027s OAuth identity to their\n   dashboard account\n```\n\n**Prerequisites for full exploit:**\n- The victim must click the attacker\u0027s crafted link\n- The OAuth2 provider must accept the attacker\u0027s domain as a valid redirect URI (some providers accept `https://*/*` or allow wildcards; others are strict)\n\n## 3. Impact\n\n- **Account takeover**: an attacker who intercepts the OAuth2 authorization code can bind the victim\u0027s OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim\u0027s access level and permissions\n- **Privilege escalation**: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment \u2014 access to all servers, credentials, and configuration\n- **Persistence**: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)\n\nThe attack complexity is higher than typical Host header injection scenarios because it requires:\n1. The `Host` header to reach the dashboard\u0027s handler unmodified (bypassing reverse proxy normalization)\n2. The OAuth2 provider to have loose redirect URL validation\n3. User interaction (the victim must authenticate)\n\nHowever, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (`Host` header) for a security-critical URL that participates in the OAuth2 authorization code flow.\n\n## 4. Remediation\n\n1. **Validate the Host header** against a configured allowlist of known dashboard hostnames:\n   ```go\n   func getRedirectURL(c *gin.Context) string {\n       host := c.Request.Host\n       if !singleton.Conf.IsAllowedHost(host) {\n           host = singleton.Conf.DashboardBaseURL // fallback\n       }\n       // ...\n   }\n   ```\n\n2. **Pin the redirect URL** to the configured dashboard URL from `singleton.Conf` instead of deriving it from the request Host header:\n   ```go\n   func getRedirectURL(c *gin.Context) string {\n       return singleton.Conf.DashboardBaseURL + \"/api/v1/oauth2/callback\"\n   }\n   ```\n\n3. **Remove Host header-based URL construction** entirely \u2014 the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request\n\n4. **Add Host header validation middleware** for all OAuth2-related endpoints as defense-in-depth",
  "id": "GHSA-9rc6-8cjv-rcvx",
  "modified": "2026-06-26T23:05:19Z",
  "published": "2026-06-26T23:05:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-9rc6-8cjv-rcvx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53523"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nezhahq/nezha"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha Monitoring: OAuth2 Redirect URL \u2014 Host Header Injection"
}

GHSA-9VM7-V8WJ-3FQW

Vulnerability from github – Published: 2024-01-23 14:43 – Updated: 2024-12-26 15:09
VLAI
Summary
keycloak-core: open redirect via "form_post.jwt" JARM response mode
Details

An incomplete fix was found in Keycloak Core patch. An attacker can steal authorization codes or tokens from clients using a wildcard in the JARM response mode "form_post.jwt". It is observed that changing the response_mode parameter in the original proof of concept from "form_post" to "form_post.jwt" can bypass the security patch implemented to address CVE-2023-6134.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "23.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-23T14:43:50Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An incomplete fix was found in Keycloak Core patch. An attacker can steal authorization codes or tokens from clients using a wildcard in the JARM response mode \"form_post.jwt\". It is observed that changing the response_mode parameter in the original proof of concept from \"form_post\" to \"form_post.jwt\" can bypass the security patch implemented to address CVE-2023-6134.",
  "id": "GHSA-9vm7-v8wj-3fqw",
  "modified": "2024-12-26T15:09:05Z",
  "published": "2024-01-23T14:43:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-9vm7-v8wj-3fqw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6927"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0094"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0095"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0096"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0097"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0098"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0100"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0101"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-6927"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2255027"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "keycloak-core: open redirect via \"form_post.jwt\" JARM response mode"
}

GHSA-9W2G-9V3R-27RP

Vulnerability from github – Published: 2025-01-27 21:30 – Updated: 2025-01-28 21:31
VLAI
Details

An issue in Guangzhou Polar Future Culture Technology Co., Ltd University Search iOS 2.27.0 allows attackers to access sensitive user information via supplying a crafted link.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-56949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T19:15:16Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Guangzhou Polar Future Culture Technology Co., Ltd University Search iOS 2.27.0 allows attackers to access sensitive user information via supplying a crafted link.",
  "id": "GHSA-9w2g-9v3r-27rp",
  "modified": "2025-01-28T21:31:02Z",
  "published": "2025-01-27T21:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZhouZiyi1/Vuls/blob/main/241212-UniversitySearch/241212-UniversitySearch.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9W78-X9JW-9C7M

Vulnerability from github – Published: 2026-03-12 21:34 – Updated: 2026-03-12 21:34
VLAI
Details

A flaw was found in mirror-registry where an authenticated user can trick the system into accessing unintended internal or restricted systems by providing malicious web addresses.

When the application processes these addresses, it automatically follows redirects without verifying the final destination, allowing attackers to route requests to systems they should not have access to.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-12T19:16:16Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in mirror-registry where an authenticated user can trick the system into accessing unintended internal or restricted systems by providing malicious web addresses. \n\nWhen the application processes these addresses, it automatically follows redirects without verifying the final destination, allowing attackers to route requests to systems they should not have access to.",
  "id": "GHSA-9w78-x9jw-9c7m",
  "modified": "2026-03-12T21:34:50Z",
  "published": "2026-03-12T21:34:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2376"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quay/quay/pull/5074"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-2376"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2439117"
    }
  ],
  "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-9WRG-64CR-9JVF

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2022-02-19 00:02
VLAI
Details

A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V2.0). Affected products contain an open redirect vulnerability. An attacker could trick a valid authenticated user to the device into clicking a malicious link there by leading to phishing attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23102"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SINEMA Remote Connect Server (All versions \u003c V2.0). Affected products contain an open redirect vulnerability. An attacker could trick a valid authenticated user to the device into clicking a malicious link there by leading to phishing attacks.",
  "id": "GHSA-9wrg-64cr-9jvf",
  "modified": "2022-02-19T00:02:36Z",
  "published": "2022-02-10T00:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23102"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-654775.pdf"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/165966/SIEMENS-SINEMA-Remote-Connect-1.0-SP3-HF1-Open-Redirection.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2022/Feb/20"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9X43-5QCQ-H79Q

Vulnerability from github – Published: 2023-10-22 21:36 – Updated: 2024-09-13 20:12
VLAI
Summary
Django Grappelli Open Redirect vulnerability
Details

views/switch.py in django-grappelli (aka Django Grappelli) before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "django-grappelli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-46898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-24T01:46:26Z",
    "nvd_published_at": "2023-10-22T19:15:08Z",
    "severity": "MODERATE"
  },
  "details": "views/switch.py in django-grappelli (aka Django Grappelli) before 2.15.2 attempts to prevent external redirection with startswith(\"/\") but this does not consider a protocol-relative URL (e.g., //example.com) attack.",
  "id": "GHSA-9x43-5qcq-h79q",
  "modified": "2024-09-13T20:12:08Z",
  "published": "2023-10-22T21:36:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46898"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sehmaschine/django-grappelli/issues/975"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sehmaschine/django-grappelli/pull/976"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sehmaschine/django-grappelli/commit/4ca94bcda0fa2720594506853d85e00c8212968f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django-grappelli/PYSEC-2023-211.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sehmaschine/django-grappelli"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sehmaschine/django-grappelli/compare/2.15.1...2.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Django Grappelli Open Redirect vulnerability"
}

GHSA-9X9C-GHC5-JHW9

Vulnerability from github – Published: 2025-08-15 16:52 – Updated: 2025-08-15 20:55
VLAI
Summary
@astrojs/node's trailing slash handling causes open redirect issue
Details

Summary

Following https://github.com/withastro/astro/security/advisories/GHSA-cq8c-xv66-36gw, there's still an Open Redirect vulnerability in a subset of Astro deployment scenarios.

Details

Astro 5.12.8 fixed a case where https://example.com//astro.build/press would redirect to the external origin //astro.build/press. However, with the Node deployment adapter in standalone mode and trailingSlash set to "always" in the Astro configuration, https://example.com//astro.build/press still redirects to //astro.build/press.

Proof of Concept

  1. Create a new minimal Astro project (astro@5.12.8)
  2. Configure it to use the Node adapter (@astrojs/node@9.4.0) and force trailing slashes: ```js // astro.config.mjs import { defineConfig } from 'astro/config'; import node from '@astrojs/node';

export default defineConfig({ trailingSlash: 'always', adapter: node({ mode: 'standalone' }), }); `` 3. Build the site by runningastro build. 4. Run the server, e.g. withastro preview. 5. Append//astro.build/press` to the preview URL, e.g. http://localhost:4321//astro.build/press 6. The site will redirect to the external Astro Build origin.

Example reproduction

  1. Open this StackBlitz reproduction.
  2. Open the preview in a separate window so the StackBlitz embed doesn't cause security errors.
  3. Append //astro.build/press to the preview URL, e.g. https://x.local-corp.webcontainer.io//astro.build/press.
  4. See it redirect to the external Astro Build origin.

Impact

This is classified as an Open Redirection vulnerability (CWE-601). It affects any user who clicks on a specially crafted link pointing to the affected domain. Since the domain appears legitimate, victims may be tricked into trusting the redirected page, leading to possible credential theft, malware distribution, or other phishing-related attacks.

No authentication is required to exploit this vulnerability. Any unauthenticated user can trigger the redirect by clicking a malicious link.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.4.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-15T16:52:48Z",
    "nvd_published_at": "2025-08-15T16:15:30Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nFollowing https://github.com/withastro/astro/security/advisories/GHSA-cq8c-xv66-36gw, there\u0027s still an Open Redirect vulnerability in a subset of Astro deployment scenarios.\n\n### Details\n\nAstro 5.12.8 fixed a case where `https://example.com//astro.build/press` would redirect to the external origin `//astro.build/press`. However, with the Node deployment adapter in standalone mode and `trailingSlash` set to `\"always\"` in the Astro configuration, `https://example.com//astro.build/press` still redirects to `//astro.build/press`.\n\n### Proof of Concept\n\n1. Create a new minimal Astro project (`astro@5.12.8`)\n2. Configure it to use the Node adapter (`@astrojs/node@9.4.0`) and force trailing slashes:\n   ```js\n   // astro.config.mjs\n   import { defineConfig } from \u0027astro/config\u0027;\n   import node from \u0027@astrojs/node\u0027;\n   \n   export default defineConfig({\n     trailingSlash: \u0027always\u0027,\n     adapter: node({ mode: \u0027standalone\u0027 }),\n   });\n   ```\n3. Build the site by running `astro build`.\n4. Run the server, e.g. with `astro preview`.\n5. Append `//astro.build/press` to the preview URL, e.g. \u003chttp://localhost:4321//astro.build/press\u003e\n6. The site will redirect to the external Astro Build origin.\n\n#### Example reproduction\n\n1. Open [this StackBlitz reproduction](https://stackblitz.com/edit/github-4fvpfhcz-nyfj2mbf).\n2. Open the preview in a separate window so the StackBlitz embed doesn\u0027t cause security errors.\n3. Append `//astro.build/press` to the preview URL, e.g. `https://x.local-corp.webcontainer.io//astro.build/press`.\n4. See it redirect to the external Astro Build origin.\n\n### Impact\n\nThis is classified as an Open Redirection vulnerability (CWE-601). It affects any user who clicks on a specially crafted link pointing to the affected domain. Since the domain appears legitimate, victims may be tricked into trusting the redirected page, leading to possible credential theft, malware distribution, or other phishing-related attacks.\n\nNo authentication is required to exploit this vulnerability. Any unauthenticated user can trigger the redirect by clicking a malicious link.",
  "id": "GHSA-9x9c-ghc5-jhw9",
  "modified": "2025-08-15T20:55:55Z",
  "published": "2025-08-15T16:52:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-9x9c-ghc5-jhw9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/5fc3c599cacb0172cc7d8e1202a5f2e8685d7ef2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@astrojs/node\u0027s trailing slash handling causes open redirect issue"
}

GHSA-C2FV-V358-GGC4

Vulnerability from github – Published: 2025-11-11 03:30 – Updated: 2025-11-11 03:30
VLAI
Details

SAP S/4HANA landscape SAP E-Recruiting BSP allows an unauthenticated attacker to craft malicious links, when clicked the victim could be redirected to the page controlled by the attacker. This has low impact on confidentiality and integrity of the application with no impact on availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-42924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T01:15:39Z",
    "severity": "MODERATE"
  },
  "details": "SAP S/4HANA landscape SAP E-Recruiting BSP allows an unauthenticated attacker to craft malicious links, when clicked the victim could be redirected to the page controlled by the attacker. This has low impact on confidentiality and integrity of the application with no impact on availability.",
  "id": "GHSA-c2fv-v358-ggc4",
  "modified": "2025-11-11T03:30:29Z",
  "published": "2025-11-11T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42924"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3642398"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2W9-HHFQ-2XQ9

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:38
VLAI
Details

Mattermost Desktop App fails to validate a mattermost server redirection and navigates to an arbitrary website

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2000"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-02T09:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost Desktop App fails to validate a mattermost server redirection and navigates\u00a0to an arbitrary website\n",
  "id": "GHSA-c2w9-hhfq-2xq9",
  "modified": "2024-04-04T05:38:33Z",
  "published": "2023-07-06T19:24:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2000"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Use a list of approved URLs or domains to be used for redirection.
Mitigation
Architecture and Design

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Mitigation MIT-21.2
Architecture and Design

Strategy: Enforcement by Conversion

  • When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation
Architecture and Design

Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).

Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.
Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CAPEC-178: Cross-Site Flashing

An attacker is able to trick the victim into executing a Flash document that passes commands or calls to a Flash player browser plugin, allowing the attacker to exploit native Flash functionality in the client browser. This attack pattern occurs where an attacker can provide a crafted link to a Flash document (SWF file) which, when followed, will cause additional malicious instructions to be executed. The attacker does not need to serve or control the Flash document. The attack takes advantage of the fact that Flash files can reference external URLs. If variables that serve as URLs that the Flash application references can be controlled through parameters, then by creating a link that includes values for those parameters, an attacker can cause arbitrary content to be referenced and possibly executed by the targeted Flash application.