Common Weakness Enumeration

CWE-647

Allowed

Use of Non-Canonical URL Paths for Authorization Decisions

Abstraction: Variant · Status: Incomplete

The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.

18 vulnerabilities reference this CWE, most recent first.

GHSA-2FX4-VWF2-PW99

Vulnerability from github – Published: 2026-02-27 09:30 – Updated: 2026-02-27 09:30
VLAI
Details

A flaw was found in the Red Hat Ansible Automation Platform Gateway route creation component. This vulnerability allows credential theft via the creation of misleading routes using a double-slash (//) prefix in the gateway_path. A malicious or socially engineered administrator can configure a honey-pot route to intercept and exfiltrate user credentials, potentially maintaining persistent access or creating a backdoor even after their permissions are revoked.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-27T08:17:08Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Red Hat Ansible Automation Platform Gateway route creation component. This vulnerability allows credential theft via the creation of misleading routes using a double-slash (//) prefix in the gateway_path. A malicious or socially engineered administrator can configure a honey-pot route to intercept and exfiltrate user credentials, potentially maintaining persistent access or creating a backdoor even after their permissions are revoked.",
  "id": "GHSA-2fx4-vwf2-pw99",
  "modified": "2026-02-27T09:30:29Z",
  "published": "2026-02-27T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9909"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21768"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21775"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23069"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23131"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-9909"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2392836"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3RG7-WF37-54RM

Vulnerability from github – Published: 2025-11-12 21:50 – Updated: 2025-11-15 03:13
VLAI
Summary
Symfony's incorrect parsing of PATH_INFO can lead to limited authorization bypass
Details

Description

The Request class improperly interprets some PATH_INFO in a way that leads to representing some URLs with a path that doesn't start with a /. This can allow bypassing some access control rules that are built with this /-prefix assumption.

Resolution

The Request class now ensures that URL paths always start with a /.

The patch for this issue is available here for branch 5.4.

Credits

We would like to thank Andrew Atkinson for discovering the issue, Chris Smith for reporting it and Nicolas Grekas for providing the fix.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/http-foundation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "5.4.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-12T21:50:37Z",
    "nvd_published_at": "2025-11-12T22:15:50Z",
    "severity": "HIGH"
  },
  "details": "### Description\n\nThe `Request` class improperly interprets some `PATH_INFO` in a way that leads to representing some URLs with a path that doesn\u0027t start with a `/`. This can allow bypassing some access control rules that are built with this `/`-prefix assumption.\n\n### Resolution\n\nThe `Request` class now ensures that URL paths always start with a `/`.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/9962b91b12bb791322fa73836b350836b6db7cac) for branch 5.4.\n\n### Credits\n\nWe would like to thank Andrew Atkinson for discovering the issue, Chris Smith for reporting it and Nicolas Grekas for providing the fix.",
  "id": "GHSA-3rg7-wf37-54rm",
  "modified": "2025-11-15T03:13:30Z",
  "published": "2025-11-12T21:50:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-3rg7-wf37-54rm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/9962b91b12bb791322fa73836b350836b6db7cac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/http-foundation/CVE-2025-64500.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2025-64500.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/blog/cve-2025-64500-incorrect-parsing-of-path-info-can-lead-to-limited-authorization-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Symfony\u0027s incorrect parsing of PATH_INFO can lead to limited authorization bypass"
}

GHSA-F54F-HR32-586F

Vulnerability from github – Published: 2025-05-03 21:30 – Updated: 2025-05-05 18:24
VLAI
Summary
Duplicate Advisory: `allowed_domains` can be bypassed by putting a decoy domain in http auth username portion of a URL
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-x39x-9qw5-ghrf. This link is maintained to preserve external references.

Original Description

