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-FC6G-2GCP-2QRQ

Vulnerability from github – Published: 2026-02-03 17:31 – Updated: 2026-02-03 18:55
VLAI
Summary
RustFS has SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers
Details

Summary

IP-based access control can be bypassed: get_condition_values trusts client-supplied X-Forwarded-For/X-Real-Ip without verifying a trusted proxy, so any reachable client can spoof aws:SourceIp and satisfy IP-allowlist policies.

Details

  • Vulnerable code: rustfs/src/auth.rs:289-304 sets remote_addr from X-Forwarded-For/X-Real-Ip, then inserts SourceIp via get_source_ip_raw, with no trust boundary or proxy validation:
    • let remote_addr = header.get("x-forwarded-for").and_then(...).or_else(|| header.get("x-real-ip")...).unwrap_or("127.0.0.1");
    • args.insert("SourceIp", vec![get_source_ip_raw(header, remote_addr)]);
  • This value feeds IAM/bucket policy evaluation in rustfs/src/storage/access.rs (authorization path), so any request that forges the header can meet aws:SourceIp conditions.
  • No authentication is required beyond the request itself; the header is taken at face value even on direct connections.

PoC

rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz

Steps (already included in rustfs-auth-trusted-ip-header-spoofing-poc/):

  1. Start RustFS with two local volumes, e.g.:
     mkdir -p /tmp/rustfs-data1 /tmp/rustfs-data2
     RUSTFS_ACCESS_KEY=devadmin RUSTFS_SECRET_KEY=devadmin \
       cargo run --bin rustfs -- --address 0.0.0.0:9000 \
       /tmp/rustfs-data1 /tmp/rustfs-data2
  1. From rustfs-auth-trusted-ip-header-spoofing-poc/, run:
     ENDPOINT=http://127.0.0.1:9000 make run
 The script:
  - Creates bucket `rustfs-trusted-ip-poc`.
  - Applies a bucket policy allowing `s3:ListBucket` only from `10.0.0.5/32` (`Principal: {"AWS":["*"]},` Resource array).
  - Sends three unauthenticated `ListBucket` calls:
      - Baseline (no spoof) → HTTP 403.
      - Spoofed `X-Forwarded-For: 10.0.0.5` → HTTP 200 (policy bypass).
      - Spoofed `X-Forwarded-For: 1.2.3.4` → HTTP 403.
  - Responses saved to `poc-baseline.xml`, `poc-spoofed.xml`, `poc-deny.xml`.

Impact

  • Vulnerability type: Authorization bypass of IP-allowlist (aws:SourceIp) via header spoofing.
  • Who is impacted: Any deployment relying on aws:SourceIp in IAM/bucket policies for S3 operations. Attackers with network reach to RustFS can forge forwarded-IP headers to gain list/read/write where IP restrictions were meant to block them.

Credits

