US-CERT.gov

Overview

Two memory-related vulnerabilities have been identified in PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. An unauthenticated remote attacker with network access to PHP web services can exploit these vulnerabilities via specially crafted HTTP requests to potentially achieve arbitrary code execution.

Description

PHP is a widely used open-source scripting language designed for web development and server-side applications. It powers millions of websites and web applications worldwide and can be deployed through a variety of server configurations, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

CVE-2026-109618: A memory corruption vulnerability exists in the out-of-memory (OOM) handling mechanism of PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The vulnerability occurs when an OOM condition interrupts request processing while internal request data is only partially initialized; subsequent cleanup routines may access the invalid memory, potentially causing memory corruption and enabling arbitrary code execution.

CVE-2026-109619: A use-after-free vulnerability exists in the global state management of PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The vulnerability occurs when a worker retains a reference to request-owned state after its backing memory has been freed. A subsequent request handled by the same worker can access this stale state before normal request initialization resets it, potentially causing memory corruption and enabling arbitrary code execution.

Impact

Successful exploitation of these vulnerabilities allows an unauthenticated attacker to remotely execute arbitrary code via specially crafted HTTP requests, compromising the confidentiality, integrity, and availability of the web service and underlying infrastructure. Apache mod_php deployments are at particularly high risk, as proof-of-concept exploitation has demonstrated that unauthenticated requests can trigger the attack before any application code executes.

Solution

Refer to the Vendor Information section below for newly patched versions of PHP that remediate these vulnerabilities. All PHP users are strongly encouraged to update immediately to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12. Source downloads are available on the official PHP release page at php.net/downloads.

Linux users are advised to check with their distribution vendor for updated packages, as many distributions received patches in advance. For PHP 8.1 and older versions that no longer receive official updates from the PHP project, contact your LTS vendor for backported fixes or upgrade to a supported version. The PHP security team has provided limited source backports for PHP 7.4, PHP 8.0, and PHP 8.1 to assist users building from source or without access to an LTS vendor.

If immediate patching is not feasible, the following temporary mitigation measures may reduce exposure to specific attack paths, though they do not provide complete protection. Because these vulnerabilities are closely related, mitigations for both CVEs should be applied:

For CVE-2026-109618 (OOM Corruption):

• Set memory_limit=-1 at an administrative level so it cannot be overridden by applications, for example via php_admin_value in the FPM pool or Apache configuration.
• Set a low post_max_size (8M for applications without file uploads, 32M if uploads are necessary).
• Keep upload_max_filesize below post_max_size.
• Enforce limits at the web server or proxy level for decoded request-body size, input variable count, multipart part count, header count, and nesting depth.
• Use container or cgroup limits as an availability boundary with policies that kill only the affected worker. Notably, RLIMIT_AS or RLIMIT_DATA should not be used to bound memory, as these cause mmap() to fail once the limit is reached, triggering the vulnerable code path rather than preventing it.

For CVE-2026-109619 (Stale Global State):

• Set session.upload_progress.enabled=0 in php.ini, FPM pool, or server configuration and restart all workers.
• On PHP 8.5, set fatal_error_backtraces=0 and restart all workers.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization.
• Remediate attacker-reachable fatal errors and execution timeouts.

System owners can limit the potential impact of successful exploitation by implementing network segmentation and ensuring that PHP installations are configured to run with minimum necessary privileges. Users are advised to monitor closely for unusual PHP process behavior or unexpected memory allocation patterns.

Acknowledgements

Thanks to OpenAI, Wiz, and Ryan at Calif.io for reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview

An authentication bypass vulnerability in the Xerj Console API allows sessions to bypass passkey-backed requirements during token issuance. By exploiting this flaw, an attacker with an existing valid token can create independent, persistent successor credentials directly through the console API. This allows the attacker to maintain access and potentially escalate privileges within the Xerj ecosystem, even if the initial token is revoked.

Description

Xerj is an open-source search and indexing engine tailored specifically for AI agents utilizing the Elasticsearch API, allowing AI models to query a structured index.

The vulnerability, CVE-2026-97406, stems from a flaw in how session states are authenticated and handled within the Xerj system architecture. According to the documented security contract, the issuance of new API tokens must be strictly authorized by a passkey-backed session. However, the Xerj implementation converts both standard browser sessions and API bearer tokens into the same generic AuthSession object. The token creation handler then accepts this generalized principal without verifying whether the session was authenticated via a passkey.
Because of this architectural oversight, an attacker who obtains or intercepts a valid Xerj API token can directly invoke the token creation endpoint, allowing them to create independent successor credentials with the same access levels of the original token. Furthermore, the Xerj platform lacks hierarchical revocation logic; consequently, revoking a compromised parent token has no effect on any descendant tokens spawned from it.

Impact

Exploiting this vulnerability allows an attacker to gain persistent, unauthorized access that completely bypasses multi-factor controls. The security risk escalates significantly if the compromised token belongs to a Xerj account owner. In this scenario, the newly created successor token retains full administrative authority. An attacker can use this persistent access to issue a new account invitation, redeem it in their own browser, and successfully enroll an entirely independent, attacker-controlled passkey. This grants the attacker permanent control over the Xerj instance and its sensitive data indices, rendering the revocation of the initial token completely ineffective.

Solution

The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project's GitHub repository for updates and install the latest version of this library once a fix has been released.

Acknowledgements

Thanks to the reporter, Shiran Guez, a Principal Application Security Architect.

This document was written by Laurie Tyzenhaus.

Overview

