CWE-345
DiscouragedInsufficient Verification of Data Authenticity
Abstraction: Class · Status: Draft
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
933 vulnerabilities reference this CWE, most recent first.
GHSA-W8HX-F868-PVCH
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2024-09-26 14:51A flaw was found in openstack-neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Source: OpenStack project. Versions before openstack-neutron 15.3.3, openstack-neutron 16.3.1 and openstack-neutron 17.1.1 are affected.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "16.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "15.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "neutron"
},
"ranges": [
{
"events": [
{
"introduced": "17.0.0"
},
{
"fixed": "17.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20267"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-23T21:28:05Z",
"nvd_published_at": "2021-05-28T19:15:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in openstack-neutron\u0027s default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Source: OpenStack project. Versions before openstack-neutron 15.3.3, openstack-neutron 16.3.1 and openstack-neutron 17.1.1 are affected.",
"id": "GHSA-w8hx-f868-pvch",
"modified": "2024-09-26T14:51:10Z",
"published": "2022-05-24T19:03:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20267"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1934330"
},
{
"type": "PACKAGE",
"url": "https://github.com/openstack/neutron"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/neutron/PYSEC-2021-136.yaml"
},
{
"type": "WEB",
"url": "https://security.openstack.org/ossa/OSSA-2021-001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Openstack Neutron has Insufficient Verification of IPv6 addresses"
}
GHSA-W8JQ-XCQF-F792
Vulnerability from github – Published: 2025-03-10 18:26 – Updated: 2025-04-09 20:13Summary
PickleScan fails to detect malicious pickle files inside PyTorch model archives when certain ZIP file flag bits are modified. By flipping specific bits in the ZIP file headers, an attacker can embed malicious pickle files that remain undetected by PickleScan while still being successfully loaded by PyTorch's torch.load(). This can lead to arbitrary code execution when loading a compromised model.
Details
PickleScan relies on Python’s zipfile module to extract and scan files within ZIP-based model archives. However, certain flag bits in ZIP headers affect how files are interpreted, and some of these bits cause PickleScan to fail while leaving PyTorch’s loading mechanism unaffected.
By modifying the flag_bits field in the ZIP file entry, an attacker can:
- Embed a malicious pickle file (bad_file.pkl) in a PyTorch model archive.
- Flip specific bits (e.g., 0x1, 0x20, 0x40) in the ZIP metadata.
- Prevent PickleScan from scanning the archive due to errors raised by zipfile.
- Successfully load the model with torch.load(), which ignores the flag modifications.
This technique effectively bypasses PickleScan's security checks while maintaining model functionality.
PoC
import os
import zipfile
import torch
from picklescan import cli
def can_scan(zip_file):
try:
cli.print_summary(False, cli.scan_file_path(zip_file))
return True
except Exception:
return False
bit_to_flip = 0x1 # Change to 0x20 or 0x40 to test different flag bits
zip_file = "model.pth"
model = {'a': 1, 'b': 2, 'c': 3}
torch.save(model, zip_file)
with zipfile.ZipFile(zip_file, "r") as source:
flipped_name = f"flipped_{bit_to_flip}_{zip_file}"
with zipfile.ZipFile(flipped_name, "w") as dest:
bad_file = zipfile.ZipInfo("model/bad_file.pkl")
# Modify the ZIP flag bits
bad_file.flag_bits |= bit_to_flip
dest.writestr(bad_file, b"bad content")
for item in source.infolist():
dest.writestr(item, source.read(item.filename))
if model == torch.load(flipped_name, weights_only=False):
if not can_scan(flipped_name):
print('Found exploitable bit:', bit_to_flip)
else:
os.remove(flipped_name)
Impact
Severity: High
- Who is impacted? Any organization or user relying on PickleScan to detect malicious pickle files inside PyTorch models.
- What is the impact? Attackers can embed malicious pickle payloads inside PyTorch models that evade PickleScan's detection but still execute upon loading.
- Potential Exploits: This vulnerability could be exploited in machine learning supply chain attacks, allowing attackers to distribute backdoored models on platforms like Hugging Face or PyTorch Hub.
Recommendations
- Improve ZIP Handling: PickleScan should use a more relaxed ZIP parser marches on when encountering modified flag bits.
- Scan All Embedded Files Regardless of Flags: Ensure that files with altered metadata are still extracted and analyzed.
By addressing these issues, PickleScan can provide stronger protection against manipulated PyTorch model archives.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "picklescan"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-1945"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-10T18:26:35Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nPickleScan fails to detect malicious pickle files inside PyTorch model archives when certain ZIP file flag bits are modified. By flipping specific bits in the ZIP file headers, an attacker can embed malicious pickle files that remain undetected by PickleScan while still being successfully loaded by PyTorch\u0027s torch.load(). This can lead to arbitrary code execution when loading a compromised model.\n\n### Details\n\nPickleScan relies on Python\u2019s zipfile module to extract and scan files within ZIP-based model archives. However, certain flag bits in ZIP headers affect how files are interpreted, and some of these bits cause PickleScan to fail while leaving PyTorch\u2019s loading mechanism unaffected.\n\nBy modifying the flag_bits field in the ZIP file entry, an attacker can:\n\n- Embed a malicious pickle file (bad_file.pkl) in a PyTorch model archive.\n- Flip specific bits (e.g., 0x1, 0x20, 0x40) in the ZIP metadata.\n- Prevent PickleScan from scanning the archive due to errors raised by zipfile.\n- Successfully load the model with torch.load(), which ignores the flag modifications.\n\nThis technique effectively bypasses PickleScan\u0027s security checks while maintaining model functionality.\n\n### PoC\n```\nimport os\nimport zipfile\nimport torch\nfrom picklescan import cli\n\ndef can_scan(zip_file):\n try:\n cli.print_summary(False, cli.scan_file_path(zip_file))\n return True\n except Exception:\n return False\n\nbit_to_flip = 0x1 # Change to 0x20 or 0x40 to test different flag bits\n\nzip_file = \"model.pth\"\nmodel = {\u0027a\u0027: 1, \u0027b\u0027: 2, \u0027c\u0027: 3}\ntorch.save(model, zip_file)\n\nwith zipfile.ZipFile(zip_file, \"r\") as source:\n flipped_name = f\"flipped_{bit_to_flip}_{zip_file}\"\n with zipfile.ZipFile(flipped_name, \"w\") as dest:\n bad_file = zipfile.ZipInfo(\"model/bad_file.pkl\")\n \n # Modify the ZIP flag bits\n bad_file.flag_bits |= bit_to_flip\n \n dest.writestr(bad_file, b\"bad content\")\n for item in source.infolist():\n dest.writestr(item, source.read(item.filename))\n\nif model == torch.load(flipped_name, weights_only=False):\n if not can_scan(flipped_name):\n print(\u0027Found exploitable bit:\u0027, bit_to_flip)\nelse:\n os.remove(flipped_name)\n```\n\n### Impact\n\nSeverity: `High`\n\n- Who is impacted? Any organization or user relying on PickleScan to detect malicious pickle files inside PyTorch models.\n- What is the impact? Attackers can embed malicious pickle payloads inside PyTorch models that evade PickleScan\u0027s detection but still execute upon loading.\n- Potential Exploits: This vulnerability could be exploited in machine learning supply chain attacks, allowing attackers to distribute backdoored models on platforms like Hugging Face or PyTorch Hub.\n\n### Recommendations\n\n- Improve ZIP Handling: PickleScan should use a more relaxed ZIP parser marches on when encountering modified flag bits.\n- Scan All Embedded Files Regardless of Flags: Ensure that files with altered metadata are still extracted and analyzed.\n\nBy addressing these issues, PickleScan can provide stronger protection against manipulated PyTorch model archives.",
"id": "GHSA-w8jq-xcqf-f792",
"modified": "2025-04-09T20:13:19Z",
"published": "2025-03-10T18:26:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-w8jq-xcqf-f792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1945"
},
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/commit/e58e45e0d9e091159c1554f9b04828bbb40b9781"
},
{
"type": "PACKAGE",
"url": "https://github.com/mmaitre314/picklescan"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/picklescan/PYSEC-2025-21.yaml"
},
{
"type": "WEB",
"url": "https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-1945"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Zip Flag Bit Exploit Crashes Picklescan But Not PyTorch"
}
GHSA-W9H2-5JVC-WPV2
Vulnerability from github – Published: 2022-05-17 04:00 – Updated: 2025-04-12 12:55The Frontel protocol before 3 on RSI Video Technologies Videofied devices does not use integrity protection, which makes it easier for man-in-the-middle attackers to (1) initiate a false alarm or (2) deactivate an alarm by modifying the client-server data stream.
{
"affected": [],
"aliases": [
"CVE-2015-8254"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-12-27T03:59:00Z",
"severity": "MODERATE"
},
"details": "The Frontel protocol before 3 on RSI Video Technologies Videofied devices does not use integrity protection, which makes it easier for man-in-the-middle attackers to (1) initiate a false alarm or (2) deactivate an alarm by modifying the client-server data stream.",
"id": "GHSA-w9h2-5jvc-wpv2",
"modified": "2025-04-12T12:55:11Z",
"published": "2022-05-17T04:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8254"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/792004"
},
{
"type": "WEB",
"url": "http://cybergibbons.com/alarms-2/multiple-serious-vulnerabilities-in-rsi-videofieds-alarm-protocol"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WC65-HW3J-6GRM
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19JFrog Artifactory Pro 6.5.9 has Incorrect Access Control.
{
"affected": [],
"aliases": [
"CVE-2018-19971"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-16T19:29:00Z",
"severity": "CRITICAL"
},
"details": "JFrog Artifactory Pro 6.5.9 has Incorrect Access Control.",
"id": "GHSA-wc65-hw3j-6grm",
"modified": "2022-05-13T01:19:50Z",
"published": "2022-05-13T01:19:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19971"
},
{
"type": "WEB",
"url": "https://bintray.com/jfrog/artifactory-pro/jfrog-artifactory-pro-zip/6.5.13#release"
},
{
"type": "WEB",
"url": "https://lists.openwall.net/full-disclosure/2019/03/19/3"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/152137/JFrog-Artifactory-Pro-6.5.9-Signature-Validation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Mar/34"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107518"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WCC5-WX82-X4GX
Vulnerability from github – Published: 2022-05-13 01:04 – Updated: 2026-05-29 15:30A Insufficient Verification of Data Authenticity (CWE-345) vulnerability exists in the Modicon M221, all versions, which could cause a change of IPv4 configuration (IP address, mask and gateway) when remotely connected to the device.
{
"affected": [],
"aliases": [
"CVE-2018-7798"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-02T17:29:00Z",
"severity": "HIGH"
},
"details": "A Insufficient Verification of Data Authenticity (CWE-345) vulnerability exists in the Modicon M221, all versions, which could cause a change of IPv4 configuration (IP address, mask and gateway) when remotely connected to the device.",
"id": "GHSA-wcc5-wx82-x4gx",
"modified": "2026-05-29T15:30:21Z",
"published": "2022-05-13T01:04:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7798"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2018-270-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105970"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-WCCM-6VX2-7P8C
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2024-04-26 00:30PuTTY through 0.75 proceeds with establishing an SSH session even if it has never sent a substantive authentication response. This makes it easier for an attacker-controlled SSH server to present a later spoofed authentication prompt (that the attacker can use to capture credential data, and use that data for purposes that are undesired by the client user).
{
"affected": [],
"aliases": [
"CVE-2021-36367"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-09T21:15:00Z",
"severity": "HIGH"
},
"details": "PuTTY through 0.75 proceeds with establishing an SSH session even if it has never sent a substantive authentication response. This makes it easier for an attacker-controlled SSH server to present a later spoofed authentication prompt (that the attacker can use to capture credential data, and use that data for purposes that are undesired by the client user).",
"id": "GHSA-wccm-6vx2-7p8c",
"modified": "2024-04-26T00:30:35Z",
"published": "2022-05-24T19:07:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36367"
},
{
"type": "WEB",
"url": "https://git.tartarus.org/?p=simon/putty.git%3Ba=commit%3Bh=1dc5659aa62848f0aeb5de7bd3839fecc7debefa"
},
{
"type": "WEB",
"url": "https://git.tartarus.org/?p=simon/putty.git;a=commit;h=1dc5659aa62848f0aeb5de7bd3839fecc7debefa"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00016.html"
},
{
"type": "WEB",
"url": "https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5588"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WFQX-GJRF-G28R
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47Summary
Crossplane allows package signature verification to be configured via the ImageConfig mechanism. When enabled, the package manager uses cosign to verify that packages are correctly signed before pulling and installing them.
When a package is installed using a tag reference (e.g., a semantic version), a malicious OCI registry could serve a correctly signed image for verification, then subsequently serve an unsigned image for installation. This is possible because Crossplane resolves the tag reference separately for each step.
This vulnerability is relevant only for users who do all three of the following:
- Configure signature verification for packages,
- Install packages using tag references rather than digests, and
- Install packages from registries they do not control.
Mitigation
Installing packages by image digest rather than using tags avoids this issue.
Fix
The package manager has been updated to resolve tag references once and use the resulting digest for both signature verification and image fetching. This ensures that Crossplane pulls the same content that had its signature verified. The fix has been applied to Crossplane's main branch and backported to the v2.3 and v2.2 release branches; it will be released in v2.3.3 and v2.2.3.
Credits
This issue was reported, independently, by @bugbunny-research and @tonghuaroot.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/crossplane/crossplane/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0-rc.0"
},
{
"last_affected": "2.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/crossplane/crossplane/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/crossplane/crossplane"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.21.0-rc.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:55Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nCrossplane allows package signature verification to be configured via the `ImageConfig` mechanism. When enabled, the package manager uses cosign to verify that packages are correctly signed before pulling and installing them.\n\nWhen a package is installed using a tag reference (e.g., a semantic version), a malicious OCI registry could serve a correctly signed image for verification, then subsequently serve an unsigned image for installation. This is possible because Crossplane resolves the tag reference separately for each step.\n\nThis vulnerability is relevant only for users who do all three of the following:\n\n1. Configure signature verification for packages,\n2. Install packages using tag references rather than digests, and\n3. Install packages from registries they do not control.\n\n## Mitigation\n\nInstalling packages by image digest rather than using tags avoids this issue.\n\n## Fix\n\nThe package manager has been updated to resolve tag references once and use the resulting digest for both signature verification and image fetching. This ensures that Crossplane pulls the same content that had its signature verified. The fix has been applied to Crossplane\u0027s `main` branch and backported to the v2.3 and v2.2 release branches; it will be released in v2.3.3 and v2.2.3.\n\n## Credits\n\nThis issue was reported, independently, by @bugbunny-research and @tonghuaroot.",
"id": "GHSA-wfqx-gjrf-g28r",
"modified": "2026-06-19T20:47:55Z",
"published": "2026-06-19T20:47:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/crossplane/crossplane/security/advisories/GHSA-wfqx-gjrf-g28r"
},
{
"type": "PACKAGE",
"url": "https://github.com/crossplane/crossplane"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Crossplane: Signature verification TOCTOU allows installing unverified package content via mutable tag"
}
GHSA-WHQX-F9J3-CH6M
Vulnerability from github – Published: 2026-01-13 14:58 – Updated: 2026-01-13 14:58Impact
A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.
This vulnerability only affects users that provide a trusted root via --trusted-root or when fetched automatically from a TUF repository, when no trusted key material is provided via SIGSTORE_REKOR_PUBLIC_KEY. When using the default flag values in Cosign v3 to sign and verify (--use-signing-config=true and --new-bundle-format=true for signing, --new-bundle-format=true for verification), users are unaffected. Cosign v2 users are affected using the default flag values.
This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.
Steps to Reproduce
echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob
Patches
Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.
Workarounds
You can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.
Note that the example below works for cosign verify, cosign verify-blob,cosign verify-blob-attestation, andcosign verify-attestation`.
SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22703"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T14:58:50Z",
"nvd_published_at": "2026-01-10T07:16:03Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nA Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact\u0027s digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact\u0027s digest, the user\u0027s public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user\u0027s identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.\n\nThis vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.\n\nThis issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.\n\n#### Steps to Reproduce\n\n```\necho blob \u003e /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob\njq \".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)\" /tmp/bundle.1 \u003e /tmp/bundle.3\ncosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp=\u0027.*\u0027 --certificate-oidc-issuer-regexp=\u0027.*\u0027 /tmp/blob\n```\n\n### Patches\n\nUpgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.\n\n### Workarounds\n\nYou can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.\n\nNote that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.\n\n```\nSIGSTORE_REKOR_PUBLIC_KEY=\u003cpath to Rekor pub key\u003e cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=\u003cpath to bundle\u003e \u003cartifact\u003e\n```",
"id": "GHSA-whqx-f9j3-ch6m",
"modified": "2026-01-13T14:58:50Z",
"published": "2026-01-13T14:58:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/security/advisories/GHSA-whqx-f9j3-ch6m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22703"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/pull/4623"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/commit/6832fba4928c1ad69400235bbc41212de5006176"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/cosign"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cosign verification accepts any valid Rekor entry under certain conditions"
}
GHSA-WJ6Q-CHPV-MCRX
Vulnerability from github – Published: 2023-10-16 09:30 – Updated: 2023-10-19 00:10Insufficient Verification of Data Authenticity vulnerability in Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.8.0,
General user can view all user data like Admin account.
Users are advised to upgrade to Apache InLong's 1.9.0 or cherry-pick [1] to solve it.
[1] https://github.com/apache/inlong/pull/8623
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.inlong:inlong"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43666"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-17T14:23:07Z",
"nvd_published_at": "2023-10-16T09:15:10Z",
"severity": "MODERATE"
},
"details": "Insufficient Verification of Data Authenticity vulnerability in Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.8.0,\u00a0\n\nGeneral user can view all user data like Admin account.\n\nUsers are advised to upgrade to Apache InLong\u0027s 1.9.0 or cherry-pick [1] to solve it.\n\n[1]\u00a0 https://github.com/apache/inlong/pull/8623 \n\n",
"id": "GHSA-wj6q-chpv-mcrx",
"modified": "2023-10-19T00:10:11Z",
"published": "2023-10-16T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43666"
},
{
"type": "WEB",
"url": "https://github.com/apache/inlong/pull/8623"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/scbgh3ty3xcxm3q33r2t9f42gwwo1why"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Insufficient Verification of Data Authenticity in Apache InLong"
}
GHSA-WMJH-CPQJ-4V6X
Vulnerability from github – Published: 2025-05-29 15:31 – Updated: 2025-06-05 00:22A vulnerability classified as problematic has been found in gradio-app gradio up to 5.29.1. This affects the function is_valid_origin of the component CORS Handler. The manipulation of the argument localhost_aliases leads to origin validation error. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"last_affected": "5.29.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-5320"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-05T00:22:23Z",
"nvd_published_at": "2025-05-29T14:15:38Z",
"severity": "LOW"
},
"details": "A vulnerability classified as problematic has been found in gradio-app gradio up to 5.29.1. This affects the function is_valid_origin of the component CORS Handler. The manipulation of the argument localhost_aliases leads to origin validation error. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-wmjh-cpqj-4v6x",
"modified": "2025-06-05T00:22:23Z",
"published": "2025-05-29T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5320"
},
{
"type": "WEB",
"url": "https://gist.github.com/superboy-zjc/aa3dfa161d7b19d8a53ab4605792f2fe"
},
{
"type": "WEB",
"url": "https://gist.github.com/superboy-zjc/aa3dfa161d7b19d8a53ab4605792f2fe#proof-of-concept-poc"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310491"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310491"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.580250"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Gradio CORS Origin Validation Bypass Vulnerability"
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-148: Content Spoofing
An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. The term content spoofing is most often used to describe modification of web pages hosted by a target to display the adversary's content instead of the owner's content. However, any content can be spoofed, including the content of email messages, file transfers, or the content of other network communication protocols. Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g. intercepting and modifying a message between the sender and recipient). Usually, the adversary will attempt to hide the fact that the content has been modified, but in some cases, such as with web site defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud (if the content governs financial transactions), privacy violations, and other unwanted outcomes.
CAPEC-218: Spoofing of UDDI/ebXML Messages
An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.
CAPEC-701: Browser in the Middle (BiTM)
An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.