Identified by SecMate (https://secmate.dev) automated analysis and validated during manual triage.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rustfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-alpha.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-21862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-03T17:31:41Z",
    "nvd_published_at": "2026-02-03T16:16:12Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nIP-based access control can be bypassed: get_condition_values trusts client-supplied X-Forwarded-For/X-Real-Ip without verifying a trusted proxy, so any reachable client can spoof aws:SourceIp and satisfy IP-allowlist policies.\n\n### Details\n\n  - Vulnerable code: `rustfs/src/auth.rs:289-304` sets `remote_addr` from `X-Forwarded-For`/`X-Real-Ip`, then inserts `SourceIp` via\n    `get_source_ip_raw`, with no trust boundary or proxy validation:\n      - `let remote_addr = header.get(\"x-forwarded-for\").and_then(...).or_else(|| header.get(\"x-real-ip\")...).unwrap_or(\"127.0.0.1\");`\n      - `args.insert(\"SourceIp\", vec![get_source_ip_raw(header, remote_addr)]);`\n  - This value feeds IAM/bucket policy evaluation in `rustfs/src/storage/access.rs` (authorization path), so any request that forges the header can meet `aws:SourceIp` conditions.\n  - No authentication is required beyond the request itself; the header is taken at face value even on direct connections.\n\n\n### PoC\n\n[rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz](https://github.com/user-attachments/files/24038162/rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz)\n\n\nSteps (already included in `rustfs-auth-trusted-ip-header-spoofing-poc/`):\n\n  1. Start RustFS with two local volumes, e.g.:\n\n```\n     mkdir -p /tmp/rustfs-data1 /tmp/rustfs-data2\n     RUSTFS_ACCESS_KEY=devadmin RUSTFS_SECRET_KEY=devadmin \\\n       cargo run --bin rustfs -- --address 0.0.0.0:9000 \\\n       /tmp/rustfs-data1 /tmp/rustfs-data2\n```\n\n  2. From `rustfs-auth-trusted-ip-header-spoofing-poc`/, run:\n\n```\n     ENDPOINT=http://127.0.0.1:9000 make run\n```\n\n     The script:\n      - Creates bucket `rustfs-trusted-ip-poc`.\n      - Applies a bucket policy allowing `s3:ListBucket` only from `10.0.0.5/32` (`Principal: {\"AWS\":[\"*\"]},` Resource array).\n      - Sends three unauthenticated `ListBucket` calls:\n          - Baseline (no spoof) \u2192 HTTP 403.\n          - Spoofed `X-Forwarded-For: 10.0.0.5` \u2192 HTTP 200 (policy bypass).\n          - Spoofed `X-Forwarded-For: 1.2.3.4` \u2192 HTTP 403.\n      - Responses saved to `poc-baseline.xml`, `poc-spoofed.xml`, `poc-deny.xml`.\n\n\n### Impact\n\n  - Vulnerability type: Authorization bypass of IP-allowlist (`aws:SourceIp`) via header spoofing.\n  - Who is impacted: Any deployment relying on `aws:SourceIp` in IAM/bucket policies for S3 operations. Attackers with network reach to RustFS can forge forwarded-IP headers to gain list/read/write where IP restrictions were meant to block them.\n\n### Credits\nIdentified by SecMate (https://secmate.dev) automated analysis and validated during manual triage.",
  "id": "GHSA-fc6g-2gcp-2qrq",
  "modified": "2026-02-03T18:55:45Z",
  "published": "2026-02-03T17:31:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rustfs/rustfs/security/advisories/GHSA-fc6g-2gcp-2qrq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21862"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rustfs/rustfs/commit/b4ba62fa3300b5b258fdc0da141481e3be7ea960"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rustfs/rustfs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RustFS has SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers"
}

GHSA-FC9M-WJM7-WJ8R

Vulnerability from github – Published: 2025-01-21 18:31 – Updated: 2025-01-21 18:31
VLAI
Details

In JetBrains YouTrack before 2024.3.55417 account takeover was possible via spoofed email and Helpdesk integration

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-24458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T18:15:18Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains YouTrack before 2024.3.55417 account takeover was possible via spoofed email and Helpdesk integration",
  "id": "GHSA-fc9m-wjm7-wj8r",
  "modified": "2025-01-21T18:31:08Z",
  "published": "2025-01-21T18:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24458"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FF5C-938W-8C9Q

Vulnerability from github – Published: 2024-05-14 22:25 – Updated: 2024-11-18 16:26
VLAI
Summary
Grafana Escalation from admin to server admin when auth proxy is used
Details

Today we are releasing Grafana 9.1.6, 9.0.9, 8.5.13. This patch release includes a Moderate severity security fix for CVE-2022-35957 that affects Grafana instances which are using Grafana Auth Proxy.

Release 9.1.6, latest patch, also containing security fix:

Release 9.0.9, only containing security fix:

Release 8.5.13, only containing security fix:

Appropriate patches have been applied to Grafana Cloud and as always, we closely coordinated with all cloud providers licensed to offer Grafana Pro. They have received early notification under embargo and confirmed that their offerings are secure at the time of this announcement. This is applicable to Amazon Managed Grafana and Azure's Grafana as a service offering.

Privilege escalation (CVE-2022-35957)

Summary

On August 9 an internal security review identified a vulnerability in the Grafana which allows an escalation from Admin privileges to Server Admin when Auth proxy authentication is used.

Auth proxy allows to authenticate a user by only providing the username (or email) in a X-WEBAUTH-USER HTTP header: the trust assumption is that a front proxy will take care of authentication and that Grafana server is publicly reachable only with this front proxy.

Datasource proxy breaks this assumption: - it is possible to configure a fake datasource pointing to a localhost Grafana install with a X-WEBAUTH-USER HTTP header containing admin username. - This fake datasource can be called publicly via this proxying feature.

The CVSS score for this vulnerability is 6.6 Moderate (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H).

Impacted versions

All Grafana installations where the Auth Proxy is used.

Solutions and mitigations

To fully address CVE-2022-35957 please upgrade your Grafana instances. They are only required if you are using Auth proxy. If you can’t upgrade, as an alternative, you can deactivate the auth proxy.

Appropriate patches have been applied to Grafana Cloud.

Timeline

