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.

199 vulnerabilities reference this CWE, most recent first.

GHSA-3JGF-R68H-XFQM

Vulnerability from github – Published: 2024-05-05 03:30 – Updated: 2024-08-07 19:55
VLAI
Summary
btcd susceptible to consensus failures
Details

btcd before 0.24.0 does not correctly implement the consensus rules outlined in BIP 68 and BIP 112, making it susceptible to consensus failures. Specifically, it uses the transaction version as a signed integer when it is supposed to be treated as unsigned. There can be a chain split and loss of funds.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/btcsuite/btcd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-06T14:28:56Z",
    "nvd_published_at": "2024-05-05T01:15:06Z",
    "severity": "MODERATE"
  },
  "details": "btcd before 0.24.0 does not correctly implement the consensus rules outlined in BIP 68 and BIP 112, making it susceptible to consensus failures. Specifically, it uses the transaction version as a signed integer when it is supposed to be treated as unsigned. There can be a chain split and loss of funds.",
  "id": "GHSA-3jgf-r68h-xfqm",
  "modified": "2024-08-07T19:55:49Z",
  "published": "2024-05-05T03:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/btcsuite/btcd/pull/1981"
    },
    {
      "type": "WEB",
      "url": "https://github.com/btcsuite/btcd/commit/253b688c68b89eca7eb75d4d5443dbdbc928db3c"
    },
    {
      "type": "WEB",
      "url": "https://delvingbitcoin.org/t/disclosure-btcd-consensus-bugs-due-to-usage-of-signed-transaction-version/455"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/btcsuite/btcd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/btcsuite/btcd/blob/e4c88c3a3ecb1813529bf3dddc7a865bd418a6b8/blockchain/chain.go#L383C1-L392C3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/btcsuite/btcd/blob/e4c88c3a3ecb1813529bf3dddc7a865bd418a6b8/txscript/opcode.go#L1172C1-L1178C3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-2818"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "btcd susceptible to consensus failures"
}

GHSA-3MG2-W983-R26Q

Vulnerability from github – Published: 2023-02-28 21:30 – Updated: 2023-03-04 06:30
VLAI
Details

In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-22998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-28T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).",
  "id": "GHSA-3mg2-w983-r26q",
  "modified": "2023-03-04T06:30:22Z",
  "published": "2023-02-28T21:30:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22998"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3PM9-5J7M-59VC

Vulnerability from github – Published: 2026-04-03 03:20 – Updated: 2026-04-28 18:19
VLAI
Summary
OpenClaw: Tlon Startup Migration Rehydrates Empty-Array Revocations From File Config
Details

Summary

Tlon Startup Migration Rehydrates Empty-Array Revocations From File Config

Current Maintainer Triage

  • Status: open
  • Normalized severity: low
  • Assessment: v2026.3.28 startup migration still treats empty-array settings as missing and can rehydrate revoked Tlon config from file state after restart.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • a4d72a83f01fedd35964c352e3473c7712a3511b — 2026-03-31T14:57:03+01:00

Release Process Note

  • The fix is already present in released version 2026.3.31.
  • This draft looks ready for final maintainer disposition or publication, not additional code-fix work.

Thanks @smaeljaish771 for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T03:20:16Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\nTlon Startup Migration Rehydrates Empty-Array Revocations From File Config\n\n## Current Maintainer Triage\n- Status: open\n- Normalized severity: low\n- Assessment: v2026.3.28 startup migration still treats empty-array settings as missing and can rehydrate revoked Tlon config from file state after restart.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `a4d72a83f01fedd35964c352e3473c7712a3511b` \u2014 2026-03-31T14:57:03+01:00\n\n## Release Process Note\n- The fix is already present in released version `2026.3.31`.\n- This draft looks ready for final maintainer disposition or publication, not additional code-fix work.\n\nThanks @smaeljaish771 for reporting.",
  "id": "GHSA-3pm9-5j7m-59vc",
  "modified": "2026-04-28T18:19:09Z",
  "published": "2026-04-03T03:20:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3pm9-5j7m-59vc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a4d72a83f01fedd35964c352e3473c7712a3511b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Tlon Startup Migration Rehydrates Empty-Array Revocations From File Config"
}