In browser-use (aka Browser Use) before 0.1.45, URL parsing of allowed_domains is mishandled because userinfo can be placed in the authority component.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.44"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "browser-use"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-05T18:24:47Z",
    "nvd_published_at": "2025-05-03T21:15:48Z",
    "severity": "CRITICAL"
  },
  "details": "# Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-x39x-9qw5-ghrf. This link is maintained to preserve external references.\n\n# Original Description\nIn browser-use (aka Browser Use) before 0.1.45, URL parsing of allowed_domains is mishandled because userinfo can be placed in the authority component.",
  "id": "GHSA-f54f-hr32-586f",
  "modified": "2025-05-05T18:24:47Z",
  "published": "2025-05-03T21:30:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/security/advisories/GHSA-x39x-9qw5-ghrf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/pull/1561"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/browser-use/browser-use"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/releases/tag/0.1.45"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: `allowed_domains` can be bypassed by putting a decoy domain in http auth username portion of a URL",
  "withdrawn": "2025-05-05T18:24:47Z"
}

GHSA-G2WH-GMWQ-2GMC

Vulnerability from github – Published: 2025-04-21 15:31 – Updated: 2025-04-21 15:31
VLAI
Details

Sonos api.sonos.com through 2025-04-21, when the /login/v3/oauth endpoint is used, accepts a redirect_uri containing userinfo in the authority component, which is not consistent with RFC 6819 section 5.2.3.5. An authorization code may be sent to an attacker-controlled destination. This might have further implications in conjunction with "Decompiling the app revealed a hardcoded secret."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-43916"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-21T14:15:36Z",
    "severity": "LOW"
  },
  "details": "Sonos api.sonos.com through 2025-04-21, when the /login/v3/oauth endpoint is used, accepts a redirect_uri containing userinfo in the authority component, which is not consistent with RFC 6819 section 5.2.3.5. An authorization code may be sent to an attacker-controlled destination. This might have further implications in conjunction with \"Decompiling the app revealed a hardcoded secret.\"",
  "id": "GHSA-g2wh-gmwq-2gmc",
  "modified": "2025-04-21T15:31:24Z",
  "published": "2025-04-21T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43916"
    },
    {
      "type": "WEB",
      "url": "https://github.com/larlarua/vulnerability-reports/blob/main/CVE-2025-43916/detail.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P688-R7JV-FM6F

Vulnerability from github – Published: 2026-06-26 21:47 – Updated: 2026-06-26 21:47
VLAI
Summary
Cargo can be coerced to share credentials between registries
Details

The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the sparse index protocol. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.

This vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is low, due to the extremely niche requirements needed to achieve the attack.

Overview

Originally Cargo only supported storing a registry's index within git repositories. Most git hosting solutions allow accessing a git repository with or without the .git suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for https://example.com/index to be used for https://example.com/index.git.

This normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with .git as different URLs than those without the suffix.

If the following conditions apply:

  • https://example.com/index is a sparse index.
  • https://example.com/index allows crates to depend on crates from any other registry.
  • The attacker is able to publish crates on https://example.com/index.
  • The attacker is able to upload arbitrary files to https://example.com/index.git.

...the attacker could configure https://example.com/index.git to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.

When the attacker then publishes a crate foo to https://example.com/index depending on a crate bar from https://example.com/index.git, and tricks the victim into downloading foo, Cargo will think the two registries share the same credential and send the victim's Cargo token to the malicious registry.

Mitigations

Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the .git suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.

Affected versions

All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.

Acknowledgements

Cargo would like to thank Christos Papakonstantinou for reporting this issue according to the Rust security policy.

Cargo also wants to thank the members of the Rust project who helped address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "cargo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.97.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-5222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:47:54Z",
    "nvd_published_at": "2026-05-25T10:16:15Z",
    "severity": "LOW"
  },
  "details": "The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the [sparse index protocol][1]. If a hosting provider allowed multiple registries to be hosted with arbitrary names within the same domain, an attacker able to publish crates in a registry could obtain the credentials of others users of the same registry.\n\nThis vulnerability is tracked as CVE-2026-5222. The severity of the vulnerability is **low**, due to the extremely niche requirements needed to achieve the attack.\n\n## Overview\n\nOriginally Cargo only supported storing a registry\u0027s index within git repositories. Most git hosting solutions allow accessing a git repository with or without the `.git` suffix, so Cargo mirrored this behavior when normalizing registry URLs. This allowed credentials for `https://example.com/index` to be used for `https://example.com/index.git`.\n\nThis normalization was unintentionally applied to the new sparse indexes too. Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with `.git` as different URLs than those without the suffix.\n\nIf the following conditions apply:\n\n* `https://example.com/index` is a sparse index.\n* `https://example.com/index` allows crates to depend on crates from any other registry.\n* The attacker is able to publish crates on `https://example.com/index`.\n* The attacker is able to upload arbitrary files to `https://example.com/index.git`.\n\n...the attacker could configure `https://example.com/index.git` to be a Cargo sparse registry requiring authentication for downloads, and with a download URL pointing to a server recording any credentials set to it.\n\nWhen the attacker then publishes a crate `foo` to `https://example.com/index` depending on a crate `bar` from `https://example.com/index.git`, and tricks the victim into downloading `foo`,  Cargo will think the two registries share the same credential and send the victim\u0027s Cargo token to the malicious registry.\n\n## Mitigations\n\nRust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the `.git` suffix from registry URLs using the git protocol. No mitigations are available for users of older versions of Cargo.\n\n## Affected versions\n\nAll versions of Cargo shipped between Rust 1.68 (the stabilization of sparse registries) and 1.96 are affected.\n\n## Acknowledgements\n\nCargo would like to thank Christos Papakonstantinou for reporting this issue according to the [Rust security policy][2].\n\nCargo also wants to thank the members of the Rust project who helped address the vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and Emily Albini for reviewing the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.\n\n[1]: https://doc.rust-lang.org/cargo/reference/registries.html#registry-protocols\n[2]: https://rust-lang.org/policies/security",
  "id": "GHSA-p688-r7jv-fm6f",
  "modified": "2026-06-26T21:47:54Z",
  "published": "2026-06-26T21:47:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rust-lang/cargo/security/advisories/GHSA-p688-r7jv-fm6f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5222"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rust-lang/cargo/pull/17031"
    },
    {
      "type": "WEB",
      "url": "https://blog.rust-lang.org/2026/05/25/cve-2026-5222"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rust-lang/cargo"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/rustlang-security-announcements/c/SfUxOiIdY5s"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Cargo can be coerced to share credentials between registries"
}