Here is a timeline starting from when we originally learned of the issue.

  • 2022-08-09: Vulnerability is reported as a result of an Internal security audit.
  • 2022-08-09: Release timeline determined: 2022-09-06 for private customer release, 2022-09-20 for public release.
  • 2022-08-09: Confirmed that Grafana Cloud is not impacted.
  • 2022-09-06: Private release.
  • 2022-09-20: Public release.

Reporting security issues

If you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of Grafana Labs' open source and commercial products (including, but not limited to Grafana, Grafana Cloud, Grafana Enterprise, and grafana.com). We can accept only vulnerability reports at this address. We would prefer that you encrypt your message to us by using our PGP key. The key fingerprint is

F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA

The key is available from keyserver.ubuntu.com.

Security announcements

We maintain a security category on our blog, where we will always post a summary, remediation, and mitigation details for any patch containing security fixes.

You can also subscribe to our RSS feed.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.1.0"
            },
            {
              "fixed": "9.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/grafana/grafana"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.5.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-35957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T22:25:56Z",
    "nvd_published_at": "2022-09-20T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Today we are releasing Grafana 9.1.6, 9.0.9, 8.5.13. This patch release includes a Moderate severity security fix for CVE-2022-35957 that affects Grafana instances which are using Grafana [Auth Proxy](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/auth-proxy/#configure-auth-proxy-authentication).\n\nRelease 9.1.6, latest patch, also containing security fix:\n\n- [Download Grafana 9.1.6](https://grafana.com/grafana/download/9.1.6)\n- [Release notes](https://grafana.com/docs/grafana/latest/release-notes/release-notes-9-1-6/)\n\nRelease 9.0.9, only containing security fix:\n\n- [Download Grafana 9.0.9](https://grafana.com/grafana/download/9.0.9)\n- [Release notes](https://grafana.com/docs/grafana/latest/release-notes/release-notes-9-0-9/)\n\nRelease 8.5.13, only containing security fix:\n\n- [Download Grafana 8.5.13](https://grafana.com/grafana/download/8.5.13)\n- [Release notes](https://grafana.com/docs/grafana/latest/release-notes/release-notes-8-5-13/)\n\nAppropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud) and as always, we closely coordinated with all cloud providers licensed to offer Grafana Pro. They have received early notification under embargo and confirmed that their offerings are secure at the time of this announcement. This is applicable to Amazon Managed Grafana and Azure\u0027s Grafana as a service offering.\n\n## Privilege escalation (CVE-2022-35957)\n\n### Summary \n\nOn August 9 an internal security review identified a vulnerability in the Grafana which allows an escalation from Admin privileges to Server Admin when Auth proxy authentication is used.\n\n[Auth proxy](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/auth-proxy/#configure-auth-proxy-authentication) allows to authenticate a user by only providing the username (or email) in a `X-WEBAUTH-USER` HTTP header: the trust assumption is that a front proxy will take care of authentication and that Grafana server is publicly reachable only with this front proxy.\n\n[Datasource proxy](https://grafana.com/docs/grafana/latest/developers/http_api/data_source/#data-source-proxy-calls) breaks this assumption:\n- it is possible to configure a fake datasource pointing to a localhost Grafana install with a `X-WEBAUTH-USER` HTTP header containing admin username.\n- This fake datasource can be called publicly via this proxying feature.\n\nThe CVSS score for this vulnerability is 6.6 Moderate (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H).\n\n### Impacted versions\n\nAll Grafana installations where the [Auth Proxy](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/auth-proxy/#configure-auth-proxy-authentication) is used.\n\n### Solutions and mitigations\n\nTo fully address CVE-2022-35957 please upgrade your Grafana instances. They are only required if you are using Auth proxy. If you can\u2019t upgrade, as an alternative, you can deactivate the auth proxy. \n\nAppropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud).\n\n### Timeline\n\nHere is a timeline starting from when we originally learned of the issue. \n\n* 2022-08-09: Vulnerability is reported as a result of an Internal security audit.\n* 2022-08-09: Release timeline determined: 2022-09-06 for private customer release, 2022-09-20 for public release.\n* 2022-08-09: Confirmed that Grafana Cloud is not impacted.\n* 2022-09-06: Private release.\n* 2022-09-20: Public release.\n\n## Reporting security issues\n\nIf you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of Grafana Labs\u0027 open source and commercial products (including, but not limited to Grafana, Grafana Cloud, Grafana Enterprise, and grafana.com). We can accept only vulnerability reports at this address. We would prefer that you encrypt your message to us by using our PGP key. The key fingerprint is\n\nF988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA\n\nThe key is available from keyserver.ubuntu.com.\n\n## Security announcements\n\nWe maintain a [security category](https://community.grafana.com/c/support/security-announcements) on our blog, where we will always post a summary, remediation, and mitigation details for any patch containing security fixes.\n\nYou can also subscribe to our [RSS feed](https://grafana.com/tags/security/index.xml).",
  "id": "GHSA-ff5c-938w-8c9q",
  "modified": "2024-11-18T16:26:41Z",
  "published": "2024-05-14T22:25:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grafana/grafana/security/advisories/GHSA-ff5c-938w-8c9q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35957"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grafana/grafana"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WYU5C2RITLHVZSTCWNGQWA6KSPYNXM2H"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221215-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Grafana Escalation from admin to server admin when auth proxy is used"
}

