Common Weakness Enumeration

CWE-208

Allowed

Observable Timing Discrepancy

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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-MQ6F-5XH5-HGCF

Vulnerability from github – Published: 2023-10-10 21:29 – Updated: 2023-11-09 16:38
VLAI
Summary
Harbor timing attack risk
Details

In the Harbor jobservice container, the comparison of secrets in the authenticator type is prone to timing attacks. The vulnerability occurs due to the following code: https://github.com/goharbor/harbor/blob/aaea068cceb4063ab89313d9785f2b40f35b0d63/src/jobservice/api/authenticator.go#L69-L69 To avoid this issue, constant time comparison should be used.

subtle.ConstantTimeCompare([]byte(expectedSecret), []byte(secret)) == 0

Impact

This attack might be possible theoretically, but no workable proof of concept is available, and access complexity is set at High. The jobservice exposes these APIs

Create a job task --- POST /api/v1/jobs    
Get job task information --- GET /api/v1/jobs/{job_id}
Stop job task ---  POST /api/v1/jobs/{job_id}
Get job log task ---  GET /api/v1/jobs/{job_id}/log
Get job execution --- GET /api/v1/jobs/{job_id}/executions
Get job stats ---  GET /api/v1/stats
Get job service configuration ---  GET /api/v1/config

It is used to create jobs/stop job tasks and retrieve job task information. If an attacker obtains the secrets, it is possible to retrieve the job information, create a job, or stop a job task.

The following versions of Harbor are involved: <=Harbor 2.8.2, <=Harbor 2.7.2, <= Harbor 2.6.x, <=Harbor 1.10.17

Patches

Harbor 2.8.3, Harbor 2.7.3, Harbor 1.10.18

Workarounds

Because the jobservice only exposes HTTP service to harbor-core containers, blocking any inbound traffic from the external network to the jobservice container can reduce the risk.

Credits

Thanks to Porcupiney Hairs for reporting this issue.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-20902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-10T21:29:02Z",
    "nvd_published_at": "2023-11-09T01:15:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Harbor jobservice container, the comparison of secrets in the authenticator type is prone to timing attacks. The vulnerability occurs due to the following code: https://github.com/goharbor/harbor/blob/aaea068cceb4063ab89313d9785f2b40f35b0d63/src/jobservice/api/authenticator.go#L69-L69\nTo avoid this issue, constant time comparison should be used.\n```\nsubtle.ConstantTimeCompare([]byte(expectedSecret), []byte(secret)) == 0\n```\n\n### Impact\nThis attack might be possible theoretically, but no workable proof of concept is available, and access complexity is set at High.\nThe jobservice exposes these APIs\n```\nCreate a job task --- POST /api/v1/jobs    \nGet job task information --- GET /api/v1/jobs/{job_id}\nStop job task ---  POST /api/v1/jobs/{job_id}\nGet job log task ---  GET /api/v1/jobs/{job_id}/log\nGet job execution --- GET /api/v1/jobs/{job_id}/executions\nGet job stats ---  GET /api/v1/stats\nGet job service configuration ---  GET /api/v1/config\n```\nIt is used to create jobs/stop job tasks and retrieve job task information.  If an attacker obtains the secrets, it is possible to retrieve the job information, create a job, or stop a job task. \n\nThe following versions of Harbor are involved:\n\u003c=Harbor 2.8.2, \u003c=Harbor 2.7.2, \u003c= Harbor 2.6.x, \u003c=Harbor 1.10.17\n\n\n### Patches\nHarbor 2.8.3, Harbor 2.7.3, Harbor 1.10.18\n\n### Workarounds\nBecause the jobservice only exposes HTTP service to harbor-core containers, blocking any inbound traffic from the external network to the jobservice container can reduce the risk.\n\n### Credits\nThanks to Porcupiney Hairs for reporting this issue.\n",
  "id": "GHSA-mq6f-5xh5-hgcf",
  "modified": "2023-11-09T16:38:40Z",
  "published": "2023-10-10T21:29:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/security/advisories/GHSA-mq6f-5xh5-hgcf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20902"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goharbor/harbor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/blob/aaea068cceb4063ab89313d9785f2b40f35b0d63/src/jobservice/api/authenticator.go#L69-L69"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/releases/tag/v1.10.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/releases/tag/v2.7.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/releases/tag/v2.8.3"
    }
  ],
  "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"
    }
  ],
  "summary": "Harbor timing attack risk"
}