Five Name Constraints findings in BoringSSL (VU#410595.8–.12) describe cases where certificate names may not be constrained as intended. Records .8, .9, .10 and .12 concern the legacy crypto/x509 path; .11 concerns the newer pki path. Two have been fixed, one is accepted, one is disputed, and one was declined.

Description

Name Constraints limit the names a subordinate certificate authority may issue. The reports concern how BoringSSL applies those limits to certain SAN (Subject Alternative Name) forms. The records do not share one status, and they do not all affect the same validation path.

VU#410595.8 (Fixed 2026-03-04): A wildcard DNS name may not be treated as covering a specifically excluded host.

VU#410595.9 (Accepted): A URI with a colon before @ may cause the wrong host to be used when matching URI constraints.

VU#410595.10 (Disputed): The finding concerns first-@ domain extraction in rfc822Name constraint matching. How consuming mail applications interpret the submitted multi-@ input, and whether that creates deployment exploitation, was not established.

VU#410595.11 (Rejected): Trailing-dot handling in rfc822Name domains. The BoringSSL team declined this on 2026-02-28 as below its security threshold.

VU#410595.12 (Fixed 2026-03-04): Trailing-dot DNS names were not always normalized on the legacy validation path.

Using BoringSSL in a product does not mean that product invokes an affected path or name form.

Impact

These findings matter only where Name Constraints are enforced on an affected path, a trusted signature can be obtained over attacker-chosen SAN fields, and the accepted name is used for authorization. Mixed-library environments may accept or reject the same certificate differently. Presence of BoringSSL does not, by itself, mean that Chrome, Android, or other products are affected.

Solution

BoringSSL fixes land in the upstream repository and reach products through each product's own update process.

• VU#410595.8 and .12 were fixed in commit 5774eca on 2026-03-04.
• VU#410595.9 is accepted and under coordination.
• VU#410595.10 is disputed.
• VU#410595.11 was declined.

CERT/CC is not coordinating BoringSSL fixes. For vendor status, contact the BoringSSL team through the Google Issue Tracker. Operators should confirm whether their deployment uses an affected path, apply available updates, and keep issued SANs well formed. A second validator helps only when it uses the same inputs and fails closed.

Acknowledgements

Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Overview

This note covers thirteen library-specific records (VU#948176.6, .8–.19) of how widely used TLS libraries apply X.509 Name Constraints. The records describe cases where a constrained name may be accepted by one library and rejected by another. Some are fixed, some remain under review, and some were not accepted as security issues.

Description

Name Constraints are meant to keep a subordinate CA inside an allowed namespace. The records cover several name forms and do not all have the same classification. VU#948176.7 does not exist.

DNS case-sensitivity and wildcards. While RFC 5280 requires case-insensitive DNS matching, it does not explicitly define wildcard Subject Alternative Name (SAN) matching, leading to varied implementation behaviors. For instance, GnuTLS was found to perform case-sensitive comparisons on certain names (CVE-2026-3833, fixed in 3.8.13). Similar discrepancies regarding case handling in wildcard parent-constraint lookups were reported in Go, as well as wildcard inconsistencies in LibreSSL and wolfSSL. Additionally, pyca/cryptography was identified to check DNS Name Constraints against certificate SANs but failed to validate them against the requested peer name (CVE-2026-34073, fixed in 46.0.6).

IP addresses. Some libraries treat IPv4 and IPv4-mapped IPv6 forms as different when matching constraints. The Go security team determined that report did not meet its security bar; similar reports exist for Apple's Security.framework and Mozilla NSS and are included as comparative evidence.

URIs. Libraries can differ on which host they extract from a URI SAN. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report remains in triage. Related URI reports exist for Apple, NSS, and wolfSSL (CVE-2026-3547, fixed in 5.9.0). A well-formed single @ is handled per RFC 3986 by most implementations.

Common Name fallback. AWS-LC and s2n-tls were reported to apply DNS constraints inconsistently when a leaf has no SAN and uses a wildcard Common Name. The AWS-LC wildcard-CN issue has been fixed; a separate Unicode CN question remains under coordination. s2n-tls is in triage.

Non-critical constraints. In the reported Mbed TLS configuration, non-critical Name Constraints are not enforced. RFC 5280 requires conforming CAs to mark the extension critical, and the reviewed Mbed TLS 3.x configuration rejects unsupported critical extensions. The vendor treats adding support as a feature request; the reporter's concern remains disputed.

Impact

These records matter only when an attacker can obtain a trusted signature over chosen certificate fields, reach an affected validation path, and the application uses the accepted identity for authorization. Validator disagreement alone is not exploitation. Effects, if any, are deployment-specific and may include acceptance of a name outside the intended namespace.

Solution

CERT/CC is coordinating remediation across the affected projects. The following summarizes available status; individual entries reflect different reporting and confirmation dates.

GnuTLS — CVE-2026-3833 fixed in 3.8.13.

pyca/cryptography — CVE-2026-34073 fixed in 46.0.6.

wolfSSL — CVE-2026-3547 fixed in 5.9.0. The wildcard was addressed in PR# 9991.

Go's crypto/x509 — Two reports are in triage. The IPv4-mapped IPv6 report was not accepted as meeting the project's security bar.

OpenSSL — PR #30319 was merged and, as confirmed on 10 September 2026, is present in all then-current publicly supported versions. The separate userinfo-colon report remains in triage.

Apple's Security.framework — Three reports submitted on 2026-03-16 remain in triage.

Mozilla NSS — IP-address report under coordination.

LibreSSL — Wildcard report under coordination.

AWS-LC — Wildcard CN issue fixed; Unicode CN report under coordination. s2n-tls is in triage.

Mbed TLS — Non-critical Name Constraints are not enforced in the reported configuration. Marking the extension critical causes such chains to fail closed rather than adding enforcement.

Until updates are widely deployed, operators who depend on Name Constraints should confirm the behavior of the libraries they actually run, keep leaf certificates to explicit SANs, and treat issuance policy as the first control. A second validator helps only when it uses the same inputs and fails closed.

Acknowledgements

Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Overview

Bisheng contains three vulnerabilities: a pre-authentication account takeover mechanism via a legacy single sign-on (SSO) endpoint; an Insecure Direct Object Reference (IDOR) vulnerability that exposes cross-user workflow data; and prior to version 2.5.0, authenticated attackers could perform cross-user LLM credential abuse and data disclosure due to missing service-layer access checks. Together, these flaws could allow unauthenticated attackers to gain administrative control while enabling authenticated users access to sensitive data and hardcoded credentials.

Description

Bisheng is an open-source Large Language Model (LLM) application DevOps platform, developed by DataElement, designed to assist in building, managing, and scaling LLMs.

CVE-2026-96679 (Legacy SSO Bypass) A vulnerability resides in the legacy SSO endpoint (POST /user/sso). The application processes incoming JSON payloads containing arbitrary usernames and issues a valid JSON Web Token (JWT) without enforcing any form of caller authentication, such as signature verification, shared secrets, or network allowlisting. Furthermore, if the provided username does not exist, the system automatically registers the account. If this newly generated account matches the configured administrative username or is the first user in the system, it is automatically granted super-administrator privileges.

CVE-2026-96681 (IDOR Workflow Exposure) There are missing authorization controls across multiple version retrieval endpoints. The underlying source code retrieves flow and workflow version records based on user-supplied parameters without performing any data ownership or permission validation. Any authenticated user can query and read the complete Domain-Specific Language (DSL) configurations belonging to other accounts.

CVE-2026-100156 (Credential Abuse & Access Control Skip) Within the assistant service's prompt auto-optimization feature, endpoints accept an assistant identifier from the caller without verifying whether the caller owned that assistant. An assistant identifier is a mechanism that lets users or systems recognize that content or interactions come from an AI assistant rather than a human.

Impact

Authentication Bypass / Account Takeover: The legacy SSO vulnerability (CVE-2026-96679) allows unauthenticated attackers to bind their session to an existing victim's profile by completely skipping JWT validation, potentially granting full super-administrative access, leading to full application compromise.

Unauthorized Data Disclosure: The IDOR vulnerability (CVE-2026-96681) causes a breach of data confidentiality, as the system fails to properly validate whether the authenticated user has permission to access the resource.

Resource and Credential Abuse: The assistant service vulnerability (CVE-2026-100156) allows authenticated attackers to run unauthorized AI inferences billed directly to another user's provider account (such as OpenAI, Azure, or Anthropic), while also leaking the victim assistant's configured tools and workflows.

Solution

The vendor has addressed two of the three discovered vulnerabilities in subsequent software releases. CERT/CC recommends upgrading to patched releases.

CVE-2026-100156: The vendor has remediated the assistant service vulnerability in version 2.5.0.

CVE-2026-96681: The vendor has remediated the IDOR workflow vulnerability in version 3.0.0.

For the remaining unpatched vulnerability (CVE-2026-96679), DataElement/Bisheng has not responded to multiple coordination efforts. CERT/CC suggests implementing the manual mitigations below until an official update becomes available.

Mitigations

CVE-2026-96679 Legacy SSO Vulnerability: Administrators should consider the following defensive measures:

• Avoid setting BISHENG_PRO=true in the environment configuration.

• Disable or deprecate the legacy SSO endpoint entirely, or enforce global JWT validation. The affected function is sso(), located in src/backend/bisheng/user/api/user.py, affecting the API endpoint POST /user/sso.

• Restrict access to the POST /user/sso network path to loopback/same-origin to provide defense-in-depth.

Acknowledgements

Thanks to Louis Sanchez, Voke Cyber, for reporting these vulnerabilities.

This vulnerability note was prepared by Laurie Tyzenhaus.

Overview

Versions <= 2.2.0 of Periphery, an agent within the Komodo server management platform, is vulnerable to OS command injection due to missing validation of container names, through two vectors: container destruction and container log searches. This allows an authenticated attacker to execute arbitrary commands as root on the underlying host, enabling persistent compromise of infrastructure.

Description

Komodo is an open-source server and deployment manager, maintained by mogh.tech, widely used in self-hosted and Docker multi-server environments. Periphery is an agent service installed on servers to give Komodo control over Docker environments.

In vulnerable versions of Komodo, Periphery does not properly validate user-supplied Docker container names before those values are interpolated into shell commands used by the agent. Two operations exhibit this vulnerability: container destruction (DestroyContainer / RemoveContainer) and container log searches (SearchContainerLog / GetContainerLogSearch). Through both avenues, raw container names are directly inserted into sh -c command lines without any shell escaping or validation. These commands then run with Periphery's root privileges on the host OS and Docker socket.

Impact

An authenticated non-admin user can escalate privileges through OS command injection via a maliciously crafted container name. Successful exploitation enables arbitrary command execution as root on a target server within a Komodo deployment. Ultimately, this enables an attacker to establish persistence, achieve lateral movement, and completely compromise a user or organization's managed infrastructure.

Solution

Fortunately, Komodo was reached to coordinate this vulnerability, and a patch has been implemented to remediate the issue in versions 2.3.0 and higher. The CERT/CC recommends that all users update immediately.

Acknowledgements

Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Overview

Lowcoder, version 2.4.10, contains an authorization bypass vulnerability in its Query Library feature’s API. Authenticated users with an admin or dev role can access private library-query data from other organizations within a multi-tenant Lowcoder instance.

Description

CVE-2026-16753 Lowcoder is an open-source low-code platform that allows individuals with minimal coding experience to build web applications through a visual drag-and-drop interface. Each Lowcoder project contains a centralized Query Library which stores the workspace’s data queries and sources for quick reuse; however, the LibraryQuery API service layer lacks organization-scope checks at two endpoints: metadata retrieval and query execution.

While the application features a role-based access mechanism (requires admin or dev), it only checks the role’s validity against the user’s own organization. The vulnerable endpoints do not validate whether the requested resource belongs to the requester's organization.

Impact

Any authenticated attacker with an admin or dev role in any organization on a multi-tenant Lowcoder instance can access other tenants’ Query Libraries. Note that these roles are granted by default for any self-signup account when LOWCODER_EMAIL_SIGNUP_ENABLED and LOWCODER_CREATE_WORKSPACE_ON_SIGNUP are TRUE. This allows an attacker to do the following:

• Read the full Domain Specific Language (DSL) of any other organization’s library queries, including complete query configuration and each referenced datasourceId.

• Execute any library query available on the instance, receiving response data directly from the affected organization’s backend data source.

Potential impacts include cross-tenant data exposure, modification, or destruction, as well as cost abuse via querying paid data sources using another tenant’s finances. By bypassing organization-level authorization, Lowcoder instances effectively function as shared environments for attackers, violating data isolation between organizations.

This vulnerability was confirmed against Lowcoder version 2.4.10.

Solution

Unfortunately, Lowcoder could not be reached to coordinate this vulnerability.

Mitigations

Lowcoder administrators should restrict access to the affected Query Library API endpoints until an official security update is available. Administrators can reduce exposure by limiting application access to trusted users and reviewing admin and dev role assignments. Organizations operating multi-tenant Lowcoder deployments should consider isolating tenants into separate instances to prevent cross-organization data access. Where source-code modifications are possible, administrators should implement organization-level authorization checks for Query Library metadata retrieval and query execution.

Acknowledgements

Thanks to Louis Sanchez, member of Voke Cyber, for reporting this vulnerability. This document was written by Alex Lewis.

Overview

This note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify.

Description

The observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280.

DNS-name comparison. RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names' case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison.

IP address handling. RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other.

URI-authority parsing. RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when @, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single @ is handled per RFC 3986 by most implementations.

Wildcard matching. RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory.

These differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment.

Impact

An attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed.

Solution

CERT/CC is coordinating with the affected projects:
* Go's crypto/x509
* Apple's Security.framework
* OpenSSL*
* LibreSSL
* pyca/cryptography
* wolfSSL

Operators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ.

Acknowledgements

Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Supporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).

Overview

Shopware 6.7 contains a stored cross-site scripting (XSS) vulnerability in its media upload functionality that can lead to administrator credential compromise and remote code execution.

Description

Shopware is an open-source e-commerce platform used to build and manage online stores. It provides merchants with customizable product pages, administrative interfaces, plugin functionality, and a media management system that allows users to upload and serve files.

CVE-2026-104937 In affected versions, Shopware’s media upload API accepts HTML files that are later served as text/html without effective Content-Security-Policy or X-Content-Type-Options security headers. An attacker with access to the media upload capability can therefore upload an HTML file with malicious embedded JavaScript, and if an administrator opens the corresponding media URL, the attacker can exfiltrate the administrator's authentication token and use it to gain unauthorized access to the Shopware Administration API.

Impact

Successful exploitation of this vulnerability could allow an attacker with media creation/upload access to execute arbitrary JavaScript in the administrator browser context, steal valid administrator authentication tokens, and gain privileged access to the Shopware Administration API. If the affected administrator account possesses extension management privileges, an attacker could upload, install, and activate malicious plugins to achieve arbitrary PHP code execution on the underlying OS with the privileges of the Shopware process.

Solution

Unfortunately, the CERT/CC was unable to reach Shopware to coordinate this vulnerability. Until a patch is available, users can reduce risk by limiting access to the media upload functionality to trusted roles or disabling HTML file uploads entirely, preventing attackers from creating malicious browser-interpretable content.

Acknowledgements

Thanks to Deflask13 for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview

Thelia versions 2.6.0 and 2.6.1 contain multiple vulnerabilities relating to file management, Smarty templating, module installation, and administrative workflows. Successful exploitation of these issues could enable remote code execution (RCE), server-side template injection (SSTI), stored and reflected cross-site scripting (XSS), unauthorized URL redirection, and other risks that expose both server-side and client-side attack surfaces.

Description

Thelia is an open-source e-commerce platform designed to provide merchants with customizable online storefronts, product management workflows, and administrative functionalities. It utilizes the Smarty template engine and provides administrators with broad control over templates, content, and modules.

CVE-2026-103521 In Thelia v2.6.0, the document upload endpoint properly blocks the upload of executable file types, but the document update endpoint does not perform the same validation. An attacker with administrative Thelia permissions can exploit this vulnerability to upload arbitrary executable files, such as malicious PHP scripts, to achieve remote code execution on the underlying server.

CVE-2026-103522 In Thelia v2.6.0, the store banner upload feature performs insufficient filetype validation that relies exclusively on client-supplied MIME types. An attacker with administrative access can upload a PHP file disguised as an image to bypass validation and achieve remote code execution on the underlying server.

CVE-2026-103523 Thelia v2.6.0 contains an open redirect vulnerability in its address creation workflow. After a user accesses a crafted URL and successfully submits the "Add New Address" form, the application redirects them to the URL specified in the next parameter. Because the application does not validate whether the destination belongs to the same origin or an approved allowlist, an attacker can supply an arbitrary external URL and redirect users to an attacker-controlled website.

CVE-2026-103524 Thelia v2.6.0 is vulnerable to multiple stored XSS vulnerabilities within the administrative interface. User-supplied input is stored without sufficient output encoding or sanitization and is later rendered in the administrator interface and/or the web store's product pages, allowing arbitrary JavaScript execution when the affected pages are viewed. The vulnerability affects multiple administrative functions including category creation and product creation.

CVE-2026-103526 In Thelia v2.6.0, both the administrative login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate valid administrator accounts. Because the endpoint also lacks rate limiting or other protections against repeated authentication attempts, username enumeration can be performed efficiently at scale.

CVE-2026-103527 Thelia v2.6.0's Smarty templates (address.html and address-update.html) fail to properly escape double quotes in the next parameter, enabling reflected XSS when an authenticated user visits the malicious link containing attacker‑controlled JavaScript.

CVE-2026-103528 Thelia 2.6.0 uses Smarty for email templates without properly restricting access to dangerous PHP functions. An authenticated administrator can inject malicious Smarty expressions into email templates via the messages configuration interface, and when the template is previewed or rendered, functions such as system(), exec(), file_put_contents(), and file_get_contents() can be executed with the privileges of the web process. This allows arbitrary OS command execution, file read/write operations, and RCE on the server.

CVE-2026-103529 Thelia v2.6.0 permits authenticated administrators to upload and install modules via the ZIP upload function without validating or sandboxing embedded PHP code. An attacker can include malicious PHP code in a module's install() method which will then be executed upon installation, enabling remote code execution with the privileges of the web server.

CVE-2026-103535 Thelia v2.6.1 contains path traversal and PHP code injection vulnerabilities in its translation editor that can be chained to achieve remote code execution. The item_name parameter, used to build the translation file's write path, does not sanitize directory traversal sequences such as ../, allowing an authenticated user with UPDATE-level permission on admin.configuration.language to write files outside templates/, including to web-accessible directories. Separately, the translation-writing logic does not escape \ in user-supplied values, allowing input to break out of the PHP string literal and inject executable code into the translation file. Chained together, these flaws allow a malicious PHP file to be written to a web-accessible path and executed with the web server's privileges.

CVE-2026-103537 Thelia v2.6.1 contains an absolute path traversal vulnerability in its Smarty template handling that enables SSTI and remote code execution. The checkTemplate() validation restricts relative directory traversal sequences such as ../ but does not reject absolute paths, allowing an authorized user to supply an arbitrary filesystem path as a template. Smarty then loads and compiles the referenced file without an effective security policy, so, depending on filesystem layout and deployment configuration, template code in that file can be executed with the web server's privileges.

Impact

Several of these vulnerabilities allow authenticated administrative users to achieve arbitrary code execution on the host server. These include insufficient file validation and unsafe upload/update workflows (CVE-2026-103521 and CVE-2026-103522), unrestricted execution of PHP code during module installation (CVE-2026-103529), unsafe template evaluation for email content (CVE-2026-103528), server side template injection via absolute paths (CVE-2026-103537), and flaws in the translation writing process that permit path traversal and PHP injection (CVE-2026-103535). Exploitation of any of these issues can result in complete compromise of the underlying application environment with the privileges of the web server.

Separately, user-supplied content rendered within administrative templates enables stored and reflected XSS. CVE-2026-103524 allows persistent JavaScript execution within the admin interface, while CVE-2026-103527 enables reflected JavaScript injection via unescaped template parameters. These vulnerabilities allow attackers to hijack administrative sessions and perform privileged actions in the browser context of other authenticated users.

The discrepancies in authentication error-handling identified in CVE-2026-103526 allow unauthenticated attackers to easily enumerate valid administrative usernames, increasing the risk and effectiveness of subsequent brute-forcing or authentication-related attacks.

Finally, the open redirect described in CVE-2026-103523 allows attackers to redirect users to external attacker-controlled websites, increasing the effectiveness of phishing or other downstream attacks.

Together, these vulnerabilities facilitate full server takeover for authenticated administrative attackers, and expose avenues for browser-based compromise or credential attacks to both authenticated and unauthenticated attackers.

Solution

Unfortunately, we were unable to coordinate these vulnerabilities with Thelia, and a patch is not yet available. To reduce risk until these issues are remediated, users and organizations should restrict access to Thelia administrative interfaces, disable or tightly limit file-upload and template-editing features, and remove PHP execution permissions from user-writable directories wherever possible. Applying strict reverse-proxy controls such as rate limiting, MIME filtering, and URL allowlisting can further reduce exposure.

Acknowledgements

Thanks to the reporters K08UK0VU, s-b321, DuanNH, Deflask13, LongNBH, and NNPhong (pnn219) from ETC JSC security team for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview

An Out-of-bounds Write vulnerability in the InsydeH2O IHISI software used by HP PC BIOS can allow a local attacker with OS kernel privileges to perform arbitrary physical memory writes, including writes to System Management RAM (SMRAM). Because the vulnerable code executes in System Management Mode (SMM), successful exploitation can allow an attacker to modify SMM-protected memory and potentially achieve arbitrary code execution in SMM. Depending on the platform's memory and firmware configuration, the arbitrary physical memory write primitive may also have implications for UEFI firmware update or flash-related operations.

Description

HP PC BIOS is firmware that initializes and manages hardware components during the boot process and provides runtime services to the operating system and provide the ability to update firmware. The affected system uses InsydeH2O Kernel version 5.5 or earlier. The BIOS includes custom HP SMM handlers that execute in System Management Mode (SMM), a highly privileged CPU execution mode that is isolated from the operating system.

CVE-2026-12855: An Out-of-bounds Write vulnerability in the H19WMIHandlerSmm module (GUID f1946499-571b-44c3-9b9c-cc55210b0c02) allows a local attacker with OS kernel privileges to read or write arbitrary physical memory, including SMRAM, through a Software SMI handler.

An attacker with kernel-level privileges can trigger the vulnerable SMM handler by issuing a Software System Management Interrupt (SMI) through I/O port 0xB2 and supplying specially crafted CPU register values. The vulnerable handler does not adequately validate the supplied parameters before performing memory operations, allowing the attacker to influence the physical address and data involved in the operation.

Because the affected handler executes in SMM, the resulting arbitrary physical memory write can target memory regions that are normally inaccessible to software executing outside SMM, including SMRAM. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution in SMM. The ability to affect firmware or ROM contents is platform-dependent and is not assumed as a direct consequence of this vulnerability.

Impact

An attacker with privileged OS kernel access (ring 0) can exploit the vulnerability by raising Software SMI interrupts through I/O port 0xB2 with crafted CPU register values. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution and persistence via modifying SMRAM.

Solution

Users should check HP's security bulletins to determine whether their system is affected. Insyde advisory is available at https://www.insyde.com/security-pledge/sa-2026009/

Acknowledgements

Thank you to Zhenyu Liu for reporting these vulnerabilities. This document was written by Vijay Sarvepalli.

Overview

Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty "signatures" array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material.

Description

Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication.

As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the "signatures" section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected:

jws.deserialize_json({"payload":"...", "signatures":[]}, key=None)
jws.deserialize('{"payload":"...","signatures":[]}', key=None)

Impact

An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following:
* Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin).
* Signed message injection between microservices using JWS.
* Forged authorization claims such as scopes, roles, or permissions.
* Integrity bypass in systems relying on signed JWS data.

