CVE-2026-53431 (GCVE-0-2026-53431)
Vulnerability from cvelistv5 – Published: 2026-07-30 14:17 – Updated: 2026-07-31 04:20
VLAI
EPSS
VEX
Title
Boruta accepts expired JWT client assertions due to missing exp claim validation
Summary
Authentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.
Boruta accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges.
This issue affects boruta: from 2.3.0 before 2.3.7.
Severity
SSVC
Exploitation: poc
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-07-30 16:12 UTC
CWE
- CWE-294 - Authentication Bypass by Capture-replay
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/malach-it/boruta_auth/security… | vendor-advisoryrelated |
| https://cna.erlef.org/cves/CVE-2026-53431.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-53431 | related |
| https://github.com/malach-it/boruta_auth/commit/5… | patch |
| https://github.com/malach-it/boruta_auth/commit/6… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-53431",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-30T16:12:55.290055Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-30T16:13:22.708Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "boruta",
"packageURL": "pkg:hex/boruta",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"lessThan": "2.3.7",
"status": "affected",
"version": "2.3.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "malach-it/boruta_auth",
"packageURL": "pkg:github/malach-it/boruta_auth",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"changes": [
{
"at": "5204f88f9b2cdd9637a755337ed5f99185be5474",
"status": "unaffected"
},
{
"at": "69363432aa36760fc5438e4e17115d0f7c1b925a",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "5bfbe1c5443bffe71cf1bf954bbdff61327d9a83",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e or \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e token endpoint authentication methods). Deployments that authenticate clients only via \u003ctt\u003eclient_secret_basic\u003c/tt\u003e or \u003ctt\u003eclient_secret_post\u003c/tt\u003e are not exposed.\u003c/p\u003e"
}
],
"value": "The attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.3.7",
"versionStartIncluding": "2.3.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Pascal Knoth"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Pascal Knoth"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.\u003c/p\u003e\u003cp\u003eBoruta accepts JWT-based client authentication (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e and \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e token endpoint authentication methods) but never enforces that the assertion\u0027s \u003ctt\u003eexp\u003c/tt\u003e claim is in the future. The pre-check helper \u003ctt\u003e\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1\u003c/tt\u003e in \u003ctt\u003elib/boruta/oauth/request/base.ex\u003c/tt\u003e only verifies that an \u003ctt\u003eexp\u003c/tt\u003e claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, \u003ctt\u003e\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0\u003c/tt\u003e in \u003ctt\u003elib/boruta/oauth/authorization/client.ex\u003c/tt\u003e, returns an empty map, so Joken\u0027s default \u003ctt\u003eexp\u003c/tt\u003e claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client\u0027s privileges.\u003c/p\u003e\u003cp\u003eThis issue affects boruta: from 2.3.0 before 2.3.7.\u003c/p\u003e"
}
],
"value": "Authentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.\n\nBoruta accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion\u0027s exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken\u0027s default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client\u0027s privileges.\n\nThis issue affects boruta: from 2.3.0 before 2.3.7."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-60 Reusing Session IDs (aka Session Replay)"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-294",
"description": "CWE-294 Authentication Bypass by Capture-replay",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-31T04:20:43.209Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
},
{
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-53431.html"
},
{
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-53431"
},
{
"tags": [
"patch"
],
"url": "https://github.com/malach-it/boruta_auth/commit/5204f88f9b2cdd9637a755337ed5f99185be5474"
},
{
"tags": [
"patch"
],
"url": "https://github.com/malach-it/boruta_auth/commit/69363432aa36760fc5438e4e17115d0f7c1b925a"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Boruta accepts expired JWT client assertions due to missing exp claim validation",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRestrict the use of JWT-based client authentication (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e and \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e) to highly trusted clients, and prefer non-JWT client authentication methods (\u003ctt\u003eclient_secret_basic\u003c/tt\u003e or \u003ctt\u003eclient_secret_post\u003c/tt\u003e) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay.\u003c/p\u003e"
}
],
"value": "Restrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay."
}
],
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-53431",
"datePublished": "2026-07-30T14:17:27.909Z",
"dateReserved": "2026-06-09T11:01:47.529Z",
"dateUpdated": "2026-07-31T04:20:43.209Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-53431",
"date": "2026-11-05",
"epss": "0.00511",
"percentile": "0.43793"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "boruta",
"packageURL": "pkg:hex/boruta",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"lessThan": "2.3.7",
"status": "affected",
"version": "2.3.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "malach-it/boruta_auth",
"packageURL": "pkg:github/malach-it/boruta_auth",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"changes": [
{
"at": "5204f88f9b2cdd9637a755337ed5f99185be5474",
"status": "unaffected"
},
{
"at": "69363432aa36760fc5438e4e17115d0f7c1b925a",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "5bfbe1c5443bffe71cf1bf954bbdff61327d9a83",
"versionType": "git"
}
]
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Authentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.\n\nBoruta accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion\u0027s exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken\u0027s default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client\u0027s privileges.\n\nThis issue affects boruta: from 2.3.0 before 2.3.7."
},
{
"lang": "es",
"value": "Una vulnerabilidad de omisi\u00f3n de autenticaci\u00f3n por captura-repetici\u00f3n en malach-it Boruta permite a un atacante que ha obtenido una aserci\u00f3n de cliente JWT previamente v\u00e1lida autenticarse como el cliente OAuth emisor despu\u00e9s de que la aserci\u00f3n haya expirado.\n\nBoruta acepta la autenticaci\u00f3n de cliente basada en JWT (m\u00e9todos de autenticaci\u00f3n de punto final de token client_secret_jwt y private_key_jwt) pero nunca impone que la declaraci\u00f3n \u2019exp\u2019 de la aserci\u00f3n est\u00e9 en el futuro. La funci\u00f3n auxiliar de pre-verificaci\u00f3n Boruta.Oauth.Request.Base.check_expiration/1 en lib/boruta/oauth/request/base.ex solo verifica que una declaraci\u00f3n \u2019exp\u2019 est\u00e9 presente (hace coincidir patrones con la existencia de la clave y devuelve \u00e9xito), y la configuraci\u00f3n de token de Joken utilizada para la verificaci\u00f3n de firma, Boruta.Oauth.Authorization.Client.Token.token_config/0 en lib/boruta/oauth/authorization/client.ex, devuelve un mapa vac\u00edo, por lo que el validador de declaraci\u00f3n \u2019exp\u2019 predeterminado de Joken tampoco se activa. Cualquier atacante que obtenga una aserci\u00f3n de cliente v\u00e1lidamente firmada (por ejemplo, a trav\u00e9s de registros, proxies inversos, herramientas de navegador u otras superficies de observabilidad) puede reproducirla indefinidamente para autenticarse como el cliente y obtener tokens de acceso con los privilegios de ese cliente.\n\nEste problema afecta a boruta: desde 2.3.0 antes de 2.3.7."
}
],
"id": "CVE-2026-53431",
"lastModified": "2026-10-23T22:10:00.160",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-53431",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-30T16:12:55.290055Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-07-30T15:16:33.567",
"references": [
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://cna.erlef.org/cves/CVE-2026-53431.html"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/malach-it/boruta_auth/commit/5204f88f9b2cdd9637a755337ed5f99185be5474"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/malach-it/boruta_auth/commit/69363432aa36760fc5438e4e17115d0f7c1b925a"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-53431"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
}
],
"sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-294"
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-53431",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-07-30T16:12:55.290055Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-30T16:13:13.574Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "boruta",
"packageURL": "pkg:hex/boruta",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"lessThan": "2.3.7",
"status": "affected",
"version": "2.3.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.Boruta.Oauth.Request.Base\u0027",
"\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027"
],
"packageName": "malach-it/boruta_auth",
"packageURL": "pkg:github/malach-it/boruta_auth",
"product": "boruta",
"programFiles": [
"lib/boruta/oauth/request/base.ex",
"lib/boruta/oauth/authorization/client.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:fetch_client_authentication/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1"
},
{
"name": "\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0"
}
],
"repo": "https://github.com/malach-it/boruta_auth",
"vendor": "malach-it",
"versions": [
{
"changes": [
{
"at": "5204f88f9b2cdd9637a755337ed5f99185be5474",
"status": "unaffected"
},
{
"at": "69363432aa36760fc5438e4e17115d0f7c1b925a",
"status": "unaffected"
}
],
"lessThan": "*",
"status": "affected",
"version": "5bfbe1c5443bffe71cf1bf954bbdff61327d9a83",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e or \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e token endpoint authentication methods). Deployments that authenticate clients only via \u003ctt\u003eclient_secret_basic\u003c/tt\u003e or \u003ctt\u003eclient_secret_post\u003c/tt\u003e are not exposed.\u003c/p\u003e"
}
],
"value": "The attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*",
"versionEndExcluding": "2.3.7",
"versionStartIncluding": "2.3.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Pascal Knoth"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Pascal Knoth"
},
{
"lang": "en",
"type": "analyst",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAuthentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.\u003c/p\u003e\u003cp\u003eBoruta accepts JWT-based client authentication (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e and \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e token endpoint authentication methods) but never enforces that the assertion\u0027s \u003ctt\u003eexp\u003c/tt\u003e claim is in the future. The pre-check helper \u003ctt\u003e\u0027Elixir.Boruta.Oauth.Request.Base\u0027:check_expiration/1\u003c/tt\u003e in \u003ctt\u003elib/boruta/oauth/request/base.ex\u003c/tt\u003e only verifies that an \u003ctt\u003eexp\u003c/tt\u003e claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, \u003ctt\u003e\u0027Elixir.Boruta.Oauth.Authorization.Client.Token\u0027:token_config/0\u003c/tt\u003e in \u003ctt\u003elib/boruta/oauth/authorization/client.ex\u003c/tt\u003e, returns an empty map, so Joken\u0027s default \u003ctt\u003eexp\u003c/tt\u003e claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client\u0027s privileges.\u003c/p\u003e\u003cp\u003eThis issue affects boruta: from 2.3.0 before 2.3.7.\u003c/p\u003e"
}
],
"value": "Authentication Bypass by Capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired.\n\nBoruta accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion\u0027s exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken\u0027s default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client\u0027s privileges.\n\nThis issue affects boruta: from 2.3.0 before 2.3.7."
}
],
"impacts": [
{
"capecId": "CAPEC-60",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-60 Reusing Session IDs (aka Session Replay)"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-294",
"description": "CWE-294 Authentication Bypass by Capture-replay",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-07-31T04:20:43.209Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"tags": [
"vendor-advisory",
"related"
],
"url": "https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6"
},
{
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-53431.html"
},
{
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-53431"
},
{
"tags": [
"patch"
],
"url": "https://github.com/malach-it/boruta_auth/commit/5204f88f9b2cdd9637a755337ed5f99185be5474"
},
{
"tags": [
"patch"
],
"url": "https://github.com/malach-it/boruta_auth/commit/69363432aa36760fc5438e4e17115d0f7c1b925a"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Boruta accepts expired JWT client assertions due to missing exp claim validation",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eRestrict the use of JWT-based client authentication (\u003ctt\u003eclient_secret_jwt\u003c/tt\u003e and \u003ctt\u003eprivate_key_jwt\u003c/tt\u003e) to highly trusted clients, and prefer non-JWT client authentication methods (\u003ctt\u003eclient_secret_basic\u003c/tt\u003e or \u003ctt\u003eclient_secret_post\u003c/tt\u003e) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay.\u003c/p\u003e"
}
],
"value": "Restrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay."
}
],
"x_generator": {
"engine": "cvelib 1.8.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-53431",
"datePublished": "2026-07-30T14:17:27.909Z",
"dateReserved": "2026-06-09T11:01:47.529Z",
"dateUpdated": "2026-07-31T04:20:43.209Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.