GHSA-MQC9-9P37-H763

Vulnerability from github – Published: 2025-10-21 15:31 – Updated: 2025-10-21 18:30
VLAI
Details

Mbed TLS through 3.6.4 has an Observable Timing Discrepancy.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-59438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-21T15:15:39Z",
    "severity": "MODERATE"
  },
  "details": "Mbed TLS through 3.6.4 has an Observable Timing Discrepancy.",
  "id": "GHSA-mqc9-9p37-h763",
  "modified": "2025-10-21T18:30:33Z",
  "published": "2025-10-21T15:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59438"
    },
    {
      "type": "WEB",
      "url": "https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2025-10-invalid-padding-error"
    },
    {
      "type": "WEB",
      "url": "https://mbed-tls.readthedocs.io/en/latest/tech-updates/security-advisories"
    }
  ],
  "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-MV3X-9FW3-QF38

Vulnerability from github – Published: 2026-03-27 09:31 – Updated: 2026-06-30 03:36
VLAI
Details

Doveadm credentials are verified using direct comparison which is susceptible to timing oracle attack. An attacker can use this to determine the configured credentials. Figuring out the credential will lead into full access to the affected component. Limit access to the doveadm http service port, install fixed version. No publicly available exploits are known.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-27856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T09:16:19Z",
    "severity": "HIGH"
  },
  "details": "Doveadm credentials are verified using direct comparison which is susceptible to timing oracle attack. An attacker can use this to determine the configured credentials. Figuring out the credential will lead into full access to the affected component. Limit access to the doveadm http service port, install fixed version. No publicly available exploits are known.",
  "id": "GHSA-mv3x-9fw3-qf38",
  "modified": "2026-06-30T03:36:02Z",
  "published": "2026-03-27T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27856"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:26564"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-27856"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2452171"
    },
    {
      "type": "WEB",
      "url": "https://documentation.open-xchange.com/dovecot/security/advisories/csaf/2026/oxdc-adv-2026-0001.json"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-27856.json"
    }
  ],
  "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"
    }
  ]
}

GHSA-MW4G-W7HH-RJPC

Vulnerability from github – Published: 2024-11-01 18:31 – Updated: 2024-11-01 18:31
VLAI
Details

IBM TXSeries for Multiplatforms 10.1 could allow an attacker to determine valid usernames due to an observable timing discrepancy which could be used in further attacks against the system.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-41741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-208"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-01T17:15:16Z",
    "severity": "MODERATE"
  },
  "details": "IBM TXSeries for Multiplatforms 10.1 could allow an attacker to determine valid usernames due to an observable timing discrepancy which could be used in further attacks against the system.",
  "id": "GHSA-mw4g-w7hh-rjpc",
  "modified": "2024-11-01T18:31:33Z",
  "published": "2024-11-01T18:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41741"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7174572"
    }
  ],
  "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-MXCC-7H5M-X57R

Vulnerability from github – Published: 2022-07-28 00:00 – Updated: 2024-01-05 13:44
VLAI
Summary
Jenkins GitHub plugin uses weak webhook signature function
Details

Jenkins GitHub Plugin 1.34.4 and earlier uses a non-constant time comparison function when checking whether the provided and computed webhook signatures are equal, allowing attackers to use statistical methods to obtain a valid webhook signature. GitHub Plugin 1.34.5 uses a constant-time comparison when validating the webhook signature.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.34.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.coravy.hudson.plugins.github:github"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.34.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-208"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-24T20:44:20Z",
    "nvd_published_at": "2022-07-27T15:15:00Z",
    "severity": "LOW"
  },
  "details": "Jenkins GitHub Plugin 1.34.4 and earlier uses a non-constant time comparison function when checking whether the provided and computed webhook signatures are equal, allowing attackers to use statistical methods to obtain a valid webhook signature. GitHub Plugin 1.34.5 uses a constant-time comparison when validating the webhook signature.\n\n",
  "id": "GHSA-mxcc-7h5m-x57r",
  "modified": "2024-01-05T13:44:46Z",
  "published": "2022-07-28T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36885"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/github-plugin/commit/11d1d79ebf85248dc43432389746c1ecc3452b6a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/github-plugin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/github-plugin/releases/tag/v1.34.5"
    },
    {
      "type": "WEB",
      "url": "https://plugins.jenkins.io/github-issues"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-07-27/#SECURITY-1849"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/07/27/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins GitHub plugin uses weak webhook signature function"
}