GHSA-FF9C-4G39-VVCF

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30
VLAI
Details

Microsoft Edge (Chromium-based) for Android Spoofing Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-451"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:18:06Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge (Chromium-based) for Android Spoofing Vulnerability",
  "id": "GHSA-ff9c-4g39-vvcf",
  "modified": "2026-03-16T15:30:41Z",
  "published": "2026-03-16T15:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0385"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-0385"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FFG9-J72F-J6XM

Vulnerability from github – Published: 2026-05-14 13:13 – Updated: 2026-06-08 23:26
VLAI
Summary
Fleet Windows MDM Azure AD JWT Authentication Bypass
Details

Summary

A vulnerability in Fleet's Windows MDM enrollment flow allows authentication tokens from any Azure AD tenant to be accepted. Because Fleet validates JWT signatures using Microsoft's multi-tenant JWKS endpoint but does not enforce the aud (audience) or iss (issuer) claims, any Microsoft-signed Azure AD access token containing the expected scopes can be used to authenticate to Fleet's MDM endpoints.

Impact

If Windows MDM is enabled, an attacker with access to any Azure AD tenant can obtain a valid Microsoft-signed token and use it to enroll unauthorized devices and interact with Fleet's MDM management APIs. During device management, Fleet may expose sensitive enrollment secrets embedded in MDM command payloads, enabling further unauthorized access.

Workarounds

If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM.

For more information

If you have any questions or comments about this advisory: Email us at security@fleetdm.com Join #fleet in osquery Slack

Credits

We thank @zaddy6 for responsibly reporting this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fleetdm/fleet/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.82.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T13:13:56Z",
    "nvd_published_at": "2026-05-14T20:17:01Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA vulnerability in Fleet\u0027s Windows MDM enrollment flow allows authentication tokens from any Azure AD tenant to be accepted. Because Fleet validates JWT signatures using Microsoft\u0027s multi-tenant JWKS endpoint but does not enforce the `aud` (audience) or `iss` (issuer) claims, any Microsoft-signed Azure AD access token containing the expected scopes can be used to authenticate to Fleet\u0027s MDM endpoints.\n\n### Impact\n\nIf Windows MDM is enabled, an attacker with access to any Azure AD tenant can obtain a valid Microsoft-signed token and use it to enroll unauthorized devices and interact with Fleet\u0027s MDM management APIs. During device management, Fleet may expose sensitive enrollment secrets embedded in MDM command payloads, enabling further unauthorized access.\n\n### Workarounds\n\nIf an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\nEmail us at [security@fleetdm.com](mailto:security@fleetdm.com)\nJoin #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)\n\n### Credits\n\nWe thank @zaddy6 for responsibly reporting this issue.",
  "id": "GHSA-ffg9-j72f-j6xm",
  "modified": "2026-06-08T23:26:12Z",
  "published": "2026-05-14T13:13:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-ffg9-j72f-j6xm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24899"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fleetdm/fleet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fleetdm/fleet/releases/tag/fleet-v4.82.0"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fleet Windows MDM Azure AD JWT Authentication Bypass"
}

GHSA-FFPG-W7V7-GMRP

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2023-02-15 03:30
VLAI
Details

A security vulnerability exists in Zingbox Inspector versions 1.294 and earlier, that allows for the Inspector to be susceptible to ARP spoofing.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-09T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A security vulnerability exists in Zingbox Inspector versions 1.294 and earlier, that allows for the Inspector to be susceptible to ARP spoofing.",
  "id": "GHSA-ffpg-w7v7-gmrp",
  "modified": "2023-02-15T03:30:26Z",
  "published": "2022-05-24T16:58:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15022"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2019-15022"
    },
    {
      "type": "WEB",
      "url": "https://securityadvisories.paloaltonetworks.com/Home/Detail/191"
    }
  ],
  "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"
    }
  ]
}

GHSA-FGMG-8V8R-JJ8G

