Common Weakness Enumeration

CWE-601

Allowed

URL Redirection to Untrusted Site ('Open Redirect')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

2561 vulnerabilities reference this CWE, most recent first.

GHSA-VPMF-FP9G-FW23

Vulnerability from github – Published: 2023-12-19 21:32 – Updated: 2026-04-28 21:33
VLAI
Details

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in CRM Perks Integration for WooCommerce and QuickBooks.This issue affects Integration for WooCommerce and QuickBooks: from n/a through 1.2.3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-38478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-19T20:15:07Z",
    "severity": "MODERATE"
  },
  "details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in CRM Perks Integration for WooCommerce and QuickBooks.This issue affects Integration for WooCommerce and QuickBooks: from n/a through 1.2.3.",
  "id": "GHSA-vpmf-fp9g-fw23",
  "modified": "2026-04-28T21:33:26Z",
  "published": "2023-12-19T21:32:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38478"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wp-woocommerce-quickbooks/wordpress-integration-for-woocommerce-and-quickbooks-plugin-1-2-3-open-redirection-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPV7-5WP2-C8XX

Vulnerability from github – Published: 2026-09-04 15:36 – Updated: 2026-09-04 15:36
VLAI
Details

Dub contains an open redirect vulnerability in the redir_url query parameter that is accepted on every short link without validation or domain allowlist enforcement. Attackers can append the redir_url parameter to any short link to redirect visitors to arbitrary external URLs through the trusted Dub domain, bypassing destination blacklists and potentially enabling phishing attacks with link cloaking enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-85676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T15:17:45Z",
    "severity": "MODERATE"
  },
  "details": "Dub contains an open redirect vulnerability in the redir_url query parameter that is accepted on every short link without validation or domain allowlist enforcement. Attackers can append the redir_url parameter to any short link to redirect visitors to arbitrary external URLs through the trusted Dub domain, bypassing destination blacklists and potentially enabling phishing attacks with link cloaking enabled.",
  "id": "GHSA-vpv7-5wp2-c8xx",
  "modified": "2026-09-04T15:36:15Z",
  "published": "2026-09-04T15:36:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85676"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dubinc/dub/issues/4337"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dubinc/dub"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dubinc/dub/blob/73415cf5e6be13ce9adb7ba5e97474307db34a17/apps/web/lib/middleware/utils/get-final-url.ts"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/dub-open-redirect-via-unrestricted-redir-url-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VPXM-CR3R-PJP9

Vulnerability from github – Published: 2025-01-30 17:50 – Updated: 2025-01-30 17:50
VLAI
Summary
General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches
Details

Impact

We recently underwent Penetration Testing of OpenMRS by a third-party company. Vulnerabilities were found, and fixes have been made and released. We've released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.

This notice applies to all OpenMRS instances. The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp.

Vulnerability Details

  • The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).
  • No vulnerabilities were found in the O3 frontend esm modules.
  • The Letter of Attestation from the penetration test is available here for your reference.
  • After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of “Excellent, Grade A”.
  • The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.

Patches

Minimum Requirements for Implementers: We strongly recommend upgrading your modules to the following versions (or greater) as soon as possible. This is the minimum amount to do and be protected from the vulnerabilities found and fixed. The following versions contain the patch:

  • Platform 2.6.11+
  • How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.
  • Notes:
    • The newly released Platform 2.7 also includes the fixes. Release Notes and more download options here.
    • Platform 2.6.8+ has most of the fixes, but these are broken if you don't use SSL, so Platform 2.6.11 or higher is preferred.
    • For those still on Platform 2.5+ such as the Bahmni ecosystem, the new 2.5.14 release includes the patch. Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes.
  • Legacy UI OMOD 1.21.0+ (here)
  • ID Gen OMOD 4.14.0+ (here)
  • Address Hierarchy OMOD 2.19.0+ (here)
  • Attachments OMOD 3.6.0+ (here)
  • Patient Flags OMOD 3.0.8+ (here)

Workarounds

There are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system's functionality.

Thank you to our amazing Security contributors!