GHSA-P6JW-R4V7-58QX

Vulnerability from github – Published: 2026-06-26 18:33 – Updated: 2026-06-26 18:33
VLAI
Details

An observable timing discrepancy in the ASP could allow a privileged attacker to perform a brute-force attack against the hash message authentication code, allowing the input of an arbitrary message, potentially leading to a loss of data integrity.

Severity
5.6 (Medium)
CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-20572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T16:16:28Z",
    "severity": "MODERATE"
  },
  "details": "An observable timing discrepancy in the ASP could allow a privileged attacker to perform a brute-force attack against the hash message authentication code, allowing the input of an arbitrary message, potentially leading to a loss of data integrity.",
  "id": "GHSA-p6jw-r4v7-58qx",
  "modified": "2026-06-26T18:33:58Z",
  "published": "2026-06-26T18:33:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20572"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4012.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-P7JQ-V8JP-J424

Vulnerability from github – Published: 2021-04-19 14:50 – Updated: 2021-04-16 23:15
VLAI
Summary
Timing side channel vulnerability in endpoint request handler in Vaadin 15-19
Details

Non-constant-time comparison of CSRF tokens in endpoint request handler in com.vaadin:flow-server versions 3.0.0 through 5.0.3 (Vaadin 15.0.0 through 18.0.6), and com.vaadin:fusion-endpoint version 6.0.0 (Vaadin 19.0.0) allows attacker to guess a security token for Fusion endpoints via timing attack.

  • https://vaadin.com/security/cve-2021-31406
Severity
4.0 (Medium)
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:flow-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "5.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.vaadin:flow-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "6.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31406"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-208"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-16T23:15:49Z",
    "nvd_published_at": "2021-04-23T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Non-constant-time comparison of CSRF tokens in endpoint request handler in `com.vaadin:flow-server` versions 3.0.0 through 5.0.3 (Vaadin 15.0.0 through 18.0.6), and com.vaadin:fusion-endpoint version 6.0.0 (Vaadin 19.0.0) allows attacker to guess a security token for Fusion endpoints via timing attack.\n\n- https://vaadin.com/security/cve-2021-31406",
  "id": "GHSA-p7jq-v8jp-j424",
  "modified": "2021-04-16T23:15:49Z",
  "published": "2021-04-19T14:50:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/flow/security/advisories/GHSA-p7jq-v8jp-j424"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vaadin/flow/pull/10157"
    },
    {
      "type": "WEB",
      "url": "https://vaadin.com/security/cve-2021-31406"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Timing side channel vulnerability in endpoint request handler in Vaadin 15-19"
}

GHSA-P953-3J66-HG45

Vulnerability from github – Published: 2025-01-28 09:32 – Updated: 2025-01-28 20:40
VLAI
Summary
Apache Hive vulnerable to Observable Timing Discrepancy and Authentication Bypass by Spoofing
Details

Use of Arrays.equals() in LlapSignerImpl in Apache Hive to compare message signatures allows attacker to forge a valid signature for an arbitrary message byte by byte. The attacker should be an authorized user of the product to perform this attack. Users are recommended to upgrade to version 4.0.0, which fixes this issue.

The problem occurs when an application doesn’t use a constant-time algorithm for validating a signature. The method Arrays.equals() returns false right away when it sees that one of the input’s bytes are different. It means that the comparison time depends on the contents of the arrays. This little thing may allow an attacker to forge a valid signature for an arbitrary message byte by byte. So it might allow malicious users to submit splits/work with selected signatures to LLAP without running as a privileged user, potentially leading to DDoS attack.

