Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

927 vulnerabilities reference this CWE, most recent first.

GHSA-9XP3-MP9C-47RF

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2025-11-04 21:30
VLAI
Details

A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an existing pending request for the same name and forwards a new request. By default, a maximum of 150 pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name. This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the "Birthday Attacks" section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-358"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-20T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an existing pending request for the same name and forwards a new request. By default, a maximum of 150 pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name. This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the \"Birthday Attacks\" section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.",
  "id": "GHSA-9xp3-mp9c-47rf",
  "modified": "2025-11-04T21:30:25Z",
  "published": "2022-05-24T17:39:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25686"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1890125"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QGB7HL3OWHTLEPSMLDGOMXQKG3KM2QME"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WYW3IR6APUSKOYKL5FT3ACTIHWHGQY32"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QGB7HL3OWHTLEPSMLDGOMXQKG3KM2QME"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WYW3IR6APUSKOYKL5FT3ACTIHWHGQY32"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202101-17"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisories/12135-security-advisory-61"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4844"
    },
    {
      "type": "WEB",
      "url": "https://www.jsof-tech.com/disclosures/dnspooq"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/434904"
    }
  ],
  "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"
    }
  ]
}

GHSA-C29C-2Q9C-PC86

Vulnerability from github – Published: 2026-07-02 16:43 – Updated: 2026-07-02 16:43
VLAI
Summary
OpenClaw: Slack allowFrom could bind to mutable display names
Details

Summary

Slack allowFrom could bind to mutable display names. In affected versions, a Slack account able to change display name metadata could match a policy entry through mutable display metadata.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could receive agent access intended for another Slack identity. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.5.3.

Mitigations