Solution

The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project's GitHub repository for updates and install the latest version of this library once a fix has been released.

Acknowledgements

Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.

Overview

Three cross-site scripting (XSS) vulnerabilities identified in Readwise Reader for Android version 8.7.2 are disclosed. An attacker with the ability to craft malicious documents or metadata can exploit these vulnerabilities by supplying poisoned content that bypasses sanitization. Successful exploitation could allow the attacker to execute arbitrary JavaScript within the application's WebView context and compromise the confidentiality and integrity of user data, including access to stored documents, credentials, and session tokens.

Description

Readwise Reader from Readwise is designed to provide a unified read-it-later service that helps individuals collect and organize articles, newsletters, videos, and other content of interest into a single reading interface. It is available on multiple platforms including Android and can synchronize content across devices.

CVE-2026-18311: A stored cross-site scripting (XSS) vulnerability in the header rendering component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via crafted document metadata fields. The header rendering component is impacted due to insufficient HTML escaping of metadata fields such as 'doc.author' and 'doc.title', which allows malicious scripts to be stored in the user's library and synchronized to Android devices where they are executed in the WebView context.

CVE-2026-18312: A stored cross-site scripting (XSS) vulnerability in the WebView URL construction logic in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious URL metadata. The WebView URL construction for X (formerly Twitter) video fallback and iOS paywall messages is impacted due to improper escaping of URL metadata before interpolation into href attributes, which allows user-controlled values to break out of the URL structure and inject script elements that are inserted into the DOM via innerHTML.