More details in the reference section.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.hive:hive-llap-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-23953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-28T20:40:21Z",
    "nvd_published_at": "2025-01-28T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Use of Arrays.equals() in LlapSignerImpl in\u00a0Apache Hive to compare message signatures\u00a0allows attacker to forge a valid signature for an arbitrary message byte by byte. The attacker should be an authorized user of the product to perform this attack.\u00a0Users are recommended to upgrade to version 4.0.0, which fixes this issue.\n\nThe problem occurs when an application doesn\u2019t use a constant-time algorithm for validating a signature.\u00a0The method Arrays.equals()\u00a0returns false\u00a0right away when it sees that one of the input\u2019s bytes are different. It means that the comparison time depends on the contents of the arrays. This little thing may allow an attacker to forge a valid signature for an arbitrary message byte by byte.\u00a0So it might allow malicious users to submit splits/work with selected signatures to LLAP without running as a privileged user, potentially leading to DDoS attack.\n\nMore details in the reference section.",
  "id": "GHSA-p953-3j66-hg45",
  "modified": "2025-01-28T20:40:21Z",
  "published": "2025-01-28T09:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/hive/commit/b418e3c9f479ba8e7d31e6470306111002ffa809"
    },
    {
      "type": "WEB",
      "url": "https://blog.gypsyengineer.com/en/security/preventing-timing-attacks-with-codeql.html"
    },
    {
      "type": "WEB",
      "url": "https://cqr.company/web-vulnerabilities/timing-attacks"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/hive"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/HIVE-28030"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/0nloywj49nbtlc6l3c6363qvq7o1ztb7"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/01/28/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Hive vulnerable to Observable Timing Discrepancy and Authentication Bypass by Spoofing"
}

GHSA-PJV4-3C63-699F

Vulnerability from github – Published: 2026-05-06 22:32 – Updated: 2026-05-14 20:42
VLAI
Summary
opentelemetry-collector-contrib's azureauthextension Authenticate method does not validate bearer tokens, allowing auth bypass via replay
Details

Summary

A server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied Host header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching Host. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).

Severity: High (CVSS 8.1). See "Threat model" below for the preconditions that inform that score.

Root cause

The extension implements both extensionauth.HTTPClient (outbound: "attach my identity to requests I send") and extensionauth.Server (inbound: "validate a credential someone presented to me"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires credential.GetToken(); the inbound path requires JWT signature verification against the issuer's JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist — none of which the extension does.

PR #39178 ("Implement extensionauth.HTTPClient and extensionauth.Server interface functions") added the Server path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound HTTPClient path (used by Azure exporters) is unaffected.

Details

Vulnerable code — extension/azureauthextension/extension.go:208–235:

func (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) {
    auth, err := getHeaderValue("Authorization", headers)
    if err != nil { return ctx, err }
    host, err := getHeaderValue("Host", headers)
    if err != nil { return ctx, err }

    authFormat := strings.Split(auth, " ")
    if len(authFormat) != 2 { /* ... */ }
    if authFormat[0] != "Bearer" { /* ... */ }

    token, err := a.getTokenForHost(ctx, host)   // asks the collector's own identity
    if err != nil { return ctx, err }
    if authFormat[1] != token {                  // string comparison, not JWT validation
        return ctx, errors.New("unauthorized: invalid token")
    }
    return ctx, nil
}

And getTokenForHost at extension.go:187–206:

options := policy.TokenRequestOptions{
    Scopes: []string{
        fmt.Sprintf("https://%s/.default", host),   // client-supplied Host chooses scope
    },
}

Two independent problems compose here:

1. No JWT validation. Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking iss, aud, exp, nbf, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity — a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an Authorization: header — can replay it directly.

2. Attacker-controlled audience. The scope used to mint the "expected" token comes from the client-supplied Host header: https://<Host>/.default. The azcore credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting Host accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration — ARM, Graph, Key Vault, a different Storage account — authenticates to the collector.

The correct primitive is a real JWT validator — e.g. github.com/coreos/go-oidc/v3 pointed at the tenant's discovery endpoint, with audience and issuer pinned server-side from configuration, never derived from request headers.

Proof of concept

Both variants assume a collector running with azureauthextension v0.124.0–v0.150.0, configured with any credential mode and referenced from a receiver's auth: block:

extensions:
  azure_auth:
    managed_identity:
      client_id: ${CLIENT_ID}

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        auth:
          authenticator: azure_auth

service:
  extensions: [azure_auth]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [debug]

Variant A — Replay (same scope)

The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for https://management.azure.com/.default and receive the same cached token. The attacker replays:

POST /v1/traces HTTP/1.1
Host: management.azure.com
Authorization: Bearer eyJ...            # token minted for management.azure.com
Content-Type: application/json

{"resourceSpans":[...]}

Authenticate calls getTokenForHost(ctx, "management.azure.com"), receives the identical cached token, and the string comparison passes.

Variant B — Scope confusion (the stronger case)

The attacker holds a token for the SP issued for a different Azure resource — say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets Host to match:

POST /v1/traces HTTP/1.1
Host: vault.azure.net
Authorization: Bearer eyJ...            # token minted for vault.azure.net
Content-Type: application/json

{"resourceSpans":[...]}

Authenticate calls getTokenForHost(ctx, "vault.azure.net"). The collector's credential mints (or returns cached) a token for https://vault.azure.net/.default — the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault."

In a correct implementation, the JWT's aud would be pinned server-side to a value unrelated to Host, and Variant B would fail regardless of what the attacker put in the Host header.

A small Go reproducer can be built around the extension's own test harness: the existing TestAuthenticate in extension_test.go is effectively a demonstration of the broken behavior — it passes when the client-supplied token equals the server-side token for the given Host, which is exactly what an attacker arranges.

Impact

Vulnerability class: Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature — no JWT validation), CWE-294 (Authentication Bypass by Capture-replay — tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing — client Host header chooses the expected scope).