Thank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs:openmrs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:legacyui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:idgen"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:addresshierarchy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:attachments"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:patientflags"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-284",
      "CWE-601",
      "CWE-614"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-30T17:50:52Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nWe recently underwent Penetration Testing of OpenMRS by a third-party company. **Vulnerabilities were found, and fixes have been made and released.** We\u0027ve released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.\n\n**This notice applies to _all_ OpenMRS instances.** The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp. \n\n## Vulnerability Details\n- The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).\n- No vulnerabilities were found in the O3 frontend esm modules. \n- The Letter of Attestation from the penetration test is [available here](https://drive.google.com/file/d/1sBm4-FzLA8hSoM9wYknBfgEttBHyLvoU/view?usp=sharing) for your reference. \n- After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of \u201cExcellent, Grade A\u201d.\n- The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.\n\n### Patches\n**Minimum Requirements for Implementers:** We **strongly** recommend upgrading your modules to the following versions (or greater) as soon as possible. **This is the minimum amount to do and be protected from the vulnerabilities found and fixed.** The following versions contain the patch: \n\n- **Platform** 2.6.11+ \n  - How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.\n  - Notes: \n    - The newly released [**Platform 2.7**](https://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_2.7.0/) also includes the fixes. [Release Notes and more download options here](https://openmrs.atlassian.net/wiki/x/XoBzEQ).\n    - Platform 2.6.8+ has most of the fixes, but these are broken if you don\u0027t use SSL, so Platform 2.6.11 or higher is preferred.\n    - For those still on Platform 2.5+ such as the Bahmni ecosystem, the new [2.5.14](https://ci.openmrs.org/browse/TRUNK-CORE2-232) release includes the patch. _Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes._\n- **Legacy UI** OMOD 1.21.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.legacyui))\n- **ID Gen** OMOD 4.14.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.idgen))\n- **Address Hierarchy** OMOD 2.19.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.addresshierarchy))\n- **Attachments** OMOD 3.6.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.attachments))\n- **Patient Flags** OMOD 3.0.8+ ([here](https://addons.openmrs.org/show/org.openmrs.module.patientflags))\n\n### Workarounds\nThere are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system\u0027s functionality.\n\n## Thank you to our amazing Security contributors!\nThank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton. \n",
  "id": "GHSA-vpxm-cr3r-pjp9",
  "modified": "2025-01-30T17:50:52Z",
  "published": "2025-01-30T17:50:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-vpxm-cr3r-pjp9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openmrs/openmrs-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches"
}

GHSA-VQ7F-4CC7-HX6Q

Vulnerability from github – Published: 2023-12-29 15:30 – Updated: 2026-04-28 21:33
VLAI
Details

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in CodePeople Calculated Fields Form.This issue affects Calculated Fields Form: from n/a through 1.2.28.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-51517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-29T15:15:10Z",
    "severity": "MODERATE"
  },
  "details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in CodePeople Calculated Fields Form.This issue affects Calculated Fields Form: from n/a through 1.2.28.",
  "id": "GHSA-vq7f-4cc7-hx6q",
  "modified": "2026-04-28T21:33:40Z",
  "published": "2023-12-29T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51517"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/calculated-fields-form/wordpress-calculated-fields-form-plugin-1-2-28-open-redirection-via-shortcode-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQP6-J452-J6WP

Vulnerability from github – Published: 2022-03-04 00:00 – Updated: 2022-03-11 22:27
VLAI
Summary
Open Redirect in CPython that affects users of OpenStack Nova
Details

A vulnerability was found in CPython which is used by openstack-nova's console proxy, noVNC. By crafting a malicious URL, noVNC could be made to redirect to any desired URL.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3654"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-11T22:27:18Z",
    "nvd_published_at": "2022-03-02T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in CPython which is used by openstack-nova\u0027s console proxy, noVNC. By crafting a malicious URL, noVNC could be made to redirect to any desired URL.",
  "id": "GHSA-vqp6-j452-j6wp",
  "modified": "2022-03-11T22:27:18Z",
  "published": "2022-03-04T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3654"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/nova/+bug/1927677"
    },
    {
      "type": "WEB",
      "url": "https://bugs.python.org/issue32084"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1961439"
    },
    {
      "type": "PACKAGE",
      "url": "https://opendev.org/openstack/nova"
    },
    {
      "type": "WEB",
      "url": "https://opendev.org/openstack/nova/commit/04d48527b62a35d912f93bc75613a6cca606df66"
    },
    {
      "type": "WEB",
      "url": "https://opendev.org/openstack/nova/commit/8906552cfc2525a44251d4cf313ece61e57251eb"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-02"
    },
    {
      "type": "WEB",
      "url": "https://security.openstack.org/ossa/OSSA-2021-002.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2021/07/29/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"
    }
  ],
  "summary": "Open Redirect in CPython that affects users of OpenStack Nova"
}