use stable Slack user IDs in allowlists until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.5.3-1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T16:43:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nSlack allowFrom could bind to mutable display names. In affected versions, a Slack account able to change display name metadata could match a policy entry through mutable display metadata.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could receive agent access intended for another Slack identity. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.3`.\n\n### Mitigations\n\nuse stable Slack user IDs in allowlists until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-c29c-2q9c-pc86",
  "modified": "2026-07-02T16:43:38Z",
  "published": "2026-07-02T16:43:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-c29c-2q9c-pc86"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Slack allowFrom could bind to mutable display names"
}

GHSA-C2H5-7F6M-JQMP

Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-25 15:32
VLAI
Details

Spoofing replies to Recursor might mark an IP of an authoritative server as not supporting EDNS, causing valdiation of DNSSEC records served by that server to fail.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T14:16:45Z",
    "severity": "MODERATE"
  },
  "details": "Spoofing replies to Recursor might mark an IP of an authoritative server as not supporting EDNS, causing valdiation of DNSSEC records served by that server to fail.",
  "id": "GHSA-c2h5-7f6m-jqmp",
  "modified": "2026-06-25T15:32:01Z",
  "published": "2026-06-25T15:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52690"
    },
    {
      "type": "WEB",
      "url": "https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-powerdns-2026-08.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C3HV-RW36-5MGQ

Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-03-25 21:30
VLAI
Details

Spoofing issue in the Privacy: Anti-Tracking component. This vulnerability affects Firefox < 149.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-24T13:16:08Z",
    "severity": "MODERATE"
  },
  "details": "Spoofing issue in the Privacy: Anti-Tracking component. This vulnerability affects Firefox \u003c 149.",
  "id": "GHSA-c3hv-rw36-5mgq",
  "modified": "2026-03-25T21:30:28Z",
  "published": "2026-03-24T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4728"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2013179"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-23"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C44J-W46W-V5RW

Vulnerability from github – Published: 2026-05-11 21:31 – Updated: 2026-05-12 15:31
VLAI
Details

A file quarantine bypass was addressed with additional checks. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. A maliciously crafted disk image may bypass Gatekeeper checks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-28954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-11T21:18:56Z",
    "severity": "HIGH"
  },
  "details": "A file quarantine bypass was addressed with additional checks. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. A maliciously crafted disk image may bypass Gatekeeper checks.",
  "id": "GHSA-c44j-w46w-v5rw",
  "modified": "2026-05-12T15:31:34Z",
  "published": "2026-05-11T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28954"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127111"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127115"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127116"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/127117"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4P7-RWRG-PF6P

Vulnerability from github – Published: 2026-03-11 19:24 – Updated: 2026-03-11 21:37
VLAI
Summary
Shopware vulnerable to a potential take over of app credentials
Details

Summary

We identified and fixed a vulnerability in the Shopware app registration flow that could, under specific conditions, allow attackers to take over the communication channel between a shop and an app. By abusing app re‑registration, an attacker could redirect app traffic to an attacker‑controlled domain and potentially obtain API credentials intended for the legitimate shop. We have no evidence that this vulnerability has been exploited.


Affected Scope

  • All apps (public and private) that use a registrationUrl in their app manifest and rely on the legacy HMAC‑based registration flow.
  • Both on‑premise and cloud installations are affected until updated to a fixed Shopware version or protected by the latest Shopware Security Plugin.
  • Shopware services and first‑party apps using the affected SDKs were reviewed and patched. The vulnerability does not affect core storefront or administration authentication; it is limited to the app system’s registration and re‑registration mechanism.

Impact

In a successful attack, an attacker who already knows certain app‑side secrets could: - Re‑register an existing app installation with a domain under their control. - Intercept App → Shop communication and cause data tampering (“data poisoning”). - Obtain API integration credentials of the shop with the permissions granted to the app. Shop owners and app manufacturers would typically observe this as “app malfunction” rather than an obvious security issue, which increases the need for hardening.


Root Cause

The legacy app registration flow used HMAC‑based authentication without sufficiently binding a shop installation to its original domain. During re‑registration, the shop-url could be updated without proving control over the previously registered shop or domain. This made targeted hijacking of app communication feasible if an attacker possessed the relevant app‑side secret.


Fix

We have hardened the app registration and re‑registration process: - Dual signature requirement: Re‑registration now requires both the app secret and the existing shop secret to be presented and validated. - Mandatory secret rotation: On successful re‑registration, a new shop secret is generated and verified; the previous secret is invalidated after a short grace period. - Stricter validation: Shopware only accepts updated shop URLs and secrets once the full confirmation flow has completed successfully. - Improved logging and monitoring: All re‑registrations are now logged with additional metadata to help detect abuse patterns. These changes are delivered via: - Updated Shopware core releases (6.6.x, 6.7.x), and - Updated versions of the Shopware Security Plugin for supported older versions, - Updated official SDKs (e.g. PHP and JavaScript app SDKs).


Required Action

For Merchants / Shop Operators

  1. Update Shopware
  2. Upgrade to the latest Shopware 6.6.x / 6.7.x release that includes this fix, or
  3. Install/update the latest Shopware Security Plugin version providing the hotfix for your Shopware 6 installation.
  4. Update apps
  5. Ensure all installed apps are updated to the latest versions provided by their manufacturers.
  6. If you suspect compromised keys or observe unexpected app behaviour, re‑install the affected app or trigger key rotation as documented by the app vendor.

For App Manufacturers / Partners

  1. Update SDKs / implementations
  2. Update to the latest Shopware app SDKs (PHP / JS) or apply the documented changes if you maintain a custom implementation of the registration flow.
  3. Validate both shopware-app-signature and shopware-shop-signature for re‑registration requests.
  4. Always generate and store a new shop secret on re‑registration and only switch to it after a successful confirmation.
  5. Review your apps
  6. Verify that your app does not blindly accept changed shop-url values without validating signatures.
  7. Check any logic that exposes data or functionality based solely on HMAC signatures from shops and ensure it aligns with the hardened registration model.
  8. Test your implementation
  9. Use the updated tooling and guidance provided in your Shopware Account / partner channels to validate that your registration flow complies with the new requirements.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31889"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T19:24:06Z",
    "nvd_published_at": "2026-03-11T20:16:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWe identified and fixed a vulnerability in the Shopware app registration flow that could, under specific conditions, allow attackers to take over the communication channel between a shop and an app. By abusing app re\u2011registration, an attacker could redirect app traffic to an attacker\u2011controlled domain and potentially obtain API credentials intended for the legitimate shop.\nWe have no evidence that this vulnerability has been exploited.\n\n---\n\n### Affected Scope\n\n- All apps (public and private) that use a `registrationUrl` in their app manifest and rely on the legacy HMAC\u2011based registration flow.\n- Both on\u2011premise and cloud installations are affected until updated to a fixed Shopware version or protected by the latest Shopware Security Plugin.\n- Shopware services and first\u2011party apps using the affected SDKs were reviewed and patched.\nThe vulnerability does not affect core storefront or administration authentication; it is limited to the app system\u2019s registration and re\u2011registration mechanism.\n\n---\n\n### Impact\n\nIn a successful attack, an attacker who already knows certain app\u2011side secrets could:\n- Re\u2011register an existing app installation with a domain under their control.\n- Intercept App \u2192 Shop communication and cause data tampering (\u201cdata poisoning\u201d).\n- Obtain API integration credentials of the shop with the permissions granted to the app.\nShop owners and app manufacturers would typically observe this as \u201capp malfunction\u201d rather than an obvious security issue, which increases the need for hardening.\n\n---\n\n### Root Cause\n\nThe legacy app registration flow used HMAC\u2011based authentication without sufficiently binding a shop installation to its original domain. During re\u2011registration, the `shop-url` could be updated without proving control over the previously registered shop or domain. This made targeted hijacking of app communication feasible if an attacker possessed the relevant app\u2011side secret.\n\n---\n\n### Fix\n\nWe have hardened the app registration and re\u2011registration process:\n- **Dual signature requirement:** Re\u2011registration now requires both the app secret and the existing shop secret to be presented and validated.\n- **Mandatory secret rotation:** On successful re\u2011registration, a new shop secret is generated and verified; the previous secret is invalidated after a short grace period.\n- **Stricter validation:** Shopware only accepts updated shop URLs and secrets once the full confirmation flow has completed successfully.\n- **Improved logging and monitoring:** All re\u2011registrations are now logged with additional metadata to help detect abuse patterns.\nThese changes are delivered via:\n- Updated Shopware core releases (6.6.x, 6.7.x), and\n- Updated versions of the Shopware Security Plugin for supported older versions,\n- Updated official SDKs (e.g. PHP and JavaScript app SDKs).\n---\n\n### Required Action\n\n#### For Merchants / Shop Operators\n\n1. **Update Shopware**\n   - Upgrade to the latest Shopware 6.6.x / 6.7.x release that includes this fix, **or**\n   - Install/update the latest Shopware Security Plugin version providing the hotfix for your Shopware 6 installation.\n2. **Update apps**\n   - Ensure all installed apps are updated to the latest versions provided by their manufacturers.\n   - If you suspect compromised keys or observe unexpected app behaviour, re\u2011install the affected app or trigger key rotation as documented by the app vendor.\n\n#### For App Manufacturers / Partners\n\n1. **Update SDKs / implementations**\n   - Update to the latest Shopware app SDKs (PHP / JS) or apply the documented changes if you maintain a custom implementation of the registration flow.\n   - Validate **both** `shopware-app-signature` and `shopware-shop-signature` for re\u2011registration requests.\n   - Always generate and store a new shop secret on re\u2011registration and only switch to it after a successful confirmation.\n2. **Review your apps**\n   - Verify that your app does not blindly accept changed `shop-url` values without validating signatures.\n   - Check any logic that exposes data or functionality based solely on HMAC signatures from shops and ensure it aligns with the hardened registration model.\n3. **Test your implementation**\n   - Use the updated tooling and guidance provided in your Shopware Account / partner channels to validate that your registration flow complies with the new requirements.",
  "id": "GHSA-c4p7-rwrg-pf6p",
  "modified": "2026-03-11T21:37:37Z",
  "published": "2026-03-11T19:24:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-c4p7-rwrg-pf6p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31889"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware vulnerable to a potential take over of app credentials"
}

GHSA-C5PG-CRR2-C647

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

In JetBrains YouTrack before 2024.1.25893 creation comments on behalf of an arbitrary user in HelpDesk was possible

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-28228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-07T12:15:46Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains YouTrack before 2024.1.25893 creation comments on behalf of an arbitrary user in HelpDesk was possible",
  "id": "GHSA-c5pg-crr2-c647",
  "modified": "2024-03-07T12:30:26Z",
  "published": "2024-03-07T12:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28228"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "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-C737-PHJJ-7FVF

Vulnerability from github – Published: 2026-01-13 15:37 – Updated: 2026-01-13 15:37
VLAI
Details

Zohocorp ManageEngine ADSelfService Plus versions before 6519 are vulnerable to Authentication Bypass due to improper filter configurations.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T14:16:36Z",
    "severity": "CRITICAL"
  },
  "details": "Zohocorp ManageEngine ADSelfService Plus versions before 6519 are vulnerable to Authentication Bypass due to improper filter configurations.",
  "id": "GHSA-c737-phjj-7fvf",
  "modified": "2026-01-13T15:37:04Z",
  "published": "2026-01-13T15:37:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11250"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/self-service-password/advisory/CVE-2025-11250.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C79H-9PJ9-MGQP

Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31
VLAI
Details

Authentication Bypass by Spoofing vulnerability in webtechideas WTI Like Post allows Functionality Bypass.This issue affects WTI Like Post: from n/a through 1.4.6.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-33917"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T09:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in webtechideas WTI Like Post allows Functionality Bypass.This issue affects WTI Like Post: from n/a through 1.4.6.",
  "id": "GHSA-c79h-9pj9-mgqp",
  "modified": "2024-05-17T09:31:03Z",
  "published": "2024-05-17T09:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33917"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wti-like-post/wordpress-wti-like-post-plugin-1-4-6-ip-restriction-bypass-vulnerability-vulnerability?_s_id=cve"
    }
  ],
  "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-C7RR-4VVG-C7R2

Vulnerability from github – Published: 2022-11-08 12:00 – Updated: 2022-11-08 19:00
VLAI
Details

WithSecure through 2022-08-10 allows attackers to cause a denial of service (issue 3 of 5).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-07T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "WithSecure through 2022-08-10 allows attackers to cause a denial of service (issue 3 of 5).",
  "id": "GHSA-c7rr-4vvg-c7r2",
  "modified": "2022-11-08T19:00:24Z",
  "published": "2022-11-08T12:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38164"
    },
    {
      "type": "WEB",
      "url": "https://withsecure.com"
    },
    {
      "type": "WEB",
      "url": "https://www.f-secure.com/en/home/support/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.