GHSA-R7CQ-76XJ-2G24

Vulnerability from github – Published: 2023-04-03 21:32 – Updated: 2025-10-22 00:32
VLAI
Details

Hitachi Vantara Pentaho Business Analytics Server versions before 9.4.0.1 and 9.3.0.2, including 8.3.x contain security restrictions using non-canonical URLs which can be circumvented.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-43939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-03T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Hitachi Vantara Pentaho Business Analytics Server versions before 9.4.0.1 and 9.3.0.2, including 8.3.x contain security restrictions using non-canonical URLs which can be circumvented.",
  "id": "GHSA-r7cq-76xj-2g24",
  "modified": "2025-10-22T00:32:43Z",
  "published": "2023-04-03T21:32:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43939"
    },
    {
      "type": "WEB",
      "url": "https://support.pentaho.com/hc/en-us/articles/14455394120333--Resolved-Pentaho-BA-Server-Use-of-Non-Canonical-URL-Paths-for-Authorization-Decisions-Versions-before-9-4-0-1-and-9-3-0-2-including-8-3-x-Impacted-CVE-2022-43939-"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-43939"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/172296/Pentaho-Business-Server-Authentication-Bypass-SSTI-Code-Execution.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WHQG-PPGF-WP8C

Vulnerability from github – Published: 2025-12-08 16:26 – Updated: 2025-12-09 16:28
VLAI
Summary
Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765
Details

Authentication Bypass via Double URL Encoding in Astro

Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794


Summary

A double URL encoding bypass allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like /%2561dmin instead of /%61dmin, attackers can still bypass authentication and access protected resources such as /admin, /api/internal, or any route protected by middleware pathname checks.

Fix

A more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :

if (containsEncodedCharacters(pathname)) {
            // Multi-level encoding detected - reject request
            return new Response(
                'Bad Request: Multi-level URL encoding is not allowed',
                {
                    status: 400,
                    headers: { 'Content-Type': 'text/plain' }
                }
            );
        }
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.15.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-08T16:26:43Z",
    "nvd_published_at": "2025-12-09T00:15:48Z",
    "severity": "MODERATE"
  },
  "details": "# Authentication Bypass via Double URL Encoding in Astro\n## Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794\n\n---\n\n### Summary\n\nA **double URL encoding bypass** allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like `/%2561dmin` instead of `/%61dmin`, attackers can still bypass authentication and access protected resources such as `/admin`, `/api/internal`, or any route protected by middleware pathname checks.\n\n\n## Fix \n\nA more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like :\n\n```\nif (containsEncodedCharacters(pathname)) {\n            // Multi-level encoding detected - reject request\n            return new Response(\n                \u0027Bad Request: Multi-level URL encoding is not allowed\u0027,\n                {\n                    status: 400,\n                    headers: { \u0027Content-Type\u0027: \u0027text/plain\u0027 }\n                }\n            );\n        }\n```",
  "id": "GHSA-whqg-ppgf-wp8c",
  "modified": "2025-12-09T16:28:41Z",
  "published": "2025-12-08T16:26:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-ggxq-hp9w-j794"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-whqg-ppgf-wp8c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64765"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66202"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/6f800813516b07bbe12c666a92937525fddb58ce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro has an Authentication Bypass via Double URL Encoding, a bypass for CVE-2025-64765"
}

