vm2 before 3.12.2 does not apply host-side Promise rejection handling in the sandbox-to-host construct trap. In BaseHandler, the apply trap calls markHostPromiseHandled() on the returned value, but the adjacent construct path returns the result of Reflect.construct without the same sanitization. If an embedder exposes a constructable host function whose constructor returns a native rejected Promise, an untrusted script executed via VM.run can invoke it with `new` and ignore the result; the rejected host Promise crosses the bridge unhandled and, under Node's strict unhandled-rejection policy, is promoted to an uncaught exception that terminates the host process.
http4k-core versions before 6.49.0.0, 5.42.0.0, and 4.51.0.0 use substring matching on the Host header in reverseProxy() and reverseProxyRouting() functions. This behavior can allow an attacker to bypass routing-based authorization by supplying a Host header that contains a configured virtual host name as a substring. This issue affects public-facing inbound HTTP handlers with multiple configured virtual hosts. The vulnerability does not affect outbound dispatch or test-time uses where the Host header is set by the application.
http4k-core versions before 6.48.0.0, 5.42.0.0, and 4.51.0.0 include a BasicCookieStorage implementation that does not properly enforce RFC 6265 cookie scoping rules. This flaw allows cookies intended for one origin or scheme to be sent to others, and Secure cookies may be transmitted over unencrypted HTTP connections. Clients using BasicCookieStorage for multiple origins or schemes are affected, while those using it for a single origin are not.
Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.4.1, a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can therefore stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they either set a new manifest without comparing the returned root CA certificate against the existing one (the default behavior of the contrast CLI) or verify the Coordinator without comparing the root CA certificate against a trusted reference. Under these conditions the attacker can issue certificates that chain back to the rogue Coordinator's root CA and recover arbitrary workload secrets of workloads deployed after the attack. Secrets of the legitimate Coordinator (seed, workload secrets, CA), workload integrity, and certificates chaining to the mesh CA are not affected.
Contrast is a Kubernetes runtime for confidential containers. In versions before 1.12.1, the secure persistent volume feature is vulnerable to a malicious host supplying a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted. Contrast v1.12.1 ships cryptsetup 2.8.1, which disables null ciphers in keyslots when the passphrase is non-empty; v1.13.0 adds detached-header validation in guest memory and integrity protection for secure persistent storage. Contrast persistent volumes were not integrity protected, so integrity impact is not considered.
A critical vulnerability (CVE-2026-100740) exists in the D-Link DIR-895L router firmware version A1_102b07. The flaw is an out-of-bounds write in the tunnel_set_params function of the L2TP Control Channel Parser. It has a CVSS score of 9.9, indicating severe impact on confidentiality, integrity, and availability. Exploit code is publicly available, but no confirmed exploitation in the wild has been reported. No patch or remediation information is currently provided.
CVE-2026-100746 is a medium severity vulnerability in coollabsio Coolify up to version 4.1.0. It affects the GitHub App Setup Handler component, specifically the Github::redirect function in the /webhooks/source/github/redirect file. The vulnerability arises from manipulation of the 'state' argument, leading to missing authentication. This flaw can be exploited remotely. An exploit has been publicly disclosed. Upgrading to version 4.1.1 addresses this issue.
CVE-2026-100865 is a high-severity code injection vulnerability in heym versions before 0.0.53. The vulnerability arises because the workflow executor service evaluates workflow condition expressions using Python's eval() function without sufficient sandboxing. Authenticated users can exploit this flaw by editing workflow condition nodes or importing malicious templates, enabling them to execute arbitrary Python and OS commands with the backend process user's privileges.
CVE-2026-100864 is a high-severity vulnerability in heym versions before 0.0.91. It allows authenticated users to escape the sandbox in the expression engine by exploiting the DotList map/filter and fallback resolver. This enables arbitrary Python code execution on the backend process via crafted workflow expressions using dunder attribute access. The vulnerability is due to improper control of code generation, classified as CWE-94.
Heym versions 0.0.90 and earlier contain two server-side request forgery (SSRF) egress gaps, both remediated in app/services/ssrf_guard.py in 0.0.91. First, the LLM image-edit input loader (_load_image_bytes) fetched caller-controlled HTTP/HTTPS URLs with a bare httpx.get, applying only a scheme check and bypassing the egress-pinning HTTP client; because the workflow DSL supports "imageInput": "$userInput.body.imageUrl", a webhook or API caller can choose the fetch target when a workflow author uses that expression, allowing requests to loopback, RFC1918, and cloud metadata endpoints. Second, _is_public_address unwrapped only IPv4-mapped IPv6 addresses, so IPv6 transition forms — the NAT64 well-known prefix 64:ff9b::/96, deprecated IPv4-compatible ::x.x.x.x addresses, and 6to4 (2002::/16, classified as globally routable by Python 3.11.0 through 3.11.9) — could carry loopback, RFC1918, link-local, or cloud-metadata IPv4 destinations past both the initial URL validation and the dial-time IP pin. Version 0.0.91 routes the image loader through guard_http_url and the guarded client, evaluates NAT64 and IPv4-compatible addresses by their embedded IPv4 address, and refuses 64:ff9b:1::/48, 6to4, and Teredo (2001::/32) outright.
heym, a workflow automation platform, stores and returns multiple capability secrets in plaintext in versions prior to 0.0.91. Affected secrets include webhook header-auth values (returned in cleartext by GET /api/workflows/{id} and persisted unsanitized into execution history), MCP API keys (stored as a plaintext column, returned in config/list responses, and accepted via the ?key= query string so they leak into logs, proxies and Referer headers), portal session tokens (stored and validated by plaintext equality with a 168-hour TTL), workflow execution JWTs (stored in full and re-listed by GET .../execution-tokens), Discord interaction tokens (the full interaction body is stored in execution history), and global variables. A user with read access to a workflow, share/team membership, or anyone able to read the database, a backup, or logs can recover these secrets and replay them to execute workflows or act as the secret owner.
CVE-2026-100861 is a Server-Side Request Forgery (SSRF) vulnerability in heymrun's heym product before version 0.0.105. The vulnerability arises because egress guards are not applied to integration services that use credential-supplied base URLs. This allows authenticated users to bypass SSRF protections by configuring credentials to point to internal addresses such as loopback, private networks, or cloud metadata endpoints. The internal service responses can then be read as workflow node output.
heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential returns None — because the credential ID does not exist or the caller is not authorized to use it — the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redis_host value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend's loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.
CVE-2026-100859 is a Server-Side Request Forgery (SSRF) vulnerability in heymrun heym versions before 0.0.106. It affects the POST /api/credentials/test endpoint, allowing collaborators with shared credential access to exfiltrate the credential owner's secret by overriding the destination URL in the config parameter. This causes the server to send decrypted authentication secrets to attacker-controlled endpoints.
heym before 0.0.109 contains a server-side request forgery vulnerability in the Slack, Discord, and Crawler workflow nodes. These nodes issue HTTP requests to URLs taken from user-created credentials (webhook_url / flaresolverr_url) using an unguarded HTTP client, bypassing the SSRF egress guard that already protects the HTTP, WebSocket, and MCP nodes; the credential API validates only that the URL is non-empty. Any registered user can create a credential pointing at an internal address and execute a workflow, causing the backend to reach loopback, private, link-local, or cloud-metadata endpoints and return the full response body in the node output (non-blind SSRF).
MONAI before 1.5.2 contains a deserialization of untrusted data vulnerability in the algo_from_pickle function in monai/auto3dseg/utils.py. The function reads a .pkl file and passes its contents to pickle.loads without validating the data source or content. If an application invokes algo_from_pickle on an attacker-supplied pickle file, an object defining __reduce__ is executed during deserialization, resulting in arbitrary code execution in the context of the application.
MONAI before 1.6.0 contains an unsafe deserialization vulnerability in the NumpyReader class that unconditionally uses numpy.load with allow_pickle=True when loading .npy and .npz files. Attackers can craft malicious .npy files with pickle payloads that execute arbitrary code when loaded through MONAI's standard data pipeline.
MONAI before 1.6.0 is vulnerable to OS command injection in the nnUNetV2Runner component (monai.apps.nnunet.nnunetv2_runner). User-controlled values taken from the YAML configuration file (notably dataset_name_or_id) and from CLI/kwargs arguments are concatenated into a command string without quoting or validation and then passed to subprocess with shell=True, so shell metacharacters (e.g., ';' on Linux, '&' on Windows) are interpreted. If a victim loads and processes a crafted configuration file — for example by instantiating nnUNetV2Runner with the malicious YAML and invoking a training/validation job such as train_single_model() — arbitrary commands are executed with the privileges of the user running the job.
MONAI versions prior to 1.6.0 contain a high-severity remote code execution vulnerability due to unsafe deserialization of untrusted pickle data in the algo_from_pickle() function. This flaw allows attackers to craft malicious pickle files that execute arbitrary system commands when processed by the vulnerable function.
MONAI through 1.6.0 contains an eval injection vulnerability in _get_fake_spatial_shape() in monai/bundle/scripts.py. The function validates shape expressions with a helper that walks the AST and only collects ast.Name nodes, rejecting any name other than 'p' or 'n', before passing the string to eval(). Expressions built solely from constants and attribute, subscript, or call nodes (for example "(1).__class__.__bases__[0].__subclasses__()" or "int.__class__.__init__.__globals__") contain no ast.Name nodes and therefore bypass the allowlist. Because the shape value originates from bundle metadata consumed by _get_real_input_data and verify_net_in_out (reachable through the bundle 'verify_net_in_out' CLI flow), an attacker who can influence a bundle's metadata can escape the eval sandbox via object introspection chains and achieve code execution in this non-default flow.