Threats tagged 'pypi'
1,403 threats
Most recently published first
| Severity | CVSS | Signals | Threat | Source | Published | Score and star |
|---|---|---|---|---|---|---|
| Malicious | – | MaliciousGCVE Database The PyPI package 'httpprobe' version 1.0.0 contains malicious code that attempts to download and execute a remote executable described as a Mirai agent. The package overrides the install command in setup.py to run this malicious code during installation. Although the remote executable was not available during analysis, the use of Onion routing and localhost fallback indicates preparation for malicious activity. This package poses a direct threat by executing unauthorized code on the user's system. | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (c3b9ca286cef4b241ded9603c192ce5b13e155cad9b017ee3f89b98674065374) During import, this malicious copy of a legitimate package downloads an encrypted data disguise as an image. It contains an archive with a next-stage script that uses the Polygon blockchain (contract 0xC7c9026a3a7e27ec6Ce2D09B19FC1FB4bc978BBb) to get the C2 address. The script then communicates with C2 over an encrypted channel to get further commands and ensures persistence. C2 delivers an executable that is executed by loading it into the memory of another process. During analysis, the encryption key and delivered binary contained test data suggesting the author experiments with building a botnet. The package has been briefly used as dependency of a Github project. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-yt-api-dlp Reasons (based on the campaign): - peristence-autorun - Downloads and executes a remote malicious script. - clones-real-package - persistence - data-from-blockchain - custom-crypto | GCVE Database | |||
| High | 7.8 | EPSS 0.2% | CVE-2026-12252nltk/nltk · Code Injection High7.8EPSS 0.2%CVE Database V5CVE-2026-12252 In nltk/nltk versions 3.9.3 and earlier, five Stanford interface classes (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, and StanfordNeuralDependencyParser) are vulnerable to untrusted JAR code execution. These classes accept user-controllable JAR paths and execute them via the `java()` function, which invokes `subprocess.Popen()` without integrity verification. This vulnerability is identical to CVE-2026-0848, which was fixed for StanfordSegmenter by adding SHA256 verification. However, the fix was not applied to these additional classes, leaving them susceptible to arbitrary code execution when loading untrusted JAR files. | CVE Database V5 | ||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (0bbaea22b635a4a8425964572b733b806f45714a9090492d1c39d545088fe336) The package was found to contain malicious code or consuming dependency that contains malicious code ## Source: kam193 (f4594bf7abce5a96c971ecc42fc52eec534a545cfc614c1b8f3b8d18ca02dd9d) The campaign consists of multiple packages. The trigger sits in the package 'procwire,' which depends on two others. During installation, procwire uses schemavault and bytekit packages. The first one holds the URL holding malware (in two places, once as steganography in the bundled image and once as a fallback just as a list of encoded bytes). The bytekit implements simple custom decoding used to retrieve back the URL in the fallback method. Additionally, procwire is also a dependency of confighub, turning another package into malware. The downloaded executable is run and quickly removed. The executable likely contains an infostealer and contacts the domain 030502[.]xyz --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-procwire Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - The malicious code is intentionally included in a dependency of the package - malware - steganography | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (4ae0aa9efa2a8389cfe9d5c41d5ab3689f4965c945a24613493f94f9de033ab1) schemavault 4.1.0 is presented as a schema-validation library but ships capabilities and data that have no relationship to schema validation. schemavault/_registry.py defines three underscore-prefixed byte arrays: `_ep` (36 bytes), `_p` (7 bytes), and `_k` (16 hex constants shaped like a symmetric key). None of these names are read anywhere in the schemavault package. schemavault/imaging.py exports `extract_metadata()`, an LSB steganography decoder that reads a length-prefixed hidden string from the shipped asset `schemavault/assets/logo.bmp` (first 16 bits = length, then length*8 bits of pixel-LSB characters); this function is likewise not invoked from anywhere in schemavault. setup.py declares `install_requires=['bytekit']` — an unpinned, generically named dependency unrelated to schema validation. The pattern is a two-package split: the primary package holds encoded payload material and a decoder utility, and the unpinned generically-named dependency is positioned to be the loader that actually decodes and executes the staged content on install or import. Because pip resolves `bytekit` without a version pin from whichever registry is configured, `pip install schemavault` pulls attacker-controlled code into the installer's environment. The dormant carrier data + LSB decoder + unrelated unpinned loader dep together match the staged-dropper shape rather than any legitimate schema-library composition. ## Source: kam193 (2af83487d12e2c9e16e3a5fae1ac369bacd5d39622a04c537edd0dbdda4a143a) The campaign consists of multiple packages. The trigger sits in the package 'procwire,' which depends on two others. During installation, procwire uses schemavault and bytekit packages. The first one holds the URL holding malware (in two places, once as steganography in the bundled image and once as a fallback just as a list of encoded bytes). The bytekit implements simple custom decoding used to retrieve back the URL in the fallback method. Additionally, procwire is also a dependency of confighub, turning another package into malware. The downloaded executable is run and quickly removed. The executable likely contains an infostealer and contacts the domain 030502[.]xyz --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-procwire Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - The malicious code is intentionally included in a dependency of the package - malware - steganography | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (805d9b5848999d2ba85368446cb12d90bf350b8201a78dd475079c04f180dd81) confighub 7.0.1 declares install_requires=['procwire'] and imports procwire at package load in __init__.py under a version gate that silently swallows ImportError (try: import procwire as _pw except ImportError: pass). procwire is not referenced anywhere in confighub's own code (loader.py, manager.py) and is not mentioned in the README or API documentation. confighub's own code is benign, but installing confighub forces resolution and import of an undocumented sibling package whose behavior determines the actual installer-side risk. If procwire is attacker-controlled or malicious, confighub acts as the delivery vector; if procwire is a benign helper, this is only a documentation/hygiene issue. Human review of procwire itself is required to determine whether this is a dependency-based dropper or an undisclosed but benign split. ## Source: kam193 (7c0b6d6eae8eecdf0317e7d4c624ff2a1eee1ca58c92c6b4fac34dd2567f4556) This package depends on malicious 'procwire', which starts malicious actions during installation. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-procwire Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - The malicious code is intentionally included in a dependency of the package - malware - steganography | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database The procwire package on PyPI contains malicious code that executes during installation by overriding the install command. It downloads and runs a remote executable, which is likely an infostealer, contacting a suspicious domain. The malicious payload is obfuscated and hidden using steganography and encoded data within dependencies. This threat also affects packages depending on procwire, such as confighub, spreading the malware further. The affected versions are 5.2.3, 5.2.5, 5.2.6, and 5.2.7. | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (2df148f70b40274f48d5bc4d8ea5a97bb434a743cf7a5c1b271a5a5cd7fa3907) During installation the obfuscated code downloads a malicious executable from a remote location. Code is designed to survive different blocks: first, there is an attempt to download the executable from one of five Cloudflare Workers. If it's not successful, the code falls back to download using DNS: first, it gets a TXT record from c.lin.dl.wel1[.]ru. This record returns a number, which is then used to iterate over domains in the form <0...n>.lin.dl.wel1[.]r and reconstruct the encoded executable from their TXT records. The executable is finally saved under a partially random name, executed, and removed after execution. The Linux executable contacts a few domains, but there is no more detailed information about its behavior available. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-haproxy-config-client Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - dependency-confusion - other - malware - covering-tracks - targetted-attack - data-stored-in-dns | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (f70d07844bca4fadfcedb195f5768c8a95318af4d62a4bcec94556b99b72c4ad) During installation the obfuscated code downloads a malicious executable from a remote location. Code is designed to survive different blocks: first, there is an attempt to download the executable from one of five Cloudflare Workers. If it's not successful, the code falls back to download using DNS: first, it gets a TXT record from c.lin.dl.wel1[.]ru. This record returns a number, which is then used to iterate over domains in the form <0...n>.lin.dl.wel1[.]r and reconstruct the encoded executable from their TXT records. The executable is finally saved under a partially random name, executed, and removed after execution. The Linux executable contacts a few domains, but there is no more detailed information about its behavior available. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-haproxy-config-client Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - dependency-confusion - other - malware - covering-tracks - targetted-attack - data-stored-in-dns | GCVE Database | |||
| High | 8.8 | EPSS 0.7% | CVE-2026-12481keras-team/keras · Deserialization of Untrusted Data High8.8EPSS 0.7%CVE Database V5CVE-2026-12481 CVE-2026-12481 is a high-severity vulnerability in keras-team/keras version 3.14.0 involving unsafe deserialization in the Lambda layer. The issue arises because the _raise_for_lambda_deserialization() function does not properly enforce safe-mode when safe_mode is None, which is the default outside a SafeModeScope context. This allows attacker-controlled marshal bytecode to be deserialized, potentially leading to arbitrary OS-level code execution. The vulnerability affects calls to keras.layers.deserialize(config), keras.models.clone_model(model), and Lambda.from_config(config) without SafeModeScope(True). The product is a cloud service, and a patch is available. No known exploits are reported in the wild. | CVE Database V5 | ||
| High | 7.0 | EPSS 0.2% | CVE-2026-52817Linuxfabrik Monitoring Plugins · Sudoers may be able to obtain privilege escalation via /usr/bin/apt-get arguments High7.0EPSS 0.2%GCVE DatabaseCVE-2026-52817 Linuxfabrik Monitoring Plugins provides monitoring plugins for Icinga, Nagios, and related systems. Prior to version 5.1.0, the shipped assets/sudoers/Debian.sudoers policy allowed the nagios or icinga account to execute /usr/bin/apt-get as root without restricting its arguments. An attacker who already controls that monitoring account can supply the APT::Update::Pre-Invoke option to execute an arbitrary command while apt-get runs with root privileges, resulting in a root shell and complete compromise of the host. The vulnerable rule supports the check-plugins/deb-updates/deb-updates plugin, but it authorized arbitrary apt-get argument sequences rather than only the required apt-get update --quiet 2 command. This issue is fixed in version 5.1.0. | GCVE Database | ||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (ad72fe1fdc56e7fb5716a906fb8481bfe1e477d2f97c649d5db853a79130628a) Installing the package or importing the module exfiltrates basic information about the host, and the package has no other purpose. --- Category: PROBABLY_PENTEST - Packages looking like typical pentest packages, but also anything that looks like testing, exploring pre-prepared kits, research & co, with clearly low-harm possibilities. Campaign: GENERIC-standard-pypi-install-pentest Reasons (based on the campaign): - The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk. - The package overrides the install command in setup.py to execute malicious code during installation. | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (93043b3f00a64c66fb0680256387471b656f222556c282c9cb1680347f14fae8) Installing the package or importing the module exfiltrates basic information about the host, and the package has no other purpose. --- Category: PROBABLY_PENTEST - Packages looking like typical pentest packages, but also anything that looks like testing, exploring pre-prepared kits, research & co, with clearly low-harm possibilities. Campaign: GENERIC-standard-pypi-install-pentest Reasons (based on the campaign): - The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk. - The package overrides the install command in setup.py to execute malicious code during installation. | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (9494382fb3885f95987ec830f096aac6cde589cac9485b6a347bafed9a8a7e39) Installing the package or importing the module exfiltrates basic information about the host, and the package has no other purpose. --- Category: PROBABLY_PENTEST - Packages looking like typical pentest packages, but also anything that looks like testing, exploring pre-prepared kits, research & co, with clearly low-harm possibilities. Campaign: GENERIC-standard-pypi-install-pentest Reasons (based on the campaign): - The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk. - The package overrides the install command in setup.py to execute malicious code during installation. | GCVE Database | |||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (b8b4f17043a9c57ea2087c59c771151186c117ab64cbf5c45df85df62469aa89) Installing the package or importing the module exfiltrates basic information about the host, and the package has no other purpose. --- Category: PROBABLY_PENTEST - Packages looking like typical pentest packages, but also anything that looks like testing, exploring pre-prepared kits, research & co, with clearly low-harm possibilities. Campaign: GENERIC-standard-pypi-install-pentest Reasons (based on the campaign): - The package contains code to exfiltrate basic data from the system, like IP or username. It has a limited risk. - The package overrides the install command in setup.py to execute malicious code during installation. | GCVE Database | |||
| High | 7.8 | EPSS 1.1% | High7.8EPSS 1.1%GCVE Database Recce OSS server versions prior to 1.50.0 that expose the server to untrusted networks without authentication are vulnerable to unauthenticated SQL execution via the query run API. When configured with a DuckDB-backed project, this allows attackers to read and write files accessible to the Recce server process, potentially leading to local file disclosure, tampering with artifacts, stored XSS via modified static files, and modification of application files if writable. The vulnerability is more severe if Recce runs as root, granting root-level file access. The issue is patched in Recce version 1.50.0. | GCVE Database | ||
| Low | – | EPSS 0.4% | CVE-2026-49292Kiwitcms · Kiwi TCMS's /init-db/ page renders and responds to requests after first use LowEPSS 0.4%GCVE DatabaseCVE-2026-49292 Kiwi TCMS's /init-db/ page, used for initial database setup, continues to respond to requests even after the initial setup is complete. This page does not require authentication because it is intended for first-time setup before user accounts exist. However, repeated access to this page after setup results only in a no-op migration status with no data loss, no state changes, and no confidential information disclosure. The page has been updated to short-circuit and perform no operations if migrations are already applied. | GCVE Database | ||
| High | 8.7 | EPSS 0.7% | CVE-2026-50180Langroid · SQLChatAgent _validate_query blocklist misses pg_read_file family enabling arbitrary file read High8.7EPSS 0.7%GCVE DatabaseCVE-2026-50180 ### Summary `SQLChatAgent` in `langroid` ships a `_validate_query` defense-in-depth layer whose `_DANGEROUS_SQL_PATTERNS` regex blocklist enumerates dangerous SQL primitives by specific function name. The list misses the canonical PostgreSQL filesystem-disclosure family `pg_read_file()`, `pg_stat_file()`, `pg_ls_logdir()`, `pg_ls_waldir()`, `pg_current_logfile()` (and similar `SELECT`-shaped functions in the same family). It also leaves SQL Server `OPENDATASOURCE` and SQLite `ATTACH '<file>' AS x` (DATABASE keyword omitted) unblocked. An attacker able to shape the LLM's generated SQL (directly via prompt input or transitively via prompt-injection in data the LLM ingests) can read arbitrary files from the PostgreSQL host through ordinary `SELECT` queries, even with the agent's strict default configuration (`allow_dangerous_operations=False`, `allowed_statement_types=['SELECT']`). The payloads survive the statement-type allowlist (each is a `SELECT`) and pass through the regex blocklist (none of the function names match), then reach the live SQLAlchemy engine via `SQLChatAgent.run_query`. ### Affected versions `langroid` `<= 0.63.0` (latest at the time of this report; PyPI release 2026-05-27). The vulnerable code path is `langroid/agent/special/sql/sql_chat_agent.py::_validate_query`, which consults the module-level `_DANGEROUS_SQL_PATTERNS` literal at `sql_chat_agent.py:113-141`. ### Privilege required Any caller able to influence the LLM-generated `RunQueryTool.query` string that reaches `SQLChatAgent.run_query`. In a typical deployment this is any client of a SQLChatAgent-backed service, or any upstream data source whose content the LLM is asked to read and summarise. No PostgreSQL credentials are required from the attacker; the agent holds them. ### Vulnerable code `langroid/agent/special/sql/sql_chat_agent.py:113-141` (the `_DANGEROUS_SQL_PATTERNS` literal) and `sql_chat_agent.py:546-615` (the `_validate_query` method that consults it): ```python # sql_chat_agent.py:113 _DANGEROUS_SQL_PATTERNS: List["re.Pattern[str]"] = [ re.compile(r"\bcopy\b[\s\S]*\bprogram\b", re.IGNORECASE), re.compile(r"\bpg_read_server_files?\b", re.IGNORECASE), re.compile(r"\bpg_read_binary_file\b", re.IGNORECASE), re.compile(r"\bpg_ls_dir\b", re.IGNORECASE), re.compile(r"\blo_(import|export)\b", re.IGNORECASE), re.compile(r"\binto\s+(outfile|dumpfile)\b", re.IGNORECASE), re.compile(r"\bload_file\s*\(", re.IGNORECASE), re.compile(r"\bload\s+data\b", re.IGNORECASE), re.compile(r"\bload_extension\s*\(", re.IGNORECASE), re.compile(r"\battach\s+database\b", re.IGNORECASE), re.compile(r"\bxp_cmdshell\b", re.IGNORECASE), re.compile(r"\bsp_oacreate\b", re.IGNORECASE), re.compile(r"\bsp_oamethod\b", re.IGNORECASE), re.compile(r"\bopenrowset\b", re.IGNORECASE), re.compile(r"\bbulk\s+insert\b", re.IGNORECASE), re.compile( r"\bcreate\s+(or\s+replace\s+)?(function|procedure|trigger)\b", re.IGNORECASE, ), re.compile(r"\bcreate\s+extension\b", re.IGNORECASE), ] ``` The blocklist is a list of `\b<exact-token>\b` literals. PostgreSQL ships several near-name functions on the same primitive that none of these match: | Function | What it returns | Matched by blocklist? | |---|---|---| | `pg_read_server_file('/path')` | file contents | yes (`pg_read_server_files?`) | | `pg_read_binary_file('/path')` | binary contents | yes | | `pg_ls_dir('/path')` | directory listing | yes | | `pg_read_file('/path')` | file contents | **no** (no `_server_` infix) | | `pg_stat_file('/path')` | size, mtime, ctime, atime, isdir | **no** | | `pg_ls_logdir()` | filenames in PostgreSQL log dir | **no** | | `pg_ls_waldir()` | WAL filenames and sizes | **no** | | `pg_ls_tmpdir()` | temp-dir listing | **no** | | `pg_ls_archive_statusdir()` | archive-status directory listing | **no** | | `pg_current_logfile()` | active server log path | **no** | Each of these is a `SELECT`-shaped function call. They pass the `sqlglot_exp.Select`-only statement-type allowlist applied at `sql_chat_agent.py:583-614`, then evade the regex blocklist (their names contain no token the blocklist enumerates), then reach the SQLAlchemy `session.execute(text(query))` sink inside `SQLChatAgent.run_query` (line 631 onwards). Two non-PostgreSQL secondary gaps with the same regex-enumeration shape: - The SQLite pattern `\battach\s+database\b` requires the literal `DATABASE` keyword. Per the SQLite grammar (https://www.sqlite.org/lang_attach.html) the keyword is optional: `ATTACH '/path/to/db' AS x` is valid syntax and matches no entry in the blocklist. Whether the agent rejects this via the statement-type allowlist depends on how the configured `sqlglot` dialect parses it; on PostgreSQL dialect parsing fails (sqlglot returns no `Select`) and the statement-type check rejects, but a SQLite-dialect SQLChatAgent (`database_uri="sqlite:///..."`) returns the statement as `sqlglot_exp.Attach`, whi | GCVE Database | ||
| Malicious | – | MaliciousGCVE Database --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (b0dd6dc392ad68861c938e7798773adf5359c835743e711a834d84221b481bdf) The package's top-level public API `dt_validator.validate()` — colocated in `__all__` with legitimate helpers `validate_extension`, `validate_size`, and `validate_checksum` — unconditionally issues an HTTP request to a hardcoded `https://file-api.free.beeceptor.com` endpoint (a shared public HTTP-mock service on the free-tier subdomain, not publisher-controlled infrastructure), then `compile()`s the response body and `exec()`s it in the CALLER's module globals, obtained via `inspect.currentframe().f_back.f_globals` (see `api_client.py` `DEFAULT_API_ENDPOINT` and `validate_data(..., allow_exec=True, namespace=caller_globals)`). Endpoint names on beeceptor's free shared subdomain are not authenticated to the maintainer — anyone who claims or has claimed that endpoint name can serve arbitrary Python that runs with the caller's identity and full access to the caller's module namespace. The README further documents a different default host (`file-read.free.beeceptor.com`) than the code actually contacts (`file-api.free.beeceptor.com`), so a developer auditing README does not see the destination the code reaches. Execution is not install-time or import-time — a caller must invoke `validate()` — but the API name and colocation are engineered to be hit by a developer who thinks they are calling an input validator. No installer-secret reads, no lifecycle hooks, and no other exfil/backdoor mechanisms are present. Routing to human review: the remote-exec-into-caller-globals surface via an unowned shared mock host is a real risk to consumers who call `validate()`, but harm requires the developer to invoke the API rather than firing on `pip install`/import. ## Source: kam193 (0fc0256380d811cdce05ffa9c3644a5f7e4ebd6f7acfce0f955935b42449b17a) Code contains a function to execute remote code, which at the time of analysis was extracting the "auth_user" table from Django DB. The remote code execution is partially documented and disguised with multiple warnings, but a) the 'convenience function' uses a hardcoded endpoint and loads results to the global namespace, b) the warnings are silenced by default. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-dt-validator Reasons (based on the campaign): - Downloads and executes a remote malicious script. - action-hidden-in-lib-usage | GCVE Database | |||
| High | 7.1 | EPSS 0.2% | CVE-2026-50181Langroid · Path traversal in the file tools allows read/write outside configured current directory High7.1EPSS 0.2%GCVE DatabaseCVE-2026-50181 Langroid's ReadFileTool and WriteFileTool do not properly restrict file operations to the configured current directory (curr_dir). They change the process working directory to curr_dir but do not validate that file paths remain within this directory, allowing path traversal sequences like '../' to read or write files outside the intended boundary. This can lead to unauthorized reading or modification of files outside the sandbox or project directory. The vulnerability affects versions of Langroid prior to 0.64.0. | GCVE Database |
Page 45 of 72