GHSA-X39X-9QW5-GHRF

Vulnerability from github – Published: 2025-05-05 18:25 – Updated: 2025-05-05 18:25
VLAI
Summary
Browser Use allows bypassing `allowed_domains` by putting a decoy domain in http auth username portion of a URL
Details

Summary

During a manual source code review, ARIMLABS.AI researchers identified that the browser_use module includes an embedded whitelist functionality to restrict URLs that can be visited. This restriction is enforced during agent initialization. However, it was discovered that these measures can be bypassed, leading to severe security implications.

Details

File: browser_use/browser/context.py

The BrowserContextConfig class defines an allowed_domains list, which is intended to limit accessible domains. This list is checked in the _is_url_allowed() method before navigation:

@dataclass
class BrowserContextConfig:
    """
    [STRIPPED]
    """
    cookies_file: str | None = None
    minimum_wait_page_load_time: float = 0.5
    wait_for_network_idle_page_load_time: float = 1
    maximum_wait_page_load_time: float = 5
    wait_between_actions: float = 1

    disable_security: bool = True

    browser_window_size: BrowserContextWindowSize = field(default_factory=lambda: {'width': 1280, 'height': 1100})
    no_viewport: Optional[bool] = None

    save_recording_path: str | None = None
    save_downloads_path: str | None = None
    trace_path: str | None = None
    locale: str | None = None
    user_agent: str = (
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36'
    )

    highlight_elements: bool = True
    viewport_expansion: int = 500
    allowed_domains: list[str] | None = None
    include_dynamic_attributes: bool = True

    _force_keep_context_alive: bool = False

The _is_url_allowed() method is responsible for checking whether a given URL is permitted:

def _is_url_allowed(self, url: str) -> bool:
    """Check if a URL is allowed based on the whitelist configuration."""
    if not self.config.allowed_domains:
        return True

    try:
        from urllib.parse import urlparse

        parsed_url = urlparse(url)
        domain = parsed_url.netloc.lower()

        # Remove port number if present
        if ':' in domain:
            domain = domain.split(':')[0]

        # Check if domain matches any allowed domain pattern
        return any(
            domain == allowed_domain.lower() or domain.endswith('.' + allowed_domain.lower())
            for allowed_domain in self.config.allowed_domains
        )
    except Exception as e:
        logger.error(f'Error checking URL allowlist: {str(e)}')
        return False

The core issue stems from the line domain = domain.split(':')[0], which allows an attacker to manipulate basic authentication credentials by providing a username:password pair. By replacing the username with a whitelisted domain, the check can be bypassed, even though the actual domain remains different.

Proof of Concept (PoC)

Set allowed_domains to ['example.com'] and use the following URL:

https://example.com:pass@localhost:8080

This allows bypassing all whitelist controls and accessing restricted internal services.