Threat model / precondition. The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an Authorization: header from any prior legitimate request for the SP. This is what drives the 8.1 score — the precondition is non-trivial but is routine in multi-workload Azure environments.

Who is impacted. Any operator of opentelemetry-collector-contrib v0.124.0 through v0.150.0 who configured azureauthextension on a receiver's auth: block. This applies to both HTTP and gRPC receivers — gRPC receivers surface :authority as Host through the collector's header handling, so the same exploit path applies there.

Deployments most at risk: - Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source). - Deployments that forward Authorization: headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL — typically several hours for MI tokens, not the 60-minute user-token window). - Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension.

Consequences. Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals.

Not impacted. The extension's outbound extensionauth.HTTPClient path, used by Azure exporters, is unaffected. Operators who use azureauthextension only on exporters can continue doing so.

Mitigation

Until a patched release is available, remove azure_auth from any receiver auth: blocks. For genuine Entra ID JWT validation on OTLP receivers, use oidcauthextension pointed at the tenant discovery URL, with audience pinned from configuration:

extensions:
  oidc:
    issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0
    audience: <expected-api-audience>

Resources

  • PR introducing the vulnerable server-side path: #39178
  • Affected versions: v0.124.0 – v0.150.0

Assisted-by: Opus 4.7

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/open-telemetry/opentelemetry-collector-contrib/extension/azureauthextension"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.124.0"
            },
            {
              "last_affected": "0.150.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42602"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-287",
      "CWE-290",
      "CWE-294",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T22:32:43Z",
    "nvd_published_at": "2026-05-13T21:16:47Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA server-side authentication bypass in `azureauthextension` allows any party who holds a single valid Azure access token for *any scope the collector\u0027s configured identity can mint for* to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth`. The extension\u0027s `Authenticate` method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client\u0027s token to the result with string equality \u2014 and the scope for that server-side token request is taken from the client-supplied `Host` header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching `Host`. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).\n\nSeverity: High (CVSS 8.1). See \"Threat model\" below for the preconditions that inform that score.\n\n### Root cause\n\nThe extension implements both `extensionauth.HTTPClient` (outbound: \"attach my identity to requests I send\") and `extensionauth.Server` (inbound: \"validate a credential someone presented to me\"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires `credential.GetToken()`; the inbound path requires JWT signature verification against the issuer\u0027s JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist \u2014 none of which the extension does.\n\nPR #39178 (\"Implement extensionauth.HTTPClient and extensionauth.Server interface functions\") added the `Server` path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound `HTTPClient` path (used by Azure exporters) is unaffected.\n\n### Details\n\nVulnerable code \u2014 `extension/azureauthextension/extension.go:208\u2013235`:\n\n```go\nfunc (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) {\n    auth, err := getHeaderValue(\"Authorization\", headers)\n    if err != nil { return ctx, err }\n    host, err := getHeaderValue(\"Host\", headers)\n    if err != nil { return ctx, err }\n\n    authFormat := strings.Split(auth, \" \")\n    if len(authFormat) != 2 { /* ... */ }\n    if authFormat[0] != \"Bearer\" { /* ... */ }\n\n    token, err := a.getTokenForHost(ctx, host)   // asks the collector\u0027s own identity\n    if err != nil { return ctx, err }\n    if authFormat[1] != token {                  // string comparison, not JWT validation\n        return ctx, errors.New(\"unauthorized: invalid token\")\n    }\n    return ctx, nil\n}\n```\n\nAnd `getTokenForHost` at `extension.go:187\u2013206`:\n\n```go\noptions := policy.TokenRequestOptions{\n    Scopes: []string{\n        fmt.Sprintf(\"https://%s/.default\", host),   // client-supplied Host chooses scope\n    },\n}\n```\n\nTwo independent problems compose here:\n\n**1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The \"expected\" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector\u0027s identity \u2014 a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header \u2014 can replay it directly.\n\n**2. Attacker-controlled audience.** The scope used to mint the \"expected\" token comes from the client-supplied `Host` header: `https://\u003cHost\u003e/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration \u2014 ARM, Graph, Key Vault, a different Storage account \u2014 authenticates to the collector.\n\nThe correct primitive is a real JWT validator \u2014 e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant\u0027s discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers.\n\n### Proof of concept\n\nBoth variants assume a collector running with `azureauthextension` v0.124.0\u2013v0.150.0, configured with any credential mode and referenced from a receiver\u0027s `auth:` block:\n\n```yaml\nextensions:\n  azure_auth:\n    managed_identity:\n      client_id: ${CLIENT_ID}\n\nreceivers:\n  otlp:\n    protocols:\n      http:\n        endpoint: 0.0.0.0:4318\n        auth:\n          authenticator: azure_auth\n\nservice:\n  extensions: [azure_auth]\n  pipelines:\n    traces:\n      receivers: [otlp]\n      exporters: [debug]\n```\n\n#### Variant A \u2014 Replay (same scope)\n\nThe attacker controls a workload that shares the collector\u0027s managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays:\n\n```\nPOST /v1/traces HTTP/1.1\nHost: management.azure.com\nAuthorization: Bearer eyJ...            # token minted for management.azure.com\nContent-Type: application/json\n\n{\"resourceSpans\":[...]}\n```\n\n`Authenticate` calls `getTokenForHost(ctx, \"management.azure.com\")`, receives the identical cached token, and the string comparison passes.\n\n#### Variant B \u2014 Scope confusion (the stronger case)\n\nThe attacker holds a token for the SP issued for a *different* Azure resource \u2014 say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match:\n\n```\nPOST /v1/traces HTTP/1.1\nHost: vault.azure.net\nAuthorization: Bearer eyJ...            # token minted for vault.azure.net\nContent-Type: application/json\n\n{\"resourceSpans\":[...]}\n```\n\n`Authenticate` calls `getTokenForHost(ctx, \"vault.azure.net\")`. The collector\u0027s credential mints (or returns cached) a token for `https://vault.azure.net/.default` \u2014 the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on \"proof of identity to Key Vault.\"\n\nIn a correct implementation, the JWT\u0027s `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header.\n\nA small Go reproducer can be built around the extension\u0027s own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior \u2014 it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges.\n\n### Impact\n\n**Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature \u2014 no JWT validation), CWE-294 (Authentication Bypass by Capture-replay \u2014 tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing \u2014 client `Host` header chooses the expected scope).\n\n**Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector\u0027s SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score \u2014 the precondition is non-trivial but is routine in multi-workload Azure environments.\n\n**Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver\u0027s `auth:` block. This applies to both HTTP and gRPC receivers \u2014 gRPC receivers surface `:authority` as `Host` through the collector\u0027s header handling, so the same exploit path applies there.\n\n**Deployments most at risk:**\n- Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source).\n- Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL \u2014 typically several hours for MI tokens, not the 60-minute user-token window).\n- Multi-tenant environments where different customers\u0027 telemetry converges at a collector protected by this extension.\n\n**Consequences.** Unauthenticated (from the collector\u0027s perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector\u0027s exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals.\n\n**Not impacted.** The extension\u0027s outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so.\n\n### Mitigation\n\nUntil a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration:\n\n```yaml\nextensions:\n  oidc:\n    issuer_url: https://login.microsoftonline.com/\u003ctenant-id\u003e/v2.0\n    audience: \u003cexpected-api-audience\u003e\n```\n\n### Resources\n\n- PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178)\n- Affected versions: v0.124.0 \u2013 v0.150.0\n\nAssisted-by: Opus 4.7",
  "id": "GHSA-pjv4-3c63-699f",
  "modified": "2026-05-14T20:42:40Z",
  "published": "2026-05-06T22:32:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/GHSA-pjv4-3c63-699f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42602"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-collector-contrib"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "opentelemetry-collector-contrib\u0027s azureauthextension Authenticate method does not validate bearer tokens, allowing auth bypass via replay"
}

