Security Vulnerabilities
Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer.
MPP.Methods.Tempo normally binds a settled TIP-20 TransferWithMemo to the specific challenge under verification through an attribution nonce carried in the memo. When a static "memo" is configured in method_config, check_matched_memo_binding/3 returns the match unconditionally and that binding is skipped, leaving only token, recipient, amount and the static memo value to match on. The static memo is echoed in every unauthenticated 402 response and Tempo transfers are public, so an attacker can take any matching transfer paid by a legitimate customer, request a fresh challenge for the same route, and present that transaction hash as a type="hash" credential. The hash path performs no sender or signature check tying the presenter to the wallet that broadcast the transfer.
This issue affects mpp: from 0.6.1 before 0.6.4.
CVSS Score
8.2
EPSS Score
0.004
Published
2026-08-19
Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.
MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.
This issue affects mpp: from 0.2.0 before 0.12.0.
CVSS Score
8.3
EPSS Score
0.004
Published
2026-08-19
Time-of-check Time-of-use (TOCTOU) Race Condition in ZenHive mpp allows an unauthenticated remote client to redeem one confirmed on-chain payment for multiple paid-resource accesses.
The type="hash" credential path in MPP.Methods.Tempo.verify/2 guards against replay with a non-atomic check-then-mark sequence: check_hash_unused/2 reads the dedup store, an eth_getTransactionReceipt round trip verifies the payment on chain, and only then does mark_hash_used/2 write the mark. Concurrent requests carrying the same settled payment hash all pass the read before any of them writes, so each is issued a receipt. The store's atomic check_and_mark/2 primitive is available and used by the type="transaction" path, but the hash path calls plain get and put even when the configured store implements it. Exploitation requires a dedup store to be configured; the default nil store is stateless and documented as offering no replay protection at all.
This issue affects mpp: from 0.2.0 before 0.6.1.
CVSS Score
6.3
EPSS Score
0.002
Published
2026-08-19
Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated remote client to obtain paid resources by resubmitting one settled on-chain transfer.
MPP.Methods.EVM.verify/2 accepts a transaction-hash credential and matches a transfer purely on token, to and amount (ERC-20) or to and value (native). It binds the proof neither to the challenge being verified nor to any record of prior use, and the generic MPP.Plug dedup store keys on challenge.id, which is regenerated for every 402 response. On a static-price route, a single historical transfer matching the charge therefore satisfies an unbounded number of later charges, including transfers an attacker can read off a public block explorer.
This issue affects mpp: from 0.3.0 before 0.6.3.
CVSS Score
8.7
EPSS Score
0.004
Published
2026-08-19
Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, and FW1060.00 through FW1060.80 is affected by a vulnerability in the host firmware boot process image validation path. An attacker with service access to the service processor can supply a maliciously crafted code update image, allowing arbitrary code to be executed on the host system. Successful exploitation could result in a confidentiality, integrity, and availability impact to the affected host system.
CVSS Score
8.2
EPSS Score
0.001
Published
2026-08-19
IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service due to improper handling of memory page table configurations.
CVSS Score
6.5
EPSS Score
0.001
Published
2026-08-19
IBM Langflow OSS 1.0.0 through 1.10.0 could allow a remote attacker to overwrite administrator email information and abuse the server as an outbound relay due to missing authentication for the registration endpoint.
CVSS Score
7.5
EPSS Score
0.004
Published
2026-08-19
CVE-2026-72530
A remote unauthorized attacker with network access via port 4307/TCP to the TrueConf server versions 5.3.X to 5.3.9, 5.4.X to 5.4.9, 5.5.X to 5.5.5, and earlier could use a specially crafted script to break out of the isolated environment and execute arbitrary code on the host system.
Known exploited
CVSS Score
9.5
EPSS Score
0.018
Published
2026-08-19
CVE-2026-72529
A remote unauthorized attacker with network access via port 4307/TCP to the TrueConf server versions 5.3.X to 5.3.9, 5.4.X to 5.4.9, 5.5.X to 5.5.5, and earlier could execute an arbitrary script by calling an undocumented function.
Known exploited
CVSS Score
9.3
EPSS Score
0.016
Published
2026-08-19
Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.3.0 until 4.14.6 and 5.0.0-beta3, the non-merged branch of process_files_from_worker() in framework/wazuh/core/cluster/master.py trusts a peer-controlled file_path key from files_metadata.json. The destination is joined to WAZUH_PATH without proving that it remains inside the directory selected by cluster_item_key. A cluster peer holding the shared Fernet key can upload a crafted extra-valid archive and overwrite security-sensitive files such as /var/ossec/etc/ossec.conf. Replacing ossec.conf can configure root-executed commands and lead to code execution after a service reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.
CVSS Score
9.1
EPSS Score
0.005
Published
2026-08-19