CVE-2026-18320: A stored cross-site scripting (XSS) vulnerability in the article body sanitization component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious SVG markup. The sanitize-html configuration is impacted due to a wildcard attribute rule that permits all attributes on SVG and PATH elements, which allows script-capable attributes such as onload and onerror to bypass sanitization.

Impact

An attacker with the ability to create or modify documents accessible to Readwise Reader can supply documents containing malicious metadata or markup that bypasses sanitization and is subsequently stored in users libraries. Because these documents are synchronized to Android devices and rendered within the Reader WebView, each vulnerability enables stored XSS: CVE-2026-18311 and CVE-2026-18312 through poisoned metadata, and CVE-2026-18320 through malicious SVG markup.

Solution

Unfortunately, the vendor could not be reached to coordinate this issue. Users should apply vendor updates as they become available (check Vendor Information section for updates) and keep Readwise Reader updated through the Google Play Store. As of publication, version 8.10.1 includes a patch that addresses the sanitizer-wildcard issue. Additionally, users should exercise caution when adding content from untrusted sources to their reading library and consider manually reviewing document metadata before saving articles to minimize exposure to malicious content.

Acknowledgements

Thanks to Zampier Zago (FUNFACTOR1) for reporting these vulnerabilities. This document was written by Alex Lewis.

