Common Weakness Enumeration
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.
5951 vulnerabilities reference this CWE, most recent first.
CVE-2026-55666 (GCVE-0-2026-55666)
Vulnerability from cvelistv5 – Published: 2026-06-24 21:06 – Updated: 2026-06-29 15:34
VLAI
EPSS
VEX
Title
Rocket.Chat: Email Parameter Fallback Leads To Account Takeover Within Apple OAuth
Summary
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, in apps/meteor/app/apple/server/loginHandler.ts, handleIdentityToken parses a JWT issued by Apple during the OAuth flow. The try block checks for an email parameter. If the JWT does not contain an email address, the application falls back to accepting an arbitrary email value supplied directly in the request. Attackers are able to forge Apple JWTs that do not contain an email address and leverage this vulnerability to carry out account takeover attacks. This vulnerability is fixed in 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/RocketChat/Rocket.Chat/securit… | x_refsource_CONFIRM |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| RocketChat | Rocket.Chat |
Affected:
>= 8.5.0-rc.0, < 8.5.1
Affected: >= 8.4.0-rc.0, < 8.4.4 Affected: >= 8.3.0-rc.0, < 8.3.6 Affected: >= 8.2.0-rc.0, < 8.2.6 Affected: >= 8.1.0-rc.0, < 8.1.6 Affected: >= 7.11.0-rc.0, < 8.0.7 Affected: < 7.10.13 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-55666",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-26T03:55:30.444148Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-29T15:34:36.146Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Rocket.Chat",
"vendor": "RocketChat",
"versions": [
{
"status": "affected",
"version": "\u003e= 8.5.0-rc.0, \u003c 8.5.1"
},
{
"status": "affected",
"version": "\u003e= 8.4.0-rc.0, \u003c 8.4.4"
},
{
"status": "affected",
"version": "\u003e= 8.3.0-rc.0, \u003c 8.3.6"
},
{
"status": "affected",
"version": "\u003e= 8.2.0-rc.0, \u003c 8.2.6"
},
{
"status": "affected",
"version": "\u003e= 8.1.0-rc.0, \u003c 8.1.6"
},
{
"status": "affected",
"version": "\u003e= 7.11.0-rc.0, \u003c 8.0.7"
},
{
"status": "affected",
"version": "\u003c 7.10.13"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, in apps/meteor/app/apple/server/loginHandler.ts, handleIdentityToken parses a JWT issued by Apple during the OAuth flow. The try block checks for an email parameter. If the JWT does not contain an email address, the application falls back to accepting an arbitrary email value supplied directly in the request. Attackers are able to forge Apple JWTs that do not contain an email address and leverage this vulnerability to carry out account takeover attacks. This vulnerability is fixed in 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13."
}
],
"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:H/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-288",
"description": "CWE-288: Authentication Bypass Using an Alternate Path or Channel",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T21:06:55.637Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-wx3c-76rf-wpwf",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-wx3c-76rf-wpwf"
}
],
"source": {
"advisory": "GHSA-wx3c-76rf-wpwf",
"discovery": "UNKNOWN"
},
"title": "Rocket.Chat: Email Parameter Fallback Leads To Account Takeover Within Apple OAuth"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-55666",
"datePublished": "2026-06-24T21:06:55.637Z",
"dateReserved": "2026-06-17T00:05:03.777Z",
"dateUpdated": "2026-06-29T15:34:36.146Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-55377 (GCVE-0-2026-55377)
Vulnerability from cvelistv5 – Published: 2026-07-10 19:57 – Updated: 2026-07-13 16:20
VLAI
EPSS
VEX
Title
Logto: Account Center MFA management step-up bypass via WebAuthn registration verification
Summary
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0.
Severity
8.1 (High)
SSVC
Exploitation: poc
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-287 - Improper Authentication
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/logto-io/logto/security/adviso… | x_refsource_CONFIRM |
| https://github.com/logto-io/logto/pull/9110 | x_refsource_MISC |
| https://github.com/logto-io/logto/commit/f56255a7… | x_refsource_MISC |
| https://github.com/logto-io/logto/releases/tag/v1.41.0 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-55377",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-13T16:20:33.380860Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-13T16:20:47.725Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/logto-io/logto/security/advisories/GHSA-q4h3-38gc-4p4j"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "logto",
"vendor": "logto-io",
"versions": [
{
"status": "affected",
"version": "\u003c 1.41.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto\u0027s Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.1,
"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:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-10T19:57:58.088Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/logto-io/logto/security/advisories/GHSA-q4h3-38gc-4p4j",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/logto-io/logto/security/advisories/GHSA-q4h3-38gc-4p4j"
},
{
"name": "https://github.com/logto-io/logto/pull/9110",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/logto-io/logto/pull/9110"
},
{
"name": "https://github.com/logto-io/logto/commit/f56255a7edf3b22b0ec2fdb814814ce6b0123b74",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/logto-io/logto/commit/f56255a7edf3b22b0ec2fdb814814ce6b0123b74"
},
{
"name": "https://github.com/logto-io/logto/releases/tag/v1.41.0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/logto-io/logto/releases/tag/v1.41.0"
}
],
"source": {
"advisory": "GHSA-q4h3-38gc-4p4j",
"discovery": "UNKNOWN"
},
"title": "Logto: Account Center MFA management step-up bypass via WebAuthn registration verification"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-55377",
"datePublished": "2026-07-10T19:57:58.088Z",
"dateReserved": "2026-06-16T18:57:40.181Z",
"dateUpdated": "2026-07-13T16:20:47.725Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-55076 (GCVE-0-2026-55076)
Vulnerability from cvelistv5 – Published: 2026-07-07 22:23 – Updated: 2026-07-08 14:03
VLAI
EPSS
VEX
Title
Coder's OIDC email_verified type coercion bypass enables account takeover via unverified email linking
Summary
Coder allows organizations to provision remote development environments via Terraform. Prior to versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2, Coder's OIDC callback checked `email_verified` with a direct Go `bool` type assertion. When an IdP returned the claim as a non-boolean (for example the string `"false"`) or omitted it, the assertion failed open and the email was treated as verified. Combined with an unconditional email-based account fallback, this enabled account takeover. The fix in versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 coerces `email_verified` across bool, string and numeric types (fail-closed) and blocks the email fallback when the matched user already has a different linked IdP subject. As a workaround, ensure the IdP returns `email_verified` as a native JSON boolean. The email-fallback linking issue has no configuration workaround; upgrading is required.
Severity
7.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
References
7 references
| URL | Tags |
|---|---|
| https://github.com/coder/coder/security/advisorie… | x_refsource_CONFIRM |
| https://github.com/coder/coder/pull/25712 | x_refsource_MISC |
| https://github.com/coder/coder/pull/25713 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.29.17 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.32.7 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.33.8 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.34.2 | x_refsource_MISC |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-55076",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-08T14:03:30.696230Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-08T14:03:39.329Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "coder",
"vendor": "coder",
"versions": [
{
"status": "affected",
"version": "\u003e= 2.34.0, \u003c 2.34.2"
},
{
"status": "affected",
"version": "\u003e= 2.33.0, \u003c 2.33.8"
},
{
"status": "affected",
"version": "\u003e= 2.30.0, \u003c 2.32.7"
},
{
"status": "affected",
"version": "\u003c 2.29.17"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Coder allows organizations to provision remote development environments via Terraform. Prior to versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2, Coder\u0027s OIDC callback checked `email_verified` with a direct Go `bool` type assertion. When an IdP returned the claim as a non-boolean (for example the string `\"false\"`) or omitted it, the assertion failed open and the email was treated as verified. Combined with an unconditional email-based account fallback, this enabled account takeover. The fix in versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 coerces `email_verified` across bool, string and numeric types (fail-closed) and blocks the email fallback when the matched user already has a different linked IdP subject. As a workaround, ensure the IdP returns `email_verified` as a native JSON boolean. The email-fallback linking issue has no configuration workaround; upgrading is required."
}
],
"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"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-704",
"description": "CWE-704: Incorrect Type Conversion or Cast",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-07T22:23:26.179Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/coder/coder/security/advisories/GHSA-75vm-6w67-gwvp",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/coder/coder/security/advisories/GHSA-75vm-6w67-gwvp"
},
{
"name": "https://github.com/coder/coder/pull/25712",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/pull/25712"
},
{
"name": "https://github.com/coder/coder/pull/25713",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/pull/25713"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.29.17",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.29.17"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.32.7",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.32.7"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.33.8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.33.8"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.34.2",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.34.2"
}
],
"source": {
"advisory": "GHSA-75vm-6w67-gwvp",
"discovery": "UNKNOWN"
},
"title": "Coder\u0027s OIDC email_verified type coercion bypass enables account takeover via unverified email linking"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-55076",
"datePublished": "2026-07-07T22:23:26.179Z",
"dateReserved": "2026-06-16T14:33:35.711Z",
"dateUpdated": "2026-07-08T14:03:39.329Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-55075 (GCVE-0-2026-55075)
Vulnerability from cvelistv5 – Published: 2026-07-07 21:33 – Updated: 2026-07-08 13:03
VLAI
EPSS
VEX
Title
Coder vulnerable to OIDC account takeover via email-based user matching and email_verified bypass
Summary
Coder allows organizations to provision remote development environments via Terraform. Prior to versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2, two flaws in Coder's OIDC login chained into account takeover. Email-based user matching fell back to linking by email without checking for an existing link to a different IdP subject and the `email_verified` claim was only enforced when present as a boolean `false` so an absent or non-boolean claim was treated as verified. The fix in versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 restricts the email fallback to first-time and legacy linking and defaults `email_verified` to false when the claim is absent or of an unexpected type. As a workaround, configure the OIDC provider to disallow self-registration or to require email verification before issuing tokens.
Severity
7.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
Assigner
References
7 references
| URL | Tags |
|---|---|
| https://github.com/coder/coder/security/advisorie… | x_refsource_CONFIRM |
| https://github.com/coder/coder/pull/25712 | x_refsource_MISC |
| https://github.com/coder/coder/pull/25713 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.29.17 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.32.7 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.33.8 | x_refsource_MISC |
| https://github.com/coder/coder/releases/tag/v2.34.2 | x_refsource_MISC |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-55075",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-08T13:02:51.874018Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-08T13:03:16.212Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "coder",
"vendor": "coder",
"versions": [
{
"status": "affected",
"version": "\u003e= 2.34.0, \u003c 2.34.2"
},
{
"status": "affected",
"version": "\u003e= 2.33.0, \u003c 2.33.8"
},
{
"status": "affected",
"version": "\u003e= 2.30.0, \u003c 2.32.7"
},
{
"status": "affected",
"version": "\u003c 2.29.17"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Coder allows organizations to provision remote development environments via Terraform. Prior to versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2, two flaws in Coder\u0027s OIDC login chained into account takeover. Email-based user matching fell back to linking by email without checking for an existing link to a different IdP subject and the `email_verified` claim was only enforced when present as a boolean `false` so an absent or non-boolean claim was treated as verified. The fix in versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 restricts the email fallback to first-time and legacy linking and defaults `email_verified` to false when the claim is absent or of an unexpected type. As a workaround, configure the OIDC provider to disallow self-registration or to require email verification before issuing tokens."
}
],
"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"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-289",
"description": "CWE-289: Authentication Bypass by Alternate Name",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-07T21:33:38.189Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/coder/coder/security/advisories/GHSA-9r87-mvcw-x35f",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/coder/coder/security/advisories/GHSA-9r87-mvcw-x35f"
},
{
"name": "https://github.com/coder/coder/pull/25712",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/pull/25712"
},
{
"name": "https://github.com/coder/coder/pull/25713",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/pull/25713"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.29.17",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.29.17"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.32.7",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.32.7"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.33.8",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.33.8"
},
{
"name": "https://github.com/coder/coder/releases/tag/v2.34.2",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/coder/coder/releases/tag/v2.34.2"
}
],
"source": {
"advisory": "GHSA-9r87-mvcw-x35f",
"discovery": "UNKNOWN"
},
"title": "Coder vulnerable to OIDC account takeover via email-based user matching and email_verified bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-55075",
"datePublished": "2026-07-07T21:33:38.189Z",
"dateReserved": "2026-06-16T14:33:35.710Z",
"dateUpdated": "2026-07-08T13:03:16.212Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54781 (GCVE-0-2026-54781)
Vulnerability from cvelistv5 – Published: 2026-07-08 22:19 – Updated: 2026-07-09 14:40
VLAI
EPSS
VEX
Title
CoreWCF: SAML SubjectConfirmation methods and holder-of-key proof keys are not enforced
Summary
CoreWCF is a port of the service side of Windows Communication Foundation (WCF) to .NET Core. Prior to 1.8.1 and 1.9.1, CoreWCF SAML token validation does not enforce SubjectConfirmation method URIs or holder-of-key proof keys in SamlSecurityTokenHandler, allowing holder-of-key downgrade or custom confirmation method assertions to authenticate a subject without proving authority over the assertion. This issue is fixed in versions 1.8.1 and 1.9.1.
Severity
7.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
Assigner
References
6 references
| URL | Tags |
|---|---|
| https://github.com/CoreWCF/CoreWCF/security/advis… | x_refsource_CONFIRM |
| https://github.com/CoreWCF/CoreWCF/commit/6a99df3… | x_refsource_MISC |
| https://github.com/CoreWCF/CoreWCF/commit/86dd323… | x_refsource_MISC |
| https://github.com/CoreWCF/CoreWCF/commit/9eb9b46… | x_refsource_MISC |
| https://github.com/CoreWCF/CoreWCF/releases/tag/v1.8.1 | x_refsource_MISC |
| https://github.com/CoreWCF/CoreWCF/releases/tag/v1.9.1 | x_refsource_MISC |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54781",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-09T14:31:13.261626Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-09T14:40:11.234Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "CoreWCF",
"vendor": "CoreWCF",
"versions": [
{
"status": "affected",
"version": "\u003e= 1.9.0, \u003c 1.9.1"
},
{
"status": "affected",
"version": "\u003c 1.8.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "CoreWCF is a port of the service side of Windows Communication Foundation (WCF) to .NET Core. Prior to 1.8.1 and 1.9.1, CoreWCF SAML token validation does not enforce SubjectConfirmation method URIs or holder-of-key proof keys in SamlSecurityTokenHandler, allowing holder-of-key downgrade or custom confirmation method assertions to authenticate a subject without proving authority over the assertion. This issue is fixed in versions 1.8.1 and 1.9.1."
}
],
"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"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-345",
"description": "CWE-345: Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-08T22:19:40.784Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-48pq-2xq3-c2m4",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-48pq-2xq3-c2m4"
},
{
"name": "https://github.com/CoreWCF/CoreWCF/commit/6a99df3242f54acd6f89edfd6050430b72d0c685",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/CoreWCF/CoreWCF/commit/6a99df3242f54acd6f89edfd6050430b72d0c685"
},
{
"name": "https://github.com/CoreWCF/CoreWCF/commit/86dd3232b6b8aaf32281be9e8d798afad6145d58",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/CoreWCF/CoreWCF/commit/86dd3232b6b8aaf32281be9e8d798afad6145d58"
},
{
"name": "https://github.com/CoreWCF/CoreWCF/commit/9eb9b46d1c2af06fb71f656a02f4d5b4649c1f03",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/CoreWCF/CoreWCF/commit/9eb9b46d1c2af06fb71f656a02f4d5b4649c1f03"
},
{
"name": "https://github.com/CoreWCF/CoreWCF/releases/tag/v1.8.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/CoreWCF/CoreWCF/releases/tag/v1.8.1"
},
{
"name": "https://github.com/CoreWCF/CoreWCF/releases/tag/v1.9.1",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/CoreWCF/CoreWCF/releases/tag/v1.9.1"
}
],
"source": {
"advisory": "GHSA-48pq-2xq3-c2m4",
"discovery": "UNKNOWN"
},
"title": "CoreWCF: SAML SubjectConfirmation methods and holder-of-key proof keys are not enforced"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54781",
"datePublished": "2026-07-08T22:19:40.784Z",
"dateReserved": "2026-06-15T23:23:57.714Z",
"dateUpdated": "2026-07-09T14:40:11.234Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54320 (GCVE-0-2026-54320)
Vulnerability from cvelistv5 – Published: 2026-06-23 18:11 – Updated: 2026-06-24 14:28
VLAI
EPSS
VEX
Title
Daytona: Cross-tenant organization takeover via invitation acceptance with an unverified email
Summary
Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.184.0, organization invitations could be accepted (and declined) by a user whose email matched the invitation but had not been verified. Daytona authenticates users via OIDC and matches an invitation's target email against the email in the caller's token, but the invitation accept and decline paths did not require that email to be verified, unlike organization creation, which already enforced verification. On identity providers that allow self-service signup and issue a session before the email is verified, an actor could register an address matching a pending invitation, leave it unverified, and accept the invitation, joining the target organization with the role the invitation carried (up to Owner). This vulnerability is fixed in 0.184.0.
Severity
8.4 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/daytonaio/daytona/security/adv… | x_refsource_CONFIRM |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54320",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-24T14:28:12.345394Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T14:28:38.501Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "daytona",
"vendor": "daytonaio",
"versions": [
{
"status": "affected",
"version": "\u003c 0.184.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Prior to 0.184.0, organization invitations could be accepted (and declined) by a user whose email matched the invitation but had not been verified. Daytona authenticates users via OIDC and matches an invitation\u0027s target email against the email in the caller\u0027s token, but the invitation accept and decline paths did not require that email to be verified, unlike organization creation, which already enforced verification. On identity providers that allow self-service signup and issue a session before the email is verified, an actor could register an address matching a pending invitation, leave it unverified, and accept the invitation, joining the target organization with the role the invitation carried (up to Owner). This vulnerability is fixed in 0.184.0."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287: Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863: Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-23T18:11:19.369Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/daytonaio/daytona/security/advisories/GHSA-m6hx-cffh-3f3h",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/daytonaio/daytona/security/advisories/GHSA-m6hx-cffh-3f3h"
}
],
"source": {
"advisory": "GHSA-m6hx-cffh-3f3h",
"discovery": "UNKNOWN"
},
"title": "Daytona: Cross-tenant organization takeover via invitation acceptance with an unverified email"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54320",
"datePublished": "2026-06-23T18:11:19.369Z",
"dateReserved": "2026-06-12T18:42:02.223Z",
"dateUpdated": "2026-06-24T14:28:38.501Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-54089 (GCVE-0-2026-54089)
Vulnerability from cvelistv5 – Published: 2026-06-25 17:46 – Updated: 2026-06-25 18:33
VLAI
EPSS
VEX
Title
File Browser: Authentication Bypass via Proxy Auth Header Forgery
Summary
File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Starting with 2.0.0-rc.1, when FileBrowser is configured with proxy authentication (auth.method=proxy), any unauthenticated attacker who can reach the server directly can impersonate any user - including admin - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to automatically create a new user account, providing an account creation primitive with no authorization. This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before.
Severity
9.1 (Critical)
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: total
CISA Coordinator (v2.0.3)
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/filebrowser/filebrowser/securi… | x_refsource_CONFIRM |
| https://github.com/filebrowser/filebrowser/blob/m… | x_refsource_MISC |
| https://github.com/filebrowser/filebrowser/blob/m… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| filebrowser | filebrowser |
Affected:
>= 2.0.0-rc.1
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-54089",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-25T18:33:12.379285Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-25T18:33:37.531Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-xqp3-jq6g-x3qm"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "filebrowser",
"vendor": "filebrowser",
"versions": [
{
"status": "affected",
"version": "\u003e= 2.0.0-rc.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Starting with 2.0.0-rc.1, when FileBrowser is configured with proxy authentication (auth.method=proxy), any unauthenticated attacker who can reach the server directly can impersonate any user - including admin - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to automatically create a new user account, providing an account creation primitive with no authorization. This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before."
}
],
"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"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-290",
"description": "CWE-290: Authentication Bypass by Spoofing",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-25T17:46:13.119Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-xqp3-jq6g-x3qm",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-xqp3-jq6g-x3qm"
},
{
"name": "https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go"
},
{
"name": "https://github.com/filebrowser/filebrowser/blob/main/http/auth.go#L121-L137",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/filebrowser/filebrowser/blob/main/http/auth.go#L121-L137"
}
],
"source": {
"advisory": "GHSA-xqp3-jq6g-x3qm",
"discovery": "UNKNOWN"
},
"title": "File Browser: Authentication Bypass via Proxy Auth Header Forgery"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-54089",
"datePublished": "2026-06-25T17:46:13.119Z",
"dateReserved": "2026-06-11T18:44:47.761Z",
"dateUpdated": "2026-06-25T18:33:37.531Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-53913 (GCVE-0-2026-53913)
Vulnerability from cvelistv5 – Published: 2026-07-06 08:12 – Updated: 2026-07-07 12:36
VLAI
EPSS
VEX
Title
Apache Camel Keycloak: KeycloakSecurityPolicy verifies the bearer access token only inside its role and permission checks, so in the default configuration the token is never verified and any non-null bearer value is accepted
Summary
Improper Authentication, Missing Authentication for Critical Function, Not Failing Securely ('Failing Open') vulnerability in Apache Camel Keycloak Component.
The KeycloakSecurityPolicy of camel-keycloak guards a route by running KeycloakSecurityProcessor.beforeProcess(), which performs three checks in sequence: it rejects a request that carries no access token, then - only if requiredRoles is non-empty - validates the roles, and - only if requiredPermissions is non-empty - validates the permissions. The actual cryptographic verification of the bearer access token (signature, issuer and expiry for a local JWT, or active-state and issuer for token introspection) is performed exclusively inside those role and permission checks. KeycloakSecurityPolicy defaults requiredRoles and requiredPermissions to empty - which is the documented 'Basic Setup' - so on a route configured that way the role and permission checks are skipped and the access token is therefore never verified. The token-presence check still rejects a missing token, but an invalid token is accepted: any non-null value in the Authorization: Bearer header - including an arbitrary string or a forged, unsigned JWT - passes the policy and the request reaches the protected route, with no signature, issuer or expiry check and no request to Keycloak. The token is read from the inbound request header because allowTokenFromHeader defaults to true. Because the normal reason to place a route behind this policy is that the route performs server-side work, the bypass results in unauthenticated access to that work; where the protected route forwards to a code-execution-capable producer, it can result in unauthenticated remote code execution. This defect is independent of CVE-2026-23552: that issue concerned the issuer claim and was fixed by adding a check inside the verification routine, but here the verification routine is not reached at all in the default configuration, so the defect remains.
This issue affects Apache Camel: from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy so that the token-verification path is exercised, set allowTokenFromHeader to false where the token is not expected from the request header, or perform token verification at the framework layer ahead of the policy.
Severity
9.8 (Critical)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://camel.apache.org/security/CVE-2026-53913.html | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Camel Keycloak |
Affected:
4.15.0 , < 4.18.3
(semver)
Affected: 4.19.0 , < 4.21.0 (semver) |
Credits
{
"containers": {
"adp": [
{
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2026-53913",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-07T12:36:36.837107Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-07T12:36:54.235Z",
"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-keycloak",
"product": "Apache Camel Keycloak",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "4.18.3",
"status": "affected",
"version": "4.15.0",
"versionType": "semver"
},
{
"lessThan": "4.21.0",
"status": "affected",
"version": "4.19.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Lidor Ben Shitrit from Novee Security"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Andrea Cosentino"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eImproper Authentication, Missing Authentication for Critical Function, Not Failing Securely (\u0027Failing Open\u0027) vulnerability in Apache Camel Keycloak Component.\u003c/p\u003eThe KeycloakSecurityPolicy of camel-keycloak guards a route by running KeycloakSecurityProcessor.beforeProcess(), which performs three checks in sequence: it rejects a request that carries no access token, then - only if requiredRoles is non-empty - validates the roles, and - only if requiredPermissions is non-empty - validates the permissions. The actual cryptographic verification of the bearer access token (signature, issuer and expiry for a local JWT, or active-state and issuer for token introspection) is performed exclusively inside those role and permission checks. KeycloakSecurityPolicy defaults requiredRoles and requiredPermissions to empty - which is the documented \u0027Basic Setup\u0027 - so on a route configured that way the role and permission checks are skipped and the access token is therefore never verified. The token-presence check still rejects a missing token, but an invalid token is accepted: any non-null value in the Authorization: Bearer header - including an arbitrary string or a forged, unsigned JWT - passes the policy and the request reaches the protected route, with no signature, issuer or expiry check and no request to Keycloak. The token is read from the inbound request header because allowTokenFromHeader defaults to true. Because the normal reason to place a route behind this policy is that the route performs server-side work, the bypass results in unauthenticated access to that work; where the protected route forwards to a code-execution-capable producer, it can result in unauthenticated remote code execution. This defect is independent of CVE-2026-23552: that issue concerned the issuer claim and was fixed by adding a check inside the verification routine, but here the verification routine is not reached at all in the default configuration, so the defect remains.\u003cbr\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy so that the token-verification path is exercised, set allowTokenFromHeader to false where the token is not expected from the request header, or perform token verification at the framework layer ahead of the policy.\u003c/p\u003e"
}
],
"value": "Improper Authentication, Missing Authentication for Critical Function, Not Failing Securely (\u0027Failing Open\u0027) vulnerability in Apache Camel Keycloak Component.\n\nThe KeycloakSecurityPolicy of camel-keycloak guards a route by running KeycloakSecurityProcessor.beforeProcess(), which performs three checks in sequence: it rejects a request that carries no access token, then - only if requiredRoles is non-empty - validates the roles, and - only if requiredPermissions is non-empty - validates the permissions. The actual cryptographic verification of the bearer access token (signature, issuer and expiry for a local JWT, or active-state and issuer for token introspection) is performed exclusively inside those role and permission checks. KeycloakSecurityPolicy defaults requiredRoles and requiredPermissions to empty - which is the documented \u0027Basic Setup\u0027 - so on a route configured that way the role and permission checks are skipped and the access token is therefore never verified. The token-presence check still rejects a missing token, but an invalid token is accepted: any non-null value in the Authorization: Bearer header - including an arbitrary string or a forged, unsigned JWT - passes the policy and the request reaches the protected route, with no signature, issuer or expiry check and no request to Keycloak. The token is read from the inbound request header because allowTokenFromHeader defaults to true. Because the normal reason to place a route behind this policy is that the route performs server-side work, the bypass results in unauthenticated access to that work; where the protected route forwards to a code-execution-capable producer, it can result in unauthenticated remote code execution. This defect is independent of CVE-2026-23552: that issue concerned the issuer claim and was fixed by adding a check inside the verification routine, but here the verification routine is not reached at all in the default configuration, so the defect remains.\nThis issue affects Apache Camel: from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, configure a non-empty requiredRoles or requiredPermissions on every KeycloakSecurityPolicy so that the token-verification path is exercised, set allowTokenFromHeader to false where the token is not expected from the request header, or perform token verification at the framework layer ahead of the policy."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-306",
"description": "CWE-306 Missing Authentication for Critical Function",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-636",
"description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-06T08:12:32.594Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://camel.apache.org/security/CVE-2026-53913.html"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Camel Keycloak: KeycloakSecurityPolicy verifies the bearer access token only inside its role and permission checks, so in the default configuration the token is never verified and any non-null bearer value is accepted",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-53913",
"datePublished": "2026-07-06T08:12:32.594Z",
"dateReserved": "2026-06-11T10:24:16.144Z",
"dateUpdated": "2026-07-07T12:36:54.235Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-53483 (GCVE-0-2026-53483)
Vulnerability from cvelistv5 – Published: 2026-07-07 12:57 – Updated: 2026-07-08 03:56
VLAI
EPSS
VEX
Summary
Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 an improper authentication vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. This is a critical severity vulnerability as it allows an attacker to take complete control of system; so Dell recommends customers to upgrade at the earliest opportunity.
Severity
9.8 (Critical)
SSVC
Exploitation: none
Automatable: yes
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
- CWE-287 - Improper Authentication
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://www.dell.com/support/kbdoc/en-us/00048126… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Dell | PowerProtect Data Domain |
Affected:
0 , < 8.8.0.0 or later
(semver)
Affected: 0 , < 8.6.1.20 or later (semver) Affected: 0 , < 8.3.1.40 or later (semver) Affected: 0 , < 7.13.1.80 or later (semver) |
Date Public
2026-07-02 06:30
Credits
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-53483",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-07T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-08T03:56:40.966Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "PowerProtect Data Domain",
"vendor": "Dell",
"versions": [
{
"lessThan": "8.8.0.0 or later",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"lessThan": "8.6.1.20 or later",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"lessThan": "8.3.1.40 or later",
"status": "affected",
"version": "0",
"versionType": "semver"
},
{
"lessThan": "7.13.1.80 or later",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "other",
"value": "Dell would like to thank Ahmed Y. Elmogy for reporting these issues."
}
],
"datePublic": "2026-07-02T06:30:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 an improper authentication vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. This is a critical severity vulnerability as it allows an attacker to take complete control of system; so Dell recommends customers to upgrade at the earliest opportunity."
}
],
"value": "Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 an improper authentication vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. This is a critical severity vulnerability as it allows an attacker to take complete control of system; so Dell recommends customers to upgrade at the earliest opportunity."
}
],
"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"
},
"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-07T12:57:07.708Z",
"orgId": "c550e75a-17ff-4988-97f0-544cde3820fe",
"shortName": "dell"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://www.dell.com/support/kbdoc/en-us/000481268/dsa-2026-278-security-update-for-dell-powerprotect-data-domain-multiple-vulnerabilities"
}
],
"source": {
"discovery": "UNKNOWN"
},
"x_generator": {
"engine": "Vulnogram 1.0.2"
}
}
},
"cveMetadata": {
"assignerOrgId": "c550e75a-17ff-4988-97f0-544cde3820fe",
"assignerShortName": "dell",
"cveId": "CVE-2026-53483",
"datePublished": "2026-07-07T12:57:07.708Z",
"dateReserved": "2026-06-09T17:04:35.250Z",
"dateUpdated": "2026-07-08T03:56:40.966Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-52845 (GCVE-0-2026-52845)
Vulnerability from cvelistv5 – Published: 2026-06-23 17:52 – Updated: 2026-07-15 00:46
VLAI
EPSS
VEX
Title
Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`
Summary
Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.4, forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _. This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable. Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy. This vulnerability is fixed in 2.11.4.
Severity
8.1 (High)
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://github.com/caddyserver/caddy/security/adv… | x_refsource_CONFIRM |
| https://access.redhat.com/security/cve/CVE-2026-52845 | vdb-entryx_refsource_REDHAT |
| https://bugzilla.redhat.com/show_bug.cgi?id=2491907 | issue-trackingx_refsource_REDHAT |
| https://security.access.redhat.com/data/csaf/v2/v… | x_sadp-csaf-vex |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| caddyserver | caddy |
Affected:
< 2.11.4
|
|
| Red Hat | Red Hat Hardened Images |
cpe:/a:redhat:hummingbird:1 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-52845",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-24T14:25:18.472130Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-24T14:26:28.296Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-f59h-q822-g45g"
}
],
"title": "CISA ADP Vulnrichment"
},
{
"affected": [
{
"collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
"cpes": [
"cpe:/a:redhat:hummingbird:1"
],
"defaultStatus": "unaffected",
"packageName": "caddy",
"product": "Red Hat Hardened Images",
"vendor": "Red Hat"
}
],
"datePublic": "2026-06-23T17:52:01.871Z",
"descriptions": [
{
"lang": "en",
"value": "A flaw was found in Caddy, an extensible server platform. A remote attacker can exploit a vulnerability in the `forward_auth` `copy_headers` functionality. This occurs because Caddy normalizes HTTP headers into Common Gateway Interface (CGI) variables by replacing hyphens with underscores, allowing a client to send an underscore alias that bypasses the header deletion step. This enables the remote attacker to inject or override identity and group headers trusted by PHP/FastCGI applications operating behind Caddy."
}
],
"metrics": [
{
"other": {
"content": {
"namespace": "https://access.redhat.com/security/updates/classification/",
"value": "Important"
},
"type": "Red Hat severity rating"
}
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.1,
"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:N",
"version": "3.1"
},
"format": "CVSS"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-15T00:46:09.498Z",
"orgId": "0b0ca135-0b70-47e7-9f44-1890c2a1c46c",
"shortName": "redhat-SADP"
},
"references": [
{
"tags": [
"vdb-entry",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/security/cve/CVE-2026-52845"
},
{
"name": "RHBZ#2491907",
"tags": [
"issue-tracking",
"x_refsource_REDHAT"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491907"
},
{
"tags": [
"x_sadp-csaf-vex"
],
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52845.json"
}
],
"timeline": [
{
"lang": "en",
"time": "2026-06-23T19:02:21.968Z",
"value": "Reported to Red Hat."
},
{
"lang": "en",
"time": "2026-06-23T17:52:01.871Z",
"value": "Made public."
}
],
"title": "github.com/caddyserver/caddy: Caddy: Remote client can inject or override identity headers via header normalization",
"x_adpType": "supplier",
"x_generator": {
"engine": "sadp-cli 1.0.0"
}
}
],
"cna": {
"affected": [
{
"product": "caddy",
"vendor": "caddyserver",
"versions": [
{
"status": "affected",
"version": "\u003c 2.11.4"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.4, forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _. This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable. Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy. This vulnerability is fixed in 2.11.4."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 8.1,
"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:N",
"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"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444: Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-06-23T17:52:01.871Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/caddyserver/caddy/security/advisories/GHSA-f59h-q822-g45g",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-f59h-q822-g45g"
}
],
"source": {
"advisory": "GHSA-f59h-q822-g45g",
"discovery": "UNKNOWN"
},
"title": "Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-52845",
"datePublished": "2026-06-23T17:52:01.871Z",
"dateReserved": "2026-06-08T18:41:27.724Z",
"dateUpdated": "2026-07-15T00:46:09.498Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Mitigation
Architecture and Design
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.