GHSA-VQV8-J3MJ-WJXJ

Vulnerability from github – Published: 2026-05-06 19:50 – Updated: 2026-05-06 19:50
VLAI
Summary
wger: trainer_login open redirect - ?next= parameter not validated against host
Details

Summary

The trainer_login view in wger redirects to request.GET['next'] directly via HttpResponseRedirect() without calling url_has_allowed_host_and_scheme(). After the trainer successfully enters impersonation mode, their browser is redirected to any attacker-controlled URL supplied in the ?next= parameter, enabling Referer exfiltration and phishing.

Details

File: wger/core/views/user.py, approximately line 203

# VULNERABLE - wger/core/views/user.py
if not own:
    request.session['trainer.identity'] = orig_user_pk
    if request.GET.get('next'):
        return HttpResponseRedirect(request.GET['next'])   # no host/scheme validation

After the impersonation logic succeeds, the view performs no validation of the next parameter before issuing the redirect. An attacker who can deliver a crafted link (e.g. /en/user/2/trainer-login?next=https://evil.example/steal) to a trainer can redirect the trainer's browser to any external host immediately after the impersonation session is established. The Location header contains the raw attacker-controlled URL.

Affected endpoint: - GET /en/user/<user_pk>/trainer-login -> wger.core.views.user.trainer_login (the ?next= redirect branch)

Suggested patch:

--- a/wger/core/views/user.py
+++ b/wger/core/views/user.py
+from django.utils.http import url_has_allowed_host_and_scheme
+
 if not own:
     request.session['trainer.identity'] = orig_user_pk
-    if request.GET.get('next'):
-        return HttpResponseRedirect(request.GET['next'])
+    next_url = request.GET.get('next')
+    if next_url and url_has_allowed_host_and_scheme(
+        next_url, allowed_hosts={request.get_host()}, require_https=request.is_secure()
+    ):
+        return HttpResponseRedirect(next_url)
     return HttpResponseRedirect(reverse('core:index'))

Adding @require_POST to trainer_login (see also VULN-030) moves the next parameter to the POST body where CSRF protection applies and eliminates the combined CSRF + open-redirect attack surface entirely.

PoC

Tested on wger/server:latest Docker image. Victim: trainer1 (gym.gym_trainer permission).

Step 1 - Authenticate as trainer:

POST /en/user/login HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded

username=trainer1&password=[REDACTED]&csrfmiddlewaretoken=[REDACTED]

-> 302 Found; Set-Cookie: sessionid=[trainer1_session]

Step 2 - Trainer clicks (or is delivered) the crafted link:

GET /en/user/2/trainer-login?next=https://evil.example/steal HTTP/1.1
Host: target
Cookie: sessionid=[trainer1_session]

-> 302 Found
   Location: https://evil.example/steal

Step 3 - Attacker server logs Referer:

Referer: http://target/en/user/2/trainer-login?next=https://evil.example/steal
(victim user_pk and next URL exposed)

Reproducibility: 2/2 runs.

Impact

An attacker who can deliver a crafted URL to a trainer (phishing email, malicious gym management system integration, social engineering) can redirect the trainer's browser to an attacker-controlled domain after the trainer enters impersonation mode. The redirect leaks:

  • The wger URL structure (including the impersonated user's user_pk) via the browser Referer header.
  • The session-rebound cookie (if the attacker page subsequently triggers an authenticated request with credentials: 'include' targeting wger, any same-site cookie without SameSite=Strict is attached).

Combined with the trainer-login scope bypass (submitted separately), this primitive allows an attacker to silently impersonate arbitrary gym=None users and then land the trainer on an attacker page for credential harvesting.

Affected deployments: every wger instance where gym.gym_trainer is delegated to non-admin users.

Severity: Medium (CVSS 5.4). Network-reachable, low complexity, low privilege (trainer role), requires victim interaction (click), scope change (attacker's origin).

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T19:50:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `trainer_login` view in wger redirects to `request.GET[\u0027next\u0027]` directly via `HttpResponseRedirect()` without calling `url_has_allowed_host_and_scheme()`. After the trainer successfully enters impersonation mode, their browser is redirected to any attacker-controlled URL supplied in the `?next=` parameter, enabling Referer exfiltration and phishing.\n\n### Details\n\n**File**: `wger/core/views/user.py`, approximately line 203\n\n```python\n# VULNERABLE - wger/core/views/user.py\nif not own:\n    request.session[\u0027trainer.identity\u0027] = orig_user_pk\n    if request.GET.get(\u0027next\u0027):\n        return HttpResponseRedirect(request.GET[\u0027next\u0027])   # no host/scheme validation\n```\n\nAfter the impersonation logic succeeds, the view performs no validation of the `next` parameter before issuing the redirect. An attacker who can deliver a crafted link (e.g. `/en/user/2/trainer-login?next=https://evil.example/steal`) to a trainer can redirect the trainer\u0027s browser to any external host immediately after the impersonation session is established. The `Location` header contains the raw attacker-controlled URL.\n\n**Affected endpoint**:\n- `GET /en/user/\u003cuser_pk\u003e/trainer-login` -\u003e `wger.core.views.user.trainer_login` (the `?next=` redirect branch)\n\n**Suggested patch**:\n\n```diff\n--- a/wger/core/views/user.py\n+++ b/wger/core/views/user.py\n+from django.utils.http import url_has_allowed_host_and_scheme\n+\n if not own:\n     request.session[\u0027trainer.identity\u0027] = orig_user_pk\n-    if request.GET.get(\u0027next\u0027):\n-        return HttpResponseRedirect(request.GET[\u0027next\u0027])\n+    next_url = request.GET.get(\u0027next\u0027)\n+    if next_url and url_has_allowed_host_and_scheme(\n+        next_url, allowed_hosts={request.get_host()}, require_https=request.is_secure()\n+    ):\n+        return HttpResponseRedirect(next_url)\n     return HttpResponseRedirect(reverse(\u0027core:index\u0027))\n```\n\nAdding `@require_POST` to `trainer_login` (see also VULN-030) moves the `next` parameter to the POST body where CSRF protection applies and eliminates the combined CSRF + open-redirect attack surface entirely.\n\n### PoC\n\nTested on `wger/server:latest` Docker image. Victim: `trainer1` (`gym.gym_trainer` permission).\n\nStep 1 - Authenticate as trainer:\n\n```\nPOST /en/user/login HTTP/1.1\nHost: target\nContent-Type: application/x-www-form-urlencoded\n\nusername=trainer1\u0026password=[REDACTED]\u0026csrfmiddlewaretoken=[REDACTED]\n\n-\u003e 302 Found; Set-Cookie: sessionid=[trainer1_session]\n```\n\nStep 2 - Trainer clicks (or is delivered) the crafted link:\n\n```\nGET /en/user/2/trainer-login?next=https://evil.example/steal HTTP/1.1\nHost: target\nCookie: sessionid=[trainer1_session]\n\n-\u003e 302 Found\n   Location: https://evil.example/steal\n```\n\nStep 3 - Attacker server logs Referer:\n\n```\nReferer: http://target/en/user/2/trainer-login?next=https://evil.example/steal\n(victim user_pk and next URL exposed)\n```\n\nReproducibility: 2/2 runs.\n\n### Impact\n\nAn attacker who can deliver a crafted URL to a trainer (phishing email, malicious gym management system integration, social engineering) can redirect the trainer\u0027s browser to an attacker-controlled domain after the trainer enters impersonation mode. The redirect leaks:\n\n- The wger URL structure (including the impersonated user\u0027s `user_pk`) via the browser `Referer` header.\n- The session-rebound cookie (if the attacker page subsequently triggers an authenticated request with `credentials: \u0027include\u0027` targeting wger, any same-site cookie without SameSite=Strict is attached).\n\nCombined with the trainer-login scope bypass (submitted separately), this primitive allows an attacker to silently impersonate arbitrary `gym=None` users and then land the trainer on an attacker page for credential harvesting.\n\n**Affected deployments**: every wger instance where `gym.gym_trainer` is delegated to non-admin users.\n\n**Severity**: Medium (CVSS 5.4). Network-reachable, low complexity, low privilege (trainer role), requires victim interaction (click), scope change (attacker\u0027s origin).",
  "id": "GHSA-vqv8-j3mj-wjxj",
  "modified": "2026-05-06T19:50:52Z",
  "published": "2026-05-06T19:50:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-vqv8-j3mj-wjxj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    }
  ],
  "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"
    }
  ],
  "summary": "wger: trainer_login open redirect - ?next= parameter not validated against host"
}

