Common Weakness Enumeration

CWE-436

Allowed-with-Review

Interpretation Conflict

Abstraction: Class · Status: Incomplete

Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.

228 vulnerabilities reference this CWE, most recent first.

GHSA-42Q8-WW2W-FGMM

Vulnerability from github – Published: 2026-07-10 15:31 – Updated: 2026-07-10 15:31
VLAI
Details

Capgo before 12.128.2 contains a cross-tenant preview namespace collision vulnerability caused by non-bijective decoding of double underscores to dots in preview hostname parsing. Attackers can register app IDs with underscores that collide with other tenants' dotted app IDs, causing preview misrouting and denial of preview access for victim applications.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56329"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T15:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Capgo before 12.128.2 contains a cross-tenant preview namespace collision vulnerability caused by non-bijective decoding of double underscores to dots in preview hostname parsing. Attackers can register app IDs with underscores that collide with other tenants\u0027 dotted app IDs, causing preview misrouting and denial of preview access for victim applications.",
  "id": "GHSA-42q8-ww2w-fgmm",
  "modified": "2026-07-10T15:31:40Z",
  "published": "2026-07-10T15:31:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Cap-go/capgo/security/advisories/GHSA-76qq-gg2p-pwwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56329"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/capgo-cross-tenant-preview-namespace-collision-via-non-bijective-underscore-decoding"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-43JV-5J4X-QV67

Vulnerability from github – Published: 2026-04-25 23:29 – Updated: 2026-05-12 13:28
VLAI
Summary
Heimdall: Case-sensitive handling of URL-encoded slashes may lead to inconsistent path interpretation
Details

Summary

Heimdall handles URL-encoded slashes (%2F) in a case-sensitive manner, while percent-encoding is defined to be case-insensitive. As a result, the lowercase equivalent (%2f) is not recognized and therefore not processed as expected when allow_encoded_slashes is set to off (the default setting).

This discrepancy can lead to differences in how request paths are interpreted by heimdall and upstream components, which may result in authorization bypass.

Note: The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled (e.g. via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag).

Details

Consider the following rule configuration:

