CWE-754 vulnerabilities

nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. Prior to version 1.3.0, `HistoryStore::put_historic_txns` uses an `assert!` to enforce invariants about `HistoricTransaction.block_number` (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the `history: &[HistoricTransaction]` input passed into `Blockchain::push_history_sync`, and a malformed history list can violate these invariants and trigger a panic. `extend_history_sync` calls `this.history_store.add_to_history(..)` before comparing the computed history root against the macro block header (`block.history_root()`), so the panic can happen before later rejection checks run. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.

free5GC UDR is the user data repository (UDR) for free5GC, an an open-source project for 5th generation (5G) mobile core networks. In versions up to and including 1.4.2, a fail-open request handling flaw in the UDR service causes the `/nudr-dr/v2/policy-data/subs-to-notify` POST handler to continue processing requests even after request body retrieval or deserialization errors. This may allow unintended creation of Policy Data notification subscriptions with invalid, empty, or partially processed input, depending on downstream processor behavior. As of time of publication, a patched version is not available.

free5GC is an open-source implementation of the 5G core network. In versions 4.2.1 and below of the UDR service, the PUT handler for updating Policy Data notification subscriptions at /nudr-dr/v2/policy-data/subs-to-notify/{subsId} does not return after request body retrieval or deserialization errors. Although HTTP 500 or 400 error responses are sent, execution continues and the processor is invoked with a potentially uninitialized or partially initialized PolicyDataSubscription object. This fail-open behavior may allow unintended modification of existing Policy Data notification subscriptions with invalid or empty input, depending on downstream processor and storage behavior. A patched version was not available at the time of publication.

Dell PowerScale OneFS, versions prior to 9.12.0.0, contains an improper check for unusual or exceptional conditions vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to denial of service.

Improper check for exceptional conditions in Recents prior to SMR Apr-2026 Release 1 allows physical attacker to bypass App Pinning.

Improper check for exceptional conditions in Device Care prior to SMR Apr-2026 Release 1 allows physical attackers to bypass Knox Guard.

An Improper Check for Unusual or Exceptional Conditions vulnerability in the chassis control daemon (chassisd) of Juniper Networks Junos OS on SRX1500, SRX4100, SRX4200 and SRX4600 allows a local attacker with low privileges to cause a complete Denial of Service (DoS). When a specific 'show chassis' CLI command is executed, chassisd crashes and restarts which causes a momentary impact to all traffic until all modules are online again. This issue affects Junos OS on SRX1500, SRX4100, SRX4200 and SRX4600:  * 23.2 versions before 23.2R2-S6, * 23.4 versions before 23.4R2-S7 * 24.2 versions before 24.2R2-S2, * 24.4 versions before 24.4R2, * 25.2 versions before 25.2R1-S1, 25.2R2.

An Improper Check for Unusual or Exceptional Conditions vulnerability in the chassis control daemon (chassisd) of Juniper Networks Junos OS on SRX1600, SRX2300 and SRX4300 allows a local attacker with low privileges to cause a complete Denial of Service (DoS). When a specific 'show chassis' CLI command is executed, chassisd crashes and restarts which causes a momentary impact to all traffic until all modules are online again. This issue affects Junos OS on SRX1600, SRX2300 and SRX4300: * 24.4 versions before 24.4R1-S3, 24.4R2. This issue does not affect Junos OS versions before 24.4R1.

An Improper Check for Unusual or Exceptional Conditions vulnerability in the packet forwarding engine (pfe) of Juniper Networks Junos OS on MX Series allows an unauthenticated, network-based attacker to bypass the configured firewall filter and access the control-plane of the device. On MX platforms with MPC10, MPC11, LC4800 or LC9600 line cards, and MX304, firewall filters applied on a loopback interface lo0.n (where n is a non-0 number) don't get executed when lo0.n is in the global VRF / default routing-instance. An affected configuration would be: user@host# show configuration interfaces lo0 | display set set interfaces lo0 unit 1 family inet filter input <filter-name> where a firewall filter is applied to a non-0 loopback interface, but that loopback interface is not referred to in any routing-instance (RI) configuration, which implies that it's used in the default RI. The issue can be observed with the CLI command: user@device> show firewall counter filter <filter_name> not showing any matches. This issue affects Junos OS on MX Series: * all versions before 23.2R2-S6, * 23.4 versions before 23.4R2-S7, * 24.2 versions before 24.2R2, * 24.4 versions before 24.4R2.

Cosign provides code signing and transparency for containers and binaries. Prior to 3.0.6 and 2.6.3, cosign verify-blob-attestation may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely. This vulnerability is fixed in 3.0.6 and 2.6.3.