Overview

ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise.

Description

ViewSonic ViewBoards are widely used smart display devices (smartboard), typically deoloyed in enterprise and educational environments. vCast is ViewSonic’s proprietary software suite for wireless connection between smartboards, which are Android-based systems, and devices running a client application. Three distinct vulnerabilities, all invoking unauthenticated endpoints, have been identified within the vCast suite.

CVE-2026-82989
vCast’s media streaming service allows a remote attacker to exfiltrate JPEG images of screen content via GET requests to an unauthenticated /snapshot or /screen API endpoint.

CVE-2026-82988
vCast’s Android Package Kit (APK) delivery mechanism allows a remote attacker to trigger unprivileged file installation by providing a malicious APK URL through an unauthenticated download endpoint.

CVE-2026-82987
vCast’s network services allow a remote attacker to inject arbitrary input into service endpoints via HTTP requests to exposed unauthenticated endpoints

Impact

An unauthenticated attacker can chain these vulnerabilities via a shared network to deliver and execute arbitrary code on a vCast-based device without user interaction. Potential device-level impact includes unauthorized access to displayed content, persistent installation and execution of arbitrary applications, and full compromise of the device. Additionally, an exploited device’s connected network may be prone to lateral movement.

Solution

Unfortunately, ViewSonic could not be reached to coordinate the vulnerability. In the meantime, firmware updates should be applied when available. If possible, segment vCast devices onto an isolated, secure network with strict controls, separate from systems containing sensitive data. Network activity should be monitored for suspicious vCast connections.

