The thistlerun package on PyPI version 0.1.0 is part of a coordinated malicious campaign involving loader packages that download and execute remote malicious scripts. While the packages themselves do not contain the payload, their intent is to facilitate execution of harmful code from external sources.
The juniperrun package on PyPI version 0.1.0 is part of a coordinated campaign involving multiple loader packages designed to download and execute remote malicious scripts. Although the packages themselves do not contain the payload, their purpose is to facilitate the execution of malicious code from external sources. This campaign is identified as malicious with intent similar to infostealers.
The flintqueue package on PyPI version 0.1.0 is part of a coordinated malicious campaign involving loader packages that download and execute remote malicious scripts. These packages do not contain the payload themselves but serve as deceptive loaders for malicious code.
The kestreljob package on PyPI version 0.1.0 is part of a malicious campaign involving loader packages that execute code from remote URLs. These packages do not contain the malicious payload themselves but are designed to download and run remote malicious scripts. This campaign is coordinated and aims to provide multiple deceptive methods to load malicious code.
The PyPI package 'onsokets' version 0.1.0 contains malicious code designed for automated file exfiltration, targeting Android devices. This package is part of a campaign identified as 2026-10-proxyrubika, which has clear malicious intent related to information stealing.
The qowa package on PyPI version 0.1.0 contains malicious code that collects the installer's hostname and sends it to an attacker-controlled Telegram bot channel. It acts as a remote access trojan (RAT) with spyware-like behavior, capable of executing remote commands and exfiltrating files. The package disguises itself as a generic utility but includes hardcoded Telegram Bot API endpoints for command and control communication.
Authlib versions prior to 1.9.0 contain a vulnerability in the RFC 9101 JWTAuthenticationRequest implementation where the unauthenticated, client-controlled request_uri parameter is passed to a hook before destination validation. This can allow a remote attacker with a valid public client ID to induce the authorization server to fetch unintended internal or link-local URLs if the integrator's hook performs unrestricted outbound fetches. The issue is fixed in version 1.9.0.
Authlib versions prior to 1.9.0 contain a vulnerability in the OpenIDImplicitGrant.validate_authorization_request() method where the client-controlled raw request payload scope is checked instead of the filtered allowed scopes. This allows a registered client permitted an ID token response type but not the openid scope to add openid to the request, obtain user consent, and receive a signed ID token with user subject and profile claims. The issue is fixed in version 1.9.0.
Authlib versions prior to 1.9.0 have a vulnerability in the default implementation of JWTBearerGrant.get_audiences() where it returns an empty list. This causes the verify_claims() method to only check for the presence of an aud claim without verifying it matches the current authorization server. As a result, an attacker with a valid assertion for another service sharing the signing key can obtain an access token from the vulnerable server. This issue is fixed in Authlib version 1.9.0.
Authlib versions prior to 1.9.0 contain a vulnerability in OpenIDMixin.parse_id_token() where the nonce_supported decision is read from an untrusted ID token. This flaw allows an attacker with a captured validly signed token to bypass nonce-to-session binding and replay the token into an attacker-controlled session in implicit and hybrid flows. The vulnerability does not affect the plain authorization code flow and requires the token to pass signature, issuer, and audience validation. The issue is fixed in version 1.9.0.
Authlib versions prior to 1.9.1 contain a critical vulnerability in the OctKey.import_key() and HMAC signing and verification path that allows zero-length key material. This flaw permits a remote attacker to generate valid HS256, HS384, or HS512 signatures for arbitrary token claims if the application's secret lookup returns an empty string or empty bytes. The vulnerability is fixed in Authlib version 1.9.1.
Authlib versions from 1.3.1 up to but not including 1.9.0 contain a vulnerability in the OctKey.import_key() function. The function only checks asymmetric-key markers at the first byte, while PEM loaders accept leading whitespace, comments, or byte-order marks. This discrepancy allows an attacker who knows the public key bytes with such prefixes to use them as an HMAC secret and forge HS256 tokens with arbitrary claims. This vulnerability bypasses the remediation for CVE-2024-37568 and is fixed in version 1.9.0.
Authlib versions from 0.13 up to but not including 1.8.0 contain a vulnerability in the is_secure_transport() function, which uses a textual prefix comparison for loopback HTTP exemptions. This flaw allows an attacker who can supply a URL to certain OIDC operations to bypass the TLS requirement and cause cleartext redirection or acceptance of cleartext endpoints. The vulnerability does not bypass redirect URI exact matching and does not enable token forgery or user authentication bypass. The issue is fixed in version 1.8.0.
PyJWT versions up to 2.13.0 and the current master branch contain a vulnerability where the HMACAlgorithm.from_jwk method accepts an empty HMAC key from a symmetric oct JWK without raising an error. This allows an attacker to forge tokens by exploiting the verification process that uses this empty key, bypassing signature verification when the key is sourced from a JWK with an empty 'k' value. The issue affects verification paths using PyJWK, PyJWKSet, or PyJWKClient. The vulnerability requires no authentication but depends on the verifier trusting a JWKS containing an empty key entry, which can happen due to misconfiguration or unset environment variables. A fix is available.
A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.
Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.
The PyPI package '1h1' version 1.0.0 is identified as malicious. During installation, it downloads and executes malware, indicating clear malicious intent including potential infostealing. This package is associated with typosquatting tactics to deceive users into installing it.
The aanthropic package on PyPI version 1.0.0 is identified as malicious. During installation, it downloads and executes malware, indicating clear malicious intent. This package is associated with a typosquatting campaign designed to trick users into installing harmful software.
The acoustichub 0.1.0 package on PyPI is part of a malicious campaign that involves loader packages designed to download and execute remote malicious scripts. Although the package itself does not contain the malicious payload or exhibit install-time execution hooks or suspicious behaviors, it serves as a mechanism to load malicious code from external sources. This campaign is identified as having clearly malicious intent, such as infostealing.
The phonemeprobe package on PyPI version 0.1.0 is part of a malicious campaign that involves loader packages designed to download and execute remote malicious scripts. Although the package itself does not contain the payload, it acts as a delivery mechanism for malicious code. No credential access, outbound network activity, or installer-affecting behavior was detected in the shipped files, but the overall intent is clearly malicious.
The ttsflow package version 0.1.0 on PyPI is associated with a malicious campaign involving loader packages that execute code from remote URLs. While the package itself does not contain direct malicious payloads or exhibit typical supply-chain attack behaviors such as credential harvesting or backdoors, it is part of a coordinated effort to provide deceptive methods for loading malicious code remotely.