A vulnerability was identified in java-json-tools json-patch up to 1.13. This affects the function CopyOperation.apply/MoveOperation.apply of the file src/main/java/com/github/fge/jsonpatch/CopyOperation.java of the component Copy Move Operations. The manipulation leads to improper access controls. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.
A security flaw has been discovered in java-json-tools jackson-coreutils 2.0. This vulnerability affects the function TreePointer.tokensFromInput of the file src/main/java/com/github/fge/jackson/jsonpointer/TreePointer.java of the component JSON Pointer parser. The manipulation results in allocation of resources. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
A vulnerability was found in java-json-tools jackson-coreutils 2.0. Affected by this vulnerability is the function BigDecimal.toPlainString of the file src/main/java/com/github/fge/jackson/JacksonUtils.java. Performing a manipulation results in resource consumption. The attack may be initiated remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.
A vulnerability has been found in java-json-tools json-patch up to 1.13. Affected by this vulnerability is the function JsonPatch.apply of the file src/main/java/com/github/fge/jsonpatch/JsonPatch.java of the component Patch Operation Handler. The manipulation leads to resource consumption. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.
A security flaw has been discovered in mwiede jsch up to 2.28.5. Affected is the function getRevokedKeys of the file src/main/java/com/jcraft/jsch/KnownHosts.java. Performing a manipulation of the argument known_hosts results in improper check for certificate revocation. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitability is told to be difficult. The exploit has been released to the public and may be used for attacks. Upgrading to version 2.28.6 is able to address this issue. The patch is named 194a2f76a5c0f1c3f778565be3fd66bcafc42d23. You should upgrade the affected component.
In the Linux kernel, the following vulnerability has been resolved: erofs: remove fscache backend entirely EROFS over fscache was introduced to provide image lazy pulling functionality. After the feature landed, the fscache subsystem made netfs a new hard dependency, which is unexpected for a local filesystem and has an kernel-defined caching hierarchy which could be inflexible compared to the fanotify pre-content hooks. Therefore, this feature has been deprecated for almost two years. As EROFS file-backed mounts and fanotify pre-content hooks both upstream for a while and already providing equivalent functionality (erofs-utils has supported fanotify pre-content hooks), let's remove the fscache backend now. The main application of this feature is Nydus [1], and they plan to move to use fanotify pre-content hooks in the near future too. I hope this patch can be merged into Linux 7.2, which is also motivated by newly found implementation issues [2][3] that are not worth investigating given the deprecation and limited development resources. The associated fscache/cachefiles cleanup patch will follow separately through the vfs tree (netfs) later: it seems fine since the codebase is isolated by CONFIG_CACHEFILES_ONDEMAND. [1] https://github.com/dragonflyoss/nydus/blob/v2.1.0/docs/nydus-fscache.md [2] https://github.com/dragonflyoss/nydus/pull/1824 [3] https://lore.kernel.org/r/20260619135800.1594811-1-michael.bommarito@gmail.com
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: hid_dump_input(field->report->device, field->usage + offset, value); if (offset >= field->report_count) { hid_err(...); return -1; } Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs "offset (1) exceeds report_count (1)" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from list_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
On August 31, 2026, a malicious Terraform module was served from the legitimate registry.coder.com domain for approximately 14 hours. This module included an extra telemetry block that exfiltrated environment data to an attacker-controlled domain. No CVE was assigned, so standard vulnerability scanning tools did not flag this incident. The compromised module affected users who created or updated templates, ran template dry-runs, or built workspaces with module caching disabled during the incident window. Sensitive data potentially leaked includes cloud credentials, API keys, tokens, SSH keys, and deployment configurations. Coder has released patched builds and a tool to help identify affected deployments, but detection requires manual checking. No attacker-side logs are available, so affected users must proactively verify exposure.
The npm package 'box-sign-client-poc' version 1.0.0 contains malicious code that executes during installation. It runs a script that collects the installer's hostname and OS username, then sends this information via a DNS query to a third-party collector at canarytokens.com. This behavior results in exfiltration of host and user identifiers to an external party at install time.
The npm package @bx-ui-framework/authentication versions 1.2.0 and 15.0.0 declare a runtime dependency on a package fetched directly from an untrusted HTTPS URL rather than the official npm registry. This dependency is named 'microfrontend' and is sourced from https://repo.artifactorymanager.com/bx-ui-framework/authentication, which is unrelated to the package's publisher identity. Because there is no version pinning, integrity hash, or signature verification, the content fetched can be fully controlled and changed by the operator of that domain, potentially delivering malicious code during installation.
The @bx-ui-framework/microfrontend npm package version 15.0.0 declares a runtime dependency on a package fetched from an untrusted HTTPS URL (https://repo.artifactorymanager.com/bx-ui-framework/microfrontend) instead of the official npm registry. This URL is not associated with the legitimate package publisher and serves a tarball without version or hash pinning, allowing arbitrary code execution during installation.
The npm package @bx-ui-framework/common versions 1.2.0 and 15.0.0 declare a self-referential dependency with a URL pointing to an external repository (https://repo.remoteknight.com/bx-ui-framework/common) instead of a version range. This causes npm to fetch and install code from that URL during installation, executing any lifecycle scripts it contains. The package's shipped index.js is inert, making the dependency declaration the primary attack vector. Whoever controls the external repository can execute arbitrary code on any machine installing the package, exploiting a dependency confusion technique.
The PyPI package `tsshare` is malicious. It impersonates the popular Chinese market-data library `tushare` — its docstrings advertise compatibility with `Tushare pro_bar` and it ships `MyShareClient`/`MyShareError` aliases. `tsshare/client.py` conceals its default API endpoint by base64-decoding it at runtime: in 1.0.5–1.0.18 the value decodes to the hardcoded raw IP `https://47.112.191.75` (Alibaba Cloud, China), and in 1.0.19 it rotates to the domain `https://fszzw56.com`. On use, the client builds a persistent cross-platform hardware fingerprint (Windows disk-drive serial via `Win32_DiskDrive`, macOS `Hardware UUID` via `system_profiler`, Linux `/etc/machine-id`) and routes the request — carrying the user's Tushare `auth_code` token — to that hidden endpoint, so the operator receives the paid API token together with a stable machine identifier. There is no install-time hook; exfiltration occurs on API use.
---
_-= Per source details. Do not edit below this line.=-_
## Source: amazon-inspector (539c8fdb69887b093801655215f1857f53abb20e6dc763198c543def86c39387)
The package presents itself as a drop-in replacement for Tushare's pro_api, but every method call is dispatched through a query() that POSTs to a hardcoded default backend at https://47.112.191.75/api/v1/proxy rather than to tushare.pro. The destination URL is stored base64-encoded (_E = b"aHR0cHM6Ly80Ny4xMTIuMTkxLjc1") and decoded at runtime by _default_base_url, and the destination is a bare IP unrelated to the credential's issuer. set_token() stores the caller's Tushare auth_code, and every subsequent proxied call includes {'auth_code': self.auth_code,...} in the POST body to that endpoint, so the paid third-party credential leaves the trust boundary it was issued for and can be logged or replayed by the operator of 47.112.191.75. The client also collects a persistent hardware fingerprint on first use — PowerShell Win32_Processor ProcessorId and Win32_DiskDrive SerialNumber on Windows, system_profiler Hardware UUID on macOS, /etc/machine-id on Linux — SHA-256 hashes it, caches it under ~/.tsshare/device_id.json, and attaches it as meta.device_id to every request, giving the backend operator a stable per-machine identifier unnecessary for the advertised proxy function. TLS certificate verification on the requests.Session is disabled by default (session.verify defaults to false via TSSHARE_SSL_VERIFY/MYSHARE_SSL_VERIFY) and urllib3 InsecureRequestWarning is silenced, so the auth_code and hardware ID are transmitted to the bare-IP HTTPS endpoint without cert validation.
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.12.97. See the following advisory for the container images for
this release:
https://access.redhat.com/errata/RHSA-2026:59833
Security Fix(es):
None
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.12 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.12/html-single/updating_clusters/index#updating-cluster-within-minor.
Joomla Extension - j2commerce.com - Missing authorization on Apps controller delegation chain in J2Store 1.0.0-3.3.21, 4.0.0-4.0.21, 4.1.0-4.1.6 - `J2StoreControllerApps`'s `appTask` delegation path instantiates app-plugin controllers with no ACL check anywhere in the code. It currently returns 403 only as a side effect of `fof.xml`'s wildcard-deny resolving under the singularised ACL key `app`, which has no explicit allow rule — not because of any deliberate check. Behind that path, `applocalizationdata::getInstallerTool()` used a caller-influenced table name with no allow-list, both to select a `#__j2store_*` table for truncation and to build a path to SQL files it then executes — a path-traversal-capable file read/execute.
Joomla Extension - j2commerce.com - Unauthenticated PayPal callback forgery leading to order confirmation fraud in J2Store 1.0.0-3.3.21, 4.0.0-4.0.21, 4.1.0-4.1.6 - The PayPal IPN listener's signature check (`_validateIPN()`) accepted `UNVERIFIED` and any non-`INVALID` response as valid, made its verification request with `CURLOPT_SSL_VERIFYPEER` disabled, and stored its verdict in a field nothing downstream ever checked — so processing continued regardless of the outcome. Separately, the paid-amount comparison only ran when `mc_gross` was a positive number; omitting the field from the POST body (`floatval(null) == 0`) skipped the check entirely. Combined with a merchant-configured `receiver_email` and a sequential, enumerable order id read from the `custom` field, an anonymous POST was enough to move a pending order straight to `CONFIRMED` with no payment, or force another customer's pending order to `FAILED`. `paypalv2.php` performed no amount check under any circumstances.