Acknowledgements

Thank you to Adam Mohammed Zenker for this report. This document was written by Alexander Lewis.

Overview

Door access controllers used on Norwegian Cruise Line (NCL) ships contain an improper authentication vulnerability that permits a replayed unique identifer (UID) from a radio-frequency identification (RFID) device to grant unauthorized entry to areas secured by these controllers.

Description

Norwegian Cruise Line is a global cruise company that operates a modern fleet sailing to destinations worldwide. As described in CVE-2026-75907, the affected card reader authenticates NFC credentials only by checking their static 7-byte UID. A UID is not a secret and does not support cryptographic challenge‑response operations, so it cannot serve as a reliable authentication factor. Although the keycard's NTAG212 tag contains a memory block with a printed serial number and a value resembling a signature, the reader does not inspect this data during the access-control process. Validation based solely on UID constitutes identification rather than authentication. Because the credential performs no cryptographic exchange and offers no defense against cloning, any device capable of replaying or emulating UIDs can reproduce a functioning keycard.

Impact

An attacker with brief physical proximity to a valid keycard can use an RFID reader to capture the UID without interacting with or altering the card. Once obtained, this UID can be copied to an inexpensive UID‑writable card to create a permanent duplicate credential. The access control readers will accept these forgeries as genuine, granting entry. Depending on logging configuration, the unauthorized entry may be indistinguishable from legitimate use. Because unauthorized access to restricted areas on a cruise vessel can have direct safety implications, this vulnerability presents a significant security risk to both internal operations and guest safety.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Users are encouraged to employ the following methods to help reduce the risk of RFID cloning:
* RFID‑blocking wallets and shielded card-holder sleeves prevent unauthorized scans.
* Placing aluminum foil on both sides of your RFID card can help limit signal transmission by creating a basic Faraday shield.
* When using or storing your card, try to keep a distance of at least 12 inches from other people or devices. Cards operating at 13.56 MHz are usually read at an approximate distance of 2–5 cm (1–2 inches).

Acknowledgements

Thank you to Mark Linton for reporting this vulnerability. This document was written by Bob Kemerer.

Overview

Imprivata Enterprise Access Management (EAM), an authentication and single sign-on platform for enterprise and clinical environments, contains a vulnerability in versions 26.2.6 and below. The product provides no supported mechanism to rotate its RSA key pair after deployment, meaning the same key pair is used indefinitely to generate the appliance's X.509 certificate.

Description

CVE-2026-82356
Imprivata EAM uses an RSA key pair to generate the X.509 certificate that identifies the appliance to the clinical workstations, Electronic Health Record (EHR) platforms, and shared-device workflows that rely on it for authentication. After reviewing the product documentation and engaging Imprivata support, it was confirmed that no supported mechanism exists to rotate this RSA key pair after deployment.

Using a single RSA key pair indefinitely for certificate generation violates cryptographic best practices. Because the key cannot be rotated, an attacker who obtains the private key retains a valid, trusted appliance identity for as long as the deployment remains in service, with no supported means to revoke or replace it short of redeploying the product.

Impact

An attacker who obtains the private key, for example through backup exfiltration, a hypervisor snapshot, or privileged access to the appliance filesystem, can impersonate the appliance to any endpoint that trusts its certificate. Because Imprivata EAM sits directly in the authentication path, this allows persistent, difficult-to-detect interception of authentication traffic across every application the appliance brokers, including SSO tokens, session assertions, and credentials for EHR and clinical systems. If perfect forward secrecy is not enforced, previously captured traffic can also be decrypted retroactively. Because the key pair cannot be rotated, this access persists until the appliance is redeployed.

Solution

Unfortunately, Imprivata could not be reached to coordinate this case. The vendor is aware of the issue, which they are tracking internally, and is reported to be working toward a resolution. No fix or timeline has been provided at the time of publication.

Until a fix is available, affected users should protect the appliance's private key by restricting filesystem and administrative access, securing backups and hypervisor snapshots, and enforcing perfect forward secrecy on upstream connections to limit the impact of any key compromise.

Acknowledgements

Thank you to Frank "5y5tem5" Mileto for reporting this issue. This document was written by Alexander Curtis.

Overview

Cinnamon's Kotaemon (all versions up to v0.12.0) multi‑user chat interface does not verify conversation ownership when loading a conversation. Any authenticated user can read, delete, rename, or overwrite another user’s conversation data by supplying the correct ID. This results in high‑impact confidentiality, integrity, and availability violations.

Description

Cinnamon's Kotaemon is an open‑source, retrieval‑augmented generation (RAG) based tool that lets you build a chatbot capable of "chatting with your documents". As discussed in CVE-2026-86867, all versions up to v0.12.0 fail to verify conversation ownership when loading a conversation. In multi‑user mode, each conversation row includes a user field that identifies its owner. The four affected handlers, select_conv, delete_conv, rename_conv, and persist_chat_suggestions, query conversations using select(Conversation).where(Conversation.id == conversation_id)

No predicate is included to ensure Conversation.user == user_id. As a result, any authenticated user can operate on conversations they do not own.

Impacted operations include:
* select_conv – reads the full chat transcript, RAG retrieval history (verbatim excerpts from uploaded private documents), plot history, and suggestion data belonging to another user.
* delete_conv – permanently deletes a conversation.
* rename_conv – renames a conversation.
* persist_chat_suggestions – overwrites a chat suggestion list.