GHSA-Q65W-FG65-79F4

Vulnerability from github – Published: 2025-03-14 19:55 – Updated: 2025-03-19 15:28
VLAI
Summary
Post-Quantum Secure Feldman's Verifiable Secret Sharing has Timing Side-Channels in Matrix Operations
Details

Description:

The feldman_vss library contains timing side-channel vulnerabilities in its matrix operations, specifically within the _find_secure_pivot function and potentially other parts of _secure_matrix_solve. These vulnerabilities are due to Python's execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme.

The _find_secure_pivot function, used during Gaussian elimination in _secure_matrix_solve, attempts to find a non-zero pivot element. However, the conditional statement if matrix[row][col] != 0 and row_random < min_value: has execution time that depends on the value of matrix[row][col]. This timing difference can be exploited by an attacker.

The constant_time_compare function in this file also does not provide a constant-time guarantee.

This advisory formalizes the timing side-channel vulnerabilities already documented in the library's "Known Security Vulnerabilities" section. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients.

An attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments.

Impact:

Successful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme. This could lead to a complete compromise of the shared secret.

References:

Remediation:

As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. The advisory recommends:

  1. SHORT TERM: Consider using this library only in environments where timing measurements by attackers are infeasible.

  2. MEDIUM TERM: Implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C.

  3. LONG TERM: Wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.

