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.
Authenticated users who hold a specifically delegated booking-management capability in the Online Scheduling and Appointment Booking System WordPress plugin (versions 23.2 through 28.3) can chain an unsafe PHP deserialization flaw with a broken access control check on a privileged maintenance routine to inject arbitrary PHP objects, overwrite privileged site options, and read stored integration secrets. The plugin does not restrict that maintenance feature to administrators and does not prevent deserialization of untrusted input, so any account granted this custom capability - which an administrator must explicitly assign, a non-default delegated privilege - can reach the vulnerable path; no end-user interaction is required (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L, score 4.7). Publicly available exploit code exists, but there is no confirmed active exploitation (the issue is not in CISA KEV) and EPSS is only 0.15% (4th percentile), so signals converge on a genuine-but-low real-world priority.
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.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 lets an authenticated user holding contributor-level access or higher supply an arbitrary URL through the plugin's feed-fetch feature, causing the web server to request that URL and return the response body back to the requester; the plugin performs no capability check on that action. Because the request originates from the server, the attacker can reach internal-only or loopback services that are otherwise unreachable from the internet - most notably cloud instance metadata endpoints and internal administrative interfaces - but the impact is limited to confidentiality, since no code execution or write capability is demonstrated. Publicly available exploit code exists (the WPScan entry documents the issue), CISA KEV does not list the CVE, and EPSS is 0.13% (2nd percentile), indicating low near-term exploitation likelihood; the assessed severity is low-to-moderate, contingent on the site allowing low-trust contributor registrations and on which internal services are reachable from the web server.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before version 2.8.27 allows an authenticated attacker holding contributor-level access or higher to direct the web server to fetch an arbitrary attacker-supplied feed URL and read the response back, enabling internal-only reconnaissance and retrieval of sensitive data such as cloud instance metadata. The plugin performs neither a capability check nor any validation of the destination before issuing the server-side request, and because the retrieval is non-blind the attacker receives the fetched content rather than learning only success or failure. Exploitation is constrained by the contributor-role prerequisite and by read-only impact (no write, no code execution), and public exploit code exists via the WPScan disclosure while EPSS remains very low at 0.13% (2nd percentile) and CISA's SSVC assessment records exploitation as none; this is a genuine but low-priority issue.
Authenticated staff-level users of the WordPress plugin Online Scheduling and Appointment Booking System (all versions before 28.3) can read, modify, and delete appointment and payment records belonging to other staff members, including the customer personal information attached to those records. The flaw is a missing ownership check on the plugin's staff-role AJAX actions: an attacker only needs a valid staff account and a record identifier belonging to someone else, with no user interaction and remote reachability. Exploitation requires an existing staff-level login and is therefore not reachable by unauthenticated visitors or ordinary subscribers; publicly available exploit code exists via the WPScan disclosure, but there is no confirmed active exploitation (CISA KEV not listed), EPSS is only 0.13% (2nd percentile), and SSVC rates exploitation as none and automatable as no, making this a genuine but low-priority issue.
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.
Credential exfiltration in Heym before version 0.0.106 allows an authenticated collaborator who has been granted shared access to a credential to cause the server to transmit the credential owner's decrypted secret to an attacker-controlled endpoint. The flaw lives in the POST /api/credentials/test endpoint, where the destination URL supplied in the config parameter is not validated, so a low-privileged collaborator can redirect a credential-verification request (CWE-918 server-side request forgery) and harvest plaintext secrets they were never entitled to read. The vendor CVSS 4.0 assessment (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) confirms high confidentiality impact with no integrity or availability effect, and no public exploit code or confirmed in-the-wild exploitation has been identified at time of analysis; risk is concentrated in multi-user, self-hosted deployments that rely on collaborator sharing, while single-user instances are not meaningfully exposed.
Server-side request forgery in AzuraCast before 0.23.8 allows an authenticated user with the station-scoped WebHooks permission to make the server send outbound HTTP POST requests to internal, loopback, or RFC1918 addresses through the Generic and Discord webhook connectors. The AbstractConnector::getValidUrl() validation only rejects literal link-local IPs and skips validation entirely when the hostname is not a literal IP, and the same user can trigger the request on demand via the webhook test endpoint. No public exploit identified at time of analysis; risk is moderate because exploitation requires a low-privileged account and impact is largely a blind Now Playing POST unless the target internal service is reachable and responsive.
Missing authorization on AzuraCast's GET /api/station/{station_id}/file/{id}/play endpoint lets any authenticated user - including one whose API key or session is scoped to a single station - download the complete media library of every other station on a multi-tenant installation running 0.23.5 or earlier. Because the endpoint accepts sequential auto-increment media IDs, an attacker can trivially enumerate and exfiltrate files from stations they have no permissions on, with no user interaction and impact limited to confidentiality (vendor CVSS 4.0 base 7.1; assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). The vendor advisory (GHSA-qff7-q5fm-8p76) ships step-by-step proof-of-concept reproduction instructions; there is no indication of confirmed active exploitation (CISA KEV) at time of analysis.
Credential exfiltration and server-side request forgery in utcp-http 1.1.3 and earlier allow an attacker who supplies a malicious OpenAPI specification to redirect a victim's OAuth2 client_id and client_secret to an arbitrary token endpoint. The library validates discovery and tool-invocation URLs via ensure_secure_url() but never applies the same guard to the OAuth2 tokenUrl taken from a remote spec, so the attacker-chosen endpoint receives the credentials in cleartext when a generated OAuth2-protected tool is invoked. Exploitation requires victim interaction (the victim must register the attacker-controlled spec and call the generated tool) and no attacker authentication; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N (7.1), with the unvalidated endpoint also usable for SSRF against internal HTTP ranges. No public exploit identified at time of analysis.
Server-side request forgery in AzuraCast (Composer package azuracast/azuracast, versions before 0.23.8 per the advisory) lets an authenticated user who holds the station-scoped RemoteRelays permission set a station's Remote Relay URL to loopback, private-network, or cloud-metadata addresses such as http://127.0.0.1:<port>/ or http://169.254.169.254/latest/meta-data/. Because the URL is validated only for syntax and an http/https scheme, the platform's periodic background Now Playing sync (AbstractRemote::getNowPlayingAsync) then automatically and repeatedly fetches that attacker-chosen address on the server's behalf, yielding blind SSRF against internal services and - on cloud-hosted instances with a reachable metadata endpoint - potentially exposing instance credentials or configuration. This is not an unauthenticated internet-facing flaw: exploitation requires an authenticated account with the RemoteRelays permission (PR:L in both the vendor's CVSS 4.0 vector and our CVSS 3.1 assessment), there is no public exploit code identified at time of analysis, and no patched release was confirmed at the time of the advisory.
Server-side request forgery in python-utcp (utcp-http) before 1.1.12 allows an unauthenticated remote attacker to cause a victim's client to issue requests to loopback services and return response bodies if the victim registers a malicious UTCP manual served from a non-loopback origin. Exploitation requires user interaction (registering the manual) and is limited to loopback interfaces, with further prerequisites of a loopback service that answers unauthenticated requests with useful data. No public exploit code exists, and the issue is fixed in utcp-http 1.1.12; this is a conditional-severity issue rather than a mass-exploitation threat.
Coordinator impersonation in Edgeless Systems Contrast (a confidential-computing runtime for Kubernetes) before version 1.4.1 lets an attacker who can redirect traffic to a rogue Coordinator recover arbitrary secrets of workloads deployed after the attack. The recovering Coordinator fails to verify the seed supplied by the recovering party, so a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled can issue certificates chaining to its own root CA, impersonating a workload owner when the `contrast` CLI `set` call does not compare the returned root CA certificate against the existing one (the CLI's default behavior) or when `verify` is run without comparing against a trusted reference. Exploitation is unauthenticated but conditional - it requires a network-position/man-in-the-middle prerequisite plus a victim workload-owner action - so this is a genuine but conditional integrity and confidentiality flaw rather than a widespread emergency; no public exploit is identified at time of analysis and the issue is not in CISA KEV.
Authenticated privilege escalation in Nezha Dashboard before 2.3.5 lets any account holding the nezha:service:write scope escalate into privileged Agent operations by creating or updating a service monitor whose Task.Type is set to a command or configuration task value, since the service API never validated that the submitted type belonged to the supported probe set. Because service monitors and privileged operations share the same protobuf Task.Type integer namespace, the crafted task is accepted and dispatched to Agents within the attacker's existing authorization scope, resulting in command execution or Agent reconfiguration (CWE-269). The independent assessment rates this as a genuine but authentication-gated privilege-escalation issue whose urgency is moderate and whose blast radius scales with how broadly service:write is delegated; the vendor has released a fix in 2.3.5 (commit 38824dbc11a63964c5b9296ae4c68e62b34fa04b) and no public exploit has been identified at time of analysis.
Denial of service in the Nezha monitoring dashboard before 2.3.8 lets any authenticated non-administrator account crash the dashboard process by submitting a malformed alert rule (invalid rule type or out-of-bounds duration) to POST /api/v1/alert-rule, which triggers an unrecovered panic in the alert evaluator goroutine. Because the offending rule is persisted, the dashboard enters a crash loop on every restart, taking down monitoring and the control plane until the bad record is manually removed from the backing datastore. No public exploit code was identified at time of analysis, exploitation requires only a low-privileged account (CVSS PR:L) and network reachability to the dashboard API, and impact is confined to availability with no confidentiality or integrity loss.
Authenticated directory deletion in the Event Gallery extension for Joomla (svenbluege.de) below version 6.5.0 allows a high-privileged Joomla backend user to supply a traversal payload in the `images` parameter of the `cache.process` clear-cache task and recursively delete any directory the web server account is permitted to write to. The impact is confined to integrity and availability of web-server-writable paths - there is no confidentiality loss (VC:N/SC:N) and no privilege gain beyond the actor's existing administrator-level access, which is the main limiting factor (PR:H), giving a CVSS 4.0 base score of 7.0. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the root cause is a CWE-22 path traversal that accepts unsanitised relative paths before file deletion.
Information disclosure and cross-boundary host memory corruption in vm2 before 3.12.2 let untrusted guest JavaScript read and modify bytes outside the sandbox whenever the embedding application explicitly allowlists Node's zlib builtin via require: { builtin: ['zlib'] }. vm2 fails to apply its Buffer backing-store ownership invariant (byteOffset === 0 && buffer.byteLength === length) to Buffers returned from host builtin modules, so zlib.deflateSync can hand back a pooled buffer whose .buffer getter exposes Node's entire 64 KiB shared small-buffer pool; a guest then builds a full-width view with Buffer.from(result.buffer, 0, result.buffer.byteLength) to disclose secrets (session tokens, decrypted material, DB rows) and corrupt unrelated host buffers sharing that pool. This is not reachable in a default vm2 deployment - it requires a non-default zlib allowlist, attacker-controlled script execution, and host secrets co-resident in the pool at exploitation time - and no public exploit code was identified at time of analysis; the vendor rates it CVSS 4.0 6.9 (Medium) with a vendor-released patch in 3.12.2.
Unauthenticated download of in-house iOS application packages and manifests is possible against enterprise-tier Fleet deployments running versions before 4.87.0, because two sessionless MDM endpoints were shipped without the intended random, time-limited URL token, letting anyone with network reach to the Fleet server fetch IPA binaries and their metadata (bundle identifier, version, name) by guessing sequential title identifiers. Impact is confined to read-only information disclosure - there is no privilege escalation or write access, the free tier is unaffected (it returns fleet.ErrMissingLicense), and hosts not managed by Fleet are untouched. The vendor CVSS 4.0 score is 6.9 (MEDIUM) while our independently assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N; no public exploit code or confirmed active exploitation was identified at time of analysis.
Revoked, expired, or download-limit-exhausted Cloudreve shares can still be mined for signed file URLs for up to 300 seconds because the file/url and file/thumb routes trust a client-supplied context_hint UUID and restore cached share navigator state without re-running the share validity or password checks (CWE-863, incorrectly cached authorization). All Cloudreve releases before 4.16.1 are affected; the independent assessment rates this moderate (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N), with remote attackers (CVSS PR:N) needing prior valid access to the share, knowledge of the target file URI from an earlier listing, and a pre-warmed hint, so this is a revocation/expiry bypass for already-known content rather than a way to discover unknown share contents. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and a vendor patch is available.
Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all versions prior to 0.0.91 and allows anyone with read access to a workflow, share/team membership, or read access to the database, a backup, or logs to recover and replay those secrets to execute workflows or act as the secret owner. Exposed values include webhook header-auth credentials returned in cleartext by GET /api/workflows/{id} and persisted into execution history, MCP API keys stored as a plaintext column and accepted via a ?key= query string that leaks into logs, proxies, and Referer headers, portal session tokens validated by plaintext equality with a 168-hour TTL, workflow execution JWTs re-listed by GET .../execution-tokens, Discord interaction tokens, and global variables. The vendor CVSS 4.0 score is 6.9 (medium) with a high-privilege prerequisite (PR:H), our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, exploitation is bounded by the need for prior authorized read access rather than a special configuration, a vendor patch is available in 0.0.91, and no public exploit was identified at time of analysis.
Cross-site request forgery in the Event Gallery extension for Joomla (svenbluege.de) affects versions below 6.5.0 and lets an attacker craft a malicious web page that silently performs shopping-cart actions on behalf of a logged-in site user, because those cart endpoints do not validate an anti-CSRF token. Exploitation requires the victim to be authenticated to a Joomla site running the vulnerable extension and to visit attacker-controlled content while that session is active; impact is limited to integrity (manipulation of cart state) with no confidentiality or availability loss, consistent with the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/C:N/I:L/A:N) rather than a worst-case reading of the vendor's 6.9 base score. No public exploit code or active exploitation has been reported, and the vendor has released version 6.5.0 as the fixed release.
Malicious Kubernetes hosts can read confidential data written to Contrast secure persistent volumes by supplying a crafted LUKS2 block device that the pod VM wrongly accepts as encrypted. The flaw affects Contrast (Go module github.com/edgelesssys/contrast) through 1.12.0 when the opt-in secure persistent volume feature is enabled and the guest bundles cryptsetup older than 2.8.1: LUKS2 metadata is unauthenticated and a header declaring the cipher_null-ecb null keyslot algorithm is accepted without error, so the Initializer assumes the device is protected when 'cryptsetup open' succeeds and writes secrets to a volume that is plaintext or keyed with an attacker-known volume key. Exploitation requires host-level provisioning privilege (CVSS 4.0 AV:A/AC:L/PR:L/UI:N, confidentiality-only; independent assessment CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), meaning the adversary is a malicious or compromised infrastructure operator rather than a conventional remote attacker; there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), and the issue is closed by Contrast 1.12.1, which ships cryptsetup 2.8.1, and further hardened by 1.13.0.
Unauthenticated disclosure of MCP Registry metadata affects Obot deployments running versions up to and including v0.22.1 when the operator has enabled registry authentication via OBOT_SERVER_ENABLE_REGISTRY_AUTH=true. A single unauthenticated GET request to /v0.1/servers returns 200 OK and exposes the registry inventory - server names, descriptions, repository URLs, icons, and connect URLs - that the operator explicitly intended to place behind authentication, because the authorizer's default-allow logic never matched the registry's top-level /v0.1 prefix. No public exploit code has been identified at time of analysis, and the independent assessment rates this as a low-impact, high-confidence information-disclosure flaw (CVSS v3.1 5.3) rather than the CVSS v4.0 6.9 figure in the CVE record: the per-user ACR filter still limits anonymous callers to entries visible to the anonymous identity, no secret environment or header values are exposed, and connecting to listed servers remains properly auth-protected.
heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workflow author cause the node to fall back to unauthenticated defaults on the backend's loopback interface. When the credential lookup returns no accessible credential - because the ID does not exist, was deleted, or belongs to another user - the node treats the failure as empty configuration and connects to localhost:6379 with no password, executing the requested Redis operation there. The impact is deployment-gated: the stock docker-compose.yml ships no Redis, so default installs only surface a misleading connection error, while operators who have placed a passwordless Redis on loopback face unauthorized read/write access; no public exploit has been identified at time of analysis and no EPSS or KEV signal is available.
Host-header routing bypass in http4k (Maven artifact org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 lets remote, unauthenticated attackers reach a virtual host they should not be authorized for by supplying a Host header that merely contains a configured vhost name - for example Host: admin.evil.com against a vhost configured as "admin" - because reverseProxy() and reverseProxyRouting() default to a substring (Contains) matcher rather than an exact match. Exploitation is tightly scoped: it requires the functions to be deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, where that routing is what enforces authorization; the documented outbound-dispatch and test-time fake-backend uses set the Host value from the calling application and are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is a genuine but narrow authorization-bypass rather than a high-severity emergency; vendor patches are available in 6.49.0.0 (Community 6.x), 5.42.0.0 and 4.51.0.0 (Enterprise LTS lines).