Docker
Monthly
Delegated 'users:update' permission in Arcane (getarcaneapp/arcane) 2.5.0 and earlier allows an authenticated holder of that permission to overwrite the global administrator's password via PUT /users/{adminId} and then authenticate as the admin, achieving complete administrator account takeover. The UpdateUser handler (backend/api/handlers/users.go:317-323) and the underlying user service (user_service.go:174) set the target user's PasswordHash from the request body and Save unconditionally, with no comparison of caller privilege against target privilege, even though users:update is deliberately intended to sit below the RequireGlobalAdmin-gated role assignment and role CRUD operations. Exploitation is remote, requires no user interaction, and needs no extra configuration beyond the precondition that an administrator has created a custom role (e.g. 'User Manager') containing users:update and assigned it to the attacker's account; deployments that never delegate that permission are not exposed, and no public exploit was identified at time of analysis (CVSS 8.8, PR:L).
Arcane versions prior to 2.5.0 disclose stored container-registry credentials to an attacker-controlled host: an authenticated principal holding both the registries:update and registries:test permissions can repoint an existing generic (non-ECR) registry entry to a URL they control without supplying a replacement token, causing the preserved encrypted PAT or password to be decrypted and sent to that host during RegistryLogin/TestRegistry. The issue is rated CVSS 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) and classified as CWE-200 information exposure, with the scope change and high confidentiality impact reflecting that the leaked credential grants access to, and potential tampering with, the source registry's images. No public exploit code and no confirmed active exploitation were identified at time of analysis, but the flaw is a credible credential-theft primitive for any tenant or operator account that has been granted registry management rights. A vendor fix is available in the 2.5.0 release.
Cross-domain sender spoofing in Mailu allows a domain manager to authenticate as arbitrary senders on other domains hosted on the same instance. The flaw is an improper-authorization issue in which the Postfix sender-login lookup honors the allow_spoofing flag globally rather than scoping it to the requesting user's own domain, so a manager of one hosted domain can enable spoofing and pass DKIM/SPF authentication for domains they do not own. Exploitation requires an existing domain-manager (administrative) role (CVSS PR:H) on a multi-tenant deployment hosting more than one domain; there is no unauthenticated or end-user path, and no public exploit code was identified at time of analysis.
Mailu, an open-source mail server distributed as a set of Docker images, contains an authorization flaw that lets an authenticated domain manager reset the password of, or mint an API token for, a higher-privileged account that merely owns a mailbox in a domain they manage - including a global admin or a manager of another domain. Because the vulnerable endpoints are the user edit, password reset, and token creation flows, a successful attack grants full control of the victim account and all of its privileges, escalating a limited domain-manager role into global administrative control; the CVSS 3.1 vector is 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). Exploitation requires valid domain-manager credentials and the specific condition that a higher-privileged user owns a mailbox inside the attacker's managed domain, so single-tenant installs with no delegated domain managers are effectively not exposed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Unauthenticated remote command execution inside containers managed by Dockhand (Finsys) affects all versions prior to 1.0.34: the WebSocket upgrade request for the in-browser terminal endpoint /api/containers/<id>/exec is served without any authentication check, so an attacker who can reach the instance and knows a running container ID can open a raw terminal session and run commands inside that container. No authentication is required (CVSS:3.1/PR:N, CWE-306), and the S:C/C:H/I:H/A:H scoring reflects realistic container-to-host escalation when the target container is privileged or exposes sensitive host mounts such as the Docker socket; exploitation is constrained in practice because the attacker must know or enumerate a specific container ID and the target must have an interactive shell. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, though the pre-auth nature and high EPSS-relevant profile make the issue high priority; a vendor-released patch exists in version 1.0.34.
EnergizeLab's station-middleware (a NestJS-based service distributed as Docker images 1.6.5 through 1.8.2) exposes administrative APIs that perform no role or authorization checks, so any authenticated user holding a valid low-privilege account can read AI provider API keys and modify configuration and object-store contents. Tracked as CWE-862 and rated 9.6 Critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) because the flaw lets a low-privileged principal cross a security boundary to reach high-confidentiality and high-integrity resources; no availability impact is described. Exploitation requires pre-existing valid credentials plus network reachability to the middleware API - there is no pre-authentication path - and no public exploit code or confirmed active exploitation was identified at time of analysis, and no EPSS data was supplied.
Arbitrary file read in EnergizeLab station-middleware Docker images 1.6.5 through 1.8.2 lets any registered low-privilege account supply a request parameter that the backend treats as a file path, resolving it without adequate restriction and returning files from outside the intended directories, which can expose middleware source, configuration and server secrets. Exploitation is remote and authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N in our independent assessment) and is confined to the listed Docker image versions; the CNA-published score of 9.9 (with scope change plus high integrity and availability impact) conflicts with our read-only impact assessment and should be reconciled before treating this as a top-tier emergency. No CISA KEV entry is present in the supplied data and no public exploit was identified at time of analysis, although the reference set includes a GitHub repository link that may contain a demonstration. Exposure risk is highest where container images carry secrets, tokens, or private keys on a filesystem reachable by the middleware process.
Denial of service in Lychee before 7.7.0 allows an authenticated user with upload/import permission to tie up image-processing capacity by submitting a tiny PDF whose first page declares an oversized /MediaBox. Lychee hands PDFs to ImageMagick with Ghostscript enabled and applies no pre-render page-size check in ImagickHandler::loadPdf(), so Ghostscript burns CPU rasterizing an enormous page before the pixel-cache policy rejects the result; in synchronous QUEUE_CONNECTION deployments a single request occupies a web worker, while the official asynchronous Docker setup instead backs up the shared image-processing queue and delays other users' work. Exploitation is gated behind authentication, only availability is affected (no confidentiality, integrity, or Ghostscript sandbox-escape impact), and no public exploit was identified at time of analysis. The vendor/CNA scored this 7.1 under CVSS 4.0, whereas the independent assessment rates the same issue CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L (4.3), reflecting limited per-request availability impact.
Command injection in Dokku before 0.38.25 allows a user with authenticated app-level Dokku access and remote SSH access to store shell-substitution payloads through the docker-options plugin, and also via dokku run -e/--env values and --ttl-seconds; on the next build, deploy, or run, Bash eval interprets the stored value and executes arbitrary commands as the dokku OS user. Exploitation is privilege-gated, requiring valid app-level credentials and SSH access rather than being remote-unauthenticated, and no public exploit was identified at time of analysis despite the CVSS 9.0 severity.
Finsys Dockhand before 1.0.43 turns authenticated stack-template submission into a server-side data-theft primitive: an attacker-supplied repository URL or stackfile value is fetched by the server and the fetched body is echoed back in the compose response field, so internal services and cloud instance-metadata endpoints can be read directly rather than probed blindly. Any holder of a valid Dockhand account with the ability to create or submit stack templates to the API compose endpoint can exploit this, and the impact grows sharply where the instance has reachable IMDS or sensitive internal services on its network. No public exploit code was identified at time of analysis, and the vendor has released version 1.0.43 as the fix; the 8.4 score reflects high confidentiality impact tempered by the requirement for an authenticated account.
Incorrect privilege assignment in Docker Hub's account-to-organization conversion feature lets an authenticated user bind a personal access token they control to a different Docker Hub account without the token secret ever being rotated or revoked. The unchanged PAT then continues to authenticate successfully - now as the recipient user - granting pull, push, and delete operations, within its existing scopes, across every repository that user can access, including organization repositories. Docker rates this 9.4 under CVSS 4.0 and our independent assessment characterizes it as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, but exploitation is not unauthenticated: the attacker must already hold a valid Docker Hub account and a PAT, and the damage is bounded by that token's scopes; no public exploit code has been identified at time of analysis.
Unauthenticated remote attackers can obtain another client's PHP session identifier from FrankenPHP worker mode before 1.12.5 when the session extension is loaded as a shared module rather than statically compiled in. Because frankenphp_reset_session_state() is compiled out under that build configuration, PS(id) persists across request boundaries on the same worker thread, so a later session_start() may keep a stale identifier instead of adopting the new request's cookie, and under concurrent requests session_id() can return a different user's identifier - enabling information disclosure, session hijacking, and intermittent logouts, with integrity and availability also impacted (CVSS 7.7, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L, CWE-362). Exposure is conditional: official static binaries and Docker images that link the session extension statically are not affected, non-worker (classic) mode is not implicated, and the leak is intermittent and timing-dependent; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated users of Nginx UI (0xJacky/Nginx-UI) prior to 2.4.1 can bypass the built-in nginx directive validation and write arbitrary nginx configuration through the MCP tool nginx_config_add, which reloads nginx with the injected directives. Where nginx is built with the njs or perl module (as in the official Docker image), an attacker - or an MCP-enabled AI agent steered by prompt injection - can achieve code execution on the nginx host with the privileges of the nginx worker process. The CVSS score of 8.8 reflects a network-reachable, low-complexity path requiring only authenticated MCP access (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), making this a credible, actionable priority rather than a paper-high CVSS; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing).
Authenticated users of Blinko through version 1.8.8 can achieve remote code execution as root by supplying a plugin name containing '../' sequences to the plugin.installPlugin tRPC procedure, which constructs the install path from the unsanitized name and writes downloaded plugin files outside the plugins directory. Because the official Docker image runs as root, an attacker can overwrite a root-owned startup file and gain code execution at the highest privilege level; the endpoint is open to any authenticated account and the referenced sign-in code indicates self-registration may be enabled, potentially letting an unauthenticated outsider obtain the required account. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8), reflecting a genuine high-priority issue rather than a CVSS-inflated paper risk; no confirmed active exploitation is indicated by CISA KEV, though the references include a public repository dedicated to this path-traversal RCE chain that should be treated as potential exploit material.
Unauthenticated remote attackers can achieve full administrative control of self-hosted Agnai instances (versions through 1.0.555) deployed with the default self-host.docker-compose.yml, which contains a hard-coded admin password and a public JWT secret. Attackers can log in as admin or forge a JWT with admin privileges to impersonate users, reset passwords, and modify server configuration. This critical vulnerability (CVSS 9.3) requires no user interaction and no prior authentication, but exploitation is limited to instances that have not overridden the default credentials and are network-reachable. No public exploit code has been identified at the time of analysis, though the hard-coded secrets are publicly visible in the repository.
Remote unauthenticated attackers can gain full administrative control of openPDC deployments provisioned from the official published Docker image, because that image embeds a fixed administrative credential that is not forced to change on first use. Exploitation requires only network reachability to the management interface and retention of the default credential; source-built or manually provisioned instances that set their own credentials are not affected. No public exploit code has been identified at time of analysis, though the vulnerable condition is inherent to the image and the CVSS 4.0 base score is 9.3, highlighting the severity for exposed deployments.
Docker Desktop for Windows versions prior to 4.92.0 fail to verify the cryptographic signature of packages supplied via the 'Docker Desktop Installer.exe install -package' command-line option. An attacker who can place a crafted package on the target host and convince a user to approve the Docker-signed UAC elevation prompt can execute arbitrary installer actions as LocalSystem, achieving full system compromise. Although the CVSS 4.0 base score is 7.3 (HIGH), exploitation is constrained: it is a local attack requiring an existing low-privileged foothold and active user interaction; no public exploit code has been identified at time of analysis, and the vendor has released a patch in 4.92.0.
Unauthenticated path traversal in the Ollama `/api/pull` endpoint lets a remote attacker write an arbitrary file outside the model store by submitting a crafted path-traversal sequence in the layer digest field, because the `digestToPath` function does not adequately validate digests before constructing a filesystem path. When the Ollama process can write to `/usr/lib/ollama` (described as the default in most Ollama Docker images) and the server or container is subsequently restarted, the planted binary is loaded and executed, yielding remote code execution as root; the same file-write primitive is available without authentication to anyone who can reach the API. The issue is fixed in Ollama 0.35.0, no public exploit code has been identified at time of analysis, CISA's SSVC assessment records exploitation as 'none', and no EPSS score was supplied in the source data. Real-world risk is high but conditional: exploitation of the full RCE chain depends on write access to `/usr/lib/ollama` and a restart, so deployments not using the default Docker image, running Ollama as a non-privileged user without write access to that directory, or not exposing the API to untrusted networks face substantially reduced exposure.
Python code injection in PraisonAI's deploy tooling (all versions up to and including 4.6.77) lets a high-privileged actor who controls the `agents_file` value break out of an f-string and execute arbitrary code on the host running the deploy command. The flaw is triggered at build/deploy time: the unsanitized value is interpolated into generated server or Dockerfile source in `deploy/api.py` and `deploy/docker.py`, written to disk, and then launched via `subprocess.Popen(['python', server_file])`, so the primary realistic exposure is CI/CD pipelines or shared build environments where `agents_file` originates from externally influenced configuration. The vendor advisory includes a proof-of-concept demonstrating the string-breakout payload and a fix is available in 4.6.78; no CISA KEV entry or other confirmation of active exploitation was present in the source data, and this is not a remotely reachable flaw in a default running service - exploitation requires the attacker to already be positioned to set or tamper with deploy-time input and for someone to invoke the deploy command.
Cross-tenant information disclosure in wger allows an authenticated trainer account that holds both the gym.gym_trainer and gym.add_adminusernote permissions but has no gym assignment (userprofile.gym = None) to read private admin notes, uploaded documents, gym contracts, user configuration and permission data belonging to any other unassigned (gym = None) user on the same instance. The root cause is an authorization guard that fails open: the five affected views compare gym objects with the Python operator '!=', and 'None != None' evaluates to False, so HttpResponseForbidden is never reached and the following queryset is filtered only by the attacker-supplied member_id. Rated CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, authenticated, low privilege), the bug is amplified because gym = None is the default state for newly registered users, so any instance with public registration plus delegated trainer permissions is exposed; a detailed proof-of-concept is documented in the published GitHub advisory and the permission-edit endpoint is also reachable, giving a possible privilege-escalation path, though no confirmed in-the-wild exploitation has been reported.
Unauthenticated remote attackers can forge Django-signed session cookies, CSRF tokens, and password-reset tokens, and bypass live-service authentication, against Plane installations that shipped with publicly known default secrets. Plane versions prior to 1.4.0 distributed fixed SECRET_KEY (60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5) and LIVE_SERVER_SECRET_KEY (htbqvBJAgpm9bzvf3r4urJer0ENReatceh) values in the deployments/aio/community/ and deployments/cli/community/ manifests, while the top-level setup.sh randomized secrets only for the development Docker Compose path, leaving AIO and CLI community deployments with shared production secrets by default. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C/I/A:H) and classified CWE-798; no public exploit identified at time of analysis, although the default key values are published in the vendor repository and are therefore trivially usable by anyone who reads it. Exposure is limited to network-reachable instances deployed via those community manifests whose operators never overrode the secrets; deployments created through the development Compose path, operator-hardened installs with unique secrets, and instances upgraded to 1.4.0 are not exploitable.
Workflow-controlled container options in Gitea act_runner let an authenticated user who can trigger a job escape the job container into the runner host, because HostConfig fields such as PidMode=host, IpcMode=host, CapAdd=[ALL] and unconfined seccomp/AppArmor profiles survive the runner's sanitization pass and a job step can then use nsenter to execute commands as root on the host. The flaw specifically defeats the 'runner privileged mode disabled' hardening control, which only forces Privileged=false while sanitizeConfig() filters nothing but Binds and Mounts, so default Docker-backed configurations are affected below v3.0.0 (Go module gitea.com/gitea/runner < 1.0.9-0.20260731160927-34bfa1915022). Publicly available exploit code exists in the form of the advisory's minimal proof-of-concept workflow YAML, but no CISA KEV listing or confirmed active exploitation has been reported; impact scales with tenancy, being critical for shared runners accepting untrusted workflow submissions and lower for single-tenant runners restricted to trusted maintainers.
Command injection in the Nx `@nx/docker` release pipeline (nx 21.4.0 through 22.7.7 and 23.0.0 through 23.1.0) lets an attacker who can influence `release.docker.repositoryName` or `registryUrl` in repository configuration execute arbitrary shell commands with the privileges of the release job. Because the plugin builds `docker tag`, image-lookup, and `docker push` calls as shell strings passed to `/bin/sh -c`, a malicious pull request or config change that reaches a `nx release version` or `nx release publish` run can exfiltrate registry credentials and cloud tokens; dry-run publishing does NOT prevent the vulnerable image-lookup pre-check from firing. This is a genuine but conditional CI/CD supply-chain risk rather than a drive-by remote exploit, and no public exploit code or confirmed active exploitation was identified at time of analysis.
In Tugtainer versions before 1.31.3, the OIDC login flow accepts unverified JWT claims from the identity provider's id_token, allowing an unauthenticated remote attacker who can influence the token exchange to impersonate any identity and gain full control of the Tugtainer session. The flaw is a pre-authentication authentication bypass (CWE-347) with high confidentiality, integrity, and availability impact once triggered; exploitation requires OIDC to be configured and enabled. No public exploit has been identified at the time of analysis, and the issue is not listed in CISA KEV. A vendor patch is available in version 1.31.3.
Authenticated server-side request forgery in Tugtainer before version 1.30.6 allows any logged-in user with access to notification settings to make the backend send outbound HTTP requests to attacker-chosen URLs through the /settings/test_notification endpoint, reaching localhost, RFC1918 ranges, and cloud metadata addresses such as 169.254.169.254. The urls field is passed directly to the Apprise notification library with no scheme, hostname, private-IP, or metadata filtering in the default configuration, and because responses are not returned to the caller the attack is blind, which limits it to internal port scanning, service probing, and indirect information inference rather than straightforward data exfiltration. Our independent assessment agrees with the SSRF class and the authentication prerequisite (PR:L) but rates the CIA impact lower (C:L/I:L/A:L) than the vendor's 9.1 scoring, so the practical severity sits below the headline score; vendor-released patch: 1.30.6, and no public exploit identified at time of analysis, with no CISA KEV listing.
Unauthenticated attackers can reach the Tugtainer Agent's Docker management API and gain effectively full control over containers and the underlying Docker host, because the agent's request-signature check in agent/auth.py returns success whenever Config.AGENT_SECRET is left empty - which is the shipped default. All Tugtainer versions prior to 1.30.4 are affected (CPE cpe:2.3:a:quenary:tugtainer with a wildcard version), though exploitation requires the agent's port (default 127.0.0.1:8001) to be network-reachable, meaning deployments that place the agent on a separate host or otherwise expose it without setting a secret are the realistic victims; deployments that keep the agent internal or set AGENT_SECRET are not reachable. The CVSS 3.1 score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis, and the issue is fixed in vendor release 1.30.4, which rejects such requests with HTTP 401.
Improper access control in Tugtainer before version 1.30.3 causes the OIDC login flow to start even when OIDC_ENABLED=false, so a direct request to /auth/oidc/login still returns HTTP 302, sets an oidc_state cookie, and redirects the browser to the configured OIDC authorization endpoint despite the disable switch. The vendor scores this 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), but real-world impact is narrower than that score implies: exploitation requires a deployment where OIDC was fully configured (well_known_url, client ID/secret, authorization endpoint) and then toggled off, and the attacker must still complete authentication against that external identity provider to turn the initiated flow into a session. No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in Tugtainer 1.30.3.
Authentication bypass in Dockhand before 1.0.40 allows unauthenticated remote attackers to force redeployments of git-backed stacks by sending unsigned webhook requests when a stack's webhook secret is null or unset; the guard fails open and accepts the request. The immediate impact is denial of service through repeated git clone and docker compose operations, while full host compromise is possible only if the attacker also has write access to the tracked git branch to inject a malicious docker-compose.yml with privileged bind mounts. No public exploit identified at time of analysis, and the independent assessment rates exploitation complexity as high for the RCE chain, with the DoS path requiring only network reachability and stack ID enumeration.
Local privilege escalation in the npm package adm-zip through version 0.6.0: when an application extracts an archive with the non-default keepOriginalPermission=true option, the library copies the Unix permission bits recorded in each zip entry's external file attributes straight to disk via fs.chmodSync() without stripping the setuid (0o4000), setgid (0o2000) or sticky (0o1000) bits. An attacker who can supply a zip - no special access needed to craft one - can therefore plant a 04755 root-owned binary whenever the extraction runs as root (the common Docker-build, CI-runner and privileged-install posture where this flag is used), and the attacker's code executes as root once a lower-privileged user later runs that file. The issue is correctly rated Medium despite a 7.1 CVSS score because it is highly conditional (flag enabled, root extraction, setuid file preserved and executed by another user); confirmed actively exploited: no - not in CISA KEV - but a working proof-of-concept (a Python-crafted zip with external_attr 0o4755 << 16) is documented in the vendor advisory. Default usage with the flag off, or extraction as a non-root user, is not exploitable.
CRLF injection in psyb0t/docker-mailbox before 0.4.13 allows a remote unauthenticated attacker to append arbitrary IMAP commands to the service's already-authenticated upstream mailbox connection when bearer-token authentication is not configured. Attacker-controlled folder, UID, or search values are passed into IMAP command construction without neutralization, yielding high integrity and availability impact on the mail store; the exposed path only exists on instances deployed without bearer-token auth, and no public exploit has been identified at time of analysis. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects a network-reachable, low-complexity, no-interaction flaw, though real-world risk is constrained by the non-default configuration requirement and the project's very small deployment base.
Arbitrary code execution on an operator's workstation is achievable through kube-compare when it processes a 'container://' reference path pointing at an untrusted container image, because the tool launches that image's entrypoint instead of only reading data out of a stopped container. Exploitation is locally scoped and gated: per the assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, an unauthenticated (PR:N) attacker must convince the operator to invoke the tool against the malicious reference (UI:R), so the victim's own action is the trigger. This is a genuine but conditionally-gated risk - escalation to full root-mediated impact occurs only where the local Docker daemon runs with elevated privileges - and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; EPSS data was not supplied. The tool is distributed in Red Hat OpenShift Container Platform 4 and the 'Pen Drive Powered by Red Hat Lightspeed' offering.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allowing unauthenticated attackers who can reach that port to take full Owner/Admin control of the Obot API and UI. Because every request is mapped to a synthetic 'nobody' user that already holds Owner and Admin roles, an attacker can register and launch attacker-controlled MCP servers, and since the quickstart also mounts /var/run/docker.sock into the container, that control extends to the host's Docker daemon. All versions through commit d7e6970 are affected; the vendor fix is documentation-only (the quickstart now enables authentication), no public exploit code has been identified at time of analysis, and instances are safe only if the operator set OBOT_SERVER_ENABLE_AUTHENTICATION=true or kept port 8080 off untrusted networks.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Node-wide denial of service in RabbitMQ server 4.1.0 through 4.1.10, 4.2.0 through 4.2.8, and 4.3.0 through 4.3.2 occurs when the non-default rabbitmq_stream_management plugin is enabled: an authenticated management-UI user with access to the target vhost - but no configure, write, or read permission on the resulting streams - can issue a single PUT to /api/stream/super-streams/{vhost}/{name} whose binding-keys field is expanded into the full stream-name list before any resource permission check, forcing a large transient allocation. The advisory demonstrates one ~4.5 MB JSON PUT killing a RabbitMQ container capped at 768 MB, so effective denial of service is strongly dependent on a low memory ceiling; on hosts with ample memory the impact degrades to a temporary resource spike rather than a guaranteed crash. No exploitation in the wild has been confirmed and no public exploit code was identified at time of analysis, but the low privilege bar (any valid management credentials with vhost access) and high availability impact make it a realistic insider or compromised-credential risk for constrained deployments. The issue is fixed in RabbitMQ 4.3.3, 4.2.9, and 4.1.11.
Command injection in Dokploy before 0.29.13 lets an authenticated organization member with service:read permission execute arbitrary commands as root inside the Dokploy container by injecting shell metacharacters into the repoPath parameter of the patch.readRepoDirectories tRPC procedure. Because the standard deployment mounts /var/run/docker.sock, successful exploitation can pivot to control Docker and compromise the host and its managed applications; the vendor fix is available in 0.29.13, and no public exploit identified at time of analysis. The vulnerability is rated CVSS 9.9 with scope change and high confidentiality, integrity, and availability impact.
Frigate NVR deployments prior to 0.18.0 ship an nginx configuration that routes the prefix-matched location /api/go2rtc/api to the internal go2rtc API behind authentication but without an administrator role check, so any authenticated user holding only a low-privilege 'viewer' account can issue GET requests to that path and read proxied go2rtc data. Reachable subpaths (streams, config, log, stack) disclose internal network addresses, configuration file paths, application logs, goroutine stack traces, and RTSP stream URLs that may embed camera credentials; the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7) reflects remote, authenticated, read-only disclosure with changed scope, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis. This is a genuine but bounded confidentiality issue: non-GET methods are rejected by limit_except GET, so no modification or lateral write is possible, the impact is contingent on RTSP URLs actually containing embedded camera credentials, and instances already upgraded to 0.18.0 are not affected. Authentication requirements are confirmed as authenticated by the CVSS vector (PR:L); unauthenticated attackers and administrators are outside the stated prerequisite set.
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Authentication bypass in Mailu 2.0 through 2024.06.55 and Mailu helm-charts before 2.7.3 allows unauthenticated remote attackers to spoof the trusted proxy identity via a client-controlled X-Forwarded-By header, bypassing header-based proxy authentication. This affects only deployments with PROXY_AUTH_WHITELIST configured and REAL_IP_HEADER unset; default configurations are not vulnerable. The vendor has released fixes in Mailu 2024.06.55 and helm-charts 2.7.3, and no public exploit has been identified at time of analysis.
Malicious or compromised Model Context Protocol (MCP) server containers run under ToolHive CLI before 0.30.1 or ToolHive Studio before 0.38.0 are not network-isolated by default, allowing them to reach Docker gateway addresses (host.docker.internal, gateway.docker.internal, 172.17.0.1) and, critically, ToolHive's own API and MCP proxy endpoints, which are reachable without authentication (CVSS vector PR:N). A hostile MCP server can therefore read exposed data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services without ever escaping the container, with the scope change (S:C) reflecting a pivot from the container into the ToolHive control plane; exploitation requires user interaction because an operator must choose to run the untrusted server (UI:R). The vendor rates this 8.8 (High/Critical); no public exploit code was identified at time of analysis and the issue is not in CISA KEV, though the impact is severe for anyone running third-party MCP servers on Docker with default settings. Fixes are available in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, which flip network isolation to enabled by default.
Code injection into the quay-builder-qemu release workflow through supply-chain compromise of the third-party GitHub Action `Noelware/docker-manifest-action`, which the workflow references by a mutable branch instead of a pinned immutable commit SHA. An attacker who first subverts that upstream action can execute arbitrary code inside the release pipeline, exfiltrating sensitive registry credentials or publishing malicious container images, with severity amplified because the workflow also exposes the default GITHUB_TOKEN. This is a CI/CD build-pipeline flaw rather than a defect in deployed Quay instances and is not directly exploitable against Quay itself; no public exploit code was identified at time of analysis, and the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H reflects high attack complexity because successful exploitation depends on first compromising an external dependency and only triggers when the release workflow executes.
Authenticated users who hold only the read-only startup.read permission on a Pelican Panel server can escalate that access into remote command execution inside the managed container, because write protection for startup settings is enforced solely through disabled client-side form controls rather than a server-side authorization check. By pushing crafted Livewire state updates, the attacker triggers afterStateUpdated callbacks that rewrite startup commands, Docker images and variables, and those values are then executed when the container starts. All Pelican Panel deployments below 1.0.0-beta35 are affected; exploitation needs a low-privileged panel account scoped to the target server, no victim interaction, and reachability of the panel's Livewire endpoint. A vendor patch is available in 1.0.0-beta35, no public exploit code has been identified, and the issue is not listed in CISA KEV at time of analysis.
Authenticated users on Harness deployments through version 3.3.0 can read infrastructure provider configurations from spaces they do not belong to, because the GET /api/v1/infraproviders endpoint fails to validate space-level access control (CWE-862). Exploitation requires only a valid low-privilege account (CVSS v4.0 PR:L, and the independent assessment rates it PR:L as well), so it is realistic mainly on multi-tenant or multi-space instances where the attacker's account lives in a different space than the targeted provider records; a single-tenant instance with no untrusted users has limited exposure. The result is a confidentiality-only impact (VC:H, no integrity or availability effect) exposing sensitive provider metadata such as Docker endpoints, TLS certificate paths, and cloud project identifiers. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Note: the supplied CVSS v4.0 base score of 7.1 and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) agree on the authenticated, network-reachable, read-only nature of the flaw.
Unauthenticated path traversal in the @zereight/mcp-gitlab Model Context Protocol server prior to version 2.1.27 allows any network-reachable attacker to read arbitrary files from the server host and exfiltrate their contents into an attacker-accessible GitLab project upload, enabling theft of the server's GITLAB_PERSONAL_ACCESS_TOKEN from /proc/self/environ and resulting in full GitLab account takeover. The exposure exists in SSE transport mode (SSE=true), which the advisory states is the default configuration for Docker deployments and which serves all MCP tools without any authentication; the assessed severity is CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). No public exploit code and no CISA KEV entry were identified at time of analysis, but the attack requires only network access to the exposed SSE port and a single call to the upload_markdown tool.
Docker Sandboxes 0.37.0 through 0.40.x contain a time-of-check/time-of-use race (CWE-367) in the guest-to-host Unix-domain socket relay: the host validates that a requested socket path sits inside an authorized workspace and then reconnects using that same pathname, letting a malicious guest swap an intermediate directory for a symlink in the gap. A guest that wins the race causes the host-side relay to connect to an arbitrary AF_UNIX socket outside the shared workspace, exposing whatever data or host capabilities that socket provides. Vendor-released fix: Docker Sandboxes 0.41.0; no public exploit code or CISA KEV entry was identified at time of analysis.
Flowise releases prior to 3.1.4 ship GitHub Actions workflows that interpolate workflow_dispatch inputs such as tag_version and node_version directly into shell run blocks, allowing OS command injection during Docker image builds. The flaw is reachable only by a user who already holds write access to the repository (CVSS 4.0 PR:H), but the payoff is large: arbitrary command execution on the build runner with access to AWS credentials and Docker Hub tokens. No public exploit code or CISA KEV entry was reported at time of analysis, and the vendor has published a fix in 3.1.4 via GitHub Security Advisory GHSA-jrcq-qjw5-xx5q; note that this is a supply-chain/CI risk to the project's own build pipeline and to forks that reuse these workflows, not a runtime flaw in deployed Flowise instances.
Sandbox escape in Docker Sandboxes on macOS (0.28.0 through 0.41.x) lets a workload running inside a sandbox break out of its shared workspace and read or modify arbitrary files on the host as the VMM user, with host code execution possible where the reachable files are executable or otherwise privileged. The virtio-fs host server follows symlinks when reopening an unlinked file from a stored path, so a guest that replaces a parent directory of a workspace file with a symlink can redirect host-side file operations outside the workspace bind mount. Exploitation requires the attacker to already control a guest workload (for example an untrusted agent or repository), is macOS-specific, and depends on winning a directory-swap timing race; SSVC records Exploitation: none, and no public exploit code was identified at time of analysis. The raw 9.4 CVSS 4.0 score should be read alongside these preconditions rather than at face value - this is a genuine sandbox escape leading to host compromise, but it is not remotely reachable and is bounded by the privileges of the VMM user rather than root.
Server-side request forgery and root-level code execution in IBM Langflow OSS 1.0.0 through 1.10.0 lets an authenticated user smuggle arbitrary Python through submitted flow components. Because the component validation scanner fails to block socket and urllib imports yet still returns "validated": true, attackers run code as UID=0 to steal AWS credentials via IMDSv1 SSRF, exfiltrate container files, and pivot to internal PostgreSQL and Redis services. Public exploit code exists, though the flaw is not on the CISA KEV list.
Authentication bypass in ESPHome Device Builder (the esphome-device-builder package powering the `dashboard` subcommand of the ghcr.io/esphome/esphome container) versions before 1.0.12 silently disables dashboard authentication on upgrade for operators who had protected it with the legacy bare $USERNAME/$PASSWORD environment variables. A rename to $ESPHOME_USERNAME/$ESPHOME_PASSWORD (PR #265) dropped the old names with no fallback, so `using_password` becomes false and both the REST auth middleware and WebSocket login gate switch off, leaving the dashboard open to anyone who can reach its port. Because a compromised dashboard caller can compile arbitrary code and read/write config and data directories, this is effectively unauthenticated RCE; publicly available exploit/PoC code exists, though it is not in CISA KEV (SSVC exploitation: none).
LangBot's debug WebSocket server binds to all interfaces on port 5401 and ships with an empty authentication key by default - and the official Docker image together with its docker-compose configuration publish that port to the host, placing every default deployment within reach of any network attacker. A remote unauthenticated attacker who reaches the /plugin/ws endpoint can register an arbitrary debug plugin, after which LangBot broadcasts the full plaintext context of every inbound IM message event to that plugin, enabling mass interception of private chats, forged bot replies, LLM pipeline poisoning via malicious tool registration, knowledge-base enumeration, and persistent denial of service by blocking legitimate plugin installations with the prod_mode flag. No patched version was available at time of publication; SSVC classifies exploitation as proof-of-concept-available and fully automatable.
Local privilege escalation in Apache Storm Worker Launcher 3.0.0 allows an authenticated Storm topology tenant to gain root on supervisor nodes by exploiting a TOCTOU race in the setuid-root worker-launcher binary: the binary chowns the entire worker directory to the untrusted topology user before re-reading the supervisor-written command file, creating a window in which the tenant can substitute attacker-controlled content. For Docker workers, the injected command executes with real uid 0 through an insufficiently constrained argument sanitizer that passes -v, --device, --cap-add, --security-opt, --user, --net, and positional arguments verbatim; for OCI workers, arbitrary host paths can be bind-mounted read-write and execution can be forced as another tenant's uid. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 3.1.0.
OS command injection in @argos-ci/core <=6.2.0 allows any attacker who can influence a CI pipeline's branch or ref name to execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process. The vulnerable sink is in packages/core/src/ci-environment/git.ts:89, where execSync() receives an unsanitized branch string interpolated into a template literal passed directly to /bin/sh -c, which evaluates $() command substitution and other metacharacters before spawning git. A fully working proof-of-concept exploit exists (GHSA-4x45-gxvp-6283) and the attack surface is widened by the fact that hasRemoteContentAccess: false - the configuration that triggers the vulnerable code path - is the default for projects without a connected Git provider integration.
Command injection in Renovate's Maven Wrapper manager allows an attacker with write access to a scanned repository to execute arbitrary OS commands on the host running Renovate when `binarySource=docker` mode is active. Unescaped `distributionType` values from `maven-wrapper.properties` are passed directly to a shell, giving the attacker full code execution in the Renovate process context. No public exploit or CISA KEV listing exists at time of analysis; vendor-released patch is available at version 44.14.7.
Command injection in Renovate's Mix package manager allows an attacker who can control private dependency package names to execute arbitrary OS commands as the Renovate process user. Versions before 44.14.7 fail to escape organization parameters before passing them to shell commands during dependency resolution in binarySource=docker mode. No public exploit code has been identified at time of analysis, but the attack surface is reachable whenever Renovate processes Elixir/Mix private dependencies under the affected configuration.
Credential exfiltration in Renovate (renovatebot/renovate) before 44.11.2 lets a malicious or compromised container registry steal the registry credentials Renovate holds. When enumerating container image tags/digests, Renovate follows an HTTP Link header pagination URL and re-attaches the original registry's credentials without checking that the follow-up URL shares the same origin (CWE-601 open redirect), so a hostile registry can redirect the authenticated request to an attacker-controlled host and capture the secrets. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not in CISA KEV.
Command injection in Renovate's Gradle Wrapper manager module allows a repository contributor to execute arbitrary OS commands on self-hosted Renovate instances. Open-source versions before 44.14.7 and Mend Renovate CE/EE before 15.4.0 fail to escape the `distributionUrl` value read from a repository-controlled `gradle/wrapper/gradle-wrapper.properties` file before passing it to the Gradle Wrapper CLI, enabling shell metacharacter injection. Exploitation is constrained to self-hosted deployments explicitly configured with `binarySource=docker` and `gradleWrapper` in `allowedUnsafeExecutions`; no public exploit code or active exploitation has been identified at time of analysis.
Command injection in Renovate's gomod manager (before 44.14.7) exposes CI/CD pipelines to arbitrary shell command execution as the Renovate user when a maliciously crafted Go module dependency name containing shell metacharacters is processed. The flaw is exercised only under two simultaneously required non-default configurations - `binarySource=docker` mode and `postUpdateOptions gomodUpdateImportPaths` enabled - confining exposure to a specific subset of Renovate deployments performing Go module major version updates. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Path traversal in @openhop/server (npm, versions ≤0.3.5) allows unauthenticated remote attackers to read or permanently delete arbitrary `.yaml` files accessible to the OpenHop process outside its configured flow data directory. The root cause is that `FlowStore.filePath()` passes caller-supplied HTTP route parameters directly to Node.js `path.join()` without any sanitization or allowlist validation, and Fastify's underlying `find-my-way` router URL-decodes the parameter before it reaches application code, enabling `..%2F`-encoded directory traversal. A fully functional PoC is publicly available with Docker-based reproduction steps; no KEV listing at time of analysis. Docker deployments expose the server on all interfaces by default, enabling direct network exploitation without user interaction.
Unauthenticated LAN access to the ESPHome Device Builder dashboard on Home Assistant add-on deployments allows any device on the local network to gain host-equivalent control with no credentials. The ingress site, which deliberately skips authentication because the HA supervisor is supposed to authenticate upstream, was bound to 0.0.0.0 instead of loopback and the supervisor gateway. Because the add-on uses host networking for mDNS, this exposed the no-auth site on the host's LAN interface, directly bypassing the supervisor's authentication layer. An attacker with LAN access can run arbitrary Python via external_components at compile time, execute arbitrary shell through compile/validation subprocesses, and read or write arbitrary files in the config and data directories. No public exploit has been identified at time of analysis.
Remote code execution in functype-mcp-server 1.4.3 and earlier allows any MCP client - including an LLM agent manipulated via prompt injection - to execute arbitrary JavaScript in the server process by invoking the `set_functype_version` tool with a `file:`, `git+`, or URL package-alias as the version string. The server interpolates the unsanitized input directly into a `pnpm add` specifier, installs the attacker-controlled package as the `functype` alias, then immediately dynamic-imports `functype/cli` from the poisoned location, running module-level attacker code with full MCP server process privileges. A fully automated Docker-based proof-of-concept confirming end-to-end RCE is documented in GHSA-wcjj-9m6g-2fr2; no public exploitation has been confirmed (not in CISA KEV), and a patched version 1.4.4 is available.
nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally places the Ollama cloud API key into Nuxt's public runtime config, causing it to appear verbatim in every server-rendered HTML page inside the `window.__NUXT__` script block, readable by any unauthenticated HTTP client. Any visitor or web crawler that fetches any page of an affected application can extract the `api_key` from the serialized SSR payload with a single GET request, then impersonate the operator against the Ollama cloud API to incur billing charges, exhaust rate limits, or exfiltrate stored model data. A publicly available PoC using Docker and Python has dynamically confirmed the leak; no public exploit identified at time of analysis for active KEV-level exploitation.
Administrative takeover of the Eclipse aeriOS Identity Manager (IdM) is possible because the current development-version deployment exposes its Keycloak server and PostgreSQL backing database to the network (Kubernetes NodePort services, and PostgreSQL bound to all interfaces under Docker Compose) while shipping fixed, publicly documented default credentials for the Keycloak admin and the PostgreSQL user. An attacker who can reach these services logs in with the published defaults to read or modify identity data - users, roles, client credentials, sessions, and cryptographic material - and can mint privileged identities or tokens trusted by other aeriOS components. No official release exists yet; there is no CISA KEV listing and no public exploit identified at time of analysis, though the credentials are effectively public in the source repository.
Local privilege escalation to root in Dell Secure Connect Gateway (SCG) 5.0 lets a low-privileged operator with SSH access to the appliance host obtain full root control without a password by abusing the exposed Docker socket (CWE-250, Execution with Unnecessary Privileges). Affected builds are the SCG Appliance prior to 5.36.00.16 and the SCG Application prior to 5.36.00.00. The same socket exposure also enables container escape: an attacker who compromises any service inside the orchestrator container can break out to host-level control. No public exploit is identified at time of analysis and it is not listed in CISA KEV, but the technique (writable/accessible Docker socket) is a well-known and reliable escalation path.
Bifrost HTTP transport before version 2.0.0 exposes an unauthenticated plugin installation endpoint (POST /api/plugins) that accepts HTTP URLs as plugin paths, enabling SSRF on all build types and unauthenticated remote code execution on dynamically linked builds. Because management authentication is disabled by default (governance.auth_config.is_enabled=false), no credentials are required to trigger the flaw; the shared-object loader fetches the attacker-supplied URL, writes it as a temporary .so, and on DYNAMIC=1 builds calls plugin.Open() which immediately executes the plugin's Init() function as the Bifrost process user. Reported by JFrog, the fix ships in transports/v2.0.0, adding an SSRF-safe dial context (SSRFSafeDialContextWithAllowlist) around plugin downloads; no public exploit code or active exploitation has been confirmed at time of analysis.
Unauthenticated session-token forgery in Peppermint (an open-source self-hosted helpdesk/ticketing platform) versions through 0.5.5 lets any remote attacker impersonate arbitrary users. The application's docker-compose.yml ships a hardcoded JWT signing secret that is public in the project repository, so an attacker who knows the secret can mint valid tokens for any user ID - including administrators - and reach protected API endpoints without credentials. Reported by VulnCheck; no public exploit identified at time of analysis, though the 'exploit' is trivially the published secret itself.
TLS certificate validation is disabled by default in the Federator component of Eclipse aeriOS, enabling man-in-the-middle interception of all outbound HTTPS connections made by the component. Any attacker who can position themselves on the network path between the Federator and external services - including OAuth authorization servers - can impersonate those services and harvest OAuth client credentials and bearer tokens. This affects only the current pre-release development codebase; a source-level fix is confirmed in commit 9c63b60, but no official tagged release exists. No public exploit or CISA KEV listing has been identified at time of analysis.
Incomplete patch for OS command injection in the Nuclio serverless dashboard (local/Docker platform, all versions prior to 1.17.4) leaves the list-all resource code path exploitable by unauthenticated remote attackers. Shell metacharacters injected via the X-Nuclio-Function-Namespace, X-Nuclio-Project-Namespace, or X-Nuclio-Function-Event-Namespace HTTP headers bypass the prior fix and reach a /bin/sh -c invocation in pkg/platform/local/client/store.go unescaped, enabling arbitrary command execution inside the dashboard container. No public exploit has been identified at time of analysis, but the attack surface is network-accessible and requires no authentication, lowering the bar significantly for any attacker already familiar with the previously disclosed injection class (GHSA-jx7q-cpg6-669g).
OS command injection in Nuclio's local Docker platform dashboard allows remote attackers to execute arbitrary shell commands as root inside the dashboard container, which holds the Docker socket, enabling full host compromise. The function namespace value - controllable via the unauthenticated (default 'nop' auth) API - is string-interpolated without quoting into a `docker ps --filter` command executed via `/bin/sh -c`, allowing a double-quote character to break out of the filter token and inject arbitrary commands. The issue is fixed in version 1.17.4, with the patch confirmed via GitHub release tag and PR #4220; no public exploit identified at time of analysis.
Authenticated command injection in Coolify before 4.2.0 allows low-privileged platform users to execute arbitrary OS commands on managed server hosts by embedding shell metacharacters into Docker environment variable key names. The flaw bypasses container isolation entirely - injected payloads travel over SSH as part of Coolify-generated Docker commands and execute in the host OS context, not within any container sandbox. The upstream fix in v4.2.0, confirmed by GitHub release tag and patch commit b50839d4515b115b7ded5db609471440249995da, adds validation constraints in ValidationPatterns.php to reject malformed key names before command construction.
Privilege-escalation-to-RCE in MCPHub before 0.12.15 lets any authenticated low-privileged user reach OS command execution via the POST /api/servers and PUT /api/servers/:name endpoints, which spawn a configured stdio process through child_process.spawn without an admin authorization check or command allowlist. Because command and args are attacker-controlled, a non-admin user can set command to /bin/sh (or any binary) and have MCPHub run it as its own OS user - frequently root in the published Docker image and in npx/systemd deployments. No public exploit identified at time of analysis, though the fixing PR (#770) and GHSA advisory publicly detail the root cause.
phpSysInfo up to and including version 3.4.5 exposes a complete IP allowlist bypass in read_config.php that any unauthenticated remote attacker can exploit by sending a spoofed X-Forwarded-For or Client-IP HTTP header set to any address present in the PSI_ALLOWED configuration. The flaw (CWE-290) renders the application's only access-control mechanism entirely ineffective, allowing full retrieval of system telemetry including hostname, kernel version, CPU model, memory layout, filesystems, and network interface addresses. A working proof-of-concept is publicly available on Exploit-DB; no CISA KEV listing exists at time of analysis.
Blind SQL injection in WsgiDAV's MySQLBrowserProvider sample module (versions <= 4.3.4) allows unauthenticated network attackers to read arbitrary data from the backing MySQL database via URL path manipulation. The record key segment of the URL is concatenated directly into a WHERE clause without escaping, enabling a boolean status-code oracle that supports full character-by-character data extraction. A secondary typo in the numeric-type check (`INTT` instead of `INT`) ensures all primary key types take the vulnerable quoted branch, and a working PoC with complete extraction script has been publicly confirmed. No public exploit identified as confirmed actively exploited (CISA KEV), but the PoC lowers the exploitation bar significantly.
NF registration poisoning in free5GC's Network Repository Function (NRF) lets attackers with SBI network access register forged Network Function profiles containing arbitrary, attacker-controlled service endpoint IPs, because the RegisterNFInstance handler performs no field validation against 3GPP TS 29.510. Legitimate NFs (AMF, SMF, AUSF, UDM, PCF, NSSF) then discover the fake profiles via NFDiscover and route control-plane signaling to the attacker, enabling interception, OAuth2 credential harvesting, and denial of service across the entire 5G core service mesh. Publicly available exploit code exists and the vendor has released a patch; the flaw is CWE-20 with a vendor CVSS 4.0 base score of 9.3 (Critical).
Unauthenticated remote code execution in SENAITE.CORE (senaite.core) 2.0.0 through 2.6.0 lets any network-reachable attacker run arbitrary Python in the Zope worker process by chaining a missing authorization check with an eval() sink in the JSON API. The anonymous-reachable /@@API/update route calls eval() on attacker-supplied RecordsField/RecordField values before any permission or write check fires, and a public working PoC (tested against the stock senaite/senaite:v2.6.0 Docker image) demonstrates credential-free command execution. Publicly available exploit code exists; the flaw is not listed in CISA KEV, so there is no confirmation of active exploitation.
Remote code execution in qwed 5.1.1 allows any authenticated tenant to execute arbitrary Python code inside the API server process by submitting crafted mathematical expressions to the POST /verify/math or POST /verify/batch endpoints. User accounts are freely self-registerable via the default-enabled /auth/signup endpoint - no invitation code or administrator approval required - making the effective exploitation barrier nearly equivalent to unauthenticated. A complete, functional proof-of-concept exploit script is publicly available in the GitHub advisory (GHSA-q27q-98j4-9pfv), and a vendor-released patch is available in version 5.1.2.
Arbitrary OS command execution in mcp-shell's default Docker image allows any MCP tool caller to bypass the secure-mode executable allowlist by supplying `/bin/bash -c <payload>` to the `shell_exec` tool, running commands as `mcpuser` (UID 1000) inside the container. The validator in `security.go` extracts only the first whitespace-delimited token as the executable, approves `/bin/bash` against the default allowlist, and passes the `-c` flag through the metacharacter check unchallenged because the default `blocked_patterns` array is empty. A fully working PoC is included in the GitHub Security Advisory GHSA-3x77-wg38-92r3; no public exploit identified at time of analysis beyond the researcher-provided PoC, and no CISA KEV listing exists. Vendor-released patch v0.6.0 is confirmed.
OS command injection in mcp-shell's 'secure mode' allows any MCP client to execute arbitrary shell commands by exploiting Git's runtime alias mechanism. The security validator in security.go blocks common shell metacharacters but omits '!', the prefix Git uses to invoke shell aliases via '-c alias.NAME=!CMD'. Because /usr/bin/git is in the default allowed_executables list and the CVSS PR:N vector confirms no authentication is required, all default Docker deployments (mcpuser, UID 1000, Git pre-installed) are exploitable by any entity with MCP connectivity. A fully functional PoC is published in the GHSA advisory; no CISA KEV listing is present at time of analysis.
Insufficient access control granularity in docker-socket-proxy allows adjacent-network attackers without credentials to read arbitrary files and exfiltrate entire container filesystems via four unguarded Docker API endpoints. When the CONTAINERS environment variable is set, the HAProxy-based proxy fails to block /containers/{id}/archive, /containers/{id}/export, /containers/{id}/logs, and /containers/{id}/top, treating namespace-level permission as blanket endpoint permission. No active exploitation or confirmed public exploit code has been identified at time of analysis, though a researcher gist is referenced alongside the upstream fix in PR #183.
Cross-user memory disclosure and tampering in Headroom's LLM proxy (versions before 0.36.1) lets a caller read or overwrite any user's stored LLM memory by simply naming another user's identifier in the client-supplied x-headroom-user-id request header. The proxy trusts this header as the authenticated identity across the chat-completion and websocket data-plane paths in headroom/proxy/handlers/openai.py, with nothing binding the value to the actual caller. The console script binds loopback by default, but the shipped docker-compose.yml publishes the proxy on 0.0.0.0 with no required proxy token, so a stock Docker deployment exposes these routes to the network unauthenticated. Reported by VulnCheck; no public exploit identified at time of analysis.
Server-side request forgery in Headroom LLM proxy (versions before 0.36.1) allows unauthenticated remote attackers to redirect proxy upstream requests to arbitrary internal, loopback, link-local, or RFC 1918 destinations - including cloud instance metadata endpoints such as 169.254.169.254 - by supplying a crafted x-headroom-base-url request header. The proxy returns upstream responses verbatim to the caller, disclosing internal service content; critically, it also forwards the original Authorization header to the attacker-designated host, enabling credential harvesting. Exploitation is trivially achievable against deployments using the vendor-shipped docker-compose.yml, which binds 0.0.0.0 and enforces no HEADROOM_PROXY_TOKEN by default - a configuration weakness the server itself warns about at startup. No public exploit or KEV listing is identified at time of analysis; a vendor patch is available in v0.36.1.
Missing authorization in the Mailu admin REST API allows unauthenticated remote attackers to strip IP-based access restrictions from any existing user token or alter its comment field, effectively neutralizing a key access-control layer on API tokens. All Mailu deployments running versions prior to 2024.06.52 with the admin REST API explicitly enabled are affected. No public exploit code or CISA KEV listing is identified at time of analysis, though the network-accessible, zero-authentication attack vector (PR:N, AC:L) makes this straightforward to leverage when the API is reachable.
Path traversal in Dockge's stack name handling allows authenticated users to exfiltrate secrets from .env and Compose files belonging to any directory the server process can reach, and to recursively delete those directories. The flaw exists because validate() - which enforces a strict name allowlist - is only called from the save() code path; the socket handlers that service read and delete operations pass the raw user-supplied name directly to Stack.getStack without sanitization. Because Dockge routinely runs as root with access to the Docker socket, the reachable set encompasses the full host filesystem, not just managed stacks. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the bypass is mechanically trivial for any authenticated user.
Remote denial-of-service in vouch-proxy v0.47.2 and earlier crashes the server process with a single unauthenticated HTTP request. The /validate endpoint's multipart cookie reassembly routine in pkg/cookie/cookie.go parses the total part count directly from the attacker-controlled Cookie header name - an N value of 10 billion passed as VouchCookie_1of10000000000 triggers a make([]string, N) call requesting approximately 160 GB of heap, immediately raising a Go runtime fatal out-of-memory error. No authentication, session token, or prior interaction is required; a fully working PoC with Docker reproduction artifacts is publicly disclosed in the GitHub Security Advisory, though no CISA KEV listing is confirmed at time of analysis.
Path traversal in the MineAdmin app-store plugin service lets any authenticated API user read, install, or uninstall plugins from directories outside the intended plugin folder by supplying traversal sequences (e.g., ../) in the `identifier` parameter of the /admin/plugin/store/download, /install, and /uninstall endpoints. The enabling condition is the absence of PermissionMiddleware on those routes (GM-4340), so exploitation requires only a valid JWT, not administrator privileges - the vendor's CVSS 4.0 vector scores PR:N, but this assessment treats the issue as authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H) because AccessTokenMiddleware still guards the endpoints. Publicly available exploit code exists and the finding was reproduced and validated in a Docker environment; the most severe outcome (code execution) additionally depends on how Plugin::install() invokes composer on the traversed path.
Uncontrolled decompression in Malcolm's upload-processing pipeline allows any authenticated user with upload permissions to exhaust the shared Docker volume by submitting a single-stream compression bomb (.gz, .bz2, .xz, .lzma, .lz). The flaw in scripts/safe-extract.py is a logic gap: entry-count, nesting-depth, and total-uncompressed-byte guards exist for container formats (zip/tar/rar/7z via libarchive) but are entirely absent for single-stream formats, allowing unbounded expansion. Successful exploitation denies service to all platform users simultaneously by starving OpenSearch, Logstash, Arkime, and Zeek of shared disk. No public exploit or CISA KEV listing has been identified at time of analysis; however, the attack is conceptually trivial once the bypass is known.
Tar extraction path traversal in moby/go-archive allows an attacker who controls archive contents to create or overwrite files outside the intended destination directory, undermining container-to-host filesystem boundaries. The affected functions - Unpack, UnpackLayer, Untar, UntarUncompressed, and ApplyLayer - perform lexical path validation but rely on OS-level resolution at operation time, meaning symlinks introduced inside the archive redirect writes to arbitrary paths writable by the extracting process. This flaw propagates through the full Docker ecosystem including Docker Engine, Docker Desktop, Docker CLI, Docker Compose, and Docker Sandboxes; vendor-released patches are available and no public exploit code has been identified at time of analysis.
Denial-of-service in vm2 (Node.js sandbox library) versions 3.11.0-3.11.5 allows sandbox code to bypass the `bufferAllocLimit` DoS mitigation via two unwrapped allocation paths - `Buffer.concat(list, totalLength)` and `Buffer.from({length: N})` - committing unbounded host external memory in a single synchronous C++ call that V8's timeout mechanism cannot interrupt. A publicly available PoC confirms that a 200-byte sandbox payload inflates host RSS by hundreds of megabytes per invocation, making a single crafted request sufficient to OOM-kill a host process running inside a Docker container, Kubernetes pod, or AWS Lambda function. No public exploit identified in CISA KEV at time of analysis, though functional exploit code is embedded in the GHSA advisory itself.
Remote command execution in Flowise <= 3.1.2 lets an authenticated user break out of the vm2/@flowiseai/nodevm JavaScript sandbox by abusing the /api/v1/node-custom-function endpoint. By passing attacker-controlled executablePath and args into puppeteer.launch(), the code reaches child_process.spawn() outside the sandbox, yielding arbitrary OS command execution as the Flowise process user (root in the official Docker image) and host file disclosure via Chromium's file:// handling. No public exploit is identified at time of analysis, but a vendor security advisory (GHSA-9gvv-qjj3-2p6g) and VulnCheck confirm the flaw; the CVSS 4.0 base score is 9.4.
Remote unauthenticated authentication bypass in WolfStack before 25.9.2 lets attackers fully compromise container hosts by supplying a hard-coded cluster secret in the X-WolfStack-Secret header. Because the secret is a compile-time constant published in src/auth/mod.rs, anyone who can reach a node's management port passes the require_auth() gate with no session, API key, or account, and can then enumerate every Docker/LXC container and run arbitrary commands as root inside any of them. No public exploit is identified at time of analysis, but the flaw is trivially reproducible from source and was reported by VulnCheck.
Command injection in stata-mcp (pip:stata-mcp < 1.19.0) enables full OS-level remote code execution against any principal that can invoke the `ado_package_install` MCP tool. The `package` argument is concatenated unsanitized into a Stata command string delivered via pexpect.sendline(), allowing embedded newline characters to inject arbitrary Stata commands - including the `shell` escape - that execute under the account running the MCP server. Because the tool is registered in the default `all` profile and `all` is the active default, no misconfiguration by the victim is required; a detailed proof-of-concept confirmed via Docker reproduction is publicly available in the GitHub advisory, and a vendor-released patch exists in v1.19.0.
URLSecurityValidator SSRF bypass in compliance-trestle <= 4.0.3 allows a network-positioned attacker to reach cloud metadata services, loopback admin interfaces, and RFC 1918 internal networks by embedding IPv4-mapped IPv6 literals (e.g., [::ffff:169.254.169.254]) or the unspecified address 0.0.0.0 in OSCAL artifact import references processed by HTTPSFetcher or SFTPFetcher. Python's ipaddress module silently returns False - rather than raising TypeError - when comparing IPv6Address objects against IPv4Network ranges, so the validator's membership checks pass these forms through to requests.get unchanged. A publicly available proof-of-concept reproduces end-to-end IMDS credential exfiltration; no active exploitation is listed in CISA KEV and EPSS stands at 0.42%.
Delegated 'users:update' permission in Arcane (getarcaneapp/arcane) 2.5.0 and earlier allows an authenticated holder of that permission to overwrite the global administrator's password via PUT /users/{adminId} and then authenticate as the admin, achieving complete administrator account takeover. The UpdateUser handler (backend/api/handlers/users.go:317-323) and the underlying user service (user_service.go:174) set the target user's PasswordHash from the request body and Save unconditionally, with no comparison of caller privilege against target privilege, even though users:update is deliberately intended to sit below the RequireGlobalAdmin-gated role assignment and role CRUD operations. Exploitation is remote, requires no user interaction, and needs no extra configuration beyond the precondition that an administrator has created a custom role (e.g. 'User Manager') containing users:update and assigned it to the attacker's account; deployments that never delegate that permission are not exposed, and no public exploit was identified at time of analysis (CVSS 8.8, PR:L).
Arcane versions prior to 2.5.0 disclose stored container-registry credentials to an attacker-controlled host: an authenticated principal holding both the registries:update and registries:test permissions can repoint an existing generic (non-ECR) registry entry to a URL they control without supplying a replacement token, causing the preserved encrypted PAT or password to be decrypted and sent to that host during RegistryLogin/TestRegistry. The issue is rated CVSS 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) and classified as CWE-200 information exposure, with the scope change and high confidentiality impact reflecting that the leaked credential grants access to, and potential tampering with, the source registry's images. No public exploit code and no confirmed active exploitation were identified at time of analysis, but the flaw is a credible credential-theft primitive for any tenant or operator account that has been granted registry management rights. A vendor fix is available in the 2.5.0 release.
Cross-domain sender spoofing in Mailu allows a domain manager to authenticate as arbitrary senders on other domains hosted on the same instance. The flaw is an improper-authorization issue in which the Postfix sender-login lookup honors the allow_spoofing flag globally rather than scoping it to the requesting user's own domain, so a manager of one hosted domain can enable spoofing and pass DKIM/SPF authentication for domains they do not own. Exploitation requires an existing domain-manager (administrative) role (CVSS PR:H) on a multi-tenant deployment hosting more than one domain; there is no unauthenticated or end-user path, and no public exploit code was identified at time of analysis.
Mailu, an open-source mail server distributed as a set of Docker images, contains an authorization flaw that lets an authenticated domain manager reset the password of, or mint an API token for, a higher-privileged account that merely owns a mailbox in a domain they manage - including a global admin or a manager of another domain. Because the vulnerable endpoints are the user edit, password reset, and token creation flows, a successful attack grants full control of the victim account and all of its privileges, escalating a limited domain-manager role into global administrative control; the CVSS 3.1 vector is 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). Exploitation requires valid domain-manager credentials and the specific condition that a higher-privileged user owns a mailbox inside the attacker's managed domain, so single-tenant installs with no delegated domain managers are effectively not exposed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Unauthenticated remote command execution inside containers managed by Dockhand (Finsys) affects all versions prior to 1.0.34: the WebSocket upgrade request for the in-browser terminal endpoint /api/containers/<id>/exec is served without any authentication check, so an attacker who can reach the instance and knows a running container ID can open a raw terminal session and run commands inside that container. No authentication is required (CVSS:3.1/PR:N, CWE-306), and the S:C/C:H/I:H/A:H scoring reflects realistic container-to-host escalation when the target container is privileged or exposes sensitive host mounts such as the Docker socket; exploitation is constrained in practice because the attacker must know or enumerate a specific container ID and the target must have an interactive shell. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, though the pre-auth nature and high EPSS-relevant profile make the issue high priority; a vendor-released patch exists in version 1.0.34.
EnergizeLab's station-middleware (a NestJS-based service distributed as Docker images 1.6.5 through 1.8.2) exposes administrative APIs that perform no role or authorization checks, so any authenticated user holding a valid low-privilege account can read AI provider API keys and modify configuration and object-store contents. Tracked as CWE-862 and rated 9.6 Critical (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) because the flaw lets a low-privileged principal cross a security boundary to reach high-confidentiality and high-integrity resources; no availability impact is described. Exploitation requires pre-existing valid credentials plus network reachability to the middleware API - there is no pre-authentication path - and no public exploit code or confirmed active exploitation was identified at time of analysis, and no EPSS data was supplied.
Arbitrary file read in EnergizeLab station-middleware Docker images 1.6.5 through 1.8.2 lets any registered low-privilege account supply a request parameter that the backend treats as a file path, resolving it without adequate restriction and returning files from outside the intended directories, which can expose middleware source, configuration and server secrets. Exploitation is remote and authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N in our independent assessment) and is confined to the listed Docker image versions; the CNA-published score of 9.9 (with scope change plus high integrity and availability impact) conflicts with our read-only impact assessment and should be reconciled before treating this as a top-tier emergency. No CISA KEV entry is present in the supplied data and no public exploit was identified at time of analysis, although the reference set includes a GitHub repository link that may contain a demonstration. Exposure risk is highest where container images carry secrets, tokens, or private keys on a filesystem reachable by the middleware process.
Denial of service in Lychee before 7.7.0 allows an authenticated user with upload/import permission to tie up image-processing capacity by submitting a tiny PDF whose first page declares an oversized /MediaBox. Lychee hands PDFs to ImageMagick with Ghostscript enabled and applies no pre-render page-size check in ImagickHandler::loadPdf(), so Ghostscript burns CPU rasterizing an enormous page before the pixel-cache policy rejects the result; in synchronous QUEUE_CONNECTION deployments a single request occupies a web worker, while the official asynchronous Docker setup instead backs up the shared image-processing queue and delays other users' work. Exploitation is gated behind authentication, only availability is affected (no confidentiality, integrity, or Ghostscript sandbox-escape impact), and no public exploit was identified at time of analysis. The vendor/CNA scored this 7.1 under CVSS 4.0, whereas the independent assessment rates the same issue CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L (4.3), reflecting limited per-request availability impact.
Command injection in Dokku before 0.38.25 allows a user with authenticated app-level Dokku access and remote SSH access to store shell-substitution payloads through the docker-options plugin, and also via dokku run -e/--env values and --ttl-seconds; on the next build, deploy, or run, Bash eval interprets the stored value and executes arbitrary commands as the dokku OS user. Exploitation is privilege-gated, requiring valid app-level credentials and SSH access rather than being remote-unauthenticated, and no public exploit was identified at time of analysis despite the CVSS 9.0 severity.
Finsys Dockhand before 1.0.43 turns authenticated stack-template submission into a server-side data-theft primitive: an attacker-supplied repository URL or stackfile value is fetched by the server and the fetched body is echoed back in the compose response field, so internal services and cloud instance-metadata endpoints can be read directly rather than probed blindly. Any holder of a valid Dockhand account with the ability to create or submit stack templates to the API compose endpoint can exploit this, and the impact grows sharply where the instance has reachable IMDS or sensitive internal services on its network. No public exploit code was identified at time of analysis, and the vendor has released version 1.0.43 as the fix; the 8.4 score reflects high confidentiality impact tempered by the requirement for an authenticated account.
Incorrect privilege assignment in Docker Hub's account-to-organization conversion feature lets an authenticated user bind a personal access token they control to a different Docker Hub account without the token secret ever being rotated or revoked. The unchanged PAT then continues to authenticate successfully - now as the recipient user - granting pull, push, and delete operations, within its existing scopes, across every repository that user can access, including organization repositories. Docker rates this 9.4 under CVSS 4.0 and our independent assessment characterizes it as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, but exploitation is not unauthenticated: the attacker must already hold a valid Docker Hub account and a PAT, and the damage is bounded by that token's scopes; no public exploit code has been identified at time of analysis.
Unauthenticated remote attackers can obtain another client's PHP session identifier from FrankenPHP worker mode before 1.12.5 when the session extension is loaded as a shared module rather than statically compiled in. Because frankenphp_reset_session_state() is compiled out under that build configuration, PS(id) persists across request boundaries on the same worker thread, so a later session_start() may keep a stale identifier instead of adopting the new request's cookie, and under concurrent requests session_id() can return a different user's identifier - enabling information disclosure, session hijacking, and intermittent logouts, with integrity and availability also impacted (CVSS 7.7, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L, CWE-362). Exposure is conditional: official static binaries and Docker images that link the session extension statically are not affected, non-worker (classic) mode is not implicated, and the leak is intermittent and timing-dependent; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated users of Nginx UI (0xJacky/Nginx-UI) prior to 2.4.1 can bypass the built-in nginx directive validation and write arbitrary nginx configuration through the MCP tool nginx_config_add, which reloads nginx with the injected directives. Where nginx is built with the njs or perl module (as in the official Docker image), an attacker - or an MCP-enabled AI agent steered by prompt injection - can achieve code execution on the nginx host with the privileges of the nginx worker process. The CVSS score of 8.8 reflects a network-reachable, low-complexity path requiring only authenticated MCP access (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), making this a credible, actionable priority rather than a paper-high CVSS; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing).
Authenticated users of Blinko through version 1.8.8 can achieve remote code execution as root by supplying a plugin name containing '../' sequences to the plugin.installPlugin tRPC procedure, which constructs the install path from the unsanitized name and writes downloaded plugin files outside the plugins directory. Because the official Docker image runs as root, an attacker can overwrite a root-owned startup file and gain code execution at the highest privilege level; the endpoint is open to any authenticated account and the referenced sign-in code indicates self-registration may be enabled, potentially letting an unauthenticated outsider obtain the required account. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8), reflecting a genuine high-priority issue rather than a CVSS-inflated paper risk; no confirmed active exploitation is indicated by CISA KEV, though the references include a public repository dedicated to this path-traversal RCE chain that should be treated as potential exploit material.
Unauthenticated remote attackers can achieve full administrative control of self-hosted Agnai instances (versions through 1.0.555) deployed with the default self-host.docker-compose.yml, which contains a hard-coded admin password and a public JWT secret. Attackers can log in as admin or forge a JWT with admin privileges to impersonate users, reset passwords, and modify server configuration. This critical vulnerability (CVSS 9.3) requires no user interaction and no prior authentication, but exploitation is limited to instances that have not overridden the default credentials and are network-reachable. No public exploit code has been identified at the time of analysis, though the hard-coded secrets are publicly visible in the repository.
Remote unauthenticated attackers can gain full administrative control of openPDC deployments provisioned from the official published Docker image, because that image embeds a fixed administrative credential that is not forced to change on first use. Exploitation requires only network reachability to the management interface and retention of the default credential; source-built or manually provisioned instances that set their own credentials are not affected. No public exploit code has been identified at time of analysis, though the vulnerable condition is inherent to the image and the CVSS 4.0 base score is 9.3, highlighting the severity for exposed deployments.
Docker Desktop for Windows versions prior to 4.92.0 fail to verify the cryptographic signature of packages supplied via the 'Docker Desktop Installer.exe install -package' command-line option. An attacker who can place a crafted package on the target host and convince a user to approve the Docker-signed UAC elevation prompt can execute arbitrary installer actions as LocalSystem, achieving full system compromise. Although the CVSS 4.0 base score is 7.3 (HIGH), exploitation is constrained: it is a local attack requiring an existing low-privileged foothold and active user interaction; no public exploit code has been identified at time of analysis, and the vendor has released a patch in 4.92.0.
Unauthenticated path traversal in the Ollama `/api/pull` endpoint lets a remote attacker write an arbitrary file outside the model store by submitting a crafted path-traversal sequence in the layer digest field, because the `digestToPath` function does not adequately validate digests before constructing a filesystem path. When the Ollama process can write to `/usr/lib/ollama` (described as the default in most Ollama Docker images) and the server or container is subsequently restarted, the planted binary is loaded and executed, yielding remote code execution as root; the same file-write primitive is available without authentication to anyone who can reach the API. The issue is fixed in Ollama 0.35.0, no public exploit code has been identified at time of analysis, CISA's SSVC assessment records exploitation as 'none', and no EPSS score was supplied in the source data. Real-world risk is high but conditional: exploitation of the full RCE chain depends on write access to `/usr/lib/ollama` and a restart, so deployments not using the default Docker image, running Ollama as a non-privileged user without write access to that directory, or not exposing the API to untrusted networks face substantially reduced exposure.
Python code injection in PraisonAI's deploy tooling (all versions up to and including 4.6.77) lets a high-privileged actor who controls the `agents_file` value break out of an f-string and execute arbitrary code on the host running the deploy command. The flaw is triggered at build/deploy time: the unsanitized value is interpolated into generated server or Dockerfile source in `deploy/api.py` and `deploy/docker.py`, written to disk, and then launched via `subprocess.Popen(['python', server_file])`, so the primary realistic exposure is CI/CD pipelines or shared build environments where `agents_file` originates from externally influenced configuration. The vendor advisory includes a proof-of-concept demonstrating the string-breakout payload and a fix is available in 4.6.78; no CISA KEV entry or other confirmation of active exploitation was present in the source data, and this is not a remotely reachable flaw in a default running service - exploitation requires the attacker to already be positioned to set or tamper with deploy-time input and for someone to invoke the deploy command.
Cross-tenant information disclosure in wger allows an authenticated trainer account that holds both the gym.gym_trainer and gym.add_adminusernote permissions but has no gym assignment (userprofile.gym = None) to read private admin notes, uploaded documents, gym contracts, user configuration and permission data belonging to any other unassigned (gym = None) user on the same instance. The root cause is an authorization guard that fails open: the five affected views compare gym objects with the Python operator '!=', and 'None != None' evaluates to False, so HttpResponseForbidden is never reached and the following queryset is filtered only by the attacker-supplied member_id. Rated CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, authenticated, low privilege), the bug is amplified because gym = None is the default state for newly registered users, so any instance with public registration plus delegated trainer permissions is exposed; a detailed proof-of-concept is documented in the published GitHub advisory and the permission-edit endpoint is also reachable, giving a possible privilege-escalation path, though no confirmed in-the-wild exploitation has been reported.
Unauthenticated remote attackers can forge Django-signed session cookies, CSRF tokens, and password-reset tokens, and bypass live-service authentication, against Plane installations that shipped with publicly known default secrets. Plane versions prior to 1.4.0 distributed fixed SECRET_KEY (60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5) and LIVE_SERVER_SECRET_KEY (htbqvBJAgpm9bzvf3r4urJer0ENReatceh) values in the deployments/aio/community/ and deployments/cli/community/ manifests, while the top-level setup.sh randomized secrets only for the development Docker Compose path, leaving AIO and CLI community deployments with shared production secrets by default. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, C/I/A:H) and classified CWE-798; no public exploit identified at time of analysis, although the default key values are published in the vendor repository and are therefore trivially usable by anyone who reads it. Exposure is limited to network-reachable instances deployed via those community manifests whose operators never overrode the secrets; deployments created through the development Compose path, operator-hardened installs with unique secrets, and instances upgraded to 1.4.0 are not exploitable.
Workflow-controlled container options in Gitea act_runner let an authenticated user who can trigger a job escape the job container into the runner host, because HostConfig fields such as PidMode=host, IpcMode=host, CapAdd=[ALL] and unconfined seccomp/AppArmor profiles survive the runner's sanitization pass and a job step can then use nsenter to execute commands as root on the host. The flaw specifically defeats the 'runner privileged mode disabled' hardening control, which only forces Privileged=false while sanitizeConfig() filters nothing but Binds and Mounts, so default Docker-backed configurations are affected below v3.0.0 (Go module gitea.com/gitea/runner < 1.0.9-0.20260731160927-34bfa1915022). Publicly available exploit code exists in the form of the advisory's minimal proof-of-concept workflow YAML, but no CISA KEV listing or confirmed active exploitation has been reported; impact scales with tenancy, being critical for shared runners accepting untrusted workflow submissions and lower for single-tenant runners restricted to trusted maintainers.
Command injection in the Nx `@nx/docker` release pipeline (nx 21.4.0 through 22.7.7 and 23.0.0 through 23.1.0) lets an attacker who can influence `release.docker.repositoryName` or `registryUrl` in repository configuration execute arbitrary shell commands with the privileges of the release job. Because the plugin builds `docker tag`, image-lookup, and `docker push` calls as shell strings passed to `/bin/sh -c`, a malicious pull request or config change that reaches a `nx release version` or `nx release publish` run can exfiltrate registry credentials and cloud tokens; dry-run publishing does NOT prevent the vulnerable image-lookup pre-check from firing. This is a genuine but conditional CI/CD supply-chain risk rather than a drive-by remote exploit, and no public exploit code or confirmed active exploitation was identified at time of analysis.
In Tugtainer versions before 1.31.3, the OIDC login flow accepts unverified JWT claims from the identity provider's id_token, allowing an unauthenticated remote attacker who can influence the token exchange to impersonate any identity and gain full control of the Tugtainer session. The flaw is a pre-authentication authentication bypass (CWE-347) with high confidentiality, integrity, and availability impact once triggered; exploitation requires OIDC to be configured and enabled. No public exploit has been identified at the time of analysis, and the issue is not listed in CISA KEV. A vendor patch is available in version 1.31.3.
Authenticated server-side request forgery in Tugtainer before version 1.30.6 allows any logged-in user with access to notification settings to make the backend send outbound HTTP requests to attacker-chosen URLs through the /settings/test_notification endpoint, reaching localhost, RFC1918 ranges, and cloud metadata addresses such as 169.254.169.254. The urls field is passed directly to the Apprise notification library with no scheme, hostname, private-IP, or metadata filtering in the default configuration, and because responses are not returned to the caller the attack is blind, which limits it to internal port scanning, service probing, and indirect information inference rather than straightforward data exfiltration. Our independent assessment agrees with the SSRF class and the authentication prerequisite (PR:L) but rates the CIA impact lower (C:L/I:L/A:L) than the vendor's 9.1 scoring, so the practical severity sits below the headline score; vendor-released patch: 1.30.6, and no public exploit identified at time of analysis, with no CISA KEV listing.
Unauthenticated attackers can reach the Tugtainer Agent's Docker management API and gain effectively full control over containers and the underlying Docker host, because the agent's request-signature check in agent/auth.py returns success whenever Config.AGENT_SECRET is left empty - which is the shipped default. All Tugtainer versions prior to 1.30.4 are affected (CPE cpe:2.3:a:quenary:tugtainer with a wildcard version), though exploitation requires the agent's port (default 127.0.0.1:8001) to be network-reachable, meaning deployments that place the agent on a separate host or otherwise expose it without setting a secret are the realistic victims; deployments that keep the agent internal or set AGENT_SECRET are not reachable. The CVSS 3.1 score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis, and the issue is fixed in vendor release 1.30.4, which rejects such requests with HTTP 401.
Improper access control in Tugtainer before version 1.30.3 causes the OIDC login flow to start even when OIDC_ENABLED=false, so a direct request to /auth/oidc/login still returns HTTP 302, sets an oidc_state cookie, and redirects the browser to the configured OIDC authorization endpoint despite the disable switch. The vendor scores this 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), but real-world impact is narrower than that score implies: exploitation requires a deployment where OIDC was fully configured (well_known_url, client ID/secret, authorization endpoint) and then toggled off, and the attacker must still complete authentication against that external identity provider to turn the initiated flow into a session. No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in Tugtainer 1.30.3.
Authentication bypass in Dockhand before 1.0.40 allows unauthenticated remote attackers to force redeployments of git-backed stacks by sending unsigned webhook requests when a stack's webhook secret is null or unset; the guard fails open and accepts the request. The immediate impact is denial of service through repeated git clone and docker compose operations, while full host compromise is possible only if the attacker also has write access to the tracked git branch to inject a malicious docker-compose.yml with privileged bind mounts. No public exploit identified at time of analysis, and the independent assessment rates exploitation complexity as high for the RCE chain, with the DoS path requiring only network reachability and stack ID enumeration.
Local privilege escalation in the npm package adm-zip through version 0.6.0: when an application extracts an archive with the non-default keepOriginalPermission=true option, the library copies the Unix permission bits recorded in each zip entry's external file attributes straight to disk via fs.chmodSync() without stripping the setuid (0o4000), setgid (0o2000) or sticky (0o1000) bits. An attacker who can supply a zip - no special access needed to craft one - can therefore plant a 04755 root-owned binary whenever the extraction runs as root (the common Docker-build, CI-runner and privileged-install posture where this flag is used), and the attacker's code executes as root once a lower-privileged user later runs that file. The issue is correctly rated Medium despite a 7.1 CVSS score because it is highly conditional (flag enabled, root extraction, setuid file preserved and executed by another user); confirmed actively exploited: no - not in CISA KEV - but a working proof-of-concept (a Python-crafted zip with external_attr 0o4755 << 16) is documented in the vendor advisory. Default usage with the flag off, or extraction as a non-root user, is not exploitable.
CRLF injection in psyb0t/docker-mailbox before 0.4.13 allows a remote unauthenticated attacker to append arbitrary IMAP commands to the service's already-authenticated upstream mailbox connection when bearer-token authentication is not configured. Attacker-controlled folder, UID, or search values are passed into IMAP command construction without neutralization, yielding high integrity and availability impact on the mail store; the exposed path only exists on instances deployed without bearer-token auth, and no public exploit has been identified at time of analysis. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects a network-reachable, low-complexity, no-interaction flaw, though real-world risk is constrained by the non-default configuration requirement and the project's very small deployment base.
Arbitrary code execution on an operator's workstation is achievable through kube-compare when it processes a 'container://' reference path pointing at an untrusted container image, because the tool launches that image's entrypoint instead of only reading data out of a stopped container. Exploitation is locally scoped and gated: per the assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, an unauthenticated (PR:N) attacker must convince the operator to invoke the tool against the malicious reference (UI:R), so the victim's own action is the trigger. This is a genuine but conditionally-gated risk - escalation to full root-mediated impact occurs only where the local Docker daemon runs with elevated privileges - and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis; EPSS data was not supplied. The tool is distributed in Red Hat OpenShift Container Platform 4 and the 'Pen Drive Powered by Red Hat Lightspeed' offering.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allowing unauthenticated attackers who can reach that port to take full Owner/Admin control of the Obot API and UI. Because every request is mapped to a synthetic 'nobody' user that already holds Owner and Admin roles, an attacker can register and launch attacker-controlled MCP servers, and since the quickstart also mounts /var/run/docker.sock into the container, that control extends to the host's Docker daemon. All versions through commit d7e6970 are affected; the vendor fix is documentation-only (the quickstart now enables authentication), no public exploit code has been identified at time of analysis, and instances are safe only if the operator set OBOT_SERVER_ENABLE_AUTHENTICATION=true or kept port 8080 off untrusted networks.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Node-wide denial of service in RabbitMQ server 4.1.0 through 4.1.10, 4.2.0 through 4.2.8, and 4.3.0 through 4.3.2 occurs when the non-default rabbitmq_stream_management plugin is enabled: an authenticated management-UI user with access to the target vhost - but no configure, write, or read permission on the resulting streams - can issue a single PUT to /api/stream/super-streams/{vhost}/{name} whose binding-keys field is expanded into the full stream-name list before any resource permission check, forcing a large transient allocation. The advisory demonstrates one ~4.5 MB JSON PUT killing a RabbitMQ container capped at 768 MB, so effective denial of service is strongly dependent on a low memory ceiling; on hosts with ample memory the impact degrades to a temporary resource spike rather than a guaranteed crash. No exploitation in the wild has been confirmed and no public exploit code was identified at time of analysis, but the low privilege bar (any valid management credentials with vhost access) and high availability impact make it a realistic insider or compromised-credential risk for constrained deployments. The issue is fixed in RabbitMQ 4.3.3, 4.2.9, and 4.1.11.
Command injection in Dokploy before 0.29.13 lets an authenticated organization member with service:read permission execute arbitrary commands as root inside the Dokploy container by injecting shell metacharacters into the repoPath parameter of the patch.readRepoDirectories tRPC procedure. Because the standard deployment mounts /var/run/docker.sock, successful exploitation can pivot to control Docker and compromise the host and its managed applications; the vendor fix is available in 0.29.13, and no public exploit identified at time of analysis. The vulnerability is rated CVSS 9.9 with scope change and high confidentiality, integrity, and availability impact.
Frigate NVR deployments prior to 0.18.0 ship an nginx configuration that routes the prefix-matched location /api/go2rtc/api to the internal go2rtc API behind authentication but without an administrator role check, so any authenticated user holding only a low-privilege 'viewer' account can issue GET requests to that path and read proxied go2rtc data. Reachable subpaths (streams, config, log, stack) disclose internal network addresses, configuration file paths, application logs, goroutine stack traces, and RTSP stream URLs that may embed camera credentials; the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7) reflects remote, authenticated, read-only disclosure with changed scope, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis. This is a genuine but bounded confidentiality issue: non-GET methods are rejected by limit_except GET, so no modification or lateral write is possible, the impact is contingent on RTSP URLs actually containing embedded camera credentials, and instances already upgraded to 0.18.0 are not affected. Authentication requirements are confirmed as authenticated by the CVSS vector (PR:L); unauthenticated attackers and administrators are outside the stated prerequisite set.
Authorization bypass in Tinyauth releases prior to 5.1.2 allows an authenticated, low-privilege user to reach applications whose per-app access controls are configured to exclude them. Tinyauth matches forwarded hostnames case-sensitively in lookupStaticACLs/GetAccessControls and in the Docker-label fallback (GetLabels), while nginx, Traefik, and Caddy route hostnames case-insensitively; requesting the target app with a differently-cased hostname therefore misses the configured policy, returns an empty access-control object, and proxyHandler treats the empty user/group/OAuth/LDAP/IP restrictions as permissive. Exploitation requires valid low-privilege credentials (CVSS PR:L) and a deployment that enforces per-app ACLs behind a case-insensitive proxy; unauthenticated visitors are still stopped at login and global login-time allowlists are not bypassed. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released fix is version 5.1.2.
Authentication bypass in Mailu 2.0 through 2024.06.55 and Mailu helm-charts before 2.7.3 allows unauthenticated remote attackers to spoof the trusted proxy identity via a client-controlled X-Forwarded-By header, bypassing header-based proxy authentication. This affects only deployments with PROXY_AUTH_WHITELIST configured and REAL_IP_HEADER unset; default configurations are not vulnerable. The vendor has released fixes in Mailu 2024.06.55 and helm-charts 2.7.3, and no public exploit has been identified at time of analysis.
Malicious or compromised Model Context Protocol (MCP) server containers run under ToolHive CLI before 0.30.1 or ToolHive Studio before 0.38.0 are not network-isolated by default, allowing them to reach Docker gateway addresses (host.docker.internal, gateway.docker.internal, 172.17.0.1) and, critically, ToolHive's own API and MCP proxy endpoints, which are reachable without authentication (CVSS vector PR:N). A hostile MCP server can therefore read exposed data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services without ever escaping the container, with the scope change (S:C) reflecting a pivot from the container into the ToolHive control plane; exploitation requires user interaction because an operator must choose to run the untrusted server (UI:R). The vendor rates this 8.8 (High/Critical); no public exploit code was identified at time of analysis and the issue is not in CISA KEV, though the impact is severe for anyone running third-party MCP servers on Docker with default settings. Fixes are available in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, which flip network isolation to enabled by default.
Code injection into the quay-builder-qemu release workflow through supply-chain compromise of the third-party GitHub Action `Noelware/docker-manifest-action`, which the workflow references by a mutable branch instead of a pinned immutable commit SHA. An attacker who first subverts that upstream action can execute arbitrary code inside the release pipeline, exfiltrating sensitive registry credentials or publishing malicious container images, with severity amplified because the workflow also exposes the default GITHUB_TOKEN. This is a CI/CD build-pipeline flaw rather than a defect in deployed Quay instances and is not directly exploitable against Quay itself; no public exploit code was identified at time of analysis, and the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H reflects high attack complexity because successful exploitation depends on first compromising an external dependency and only triggers when the release workflow executes.
Authenticated users who hold only the read-only startup.read permission on a Pelican Panel server can escalate that access into remote command execution inside the managed container, because write protection for startup settings is enforced solely through disabled client-side form controls rather than a server-side authorization check. By pushing crafted Livewire state updates, the attacker triggers afterStateUpdated callbacks that rewrite startup commands, Docker images and variables, and those values are then executed when the container starts. All Pelican Panel deployments below 1.0.0-beta35 are affected; exploitation needs a low-privileged panel account scoped to the target server, no victim interaction, and reachability of the panel's Livewire endpoint. A vendor patch is available in 1.0.0-beta35, no public exploit code has been identified, and the issue is not listed in CISA KEV at time of analysis.
Authenticated users on Harness deployments through version 3.3.0 can read infrastructure provider configurations from spaces they do not belong to, because the GET /api/v1/infraproviders endpoint fails to validate space-level access control (CWE-862). Exploitation requires only a valid low-privilege account (CVSS v4.0 PR:L, and the independent assessment rates it PR:L as well), so it is realistic mainly on multi-tenant or multi-space instances where the attacker's account lives in a different space than the targeted provider records; a single-tenant instance with no untrusted users has limited exposure. The result is a confidentiality-only impact (VC:H, no integrity or availability effect) exposing sensitive provider metadata such as Docker endpoints, TLS certificate paths, and cloud project identifiers. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV). Note: the supplied CVSS v4.0 base score of 7.1 and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) agree on the authenticated, network-reachable, read-only nature of the flaw.
Unauthenticated path traversal in the @zereight/mcp-gitlab Model Context Protocol server prior to version 2.1.27 allows any network-reachable attacker to read arbitrary files from the server host and exfiltrate their contents into an attacker-accessible GitLab project upload, enabling theft of the server's GITLAB_PERSONAL_ACCESS_TOKEN from /proc/self/environ and resulting in full GitLab account takeover. The exposure exists in SSE transport mode (SSE=true), which the advisory states is the default configuration for Docker deployments and which serves all MCP tools without any authentication; the assessed severity is CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). No public exploit code and no CISA KEV entry were identified at time of analysis, but the attack requires only network access to the exposed SSE port and a single call to the upload_markdown tool.
Docker Sandboxes 0.37.0 through 0.40.x contain a time-of-check/time-of-use race (CWE-367) in the guest-to-host Unix-domain socket relay: the host validates that a requested socket path sits inside an authorized workspace and then reconnects using that same pathname, letting a malicious guest swap an intermediate directory for a symlink in the gap. A guest that wins the race causes the host-side relay to connect to an arbitrary AF_UNIX socket outside the shared workspace, exposing whatever data or host capabilities that socket provides. Vendor-released fix: Docker Sandboxes 0.41.0; no public exploit code or CISA KEV entry was identified at time of analysis.
Flowise releases prior to 3.1.4 ship GitHub Actions workflows that interpolate workflow_dispatch inputs such as tag_version and node_version directly into shell run blocks, allowing OS command injection during Docker image builds. The flaw is reachable only by a user who already holds write access to the repository (CVSS 4.0 PR:H), but the payoff is large: arbitrary command execution on the build runner with access to AWS credentials and Docker Hub tokens. No public exploit code or CISA KEV entry was reported at time of analysis, and the vendor has published a fix in 3.1.4 via GitHub Security Advisory GHSA-jrcq-qjw5-xx5q; note that this is a supply-chain/CI risk to the project's own build pipeline and to forks that reuse these workflows, not a runtime flaw in deployed Flowise instances.
Sandbox escape in Docker Sandboxes on macOS (0.28.0 through 0.41.x) lets a workload running inside a sandbox break out of its shared workspace and read or modify arbitrary files on the host as the VMM user, with host code execution possible where the reachable files are executable or otherwise privileged. The virtio-fs host server follows symlinks when reopening an unlinked file from a stored path, so a guest that replaces a parent directory of a workspace file with a symlink can redirect host-side file operations outside the workspace bind mount. Exploitation requires the attacker to already control a guest workload (for example an untrusted agent or repository), is macOS-specific, and depends on winning a directory-swap timing race; SSVC records Exploitation: none, and no public exploit code was identified at time of analysis. The raw 9.4 CVSS 4.0 score should be read alongside these preconditions rather than at face value - this is a genuine sandbox escape leading to host compromise, but it is not remotely reachable and is bounded by the privileges of the VMM user rather than root.
Server-side request forgery and root-level code execution in IBM Langflow OSS 1.0.0 through 1.10.0 lets an authenticated user smuggle arbitrary Python through submitted flow components. Because the component validation scanner fails to block socket and urllib imports yet still returns "validated": true, attackers run code as UID=0 to steal AWS credentials via IMDSv1 SSRF, exfiltrate container files, and pivot to internal PostgreSQL and Redis services. Public exploit code exists, though the flaw is not on the CISA KEV list.
Authentication bypass in ESPHome Device Builder (the esphome-device-builder package powering the `dashboard` subcommand of the ghcr.io/esphome/esphome container) versions before 1.0.12 silently disables dashboard authentication on upgrade for operators who had protected it with the legacy bare $USERNAME/$PASSWORD environment variables. A rename to $ESPHOME_USERNAME/$ESPHOME_PASSWORD (PR #265) dropped the old names with no fallback, so `using_password` becomes false and both the REST auth middleware and WebSocket login gate switch off, leaving the dashboard open to anyone who can reach its port. Because a compromised dashboard caller can compile arbitrary code and read/write config and data directories, this is effectively unauthenticated RCE; publicly available exploit/PoC code exists, though it is not in CISA KEV (SSVC exploitation: none).
LangBot's debug WebSocket server binds to all interfaces on port 5401 and ships with an empty authentication key by default - and the official Docker image together with its docker-compose configuration publish that port to the host, placing every default deployment within reach of any network attacker. A remote unauthenticated attacker who reaches the /plugin/ws endpoint can register an arbitrary debug plugin, after which LangBot broadcasts the full plaintext context of every inbound IM message event to that plugin, enabling mass interception of private chats, forged bot replies, LLM pipeline poisoning via malicious tool registration, knowledge-base enumeration, and persistent denial of service by blocking legitimate plugin installations with the prod_mode flag. No patched version was available at time of publication; SSVC classifies exploitation as proof-of-concept-available and fully automatable.
Local privilege escalation in Apache Storm Worker Launcher 3.0.0 allows an authenticated Storm topology tenant to gain root on supervisor nodes by exploiting a TOCTOU race in the setuid-root worker-launcher binary: the binary chowns the entire worker directory to the untrusted topology user before re-reading the supervisor-written command file, creating a window in which the tenant can substitute attacker-controlled content. For Docker workers, the injected command executes with real uid 0 through an insufficiently constrained argument sanitizer that passes -v, --device, --cap-add, --security-opt, --user, --net, and positional arguments verbatim; for OCI workers, arbitrary host paths can be bind-mounted read-write and execution can be forced as another tenant's uid. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 3.1.0.
OS command injection in @argos-ci/core <=6.2.0 allows any attacker who can influence a CI pipeline's branch or ref name to execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process. The vulnerable sink is in packages/core/src/ci-environment/git.ts:89, where execSync() receives an unsanitized branch string interpolated into a template literal passed directly to /bin/sh -c, which evaluates $() command substitution and other metacharacters before spawning git. A fully working proof-of-concept exploit exists (GHSA-4x45-gxvp-6283) and the attack surface is widened by the fact that hasRemoteContentAccess: false - the configuration that triggers the vulnerable code path - is the default for projects without a connected Git provider integration.
Command injection in Renovate's Maven Wrapper manager allows an attacker with write access to a scanned repository to execute arbitrary OS commands on the host running Renovate when `binarySource=docker` mode is active. Unescaped `distributionType` values from `maven-wrapper.properties` are passed directly to a shell, giving the attacker full code execution in the Renovate process context. No public exploit or CISA KEV listing exists at time of analysis; vendor-released patch is available at version 44.14.7.
Command injection in Renovate's Mix package manager allows an attacker who can control private dependency package names to execute arbitrary OS commands as the Renovate process user. Versions before 44.14.7 fail to escape organization parameters before passing them to shell commands during dependency resolution in binarySource=docker mode. No public exploit code has been identified at time of analysis, but the attack surface is reachable whenever Renovate processes Elixir/Mix private dependencies under the affected configuration.
Credential exfiltration in Renovate (renovatebot/renovate) before 44.11.2 lets a malicious or compromised container registry steal the registry credentials Renovate holds. When enumerating container image tags/digests, Renovate follows an HTTP Link header pagination URL and re-attaches the original registry's credentials without checking that the follow-up URL shares the same origin (CWE-601 open redirect), so a hostile registry can redirect the authenticated request to an attacker-controlled host and capture the secrets. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not in CISA KEV.
Command injection in Renovate's Gradle Wrapper manager module allows a repository contributor to execute arbitrary OS commands on self-hosted Renovate instances. Open-source versions before 44.14.7 and Mend Renovate CE/EE before 15.4.0 fail to escape the `distributionUrl` value read from a repository-controlled `gradle/wrapper/gradle-wrapper.properties` file before passing it to the Gradle Wrapper CLI, enabling shell metacharacter injection. Exploitation is constrained to self-hosted deployments explicitly configured with `binarySource=docker` and `gradleWrapper` in `allowedUnsafeExecutions`; no public exploit code or active exploitation has been identified at time of analysis.
Command injection in Renovate's gomod manager (before 44.14.7) exposes CI/CD pipelines to arbitrary shell command execution as the Renovate user when a maliciously crafted Go module dependency name containing shell metacharacters is processed. The flaw is exercised only under two simultaneously required non-default configurations - `binarySource=docker` mode and `postUpdateOptions gomodUpdateImportPaths` enabled - confining exposure to a specific subset of Renovate deployments performing Go module major version updates. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Path traversal in @openhop/server (npm, versions ≤0.3.5) allows unauthenticated remote attackers to read or permanently delete arbitrary `.yaml` files accessible to the OpenHop process outside its configured flow data directory. The root cause is that `FlowStore.filePath()` passes caller-supplied HTTP route parameters directly to Node.js `path.join()` without any sanitization or allowlist validation, and Fastify's underlying `find-my-way` router URL-decodes the parameter before it reaches application code, enabling `..%2F`-encoded directory traversal. A fully functional PoC is publicly available with Docker-based reproduction steps; no KEV listing at time of analysis. Docker deployments expose the server on all interfaces by default, enabling direct network exploitation without user interaction.
Unauthenticated LAN access to the ESPHome Device Builder dashboard on Home Assistant add-on deployments allows any device on the local network to gain host-equivalent control with no credentials. The ingress site, which deliberately skips authentication because the HA supervisor is supposed to authenticate upstream, was bound to 0.0.0.0 instead of loopback and the supervisor gateway. Because the add-on uses host networking for mDNS, this exposed the no-auth site on the host's LAN interface, directly bypassing the supervisor's authentication layer. An attacker with LAN access can run arbitrary Python via external_components at compile time, execute arbitrary shell through compile/validation subprocesses, and read or write arbitrary files in the config and data directories. No public exploit has been identified at time of analysis.
Remote code execution in functype-mcp-server 1.4.3 and earlier allows any MCP client - including an LLM agent manipulated via prompt injection - to execute arbitrary JavaScript in the server process by invoking the `set_functype_version` tool with a `file:`, `git+`, or URL package-alias as the version string. The server interpolates the unsanitized input directly into a `pnpm add` specifier, installs the attacker-controlled package as the `functype` alias, then immediately dynamic-imports `functype/cli` from the poisoned location, running module-level attacker code with full MCP server process privileges. A fully automated Docker-based proof-of-concept confirming end-to-end RCE is documented in GHSA-wcjj-9m6g-2fr2; no public exploitation has been confirmed (not in CISA KEV), and a patched version 1.4.4 is available.
nuxt-ollama versions 1.2.26 through 1.3.0 unconditionally places the Ollama cloud API key into Nuxt's public runtime config, causing it to appear verbatim in every server-rendered HTML page inside the `window.__NUXT__` script block, readable by any unauthenticated HTTP client. Any visitor or web crawler that fetches any page of an affected application can extract the `api_key` from the serialized SSR payload with a single GET request, then impersonate the operator against the Ollama cloud API to incur billing charges, exhaust rate limits, or exfiltrate stored model data. A publicly available PoC using Docker and Python has dynamically confirmed the leak; no public exploit identified at time of analysis for active KEV-level exploitation.
Administrative takeover of the Eclipse aeriOS Identity Manager (IdM) is possible because the current development-version deployment exposes its Keycloak server and PostgreSQL backing database to the network (Kubernetes NodePort services, and PostgreSQL bound to all interfaces under Docker Compose) while shipping fixed, publicly documented default credentials for the Keycloak admin and the PostgreSQL user. An attacker who can reach these services logs in with the published defaults to read or modify identity data - users, roles, client credentials, sessions, and cryptographic material - and can mint privileged identities or tokens trusted by other aeriOS components. No official release exists yet; there is no CISA KEV listing and no public exploit identified at time of analysis, though the credentials are effectively public in the source repository.
Local privilege escalation to root in Dell Secure Connect Gateway (SCG) 5.0 lets a low-privileged operator with SSH access to the appliance host obtain full root control without a password by abusing the exposed Docker socket (CWE-250, Execution with Unnecessary Privileges). Affected builds are the SCG Appliance prior to 5.36.00.16 and the SCG Application prior to 5.36.00.00. The same socket exposure also enables container escape: an attacker who compromises any service inside the orchestrator container can break out to host-level control. No public exploit is identified at time of analysis and it is not listed in CISA KEV, but the technique (writable/accessible Docker socket) is a well-known and reliable escalation path.
Bifrost HTTP transport before version 2.0.0 exposes an unauthenticated plugin installation endpoint (POST /api/plugins) that accepts HTTP URLs as plugin paths, enabling SSRF on all build types and unauthenticated remote code execution on dynamically linked builds. Because management authentication is disabled by default (governance.auth_config.is_enabled=false), no credentials are required to trigger the flaw; the shared-object loader fetches the attacker-supplied URL, writes it as a temporary .so, and on DYNAMIC=1 builds calls plugin.Open() which immediately executes the plugin's Init() function as the Bifrost process user. Reported by JFrog, the fix ships in transports/v2.0.0, adding an SSRF-safe dial context (SSRFSafeDialContextWithAllowlist) around plugin downloads; no public exploit code or active exploitation has been confirmed at time of analysis.
Unauthenticated session-token forgery in Peppermint (an open-source self-hosted helpdesk/ticketing platform) versions through 0.5.5 lets any remote attacker impersonate arbitrary users. The application's docker-compose.yml ships a hardcoded JWT signing secret that is public in the project repository, so an attacker who knows the secret can mint valid tokens for any user ID - including administrators - and reach protected API endpoints without credentials. Reported by VulnCheck; no public exploit identified at time of analysis, though the 'exploit' is trivially the published secret itself.
TLS certificate validation is disabled by default in the Federator component of Eclipse aeriOS, enabling man-in-the-middle interception of all outbound HTTPS connections made by the component. Any attacker who can position themselves on the network path between the Federator and external services - including OAuth authorization servers - can impersonate those services and harvest OAuth client credentials and bearer tokens. This affects only the current pre-release development codebase; a source-level fix is confirmed in commit 9c63b60, but no official tagged release exists. No public exploit or CISA KEV listing has been identified at time of analysis.
Incomplete patch for OS command injection in the Nuclio serverless dashboard (local/Docker platform, all versions prior to 1.17.4) leaves the list-all resource code path exploitable by unauthenticated remote attackers. Shell metacharacters injected via the X-Nuclio-Function-Namespace, X-Nuclio-Project-Namespace, or X-Nuclio-Function-Event-Namespace HTTP headers bypass the prior fix and reach a /bin/sh -c invocation in pkg/platform/local/client/store.go unescaped, enabling arbitrary command execution inside the dashboard container. No public exploit has been identified at time of analysis, but the attack surface is network-accessible and requires no authentication, lowering the bar significantly for any attacker already familiar with the previously disclosed injection class (GHSA-jx7q-cpg6-669g).
OS command injection in Nuclio's local Docker platform dashboard allows remote attackers to execute arbitrary shell commands as root inside the dashboard container, which holds the Docker socket, enabling full host compromise. The function namespace value - controllable via the unauthenticated (default 'nop' auth) API - is string-interpolated without quoting into a `docker ps --filter` command executed via `/bin/sh -c`, allowing a double-quote character to break out of the filter token and inject arbitrary commands. The issue is fixed in version 1.17.4, with the patch confirmed via GitHub release tag and PR #4220; no public exploit identified at time of analysis.
Authenticated command injection in Coolify before 4.2.0 allows low-privileged platform users to execute arbitrary OS commands on managed server hosts by embedding shell metacharacters into Docker environment variable key names. The flaw bypasses container isolation entirely - injected payloads travel over SSH as part of Coolify-generated Docker commands and execute in the host OS context, not within any container sandbox. The upstream fix in v4.2.0, confirmed by GitHub release tag and patch commit b50839d4515b115b7ded5db609471440249995da, adds validation constraints in ValidationPatterns.php to reject malformed key names before command construction.
Privilege-escalation-to-RCE in MCPHub before 0.12.15 lets any authenticated low-privileged user reach OS command execution via the POST /api/servers and PUT /api/servers/:name endpoints, which spawn a configured stdio process through child_process.spawn without an admin authorization check or command allowlist. Because command and args are attacker-controlled, a non-admin user can set command to /bin/sh (or any binary) and have MCPHub run it as its own OS user - frequently root in the published Docker image and in npx/systemd deployments. No public exploit identified at time of analysis, though the fixing PR (#770) and GHSA advisory publicly detail the root cause.
phpSysInfo up to and including version 3.4.5 exposes a complete IP allowlist bypass in read_config.php that any unauthenticated remote attacker can exploit by sending a spoofed X-Forwarded-For or Client-IP HTTP header set to any address present in the PSI_ALLOWED configuration. The flaw (CWE-290) renders the application's only access-control mechanism entirely ineffective, allowing full retrieval of system telemetry including hostname, kernel version, CPU model, memory layout, filesystems, and network interface addresses. A working proof-of-concept is publicly available on Exploit-DB; no CISA KEV listing exists at time of analysis.
Blind SQL injection in WsgiDAV's MySQLBrowserProvider sample module (versions <= 4.3.4) allows unauthenticated network attackers to read arbitrary data from the backing MySQL database via URL path manipulation. The record key segment of the URL is concatenated directly into a WHERE clause without escaping, enabling a boolean status-code oracle that supports full character-by-character data extraction. A secondary typo in the numeric-type check (`INTT` instead of `INT`) ensures all primary key types take the vulnerable quoted branch, and a working PoC with complete extraction script has been publicly confirmed. No public exploit identified as confirmed actively exploited (CISA KEV), but the PoC lowers the exploitation bar significantly.
NF registration poisoning in free5GC's Network Repository Function (NRF) lets attackers with SBI network access register forged Network Function profiles containing arbitrary, attacker-controlled service endpoint IPs, because the RegisterNFInstance handler performs no field validation against 3GPP TS 29.510. Legitimate NFs (AMF, SMF, AUSF, UDM, PCF, NSSF) then discover the fake profiles via NFDiscover and route control-plane signaling to the attacker, enabling interception, OAuth2 credential harvesting, and denial of service across the entire 5G core service mesh. Publicly available exploit code exists and the vendor has released a patch; the flaw is CWE-20 with a vendor CVSS 4.0 base score of 9.3 (Critical).
Unauthenticated remote code execution in SENAITE.CORE (senaite.core) 2.0.0 through 2.6.0 lets any network-reachable attacker run arbitrary Python in the Zope worker process by chaining a missing authorization check with an eval() sink in the JSON API. The anonymous-reachable /@@API/update route calls eval() on attacker-supplied RecordsField/RecordField values before any permission or write check fires, and a public working PoC (tested against the stock senaite/senaite:v2.6.0 Docker image) demonstrates credential-free command execution. Publicly available exploit code exists; the flaw is not listed in CISA KEV, so there is no confirmation of active exploitation.
Remote code execution in qwed 5.1.1 allows any authenticated tenant to execute arbitrary Python code inside the API server process by submitting crafted mathematical expressions to the POST /verify/math or POST /verify/batch endpoints. User accounts are freely self-registerable via the default-enabled /auth/signup endpoint - no invitation code or administrator approval required - making the effective exploitation barrier nearly equivalent to unauthenticated. A complete, functional proof-of-concept exploit script is publicly available in the GitHub advisory (GHSA-q27q-98j4-9pfv), and a vendor-released patch is available in version 5.1.2.
Arbitrary OS command execution in mcp-shell's default Docker image allows any MCP tool caller to bypass the secure-mode executable allowlist by supplying `/bin/bash -c <payload>` to the `shell_exec` tool, running commands as `mcpuser` (UID 1000) inside the container. The validator in `security.go` extracts only the first whitespace-delimited token as the executable, approves `/bin/bash` against the default allowlist, and passes the `-c` flag through the metacharacter check unchallenged because the default `blocked_patterns` array is empty. A fully working PoC is included in the GitHub Security Advisory GHSA-3x77-wg38-92r3; no public exploit identified at time of analysis beyond the researcher-provided PoC, and no CISA KEV listing exists. Vendor-released patch v0.6.0 is confirmed.
OS command injection in mcp-shell's 'secure mode' allows any MCP client to execute arbitrary shell commands by exploiting Git's runtime alias mechanism. The security validator in security.go blocks common shell metacharacters but omits '!', the prefix Git uses to invoke shell aliases via '-c alias.NAME=!CMD'. Because /usr/bin/git is in the default allowed_executables list and the CVSS PR:N vector confirms no authentication is required, all default Docker deployments (mcpuser, UID 1000, Git pre-installed) are exploitable by any entity with MCP connectivity. A fully functional PoC is published in the GHSA advisory; no CISA KEV listing is present at time of analysis.
Insufficient access control granularity in docker-socket-proxy allows adjacent-network attackers without credentials to read arbitrary files and exfiltrate entire container filesystems via four unguarded Docker API endpoints. When the CONTAINERS environment variable is set, the HAProxy-based proxy fails to block /containers/{id}/archive, /containers/{id}/export, /containers/{id}/logs, and /containers/{id}/top, treating namespace-level permission as blanket endpoint permission. No active exploitation or confirmed public exploit code has been identified at time of analysis, though a researcher gist is referenced alongside the upstream fix in PR #183.
Cross-user memory disclosure and tampering in Headroom's LLM proxy (versions before 0.36.1) lets a caller read or overwrite any user's stored LLM memory by simply naming another user's identifier in the client-supplied x-headroom-user-id request header. The proxy trusts this header as the authenticated identity across the chat-completion and websocket data-plane paths in headroom/proxy/handlers/openai.py, with nothing binding the value to the actual caller. The console script binds loopback by default, but the shipped docker-compose.yml publishes the proxy on 0.0.0.0 with no required proxy token, so a stock Docker deployment exposes these routes to the network unauthenticated. Reported by VulnCheck; no public exploit identified at time of analysis.
Server-side request forgery in Headroom LLM proxy (versions before 0.36.1) allows unauthenticated remote attackers to redirect proxy upstream requests to arbitrary internal, loopback, link-local, or RFC 1918 destinations - including cloud instance metadata endpoints such as 169.254.169.254 - by supplying a crafted x-headroom-base-url request header. The proxy returns upstream responses verbatim to the caller, disclosing internal service content; critically, it also forwards the original Authorization header to the attacker-designated host, enabling credential harvesting. Exploitation is trivially achievable against deployments using the vendor-shipped docker-compose.yml, which binds 0.0.0.0 and enforces no HEADROOM_PROXY_TOKEN by default - a configuration weakness the server itself warns about at startup. No public exploit or KEV listing is identified at time of analysis; a vendor patch is available in v0.36.1.
Missing authorization in the Mailu admin REST API allows unauthenticated remote attackers to strip IP-based access restrictions from any existing user token or alter its comment field, effectively neutralizing a key access-control layer on API tokens. All Mailu deployments running versions prior to 2024.06.52 with the admin REST API explicitly enabled are affected. No public exploit code or CISA KEV listing is identified at time of analysis, though the network-accessible, zero-authentication attack vector (PR:N, AC:L) makes this straightforward to leverage when the API is reachable.
Path traversal in Dockge's stack name handling allows authenticated users to exfiltrate secrets from .env and Compose files belonging to any directory the server process can reach, and to recursively delete those directories. The flaw exists because validate() - which enforces a strict name allowlist - is only called from the save() code path; the socket handlers that service read and delete operations pass the raw user-supplied name directly to Stack.getStack without sanitization. Because Dockge routinely runs as root with access to the Docker socket, the reachable set encompasses the full host filesystem, not just managed stacks. No public exploit has been identified at time of analysis and no CISA KEV listing exists, but the bypass is mechanically trivial for any authenticated user.
Remote denial-of-service in vouch-proxy v0.47.2 and earlier crashes the server process with a single unauthenticated HTTP request. The /validate endpoint's multipart cookie reassembly routine in pkg/cookie/cookie.go parses the total part count directly from the attacker-controlled Cookie header name - an N value of 10 billion passed as VouchCookie_1of10000000000 triggers a make([]string, N) call requesting approximately 160 GB of heap, immediately raising a Go runtime fatal out-of-memory error. No authentication, session token, or prior interaction is required; a fully working PoC with Docker reproduction artifacts is publicly disclosed in the GitHub Security Advisory, though no CISA KEV listing is confirmed at time of analysis.
Path traversal in the MineAdmin app-store plugin service lets any authenticated API user read, install, or uninstall plugins from directories outside the intended plugin folder by supplying traversal sequences (e.g., ../) in the `identifier` parameter of the /admin/plugin/store/download, /install, and /uninstall endpoints. The enabling condition is the absence of PermissionMiddleware on those routes (GM-4340), so exploitation requires only a valid JWT, not administrator privileges - the vendor's CVSS 4.0 vector scores PR:N, but this assessment treats the issue as authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H) because AccessTokenMiddleware still guards the endpoints. Publicly available exploit code exists and the finding was reproduced and validated in a Docker environment; the most severe outcome (code execution) additionally depends on how Plugin::install() invokes composer on the traversed path.
Uncontrolled decompression in Malcolm's upload-processing pipeline allows any authenticated user with upload permissions to exhaust the shared Docker volume by submitting a single-stream compression bomb (.gz, .bz2, .xz, .lzma, .lz). The flaw in scripts/safe-extract.py is a logic gap: entry-count, nesting-depth, and total-uncompressed-byte guards exist for container formats (zip/tar/rar/7z via libarchive) but are entirely absent for single-stream formats, allowing unbounded expansion. Successful exploitation denies service to all platform users simultaneously by starving OpenSearch, Logstash, Arkime, and Zeek of shared disk. No public exploit or CISA KEV listing has been identified at time of analysis; however, the attack is conceptually trivial once the bypass is known.
Tar extraction path traversal in moby/go-archive allows an attacker who controls archive contents to create or overwrite files outside the intended destination directory, undermining container-to-host filesystem boundaries. The affected functions - Unpack, UnpackLayer, Untar, UntarUncompressed, and ApplyLayer - perform lexical path validation but rely on OS-level resolution at operation time, meaning symlinks introduced inside the archive redirect writes to arbitrary paths writable by the extracting process. This flaw propagates through the full Docker ecosystem including Docker Engine, Docker Desktop, Docker CLI, Docker Compose, and Docker Sandboxes; vendor-released patches are available and no public exploit code has been identified at time of analysis.
Denial-of-service in vm2 (Node.js sandbox library) versions 3.11.0-3.11.5 allows sandbox code to bypass the `bufferAllocLimit` DoS mitigation via two unwrapped allocation paths - `Buffer.concat(list, totalLength)` and `Buffer.from({length: N})` - committing unbounded host external memory in a single synchronous C++ call that V8's timeout mechanism cannot interrupt. A publicly available PoC confirms that a 200-byte sandbox payload inflates host RSS by hundreds of megabytes per invocation, making a single crafted request sufficient to OOM-kill a host process running inside a Docker container, Kubernetes pod, or AWS Lambda function. No public exploit identified in CISA KEV at time of analysis, though functional exploit code is embedded in the GHSA advisory itself.
Remote command execution in Flowise <= 3.1.2 lets an authenticated user break out of the vm2/@flowiseai/nodevm JavaScript sandbox by abusing the /api/v1/node-custom-function endpoint. By passing attacker-controlled executablePath and args into puppeteer.launch(), the code reaches child_process.spawn() outside the sandbox, yielding arbitrary OS command execution as the Flowise process user (root in the official Docker image) and host file disclosure via Chromium's file:// handling. No public exploit is identified at time of analysis, but a vendor security advisory (GHSA-9gvv-qjj3-2p6g) and VulnCheck confirm the flaw; the CVSS 4.0 base score is 9.4.
Remote unauthenticated authentication bypass in WolfStack before 25.9.2 lets attackers fully compromise container hosts by supplying a hard-coded cluster secret in the X-WolfStack-Secret header. Because the secret is a compile-time constant published in src/auth/mod.rs, anyone who can reach a node's management port passes the require_auth() gate with no session, API key, or account, and can then enumerate every Docker/LXC container and run arbitrary commands as root inside any of them. No public exploit is identified at time of analysis, but the flaw is trivially reproducible from source and was reported by VulnCheck.
Command injection in stata-mcp (pip:stata-mcp < 1.19.0) enables full OS-level remote code execution against any principal that can invoke the `ado_package_install` MCP tool. The `package` argument is concatenated unsanitized into a Stata command string delivered via pexpect.sendline(), allowing embedded newline characters to inject arbitrary Stata commands - including the `shell` escape - that execute under the account running the MCP server. Because the tool is registered in the default `all` profile and `all` is the active default, no misconfiguration by the victim is required; a detailed proof-of-concept confirmed via Docker reproduction is publicly available in the GitHub advisory, and a vendor-released patch exists in v1.19.0.
URLSecurityValidator SSRF bypass in compliance-trestle <= 4.0.3 allows a network-positioned attacker to reach cloud metadata services, loopback admin interfaces, and RFC 1918 internal networks by embedding IPv4-mapped IPv6 literals (e.g., [::ffff:169.254.169.254]) or the unspecified address 0.0.0.0 in OSCAL artifact import references processed by HTTPSFetcher or SFTPFetcher. Python's ipaddress module silently returns False - rather than raising TypeError - when comparing IPv6Address objects against IPv4Network ranges, so the validator's membership checks pass these forms through to requests.get unchanged. A publicly available proof-of-concept reproduces end-to-end IMDS credential exfiltration; no active exploitation is listed in CISA KEV and EPSS stands at 0.42%.