Note that the usage of random.Random() identified in the _refresh_shares_additive function is intentional and secure as documented in the "False-Positive Vulnerabilities" section of the code, and should not be considered part of this vulnerability.

Severity
5.8 (Medium)
CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PostQuantum-Feldman-VSS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.8.0b2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-29780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-208",
      "CWE-385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-14T19:55:10Z",
    "nvd_published_at": "2025-03-14T18:15:32Z",
    "severity": "MODERATE"
  },
  "details": "**Description:**\n\nThe `feldman_vss` library contains timing side-channel vulnerabilities in its matrix operations, specifically within the `_find_secure_pivot` function and potentially other parts of `_secure_matrix_solve`. These vulnerabilities are due to Python\u0027s execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme.\n\nThe `_find_secure_pivot` function, used during Gaussian elimination in `_secure_matrix_solve`, attempts to find a non-zero pivot element. However, the conditional statement `if matrix[row][col] != 0 and row_random \u003c min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker.\n\nThe `constant_time_compare` function in this file also does not provide a constant-time guarantee.\n\nThis advisory formalizes the timing side-channel vulnerabilities already documented in the library\u0027s \"Known Security Vulnerabilities\" section. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients.\n\nAn attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments.\n\n**Impact:**\n\nSuccessful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme.  This could lead to a complete compromise of the shared secret.\n\n**References:**\n\n*   File: `feldman_vss.py`\n*   Function: `_find_secure_pivot`\n*   Function: `_secure_matrix_solve`\n*   Function: `constant_time_compare`\n*   [Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (1996)](https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf) - A seminal paper on timing attacks.\n*   [Side-Channel Attacks](https://en.wikipedia.org/wiki/Side-channel_attack) - Wikipedia article on side-channel attacks.\n\n**Remediation:**\n\nAs acknowledged in the library\u0027s documentation, these vulnerabilities cannot be adequately addressed in pure Python. The advisory recommends:\n\n1. SHORT TERM: Consider using this library only in environments where timing measurements by attackers are infeasible.\n\n2. MEDIUM TERM: Implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C.\n\n3. LONG TERM: Wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.\n\nNote that the usage of random.Random() identified in the _refresh_shares_additive function is intentional and secure as documented in the \"False-Positive Vulnerabilities\" section of the code, and should not be considered part of this vulnerability.",
  "id": "GHSA-q65w-fg65-79f4",
  "modified": "2025-03-19T15:28:08Z",
  "published": "2025-03-14T19:55:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS/security/advisories/GHSA-q65w-fg65-79f4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29780"
    },
    {
      "type": "WEB",
      "url": "https://en.wikipedia.org/wiki/Side-channel_attack"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS"
    },
    {
      "type": "WEB",
      "url": "https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Post-Quantum Secure Feldman\u0027s Verifiable Secret Sharing has Timing Side-Channels in Matrix Operations"
}

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.

← Back to the CWE list