GHSA-3Q34-RX83-R6MQ

Vulnerability from github – Published: 2026-04-25 23:30 – Updated: 2026-05-12 13:29
VLAI
Summary
Heimdall has an authorization bypass via path normalization mismatch
Details

Summary

Heimdall performs rule matching on the raw (non-normalized) request path, while downstream components may normalize dot-segments according to RFC 3986, Section 6.2.2.3. This discrepancy can result in heimdall authorizing a request for one path (e.g., /user/../admin, or URL-encoded variants such as /user/%2e%2e/admin or /user/%2e%2e%2fadmin. The latter would require the allow_encoded_slashes option to be set to on or no_decode.) while the downstream ultimately processes a different, normalized path (/admin).

Details

This vulnerability can be exploited by an adversary if rule matching is performed using free (named or unnamed) wildcards without further constraints, as shown in the example snippets below.

id: rule-1
match:
  routes:
    - path: /user/**
execute: # configured to require authentication and authorization
  # ...
id: rule-2
match:
  routes:
    - path: /public/**
execute: # configured to allow anonymous access
  # ...

If an adversary sends a request to /public/../user/whatever, rule-2 will be matched and executed. The downstream service may, however, normalize the request path and interpret it as /user/whatever.

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

  • Normalize HTTP paths or reject HTTP paths containing relative path expressions in the layers in front of Heimdall - this is good practice anyway. Some proxies do that by default, such as Traefik; others, such as Envoy, require additional configuration (for Envoy see normalize_path).
  • Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming 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-42274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-35",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-25T23:30:46Z",
    "nvd_published_at": "2026-05-08T04:16:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nHeimdall performs rule matching on the raw (non-normalized) request path, while downstream components may normalize dot-segments according to [RFC 3986, Section 6.2.2.3](https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.3). This discrepancy can result in heimdall authorizing a request for one path (e.g., `/user/../admin`, or URL-encoded variants such as `/user/%2e%2e/admin` or `/user/%2e%2e%2fadmin`. The latter would require the `allow_encoded_slashes` option to be set to `on` or `no_decode`.) while the downstream ultimately processes a different, normalized path (`/admin`).\n\n### Details\n\nThis vulnerability can be exploited by an adversary if rule matching is performed using free (named or unnamed) wildcards without further constraints, as shown in the example snippets below.\n\n```yaml\nid: rule-1\nmatch:\n  routes:\n    - path: /user/**\nexecute: # configured to require authentication and authorization\n  # ...\n```\n\n```yaml\nid: rule-2\nmatch:\n  routes:\n    - path: /public/**\nexecute: # configured to allow anonymous access\n  # ...\n```\n\nIf an adversary sends a request to `/public/../user/whatever`, rule-2 will be matched and executed. The downstream service may, however, normalize the request path and interpret it as `/user/whatever`.\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### Workarounds\n\n* Normalize HTTP paths or reject HTTP paths containing relative path expressions in the layers in front of Heimdall - this is good practice anyway. Some proxies do that by default, such as Traefik; others, such as Envoy, require additional configuration (for Envoy see [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)).\n* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project\u0027s service.",
  "id": "GHSA-3q34-rx83-r6mq",
  "modified": "2026-05-12T13:29:02Z",
  "published": "2026-04-25T23:30:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-3q34-rx83-r6mq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42274"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/pull/3209"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/commit/b5dfa484b7a8c2ce6d8691c026f9da867719947a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/releases/tag/v0.17.14"
    },
    {
      "type": "WEB",
      "url": "https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.3"
    }
  ],
  "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 has an authorization bypass via path normalization mismatch"
}

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-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"
}

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.