CWE-354
AllowedImproper Validation of Integrity Check Value
Abstraction: Base · Status: Draft
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
231 vulnerabilities reference this CWE, most recent first.
GHSA-M525-P4RF-7H93
Vulnerability from github – Published: 2024-01-29 12:30 – Updated: 2024-01-29 12:30Improper Input Validation vulnerability in the upload functionality for user avatars allows functionality misuse due to missing check of filetypes. This issue affects OTRS: from 7.0.X through 7.0.48, from 8.0.X through 8.0.37, from 2023 through 2023.1.1.
{
"affected": [],
"aliases": [
"CVE-2024-23790"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-29T10:15:08Z",
"severity": "LOW"
},
"details": "Improper Input Validation vulnerability in the upload functionality for user avatars allows functionality misuse due to missing check of filetypes.\nThis issue affects OTRS: from 7.0.X through 7.0.48, from 8.0.X through 8.0.37, from 2023 through 2023.1.1.\n\n",
"id": "GHSA-m525-p4rf-7h93",
"modified": "2024-01-29T12:30:20Z",
"published": "2024-01-29T12:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23790"
},
{
"type": "WEB",
"url": "https://otrs.com/release-notes/otrs-security-advisory-2024-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M6WW-2P98-RFP9
Vulnerability from github – Published: 2023-11-14 18:30 – Updated: 2024-10-18 15:31An improper validation of integrity check value vulnerability [CWE-354] in FortiOS 7.2.0 through 7.2.3, 7.0.0 through 7.0.12, 6.4 all versions, 6.2 all versions, 6.0 all versions and FortiProxy 7.2 all versions, 7.0 all versions, 2.0 all versions VMs may allow a local attacker with admin privileges to boot a malicious image on the device and bypass the filesystem integrity check in place.
{
"affected": [],
"aliases": [
"CVE-2023-28002"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-14T18:15:29Z",
"severity": "MODERATE"
},
"details": "An improper validation of integrity check value vulnerability [CWE-354] in FortiOS 7.2.0 through 7.2.3, 7.0.0 through 7.0.12, 6.4 all versions, 6.2 all versions, 6.0 all versions and FortiProxy 7.2 all versions, 7.0 all versions, 2.0 all versions VMs may allow a local attacker\u00a0with admin privileges to boot a malicious image on the device and bypass the filesystem integrity check in place.",
"id": "GHSA-m6ww-2p98-rfp9",
"modified": "2024-10-18T15:31:11Z",
"published": "2023-11-14T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28002"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-22-396"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M83X-3X2C-26Q8
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2025-04-20 03:47rsync 3.1.3-development before 2017-10-24 mishandles archaic checksums, which makes it easier for remote attackers to bypass intended access restrictions. NOTE: the rsync development branch has significant use beyond the rsync developers, e.g., the code has been copied for use in various GitHub projects.
{
"affected": [],
"aliases": [
"CVE-2017-15994"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-29T06:29:00Z",
"severity": "CRITICAL"
},
"details": "rsync 3.1.3-development before 2017-10-24 mishandles archaic checksums, which makes it easier for remote attackers to bypass intended access restrictions. NOTE: the rsync development branch has significant use beyond the rsync developers, e.g., the code has been copied for use in various GitHub projects.",
"id": "GHSA-m83x-3x2c-26q8",
"modified": "2025-04-20T03:47:50Z",
"published": "2022-05-13T01:44:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15994"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git%3Ba=commit%3Bh=7b8a4ecd6ff9cdf4e5d3850ebf822f1e989255b3"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git%3Ba=commit%3Bh=9a480deec4d20277d8e20bc55515ef0640ca1e55"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git%3Ba=commit%3Bh=c252546ceeb0925eb8a4061315e3ff0a8c55b48b"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git;a=commit;h=7b8a4ecd6ff9cdf4e5d3850ebf822f1e989255b3"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git;a=commit;h=9a480deec4d20277d8e20bc55515ef0640ca1e55"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=rsync.git;a=commit;h=c252546ceeb0925eb8a4061315e3ff0a8c55b48b"
}
],
"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-M9C9-MC2H-9WJW
Vulnerability from github – Published: 2025-01-14 22:04 – Updated: 2025-01-14 22:04Impact
Unintended permanent chain split affecting greater than or equal to 25% of the network, requiring hard fork (network partition requiring hard fork)
Lodestar does not verify checksum in snappy framing uncompressed chunks.
Vulnerability Details
In Req/Resp protocol the messages are encoded by using ssz_snappy encoding, which is a snappy framing compression over ssz encoded message.
In snappy framing format there are uncompressed chunks, each such chunk is prefixed with a checksum.
Let's see how golang implementation parses such chunks - https://github.com/golang/snappy/blob/master/decode.go#L176
case chunkTypeUncompressedData:
// Section 4.3. Uncompressed data (chunk type 0x01).
if chunkLen < checksumSize {
r.err = ErrCorrupt
return r.err
}
buf := r.buf[:checksumSize]
if !r.readFull(buf, false) {
return r.err
}
checksum := uint32(buf[0]) | uint32(buf[1])<<8 | uint32(buf[2])<<16 | uint32(buf[3])<<24
// Read directly into r.decoded instead of via r.buf.
n := chunkLen - checksumSize
if n > len(r.decoded) {
r.err = ErrCorrupt
return r.err
}
if !r.readFull(r.decoded[:n], false) {
return r.err
}
if crc(r.decoded[:n]) != checksum {
r.err = ErrCorrupt
return r.err
}
r.i, r.j = 0, n
continue
As you can see, if checksum is incorrect, decoder fails and returns error.
Now let's look at lodestar decoder https://github.com/ChainSafe/lodestar/blob/unstable/packages/reqresp/src/encodingStrategies/sszSnappy/snappyFrames/uncompress.ts#L17
uncompress(chunk: Uint8ArrayList): Uint8ArrayList | null {
this.buffer.append(chunk);
const result = new Uint8ArrayList();
while (this.buffer.length > 0) {
if (this.buffer.length < 4) break;
const type = getChunkType(this.buffer.get(0));
const frameSize = getFrameSize(this.buffer, 1);
if (this.buffer.length - 4 < frameSize) {
break;
}
const data = this.buffer.subarray(4, 4 + frameSize);
this.buffer.consume(4 + frameSize);
if (!this.state.foundIdentifier && type !== ChunkType.IDENTIFIER) {
throw "malformed input: must begin with an identifier";
}
if (type === ChunkType.IDENTIFIER) {
if (!Buffer.prototype.equals.call(data, IDENTIFIER)) {
throw "malformed input: bad identifier";
}
this.state.foundIdentifier = true;
continue;
}
if (type === ChunkType.COMPRESSED) {
result.append(uncompress(data.subarray(4)));
}
if (type === ChunkType.UNCOMPRESSED) {
1) result.append(data.subarray(4));
}
}
if (result.length === 0) {
return null;
}
return result;
}
As you can see, checksum is not verified, bytes are appended to 'result'
Proof of Concept
How to reproduce:
get poc via gist link and run it:
$ node dec1.mjs
checking chunk type=255
checking chunk type=1
got uncompressed chunk..
Decompressed ok 124 bytes
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@lodestar/reqresp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-14T22:04:02Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nUnintended permanent chain split affecting greater than or equal to 25% of the network, requiring hard fork (network partition requiring hard fork)\n\nLodestar does not verify checksum in snappy framing uncompressed chunks.\n\n### Vulnerability Details\nIn Req/Resp protocol the messages are encoded by using ssz_snappy encoding, which is a snappy framing compression over ssz encoded message.\n\nIn snappy framing format there are uncompressed chunks, each such chunk is prefixed with a checksum.\n\nLet\u0027s see how golang implementation parses such chunks - https://github.com/golang/snappy/blob/master/decode.go#L176\n\n```\n\tcase chunkTypeUncompressedData:\n\t\t\t// Section 4.3. Uncompressed data (chunk type 0x01).\n\t\t\tif chunkLen \u003c checksumSize {\n\t\t\t\tr.err = ErrCorrupt\n\t\t\t\treturn r.err\n\t\t\t}\n\t\t\tbuf := r.buf[:checksumSize]\n\t\t\tif !r.readFull(buf, false) {\n\t\t\t\treturn r.err\n\t\t\t}\n\t\t\tchecksum := uint32(buf[0]) | uint32(buf[1])\u003c\u003c8 | uint32(buf[2])\u003c\u003c16 | uint32(buf[3])\u003c\u003c24\n\t\t\t// Read directly into r.decoded instead of via r.buf.\n\t\t\tn := chunkLen - checksumSize\n\t\t\tif n \u003e len(r.decoded) {\n\t\t\t\tr.err = ErrCorrupt\n\t\t\t\treturn r.err\n\t\t\t}\n\t\t\tif !r.readFull(r.decoded[:n], false) {\n\t\t\t\treturn r.err\n\t\t\t}\n\t\t\tif crc(r.decoded[:n]) != checksum {\n\t\t\t\tr.err = ErrCorrupt\n\t\t\t\treturn r.err\n\t\t\t}\n\t\t\tr.i, r.j = 0, n\n\t\t\tcontinue\n```\n\nAs you can see, if checksum is incorrect, decoder fails and returns error.\n\nNow let\u0027s look at lodestar decoder https://github.com/ChainSafe/lodestar/blob/unstable/packages/reqresp/src/encodingStrategies/sszSnappy/snappyFrames/uncompress.ts#L17\n\n```\nuncompress(chunk: Uint8ArrayList): Uint8ArrayList | null {\n this.buffer.append(chunk);\n const result = new Uint8ArrayList();\n while (this.buffer.length \u003e 0) {\n if (this.buffer.length \u003c 4) break;\n\n const type = getChunkType(this.buffer.get(0));\n const frameSize = getFrameSize(this.buffer, 1);\n\n if (this.buffer.length - 4 \u003c frameSize) {\n break;\n }\n\n const data = this.buffer.subarray(4, 4 + frameSize);\n this.buffer.consume(4 + frameSize);\n\n if (!this.state.foundIdentifier \u0026\u0026 type !== ChunkType.IDENTIFIER) {\n throw \"malformed input: must begin with an identifier\";\n }\n\n if (type === ChunkType.IDENTIFIER) {\n if (!Buffer.prototype.equals.call(data, IDENTIFIER)) {\n throw \"malformed input: bad identifier\";\n }\n this.state.foundIdentifier = true;\n continue;\n }\n\n if (type === ChunkType.COMPRESSED) {\n result.append(uncompress(data.subarray(4)));\n }\n if (type === ChunkType.UNCOMPRESSED) {\n1) result.append(data.subarray(4));\n }\n }\n if (result.length === 0) {\n return null;\n }\n return result;\n }\n```\n\nAs you can see, checksum is not verified, bytes are appended to \u0027result\u0027\n\n### Proof of Concept\n\nHow to reproduce:\n\nget poc via [gist link](https://gist.github.com/gln7/aab55674431b1c8d42a59ccf9d7cbf60) and run it:\n\n```\n$ node dec1.mjs \nchecking chunk type=255\nchecking chunk type=1\ngot uncompressed chunk..\nDecompressed ok 124 bytes\n```\n",
"id": "GHSA-m9c9-mc2h-9wjw",
"modified": "2025-01-14T22:04:02Z",
"published": "2025-01-14T22:04:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ChainSafe/lodestar/security/advisories/GHSA-m9c9-mc2h-9wjw"
},
{
"type": "WEB",
"url": "https://github.com/ChainSafe/lodestar/commit/18a0d681dbcc51fb2ac9456f31e91f4e31a18300"
},
{
"type": "PACKAGE",
"url": "https://github.com/ChainSafe/lodestar"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Lodestar snappy checksum issue"
}
GHSA-MM73-86F9-5X5C
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2024-04-23 23:37It was found in Moodle before version 3.10.1, 3.9.4 and 3.8.7 that a insufficient capability checks in some grade related web services meant students were able to view other students grades.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.8"
},
{
"fixed": "3.8.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.9"
},
{
"fixed": "3.9.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.10"
},
{
"fixed": "3.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20184"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-23T23:37:58Z",
"nvd_published_at": "2021-01-28T19:15:00Z",
"severity": "MODERATE"
},
"details": "It was found in Moodle before version 3.10.1, 3.9.4 and 3.8.7 that a insufficient capability checks in some grade related web services meant students were able to view other students grades.",
"id": "GHSA-mm73-86f9-5x5c",
"modified": "2024-04-23T23:37:58Z",
"published": "2022-05-24T17:40:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20184"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=417167"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle Grade information disclosure in grade\u0027s external fetch functions"
}
GHSA-MMF8-487Q-P45M
Vulnerability from github – Published: 2026-03-11 14:55 – Updated: 2026-03-11 20:43Summary
A high-severity integrity bypass vulnerability existed in Striae's digital confirmation workflow prior to v3.0.0. Hash-only validation trusted manifest hash fields that could be modified together with package content, allowing tampered confirmation packages to pass integrity checks.
Impact
Confirmation package integrity could be bypassed because both content and hash values were mutable in the same trust boundary. An attacker with access to an exported package could alter confirmation data and recompute hashes so hash-only checks still passed.
This affects users relying on digital confirmations as an immutability and forensic chain-of-custody control.
Patches
Patched in v3.0.0.
Upgrade to:
- v3.0.0 or later
Security behavior added in v3.0.0: - Server-issued asymmetric signatures for forensic manifests - Canonical payload signature verification during import and manual hash verification - Fail-closed behavior when signature metadata is missing or invalid - Signature/key provenance support for audit-related workflows
Workarounds
There is no full cryptographic workaround equivalent to upgrading.
Temporary mitigations: - Treat hash-only validation as a tamper indicator, not proof of immutability - Restrict package exchange to trusted authenticated internal channels - Require out-of-band reviewer attestation for sensitive confirmation workflows - Pause imports from untrusted sources until upgraded
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@striae-org/striae"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.22-0"
},
{
"fixed": "3.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31839"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-353",
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-11T14:55:49Z",
"nvd_published_at": "2026-03-11T17:16:58Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA high-severity integrity bypass vulnerability existed in Striae\u0027s digital confirmation workflow prior to v3.0.0. Hash-only validation trusted manifest hash fields that could be modified together with package content, allowing tampered confirmation packages to pass integrity checks.\n\n## Impact\n\nConfirmation package integrity could be bypassed because both content and hash values were mutable in the same trust boundary. An attacker with access to an exported package could alter confirmation data and recompute hashes so hash-only checks still passed.\n\nThis affects users relying on digital confirmations as an immutability and forensic chain-of-custody control.\n\n## Patches\n\nPatched in **v3.0.0**.\n\nUpgrade to:\n- `v3.0.0` or later\n\nSecurity behavior added in v3.0.0:\n- Server-issued asymmetric signatures for forensic manifests\n- Canonical payload signature verification during import and manual hash verification\n- Fail-closed behavior when signature metadata is missing or invalid\n- Signature/key provenance support for audit-related workflows\n\n## Workarounds\n\nThere is no full cryptographic workaround equivalent to upgrading.\n\nTemporary mitigations:\n- Treat hash-only validation as a tamper indicator, not proof of immutability\n- Restrict package exchange to trusted authenticated internal channels\n- Require out-of-band reviewer attestation for sensitive confirmation workflows\n- Pause imports from untrusted sources until upgraded",
"id": "GHSA-mmf8-487q-p45m",
"modified": "2026-03-11T20:43:41Z",
"published": "2026-03-11T14:55:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/striae-org/striae/security/advisories/GHSA-mmf8-487q-p45m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31839"
},
{
"type": "PACKAGE",
"url": "https://github.com/striae-org/striae"
},
{
"type": "WEB",
"url": "https://github.com/striae-org/striae/releases/tag/v3.0.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Striae has a hash validation utility vulnerability"
}
GHSA-MQ8V-785F-4PMX
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2026-04-14 09:30An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol.
{
"affected": [],
"aliases": [
"CVE-2020-26141"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol.",
"id": "GHSA-mq8v-785f-4pmx",
"modified": "2026-04-14T09:30:37Z",
"published": "2022-05-24T19:01:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26141"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019200.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-913875.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-913875.pdf"
},
{
"type": "WEB",
"url": "https://github.com/vanhoefm/fragattacks/blob/master/SUMMARY.md"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/12602-security-advisory-63"
},
{
"type": "WEB",
"url": "https://www.fragattacks.com"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/11/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MQM6-5RHF-VP27
Vulnerability from github – Published: 2025-06-12 21:30 – Updated: 2025-06-12 21:30An improper validation of integrity check value vulnerability exists in
AVEVA PI Connector for CygNet Versions 1.6.14 and prior that, if exploited, could allow a miscreant with elevated privileges to modify PI Connector for CygNet local data files (cache and buffers) in a way that causes the connector service to become unresponsive.
{
"affected": [],
"aliases": [
"CVE-2025-4418"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-12T20:15:21Z",
"severity": "MODERATE"
},
"details": "An improper validation of integrity check value vulnerability exists in \n\nAVEVA\u00a0PI Connector for CygNet Versions 1.6.14 and prior that, if exploited, \ncould allow a miscreant with elevated privileges to modify PI Connector \nfor CygNet local data files (cache and buffers) in a way that causes the\n connector service to become unresponsive.",
"id": "GHSA-mqm6-5rhf-vp27",
"modified": "2025-06-12T21:30:31Z",
"published": "2025-06-12T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4418"
},
{
"type": "WEB",
"url": "https://www.aveva.com/en/support-and-success/cyber-security-updates"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-162-09"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/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-MRPR-VR82-X88R
Vulnerability from github – Published: 2024-11-13 21:30 – Updated: 2024-11-26 19:00Jenkins Pipeline: Groovy Plugin 3990.vd281dd77a_388 and earlier, except 3975.3977.v478dd9e956c3 does not check whether the main (Jenkinsfile) script for a rebuilt build is approved, allowing attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. This allows attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. Pipeline: Groovy Plugin 3993.v3e20a_37282f8 refuses to rebuild a build whose main (Jenkinsfile) script is unapproved.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins.workflow:workflow-cps"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3993.v3e20a"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52550"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-14T15:41:46Z",
"nvd_published_at": "2024-11-13T21:15:29Z",
"severity": "HIGH"
},
"details": "Jenkins Pipeline: Groovy Plugin 3990.vd281dd77a_388 and earlier, except 3975.3977.v478dd9e956c3 does not check whether the main (Jenkinsfile) script for a rebuilt build is approved, allowing attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. This allows attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved. Pipeline: Groovy Plugin 3993.v3e20a_37282f8 refuses to rebuild a build whose main (Jenkinsfile) script is unapproved.\n",
"id": "GHSA-mrpr-vr82-x88r",
"modified": "2024-11-26T19:00:12Z",
"published": "2024-11-13T21:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52550"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/workflow-cps-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2024-11-13/#SECURITY-3362"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Rebuilding a run with revoked script approval allowed by Jenkins Pipeline: Groovy Plugin "
}
GHSA-MVWM-RCRW-PR2J
Vulnerability from github – Published: 2023-06-13 18:30 – Updated: 2023-12-21 15:30An issue was discovered in systemd 253. An attacker can modify the contents of past events in a sealed log file and then adjust the file such that checking the integrity shows no error, despite modifications.
{
"affected": [],
"aliases": [
"CVE-2023-31439"
],
"database_specific": {
"cwe_ids": [
"CWE-354"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-13T17:15:14Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in systemd 253. An attacker can modify the contents of past events in a sealed log file and then adjust the file such that checking the integrity shows no error, despite modifications.",
"id": "GHSA-mvwm-rcrw-pr2j",
"modified": "2023-12-21T15:30:31Z",
"published": "2023-06-13T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31439"
},
{
"type": "WEB",
"url": "https://github.com/systemd/systemd/pull/28885"
},
{
"type": "WEB",
"url": "https://github.com/kastel-security/Journald"
},
{
"type": "WEB",
"url": "https://github.com/kastel-security/Journald/blob/main/journald-publication.pdf"
},
{
"type": "WEB",
"url": "https://github.com/systemd/systemd/releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.
CAPEC-145: Checksum Spoofing
An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
CAPEC-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.