Although select_conv includes an ownership check for the selected (file‑picker) field, all sensitive payloads (chat history, retrieval history, plot history) are returned unconditionally. The system trusts user‑controlled identifiers for authorization. Attackers require only an authenticated account on the instance and a victim conversation UUID (Universally Unique Identifier). Affected users’ public conversations appear in the global conversation browser, exposing their UUIDs. If a conversation is later set to private, the UUID remains unchanged and still valid. Similar direct calls to delete_conv, rename_conv, and persist_chat_suggestions allow deletion, renaming, or content overwriting. No elevated privileges are required; any authenticated user account is sufficient.

Impact

Full chat transcripts and RAG retrieval history for any conversation are disclosed. For Kotaemon's primary deployment use case (enterprise document Q&A over proprietary knowledge bases such as legal briefs, financial reports, research papers, and internal strategy documents), the retrieval_history field contains verbatim excerpts from those private documents. A single IDOR (Insecure Direct Object Reference) read may expose more sensitive content than what the affected user intended to share with any other party.

Conversations can be renamed or have their suggestion state overwritten. While the impact of renaming is limited, the persist_chat_suggestions path allows an attacker to inject attacker-controlled prompt suggestions into the victim's conversation UI, a potential vector for prompt injection if the AI model acts on suggested prompts.

delete_conv permanently destroys any conversation with a single call. An attacker can systematically delete all conversations of a target user or across all users if they have access to the UUIDs. There is no recycle bin or soft-delete in the Kotaemon data model for conversations.

Because retrieval_history contains verbatim document chunks (not just file names), the attacker does not need separate file-read permissions to access the content of documents indexed into the victim's knowledge base. The chat conversation becomes a side-channel through which document content leaks.

Solution

Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, please refer to the vendor's web site and GitHub repository (listed in the references below) for future updates.
https://github.com/Cinnamon/kotaemon
https://cinnamon.github.io/kotaemon/

Acknowledgements

Thank you to Louis Sanchez for reporting this vulnerability. This document was written by Bob Kemerer.

Overview

Vendor-signed UEFI Shell applications may allow an attacker to bypass Secure Boot protections by abusing commands such as mm (Memory Modify). On systems that trust the affected vendor’s certificate or include the application’s Authenticode hash in the UEFI Authorized Signature Database (DB), an attacker with sufficient access could use the application’s direct memory-access capabilities to disable or circumvent Secure Boot enforcement and execute untrusted UEFI code. To mitigate this risk, system administrators should apply available firmware and software updates from affected hardware vendors.

Description

The Unified Extensible Firmware Interface (UEFI) standard defines the firmware architecture used to initialize hardware and transfer control to modern operating systems during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before their execution. Trust for these signatures is managed through several databases, including the Authorized Signature Database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.

There are multiple implementations of the UEFI Shell, and OEM vendors typically sign the implementation that they distribute. Some UEFI Shell implementations expose built-in capabilities for directly manipulating system memory and interacting with the UEFI environment. Because the Shell is vendor-signed and therefore permitted to execute with Secure Boot enabled, an attacker who can launch a vulnerable Shell can use these capabilities to modify the protected pre-boot state and potentially load or execute untrusted UEFI code. This creates a security boundary violation: Secure Boot permits execution of the signed Shell, while the Shell itself provides the primitives necessary to circumvent the integrity protections Secure Boot is intended to enforce. As a result, an attacker can potentially compromise the pre-boot environment despite Secure Boot being enabled.

Researchers from Binarly identified multiple UEFI Shell applications vulnerable to this type of abuse. Note that Eclypsium has also identified and reported some such signed UEFI shell binaries that expose high-privileged capabilities that can be used to bypass Secure Boot. To neutralize the risk, the affected binaries will need to be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.

