Predictable value generation in Citrix NetScaler ADC and Gateway (CWE-342) lets unauthenticated remote attackers predict subsequent values from previously observed ones, primarily compromising integrity and availability rather than confidentiality. The vendor rates this 8.8 (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, VC:L/VI:H/VA:H), while our independent assessment sees a 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H) indicating a high attack complexity because exploitation typically requires harvesting at least one prior value. Affected versions are ADC before 14.1-73.37 and 13.1-64.23 (also 14.1-73.37 FIPS and 13.1.37.279 FIPS/NDcPP) and Gateway before 14.1-73.37 and 13.1-64.23; vendor patches are available and no public exploit identified at time of analysis.
Remote unauthenticated attackers can trigger a memory overflow in Citrix NetScaler ADC and Gateway, leading to unpredictable behavior or denial of service. Affected versions include ADC before 14.1-73.37 and 13.1-64.23 (plus FIPS/NDcPP builds before 14.1-73.37 and 13.1.37.279), and Gateway before 14.1-73.37 and 13.1-64.23. The vendor CVSS 4.0 base score is 8.8 with availability as the dominant impact (VA:H), and no public exploit has been identified at time of analysis.
A memory overflow in Citrix NetScaler ADC and NetScaler Gateway can be triggered by unauthenticated remote attackers (CVSS vector PR:N/UI:N/AV:N), causing unpredictable appliance behavior and denial of service. Affected deployments are ADC before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, and before 13.1.37.279 FIPS/NDcPP, plus Gateway before 14.1-73.37 and before 13.1-64.23. The vendor rates the flaw 8.8, and the dominant impact is availability (VA:H) rather than confidentiality or integrity compromise; no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status.
Memory overflow in Citrix NetScaler ADC and NetScaler Gateway running versions prior to 14.1-73.37 or 13.1-64.23 (and the corresponding FIPS/NDcPP builds) can be triggered over the network by an unauthenticated attacker with no user interaction, producing unpredictable or erroneous appliance behavior or a denial of service. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H) is dominated by availability impact, with only incidental confidentiality and integrity exposure, so the demonstrated risk is service disruption rather than confirmed remote code execution. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so the practical exposure driver is network reachability to an unpatched ADC or Gateway instance; fixed builds are available via Citrix bulletin CTX697096.
Feature policy bypass in Citrix NetScaler ADC and Gateway allows unauthenticated remote attackers to evade certain configured policies when those policies use HTTP URL-based expressions, potentially bypassing policy enforcement controls. Affected are ADC before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, and before 13.1.37.279 FIPS/NDcPP; Gateway before 14.1-73.37 and before 13.1-64.23. No public exploit identified at time of analysis, and the vendor advisory CTX697096 covers this issue alongside related NetScaler CVEs; exploitation requires the specific precondition of a URL-based feature policy, which limits real-world risk.
Stored cross-site scripting in the commercial Download Manager Pro WordPress plugin (before version 7.5.6) allows an unauthenticated attacker to inject script payloads through the plugin's email-locked download subscription form, which are then rendered unsanitized on an administrator-facing page and execute in the admin's browser session. The free plugin distributed under the same slug does not ship the affected feature and is not vulnerable, so only sites running the Pro edition with that subscription form in use are exposed - and exploitation only completes when an administrator subsequently views the poisoned admin page. Publicly available exploit code exists (WPScan published the vector), but there is no confirmed active exploitation (CISA KEV does not list it), SSVC records Exploitation: none and Automatable: no because of the mandatory admin interaction, and EPSS is low at 0.17% (6th percentile), which is why this is treated as a moderate-priority issue rather than the critical score implied by the vendor's 8.8 CVSS.
Administrator password-reset links in Sylius are built from the unvalidated request Host header, so an unauthenticated attacker who knows an administrator's email address can send a single request to /admin/forgotten-password (or POST /api/v2/admin/administrators/reset-password) with a forged Host or X-Forwarded-Host header and cause the reset-token link in the generated email to point at an attacker-controlled domain. If the targeted administrator then clicks the poisoned link, the attacker captures a valid reset token and can take over the administrator account, yielding high impact on confidentiality, integrity and availability (assessed CVSS:3.1 8.7, AV:N/AC:L/PR:N/UI:R). No public exploit identified at time of analysis, and exploitation is neutralized in deployments that enforce Symfony trusted_hosts or normalize/reject untrusted Host and X-Forwarded-Host values at a reverse proxy or load balancer; only the admin reset flow is affected, since the shop-side reset builds its link from the channel's configured hostname.
JWT audience confusion in Sylius (before 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9) allows a self-registered shop customer to escalate to full administrator access. Because tokens issued by the Shop API omit any firewall/audience identifier, an attacker who registers a shop account using an existing administrator's email address receives a token that the Admin API resolves to that administrator, granting complete administrative control (CVSS 3.1 8.7, PR:L, C/I/A:H). Exploitation requires the default configuration with both Shop and Admin JWT firewalls and self-service shop registration enabled, plus knowledge of the admin's email; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but public patch and GitHub advisory details are available.
Insufficient verification of payment-claim state in the Sylius e-commerce platform (versions before 2.1.16 and 2.2.9) lets unauthenticated remote attackers inflate an order after a payment gateway has already captured the original, smaller amount, causing Sylius to mark the enlarged order as fully paid while the gateway only collected the lower figure. The flaw is reachable with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (integrity-only, high impact) and requires no login, but does demand a live storefront with a capture/authorize-capable payment gateway, an attacker-funded legitimate small transaction, and control over the timing between gateway capture and cart recalculation. This is a genuine financial-fraud defect rather than a theoretical high-score paper cut, though no confirmed active exploitation (CISA KEV) and no public exploit code were identified at time of analysis.
An out-of-bounds write in the L2TP control-channel parsing routine (tunnel_set_params in tunnel.c) of D-Link DIR-895L firmware A1_102b07 lets a remote attacker corrupt memory by sending a crafted L2TP control message containing a malformed Host Name AVP. The vendor's CVSS 4.0 score of 8.6 reflects a network-reachable, low-complexity attack requiring low privileges (PR:L), and VulDB has published a public proof-of-concept write-up, so publicly available exploit code exists. Note that the vendor vector's subsequent-system (SC/SI/SA:H) clause appears inflated - the flaw is an in-process memory corruption on a single consumer router - and the DIR-895L is a discontinued model, so no vendor patch has been identified.
Authentication bypass in wolfSSL TLS clients built with Raw Public Key (RPK) support allows a malicious or on-path server to force acceptance of an unsolicited server_cert_type=RawPublicKey extension during a TLS 1.2, TLS 1.3, or DTLS 1.2 handshake, causing the client to treat RPK as the negotiated credential form and skip normal certificate-chain verification. Only builds compiled with HAVE_RPK (--enable-rpk, --enable-all, or --enable-distro) are exposed; default builds are unaffected, and exploitation additionally requires the victim to act as the client connecting to the attacker-controlled server (or an on-path injector) with no user interaction, as reflected by PR:N in the vector. There is no public exploit identified at time of analysis and no CISA KEV listing, though the raw CVSS 4.0 base score of 8.3 contrasts sharply with the non-default, compile-time-gated reachability captured in the independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), so the practical risk is concentrated in RPK-enabled deployments.
wolfSSL builds that enable the WOLFSSL_TRUST_PEER_CERT macro can be induced to accept a forged clone of a trusted-peer CA, letting a malicious (D)TLS server bypass peer authentication; when OPENSSL_COMPATIBLE_DEFAULTS is also defined the flaw spreads to all CA certificate loading. The vulnerable path is reached through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(), APIs used by autoconf/distro builds of nginx, haproxy, stunnel, wpa_supplicant, apache httpd, hitch, bind, rsyslog and ffmpeg, and exploitation is unauthenticated over the network (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). The practical barrier is that the attacker must already know which certificates the victim loaded before a matching clone can be forged (assessment- and vendor-cited AT:P), so this is a targeted authentication bypass rather than a mass-exploitable one; patches exist upstream but no public exploit code has been identified at time of analysis.
Certificate forgery in the wolfSSL client (versions 5.7.2 through 5.9.2) lets a remote attacker who already holds any certificate and matching private key that chains to a CA the client trusts mint certificates for arbitrary identities that the affected client accepts as valid, enabling full TLS man-in-the-middle of connections that client initiates. The defect is reachable only in a non-default configuration: a client build with HAVE_CERTIFICATE_STATUS_REQUEST_V2 that explicitly enables RFC 6961 multiple OCSP stapling via wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options); in addition, the attacker-supplied end-entity certificate can be written into the persistent trust store held by the shared WOLFSSL_CTX, so later connections that reuse that context stay affected even when multi-stapling is no longer in use. No public exploit identified at time of analysis; the vendor-reported CVSS 4.0 base of 8.3 and an independent assessment of CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N both treat this as a genuine certificate-validation failure (CWE-295) rather than a merely information-disclosing bug, with the 'attacker must already hold a certificate chaining to a trusted CA' prerequisite as the main limiting factor. Upstream fix is available as PR #11027; a released patched version is not independently confirmed in the available data.
Incorrect authorization in the Sylius Shop API lets anyone holding an order token submit arbitrary payment actions - most notably refunds - against their own completed orders through POST /api/v2/shop/orders/{tokenValue}/payment-requests. Affected releases are Sylius versions before 2.1.16 and before 2.2.9; the endpoint accepted any caller-supplied action value with order ownership as the only check, so where a payment gateway wires a refund-class action into its action-indexed command provider the gateway executes the refund while Sylius still records the order as paid, producing direct financial loss. The vulnerability is remote and unauthenticated per the assessed CVSS vector (PR:N) because the order token is held by any customer for their own purchase, but exploitation is gated by that specific gateway configuration (AC:H / AT:P), and no public exploit has been identified at the time of analysis.
Stored code injection in the Ad Inserter WordPress plugin before 2.8.19 allows an authenticated user with a role as low as subscriber to save content that the plugin then executes as PHP or serves unescaped to site visitors, because one of the plugin's settings pages is not access-restricted and the data written there is not filtered. Exploitation is conditional rather than trivial: the threat actor needs a low-privileged account (easy on sites with open registration) and the site must be running a configuration in which the plugin's own settings make that page reachable by every logged-in user, which is why the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H with total technical impact. Publicly available exploit code exists, but the EPSS score is only 0.15% (4th percentile), there is no CISA KEV listing, and independent review characterises this as a real-but-conditional priority rather than an emergency.
Malcure Malware Shield (Removal, Repair, Monitor) before 19.9.7 fails to enforce an authorization check on an AJAX action, allowing an authenticated subsite administrator on a WordPress multisite network to write and delete arbitrary files in the network's shared filesystem, which can lead to remote code execution. The vulnerability requires a multisite installation and an existing privileged account (CVSS PR:H); it is not exploitable on single-site installs or by unauthenticated users, and SSVC records Automatable:no. Publicly available exploit code exists, but no active exploitation is confirmed (CISA KEV absent; SSVC Exploitation:none), and EPSS is low at 0.18% (7th percentile).
Command execution as the Liquidsoap process user is possible in AzuraCast through 0.23.x when an authenticated station user with Streamers and Profile permissions sets a streamer username containing shell metacharacters and a live recording session closes. The flaw (CWE-78, CVSS 8.7) requires the live-recording feature to be active and the malicious username to be passed unquoted into process.run during Liquidsoap config generation; there is no public exploit identified at time of analysis, and exploitation is limited to insiders or attackers who already hold streamer-level credentials on a station where recording is enabled.
OS command injection in Fleet's generator for Fleet-maintained macOS app install and uninstall scripts allows crafted Homebrew cask metadata containing shell metacharacters such as $(...) to be carried unescaped into scripts that run as root on managed macOS hosts. Manifests generated before 2026-08-19 are affected; the flaw is a supply-chain vector because the attacker needs no Fleet credentials, only the ability to land crafted metadata in an upstream Homebrew cask that must then survive both upstream Homebrew cask review and Fleet's review of the automated ingestion pull request before a managed host installs or uninstalls the app. The vendor CVSS 4.0 base is 8.9, but the vendor's own vector is PR:H while CERT's independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, and the two independent review gates plus central, pre-built manifest distribution on 2026-08-19 sharply limit real-world exploitability; no public exploit code has been identified and there is no confirmed active exploitation (not in CISA KEV), so exploitation is assessed as difficult rather than imminent.
Denial of service in vm2 sandboxes before 3.12.2 allows an untrusted script running via VM.run to terminate the host Node.js process. The BaseHandler construct trap returns Reflect.construct's result without calling markHostPromiseHandled() the way the adjacent apply trap does, so if an embedder exposes a constructable host function whose constructor returns a resident rejected Promise, invoking it with `new` and discarding the result lets the rejection cross the sandbox bridge unhandled; under Node's default strict unhandled-rejection policy this is promoted to a process-terminating uncaught exception. The bug is unauthenticated in the sense that the attacker only needs to submit script code (PR:N/UI:N), but exploitation is conditional: it requires a specific embedder integration exposing such a constructable Promise-returning host constructor, which is the AT:P precondition and is not vm2 default behavior; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Deserialization of untrusted data in MONAI's auto3dseg utility (monai/auto3dseg/utils.py) allows arbitrary code execution when algo_from_pickle() is called on an attacker-supplied .pkl file: the function reads the raw file bytes and hands them to pickle.loads() without any source or content validation, so any object defining __reduce__ runs in the victim application's context. Exploitation is conditional rather than remote-against-a-service: an attacker must first deliver a malicious pickle (model exchange, shared storage, or a pipeline input) and the victim's code must invoke this specific function, and per the authoritative assessment the vector is local with user interaction required (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) rather than unauthenticated network exploitation. A working proof-of-concept is documented in the upstream GitHub advisory GHSA-89gg-p5r5-q6r4 (publicly available exploit code exists), but there is no confirmed active exploitation (CISA KEV).
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow expressions to execute arbitrary Python and run operating-system commands as the backend process. The flaw lives in the expression engine's DotList map/filter item expressions and its fallback resolver, which fail to block dunder attribute traversal, letting an attacker chain attributes to reach functions such as os.system. Exploitation requires a valid account with workflow-authoring rights (PR:L) but no user interaction, making this a network-reachable, low-complexity compromise of confidentiality, integrity, and availability; no public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation.
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a workflow branch or condition node - or a victim who imports a workflow template containing a malicious condition node - run arbitrary Python as the backend process user whenever the workflow executes. The same release bundles four further flaws: fail-open Slack and Telegram webhook verification that allows unauthenticated workflow triggering with the owner's credentials when a trigger node has no credentialId or an empty signing secret, an OAuth redirect_uri scheme-validation gap that permits javascript:/data: URIs and script execution in the Heym origin, and plaintext storage of WorkflowExecutionToken, PortalSession, HITLRequest.public_token and OAuthAuthorizationCode values. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the 0.0.x pre-release product has a very small deployment base.
Code injection in AzuraCast through 0.23.5 lets an authenticated user holding the RemoteRelays station permission inject nested Liquidsoap interpolation syntax (for example #{#{EXPR}}) into the remote relay password field, achieving arbitrary code execution inside the Liquidsoap process, disclosing internal API keys, or disrupting station operation. The root cause is an incomplete migration in ConfigWriter.php from the vulnerable cleanUpString() sanitizer to the safe toRawString() helper; a prior commit (ff49ef4) migrated host, username, mount, name, description, genre, and URL fields but left the password field behind. No public exploit identified at time of analysis, and exploitation is gated by the RemoteRelays privilege (PR:L) and by the station's Liquidsoap configuration being regenerated and loaded.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Unauthenticated DQL injection in AzuraCast before 0.23.8 allows remote attackers to extract sensitive database information, including user credentials and station settings, via the sortOrder parameter in the search/list API. No authentication or user interaction is required (CVSS 4.0 PR:N/UI:N), though exploitation requires network reachability to the AzuraCast web interface. No public exploit identified at time of analysis, but the flaw is trivially exploitable and affects many internet-facing radio panel deployments.
OS command injection in MONAI's nnUNetV2Runner (monai.apps.nnunet.nnunetv2_runner) allows arbitrary command execution with the privileges of the user running an nnU-Net training or validation job, because values such as dataset_name_or_id from a YAML config - or from CLI/kwargs arguments - are concatenated into a command string and passed to subprocess with shell=True without quoting or validation. All MONAI releases before 1.6.0 are affected; exploitation is not network-facing and requires the victim to load an attacker-supplied configuration file and then launch a job such as train_single_model(), so the real-world risk is config-trust dependent rather than remotely triggerable. Publicly available exploit code exists (a Windows-verified proof of concept is included in the GHSA advisory), no authentication is required in the assessed vector (PR:N), and no confirmed active exploitation (CISA KEV) has been reported at time of analysis. Vendor-released patch: MONAI 1.6.0.
Authenticated code injection in AzuraCast 0.23.3 and earlier lets a user holding StationPermissions::Media or StationPermissions::Profile plant Liquidsoap interpolation sequences (#{...}) into playlist remote URLs or station metadata fields, which the ConfigWriter::cleanUpString() helper writes unsanitized into the generated .liq configuration. When the affected station's Liquidsoap backend is next restarted and re-parses that config, the embedded #{process.run(...)} expression is evaluated and executes arbitrary shell commands as the azuracast service user. Exploitation is not confirmed in the wild (no CISA KEV listing), but the vendor advisory publishes proof-of-concept payloads for both the Media-permission and Profile-permission paths; the trigger is delayed and interaction-dependent, requiring a station restart after the malicious value is saved.
Container image substitution in Edgeless Contrast 1.14.0 through 1.23.0 lets an attacker who can reach the Kata agent API - in Contrast's threat model, a Kubernetes cluster administrator - swap a workload's container image for an exploit payload and thereby break the integrity guarantees of the confidential container. The root cause is a runtime-policy generation bug: a misplaced allow_storage rule introduced by a bad rebase during a Kata Containers update accepts storage entries using the image_guest_pull driver without verifying the image digest. No public exploit code has been identified at time of analysis and EPSS is low at 0.23% (12th percentile), but exploitation is authenticated (CVSS PR:L), non-automatable per SSVC, and gated on the substituted image still satisfying all remaining policy rules; technical impact is rated total.
Arbitrary writes to the guest root filesystem in Edgeless Systems' Contrast confidential-computing runtime before 1.19.1 allow a malicious process on the untrusted Kubernetes host to achieve full guest takeover. The flaw lives in the Kata agent policies generated by the Contrast CLI: the CopyFile verification does not correctly resolve symlinks (CWE-59), so an attacker who can open a VSOCK connection to the Kata agent can chain CopyFile requests to overwrite security-critical files inside the guest or trick the workload into disclosing sensitive data. The vendor (via VulnCheck) scores this CVSS 4.0 8.6 (High), and an independent assessment concurs that it is a genuine confidentiality-and-integrity break (CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) rather than a high-score paper cut. Exploitation is not reachable over a standard network - the attacker must already hold a foothold on the untrusted host, which is precisely the adversary model Contrast assumes - and no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
MONAI through 1.6.0 will execute arbitrary code in the victim's process when it loads an attacker-supplied bundle, because the bundle configuration engine resolves '_target_' values to any importable callable without an allow list and passes '$' expressions straight to Python's eval(). An attacker who publishes or shares a crafted bundle achieves code execution as soon as an operator calls monai.bundle.load() or monai.bundle.run() on it; no credentials are required against the victim (PR:N), but the attack does depend on user interaction (UI:R) since the operator must obtain and load an untrusted bundle, and the payload runs with the privileges of the loading process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; the primary exposure is to environments that pull third-party or community-contributed MONAI bundles rather than first-party trusted ones.
Workload secrets are written to the initializer's standard output at INFO level in Edgeless Systems Contrast versions 1.9.0 through 1.12.1, so any Kubernetes principal that holds get or list permission on the pods/logs subresource in the affected namespace can read them from the container log stream. Because those workload secrets back Contrast's encrypted storage and HashiCorp Vault integration, the storage keys and Vault credentials derived from them must also be treated as compromised, giving the attacker a path to decrypt protected data and reach Vault-backed secrets. The flaw is a regression of GHSA-h5f8-crrq-4pw8 (originally fixed in 1.8.1 but never ported to the main branch), patchable in 1.12.2; there is no public exploit identified at time of analysis and no KEV listing, so risk is driven by the low barrier of an existing log-read RBAC grant rather than by active exploitation.
Workload secrets managed by Edgeless Systems' Contrast confidential-computing platform are written to Kubernetes pod logs, letting anyone with log-read access recover secrets that are meant to be visible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner. All Contrast releases up to and including 1.8.0 are affected whenever the Contrast initializer runs at the default CONTRAST_LOG_LEVEL of info (the same leak also occurs at debug), so installations that never customized the initializer log level are exposed by default; deployments that do not use workload secrets at all are unaffected. Recovering the leaked value requires low-privileged access - Kubernetes get or list permission on pods/logs (PR:L in the assessed vector) or read access to the underlying Kubernetes log storage - this is a passive confidentiality disclosure with no code execution, and no public exploit has been identified at time of analysis.
Deserialization of attacker-controlled pickle data in MONAI's Auto3DSeg module (monai/auto3dseg/utils.py) lets code run inside any process that calls algo_from_pickle() on a file the attacker can supply or substitute, with full read/write/execute impact on that process and its data. Versions before 1.6.0 are affected (pip package monai < 1.6.0, CPE cpe:2.3:a:project-monai:monai); the vulnerable pickle.loads() at line 321 fires before any isinstance or key checks, so no special configuration flag is needed to reach the sink. The exposure is conditional rather than remote: the vector is local (AV:L) with passive user interaction (UI:P) - a victim, typically a medical-imaging or ML pipeline exchanging algorithm bundles or model checkpoints, must load the crafted .pkl file, and no authentication is required on the loading side (PR:N) - scored 8.5. There is no evidence of confirmed active exploitation (no CISA KEV entry), but publicly available exploit code exists: the upstream advisory ships a working proof-of-concept, and users who upgraded to v1.5.2 believing GHSA-89gg-p5r5-q6r4 fixed this remain fully vulnerable because that earlier patch was never actually implemented in the code.
Arbitrary code execution in MONAI versions prior to 1.6.0 occurs when a crafted .npy or .npz file is loaded through the NumpyReader class, which hardcodes numpy.load with allow_pickle=True. An unauthenticated attacker who can place a malicious file on a path the victim opens can trigger pickle deserialization, leading to full compromise of confidentiality, integrity, and availability. Exploitation requires user interaction (the victim must load the file) and the attack vector is local; no public exploit code has been identified at time of analysis.
Local code execution in MONAI 1.6.0 and all released versions allows an authenticated low-privileged local attacker to run arbitrary code as another user by writing a malicious pickle file to a shared or world-writable MONAI cache directory (e.g., /tmp/monai_cache, HPC scratch, ~/.cache/monai). The victim must subsequently run a PersistentDataset pipeline that caches MetaTensors (the default in MONAI >= 1.0), which forces torch.load(weights_only=False) and pickle.loads on the poisoned file. No vendor-released patch identified at time of analysis; no public exploit identified at time of analysis.
python-utcp versions before 1.1.4 allow server-side request forgery through the utcp-http plugin's HttpCommunicationProtocol.call_tool, which validates the initial tool URL but follows HTTP redirects with no per-hop re-validation, so an attacker-controlled tool endpoint can return a 3xx Location that drives the UTCP client into internal HTTP services or the cloud metadata endpoint (169.254.169.254) and returns the response body to the tool caller. The vulnerable path is the core UTCP pattern of registering a tool or manual/OpenAPI spec from a runtime-supplied URL and then invoking it; the initial URL only needs to pass ensure_secure_url (any https:// or a benign attacker-owned host), with the attacker supplying the redirect. Exploitation is remote and requires no privileges (CVSS 4.0 PR:N, assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), but it is gated on the host ingesting and invoking an attacker-influenced tool spec and on an internal HTTP service being reachable from the client, which keeps practical priority moderate rather than critical; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 1.1.4.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
Cookie scoping bypass in the http4k client-side cookie jar (Maven org.http4k:http4k-core) causes cookies stored by BasicCookieStorage to be replayed to origins and schemes they were never scoped to, potentially exposing session cookies or other sensitive values. Only applications that reuse a single storage instance across more than one origin or scheme are affected; per-origin instances are explicitly unaffected, and no public exploit identified at time of analysis. The vendor rates this 8.3 (CVSS 4.0) while an independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, reflecting a conditional client-side confidentiality flaw that additionally requires an attacker-controlled or attacker-observable second destination before leaked cookies can be captured, making it moderate rather than high-urgency. Fixes ship in 6.48.0.0, 5.42.0.0, and 4.51.0.0; authentication is not required to trigger the flawed behavior (CVSS PR:N), but exploitation depends on the developer's multi-origin storage configuration rather than on attacker-supplied input reaching a server.
Environment-variable secrets such as NPM_TOKEN or GITHUB_TOKEN can be exfiltrated from a developer's machine by pnpm 11.0.0 through 11.10.x and 10.7.0 through 10.34.4, which expand ${VAR} placeholders in the httpProxy, httpsProxy and noProxy settings read from a repository-controlled pnpm-workspace.yaml. An attacker who controls only that manifest - a public repo, a fork, or a supply-chain pull request - can cause a victim who merely clones the repository and runs a command such as pnpm install to expand secrets into an attacker-controlled proxy hostname or userinfo, routing install traffic and the associated DNS lookups through the attacker's host; exfiltration occurs during configuration loading, before any lifecycle script runs. No authentication or pre-existing access to the victim's store, global config, lockfile, node_modules, or environment is required (CVSS PR:N), but the attack depends on user interaction because the victim must voluntarily clone the repository and invoke pnpm in a secret-bearing environment; publicly available proof-of-concept code exists, and no confirmed active exploitation (CISA KEV) has been reported.
Server-side request forgery in Obot through v0.22.1 allows an authenticated user holding the Power User, Power User Plus, or Admin role to register a remote MCP server pointing at an arbitrary URL, which Obot then fetches server-side with no destination validation. Because the fetched response is reflected back in Obot's error messages, this is a non-blind SSRF: the attacker can read responses from internal services and, against the cloud metadata endpoint 169.254.169.254, potentially obtain the host's cloud IAM credentials and pivot into the cloud account. Exploitation is role-gated and requires authentication to be enabled with privileged users permitted to register remote MCP servers; there is no public exploit identified at time of analysis, and the issue is fixed in v0.23.0.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Replay of captured Digest authentication credentials is possible in the http4k http4k-security-digest module (org.http4k:http4k-security-digest) because ServerFilters.DigestAuth and the underlying DigestAuthProvider default their nonceVerifier parameter to { true }, accepting every nonce regardless of value, age, or prior use. Any application that uses these components with the default configuration and exposes a protected resource has no replay protection: an attacker who obtains a valid 'Authorization: Digest' header - for example through network observation or reading logs that record the header - can replay that response indefinitely against the same resource, yielding credential-equivalent access and information disclosure rather than modification of data. The weakness has been present since DigestAuthProvider was introduced in 2021; the CVSS 4.0 score is 8.2 (8.2 with AT:P reflecting the capture prerequisite), and the independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, treating it as a real but conditionally gated authentication weakness rather than a mass-exploitable critical. There is no public exploit identified at time of analysis, and vendor-released patches exist in 6.48.0.0, 5.42.0.0, and 4.51.0.0.
Unauthenticated media exposure in AzuraCast before 0.23.8 allows remote attackers to download audio files that station operators intended to keep private, because the public On-Demand download endpoint does not verify playlist-level access controls before serving a requested media item (CWE-862 Missing Authorization). Any deployment that exposes the On-Demand endpoint and relies on playlist membership to restrict content is affected, and no authentication or user interaction is required once an attacker has a valid media identifier for the target station. The impact is confidentiality-only with no write or availability effect; exploitation is not confirmed as actively exploited and no public exploit code identified at time of analysis, so despite the vendor's 8.2 score this is a genuine but moderate-severity access-control flaw.
Non-blind server-side request forgery in heym (heymrun) before 0.0.109 lets any registered user redirect backend HTTP requests to loopback, private, link-local, or cloud-metadata addresses and read the full response body in the workflow node output. The flaw is confined to the Slack, Discord, and Crawler workflow nodes, which build requests from user-supplied credential URLs (webhook_url / flaresolverr_url) with an unguarded HTTP client that bypasses the SSRF egress guard already enforced on the HTTP, WebSocket, and MCP nodes. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation requires only a valid account (PR:L) on an affected instance and no user interaction; the fixed release is 0.0.109.
Parse Server deployments running versions 9.0.0 through 9.10.1-alpha.9 or 8.0.2 through 8.6.90 that enable code-based social login adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo) fail to re-verify provider credentials when authentication data is submitted alongside a username and password on the login endpoint. An authenticated attacker holding a low-privileged account can therefore attach an arbitrary, unverified external provider identity to their own account - or pre-claim the provider ID of a victim who has not yet linked that provider, so the victim's later legitimate provider sign-in lands on the attacker's account. Exploitation is conditional: it requires a non-default adapter to be configured and a valid authenticated session, and the pre-hijack variant additionally requires the targeted victim to complete a legitimate provider login. No public exploit code or confirmed active exploitation was identified at time of analysis, and the assessed risk is a genuine but conditional authentication flaw rather than a mass-exploitation threat.
Command injection in navi through 2.24.0 allows an attacker who controls cheatsheet variable values - or file names inside a suggestion command directory - to have unescaped shell metacharacters substituted into commands that navi executes with the victim's privileges. Exploitation is local and condition-dependent: the crafted content must reach the victim (for example through a shared or poisoned cheatsheet repository) and the victim must interactively invoke the affected cheatsheet, after which arbitrary commands run at the user's own privilege level. No public exploit code was identified at time of analysis, and the flaw is not listed in CISA KEV, but the CVSS 4.0 score of 7.3 reflects high confidentiality, integrity, and availability impact on the victim's account once the conditions are met.
MONAI through 1.6.0 lets a user who can supply or tamper with a bundle's metadata achieve code execution by abusing an eval()-based sandbox in _get_fake_spatial_shape() (monai/bundle/scripts.py). The vulnerable function screens shape expressions with a helper that walks the AST and only rejects ast.Name nodes outside the 'p'/'n' allowlist, so payloads assembled purely from constants and attribute, subscript, or call nodes - such as "(1).__class__.__bases__[0].__subclasses__()" - pass validation and then reach eval(), enabling object-introspection chains that escape to arbitrary code execution. The path is reachable through the non-default bundle 'verify_net_in_out' CLI verification flow (_get_real_input_data / verify_net_in_out), so exploitation is limited to authenticated local users (CVSS:3.1/AV:L/AC:H/PR:L/UI:N, CVA:H) who run that verification on an untrusted or modified bundle; default MONAI workflows that never verify untrusted bundles are not exposed, and no public exploit code was identified at time of analysis.
Authenticated users with only View Station Page permission on AzuraCast before 0.23.8 can retrieve plaintext Icecast/Shoutcast admin, source, and relay passwords from the GET /api/station/{id}/vue/profile endpoint. The exposed admin credentials permit logging into the Icecast admin interface without holding Broadcasting permission, escalating the attacker's effective access within the streaming infrastructure. This broken access control issue (CWE-200) is rated moderate severity and is realistically exploitable only in multi-user or multi-tenant deployments where untrusted or semi-trusted parties hold low-privilege View-only accounts; no public exploit identified at time of analysis.
Path traversal in the Rust-based pacquet package-manager component shipped inside pnpm allows a crafted lockfile to create symlinks and directories outside the project or node_modules boundary during installation. Only pnpm npm-package versions 12.0.0-alpha.0 through 12.0.0-alpha.4 that bundle pacquet are affected, and exploitation requires the victim to explicitly run an install with --trust-lockfile or a frozen lockfile against an attacker-supplied lockfile, so the trust flag that bypasses re-resolution is the enabling condition rather than a remotely reachable flaw. Impact is integrity-focused (CVSS 7.1, CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L), and no public exploit code was identified at time of analysis.