Monthly
Checksum verification bypass in the Go toolchain (cmd/go) versions 1.27.0 before 1.27.2 and before 1.26.9 allows a malicious Go project with a forged golang.org/toolchain go.sum entry, combined with a user-selected attacker-controlled GOMODPROXY, to substitute a tampered toolchain that cmd/go would otherwise reject. Exploitation requires local access and user interaction (CVSS 7.8, AV:L/UI:R) and two attacker-controlled preconditions the victim must opt into: operating inside the crafted project and using the malicious proxy. No public exploit code identified at time of analysis, and EPSS is 0.13% (2nd percentile), indicating low predicted exploitation likelihood.
Go toolchain (cmd/go) releases before 1.26.9 and 1.27.0 through 1.27.1 can be induced to substitute an attacker-controlled module in place of the bundled golang.org/fips140 dependency when a developer builds a project that ships a bogus golang.org/fips140 definition and connects the build to an attacker-operated GOMODPROXY. Successful abuse yields high confidentiality, integrity, and availability impact within the build environment because the toolchain fails to properly validate the module's integrity check value (CWE-354), so untrusted module content is accepted in place of the trusted bundled copy. Exploitation is conditional rather than widespread: it requires both an attacker-crafted project and explicit developer action to use a non-default, attacker-chosen proxy (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 7.8), and no public exploit code or confirmed active exploitation has been identified at time of analysis, with EPSS at roughly 0.11% (1st percentile). Vendor patches are available in Go 1.26.9 and 1.27.2.
Cache poisoning in BuildKit lets a malicious image advertise DiffIDs that do not match its actual layer contents, so a daemon with a shared or persistent cache can adopt attacker-controlled layers as the base for a victim image and execute attacker code inside the victim build - for example by replacing a commonly executed path such as /bin/sh, reading build secrets mounted into the build, altering output artifacts, or hanging the build. Exploitation is unauthenticated but conditional: the attacker's image must be processed before the victim build on a daemon with a shared or persistent cache (multi-tenant or long-lived CI/build farms), and a victim build must then reference the targeted base image; ephemeral, non-shared caches are unaffected. No public exploit code identified at time of analysis; the vendor patch is BuildKit v0.33.1, and the issue carries a CVSS 7.5 (CVSS 4.0) rating with our independent assessment at CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Information disclosure in Bouncy Castle C# (bc-csharp) versions before 2.7.0 allows unauthenticated remote attackers to obtain plaintext from forged ciphertexts when an application decrypts into a caller-supplied buffer and subsequently observes that buffer after a failed authentication-tag check (e.g., through buffer reuse or logging). The vulnerability affects CcmBlockCipher and KCcmBlockCipher (DSTU 7624 CCM) only; methods returning newly allocated arrays are not vulnerable. No public exploit code or active exploitation has been identified, and the practical risk is conditional on the application exposing the failed decryption buffer, narrowing the attack surface despite the vendor-assigned CVSS 4.0 score of 8.2.
Forgery of encrypted messages is possible in Legion of the Bouncy Castle Inc.'s bc-csharp (Bouncy Castle C#) before 2.7.0 when an IesEngine is constructed without a block cipher and initialised in static-static mode, because the keystream produced by the key-derivation function reveals the message authentication key for any message shorter than one the attacker has already observed. An unauthenticated remote attacker who possesses one ciphertext together with its known plaintext can therefore compute the MAC key and submit a crafted ciphertext and tag that the recipient accepts as authentic, although the forgery is confined to messages strictly shorter than the observed message and applications using standard ECIES with ephemeral sender keys or a block-cipher mode are unaffected. Vendor patch available: the defect is corrected in bc-csharp 2.7.0 via upstream commit f881400b761134160ec2a05fd27c3e569453788d, and no public exploit code was identified at time of analysis.
On-path attackers who can intercept and modify CMS messages can silently tamper with AES-CCM-protected content that Legion of the Bouncy Castle Inc.'s bc-csharp library (versions before 2.7.0) decrypts. The root cause is that CcmParameters accepted any aes-ICVlen value from an untrusted AlgorithmIdentifier while CcmBlockCipher enforced the tag length only on the encryption path, so a decryption carrying a zero-length or very short tag compared an empty or truncated tag and accepted forged ciphertext without any detectable integrity failure; the same fix also hardens the AES-GCM CMS parameter handling. The reachable paths are ParameterUtilities.GetCipherParameters as used by CmsEnvelopedData and CmsEnvelopedDataParser for AES-CCM EnvelopedData, plus any caller that forwards an unchecked tag length into CcmBlockCipher for decryption. A vendor patch is available in 2.7.0 and the change is published as two commits plus a wiki advisory; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and because exploitation requires an attacker to already hold a network interception position (no remote-from-anywhere access, no authentication, no user interaction), the practical risk is a genuine but precondition-gated integrity/tampering issue rather than a broadly exploitable one.
Package-index corruption and denial of package-management operations affect MidnightBSD mport before 2.7.8 when a malicious or faulty package mirror supplies truncated, corrupt, or otherwise failing zstd-compressed index data. A remote unauthenticated attacker must control or machine-in-the-middle a mirror used by mport, making the practical risk moderate despite a CVSS 4.0 score of 8.3; the impact is limited to index integrity and availability, with no confidentiality exposure or whole-system compromise. The issue is fixed in mport 2.7.8; no public exploit identified at time of analysis.
Let me synthesize. CVE-2026-73459: Arista EOS IS-IS LSP purge via crafted IS-IS LSP PDU. Unauthenticated attacker with adjacency/adjacent network access. CVSS 4.0: AV:A (adjacent), AC:L, AT:P (attack requirements present), PR:N, UI:N, VC:N, VI:N, VA:H, SC:N, SI:N, SA:H. CWE-354: Improper Validation of Integrity Check Value. Hmm, CWE-354 is "Improper Validation of Integrity Check Value". Actually CWE-354 is "Improper Validation of Integrity Check Value". Yes. So the crafted LSP with invalid/wrong checksum (IS-IS LSP checksum) isn't validated, causing legitimate LSP to be purged (sequence number manipulation / LSP purge). Actually the scenario: attacker injects crafted IS-IS LSP PDU that purges a legitimate LSP from the link-state database — likely by spoofing LSP with same LSP ID (source ID + pseudonode ID) with... Actually removal could happen by a zero-lifetime LSP or by "purge" mechanism with Remaining Lifetime = 0. In IS-IS, an LSP with remaining lifetime 0 is purged. So crafted LSP with matching LSP ID and Remaining Lifetime 0 plus invalid checksum being accepted → purges legitimate LSP. AV:A — adjacent network — requires attacker on same broadcast segment / L2 adjacency, must be able to send IS-IS PDUs (L2 multicast, no auth if authentication not configured). AT:P — attack requirements present: need to be on an IS-IS enabled link/adjacency; possibly need to be able to form adjacency or at least inject raw L2 frames. PR:N — no auth (if IS-IS authentication is not configured). But PR:N in CVSS 4.0 means none — no privileges required. However, if IS-IS authentication is configured, injection requires the auth key — hence AT:P captures the requirement. EPSS: not given. KEV: not given (not listed). POC: not given. Patch: EOS 4.36.0 ≤4.36.1F affected; advisory 0160 available. Fix version not explicitly given in input — the advisory presumably lists fixed versions. I should not invent. So: "Patch available per vendor advisory" — advisory SAF-0160 at arista.com.
Checksum verification bypass in the Go toolchain (cmd/go) versions 1.27.0 before 1.27.2 and before 1.26.9 allows a malicious Go project with a forged golang.org/toolchain go.sum entry, combined with a user-selected attacker-controlled GOMODPROXY, to substitute a tampered toolchain that cmd/go would otherwise reject. Exploitation requires local access and user interaction (CVSS 7.8, AV:L/UI:R) and two attacker-controlled preconditions the victim must opt into: operating inside the crafted project and using the malicious proxy. No public exploit code identified at time of analysis, and EPSS is 0.13% (2nd percentile), indicating low predicted exploitation likelihood.
Go toolchain (cmd/go) releases before 1.26.9 and 1.27.0 through 1.27.1 can be induced to substitute an attacker-controlled module in place of the bundled golang.org/fips140 dependency when a developer builds a project that ships a bogus golang.org/fips140 definition and connects the build to an attacker-operated GOMODPROXY. Successful abuse yields high confidentiality, integrity, and availability impact within the build environment because the toolchain fails to properly validate the module's integrity check value (CWE-354), so untrusted module content is accepted in place of the trusted bundled copy. Exploitation is conditional rather than widespread: it requires both an attacker-crafted project and explicit developer action to use a non-default, attacker-chosen proxy (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 7.8), and no public exploit code or confirmed active exploitation has been identified at time of analysis, with EPSS at roughly 0.11% (1st percentile). Vendor patches are available in Go 1.26.9 and 1.27.2.
Cache poisoning in BuildKit lets a malicious image advertise DiffIDs that do not match its actual layer contents, so a daemon with a shared or persistent cache can adopt attacker-controlled layers as the base for a victim image and execute attacker code inside the victim build - for example by replacing a commonly executed path such as /bin/sh, reading build secrets mounted into the build, altering output artifacts, or hanging the build. Exploitation is unauthenticated but conditional: the attacker's image must be processed before the victim build on a daemon with a shared or persistent cache (multi-tenant or long-lived CI/build farms), and a victim build must then reference the targeted base image; ephemeral, non-shared caches are unaffected. No public exploit code identified at time of analysis; the vendor patch is BuildKit v0.33.1, and the issue carries a CVSS 7.5 (CVSS 4.0) rating with our independent assessment at CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Information disclosure in Bouncy Castle C# (bc-csharp) versions before 2.7.0 allows unauthenticated remote attackers to obtain plaintext from forged ciphertexts when an application decrypts into a caller-supplied buffer and subsequently observes that buffer after a failed authentication-tag check (e.g., through buffer reuse or logging). The vulnerability affects CcmBlockCipher and KCcmBlockCipher (DSTU 7624 CCM) only; methods returning newly allocated arrays are not vulnerable. No public exploit code or active exploitation has been identified, and the practical risk is conditional on the application exposing the failed decryption buffer, narrowing the attack surface despite the vendor-assigned CVSS 4.0 score of 8.2.
Forgery of encrypted messages is possible in Legion of the Bouncy Castle Inc.'s bc-csharp (Bouncy Castle C#) before 2.7.0 when an IesEngine is constructed without a block cipher and initialised in static-static mode, because the keystream produced by the key-derivation function reveals the message authentication key for any message shorter than one the attacker has already observed. An unauthenticated remote attacker who possesses one ciphertext together with its known plaintext can therefore compute the MAC key and submit a crafted ciphertext and tag that the recipient accepts as authentic, although the forgery is confined to messages strictly shorter than the observed message and applications using standard ECIES with ephemeral sender keys or a block-cipher mode are unaffected. Vendor patch available: the defect is corrected in bc-csharp 2.7.0 via upstream commit f881400b761134160ec2a05fd27c3e569453788d, and no public exploit code was identified at time of analysis.
On-path attackers who can intercept and modify CMS messages can silently tamper with AES-CCM-protected content that Legion of the Bouncy Castle Inc.'s bc-csharp library (versions before 2.7.0) decrypts. The root cause is that CcmParameters accepted any aes-ICVlen value from an untrusted AlgorithmIdentifier while CcmBlockCipher enforced the tag length only on the encryption path, so a decryption carrying a zero-length or very short tag compared an empty or truncated tag and accepted forged ciphertext without any detectable integrity failure; the same fix also hardens the AES-GCM CMS parameter handling. The reachable paths are ParameterUtilities.GetCipherParameters as used by CmsEnvelopedData and CmsEnvelopedDataParser for AES-CCM EnvelopedData, plus any caller that forwards an unchecked tag length into CcmBlockCipher for decryption. A vendor patch is available in 2.7.0 and the change is published as two commits plus a wiki advisory; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and because exploitation requires an attacker to already hold a network interception position (no remote-from-anywhere access, no authentication, no user interaction), the practical risk is a genuine but precondition-gated integrity/tampering issue rather than a broadly exploitable one.
Package-index corruption and denial of package-management operations affect MidnightBSD mport before 2.7.8 when a malicious or faulty package mirror supplies truncated, corrupt, or otherwise failing zstd-compressed index data. A remote unauthenticated attacker must control or machine-in-the-middle a mirror used by mport, making the practical risk moderate despite a CVSS 4.0 score of 8.3; the impact is limited to index integrity and availability, with no confidentiality exposure or whole-system compromise. The issue is fixed in mport 2.7.8; no public exploit identified at time of analysis.
Let me synthesize. CVE-2026-73459: Arista EOS IS-IS LSP purge via crafted IS-IS LSP PDU. Unauthenticated attacker with adjacency/adjacent network access. CVSS 4.0: AV:A (adjacent), AC:L, AT:P (attack requirements present), PR:N, UI:N, VC:N, VI:N, VA:H, SC:N, SI:N, SA:H. CWE-354: Improper Validation of Integrity Check Value. Hmm, CWE-354 is "Improper Validation of Integrity Check Value". Actually CWE-354 is "Improper Validation of Integrity Check Value". Yes. So the crafted LSP with invalid/wrong checksum (IS-IS LSP checksum) isn't validated, causing legitimate LSP to be purged (sequence number manipulation / LSP purge). Actually the scenario: attacker injects crafted IS-IS LSP PDU that purges a legitimate LSP from the link-state database — likely by spoofing LSP with same LSP ID (source ID + pseudonode ID) with... Actually removal could happen by a zero-lifetime LSP or by "purge" mechanism with Remaining Lifetime = 0. In IS-IS, an LSP with remaining lifetime 0 is purged. So crafted LSP with matching LSP ID and Remaining Lifetime 0 plus invalid checksum being accepted → purges legitimate LSP. AV:A — adjacent network — requires attacker on same broadcast segment / L2 adjacency, must be able to send IS-IS PDUs (L2 multicast, no auth if authentication not configured). AT:P — attack requirements present: need to be on an IS-IS enabled link/adjacency; possibly need to be able to form adjacency or at least inject raw L2 frames. PR:N — no auth (if IS-IS authentication is not configured). But PR:N in CVSS 4.0 means none — no privileges required. However, if IS-IS authentication is configured, injection requires the auth key — hence AT:P captures the requirement. EPSS: not given. KEV: not given (not listed). POC: not given. Patch: EOS 4.36.0 ≤4.36.1F affected; advisory 0160 available. Fix version not explicitly given in input — the advisory presumably lists fixed versions. I should not invent. So: "Patch available per vendor advisory" — advisory SAF-0160 at arista.com.