Impacted UEFI Applications
[Vendor, Application and vulnerable function
Authenticode SHA hash
SHA256 file hash]
Acer `UEFI shell` mm,dmpstore 805f72afd179fe67ceee14c76f92c8f76cad23130fa075d1d5678e242a0d3d52 f52b8dbffaa9b57910b3c369c384f7ccfe8d696e05e7a8a7f0da0db5540949c2 Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b3a999b7fad3c8cfeff88ab8b29d261b241689c857e13414a9ae0e9f84a10a5f Acer `UEFI shell` mm,dmpstore a249bd3044e9aa5d4e2dfa9f94b0ffa437f4ebf3f39d57c9f276b3b9988b2b0b 77a36a8f035dfb1fdf5170f396e29a8b3e4b93558317a51eafd5be9c5ead5ef9 Acer `UEFI shell` mm,dmpstore 6ce33e23b21bfa1ce143fdadf55d00340a9fa3215dd73e31fa6307d5733b8841 77019c81bdc1accbd0c99b20b12edcd578dabc4cac4fa66934465f20c1c0aa2c Acer `UEFI shell` mm,dmpstore ad30615c1ad7da2e47dcf28a571dc62b9c034c6ade434de8daa35965062f3a7f c0194c555db9f5f7080c3344db028f44af522bac63c13d764ff416ac244e3c08 Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b2e0afb2844241479db7d19398c837049fb4c7f08560963d616b3c95b1d382e2 Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 2bfbec41b536b248a3e0a28dddfbcd57f774f03b72028cec91def28b2dcffc2f Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 5cdf3d75c0ec0800b9692aedef19527f06eb4a16fdda586f5527350e2f6a40ad Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 6ccd1ee8b067d02c083e73a0c2e18712d55b78bd99fec392daf702a147ce6d41 Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 a632de93bfd10d89326db2171673bd246cd6533dcdf8e5f6de85949855695e78 Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 d2ed7a747c5b3e5c83319e5d186ec602918fbf0651d059699a3c68f609d25cf2 Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 ec23a874c3c0e852becc8fa4010c60e5f8922fe671f5351cf8a976da59a01f86 Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 f75456cd23e492a078b3a81ffbbe262a1511ac9480c4f397e3d4be3b4ce5a455 Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 f89cdf53d55d70fea31723f52d6b816937aebe2a2212ddcde7e3732e39c1fbfe Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 fb68dfe907b99c23e97f98518d5e1079312d3981df036bb64d4682fe6fff83b5 Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 20cca70af9e3b4e5640d52840c84a1968d5be6ca881b393bc236f8d349c225ce Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 d4e7b11a30edd1f89c4fa1664eff98907202f15bc59c2cdfddf345a09ffbb1d4 Eurosoft `UEFI shell` mm,dmpstore e9d873cbcede3634e0a4b3644b51e1c8a0a048272992c738513ebc96cd3e3360 1e918f170a796b4b0b1400bb9bdae75be1cf86705c2d0fc8fb9dd0c5016b933b Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 51401e93b940dec1a4391303fb6e390194b90113a8f7da6e711253c82a02b8e4 Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 7e1dbf3e72b8c3c4967364f49da0cd5e3c09d921086d60ac2a493b55818cd7cf Framework `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 0e03ff927005c70636273a4b9287683a821082f952dc7c9beda1a4fc911dddce Getac `UEFI shell` mm,dmpstore 09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0 380a387b53a0ca586fe32eb1459b036f5dc178b26b2b0ec618c598eb4714d1fe Lenovo `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 1f2c450bbf287e35747561723079c166aed3eddfc509b26c18dd8e19417f1838 MinisForum `UEFI shell` mm,dmpstore 5e7b3650103fb1c15e610e2381351d9b36546f260284535ed5774adf7532f633 9de8a0194052063ce541b34fbd451071ea3051914fc234b6d691d006f0a0f994 Msi `UEFI shell` mm,dmpstore 61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70 da5f4aa2008e6e26c3553b3dee4cf835ceac88820658693704cea35f62733ce3 Seagate `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 53d87f3b7729fe82b47606a85e606c30d2bb61d3da3f01caef17eb7164bca261 Uniwill `UEFI shell` mm,dmpstore 55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66 d4f05110f4bb55677426067db88f61595dc1831659ba43a5770268b73d4eb479 Unknown `UEFI shell` mm,dmpstore 044f80d53ecea7dc108bbf54a89f431d22aa4ebd9b43da3a2abba75bede8b431 67bf47b637bff078e6eae9afbae26b82c701739ae7fcd8e7d282b1f2901f9634 Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 8e61f24a72c3138bde4b63766ceee1ce1a70a00046cc6867c61520084d884346 Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 88fbb6425f43eb54194dbb607141e65adc2d1e7e0d33b6bfe762504547024942 Impact

This vulnerability impacts systems that trust the compromised vendor certificate within their UEFI Authorized Signature Database (DB) or those that include the affected application’s Authenticode hash in the DB. An attacker with physical access or administrative privileges can leverage these trusted components to bypass Secure Boot and execute arbitrary code during the pre-boot phase. Because this execution occurs before the operating system and endpoint security products initialize, the malicious code can achieve persistent platform compromise, including the loading of unsigned kernel components, while remaining entirely invisible to standard security controls and Endpoint Detection and Response (EDR) solutions.

Solution

Apply the latest firmware and software updates from your hardware vendor. These updates are expected to replace vulnerable UEFI applications with secure versions. Update and verify the UEFI DBX on the affected systems to revoke trust in vulnerable binaries or, where necessary, the certificates used to sign them, preventing the affected binaries from executing during boot.

Acknowledgements

Thanks to Binarly for researching and reporting this vulnerability. Thanks to Eclypsium researchers continued work on UEFI risks from such signed applications. This document was written by Vijay Sarvepalli.

Overview

Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacker to escalate privileges and lead to full compromise of the target device.

Description

Dokploy is an open-source Platform as a Service solution for deploying applications and databases on self-hosted servers. Dokploy allows authenticated users to create and schedule database backups and restore previously created backups. These backup operations are executed by the Dokploy process, which runs with root privileges by default.

Dokploy is vulnerable to OS command injection in its database backup creation and restoration functionality due to insufficient sanitization of user-controlled input before it is incorporated into shell commands. The vulnerable backup functionality constructs database-specific shell commands that directly interpolate a user-supplied database name, while the restore functionality incorporates a user-supplied backupFile value into a shell command. Both operations ultimately pass the resulting command to a shell execution helper that invokes /bin/bash as a child of the Dokploy process, without shell escaping or restrictions on shell metacharacters.

The affected parameters are exposed through tRPC procedures that only validate that the supplied values are non-empty strings. Consequently, authenticated users with permission to perform database backups can supply shell metacharacters that are interpreted by /bin/bash, resulting in arbitrary command execution on the Dokploy host with the root privileges of the Dokploy server process.

Impact

An attacker with authenticated Dokploy account with backup permission (granted by default for database services) can execute arbitrary commands as root (default configuration) on the Dokploy host. Successful exploitation provides full control of the host, including persistent read/write access to the target server's filesystem and the ability to steal private credentials stored for other tenants managed by the same Dokploy instance.
The vulnerability affects all five database types supported by Dokploy: PostgreSQL, MySQL, MariaDB, MongoDB, and LibSQL. Exploitation was confirmed against versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch available on GitHub.

Solution

Unfortunately, Dokploy could not be reached to coordinate this vulnerability; however, the issue has been patched in Dokploy versions 0.29.13 and beyond. The CERT/CC recommends users update immediately. Database administrators or general operators unable to update should mitigate potential attacks by turning off default backup permissions, and restricting these permissions only to necessary users and roles.

Acknowledgements

Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Overview

A vulnerability in MLflow’s dspy and statsmodels model flavors allows unauthorized pickle deserialization executions despite a safety control. Specifically, the dspy flavor conditionally applies the control based on the model path’s file extension, and the statsmodels flavor does not apply the control.

Description

MLflow is an open-source platform for managing machine learning lifecycles, including model packaging, versioning, and deployment. "Flavors" refer to the specialized frameworks through which supported models are stored and loaded. In response to previous vulnerability concerns, MLflow implemented the MLFLOW_ALLOW_PICKLE_DESERIALIZATION safety control to block and disable executing any pickle deserialization and subsequent loads per the user’s choice.

When loading models through mlflow.pyfunc.load_model(model), users must specify a model flavor and path in an MLmodel file. With the dspy flavor, MLflow checks the value of MLFLOW_ALLOW_PICKLE_DESERIALIZATION, and whether the specified model path ends in .pkl. A model path that does not end in .pkl (even if the file is actually a pickle file), will route to a separate branch for pickle deserialization, bypassing the safety control. However, when loading through the statsmodels flavor, there is no check for MLFLOW_ALLOW_PICKLE_DESERIALIZATION at all.

Impact

Exploitation of this vulnerability allows for arbitrary remote code execution through a malicious pickle-loaded payload, regardless of a user explicitly disallowing pickle serialization, through vulnerable flavor specifications in the MLmodel configuration file. The attack path requires write access to any location from which a user obtains MLflow models. This vulnerability was confirmed against MLflow 3.12.0.

Solution

MLFlow could not be reached to coordinate this vulnerability; however, the statsmodels flavor was patched in versions >= 3.15.0. Users should upgrade immediately. Until a further fix remedying the dspy flavor vulnerability is available, MLflow users who wish to block pickle deserialization and loads should avoid loading any models via the dspy flavor.

Acknowledgements

Thanks to Prasanna Dabi for reporting this vulnerability. This document was written by Alex Lewis.