CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
6346 vulnerabilities reference this CWE, most recent first.
CVE-2026-66908 (GCVE-0-2026-66908)
Vulnerability from cvelistv5 – Published: 2026-08-24 16:14 – Updated: 2026-08-25 19:38- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://camel.apache.org/security/CVE-2026-66908.html | vendor-advisory |
| http://www.openwall.com/lists/oss-security/2026/0… |
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Camel |
Affected:
4.8.0 , < 4.22.0
(semver)
|
{
"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"
}
CVE-2026-66014 (GCVE-0-2026-66014)
Vulnerability from cvelistv5 – Published: 2026-07-27 19:29 – Updated: 2026-07-27 20:15- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://docs.jfrog.com/releases/docs/jfrog-securi… | vendor-advisory |
| https://docs.jfrog.com/releases/docs/artifactory-… | vendor-advisory |
| Vendor | Product | Version | |
|---|---|---|---|
| jfrog | artifactory |
Affected:
0 , < 7.111.18
(custom)
Affected: 7.117.0 , < 7.117.25 (custom) Affected: 7.125.0 , < 7.125.18 (custom) Affected: 7.133.0 , < 7.133.27 (custom) Affected: 7.146.0 , < 7.146.34 (custom) Affected: 7.161.0 , < 7.161.15 (custom) |
{
"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"
}
CVE-2026-65633 (GCVE-0-2026-65633)
Vulnerability from cvelistv5 – Published: 2026-08-25 08:03 – Updated: 2026-08-25 19:49- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://github.com/team-alembic/ash_authenticatio… | vendor-advisoryrelated |
| https://cna.erlef.org/cves/CVE-2026-65633.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-65633 | related |
| https://github.com/team-alembic/ash_authenticatio… | patch |
| https://github.com/team-alembic/ash_authenticatio… | patch |
| Vendor | Product | Version | |
|---|---|---|---|
| team-alembic | ash_authentication |
Affected:
3.10.5 , < 4.14.2
(semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.13 (semver) cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
|
| team-alembic | ash_authentication |
Affected:
eca8cadea0f1595ed2c10a0c177b1da9aa9e5269 , < *
(git)
cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* |
{
"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"
}
CVE-2026-64665 (GCVE-0-2026-64665)
Vulnerability from cvelistv5 – Published: 2026-08-06 19:25 – Updated: 2026-08-07 17:09| URL | Tags |
|---|---|
| https://github.com/statamic/cms/security/advisori… | x_refsource_CONFIRM |
| https://github.com/statamic/cms/pull/14887 | x_refsource_MISC |
| https://github.com/statamic/cms/commit/e59dd342c8… | x_refsource_MISC |
| https://github.com/statamic/cms/releases/tag/v5.74.1 | x_refsource_MISC |
| https://github.com/statamic/cms/releases/tag/v6.24.0 | x_refsource_MISC |
{
"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"
}
CVE-2026-62896 (GCVE-0-2026-62896)
Vulnerability from cvelistv5 – Published: 2026-08-06 22:37 – Updated: 2026-08-29 16:20 Exclusively Hosted Service- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://msrc.microsoft.com/update-guide/vulnerabi… | vendor-advisorypatch |
| Vendor | Product | Version | |
|---|---|---|---|
| Microsoft | Microsoft Teams |
Affected:
-
cpe:2.3:a:microsoft:teams:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-62896",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-06T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T03:56:05.040Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Microsoft Teams",
"vendor": "Microsoft",
"versions": [
{
"status": "affected",
"version": "-"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:microsoft:teams:*:*:*:*:*:*:*:*",
"versionStartIncluding": "-",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"datePublic": "2026-08-06T14:00:00.000Z",
"descriptions": [
{
"lang": "en-US",
"value": "Improper authentication in Microsoft Teams allows an authorized attacker to elevate privileges over a network."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 9.6,
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N/E:U/RL:O/RC:C",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en-US",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en-US",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-29T16:20:55.724Z",
"orgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"shortName": "microsoft"
},
"references": [
{
"name": "Microsoft Teams Elevation of Privilege Vulnerability",
"tags": [
"vendor-advisory",
"patch"
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62896"
}
],
"tags": [
"exclusively-hosted-service"
],
"title": "Microsoft Teams Elevation of Privilege Vulnerability"
}
},
"cveMetadata": {
"assignerOrgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"assignerShortName": "microsoft",
"cveId": "CVE-2026-62896",
"datePublished": "2026-08-06T22:37:35.575Z",
"dateReserved": "2026-07-14T21:25:21.034Z",
"dateUpdated": "2026-08-29T16:20:55.724Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-62827 (GCVE-0-2026-62827)
Vulnerability from cvelistv5 – Published: 2026-08-11 17:03 – Updated: 2026-08-29 16:20- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://msrc.microsoft.com/update-guide/vulnerabi… | vendor-advisorypatch |
| Vendor | Product | Version | |
|---|---|---|---|
| Microsoft | Microsoft SharePoint Enterprise Server 2016 |
Affected:
16.0.0 , < 16.0.5565.1001
(custom)
|
|
| Microsoft | Microsoft SharePoint Server 2019 |
Affected:
16.0.0 , < 16.0.10417.20198
(custom)
|
|
| Microsoft | Microsoft SharePoint Server Subscription Edition |
Affected:
16.0.0 , < 16.0.19725.20522
(custom)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-62827",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-12T03:58:30.454510Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-12T13:42:16.399Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"platforms": [
"x64-based Systems"
],
"product": "Microsoft SharePoint Enterprise Server 2016",
"vendor": "Microsoft",
"versions": [
{
"lessThan": "16.0.5565.1001",
"status": "affected",
"version": "16.0.0",
"versionType": "custom"
}
]
},
{
"platforms": [
"x64-based Systems"
],
"product": "Microsoft SharePoint Server 2019",
"vendor": "Microsoft",
"versions": [
{
"lessThan": "16.0.10417.20198",
"status": "affected",
"version": "16.0.0",
"versionType": "custom"
}
]
},
{
"platforms": [
"x64-based Systems"
],
"product": "Microsoft SharePoint Server Subscription Edition",
"vendor": "Microsoft",
"versions": [
{
"lessThan": "16.0.19725.20522",
"status": "affected",
"version": "16.0.0",
"versionType": "custom"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:microsoft:sharepoint_server_2016:*:*:*:*:enterprise:*:*:*",
"versionEndExcluding": "16.0.5565.1001",
"versionStartIncluding": "16.0.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:microsoft:sharepoint_server_2019:*:*:*:*:*:*:*:*",
"versionEndExcluding": "16.0.10417.20198",
"versionStartIncluding": "16.0.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:a:microsoft:sharepoint_server:*:*:*:*:subscription:*:*:*",
"versionEndExcluding": "16.0.19725.20522",
"versionStartIncluding": "16.0.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"datePublic": "2026-08-11T14:00:00.000Z",
"descriptions": [
{
"lang": "en-US",
"value": "Improper authentication in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en-US",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en-US",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-29T16:20:51.537Z",
"orgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"shortName": "microsoft"
},
"references": [
{
"name": "Microsoft SharePoint Server Elevation of Privilege Vulnerability",
"tags": [
"vendor-advisory",
"patch"
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62827"
}
],
"title": "Microsoft SharePoint Server Elevation of Privilege Vulnerability"
}
},
"cveMetadata": {
"assignerOrgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"assignerShortName": "microsoft",
"cveId": "CVE-2026-62827",
"datePublished": "2026-08-11T17:03:28.556Z",
"dateReserved": "2026-07-14T21:10:38.082Z",
"dateUpdated": "2026-08-29T16:20:51.537Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-62825 (GCVE-0-2026-62825)
Vulnerability from cvelistv5 – Published: 2026-07-24 00:01 – Updated: 2026-08-28 17:56 Exclusively Hosted Service- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://msrc.microsoft.com/update-guide/vulnerabi… | vendor-advisorypatch |
| Vendor | Product | Version | |
|---|---|---|---|
| Microsoft | Azure Key Vault |
Affected:
-
cpe:2.3:a:microsoft:azure_key_vault:*:*:*:*:*:*:*:* |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-62825",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-24T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-25T03:55:30.775Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Azure Key Vault",
"vendor": "Microsoft",
"versions": [
{
"status": "affected",
"version": "-"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:microsoft:azure_key_vault:*:*:*:*:*:*:*:*",
"versionStartIncluding": "-",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"datePublic": "2026-07-23T14:00:00.000Z",
"descriptions": [
{
"lang": "en-US",
"value": "Improper authentication in Azure Key Vault allows an unauthorized attacker to elevate privileges over a network."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 10,
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H/E:U/RL:O/RC:C",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en-US",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en-US",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-28T17:56:36.845Z",
"orgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"shortName": "microsoft"
},
"references": [
{
"name": "Azure Key Vault Elevation of Privilege Vulnerability",
"tags": [
"vendor-advisory",
"patch"
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62825"
}
],
"tags": [
"exclusively-hosted-service"
],
"title": "Azure Key Vault Elevation of Privilege Vulnerability"
}
},
"cveMetadata": {
"assignerOrgId": "f38d906d-7342-40ea-92c1-6c4a2c6478c8",
"assignerShortName": "microsoft",
"cveId": "CVE-2026-62825",
"datePublished": "2026-07-24T00:01:13.490Z",
"dateReserved": "2026-07-14T21:10:38.082Z",
"dateUpdated": "2026-08-28T17:56:36.845Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-62669 (GCVE-0-2026-62669)
Vulnerability from cvelistv5 – Published: 2026-08-19 15:40 – Updated: 2026-08-19 18:18- CWE-287 - Improper Authentication
| URL | Tags |
|---|---|
| https://github.com/getgrav/grav/security/advisori… | x_refsource_CONFIRM |
| https://github.com/getgrav/grav-plugin-login/comm… | x_refsource_MISC |
| https://github.com/getgrav/grav-plugin-login/rele… | x_refsource_MISC |
| Vendor | Product | Version | |
|---|---|---|---|
| getgrav | grav |
Affected:
< 2.0.4
|
|
| getgrav | grav-plugin-login |
Affected:
< 3.8.11
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-62669",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-19T18:16:05.801751Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-19T18:18:46.380Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "grav",
"vendor": "getgrav",
"versions": [
{
"status": "affected",
"version": "\u003c 2.0.4"
}
]
},
{
"product": "grav-plugin-login",
"vendor": "getgrav",
"versions": [
{
"status": "affected",
"version": "\u003c 3.8.11"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Grav Login Plugin adds login, basic ACL, and session wide messages to Grav. Prior to 3.8.11, the Grav Login plugin login.regenerate2FASecret task checks only that the pending-session user exists rather than requiring $user-\u003eauthorized. After submitting a victim\u0027s correct password, an attacker can invoke taskRegenerate2FASecret() during the pending TOTP challenge, overwrite twofa_secret, read the replacement secret from the response, calculate a valid code, and complete authentication without the victim\u0027s second factor. This issue is fixed in version 3.8.11."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"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:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-19T15:40:03.252Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/getgrav/grav/security/advisories/GHSA-7mgc-c7pq-3rr3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-7mgc-c7pq-3rr3"
},
{
"name": "https://github.com/getgrav/grav-plugin-login/commit/5d1b722298cb947d8f434025d121b99152a2c630",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/getgrav/grav-plugin-login/commit/5d1b722298cb947d8f434025d121b99152a2c630"
},
{
"name": "https://github.com/getgrav/grav-plugin-login/releases/tag/3.8.11",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/getgrav/grav-plugin-login/releases/tag/3.8.11"
}
],
"source": {
"advisory": "GHSA-7mgc-c7pq-3rr3",
"discovery": "UNKNOWN"
},
"title": "Grav Login Plugin: 2FA Bypass via \u0027login.regenerate2FASecret\u0027 - Secret Rotation During Pending Challenge"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-62669",
"datePublished": "2026-08-19T15:40:03.252Z",
"dateReserved": "2026-07-14T20:22:04.394Z",
"dateUpdated": "2026-08-19T18:18:46.380Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-62144 (GCVE-0-2026-62144)
Vulnerability from cvelistv5 – Published: 2026-07-22 13:53 – Updated: 2026-07-24 03:56- CWE-287 - Improper Authentication.
| Vendor | Product | Version | |
|---|---|---|---|
| checkpoint | Quantum Security Management |
Affected:
R82.10 with Jumbo Hotfix Take 36 or below
Affected: R82 with Jumbo Hotfix Take 118 or below Affected: R81.20 with Jumbo Hotfix Take 158 or below Affected: R81.10, R81, R80.30, R80.20, R80.10, R80, and R77.30 |
|
| checkpoint | Multi-Domain Security Management |
Affected:
R82.10 with Jumbo Hotfix Take 36 or below
Affected: R82 with Jumbo Hotfix Take 118 or below Affected: R81.20 with Jumbo Hotfix Take 158 or below Affected: R81.10, R81, R80.30, R80.20, R80.10, R80, and R77.30 |
{
"containers": {
"adp": [
{
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2026-62144",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-23T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-24T03:56:14.016Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Quantum Security Management",
"vendor": "checkpoint",
"versions": [
{
"status": "affected",
"version": "R82.10 with Jumbo Hotfix Take 36 or below"
},
{
"status": "affected",
"version": "R82 with Jumbo Hotfix Take 118 or below"
},
{
"status": "affected",
"version": "R81.20 with Jumbo Hotfix Take 158 or below"
},
{
"status": "affected",
"version": "R81.10, R81, R80.30, R80.20, R80.10, R80, and R77.30"
}
]
},
{
"product": "Multi-Domain Security Management",
"vendor": "checkpoint",
"versions": [
{
"status": "affected",
"version": "R82.10 with Jumbo Hotfix Take 36 or below"
},
{
"status": "affected",
"version": "R82 with Jumbo Hotfix Take 118 or below"
},
{
"status": "affected",
"version": "R81.20 with Jumbo Hotfix Take 158 or below"
},
{
"status": "affected",
"version": "R81.10, R81, R80.30, R80.20, R80.10, R80, and R77.30"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "An authentication bypass vulnerability in Check Point Security Management and Multi-Domain Security Management allows an unauthenticated remote attacker to execute administrative commands on the Management Server. Successful exploitation may also allow command execution on managed Security Gateways. Exploitation requires network access to the Management Server without firewall protection or a configuration that does not restrict Trusted Clients."
}
],
"metrics": [
{
"format": "CVSS",
"other": {
"content": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
},
"type": "CVSSv4.0"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication.",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-22T13:57:08.986Z",
"orgId": "897c38be-0345-43cd-b6cf-fe179e0c4f45",
"shortName": "checkpoint"
},
"references": [
{
"url": "https://support.checkpoint.com/results/sk/sk185152"
}
],
"title": "Management Authentication Bypass and Privilege Escalation"
}
},
"cveMetadata": {
"assignerOrgId": "897c38be-0345-43cd-b6cf-fe179e0c4f45",
"assignerShortName": "checkpoint",
"cveId": "CVE-2026-62144",
"datePublished": "2026-07-22T13:53:35.969Z",
"dateReserved": "2026-07-13T10:24:07.648Z",
"dateUpdated": "2026-07-24T03:56:14.016Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-61740 (GCVE-0-2026-61740)
Vulnerability from cvelistv5 – Published: 2026-07-15 14:14 – Updated: 2026-07-15 15:30| URL | Tags |
|---|---|
| https://github.com/HKUDS/LightRAG/security/adviso… | x_refsource_CONFIRM |
| https://github.com/HKUDS/LightRAG/pull/3319 | x_refsource_MISC |
| https://github.com/HKUDS/LightRAG/commit/f7819aa3… | x_refsource_MISC |
| https://github.com/HKUDS/LightRAG/releases/tag/v1.5.4 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-61740",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-15T15:14:50.443978Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-15T15:30:39.185Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-f4vv-55c2-5789"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "LightRAG",
"vendor": "HKUDS",
"versions": [
{
"status": "affected",
"version": "\u003c 1.5.4"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "LightRAG provides simple and fast retrieval-augmented generation. Prior to 1.5.4, when LightRAG is deployed with LIGHTRAG_API_KEY set but AUTH_ACCOUNTS unset, X-API-Key protection can be bypassed because lightrag/api/auth.py falls back to a hardcoded DEFAULT_TOKEN_SECRET, /auth-status and /login can mint guest JWTs, and combined_dependency in lightrag/api/utils_api.py accepts a valid guest token before checking the API key. A remote unauthenticated attacker can call endpoints guarded by combined_auth, including document read, upload, deletion, graph mutation, and query endpoints. This vulnerability is fixed in 1.5.4."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.3,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-798",
"description": "CWE-798: Use of Hard-coded Credentials",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-15T14:14:41.064Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-f4vv-55c2-5789",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-f4vv-55c2-5789"
},
{
"name": "https://github.com/HKUDS/LightRAG/pull/3319",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/HKUDS/LightRAG/pull/3319"
},
{
"name": "https://github.com/HKUDS/LightRAG/commit/f7819aa3a49a9d8d92eed8251d82d6ebcafa8cba",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/HKUDS/LightRAG/commit/f7819aa3a49a9d8d92eed8251d82d6ebcafa8cba"
},
{
"name": "https://github.com/HKUDS/LightRAG/releases/tag/v1.5.4",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/HKUDS/LightRAG/releases/tag/v1.5.4"
}
],
"source": {
"advisory": "GHSA-f4vv-55c2-5789",
"discovery": "UNKNOWN"
},
"title": "LightRAG: Authentication bypass: hardcoded DEFAULT_TOKEN_SECRET and public /auth-status defeat LIGHTRAG_API_KEY protection"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-61740",
"datePublished": "2026-07-15T14:14:41.064Z",
"dateReserved": "2026-07-10T18:59:00.047Z",
"dateUpdated": "2026-07-15T15:30:39.185Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
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-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
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.