Vulnerability from github – Published: 2024-05-22 18:30 – Updated: 2024-05-22 18:30
VLAI
Details

Multiple Cisco products are affected by a vulnerability in the Snort Intrusion Prevention System (IPS) rule engine that could allow an unauthenticated, remote attacker to bypass the configured rules on an affected system. This vulnerability is due to incorrect HTTP packet handling. An attacker could exploit this vulnerability by sending crafted HTTP packets through an affected device. A successful exploit could allow the attacker to bypass configured IPS rules and allow uninspected traffic onto the network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T17:16:13Z",
    "severity": "MODERATE"
  },
  "details": "Multiple Cisco products are affected by a vulnerability in the Snort Intrusion Prevention System (IPS) rule engine that could allow an unauthenticated, remote attacker to bypass the configured rules on an affected system. This vulnerability is due to incorrect HTTP packet handling. An attacker could exploit this vulnerability by sending crafted HTTP packets through an affected device. A successful exploit could allow the attacker to bypass configured IPS rules and allow uninspected traffic onto the network.",
  "id": "GHSA-fgmg-8v8r-jj8g",
  "modified": "2024-05-22T18:30:42Z",
  "published": "2024-05-22T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20363"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort3-ips-bypass-uE69KBMd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FJFC-7X5G-G52W

Vulnerability from github – Published: 2026-07-17 03:31 – Updated: 2026-07-17 03:31
VLAI
Details

OpenClaw MS Teams before 2026.5.12 contain an authorization bypass vulnerability where the allowFrom feature binds to mutable display names. Attackers with lower-trust access can perform actions requiring stronger authorization by exploiting the mutable display name binding in the affected feature.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-62224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T02:18:09Z",
    "severity": "LOW"
  },
  "details": "OpenClaw MS Teams before 2026.5.12 contain an authorization bypass vulnerability where the allowFrom feature binds to mutable display names. Attackers with lower-trust access can perform actions requiring stronger authorization by exploiting the mutable display name binding in the affected feature.",
  "id": "GHSA-fjfc-7x5g-g52w",
  "modified": "2026-07-17T03:31:23Z",
  "published": "2026-07-17T03:31:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7w4v-g4m6-j88v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62224"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-ms-teams-authorization-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FJQ7-JR7J-JH92

Vulnerability from github – Published: 2024-07-08 15:31 – Updated: 2024-07-08 15:31
VLAI
Details

Certain http endpoints of Checkmk in Checkmk < 2.3.0p10 < 2.2.0p31, < 2.1.0p46, <= 2.0.0p39 allows remote attacker to bypass authentication and access data

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-6163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-08T13:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Certain http endpoints of Checkmk in Checkmk \u003c 2.3.0p10 \u003c 2.2.0p31, \u003c 2.1.0p46, \u003c= 2.0.0p39 allows remote attacker to bypass authentication and access data",
  "id": "GHSA-fjq7-jr7j-jh92",
  "modified": "2024-07-08T15:31:56Z",
  "published": "2024-07-08T15:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6163"
    },
    {
      "type": "WEB",
      "url": "https://checkmk.com/werk/17011"
    }
  ],
  "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-FP52-QW33-MFMW

Vulnerability from github – Published: 2021-08-02 17:11 – Updated: 2023-08-29 22:39
VLAI
Summary
Authentication Bypass by Spoofing and Insufficient Verification of Data Authenticity in Hashicorp Vault
Details

HashiCorp Vault and Vault Enterprise versions 0.7.1 and newer, when configured with the AWS IAM auth method, may be vulnerable to authentication bypass. Fixed in 1.2.5, 1.3.8, 1.4.4, and 1.5.1..

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.1"
            },
            {
              "fixed": "1.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/vault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-16250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-26T18:55:09Z",
    "nvd_published_at": "2020-08-26T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "HashiCorp Vault and Vault Enterprise versions 0.7.1 and newer, when configured with the AWS IAM auth method, may be vulnerable to authentication bypass. Fixed in 1.2.5, 1.3.8, 1.4.4, and 1.5.1..",
  "id": "GHSA-fp52-qw33-mfmw",
  "modified": "2023-08-29T22:39:27Z",
  "published": "2021-08-02T17:11:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16250"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hashicorp/vault"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#151"
    },
    {
      "type": "WEB",
      "url": "https://www.hashicorp.com/blog/category/vault"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/159478/Hashicorp-Vault-AWS-IAM-Integration-Authentication-Bypass.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authentication Bypass by Spoofing and Insufficient Verification of Data Authenticity in Hashicorp Vault"
}

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.