Impact

  • Affected all users relying on this functionality for security.
  • Potential for unauthorized enumeration of localhost services and internal networks.
  • Ability to bypass domain whitelisting, leading to unauthorized browsing.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.44"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "browser-use"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-47241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-647"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-05T18:25:04Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary  \nDuring a manual source code review, [**ARIMLABS.AI**](https://arimlabs.ai) researchers identified that the `browser_use` module includes an embedded whitelist functionality to restrict URLs that can be visited. This restriction is enforced during agent initialization. However, it was discovered that these measures can be bypassed, leading to severe security implications.  \n\n### Details  \n**File:** `browser_use/browser/context.py`  \n\nThe `BrowserContextConfig` class defines an `allowed_domains` list, which is intended to limit accessible domains. This list is checked in the `_is_url_allowed()` method before navigation:\n\n```python\n@dataclass\nclass BrowserContextConfig:\n    \"\"\"\n    [STRIPPED]\n    \"\"\"\n    cookies_file: str | None = None\n    minimum_wait_page_load_time: float = 0.5\n    wait_for_network_idle_page_load_time: float = 1\n    maximum_wait_page_load_time: float = 5\n    wait_between_actions: float = 1\n\n    disable_security: bool = True\n\n    browser_window_size: BrowserContextWindowSize = field(default_factory=lambda: {\u0027width\u0027: 1280, \u0027height\u0027: 1100})\n    no_viewport: Optional[bool] = None\n\n    save_recording_path: str | None = None\n    save_downloads_path: str | None = None\n    trace_path: str | None = None\n    locale: str | None = None\n    user_agent: str = (\n        \u0027Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36\u0027\n    )\n\n    highlight_elements: bool = True\n    viewport_expansion: int = 500\n    allowed_domains: list[str] | None = None\n    include_dynamic_attributes: bool = True\n\n    _force_keep_context_alive: bool = False\n```\nThe _is_url_allowed() method is responsible for checking whether a given URL is permitted:\n```python\ndef _is_url_allowed(self, url: str) -\u003e bool:\n    \"\"\"Check if a URL is allowed based on the whitelist configuration.\"\"\"\n    if not self.config.allowed_domains:\n        return True\n\n    try:\n        from urllib.parse import urlparse\n\n        parsed_url = urlparse(url)\n        domain = parsed_url.netloc.lower()\n\n        # Remove port number if present\n        if \u0027:\u0027 in domain:\n            domain = domain.split(\u0027:\u0027)[0]\n\n        # Check if domain matches any allowed domain pattern\n        return any(\n            domain == allowed_domain.lower() or domain.endswith(\u0027.\u0027 + allowed_domain.lower())\n            for allowed_domain in self.config.allowed_domains\n        )\n    except Exception as e:\n        logger.error(f\u0027Error checking URL allowlist: {str(e)}\u0027)\n        return False\n```\nThe core issue stems from the line `domain = domain.split(\u0027:\u0027)[0]`, which allows an attacker to manipulate basic authentication credentials by providing a username:password pair. By replacing the username with a whitelisted domain, the check can be bypassed, even though the actual domain remains different.\n### Proof of Concept (PoC)\n\nSet allowed_domains to [\u0027example.com\u0027] and use the following URL:\n\nhttps://example.com:pass@localhost:8080\n\nThis allows bypassing all whitelist controls and accessing restricted internal services.\n### Impact\n\n- Affected all users relying on this functionality for security.\n- Potential for unauthorized enumeration of localhost services and internal networks.\n- Ability to bypass domain whitelisting, leading to unauthorized browsing.",
  "id": "GHSA-x39x-9qw5-ghrf",
  "modified": "2025-05-05T18:25:04Z",
  "published": "2025-05-05T18:25:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/security/advisories/GHSA-x39x-9qw5-ghrf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/pull/1561"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/browser-use/browser-use"
    },
    {
      "type": "WEB",
      "url": "https://github.com/browser-use/browser-use/releases/tag/0.1.45"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Browser Use allows bypassing `allowed_domains` by putting a decoy domain in http auth username portion of a URL"
}

Mitigation
Architecture and Design

Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form.

Mitigation
Architecture and Design

Reject all alternate path encodings that are not in the expected canonical form.

No CAPEC attack patterns related to this CWE.