GHSA-VR3H-J7MQ-24MM

Vulnerability from github – Published: 2026-07-20 21:31 – Updated: 2026-07-21 21:32
VLAI
Details

The Joomla extension Hikashop is vulnerable to an open redirect.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-61901"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T19:17:28Z",
    "severity": "MODERATE"
  },
  "details": "The Joomla extension Hikashop is vulnerable to an open redirect.",
  "id": "GHSA-vr3h-j7mq-24mm",
  "modified": "2026-07-21T21:32:23Z",
  "published": "2026-07-20T21:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61901"
    },
    {
      "type": "WEB",
      "url": "https://www.hikashop.com"
    }
  ],
  "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-VRG4-HQCW-HJVG

Vulnerability from github – Published: 2025-04-24 18:31 – Updated: 2026-04-01 18:34
VLAI
Details

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Heateor Support Sassy Social Share allows Phishing. This issue affects Sassy Social Share: from n/a through 3.3.73.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-39404"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-24T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "URL Redirection to Untrusted Site (\u0027Open Redirect\u0027) vulnerability in Heateor Support Sassy Social Share allows Phishing. This issue affects Sassy Social Share: from n/a through 3.3.73.",
  "id": "GHSA-vrg4-hqcw-hjvg",
  "modified": "2026-04-01T18:34:55Z",
  "published": "2025-04-24T18:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39404"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/sassy-social-share/vulnerability/wordpress-sassy-social-share-plugin-3-3-73-open-redirection-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRM9-X4WW-QPGW

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02
VLAI
Details

