Introduction
On July 6, 2025, a suspicious Python package called ‘cloudscrapersafe’ was uploaded to the Python Package Index (PyPI). Marketed as a utility to evade Cloudflare’s anti-bot protections, this package was a modified version of a widely used ‘cloudscraper’ library, which is used to automate access to websites protected by Cloudflare’s IUAM (I’m Under Attack Mode).
Within a few hours, the package had already been downloaded and potentially deployed in some environments. Thankfully, PyPI swiftly removed the package after realizing it was malicious.
While preserving every original feature of ‘cloudscraper’, the package secretly embeds logic designed to intercept credit card information and exfiltrate it to an external Telegram bot.
It is worth noting that while ‘cloudscraper’ itself has over 1.4 million downloads and is openly available, it is used to circumvent security protections, a use case that already sits in a gray zone. This highlights the risk of developers importing tools that are both legally questionable and technically dangerous, with little scrutiny over what additional payloads they may include.
The attack is a textbook example of supply chain abuse: a malicious actor takes a known open-source library, clones it under a slightly different name, and injects harmful code while preserving the original functionality. The package, ‘cloudscrapersafe’, retained the scraping and challenge-solving features of ‘cloudscraper’ but added two specific logic blocks to monitor HTTP requests and responses for sensitive financial data.
These malicious additions were triggered only in narrow conditions, namely when a POST request was sent to specific URLs associated with online payment gateways. When such a match was detected, the package extracted credit card numbers and expiration dates from either form data or JSON payloads. If the transaction appeared to be successful, the data was transmitted to a hardcoded Telegram bot.
Technical Details
The malicious behavior is embedded directly into the class that overrides requests.Session, specifically within the request() method:
Malicious code injected to request handler
The injected logic inspects outgoing POST requests for three specific endpoints, all of which are base64-encoded in the source to evade static analysis:
- hxxps://credomatic.compassmerchantsolutions.com/api/transact.php
- If matched, the script attempts to extract ‘ccnumber’ and ‘ccexp’ from the request payload.
- hxxps://checkout.baccredomatic.com/purchase/order/
- The script extracts a transaction identifier from the URL path.
- hxxps://ecommerce.credomatic.com:447/3DS/API/api/Secure/Execute
- The script looks for ‘CardNumber’, ‘CardExpMonth’, and ‘CardExpYear’ in a JSON body, storing all values in memory.
The stolen data is stored internally, using the variables self.contendatax and self.conteninitx.
Once the request is sent and a response is received, a second block of malicious code analyzes the response object:
Malicious code that was injected into the response handler
Once removing the obfuscation, we see that the script looks for signs of a successful transaction in two ways:
- The Location header contains the string responsetext=APPROVED.
- The response JSON contains {“NextStep”: “N”} and a JWT token whose decoded payload includes “responseCodeDescription”: “APROBADA”.
If either condition is met, the package attempts to send a GET request to a Telegram bot API endpoint using an obfuscated function that reconstructs the URL and query parameters from lists of character codes. This request is intended to exfiltrate the collected credit card data.
Deobfuscated malicious code that was injected into the response handler
Conclusions
This case illustrates the growing sophistication of supply chain attacks within the Python ecosystem. The attacker cloned an existing tool already operating in an ethically ambiguous domain, added a narrow but dangerous payload, and relied on the community’s trust and automation to propagate it.
Several important takeaways emerge:
- Developers must treat packages that bypass security protections as inherently risky, even if they are popular or widely used. Legitimacy cannot be assumed based on download counts alone.
- Despite PyPI’s quarantine mechanism, the package files remained downloadable after being flagged for around 24 hours. Package registries like PyPI should adopt stronger quarantine mechanisms that prevent post-flag downloads and alert any projects that may have integrated the package.
- Security teams should implement package vetting workflows, including static code inspection for new dependencies and monitoring for signs of obfuscated code or overridden HTTP request logic.
Ultimately, the incident highlights that the real risk often lies not in obscure malware samples, but in small, deliberate modifications to packages we think we already trust.
The post From Cloudflare Bypass to Credit Card Theft appeared first on Blog.
