PULSE
LIVE21signals / 24h
FEED
ransomnova reclama a VNSO · Not Foundransomblacknevas reclama a Zuni Shopping Center, Inc. · US · Consumer Servicesransomqilin reclama a P & A Construction · US · Constructionransombraincipher reclama a windiam.com · Technologyransomqilin reclama a Primeline Logistics · IE · Transportation/Logisticsransomqilin reclama a Recsa · CR · Not Foundransomqilin reclama a Salida Union School District · US · Educationransomchaos reclama a neopharmlabs.com · US · Healthcareransomqilin reclama a Cpcg · BR · Not Foundransomqilin reclama a EFU Life Assurance · PK · Financial Servicesransomqilin reclama a Infina Health · Healthcareransomm3rx reclama a ubfreight.com · Transportation/Logisticsransomkrybit reclama a dhli.in · IN · Not Foundransomkrybit reclama a Vibonum Technologies Private Limited · IN · Technologyransomnova reclama a VNSO · Not Foundransomblacknevas reclama a Zuni Shopping Center, Inc. · US · Consumer Servicesransomqilin reclama a P & A Construction · US · Constructionransombraincipher reclama a windiam.com · Technologyransomqilin reclama a Primeline Logistics · IE · Transportation/Logisticsransomqilin reclama a Recsa · CR · Not Foundransomqilin reclama a Salida Union School District · US · Educationransomchaos reclama a neopharmlabs.com · US · Healthcareransomqilin reclama a Cpcg · BR · Not Foundransomqilin reclama a EFU Life Assurance · PK · Financial Servicesransomqilin reclama a Infina Health · Healthcareransomm3rx reclama a ubfreight.com · Transportation/Logisticsransomkrybit reclama a dhli.in · IN · Not Foundransomkrybit reclama a Vibonum Technologies Private Limited · IN · Technology
← All CVEs
CVE WatchJul 22, 2026

CVE-2026-11721

It is possible for an attacker's zone to respond to a query with an RRSIG that has a smaller number of labels than the zone in which the RRS

CVSS

7.5

High

EPSS

KEV

Exploit Today

0-100

Published: Jul 22, 2026 · Last modified: Jul 22, 2026 · CWE-1284

EPSS · 30d

Not enough EPSS history yet.

Technical description

It is possible for an attacker's zone to respond to a query with an RRSIG that has a smaller number of labels than the zone in which the RRSIG is contained. This causes `named` to produce a wildcard name for a zone that is shorter than the attacker's zone, which can result in cache poisoning. For this attack to have any effect, the resolver under attack must have set `synth-from-dnssec yes;` (which is the default). This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.

Official references
Related CVEs
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-108226.5 MED
If BIND encounters a particular invalid data structure in a DNS record, it will accept the invalid data, and may subsequently abort and exit. BIND will first need to store a DNS record for a key (KEY, DNSKEY, etc.). That key must specify a PRIVATEDNS algorithm (253), and in the algorithm identifier, improperly give a length longer than the actual identifier data. The invalid identifier will be stored. If BIND later needs to render that record to text, it will use the invalid length during processing, leading to a consistency check failing. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.5h
CVE-2026-326657.5 HIG
In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, when downstream DNS-over-QUIC (DoQ) is enabled, the first two bidirectional streams on a new QUIC connection (stream_id 0 and 4) bypass the per-stream 'quic-size' gate entirely, and large input buffers are allocated later, after only the 2-byte length prefix has been received from the initial streams. As a result, a remote client can make Unbound exceed the configured 'quic-size' limit with low-cost input. Using only one connection and two streams, each sending a declared 65535-byte length prefix and then holding the streams open, a client can already trivially make Unbound roughly allocate double that amount. This is a remote availability issue / memory-accounting bypass in the downstream DoQ implementation that leads to denial of service for new DoQ clients. This vulnerability needs Unbound to be compiled with DoQ support ('--with-libngtcp2') and the 'quic-port' to be configured for the listening interfaces.5h
CVE-2026-476677.5 HIG
0CImg Library is a C++ library for image processing. Prior to version 4.0.0 in `_load_analyze()`, the header_size field is read as an `unsigned int` from the first 4 bytes of an Analyze/NIfTI file and passed directly to `new unsigned char[header_size]` without being bounded against the actual file size. A value up to ~4 GB is accepted. If the subsequent `fread` returns `short` as it will for any malformed file), the function throws a `CImgIOException` and the allocated buffer is never freed. A 6-byte crafted file is sufficient to trigger an allocation of ~1.3 GB per call, with the full allocation leaked on every error path. The issue is reachable via `load_analyze()` and the generic `load()` when the file extension is .hdr, .img, or .nii. Version 4.0.0 fixes the issue.1d
CVE-2026-59695
22.2%
7Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet in a single request by naming an arbitrarily high gas price. When the mpp Elixir library is configured as fee payer (fee_payer: true), MPP.Tempo.Transaction.cosign_fee_payer/3 re-signs the client-supplied base fields of the 0x76 AASigned envelope verbatim, including max_fee_per_gas and max_priority_fee_per_gas, without validating that they are within reasonable bounds. A malicious client embeds arbitrarily large values for these fields in the signed envelope. The server co-signs and broadcasts the transaction. The effective_gas_price billed against the fee-payer wallet is derived from the attacker-supplied ceilings, so the server pays those inflated per-gas rates out of its own wallet. A single crafted request can drain the wallet entirely, after which the server can no longer sponsor gas for legitimate payment requests. This issue affects mpp: from 0.2.0 before 0.6.0.5d
CVE-2026-59694
22.2%
7Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per payment by a large multiplier, degrading the sponsor's operating margin. When the mpp Elixir library is configured as fee payer (fee_payer: true), MPP.Tempo.Transaction.cosign_fee_payer/3 re-signs the client-supplied base fields of the 0x76 AASigned envelope verbatim, including the EIP-2930 access list, without validating its length or contents. EIP-2930 access list entries incur intrinsic gas (~2,400 gas per address, plus 1,900 gas per storage key) charged before any opcode executes, regardless of whether the listed addresses are ever touched. A malicious client submits a valid transferWithMemo call alongside a large number of fabricated access-list entries. The server co-signs and broadcasts the transaction. The intended transfer executes normally, but the fee-payer wallet pays a large multiple of the expected gas cost with no corresponding on-chain work. At the maintainer's default of 137 access-list entries (fitting within Bandit's 10,000-byte per-header-field limit) and 100 Gwei max_fee_per_gas, per-payment gas cost rises from ~51,287 to ~380,087 gas, a 7.4x multiplier. Sustained abuse destroys the sponsor's operating margin on low-cost payments and, over time, drains the fee-payer wallet. This issue affects mpp: from 0.2.0 before 0.6.0.5d
CVE-2026-59252
28.6%
9Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients. When the mpp Elixir library is configured as fee payer (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests. The wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions. This issue affects mpp: from 0.2.0 before 0.6.0.5d