When subscribing using AcyMailing, the 'redirect' parameter isn't properly sanitized. Turning the request from POST to GET, an attacker can craft a link containing a potentially malicious landing page and send it to the victim.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-24288"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-17T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "When subscribing using AcyMailing, the \u0027redirect\u0027 parameter isn\u0027t properly sanitized. Turning the request from POST to GET, an attacker can craft a link containing a potentially malicious landing page and send it to the victim.",
  "id": "GHSA-vrm9-x4ww-qpgw",
  "modified": "2022-05-24T19:02:37Z",
  "published": "2022-05-24T19:02:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24288"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/56628862-1687-4862-9ed4-145d8dfbca97"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VRW8-FXC6-2R93

Vulnerability from github – Published: 2025-06-20 16:37 – Updated: 2025-10-13 15:41
VLAI
Summary
chi Allows Host Header Injection which Leads to Open Redirect in RedirectSlashes
Details

Summary

The RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect.

We consider this a lower-severity open redirect, as it can't be exploited from browsers or email clients (requires manipulation of a Host header).

Details

The RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/master/middleware/strip.go#L55

The Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware

PoC

Create a simple server which uses the RedirectSlashes middleware

package main

import (
    "fmt"
    "net/http"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware" // Import the middleware package
)

func main() {
    // Create a new Chi router
    r := chi.NewRouter()

    // Use the built-in RedirectSlashes middleware
    r.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes

    // Define a route handler
    r.Get("/", func(w http.ResponseWriter, r *http.Request) {
        // A simple response
        w.Write([]byte("Hello, World!"))
    })

    // Start the server
    fmt.Println("Starting server on :8080")
    http.ListenAndServe(":8080", r)
}

Run the server go run main.go

Once the server is running, send a request that will trigger the RedirectSlashes function with an arbitrary Host header curl -iL -H "Host: example.com" http://localhost:8080/test/