id: rule-1
match:
  routes:
    - path: /admin/**
execute: # configured to require authentication and authorization
  # ...

If an adversary sends a request such as /admin%2fsecret, neither is the above rule matched, nor is the request rejected (as would be expected when allow_encoded_slashes is set to off). Instead, the default rule (if configured) will be executed.

If the configured default rule is overly permissive (e.g. allowing anonymous access), and the upstream service interprets %2f as a path separator, the request may ultimately be processed as /admin/secret.

This results in the request being authorized based on a different path than the one processed by the upstream service, leading to authorization bypass.

Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

  • Access to or modification of data that should be restricted
  • Invocation of functionality that is expected to require authentication or authorization
  • In certain configurations, escalation of privileges depending on the exposed functionality

Workarounds

  • Developers should not use the --insecure or the --insecure-skip-secure-default-rule-enforcement flags and configure their default rule to implement "deny by default".
  • Reject HTTP paths containing encoded slashes in the layers in front of heimdall. Some proxies, like e.g., Traefik, do that by default.
  • Include the ID of the rule expected to be executed in the JWT issued by heimdall and verify that value in the project's service.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:29:40Z",
    "nvd_published_at": "2026-05-08T04:16:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nHeimdall handles URL-encoded slashes (`%2F`) in a case-sensitive manner, while percent-encoding is defined to be case-insensitive. As a result, the lowercase equivalent (`%2f`) is not recognized and therefore not processed as expected when `allow_encoded_slashes` is set to `off` (the default setting).\n\nThis discrepancy can lead to differences in how request paths are interpreted by heimdall and upstream components, which may result in authorization bypass.\n\n**Note:** The issue can only lead to unintended access if heimdall is configured with an \"allow all\" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled (e.g. via `--insecure-skip-secure-default-rule-enforcement` or the broader `--insecure` flag).\n\n### Details\n\nConsider the following rule configuration:\n\n```yaml\nid: rule-1\nmatch:\n  routes:\n    - path: /admin/**\nexecute: # configured to require authentication and authorization\n  # ...\n```\n\nIf an adversary sends a request such as `/admin%2fsecret`, neither is the above rule matched, nor is the request rejected (as would be expected when `allow_encoded_slashes` is set to `off`). Instead, the default rule (if configured) will be executed.\n\nIf the configured default rule is overly permissive (e.g. allowing anonymous access), and the upstream service interprets `%2f` as a path separator, the request may ultimately be processed as `/admin/secret`.\n\nThis results in the request being authorized based on a different path than the one processed by the upstream service, leading to authorization bypass.\n\n### Impact\n\nBypass of access control policies enforced by heimdall may lead to the following consequences:\n\n* Access to or modification of data that should be restricted\n* Invocation of functionality that is expected to require authentication or authorization\n* In certain configurations, escalation of privileges depending on the exposed functionality\n\n\n### Workarounds\n\n* Developers should not use the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags and configure their default rule to implement \"deny by default\".\n* Reject HTTP paths containing encoded slashes in the layers in front of heimdall. Some proxies, like e.g., Traefik, do that by default.\n* Include the ID of the rule expected to be executed in the JWT issued by heimdall and verify that value in the project\u0027s service.",
  "id": "GHSA-43jv-5j4x-qv67",
  "modified": "2026-05-12T13:28:19Z",
  "published": "2026-04-25T23:29:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-43jv-5j4x-qv67"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/pull/3207"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/commit/8b0de6aba23a047cfee3081df878271bb17f4351"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/releases/tag/v0.17.14"
    }
  ],
  "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:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: Case-sensitive handling of URL-encoded slashes may lead to inconsistent path interpretation"
}

GHSA-4528-VMXJ-V97W

Vulnerability from github – Published: 2022-11-23 18:30 – Updated: 2022-11-28 18:30
VLAI
Details

Insecure method vulnerability in which allowed HTTP methods are disclosed. E.g., OPTIONS, DELETE, TRACE, and PUT

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-650"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-23T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insecure method vulnerability in which allowed HTTP methods are disclosed. E.g., OPTIONS, DELETE, TRACE, and PUT",
  "id": "GHSA-4528-vmxj-v97w",
  "modified": "2022-11-28T18:30:15Z",
  "published": "2022-11-23T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38115"
    },
    {
      "type": "WEB",
      "url": "https://documentation.solarwinds.com/en/success_center/sem/content/release_notes/sem_2022-4_release_notes.htm"
    },
    {
      "type": "WEB",
      "url": "https://www.solarwinds.com/trust-center/security-advisories/CVE-2022-38115"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-459M-QJWC-XV42

Vulnerability from github – Published: 2024-02-02 03:30 – Updated: 2024-02-02 03:30
VLAI
Details

IBM PowerSC 1.3, 2.0, and 2.1 uses insecure HTTP methods which could allow a remote attacker to perform unauthorized file request modification. IBM X-Force ID: 275109.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-50327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-650"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-02T01:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM PowerSC 1.3, 2.0, and 2.1 uses insecure HTTP methods which could allow a remote attacker to perform unauthorized file request modification.  IBM X-Force ID:  275109.\n\n",
  "id": "GHSA-459m-qjwc-xv42",
  "modified": "2024-02-02T03:30:32Z",
  "published": "2024-02-02T03:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50327"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275109"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7113759"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48F2-M7JG-866X

Vulnerability from github – Published: 2022-06-06 21:24 – Updated: 2022-06-06 21:24
VLAI
Summary
Failed payment recorded has completed in Silverstripe Omnipay
Details

Impact

For a subset of Omnipay gateways (those that use intermediary states like isNotification() or isRedirect()), if the payment identifier or success URL is exposed it is possible for payments to be prematurely marked as completed without payment being taken. This is mitigated by the fact that most payment gateways hide this information from users, however some issuing banks offer flawed 3DSecure implementations that may inadvertently expose this data.

Patches

The following versions have been patched to fix this issue:

  • 2.5.2
  • 3.0.2
  • 3.1.4
  • 3.2.1

Workarounds

There are no known workarounds for this vulnerability.

References

N/A.

For more information

If you have any questions or comments about this advisory: * Email us at security@silverstripe.org

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/silverstripe-omnipay"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/silverstripe-omnipay"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/silverstripe-omnipay"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "silverstripe/silverstripe-omnipay"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29254"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-437"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-06T21:24:39Z",
    "nvd_published_at": "2022-06-09T07:15:00Z",
    "severity": "LOW"
  },
  "details": "### Impact\nFor a subset of Omnipay gateways (those that use intermediary states like `isNotification()` or `isRedirect()`), if the payment identifier or success URL is exposed it is possible for payments to be prematurely marked as completed without payment being taken. This is mitigated by the fact that most payment gateways hide this information from users, however some issuing banks offer flawed 3DSecure implementations that may inadvertently expose this data.\n\n### Patches\nThe following versions have been patched to fix this issue:\n\n- `2.5.2`\n- `3.0.2`\n- `3.1.4`\n- `3.2.1`\n\n### Workarounds\nThere are no known workarounds for this vulnerability.\n\n### References\nN/A.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@silverstripe.org](mailto:security@silverstripe.org)\n",
  "id": "GHSA-48f2-m7jg-866x",
  "modified": "2022-06-06T21:24:39Z",
  "published": "2022-06-06T21:24:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/security/advisories/GHSA-48f2-m7jg-866x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29254"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/commit/7dee9a1e0a5f54c2dc06e018cff3d9a19044e01b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/silverstripe/silverstripe-omnipay"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/releases/tag/2.5.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/releases/tag/3.0.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/releases/tag/3.1.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/silverstripe/silverstripe-omnipay/releases/tag/3.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Failed payment recorded has completed in Silverstripe Omnipay"
}

GHSA-4C8G-83QW-93J6

Vulnerability from github – Published: 2026-07-21 19:03 – Updated: 2026-08-28 18:31
VLAI
Summary
fast-uri vulnerable to host confusion via failed IDN canonicalization
Details

Impact

fast-uri versions >= 2.3.1, <= 4.0.0 fail to canonicalize Unicode/IDN hostnames for HTTP-family URLs. The IDN conversion path calls URL.domainToASCII(...) on the global WHATWG URL constructor, where that helper does not exist. The resulting TypeError is silently routed into parsed.error, but parse(), normalize(), and equal() all return with the host left in its original Unicode form.

For example, http://127。0。0。1/ is treated by fast-uri as host 127。0。0。1, while Node's WHATWG URL parser and fetch() canonicalize the same input to 127.0.0.1.

Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.0.1, v3.1.3, or v2.4.2

Workarounds

None. Upgrade to the patched version.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-uri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.1"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-13676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-551"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:03:11Z",
    "nvd_published_at": "2026-06-29T14:16:47Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`fast-uri` versions `\u003e= 2.3.1, \u003c= 4.0.0` fail to canonicalize Unicode/IDN hostnames for HTTP-family URLs. The IDN conversion path calls `URL.domainToASCII(...)` on the global WHATWG `URL` constructor, where that helper does not exist. The resulting `TypeError` is silently routed into `parsed.error`, but `parse()`, `normalize()`, and `equal()` all return with the host left in its original Unicode form.\n\nFor example, `http://127\u30020\u30020\u30021/` is treated by `fast-uri` as host `127\u30020\u30020\u30021`, while Node\u0027s WHATWG URL parser and `fetch()` canonicalize the same input to `127.0.0.1`.\n\nApplications that use `fast-uri` to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL into Node\u0027s URL or `fetch()` consumers see a policy/use desync and can be steered to an unintended destination.\n\n### Patches\n\nUpgrade to `fast-uri` v4.0.1, v3.1.3, or v2.4.2\n\n### Workarounds\n\nNone. Upgrade to the patched version.",
  "id": "GHSA-4c8g-83qw-93j6",
  "modified": "2026-08-28T18:31:12Z",
  "published": "2026-07-21T19:03:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-4c8g-83qw-93j6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13676"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/pull/188"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/commit/2a6d357a18a68e6d812824379fd3388a1ae50d05"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/commit/21ea1f9d70495c931f55dff893a8fa38f4f2e6bd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/commit/01db48010f594b98f7b323be18b393791c66ed1d"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:51349"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:54760"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:56366"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:56431"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57013"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57191"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57194"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57590"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59593"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:60386"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:60520"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-13676"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2494197"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fast-uri"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/releases/tag/v2.4.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/releases/tag/v3.1.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fast-uri/releases/tag/v4.0.1"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-13676.json"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37186"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37585"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37628"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40118"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40262"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40765"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:40945"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41066"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41928"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41929"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:42815"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:43038"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:44239"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:44268"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47728"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48124"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48126"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:49642"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50340"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50479"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50758"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:51196"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:51197"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:51342"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:51348"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-uri vulnerable to host confusion via failed IDN canonicalization"
}

GHSA-4C8J-MGM4-QQVP

Vulnerability from github – Published: 2026-06-26 19:26 – Updated: 2026-06-26 19:26
VLAI
Summary
Remark42: Cross-Site Scripting (XSS) on /api/v1/img via content-type spoofing
Details

Summary

The remark42 image proxy fetches an arbitrary remote URL and re-serves the response from remark42's own origin. The download path decides whether the fetched resource is an image by looking only at the Content-Type header the remote server claims — it never inspects the actual bytes. The serving path then derives the response Content-Type by sniffing those bytes with http.DetectContentType.

An attacker hosts a URL that sets Content-Type to image/png but returns an HTML/JavaScript body:

  • the download check sees image/png → accepts it;
  • the serve path sniffs the body → emits Content-Type: text/html;
  • the browser renders attacker HTML/JS as a document in remark42's origin.

Details

Downloader

backend/app/rest/proxy/image.godownloadImage(), lines 189-206:

contentType := resp.Header.Get("Content-Type")
if !strings.HasPrefix(contentType, "image/") {
    return nil, fmt.Errorf("invalid content type %s", contentType)
}

maxSize := 5 * 1024 * 1024 // 5MB default
if p.ImageService != nil && p.ImageService.MaxSize > 0 {
    maxSize = p.ImageService.MaxSize
}
lr := io.LimitReader(resp.Body, int64(maxSize)+1)
imgData, err := io.ReadAll(lr)
if err != nil {
    return nil, fmt.Errorf("unable to read image body: %w", err)
}
if len(imgData) > maxSize {
    return nil, fmt.Errorf("image is too large")
}
return imgData, nil          // <-- bytes never validated, returned as-is

Send Content-Type: image/png and the check passes regardless of what the body actually contains.

Server

backend/app/rest/proxy/image.goHandler(), line 131:

w.Header().Add("Content-Type", p.ImageService.ImgContentType(img))
_, err = io.Copy(w, bytes.NewReader(img))

backend/app/store/image/image.goImgContentType(), lines 242-249:

func (s *Service) ImgContentType(img []byte) string {
    contentType := http.DetectContentType(img)
    if contentType == "application/octet-stream" {
        return "image/*"
    }
    return contentType                 // <-- returns text/html for an HTML body
}

PoC

self.send_response(200)
self.send_header("Content-Type", "image/png")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)            # body = <!DOCTYPE html><script>...</script>

Then have the victim open https://<remark42-host>/api/v1/img?src=<base64(attacker-host)> top-level.

Impact

  • The script can issue authenticated, same-origin API calls with credentials: 'include' — the JWT cookie is sent automatically.
  • The script can read the XSRF-TOKEN cookie and re-send it as the X-XSRF-TOKEN header, defeating CSRF protection. The attacker acts as the victim: delete/edit their comments, change their settings, and — if the victim is admin — perform admin actions.

Triggering requires no remark42 account on the target instance; the attacker only needs to host the malicious upstream URL and deliver the proxy link to a victim by any means (email, DM, link on another site, etc.).

Fix

v1.16.0 adds layered defense to /api/v1/img and /api/v1/picture/{user}/{id}:

  • rest.SafeImgContentType validates sniffed body bytes against a strict allowlist (image/png, image/jpeg, image/gif, image/webp, image/bmp, image/x-icon). Non-image content returns 415 with no body echo. SVG is implicitly excluded.
  • Every response carries Content-Security-Policy: default-src 'none'; sandbox; frame-ancestors 'none', X-Content-Type Options: nosniff, and Content-Disposition: inline; filename="image".
  • The ETag is bumped to "v2:<base64(src)>". Browsers that revalidate cached pre-fix responses get a fresh validated 200 instead of a 304 against the poisoned cached entry.
  • The strict default-src 'none'; sandbox CSP also applies to all /api/v1/* routes as defense-in-depth.

Residual exposure

Browser-local caches that already hold a pre-fix text/html response with Cache-Control: max-age=2592000 keep serving it from local store until the TTL expires or the cache is evicted under memory pressure. The ETag bump only reaches clients that revalidate during the cached lifetime. Operators running a CDN/edge cache in front of remark42 should purge /api/v1/img after deploying v1.16.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/umputun/remark42"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T19:26:43Z",
    "nvd_published_at": "2026-06-17T13:20:43Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe remark42 image proxy fetches an arbitrary remote URL and re-serves the response from remark42\u0027s own origin. The download path decides whether the fetched resource is an image by looking only at the `Content-Type` header the remote server claims \u2014 it never inspects the actual bytes. The serving path then derives the response `Content-Type` by sniffing those bytes with `http.DetectContentType`.\n\nAn attacker hosts a URL that sets `Content-Type` to `image/png` but returns an HTML/JavaScript body:\n\n* the download check sees `image/png` \u2192 accepts it;\n* the serve path sniffs the body \u2192 emits `Content-Type: text/html`;\n* the browser renders attacker HTML/JS as a document in remark42\u0027s origin.\n\n### Details\n#### Downloader\n\n`backend/app/rest/proxy/image.go` \u2014 `downloadImage()`, lines 189-206:\n\n```go\ncontentType := resp.Header.Get(\"Content-Type\")\nif !strings.HasPrefix(contentType, \"image/\") {\n    return nil, fmt.Errorf(\"invalid content type %s\", contentType)\n}\n\nmaxSize := 5 * 1024 * 1024 // 5MB default\nif p.ImageService != nil \u0026\u0026 p.ImageService.MaxSize \u003e 0 {\n    maxSize = p.ImageService.MaxSize\n}\nlr := io.LimitReader(resp.Body, int64(maxSize)+1)\nimgData, err := io.ReadAll(lr)\nif err != nil {\n    return nil, fmt.Errorf(\"unable to read image body: %w\", err)\n}\nif len(imgData) \u003e maxSize {\n    return nil, fmt.Errorf(\"image is too large\")\n}\nreturn imgData, nil          // \u003c-- bytes never validated, returned as-is\n```\n\nSend `Content-Type: image/png` and the check passes regardless of what the body actually contains.\n\n#### Server\n\n`backend/app/rest/proxy/image.go` \u2014 `Handler()`, line 131:\n\n```go\nw.Header().Add(\"Content-Type\", p.ImageService.ImgContentType(img))\n_, err = io.Copy(w, bytes.NewReader(img))\n```\n\n`backend/app/store/image/image.go` \u2014 `ImgContentType()`, lines 242-249:\n\n```go\nfunc (s *Service) ImgContentType(img []byte) string {\n    contentType := http.DetectContentType(img)\n    if contentType == \"application/octet-stream\" {\n        return \"image/*\"\n    }\n    return contentType                 // \u003c-- returns text/html for an HTML body\n}\n```\n\n### PoC\n\n```python\nself.send_response(200)\nself.send_header(\"Content-Type\", \"image/png\")\nself.send_header(\"Content-Length\", str(len(body)))\nself.end_headers()\nself.wfile.write(body)            # body = \u003c!DOCTYPE html\u003e\u003cscript\u003e...\u003c/script\u003e\n```\n\nThen have the victim open `https://\u003cremark42-host\u003e/api/v1/img?src=\u003cbase64(attacker-host)\u003e` top-level.\n\n### Impact\n* The script can issue authenticated, same-origin API calls with `credentials: \u0027include\u0027` \u2014 the JWT cookie is sent automatically.\n* The script can read the `XSRF-TOKEN` cookie and re-send it as the `X-XSRF-TOKEN` header, defeating CSRF protection. The attacker acts as the victim: delete/edit their comments, change their settings, and \u2014 if the victim is admin \u2014 perform admin actions.\n\nTriggering requires no remark42 account on the target instance; the attacker only needs to host the malicious upstream URL and deliver the proxy link to a victim by any means (email, DM, link on another site, etc.).\n\n### Fix\n\n`v1.16.0` adds layered defense to `/api/v1/img` and `/api/v1/picture/{user}/{id}`:\n\n* `rest.SafeImgContentType` validates sniffed body bytes against a strict allowlist (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/bmp`, `image/x-icon`). Non-image content returns `415` with no body echo. SVG is implicitly excluded.\n* Every response carries `Content-Security-Policy: default-src \u0027none\u0027; sandbox; frame-ancestors \u0027none\u0027`, `X-Content-Type Options: nosniff`, and `Content-Disposition: inline; filename=\"image\"`.\n* The ETag is bumped to `\"v2:\u003cbase64(src)\u003e\"`. Browsers that revalidate cached pre-fix responses get a fresh validated `200` instead of a `304` against the poisoned cached entry.\n* The strict `default-src \u0027none\u0027; sandbox` CSP also applies to all `/api/v1/*` routes as defense-in-depth.\n\n#### Residual exposure\n\nBrowser-local caches that already hold a pre-fix `text/html` response with `Cache-Control: max-age=2592000` keep serving it from local store until the TTL expires or the cache is evicted under memory pressure. The ETag bump only reaches clients that revalidate during the cached lifetime. Operators running a CDN/edge cache in front of remark42 should purge `/api/v1/img` after deploying `v1.16.0`.",
  "id": "GHSA-4c8j-mgm4-qqvp",
  "modified": "2026-06-26T19:26:44Z",
  "published": "2026-06-26T19:26:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/security/advisories/GHSA-4c8j-mgm4-qqvp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48788"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/commit/78d6de6bce1e961f023969da3ec8a00dd80c9ae8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umputun/remark42"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/releases/tag/v1.16.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Remark42: Cross-Site Scripting (XSS) on /api/v1/img via content-type spoofing"
}

GHSA-4P64-V8F5-R2GX

Vulnerability from github – Published: 2026-04-14 20:05 – Updated: 2026-04-14 20:05
VLAI
Summary
Multiple security fixes in justhtml
Details

Summary

justhtml 1.16.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

  • programmatic DOM input to sanitize() or sanitize_dom()
  • reused or mutated sanitization policy objects
  • custom policies that preserve foreign namespaces such as SVG or MathML

Affected versions

  • justhtml <= 1.15.0

Fixed version

  • justhtml 1.16.0 released on April 12, 2026

Impact

Policy reuse and mutation

Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

In-memory sanitization gaps

Programmatic DOM sanitization could miss dangerous mixed-case tag names such as ScRiPt or StYlE, and custom drop_content_tags values such as {"SCRIPT"} could silently fail to drop dangerous subtrees.

Serialization injection

Crafted programmatic doctype names could serialize into active markup before the document body.

Foreign-namespace policy bypasses

Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

  • animation elements such as <set> and <animate> that mutate already-sanitized attributes after sanitization
  • presentation attributes such as fill, clip-path, mask, marker-start, and cursor containing external url(...) references
  • programmatic DOM trees that claim namespace="html" but serialize as <svg> or <math>, bypassing foreign-content checks

Rawtext hardening gap

Mixed-case programmatic style or script nodes could bypass rawtext hardening and preserve active stylesheet content such as remote @import rules.

Default configuration

Most of these issues did not affect the normal JustHTML(..., sanitize=True) path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

Recommended action

Upgrade to justhtml 1.16.0.

If you cannot upgrade immediately:

  • do not mutate DEFAULT_POLICY, DEFAULT_DOCUMENT_POLICY, or nested policy internals
  • avoid reusing policy objects after mutating nested state
  • avoid preserving SVG or MathML for untrusted input
  • avoid preserving style or script in custom policies for untrusted input
  • avoid serializing untrusted programmatic doctypes or DOM trees

Credit

Discovered during an internal security review of justhtml.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.15.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "justhtml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-436",
      "CWE-471",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:05:10Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\n`justhtml` `1.16.0` fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.\n\nMost of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:\n\n- programmatic DOM input to `sanitize()` or `sanitize_dom()`\n- reused or mutated sanitization policy objects\n- custom policies that preserve foreign namespaces such as SVG or MathML\n\n## Affected versions\n\n- `justhtml` `\u003c= 1.15.0`\n\n## Fixed version\n\n- `justhtml` `1.16.0` released on April 12, 2026\n\n## Impact\n\n### Policy reuse and mutation\nNested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.\n\n### In-memory sanitization gaps\nProgrammatic DOM sanitization could miss dangerous mixed-case tag names such as `ScRiPt` or `StYlE`, and custom `drop_content_tags` values such as `{\"SCRIPT\"}` could silently fail to drop dangerous subtrees.\n\n### Serialization injection\nCrafted programmatic doctype names could serialize into active markup before the document body.\n\n### Foreign-namespace policy bypasses\nCustom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:\n\n- animation elements such as `\u003cset\u003e` and `\u003canimate\u003e` that mutate already-sanitized attributes after sanitization\n- presentation attributes such as `fill`, `clip-path`, `mask`, `marker-start`, and `cursor` containing external `url(...)` references\n- programmatic DOM trees that claim `namespace=\"html\"` but serialize as `\u003csvg\u003e` or `\u003cmath\u003e`, bypassing foreign-content checks\n\n### Rawtext hardening gap\nMixed-case programmatic `style` or `script` nodes could bypass rawtext hardening and preserve active stylesheet content such as remote `@import` rules.\n\n## Default configuration\n\nMost of these issues did **not** affect the normal `JustHTML(..., sanitize=True)` path for ordinary parsed HTML.\n\nThe main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.\n\n## Recommended action\n\nUpgrade to `justhtml` `1.16.0`.\n\nIf you cannot upgrade immediately:\n\n- do not mutate `DEFAULT_POLICY`, `DEFAULT_DOCUMENT_POLICY`, or nested policy internals\n- avoid reusing policy objects after mutating nested state\n- avoid preserving SVG or MathML for untrusted input\n- avoid preserving `style` or `script` in custom policies for untrusted input\n- avoid serializing untrusted programmatic doctypes or DOM trees\n\n## Credit\n\nDiscovered during an internal security review of `justhtml`.",
  "id": "GHSA-4p64-v8f5-r2gx",
  "modified": "2026-04-14T20:05:10Z",
  "published": "2026-04-14T20:05:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EmilStenstrom/justhtml/security/advisories/GHSA-4p64-v8f5-r2gx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EmilStenstrom/justhtml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Multiple security fixes in justhtml"
}

GHSA-4VC4-M8QH-G8JM

Vulnerability from github – Published: 2025-03-12 20:20 – Updated: 2025-11-03 21:33
VLAI
Summary
Ruby SAML allows a SAML authentication bypass due to DOCTYPE handling (parser differential)
Details

Summary

An authentication bypass vulnerability was found in ruby-saml due to a parser differential. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack.

Impact

This issue may lead to authentication bypass.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-12T20:20:24Z",
    "nvd_published_at": "2025-03-12T21:15:42Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn authentication bypass vulnerability was found in ruby-saml due to a parser differential.\nReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack.\n\n### Impact\nThis issue may lead to authentication bypass.",
  "id": "GHSA-4vc4-m8qh-g8jm",
  "modified": "2025-11-03T21:33:11Z",
  "published": "2025-03-12T20:20:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-4vc4-m8qh-g8jm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-hw46-3hmr-x9xv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25291"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e76c5b36bac40aedbf1ba7ffaaf495be63328cd9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f9afa467b585de279db0cbd0fb8ae97"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2025/03/12/patch-release-gitlab-17-9-2-released"
    },
    {
      "type": "WEB",
      "url": "https://github.blog/security/sign-in-as-anyone-bypassing-saml-sso-authentication-with-parser-differentials"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAML-Toolkits/ruby-saml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.12.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/releases/tag/v1.18.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2025-25291.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=43374519"
    },
    {
      "type": "WEB",
      "url": "https://portswigger.net/research/saml-roulette-the-hacker-always-wins"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250314-0010"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2024-329_GHSL-2024-330_ruby-saml"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ruby SAML allows a SAML authentication bypass due to DOCTYPE handling (parser differential)"
}

GHSA-546M-4W73-87M7

Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22
VLAI
Details

bgpd in FRRouting FRR (aka Free Range Routing) 2.x and 3.x before 3.0.4, 4.x before 4.0.1, 5.x before 5.0.2, and 6.x before 6.0.2 (not affecting Cumulus Linux or VyOS), when ENABLE_BGP_VNC is used for Virtual Network Control, allows remote attackers to cause a denial of service (peering session flap) via attribute 255 in a BGP UPDATE packet. This occurred during Disco in January 2019 because FRR does not implement RFC 7606, and therefore the packets with 255 were considered invalid VNC data and the BGP session was closed.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-5892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-10T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "bgpd in FRRouting FRR (aka Free Range Routing) 2.x and 3.x before 3.0.4, 4.x before 4.0.1, 5.x before 5.0.2, and 6.x before 6.0.2 (not affecting Cumulus Linux or VyOS), when ENABLE_BGP_VNC is used for Virtual Network Control, allows remote attackers to cause a denial of service (peering session flap) via attribute 255 in a BGP UPDATE packet. This occurred during Disco in January 2019 because FRR does not implement RFC 7606, and therefore the packets with 255 were considered invalid VNC data and the BGP session was closed.",
  "id": "GHSA-546m-4w73-87m7",
  "modified": "2022-05-13T01:22:33Z",
  "published": "2022-05-13T01:22:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86705a"
    },
    {
      "type": "WEB",
      "url": "https://frrouting.org/community/security/cve-2019-5892.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/releases/tag/frr-3.0.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/releases/tag/frr-4.0.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/releases/tag/frr-5.0.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/releases/tag/frr-6.0.2"
    },
    {
      "type": "WEB",
      "url": "https://lists.frrouting.org/pipermail/frog/2019-January/000404.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-105: HTTP Request Splitting

An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).

See CanPrecede relationships for possible consequences.

CAPEC-273: HTTP Response Smuggling

An adversary manipulates and injects malicious content in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., server).

See CanPrecede relationships for possible consequences.

CAPEC-34: HTTP Response Splitting

An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.

See CanPrecede relationships for possible consequences.