Hi!
Below is a summary of three vulnerabilities identified project. Each issue is explained with a short description and a practical attack scenario to illustrate the potential impact.
1) Unbounded Sleep DoS via interval
Description
The interval parameter in both synchronous and asynchronous decoders is passed directly into time.sleep or asyncio.sleep without any upper bound. This means user input can freeze a worker thread or async task for arbitrarily long durations.
Attack Scenario
If a service exposes an API like:
POST /decode { "url": "...", "interval": 999999 }
an attacker can send requests with very large interval values. Each request ties up a worker, and with enough requests, the server runs out of available threads/tasks, effectively causing denial of service.
2) Unbounded Base64 Token → Memory/CPU Exhaustion
Description
Google News tokens in the last path segment of a URL are fed into base64.urlsafe_b64decode without any limit. Extremely large inputs cause the function to allocate and copy massive amounts of data in memory, spiking CPU and RAM usage.
Attack Scenario
An attacker sends a crafted URL like:
https://news.google.com/articles/AAAA....AAAA (hundreds of MBs long)
The library tries to decode this huge token, allocating hundreds of MB in memory. Multiple such requests can exhaust memory and CPU, leading to slowdowns, crashes, or out-of-memory conditions.
3) Always-True Path Validation + No-Timeout POST
Description
In decoderv2 and decoderv3, the path validation uses (path[-2] == 'articles') or 'read', which is always true. This allows arbitrary non-Google URLs to pass validation. Additionally, if the decoded content starts with AU_yqL, the code triggers a call to decoderv4.fetch_decoded_batch_execute, which performs a POST request to Google without any timeout.
Attack Scenario
An attacker submits a URL like:
https://evil.com/fakepath/BASE64TOKEN
Since validation always passes, the token is decoded. If the decoded string starts with AU_yqL, the library makes a POST to Google’s endpoint. Because the request has no timeout, attackers can exploit slow or blackholed connections to hang worker threads indefinitely. Repeated many times, this drains resources and causes denial of service.
If you have any questions let us know!
Regards
Hi!
Below is a summary of three vulnerabilities identified project. Each issue is explained with a short description and a practical attack scenario to illustrate the potential impact.
1) Unbounded Sleep DoS via interval
Description
The interval parameter in both synchronous and asynchronous decoders is passed directly into time.sleep or asyncio.sleep without any upper bound. This means user input can freeze a worker thread or async task for arbitrarily long durations.
Attack Scenario
If a service exposes an API like:
POST /decode { "url": "...", "interval": 999999 }an attacker can send requests with very large interval values. Each request ties up a worker, and with enough requests, the server runs out of available threads/tasks, effectively causing denial of service.
2) Unbounded Base64 Token → Memory/CPU Exhaustion
Description
Google News tokens in the last path segment of a URL are fed into base64.urlsafe_b64decode without any limit. Extremely large inputs cause the function to allocate and copy massive amounts of data in memory, spiking CPU and RAM usage.
Attack Scenario
An attacker sends a crafted URL like:
https://news.google.com/articles/AAAA....AAAA (hundreds of MBs long)The library tries to decode this huge token, allocating hundreds of MB in memory. Multiple such requests can exhaust memory and CPU, leading to slowdowns, crashes, or out-of-memory conditions.
3) Always-True Path Validation + No-Timeout POST
Description
In decoderv2 and decoderv3, the path validation uses (path[-2] == 'articles') or 'read', which is always true. This allows arbitrary non-Google URLs to pass validation. Additionally, if the decoded content starts with AU_yqL, the code triggers a call to decoderv4.fetch_decoded_batch_execute, which performs a POST request to Google without any timeout.
Attack Scenario
An attacker submits a URL like:
https://evil.com/fakepath/BASE64TOKENSince validation always passes, the token is decoded. If the decoded string starts with AU_yqL, the library makes a POST to Google’s endpoint. Because the request has no timeout, attackers can exploit slow or blackholed connections to hang worker threads indefinitely. Repeated many times, this drains resources and causes denial of service.
If you have any questions let us know!
Regards