EUVD-2026-53920
GHSA-7m8f-hgjq-8gc9
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable unauthenticated webhook endpoint with no complexity barriers; impact is availability-only with no confidentiality or integrity effect.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
aiosend is a synchronous and asynchronous Crypto Pay API client. Pror to version 3.0.7, WebhookHandler.feed_update() deserializes the entire request body before verifying the HMAC signature. This allows an unauthenticated attacker to force expensive parsing of arbitrary JSON payloads that will ultimately be rejected, leading to unnecessary CPU and memory consumption. Version 3.0.7 fixes the issue. Some workarounds are available. Restrict request body size at the reverse proxy or web framework, rate-limit webhook endpoints, and/or reject oversized requests before JSON parsing.
AnalysisAI
Deserialization-before-authentication in aiosend's WebhookHandler exposes all webhook integrations prior to version 3.0.7 to pre-authentication denial-of-service. An unauthenticated remote attacker can submit arbitrarily large or complex JSON payloads to any reachable aiosend webhook endpoint, forcing a full Pydantic model deserialization pass - including retention of attacker-supplied extra fields in memory due to CryptoPayObject's extra='allow' configuration - before the HMAC signature is checked and the request is rejected. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack requires no credentials and minimal skill.
Technical ContextAI
aiosend (CPE: cpe:2.3:a:vovchic17:aiosend:*:*:*:*:*:*:*:*) is a PyPI-distributed Python library for the Telegram Crypto Pay API, providing synchronous and asynchronous webhook managers (AiohttpManager, FastAPIManager, FlaskManager). The root cause is CWE-400 (Uncontrolled Resource Consumption): in aiosend/webhook/base.py, WebhookHandler.feed_update() invokes Pydantic's Update.model_validate() on the full request body before calling self._check_signature(), deferring authentication until after all parsing work is complete. A second amplifier exists in aiosend/types/base.py: CryptoPayObject is configured with ConfigDict(extra='allow'), so arbitrary attacker-supplied JSON fields are allocated and held in memory during the rejected parse. The fix (commit db20f0a) reorders this logic - the raw body string is now passed to signature checking first, and model_validate_json() is called only after the HMAC is confirmed valid. A lightweight regex extractor (_extract_update_id) was added to allow logging of the update ID without full deserialization.
RemediationAI
Upgrade aiosend to version 3.0.7, available at https://github.com/vovchic17/aiosend/releases/tag/v3.0.7 and confirmed by commit db20f0a742209dfac181863d398ec5112687efa4. Until upgrading, three compensating controls are available: first, restrict the maximum request body size at the reverse proxy or web framework layer (for example, Nginx client_max_body_size or equivalent) - this caps per-request parsing cost but requires selecting a limit that does not truncate legitimate large payloads, and it does not eliminate the vulnerability; second, apply rate limiting on the webhook endpoint by source IP to reduce attacker throughput, which is effective against unsophisticated floods but bypassable with distributed sources; third, configure the reverse proxy to reject oversized requests before they reach the application parser entirely, which is the most effective workaround when combined with the size limit. None of these controls address the root cause; upgrading to 3.0.7 is the definitive fix.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today