CWE-287

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-08-24T19:13:41.074Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/08/24/12"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 7.5,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "NONE",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-66908",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-25T19:38:05.072472Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-25T19:38:28.088Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-platform-http-main",
          "packageURL": "pkg:maven/org.apache.camel/camel-platform-http-main",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.22.0",
              "status": "affected",
              "version": "4.8.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "n0mi1k"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Authentication vulnerability in Apache Camel Platform HTTP Main component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.8.0 before 4.22.0.\u003c/p\u003e\u003cp\u003eThe camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed.\u003c/p\u003e\u003cp\u003eNotes:\u003c/p\u003e\u003cp\u003eThe JIRA ticket:\u0026nbsp;\u003ca href=\"https://issues.apache.org/jira/browse/CAMEL-24281\" rel=\"noopener nofollow noreferrer\"\u003ehttps://issues.apache.org/jira/browse/CAMEL-24281\u003c/a\u003e\u0026nbsp;refers to the various commits that resolved the issue, and has more details.\u003c/p\u003e\u003cp\u003eThe fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available.\u0026nbsp;\u003c/p\u003e"
            }
          ],
          "value": "Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.\n\n\n\nThis issue affects Apache Camel: from 4.8.0 before 4.22.0.\n\n\n\nThe camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all.\n\n\n\nUsers are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed.\n\n\n\nNotes:\n\n\n\nThe JIRA ticket:\u00a0 https://issues.apache.org/jira/browse/CAMEL-24281 \u00a0refers to the various commits that resolved the issue, and has more details.\n\n\n\nThe fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual severity rating"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-24T16:14:18.202Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-66908.html"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-platform-http-main: when JWT authentication was configured with a keystore but no issuer or audience, the iss and aud claims were never validated, so any unexpired token signed by a trusted key was accepted",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-66908",
    "datePublished": "2026-08-24T16:14:18.202Z",
    "dateReserved": "2026-07-28T09:33:04.800Z",
    "dateUpdated": "2026-08-25T19:38:28.088Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-66014",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-27T20:15:11.976218Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-27T20:15:18.293Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "artifactory",
          "vendor": "jfrog",
          "versions": [
            {
              "lessThan": "7.111.18",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            },
            {
              "lessThan": "7.117.25",
              "status": "affected",
              "version": "7.117.0",
              "versionType": "custom"
            },
            {
              "lessThan": "7.125.18",
              "status": "affected",
              "version": "7.125.0",
              "versionType": "custom"
            },
            {
              "lessThan": "7.133.27",
              "status": "affected",
              "version": "7.133.0",
              "versionType": "custom"
            },
            {
              "lessThan": "7.146.34",
              "status": "affected",
              "version": "7.146.0",
              "versionType": "custom"
            },
            {
              "lessThan": "7.161.15",
              "status": "affected",
              "version": "7.161.0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Amy Burnett | OpenAI"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "JFrog Artifactory contains an authentication handling weakness in internal request processing that, under specific conditions, may allow an attacker to escalate privileges beyond the intended access level.\u003cbr\u003e"
            }
          ],
          "value": "JFrog Artifactory contains an authentication handling weakness in internal request processing that, under specific conditions, may allow an attacker to escalate privileges beyond the intended access level."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-27T19:29:47.318Z",
        "orgId": "48a46f29-ae42-4e1d-90dd-c1676c1e5e6d",
        "shortName": "JFROG"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://docs.jfrog.com/releases/docs/jfrog-security-advisories"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Potential authentication bypass leading to privilege escalation in Artifactory",
      "x_generator": {
        "engine": "Vulnogram 1.0.4"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "48a46f29-ae42-4e1d-90dd-c1676c1e5e6d",
    "assignerShortName": "JFROG",
    "cveId": "CVE-2026-66014",
    "datePublished": "2026-07-27T19:29:47.318Z",
    "dateReserved": "2026-07-23T19:59:51.587Z",
    "dateUpdated": "2026-07-27T20:15:18.293Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-65633",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-25T19:49:03.433221Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-25T19:49:22.437Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
          ],
          "packageName": "ash_authentication",
          "packageURL": "pkg:hex/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/plug/helpers.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:retrieve_from_bearer/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "4.14.2",
              "status": "affected",
              "version": "3.10.5",
              "versionType": "semver"
            },
            {
              "lessThan": "5.0.0-rc.13",
              "status": "affected",
              "version": "5.0.0-rc.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027"
          ],
          "packageName": "team-alembic/ash_authentication",
          "packageURL": "pkg:github/team-alembic/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/plug/helpers.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Plug.Helpers\u0027:retrieve_from_bearer/3"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "changes": [
                {
                  "at": "8cf8b2d4426172be0900a3505e9491800b951750",
                  "status": "unaffected"
                },
                {
                  "at": "124eddd1bbeb40289c3fe8831ac10677a19fcf09",
                  "status": "unaffected"
                }
              ],
              "lessThan": "*",
              "status": "affected",
              "version": "eca8cadea0f1595ed2c10a0c177b1da9aa9e5269",
              "versionType": "git"
            }
          ]
        }
      ],
      "configurations": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe bypass is reachable only when a resource uses stateless bearer-token verification, i.e. \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e is \u003ccode\u003efalse\u003c/code\u003e (the DSL default). In that mode \u003ccode\u003evalidate_token/3\u003c/code\u003e returns \u003ccode\u003e{:ok, nil}\u003c/code\u003e without consulting the token resource, so the JWT\u0027s \u003ccode\u003epurpose\u003c/code\u003e claim is the only remaining scoping signal at the bearer boundary and it is never checked. When \u003ccode\u003erequire_token_presence_for_authentication?\u003c/code\u003e is \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003evalidate_token/3\u003c/code\u003e looks the token up with \u003ccode\u003eget_token(%{\"jti\" =\u0026gt; jti, \"purpose\" =\u0026gt; \"user\"})\u003c/code\u003e; purpose-limited tokens are stored under their own purpose (\u003ccode\u003esign_in\u003c/code\u003e, \u003ccode\u003eremember_me\u003c/code\u003e, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to \u003ccode\u003erequire_token_presence_for_authentication?: true\u003c/code\u003e and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\u003c/p\u003e\n\u003cp\u003eExploitation additionally requires the host application to wire up \u003ccode\u003eAshAuthentication.Plug.Helpers.retrieve_from_bearer/3\u003c/code\u003e on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable \u003ccode\u003esub\u003c/code\u003e claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with \u003ccode\u003esign_in_tokens_enabled?: true\u003c/code\u003e. The session-based path (\u003ccode\u003eauthenticate_resource_from_session/4\u003c/code\u003e) already enforces \u003ccode\u003epurpose == \"user\"\u003c/code\u003e against the token resource and is not affected.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. `require_token_presence_for_authentication?` is `false` (the DSL default). In that mode `validate_token/3` returns `{:ok, nil}` without consulting the token resource, so the JWT\u0027s `purpose` claim is the only remaining scoping signal at the bearer boundary and it is never checked. When `require_token_presence_for_authentication?` is `true`, `validate_token/3` looks the token up with `get_token(%{\"jti\" =\u003e jti, \"purpose\" =\u003e \"user\"})`; purpose-limited tokens are stored under their own purpose (`sign_in`, `remember_me`, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to `require_token_presence_for_authentication?: true` and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\n\nExploitation additionally requires the host application to wire up `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable `sub` claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with `sign_in_tokens_enabled?: true`. The session-based path (`authenticate_resource_from_session/4`) already enforces `purpose == \"user\"` against the token resource and is not affected."
            }
          ],
          "value": "The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT\u0027s purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{\"jti\" =\u003e jti, \"purpose\" =\u003e \"user\"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.\n\nExploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == \"user\" against the token resource and is not affected."
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.2",
                  "versionStartIncluding": "3.10.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.0.0-rc.13",
                  "versionStartIncluding": "5.0.0-rc.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "EQSTLab"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "James Harton"
        },
        {
          "lang": "en",
          "type": "coordinator",
          "value": "Jonatan M\u00e4nnchen / EEF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\u003c/p\u003e\n\u003cp\u003eThe bearer-token authentication helper \u003ccode\u003eAshAuthentication.Plug.Helpers.retrieve_from_bearer/3\u003c/code\u003e verifies an \u003ccode\u003eAuthorization: Bearer\u003c/code\u003e JWT\u0027s signature and rejects tokens containing an \u003ccode\u003eact\u003c/code\u003e claim, but performs no check that the token\u0027s \u003ccode\u003epurpose\u003c/code\u003e claim equals \u003ccode\u003euser\u003c/code\u003e at the bearer boundary. When the resource is configured with \u003ccode\u003erequire_token_presence_for_authentication?: false\u003c/code\u003e (the DSL default), the follow-on \u003ccode\u003evalidate_token/3\u003c/code\u003e helper returns \u003ccode\u003e{:ok, nil}\u003c/code\u003e without consulting the token resource, so no downstream check on \u003ccode\u003epurpose\u003c/code\u003e takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the \u003ccode\u003epurpose: sign_in\u003c/code\u003e token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full \u003ccode\u003ecurrent_user\u003c/code\u003e assignment.\u003c/p\u003e\n\u003cp\u003eThis bypasses the library\u0027s intended token-exchange contract, in which the \u003ccode\u003esign_in\u003c/code\u003e token is meant to be presented exactly once to a preparation that validates the \u003ccode\u003epurpose\u003c/code\u003e claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the \u003ccode\u003eAuthorization\u003c/code\u003e header succeeds because the stateless bearer path never scopes it to \u003ccode\u003epurpose == \"user\"\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up \u003ccode\u003eretrieve_from_bearer/3\u003c/code\u003e on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with \u003ccode\u003esign_in_tokens_enabled?: true\u003c/code\u003e. Resources configured with \u003ccode\u003erequire_token_presence_for_authentication?: true\u003c/code\u003e (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (\u003ccode\u003eauthenticate_resource_from_session/4\u003c/code\u003e) enforce \u003ccode\u003epurpose == \"user\"\u003c/code\u003e against the stored token record and are not affected.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\n\nThe bearer-token authentication helper `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifies an `Authorization: Bearer` JWT\u0027s signature and rejects tokens containing an `act` claim, but performs no check that the token\u0027s `purpose` claim equals `user` at the bearer boundary. When the resource is configured with `require_token_presence_for_authentication?: false` (the DSL default), the follow-on `validate_token/3` helper returns `{:ok, nil}` without consulting the token resource, so no downstream check on `purpose` takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the `purpose: sign_in` token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full `current_user` assignment.\n\nThis bypasses the library\u0027s intended token-exchange contract, in which the `sign_in` token is meant to be presented exactly once to a preparation that validates the `purpose` claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the `Authorization` header succeeds because the stateless bearer path never scopes it to `purpose == \"user\"`.\n\nAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up `retrieve_from_bearer/3` on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with `sign_in_tokens_enabled?: true`. Resources configured with `require_token_presence_for_authentication?: true` (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (`authenticate_resource_from_session/4`) enforce `purpose == \"user\"` against the stored token record and are not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
            }
          ],
          "value": "Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.\n\nThe bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT\u0027s signature and rejects tokens containing an act claim, but performs no check that the token\u0027s purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.\n\nThis bypasses the library\u0027s intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == \"user\".\n\nAn attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == \"user\" against the stored token record and are not affected.\n\nThis issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-21",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-21 Exploitation of Trusted Identifiers"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.6,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-25T08:03:51.846Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-6vcj-3h59-rrc3"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-65633.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-65633"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/8cf8b2d4426172be0900a3505e9491800b951750"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/124eddd1bbeb40289c3fe8831ac10677a19fcf09"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Purpose-limited JWT accepted as full bearer authentication in AshAuthentication"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-65633",
    "datePublished": "2026-08-25T08:03:51.846Z",
    "dateReserved": "2026-07-22T13:58:26.233Z",
    "dateUpdated": "2026-08-25T19:49:22.437Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-65211",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-11-04T14:52:42.359980Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-11-04T14:58:56.362Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "affected",
          "platforms": [
            "BMC"
          ],
          "product": "MBD-X12SPI",
          "vendor": "SMCI",
          "versions": [
            {
              "status": "affected",
              "version": "01.07.20",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "runZero"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "This issue may allow an authenticated IPMI Administrator to read and write arbitrary BMC physical memory and thereby execute code on the BMC operating system."
            }
          ],
          "value": "This issue may allow an authenticated IPMI Administrator to read and write arbitrary BMC physical memory and thereby execute code on the BMC operating system."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-233",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-233: Privilege Escalation"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "HIGH",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T08:12:15.451Z",
        "orgId": "def9a96e-e099-41a9-bfac-30fd4f82c411",
        "shortName": "Supermicro"
      },
      "references": [
        {
          "url": "https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2026_1"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Supermicro BMC IPMI  feature contains Critical Privilege Escalation and Arbitrary Access vulnerability",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "def9a96e-e099-41a9-bfac-30fd4f82c411",
    "assignerShortName": "Supermicro",
    "cveId": "CVE-2026-65211",
    "datePublished": "2026-10-27T08:12:15.451Z",
    "dateReserved": "2026-07-21T20:14:39.682Z",
    "dateUpdated": "2026-11-04T14:58:56.362Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-65121",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-22T15:27:31.252287Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-22T15:27:42.843Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Linux"
          ],
          "product": "Infrastructure Controller",
          "vendor": "NVIDIA",
          "versions": [
            {
              "status": "affected",
              "version": "0 to 1.9"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "NVIDIA Infrastructure Controller for Linux contains a vulnerability where an  attacker could cause an improper authentication issue. A successful exploit of this vulnerability might lead to escalation of privileges, information disclosure, and data tampering."
            }
          ],
          "value": "NVIDIA Infrastructure Controller for Linux contains a vulnerability where an  attacker could cause an improper authentication issue. A successful exploit of this vulnerability might lead to escalation of privileges, information disclosure, and data tampering."
        }
      ],
      "impacts": [
        {
          "descriptions": [
            {
              "lang": "en",
              "value": "escalation of privileges, data tampering, information disclosure"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "ADJACENT_NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-22T14:10:22.711Z",
        "orgId": "9576f279-3576-44b5-a4af-b9a8644b2de6",
        "shortName": "nvidia"
      },
      "references": [
        {
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65121"
        },
        {
          "url": "https://www.cve.org/CVERecord?id=CVE-2026-65121"
        },
        {
          "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5879"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "x_generator": {
        "engine": "NVIDIA PSIRT"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "9576f279-3576-44b5-a4af-b9a8644b2de6",
    "assignerShortName": "nvidia",
    "cveId": "CVE-2026-65121",
    "datePublished": "2026-09-22T14:10:22.711Z",
    "dateReserved": "2026-07-21T17:12:33.431Z",
    "dateUpdated": "2026-09-22T15:27:42.843Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-64665",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-07T15:26:57.594364Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-07T17:09:33.394Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "cms",
          "vendor": "statamic",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 5.74.1"
            },
            {
              "status": "affected",
              "version": "\u003e= 6.0.0, \u003c 6.24.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Statamic is a Laravel and Git powered content management system (CMS). Prior to 5.74.1 and 6.24.0, when OAuth login was enabled with a provider that does not guarantee verified email addresses, an unauthenticated attacker could sign in as an existing user, potentially including a super admin, without knowing that user\u0027s password, because the application matched OAuth identities to accounts by email address alone. Exploitation requires OAuth to be explicitly enabled with such a provider. This issue is fixed in versions 5.74.1 and 6.24.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-06T19:25:01.756Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/statamic/cms/security/advisories/GHSA-93qh-5269-9wcf",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/statamic/cms/security/advisories/GHSA-93qh-5269-9wcf"
        },
        {
          "name": "https://github.com/statamic/cms/pull/14887",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/statamic/cms/pull/14887"
        },
        {
          "name": "https://github.com/statamic/cms/commit/e59dd342c83bc45de26573cfb0536a0bca98255a",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/statamic/cms/commit/e59dd342c83bc45de26573cfb0536a0bca98255a"
        },
        {
          "name": "https://github.com/statamic/cms/releases/tag/v5.74.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/statamic/cms/releases/tag/v5.74.1"
        },
        {
          "name": "https://github.com/statamic/cms/releases/tag/v6.24.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/statamic/cms/releases/tag/v6.24.0"
        }
      ],
      "source": {
        "advisory": "GHSA-93qh-5269-9wcf",
        "discovery": "UNKNOWN"
      },
      "title": "Statamic: Account takeover via OAuth email matching without email-verification check"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-64665",
    "datePublished": "2026-08-06T19:25:01.756Z",
    "dateReserved": "2026-07-20T17:11:30.897Z",
    "dateUpdated": "2026-08-07T17:09:33.394Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-63472",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T15:20:50.486756Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T15:21:11.192Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "vendure",
          "vendor": "vendurehq",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.7.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Vendure is an open-source headless commerce platform. Prior to 3.7.0, ExternalAuthenticationService.createCustomerAndUser in packages/core/src/service/helpers/external-authentication/external-authentication.service.ts selects an existing customer user by emailAddress and attaches a newly presented ExternalAuthenticationMethod without requiring verified to be true. In deployments with a custom external AuthenticationStrategy that forwards an email whose ownership the provider has not verified, an attacker can authenticate with a victim\u0027s email and bind the attacker\u0027s external identity to the victim\u0027s existing account. This can expose orders, addresses, and personal information and permit account changes or orders as the victim. Native-only email and password deployments and external strategies that always require provider-verified email ownership are unaffected, and new-account creation for an unused email remains permitted. This issue is fixed in version 3.7.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-17T14:40:31.353Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4"
        },
        {
          "name": "https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485"
        },
        {
          "name": "https://github.com/vendurehq/vendure/releases/tag/v3.7.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vendurehq/vendure/releases/tag/v3.7.0"
        }
      ],
      "source": {
        "advisory": "GHSA-6j36-r6pr-59x4",
        "discovery": "UNKNOWN"
      },
      "title": "Vendure: External-authentication account takeover: external login linked to a pre-existing account by email without verification"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63472",
    "datePublished": "2026-09-17T14:40:31.353Z",
    "dateReserved": "2026-07-16T21:37:45.769Z",
    "dateUpdated": "2026-09-17T15:21:11.192Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-63439",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-11-09T13:20:03.819595Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-11-09T13:20:36.761Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/Bubka/2FAuth/security/advisories/GHSA-mh8r-74x2-r457"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "2FAuth",
          "vendor": "Bubka",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 8.0.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard is enabled, ReverseProxyGuard::user() reads the default REMOTE_USER identity header, or a custom identity header selected by the AUTH_PROXY_HEADER_FOR_USER configuration setting, without confirming that the request originated from a configured trusted proxy. A remote client that can reach the application directly can forge the selected identity header and authenticate as an existing user, including an administrator, gaining access to stored 2FA secrets and account or application management functions. This issue is fixed in version 8.0.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-06T20:22:31.651Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Bubka/2FAuth/security/advisories/GHSA-mh8r-74x2-r457",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Bubka/2FAuth/security/advisories/GHSA-mh8r-74x2-r457"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/commit/43873cbfba445926c7008b4291eeee67752af9e8",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/commit/43873cbfba445926c7008b4291eeee67752af9e8"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/releases/tag/v8.0.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/releases/tag/v8.0.0"
        }
      ],
      "source": {
        "advisory": "GHSA-mh8r-74x2-r457",
        "discovery": "UNKNOWN"
      },
      "title": "2FAuth: Reverse Proxy Guard Trusts Client-Supplied Headers Without Proxy Verification"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63439",
    "datePublished": "2026-11-06T20:22:31.651Z",
    "dateReserved": "2026-07-16T19:35:57.767Z",
    "dateUpdated": "2026-11-09T13:20:36.761Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "2FAuth",
          "vendor": "Bubka",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 8.0.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard accepts authentication headers from a client that did not pass through a trusted proxy, RemoteUserProvider::retrieveById() creates an account for an unknown REMOTE_USER, promotes the first created account to administrator, and synchronizes the account email from the configured mail header. An unauthenticated remote client can therefore create an administrator on a fresh instance or impersonate and redirect email for a known account, exposing 2FA secrets and administrative functions. This issue is fixed in version 8.0.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-06T20:20:27.407Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Bubka/2FAuth/security/advisories/GHSA-r9xx-45m8-mw24",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Bubka/2FAuth/security/advisories/GHSA-r9xx-45m8-mw24"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/commit/43873cbfba445926c7008b4291eeee67752af9e8",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/commit/43873cbfba445926c7008b4291eeee67752af9e8"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/commit/8a4c395cac97f8b70b4a822639a6ad8a816f927c",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/commit/8a4c395cac97f8b70b4a822639a6ad8a816f927c"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/commit/d9e58ac4a63fbd8a073e423567881c81a87915de",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/commit/d9e58ac4a63fbd8a073e423567881c81a87915de"
        },
        {
          "name": "https://github.com/Bubka/2FAuth/releases/tag/v8.0.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Bubka/2FAuth/releases/tag/v8.0.0"
        }
      ],
      "source": {
        "advisory": "GHSA-r9xx-45m8-mw24",
        "discovery": "UNKNOWN"
      },
      "title": "2FAuth: Reverse Proxy Guard Auto-Creates Users With Admin Promotion From Unauthenticated Header Value"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63438",
    "datePublished": "2026-11-06T20:20:27.407Z",
    "dateReserved": "2026-07-16T19:35:57.767Z",
    "dateUpdated": "2026-11-06T20:20:27.407Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-63398",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-11-02T17:09:34.942380Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-11-02T17:56:56.369Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "coop",
          "vendor": "roostorg",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.0.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Coop is an open source review and moderation tool from ROOST. Prior to 1.0.2, the SAML strategy\u0027s verify callback resolved the authenticated user by email alone using `kyselyUserFindByEmail`, without binding the lookup to the organization in `/saml/login/:orgId/callback`. An attacker who administers an organization and controls its SAML IdP signing key can submit an assertion for a victim email to another organization\u0027s callback when that target organization has registered the same signing certificate. The assertion verifies against the target certificate, and the email resolves to the target user, creating a session as that user and allowing full cross-tenant account takeover without privileges in the target organization. Exploitation requires the unusual configuration in which the target certificate matches a signing key controlled by the attacker. This issue is fixed in version 1.0.2."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7.4,
            "baseSeverity": "HIGH",
            "privilegesRequired": "HIGH",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T22:44:43.092Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/roostorg/coop/security/advisories/GHSA-2v93-383c-9fw2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/roostorg/coop/security/advisories/GHSA-2v93-383c-9fw2"
        },
        {
          "name": "https://github.com/roostorg/coop/pull/783",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/roostorg/coop/pull/783"
        },
        {
          "name": "https://github.com/roostorg/coop/commit/d1be81b6b33abc1162ee6b9952d4bd1ca761b071",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/roostorg/coop/commit/d1be81b6b33abc1162ee6b9952d4bd1ca761b071"
        },
        {
          "name": "https://github.com/roostorg/coop/releases/tag/1.0.2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/roostorg/coop/releases/tag/1.0.2"
        }
      ],
      "source": {
        "advisory": "GHSA-2v93-383c-9fw2",
        "discovery": "UNKNOWN"
      },
      "title": "Coop has SAML cross-tenant authentication bypass"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-63398",
    "datePublished": "2026-10-30T22:44:43.092Z",
    "dateReserved": "2026-07-16T19:20:28.986Z",
    "dateUpdated": "2026-11-02T17:56:56.369Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}