Observe that the request will be redirected to example.com

curl -L -H "Host: example.com" http://localhost:8080/test/

<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
... snipped ...

Without the host header, the response is returned from the test server

curl -L http://localhost:8080/test/

404 page not found

Impact

An open redirect vulnerability allows attackers to trick users into visiting malicious sites. This can lead to phishing attacks, credential theft, and malware distribution, as users trust the application’s domain while being redirected to harmful sites.

Potential mitigation

It seems that the purpose of the RedirectSlashes function is to redirect within the same application. In that case r.RequestURI can be used instead of r.Host by default. If there is a use case to redirect to a different host, a flag can be added to use the Host header instead. As this flag will be controlled by the developer they will make the decision of allowing redirects to arbitrary hosts based on their judgement.

Severity
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.2.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-chi/chi/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-20T16:37:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect.\n\nWe consider this a **lower-severity** open redirect, as it can\u0027t be exploited from browsers or email clients (requires manipulation of a Host header).\n\n### Details\nThe RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/master/middleware/strip.go#L55\n\nThe Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware\n\n### PoC\nCreate a simple server which uses the RedirectSlashes middleware\n```\npackage main\n\nimport (\n\t\"fmt\"\n\t\"net/http\"\n\n\t\"github.com/go-chi/chi/v5\"\n\t\"github.com/go-chi/chi/v5/middleware\" // Import the middleware package\n)\n\nfunc main() {\n\t// Create a new Chi router\n\tr := chi.NewRouter()\n\n\t// Use the built-in RedirectSlashes middleware\n\tr.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes\n\n\t// Define a route handler\n\tr.Get(\"/\", func(w http.ResponseWriter, r *http.Request) {\n\t\t// A simple response\n\t\tw.Write([]byte(\"Hello, World!\"))\n\t})\n\n\t// Start the server\n\tfmt.Println(\"Starting server on :8080\")\n\thttp.ListenAndServe(\":8080\", r)\n}\n```\nRun the server `go run main.go`\n\nOnce the server is running, send a request that will trigger the RedirectSlashes function with an arbitrary Host header\n`curl -iL -H \"Host: example.com\" http://localhost:8080/test/`\n\nObserve that the request will be redirected to example.com\n\n```\ncurl -L -H \"Host: example.com\" http://localhost:8080/test/\n\n\u003c!doctype html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n    \u003ctitle\u003eExample Domain\u003c/title\u003e\n\n    \u003cmeta charset=\"utf-8\" /\u003e\n    \u003cmeta http-equiv=\"Content-type\" content=\"text/html; charset=utf-8\" /\u003e\n    \u003cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1\" /\u003e\n    \u003cstyle type=\"text/css\"\u003e\n    body {\n        background-color: #f0f0f2;\n        margin: 0;\n        padding: 0;\n        font-family: -apple-system, system-ui, BlinkMacSystemFont, \"Segoe UI\", \"Open Sans\", \"Helvetica Neue\", Helvetica, Arial, sans-serif;\n... snipped ...\n```\nWithout the host header, the response is returned from the test server\n```\ncurl -L http://localhost:8080/test/\n\n404 page not found\n```\n\n### Impact\nAn open redirect vulnerability allows attackers to trick users into visiting malicious sites. This can lead to phishing attacks, credential theft, and malware distribution, as users trust the application\u2019s domain while being redirected to harmful sites.\n\n### Potential mitigation\nIt seems that the purpose of the RedirectSlashes function is to redirect within the same application. In that case r.RequestURI can be used instead of r.Host by default. If there is a use case to redirect to a different host, a flag can be added to use the Host header instead. As this flag will be controlled by the developer they will make the decision of allowing redirects to arbitrary hosts  based on their judgement.",
  "id": "GHSA-vrw8-fxc6-2r93",
  "modified": "2025-10-13T15:41:17Z",
  "published": "2025-06-20T16:37:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-chi/chi/security/advisories/GHSA-vrw8-fxc6-2r93"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-chi/chi/commit/1be7ad938cc9c5b39a9dea01a5c518848928ab65"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-chi/chi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "chi Allows Host Header Injection which Leads to Open Redirect in RedirectSlashes"
}
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.

← Back to the CWE list