CVE-2026-70646: 
Python vulnerability analysis and mitigation

CVE-2026-70646 is a pre-authentication denial-of-service vulnerability in the aiosend Python library, a synchronous and asynchronous Crypto Pay API client. The flaw exists in WebhookHandler.feed_update(), which deserializes the entire request body before verifying the HMAC signature, allowing unauthenticated attackers to force expensive JSON parsing. All versions up to and including 3.0.6 are affected; version 3.0.7 contains the fix. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is CWE-400 (Uncontrolled Resource Consumption): in aiosend/webhook/base.py, WebhookHandler.feed_update() calls Update.model_validate(body, context={"client": self}) via Pydantic before invoking _check_signature(), meaning full deserialization occurs prior to any authentication check. Compounding the issue, CryptoPayObject is configured with ConfigDict(extra="allow"), which causes arbitrary extra fields in the JSON payload to be retained in memory, amplifying resource consumption. The fix (commit db20f0a) reverses the order of operations — HMAC verification is performed on the raw request body string first, and Update.model_validate_json() is only called if the signature is valid (GitHub Advisory, Fix Commit).

Successful exploitation results in a pre-authentication denial-of-service condition affecting all webhook integrations built on aiosend (AiohttpManager, FastAPIManager, and FlaskManager). An unauthenticated attacker can repeatedly send arbitrarily large JSON payloads with invalid signatures, forcing the server to consume CPU time and memory for parsing before ultimately rejecting the request. There is no confidentiality or integrity impact; the sole consequence is degraded or complete loss of availability for the webhook-handling service (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported. The NVD SSVC assessment marks exploitation as "none" and the attack as automatable, reflecting that the attack requires no authentication, no user interaction, and low complexity — any attacker with network access to the webhook endpoint can trigger it. The EPSS score is approximately 0.0035 (0.35%), indicating a low probability of near-term exploitation (GitHub Advisory). The vulnerability is not listed in the CISA KEV catalog.

1. Identify the target: Locate a service exposing an aiosend webhook endpoint (e.g., /webhook) running aiosend <= 3.0.6, reachable over the network.
2. Craft a large JSON payload: Construct an arbitrarily large, valid-looking JSON body (e.g., a deeply nested object or a payload with many extra fields, exploiting the extra="allow" Pydantic configuration) to maximize CPU and memory consumption during parsing.
3. Send unauthenticated POST requests: Submit repeated HTTP POST requests to the webhook endpoint with the crafted payload and an invalid or missing Crypto-Pay-Api-Signature header. No valid HMAC token is required.
4. Force resource exhaustion: The server performs full Pydantic deserialization on each request before checking the signature. With sufficient request volume or payload size, CPU and memory are exhausted, causing the webhook handler — and potentially the broader application — to become unresponsive (GitHub Advisory).

• Network: High volume of HTTP POST requests to the webhook endpoint (e.g., /webhook) from one or more source IPs, particularly with large request bodies and missing or invalid Crypto-Pay-Api-Signature headers.
• Logs: Application or web framework logs showing repeated 400/500 responses or signature validation failures on the webhook route; log entries from loggers.webhook indicating "Signature is invalid" at high frequency.
• Process/System: Elevated CPU and memory usage by the Python process hosting the aiosend webhook handler, potentially leading to OOM kills or process restarts; unusual spikes in garbage collection activity.

Upgrade aiosend to version 3.0.7 or later, which validates the HMAC signature against the raw request body string before performing any JSON deserialization (Release v3.0.7). For deployments that cannot upgrade immediately, the following workarounds reduce exposure: restrict the maximum request body size at the reverse proxy (e.g., nginx client_max_body_size) or web framework level; apply rate limiting to the webhook endpoint; and configure the server to reject oversized requests before they reach the application layer (GitHub Advisory).