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-7R92-3JGR-R65Q
Vulnerability from github – Published: 2026-05-06 22:40 – Updated: 2026-05-14 20:42Impact
The mul_mod function implements multiplication via a binary expansion loop whose execution time depends on the Hamming weight of the second operand (the exponent). An attacker who can measure the time of secret‑sharing operations (e.g., via a remote service) could progressively recover the values of shares, ultimately leading to secret reconstruction.
Patches
https://github.com/svvqt/pyquorum/releases/tag/v0.2.1
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyquorum"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44368"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T22:40:15Z",
"nvd_published_at": "2026-05-13T21:16:47Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe `mul_mod` function implements multiplication via a binary expansion loop whose execution time depends on the Hamming weight of the second operand (the exponent). An attacker who can measure the time of secret\u2011sharing operations (e.g., via a remote service) could progressively recover the values of shares, ultimately leading to secret reconstruction.\n\n### Patches\nhttps://github.com/svvqt/pyquorum/releases/tag/v0.2.1",
"id": "GHSA-7r92-3jgr-r65q",
"modified": "2026-05-14T20:42:45Z",
"published": "2026-05-06T22:40:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/svvqt/pyquorum/security/advisories/GHSA-7r92-3jgr-r65q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44368"
},
{
"type": "WEB",
"url": "https://github.com/svvqt/pyquorum/commit/1e9ac41dd3c305c13d7a6b7d227bf325be82d730"
},
{
"type": "PACKAGE",
"url": "https://github.com/svvqt/pyquorum"
},
{
"type": "WEB",
"url": "https://github.com/svvqt/pyquorum/releases/tag/v0.2.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "pyquorum: Timing side\u2011channel in mul_mod"
}
GHSA-7RW5-9F7Q-XJ36
Vulnerability from github – Published: 2026-07-24 16:55 – Updated: 2026-07-24 16:55Summary
The /api/v1/auths/signin endpoint leaked whether an email address belonged to a registered account through a response-time side channel. Password verification ran bcrypt only when the email was found in the database; for a non-existent email the request returned early without hashing. The expensive bcrypt comparison therefore made valid-account attempts respond significantly slower (~180 ms) than non-existent ones (~5 ms), so an unauthenticated attacker could enumerate valid accounts by measuring response time.
Details
On signin the backend looked the user up by email and only performed the bcrypt password comparison if a record existed. A missing email short-circuited before any hashing, producing the timing gap. The built-in brute-force throttling did not prevent it: sending one request at a time with a small delay between requests stays under the rate limit while still exposing the difference.
Observed in the reporter's run (HTTP 400 for every attempt, the response time is the signal):
Email Status Response time
joe@example.com 400 186 ms <- valid account
larry@example.com 400 9 ms
jose@example.com 400 6 ms
james@example.com 400 5 ms
Impact
An unauthenticated attacker can enumerate which email addresses are registered accounts, which enables targeted password-spraying against confirmed accounts. The impact is amplified by MFA not being enabled by default. No data is read or modified; the disclosure is limited to account existence.
Patched
The authentication path now runs a bcrypt verification against a constant placeholder hash whenever the email does not resolve to an active credential, so a real hash comparison executes on every attempt and the response time is the same whether or not the account exists. Fixed in 0.10.0.
Credits
@dievus
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59218"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:55:06Z",
"nvd_published_at": "2026-07-09T17:17:02Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe `/api/v1/auths/signin` endpoint leaked whether an email address belonged to a registered account through a response-time side channel. Password verification ran bcrypt only when the email was found in the database; for a non-existent email the request returned early without hashing. The expensive bcrypt comparison therefore made valid-account attempts respond significantly slower (~180 ms) than non-existent ones (~5 ms), so an unauthenticated attacker could enumerate valid accounts by measuring response time.\n\n### Details\n\nOn signin the backend looked the user up by email and only performed the bcrypt password comparison if a record existed. A missing email short-circuited before any hashing, producing the timing gap. The built-in brute-force throttling did not prevent it: sending one request at a time with a small delay between requests stays under the rate limit while still exposing the difference.\n\nObserved in the reporter\u0027s run (HTTP 400 for every attempt, the response time is the signal):\n\n```\nEmail Status Response time\njoe@example.com 400 186 ms \u003c- valid account\nlarry@example.com 400 9 ms\njose@example.com 400 6 ms\njames@example.com 400 5 ms\n```\n\n### Impact\n\nAn unauthenticated attacker can enumerate which email addresses are registered accounts, which enables targeted password-spraying against confirmed accounts. The impact is amplified by MFA not being enabled by default. No data is read or modified; the disclosure is limited to account existence.\n\n### Patched\n\nThe authentication path now runs a bcrypt verification against a constant placeholder hash whenever the email does not resolve to an active credential, so a real hash comparison executes on every attempt and the response time is the same whether or not the account exists. Fixed in 0.10.0.\n\n### Credits\n\n@dievus",
"id": "GHSA-7rw5-9f7q-xj36",
"modified": "2026-07-24T16:55:06Z",
"published": "2026-07-24T16:55:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-7rw5-9f7q-xj36"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59218"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/26385"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/993e74912199c66c522f08ec81abe31d76985e39"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
}
],
"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"
}
],
"summary": "Open WebUI: Account enumeration via observable login timing discrepancy"
}
GHSA-7W52-7JVM-M9VW
Vulnerability from github – Published: 2026-06-04 19:31 – Updated: 2026-06-11 14:06Summary
There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.
Details
The faulty code exists in src/Core/Framework/Api/OAuth/UserRepository.php:
public function getUserEntityByUserCredentials(
string $username,
#[\SensitiveParameter]
string $password,
string $grantType,
ClientEntityInterface $clientEntity
): ?UserEntityInterface {
if ($this->loginConfigService->getConfig()?->useDefault === false) {
// never allow login via password if the default login is disabled (e.g. using SSO only)
return null;
}
$builder = $this->connection->createQueryBuilder();
$user = $builder->select('user.id', 'user.password')
->from('user')
->where('username = :username')
->setParameter('username', $username)
->fetchAssociative();
// PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND
if (!$user) {
return null;
}
// PATH 2: VERIFY PASSWORD IF USER IS FOUND
if (!password_verify($password, (string) $user['password'])) {
return null;
}
return new User(Uuid::fromBytesToHex($user['id']));
}
Subroutine getUserEntityByUserCredentials() is called when an auth request is send to api/oauth/token. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using password_verify.
PHP method password_verify by default uses hashing algorithm Argon2id which by design is intentionally 'slow' by introducing a timing cost to an attempt to bruteforce hashes more costly.
Since password_verify has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.
Proposed fix
Before doing the early return, password_verify a dummy hash.
Impact
- More targeted dictionary/bruteforce attacks.
- Spear phishing / eases social engineering.
- Credential stuffing from other data leaks.
Authors
Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.10.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48011"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T19:31:17Z",
"nvd_published_at": "2026-06-10T22:17:00Z",
"severity": "LOW"
},
"details": "### Summary\nThere is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.\n\n### Details\nThe faulty code exists in [`src/Core/Framework/Api/OAuth/UserRepository.php`](https://github.com/shopware/shopware/blob/trunk/src/Core/Framework/Api/OAuth/UserRepository.php):\n```\npublic function getUserEntityByUserCredentials(\n string $username,\n #[\\SensitiveParameter]\n string $password,\n string $grantType,\n ClientEntityInterface $clientEntity\n ): ?UserEntityInterface {\n if ($this-\u003eloginConfigService-\u003egetConfig()?-\u003euseDefault === false) {\n // never allow login via password if the default login is disabled (e.g. using SSO only)\n return null;\n }\n\n $builder = $this-\u003econnection-\u003ecreateQueryBuilder();\n $user = $builder-\u003eselect(\u0027user.id\u0027, \u0027user.password\u0027)\n -\u003efrom(\u0027user\u0027)\n -\u003ewhere(\u0027username = :username\u0027)\n -\u003esetParameter(\u0027username\u0027, $username)\n -\u003efetchAssociative();\n\n // PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND\n if (!$user) {\n return null;\n }\n\n // PATH 2: VERIFY PASSWORD IF USER IS FOUND\n if (!password_verify($password, (string) $user[\u0027password\u0027])) {\n return null;\n }\n\n return new User(Uuid::fromBytesToHex($user[\u0027id\u0027]));\n }\n```\n\nSubroutine `getUserEntityByUserCredentials()` is called when an auth request is send to `api/oauth/token`. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using `password_verify`.\n\nPHP method `password_verify` by default uses hashing algorithm Argon2id which by design is intentionally \u0027slow\u0027 by introducing a timing cost to an attempt to bruteforce hashes more costly.\n\nSince `password_verify` has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.\n\n### Proposed fix\nBefore doing the early return, `password_verify` a dummy hash.\n\n### Impact\n1. More targeted dictionary/bruteforce attacks.\n2. Spear phishing / eases social engineering.\n3. Credential stuffing from other data leaks.\n\n### Authors\nNiel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)",
"id": "GHSA-7w52-7jvm-m9vw",
"modified": "2026-06-11T14:06:35Z",
"published": "2026-06-04T19:31:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-7w52-7jvm-m9vw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48011"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
}
],
"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": "Shopware: Timing-attack on admin panel allowing enumeration of administrator usernames"
}
GHSA-86J9-25M2-9W97
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-02 17:12Jenkins Zanata Plugin 0.6 and earlier does not use a constant-time comparison when checking whether the provided and expected webhook token hashes are equal.
This could potentially allow attackers to use statistical methods to obtain a valid webhook token.
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:zanata"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46660"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-30T14:50:44Z",
"nvd_published_at": "2023-10-25T18:17:40Z",
"severity": "LOW"
},
"details": "Jenkins Zanata Plugin 0.6 and earlier does not use a constant-time comparison when checking whether the provided and expected webhook token hashes are equal.\n\nThis could potentially allow attackers to use statistical methods to obtain a valid webhook token.\n\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-86j9-25m2-9w97",
"modified": "2023-11-02T17:12:46Z",
"published": "2023-10-25T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46660"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/zanata-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-10-25/#SECURITY-2879"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/10/25/2"
}
],
"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 hash comparison in Jenkins Zanata Plugin"
}
GHSA-8859-V9JP-CPHF
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-02 16:55Jenkins Multibranch Scan Webhook Trigger Plugin 1.0.9 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.
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "igalg.jenkins.plugins:multibranch-scan-webhook-trigger"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46656"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-30T14:58:39Z",
"nvd_published_at": "2023-10-25T18:17:40Z",
"severity": "LOW"
},
"details": "Jenkins Multibranch Scan Webhook Trigger Plugin 1.0.9 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\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-8859-v9jp-cphf",
"modified": "2023-11-02T16:55:44Z",
"published": "2023-10-25T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46656"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/multibranch-scan-webhook-trigger-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-10-25/#SECURITY-2875"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/10/25/2"
}
],
"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": "Jenkins Multibranch Scan Webhook Trigger Plugin uses non-constant time webhook token comparison"
}
GHSA-885R-HHPR-CC9P
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-02 16:56Jenkins Gogs Plugin 1.0.15 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.
As of publication of this advisory, there is no fix.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:gogs-webhook"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46657"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-30T14:55:53Z",
"nvd_published_at": "2023-10-25T18:17:40Z",
"severity": "LOW"
},
"details": "Jenkins Gogs Plugin 1.0.15 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\nAs of publication of this advisory, there is no fix.",
"id": "GHSA-885r-hhpr-cc9p",
"modified": "2023-11-02T16:56:29Z",
"published": "2023-10-25T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46657"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/gogs-webhook-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-10-25/#SECURITY-2896"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/10/25/2"
}
],
"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": "Jenkins Gogs Plugin uses non-constant time webhook token comparison"
}
GHSA-8CH4-58QP-G3MP
Vulnerability from github – Published: 2021-06-11 17:43 – Updated: 2024-11-19 18:19The aaugustin websockets library before 9.1 for Python has an Observable Timing Discrepancy on servers when HTTP Basic Authentication is enabled with basic_auth_protocol_factory(credentials=...). An attacker may be able to guess a password via a timing attack.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "websockets"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-33880"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-10T16:24:45Z",
"nvd_published_at": "2021-06-06T15:15:00Z",
"severity": "HIGH"
},
"details": "The aaugustin websockets library before 9.1 for Python has an Observable Timing Discrepancy on servers when HTTP Basic Authentication is enabled with basic_auth_protocol_factory(credentials=...). An attacker may be able to guess a password via a timing attack.",
"id": "GHSA-8ch4-58qp-g3mp",
"modified": "2024-11-19T18:19:55Z",
"published": "2021-06-11T17:43:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33880"
},
{
"type": "WEB",
"url": "https://github.com/aaugustin/websockets/commit/547a26b685d08cac0aa64e5e65f7867ac0ea9bc0"
},
{
"type": "WEB",
"url": "https://github.com/aaugustin/websockets"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/websockets/PYSEC-2021-95.yaml"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
}
],
"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:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Observable Timing Discrepancy in aaugustin websockets library"
}
GHSA-8JQH-95G6-7JPJ
Vulnerability from github – Published: 2026-08-28 16:01 – Updated: 2026-08-28 16:01Summary
Phalcon\Encryption\Crypt provides authenticated encryption: when useSigning is enabled (the default), encrypt() appends an HMAC tag and decrypt() verifies it before returning the plaintext. The verification compares the attacker-supplied tag against the freshly computed HMAC using PHP/Zephir identity comparison (!==), which the Zephir compiler lowers to !ZEPHIR_IS_IDENTICAL(...) — a byte-wise memcmp that returns early on the first differing byte. The comparison time therefore depends on how many leading bytes of the supplied tag are correct, a classic MAC-verification timing side-channel. Every other secret/MAC comparison in the framework uses the constant-time hash_equals() (zephir_hash_equals) — the CSRF token check (Security::checkToken) and the JWT signature check (Signer\Hmac::verify); Crypt::decrypt is the lone deviation.
Details
Vulnerable code
phalcon/Encryption/Crypt.zep:246 (Zephir source):
if true === this->useSigning {
// Checks on the decrypted message digest using the HMAC method.
if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {
throw new Mismatch("Hash does not match.");
}
}
Generated C --> ext/phalcon/encryption/crypt.zep.c:364-367:
ZEPHIR_CALL_FUNCTION(&_8$$7, "hash_hmac", NULL, 245, &hashAlgorithm, &padded, &decryptKey, &__$true);
...
if (!ZEPHIR_IS_IDENTICAL(&digest, &_8$$7)) { // <-- non-constant-time
ZEPHIR_THROW_EXCEPTION_DEBUG_STR(..., "Hash does not match.", "phalcon/Encryption/Crypt.zep", 247);
ZEPHIR_IS_IDENTICAL --> zephir_is_identical() (ext/kernel/operators.c:472) --> Zend is_identical_function --> for equal-length strings a memcmp that exits on the first mismatching byte (data-dependent timing).
Impact
The HMAC is the integrity/authentication tag of Phalcon's authenticated-encryption scheme. A successful timing attack (Keyczar/CVE-2009-0654-style: fix the IV+ciphertext so the target tag is constant, then recover it byte-by-byte from response timing) yields a tag the attacker can attach to a chosen IV+ciphertext so that decrypt() accepts it as authentic, defeating the integrity guarantee. Combined with CFB malleability (flipping a ciphertext byte flips the corresponding plaintext byte), an attacker who recovers the forging capability can tamper with the decrypted contents the application trusts (e.g. encrypted cookies carrying authorization/identity state). There is no confidentiality break by itself.
Suggested fix
Replace the identity comparison with the constant-time helper already used elsewhere in the framework. In phalcon/Encryption/Crypt.zep:246:
// before
if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {
throw new Mismatch("Hash does not match.");
}
// after
if true !== hash_equals(hash_hmac(hashAlgorithm, padded, decryptKey, true), digest) {
throw new Mismatch("Hash does not match.");
}
hash_equals() returns false for unequal-length inputs, so it also covers the truncated-tag case. Optional further hardening: verify the MAC before unpadding (functionally moot here because cryptUnpadText never throws) and consider migrating the default toward an AEAD mode such as aes-256-gcm.
Addressed Issue:
- https://github.com/phalcon/cphalcon/issues/17090
Patched Stream:
- https://github.com/phalcon/cphalcon/issues/17090
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.14.0"
},
"package": {
"ecosystem": "Packagist",
"name": "phalcon/cphalcon"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54736"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T16:01:05Z",
"nvd_published_at": "2026-07-10T22:16:42Z",
"severity": "HIGH"
},
"details": "## Summary\n\n`Phalcon\\Encryption\\Crypt` provides authenticated encryption: when `useSigning` is enabled (the default), `encrypt()` appends an HMAC tag and `decrypt()` verifies it before returning the plaintext. The verification compares the attacker-supplied tag against the freshly computed HMAC using PHP/Zephir identity comparison (`!==`), which the Zephir compiler lowers to `!ZEPHIR_IS_IDENTICAL(...)` \u2014 a byte-wise `memcmp` that returns early on the first differing byte. The comparison time therefore depends on how many leading bytes of the supplied tag are correct, a classic MAC-verification timing side-channel. Every other secret/MAC comparison in the framework uses the constant-time `hash_equals()` (`zephir_hash_equals`) \u2014 the CSRF token check (`Security::checkToken`) and the JWT signature check (`Signer\\Hmac::verify`); `Crypt::decrypt` is the lone deviation.\n\n## Details\n\n### Vulnerable code\n\n`phalcon/Encryption/Crypt.zep:246` (Zephir source):\n\n```zephir\nif true === this-\u003euseSigning {\n // Checks on the decrypted message digest using the HMAC method.\n if digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {\n throw new Mismatch(\"Hash does not match.\");\n }\n}\n```\n\nGenerated C --\u003e `ext/phalcon/encryption/crypt.zep.c:364-367`:\n\n```c\nZEPHIR_CALL_FUNCTION(\u0026_8$$7, \"hash_hmac\", NULL, 245, \u0026hashAlgorithm, \u0026padded, \u0026decryptKey, \u0026__$true);\n...\nif (!ZEPHIR_IS_IDENTICAL(\u0026digest, \u0026_8$$7)) { // \u003c-- non-constant-time\n ZEPHIR_THROW_EXCEPTION_DEBUG_STR(..., \"Hash does not match.\", \"phalcon/Encryption/Crypt.zep\", 247);\n```\n\n`ZEPHIR_IS_IDENTICAL` --\u003e `zephir_is_identical()` (`ext/kernel/operators.c:472`) --\u003e Zend `is_identical_function` --\u003e for equal-length strings a `memcmp` that exits on the first mismatching byte (data-dependent timing).\n\n\n\n### Impact\n\nThe HMAC is the integrity/authentication tag of Phalcon\u0027s authenticated-encryption scheme. A successful timing attack (Keyczar/CVE-2009-0654-style: fix the IV+ciphertext so the target tag is constant, then recover it byte-by-byte from response timing) yields a tag the attacker can attach to a chosen IV+ciphertext so that `decrypt()` accepts it as authentic, defeating the integrity guarantee. Combined with CFB malleability (flipping a ciphertext byte flips the corresponding plaintext byte), an attacker who recovers the forging capability can tamper with the decrypted contents the application trusts (e.g. encrypted cookies carrying authorization/identity state). There is no confidentiality break by itself.\n\n## Suggested fix\n\nReplace the identity comparison with the constant-time helper already used elsewhere in the framework. In `phalcon/Encryption/Crypt.zep:246`:\n\n```zephir\n// before\nif digest !== hash_hmac(hashAlgorithm, padded, decryptKey, true) {\n throw new Mismatch(\"Hash does not match.\");\n}\n// after\nif true !== hash_equals(hash_hmac(hashAlgorithm, padded, decryptKey, true), digest) {\n throw new Mismatch(\"Hash does not match.\");\n}\n```\n\n`hash_equals()` returns false for unequal-length inputs, so it also covers the truncated-tag case. Optional further hardening: verify the MAC before unpadding (functionally moot here because `cryptUnpadText` never throws) and consider migrating the default toward an AEAD mode such as `aes-256-gcm`.\n\nAddressed Issue: \n\n- https://github.com/phalcon/cphalcon/issues/17090\n\nPatched Stream: \n\n- https://github.com/phalcon/cphalcon/issues/17090",
"id": "GHSA-8jqh-95g6-7jpj",
"modified": "2026-08-28T16:01:05Z",
"published": "2026-08-28T16:01:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phalcon/cphalcon/security/advisories/GHSA-8jqh-95g6-7jpj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54736"
},
{
"type": "WEB",
"url": "https://github.com/phalcon/cphalcon/issues/17090"
},
{
"type": "WEB",
"url": "https://github.com/phalcon/cphalcon/pull/17091"
},
{
"type": "WEB",
"url": "https://github.com/phalcon/cphalcon/commit/ad53ab1b2e7ec59b3af92b0b37b8aaa099011137"
},
{
"type": "PACKAGE",
"url": "https://github.com/phalcon/cphalcon"
},
{
"type": "WEB",
"url": "https://github.com/phalcon/cphalcon/releases/tag/v5.14.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Phalcon: Non-constant-time HMAC verification in `Encryption\\Crypt::decrypt` (timing side-channel)"
}
GHSA-8VXV-2G8P-2249
Vulnerability from github – Published: 2022-05-24 21:33 – Updated: 2022-05-24 21:33Impact
Token comparison was not constant time, and could theorically be used to guess value of an TOTP token, and thus reuse it in the same time window. The attacker would have to know the password beforehand nonetheless.
Patches
Library now used constant-time comparison.
Workarounds
No.
For more information
If you have any questions or comments about this advisory: * Open an issue in totp-rs * Email us at cleo.rebert@gmail.com
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "totp-rs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-29185"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208"
],
"github_reviewed": true,
"github_reviewed_at": "2022-05-24T21:33:15Z",
"nvd_published_at": "2022-05-20T20:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nToken comparison was not constant time, and could theorically be used to guess value of an TOTP token, and thus reuse it in the same time window. The attacker would have to know the password beforehand nonetheless.\n\n### Patches\nLibrary now used constant-time comparison.\n\n### Workarounds\nNo.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [totp-rs](https://github.com/constantoine/totp-rs)\n* Email us at [cleo.rebert@gmail.com](mailto:cleo.rebert@gmail.com)\n",
"id": "GHSA-8vxv-2g8p-2249",
"modified": "2022-05-24T21:33:15Z",
"published": "2022-05-24T21:33:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/constantoine/totp-rs/security/advisories/GHSA-8vxv-2g8p-2249"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29185"
},
{
"type": "WEB",
"url": "https://github.com/constantoine/totp-rs/issues/13"
},
{
"type": "WEB",
"url": "https://github.com/constantoine/totp-rs/commit/1f1e1a6fe722deb1656f483b1367ea4be978db5b"
},
{
"type": "PACKAGE",
"url": "https://github.com/constantoine/totp-rs"
},
{
"type": "WEB",
"url": "https://github.com/constantoine/totp-rs/compare/v1.0...v1.1.0"
},
{
"type": "WEB",
"url": "https://github.com/constantoine/totp-rs/releases/tag/v1.1.0"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2022-0018.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Observable Timing Discrepancy in totp-rs"
}
GHSA-8W6W-PRH9-WR2J
Vulnerability from github – Published: 2025-04-02 09:30 – Updated: 2025-11-03 21:33Execution time for an unsuccessful login differs when using a non-existing username compared to using an existing one.
{
"affected": [],
"aliases": [
"CVE-2024-36469"
],
"database_specific": {
"cwe_ids": [
"CWE-208"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-02T07:15:40Z",
"severity": "LOW"
},
"details": "Execution time for an unsuccessful login differs when using a non-existing username compared to using an existing one.",
"id": "GHSA-8w6w-prh9-wr2j",
"modified": "2025-11-03T21:33:27Z",
"published": "2025-04-02T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36469"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00027.html"
},
{
"type": "WEB",
"url": "https://support.zabbix.com/browse/ZBX-26255"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/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"
}
]
}
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.