US-CERT.gov

A heap-based buffer overflow exists in the Tight JPEG decoding component of the TightVNC Windows Viewer version 1.3.10 and affected UltraVNC Windows Viewers. An attacker controlling a malicious VNC server can trigger memory corruption by sending a specially crafted screen update. Successful exploitation can crash the viewer and may allow arbitrary code execution, although only denial of service conditions were demonstrated during testing.

TightVNC and UltraVNC provide remote desktop access using the Remote Framebuffer (RFB) protocol. Their viewer applications connect to VNC servers and decode screen updates for local display. Tight encoding supports JPEG compression of image data within these updates.

The Windows viewer function DecompressJpegRect() allocates a heap buffer using a hardcoded maximum row width of 8,192 pixels but converts JPEG pixel data using the server-supplied rectangle width without adequately checking that the output fits within the buffer. A malicious server can supply an oversized Tight JPEG rectangle that causes the conversion loop to write beyond the allocated memory. In an allocation demonstrated during testing, which included 256 bytes of padding, the out-of-bounds write began at a rectangle width of 8,257 pixels.

Exploitation requires a vulnerable viewer to establish a session with an attacker-controlled or compromised VNC server and process its crafted update. The server can advertise a sufficiently large framebuffer, so checking that the rectangle fits within the advertised framebuffer does not, by itself, prevent this overflow. Authentication or transport encryption does not prevent exploitation by a malicious server participating in the session.

An attacker controlling a VNC server can corrupt heap memory in a connected vulnerable viewer, terminating the application and interrupting the remote desktop session. Memory corruption may also permit arbitrary code execution with the privileges of the user running the viewer, but only denial of service was confirmed during testing.

Review the Vendor Information section for product-specific patch information.

According to UltraVNC’s release notes, the Tight JPEG heap overflow vulnerability was addressed in version 1.8.2.8. Users should upgrade to a current supported release containing that fix, such as version 1.8.3.1.

Unfortunately, we were unable to reach TightVNC to coordinate a fix for the affected 1.3.10 Windows viewer. Users should replace affected viewers with a maintained version or an alternative solution that has been confirmed to address the vulnerability.

Until a corrected viewer is deployed, restrict connections to trusted VNC servers only. This reduces exposure but does not protect against a compromised trusted server.

Thank you to re9rch for reporting this vulnerability. This document was written by Michael Bragg.

Multiple arbitrary file read and write vulnerabilities have been identified in applications that use ImageMagick with insufficiently restrictive security policies. Collectively referred to as ImageTragick2, these issues arise when ImageMagick processes attacker-controlled SVG or PostScript content using dangerous coders or delegates permitted by its default or application-supplied configuration. An attacker who can upload an image, or otherwise cause an application to process crafted image content, may be able to read or write files accessible to the ImageMagick process. In some deployments, these capabilities may be chained to achieve arbitrary code execution, compromising the confidentiality, integrity, and availability of the affected application and host.

ImageMagick is a widely used open-source image-processing suite. Web and content-management applications, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, may use ImageMagick for operations such as thumbnail generation, cropping, conversion, and transformation. ImageMagick is also commonly included in containerized AI image-processing pipelines. It may operate before inference to normalize or transform inputs, or after inference to convert and prepare generated output. In these environments, images may originate not only from direct uploads but also from URLs, automated agents, datasets, model outputs, or other upstream services.

Two vulnerability variants have been identified:
Coder invocation through SVG (MSL injection)

ImageMagick's SVG processing can allow a crafted SVG <image> element to invoke a dangerous coder through its xlink:href value, for example, by referencing an MSL: resource. ImageMagick may then interpret the referenced content as a Magick Scripting Language (MSL) script. The script can invoke additional image readers and direct attacker-controlled image data to selected filesystem paths, enabling unauthorized file access. Exploitation depends on the internal SVG coder and the required dangerous coders being available to the ImageMagick process.

Ghostscript invocation through content detection

ImageMagick's content-based format detection may identify crafted input as PostScript and invoke Ghostscript, a separate interpreter used by ImageMagick to handle PostScript, EPS, and PDF, even when the filename or declared type suggests another format. Although Ghostscript is invoked with -dSAFER, the observed configuration permits file access within /tmp. A crafted PostScript file may therefore read or write data in that directory. This can affect applications that use shared temporary storage for uploaded files, processing artifacts, sessions, or other security-sensitive data.

These issues highlight an important aspect of ImageMagick's security model: Behavior that can be restricted through a custom security policy is treated as a configuration issue, not a vulnerability in ImageMagick itself. Applications and distributions are therefore responsible for deploying a policy appropriate to their threat model. Many integrations, however, process untrusted content without a sufficiently restrictive policy.

An attacker who can cause an affected application to process crafted SVG or PostScript content may be able to read or write files in directory locations accessible to the ImageMagick process. In some cases, arbitrary code execution is possible when file access can be combined with writable executable content. AI-enabled services that utilize ImageMagick may face additional exposure because of untrusted image processing. In container deployments, writable host mounts, shared volumes, credentials, or inference artifacts can substantially increase the impact of a successful exploit.

Consult the Vendor Information section for product-specific updates and mitigations. Users of products that integrate ImageMagick, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, should install vendor-provided updates when available. Updating ImageMagick alone may be insufficient if its security policy continues to permit dangerous coders or delegates.

Apply a custom policy.xml based on an allowlist: enable only the formats and operations the application requires, and disable unnecessary coders and delegates, including MSL, MVG, PS, EPS, and PDF. ImageMagick's bundled secure policy template may not be sufficient for every deployment; verify the effective policy and confirm that prohibited formats are rejected.

Additional recommendations include:
- Isolate image processing: Process untrusted images in a dedicated, minimally privileged environment with restricted filesystem access. Apply the same controls to AI preprocessing and post-processing pipelines.
- Validate and constrain input: Verify file content rather than relying on filenames, extensions, or client-supplied media types.
- Monitor processing activity: Alert on ImageMagick policy violations, unexpected delegate or coder use, unusual processing failures, and unexpected file creation.

Thanks to RyotaK of GMO Flatt Security Inc. for reporting these vulnerabilities. The pwn.ai team independently discovered Variant 2 and reported it to WordPress as CVE-2026-65640. This document was written by Vijay Sarvepalli and Molly Jaconski.

The npm library promzard, versions 4.0.0 and earlier, is vulnerable to remote code execution due to direct string interpolation of context object keys, which allows unsanitized JavaScript code injection.

promzard is a Node.js library designed to automate configuration workflows by evaluating template modules and generating data objects via interactive prompting. The library allows users to provide a context object ctx to expose specific data to the template module.

promzard builds an object by walking the template module for prompt() and asynchronous functions. The keys of ctx, however, are treated as raw JavaScript source code instead of inert data. The implementation performs direct string interpolation of ctx keys, without validation or sanitization, into the parameter list of a function-expression source string that is then evaluated with vm.runInThisContext(). A key containing attacker-controlled JavaScript syntax can be executed during evaluation.

An attacker capable of influencing the ctx object’s keys (e.g. via parsed configuration file, an HTTP request, or environment variables) can break out of the function parameter list and inject arbitrary JavaScript code. This results in remote code execution within the context of the Node.js process.

Unfortunately, the maintainers of promzard could not be reached to coordinate the vulnerability. The CERT/CC recommends users ensure that any data used to populate ctx is strictly validated, and that arbitrary keys should not be passed from untrusted sources.

Thanks to Abdullah Hamdan for reporting this vulnerability. This document was written by Alex Lewis.

ComfyUI-Easy-Use version 1.4.1 and earlier contains a vulnerability in its save_preview() handler that allows an unauthenticated attacker to overwrite an installed custom node’s Python file. An attacker who can reach the affected ComfyUI instance over the network can use the overwrite to execute arbitrary code when ComfyUI restarts.

ComfyUI is a node-based interface for building generative AI workflows. ComfyUI-Easy-Use is an extension that adds custom nodes and workflow utilities.
An attacker can upload a Python file to ComfyUI’s input directory then use save_preview() to copy that file over an installed custom node’s __init__.py. Upon restart, ComfyUI will import and execute the modified node. Remote exploitation requires a deployment that exposes the affected routes to the attacker without authentication.

An unauthenticated attacker who can reach the affected routes can execute arbitrary Python code and operating system commands with the privileges of the ComfyUI process. The attacker can read or modify models, workflows, and other files accessible to the process and obtain credentials available in its environment. Exploitation requires no user interaction. The reporter confirmed the vulnerability in ComfyUI-Easy-Use version up to verion 1.4.1.

Unfortunately, the maintainer of ComfyUI-Easy-Use could not be reached to coordinate this vulnerability. To mitigate the vulnerability, remove the extension or restrict network access to ComfyUI to trusted users. The maintainer have released a fix in main as commit 8a0f2fc412.

Thanks to Nguyen Huy Hoang for reporting this vulnerability. This document was written by Alex Lewis and Michael Bragg.

Multiple vulnerabilities in the FrodoBots EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) may allow remote code execution, unauthorized access to onboard sensors, disclosure of sensitive information, and full compromise of affected devices. Exploitation may enable an attacker to remotely control the rover, access audiovisual streams, or pivot into the user’s network.

The FrodoBots EarthRover Mini+ is a compact, internet‑connected mobile robot used in educational and consumer environments. The device includes a camera, microphone, motor controllers, and multiple onboard services. Multiple vulnerabilities in the EarthRover Mini+ firmware (version 6.2.4_6.2.5_0.614.0) can allow remote code execution, unauthorized access to onboard sensors, exposure of sensitive data, and complete device compromise. An attacker could potentially take remote control of the rover, access its audio and video streams, or use it to gain a foothold in its network.

CVE-2026-121685: The firmware contains several sets of hard-coded, fleet‑wide credentials, including BasicAuth credentials for an Agora token service, AWS IAM (Amazon Web Services Identity and Access Management) access keys, Amazon Web Services Internet of Things Message Queuing Telemetry Transport (AWS IoT MQTT) credentials, and a Slack incoming webhook URL. Agora Token Service is an open source server that generates secure, time‑limited authentication tokens for use with Agora.io’s RTC (Real‑Time Communication) and RTM (Real‑Time Messaging) services. A Slack incoming webhook URL is a unique endpoint that lets external systems send messages into a Slack channel without the need for a full Slack application. These are embedded directly in frodobot.bin and are accessible through static analysis of the publicly downloadable firmware or from any device. Extraction requires no special privileges.

CVE-2026-121686: Unauthenticated remote command execution is allowed via Message Queuing Telemetry Transport (MQTT). A firmware method accepts arbitrary shell commands delivered via Amazon Web Services Internet of Things Message Queuing Telemetry Transport (AWS IoT MQTT) messages and executes them as root. Access is gated only by shared Internet of Things (IoT) credentials, with no per‑device authentication, enabling remote code execution (RCE) as root across the fleet. The IoT credentials are hard-coded in the firmware as discussed in CVE-2026-121685.

CVE-2026-121687: Several local interfaces are exposed without authentication. These services allow full local compromise of device functionality and provide access to sensitive information.
* HTTP REST API on port 80 (motor control, telemetry/GPS/IMEI) contains endpoints that reveal the plaintext Wi‑Fi password, enable Wi‑Fi join functionality, diagnostic export services
* Android Debug Bridge (ADB) root shell on port 5555
* SSH on port 22

CVE-2026-121688: The firmware contains an insecure STM32 update mechanism. STM32 is a family of 32-bit microcontrollers and is based primarily on Arm Cortex-M processor cores. They are widely used in embedded systems, IoT devices, industrial controls, robotics, automotive electronics, and consumer products. The STM32 motor‑controller firmware is fetched over unencrypted HTTP. Integrity is validated only via MD5, with the hash provided in the same unprotected response. No code‑signing mechanism is implemented, allowing firmware to be replaced with potentially malicious code.

CVE-2026-121689: The firmware exposes sensitive credentials through multiple insecure mechanisms. The Wi‑Fi PSK is stored in plaintext in wpa_supplicant.conf and is disclosed through unauthenticated API endpoints and diagnostic exports. Additionally, unauthenticated ADB access allows retrieval of the /etc/shadow file.

CVE-2026-121690: The firmware executes code with unnecessary privileges. All processes run as root and the system lacks privilege separation. The compromise of any single service results in full administrative control of the device.

Exploitation of these vulnerabilities may allow:
* Unauthorized access to live camera and microphone feeds.
* Fleet‑wide remote root access and full robot control via MQTT.
* Extraction of the user’s Wi‑Fi credentials and lateral movement onto the local network.
* Persistent compromise through tampered motor‑controller firmware.
* Unauthorized posting to the vendor’s Slack channels and potential exposure of backend infrastructure via IAM credential misuse.
* Given the rover’s mobility and sensor suite, exploitation may enable both digital and physical impacts.

As of this writing, the vendor has provided the following remediation status:

CVE-2026-121685 (Hard-coded credentials): Addressed

Most embedded credentials have been removed. One credential remains for requesting an Agora session token; backend authorization checks restrict misuse. Remaining credentials are limited to session‑bound operations.

CVE-2026-121686 (Remote command execution): Addressed

Arbitrary shell command execution has been removed. The device now supports only a small set of predefined management commands (e.g., reboot).

CVE-2026-121687 -- CVE-2026-121690. (Local interfaces and privilege model): Addressed or not remotely exploitable under current deployment model.

Local interfaces require connection to the device’s Wi‑Fi access point, which has a configurable password. The vendor asserts that an attacker must be physically near the device and connected to its Wi‑Fi network to exploit these interfaces. The firmware update process is manual and conducted through the local Wi‑Fi network.

The vendor validated changes via static analysis and internal implementation review, and considers the findings fixed, mitigated, or not applicable in the current deployment model.

Users are encouraged to update to the latest version of the FrodoBots EarthRover Mini+ firmware.

Thank you to Justin Davis for reporting these vulnerabilities. This document was written by Bob Kemerer.

PrestaShop's back-office Performance > Debug mode functionality contains a PHP code injection vulnerability. An authenticated attacker with permission to modify debug-mode configuration can submit crafted cookie configuration values that are written into an executable PHP configuration file. Successful exploitation could allow arbitrary code execution with the privileges of the PHP process.

PrestaShop is an open-source e-commerce platform for creating and managing online stores. Its back-office Performance configuration includes a Debug mode for developers, which is enabled based on a specified cookie name and value.

PrestaShop's debug-mode configuration code inserts the user-controlled values debug_cookie_name and debug_cookie_value into a PHP expression without adequately escaping or sanitizing them for use in PHP source code. The application writes this expression into the PHP define() statement in config/defines.inc.php or config/defines_custom.inc.php. A crafted value can terminate the intended string and introduce attacker-controlled PHP statements. The modified configuration file is loaded during application initialization, causing the injected code to execute on a subsequent request.

Exploitation requires an authenticated back-office account with permission to modify debug mode settings and a configuration file writable by the PHP process. Root or operating-system administrator privileges are not required. Cross-site request forgery (CSRF) protection helps prevent unauthorized requests made through another user's session, but does not prevent exploitation by an attacker controlling an account with the required permissions. Injected code executes with the privileges of the PHP process. Affected release versions remain to be confirmed.

An authenticated attacker with the required configuration permissions could execute arbitrary PHP code in the security context of the PHP process. This could allow access to application secrets and customer data, modification or deletion of application files and database contents, and disruption of store operations. Operating-system command execution depends on the PHP configuration and available functions. The vulnerability does not independently grant root privileges.

PrestaShop version 9.2.1 addresses this vulnerability. Administrators should upgrade affected installations to version 9.2.1 or later.
If an immediate upgrade is not possible, allow only trusted administrators to modify Performance and Debug mode settings, and restrict network access to the back office. Where operationally feasible, prevent the PHP process from writing to config/defines.inc.php and config/defines_custom.inc.php. This may also prevent legitimate configuration changes.

Thanks to Deflask13 for reporting this vulnerability. This document was written by Michael Bragg.

Multiple vulnerabilities have been identified in the Android application, BaseChat – Audio Dating App, version 9.8.1, which ultimately compromise the privacy of users’ personal data and activity.

BaseChat is an online dating platform built in Flutter and targeted toward users over 18. It facilitates anonymous, voice-first interaction between users. Three distinct vulnerabilities have been identified within the shipped Android application.
VU#124705.1: The application fails open when validating TLS server certificates for connections to its backend API host. The application allows any self-signed certificate to bypass standard TLS security checks.
VU#124705.2: Paid user accounts are mapped to a third-party RevenueCat subscriber database using raw MSISDNs (phone numbers), which are a guessable public identifier. Because the RevenueCat Software Development Kit (SDK) includes a public API key within the application’s Android Package Kit (APK), an attacker can query the RevenueCat’s API using predictable identifiers to retrieve individual user metadata.
VU#124705.3: The application writes Personally Identifiable Information (PII) to Android system logs in its production build. During voice calls, the application logs the remote party’s MSISDN through unstripped debug statements, which allows an attacker to recovery phone numbers of callers who are intended to remain anonymous.

Impacts of successful exploitation vary by vulnerability.
VU#124705.1: A network-positioned attacker can intercept and modify API communication, potentially leading to account takeover via session credential theft.
VU#124705.2: An attacker can locate the public RevenueCat SDK key and query the RevenueCat API using arbitrary phone numbers to retrieve associated user metadata, including activity and purchase history.
VU#124705.3: The personal data, or PII, of other users, intended to be anonymous, can be accessed through local system logs. The application’s backend sending other users’ MSISDNs to the client in any capacity presents a privacy violation.
These vulnerabilities have been confirmed against Basechat – Audio Dating App, Android version 9.8.1.

Unfortunately, Mobile Trading GmbH, the owners of BaseChat, could not be reached to coordinate this vulnerability.

Thanks to Mahmoud Ali Khan for reporting these vulnerabilities. This document was written by Alex Lewis.

INFINITT PACS installations using System Manager versions 3.0.11.3 and 3.0.11.5 contain vulnerabilities that may allow an attacker to execute arbitrary code. INFINITT Healthcare has remediated the issues in System Manager versions 3.0.12.3 and 3.0.12.5.

INFINITT PACS is an enterprise web-based medical imaging platform that stores, retrieves, and displays patient scans.

CVE-2026-16305
An improperly protected update manifest may allow a local attacker to execute commands with administrative privileges when an update is approved.
SmartExecute.exe reads and runs commands from execlist.txt after an update. Because of insecure file permissions on execlist.txt, a low-privileged attacker can modify the file before it is processed to add arbitrary malicious commands. After SmartUpdate.exe launches, it runs SmartExecute.exe and the user can be prompted by User Account Control (UAC), which can allow the malicious command to execute with administrative privileges.

CVE-2026-16306
An unsafe command dispatch through the registered imodular:// URI scheme may result in code execution.
A vulnerability in IModular.exe allows an attacker to execute certain application functions by supplying a crafted imodular:// link. The application reads the cmd value from the link and executes the corresponding function without verifying that the command is permitted or safe. By convincing an end user to open a crafted imodular:// link, an attacker can cause IModular.exe to access attacker-controlled files or run specific programs from a local folder or network share. The link also accepts a url parameter that causes IModular.exe to connect to an attacker-controlled SignalR endpoint, creating an unauthorized outbound connection.

Successful exploitation of CVE-2026-16305 may allow a local, low-privileged attacker to execute arbitrary commands with administrative privileges on the affected workstation. An attacker could then install or modify software, access protected files, disable security controls, or establish persistent access to the system.
Successful exploitation of CVE-2026-16306 may allow a remote attacker to execute code with the privileges of the affected user, access or modify data available to that user, and use the compromised workstation as a foothold for further attacks. The vulnerability may allow unauthorized outbound communication with an attacker-controlled SignalR server, potentially exposing sensitive information or enabling additional malicious activity.

There are no indications that these vulnerabilities have been exploited. INFINITT Healthcare recommends upgrading affected installations to one of the following fixed System Manager versions:

• System Manager 3.0.12.3
• System Manager 3.0.12.5

Organizations should apply the appropriate update as soon as operationally feasible.

Thanks to Piotr Berlinski from CyberArms.io for identifying these vulnerabilities, and to INFINITT for quickly addressing the problems. This document was written by Michael Bragg.

Fireblocks' mpc-lib library contains a cryptographic fail-open vulnerability in its BIP32 hardened derivation implementation in the case of a missing private parent key. This breaks the ancestor isolation property of hardened derivation, allowing an attacker with a compromised lower-level signer share to recover the higher-level share it was derived from.

Fireblocks is a digital-asset custody and wallet platform that secures the private keys behind cryptocurrency wallets for institutions and exchanges, using multi-party computation (MPC) so that no single machine ever holds a complete key.

Fireblocks’ key security pipeline contains two layers: MPC, which splits a single key into shares, and hardened derivation, which mathematically isolates each share from its key hierarchy. Normally, the derivation delta between parent and child keys is formed by hashing the private parent key, a derivation index, and associated metadata.

CVE-2026-90975 A fail-open vulnerability was identified within the BIP32 hardened derivation implementation which fails to reject operations where no parent secret is present. If a parent key is missing, the implementation substitutes the secret parent contribution with a null buffer. Because the buffer becomes a known constant, 0, the delta becomes computable, violating ancestor isolation.

An attacker who compromises a single MPC party's descendant signer share, and who knows the associated chain code, can compute the public derivation delta and subtract it to recover that party's ancestor share, repeating the operation up the hierarchy to obtain that party's root share. The isolation between derivation levels is reduced to a publicly computable scalar, so a single leaf-level share compromise extends to that party's shares across the entire key hierarchy managed by the MPC cluster.

The primary MPC secret-sharing layer still prevents reconstruction of a full private key from a single compromised party's shares, so this flaw does not by itself yield a spendable key. Its significance is the elimination of a defense-in-depth layer: hardened derivation no longer provides post-compromise ancestor isolation, threshold-security assumptions degrade as compromise propagates across derivation levels over time, and the downgrade occurs silently with no error or log signal. In BIP32 deployments where the chain code is treated as public, the precondition of knowing the chain code is trivially met.

At the time of writing, Fireblocks could not be reached to coordinate this vulnerability, and no vendor fix is available. Integrators can, however, reduce exposure with the following mitigations.

• Treat the chain code as secret. The attack is only available to a party that knows the chain code, because the derivation delta is computed as HMAC-SHA512(chaincode, ...). Chain codes should not be distributed in watch-only extended public keys or otherwise exposed to untrusted parties. Where a deployment can keep the chain code confidential, the delta is no longer publicly computable and ancestor-share recovery is not possible. This is the most effective mitigation available without a code change.

• Do not rely on hardened derivation for isolation between signer shares. Audit derivation paths for hardened segments and treat the compromise of any single share as potentially exposing that party's other shares across the derivation hierarchy.

A complete fix requires a change in the library.

Thanks to hodlturk for reporting this vulnerability. This document was written using AI assisted tools by Alexander Curtis and Alex Lewis.

vsomeip, COVESA's open source implementation of the SOME/IP automotive communication middleware, contained a memory allocation vulnerability present in versions 3.7.3 and below. A vsomeip reliable (TCP) SOME/IP endpoint grows its receive buffer to an attacker-declared message size before validating that the declared bytes have actually been received, allowing a remote, unauthenticated peer to exhaust host memory and deny service. The issue was reported publicly as COVESA/vsomeip issue #1009 and fixed in release 3.7.4 (2026-07-06).

CVE-2026-91141
vsomeip is a middleware implementation of the Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol, widely used for service-oriented communication between electronic control units (ECUs) in automotive and other embedded environments. A SOME/IP message begins with a 16-byte header that includes a 32-bit length field declaring the size of the message that follows.

A vulnerability was discovered in the handling of this length field on reliable (TCP) endpoints. When a message arrives, vsomeip grows its receive buffer to the size declared in the length field in order to read the incoming message, before confirming that those bytes have actually been received. In the default configuration, no size limit is applied to reliable endpoints, so a peer can declare a message size of up to roughly 4 GB and cause the receiver to allocate that memory. Because a freshly accepted connection reaches this path on its first message, no valid service, credentials, or SOME/IP authentication are required to trigger the allocation. The client endpoint contains the same behavior, where a malicious or compromised server can attack a connecting client.

Deployments that explicitly configure a reliable message-size limit are not affected.

This issue is publicly known. It was reported as COVESA/vsomeip issue #1009 (opened 2026-02-26) and fixed in release 3.7.4 (released 2026-07-06).

A remote, unauthenticated peer can force the host to allocate an attacker-chosen amount of memory, up to approximately 4 GB per connection, by sending a single short message on a normal TCP connection to any reachable reliable SOME/IP endpoint in the default configuration. On a memory-constrained node this can terminate the service outright: a service limited to 1.5 GB was OOM-killed by a single 16-byte message claiming a 3 GB payload. On a memory-rich host, the allocation for a single connection is released when the connection closes, so sustained memory exhaustion and denial of service follow from holding or repeating connections, each forcing its own allocation.

Upgrade to vsomeip 3.7.4 or later. This issue is fixed in release 3.7.4 (released 2026-07-06). The fix replaces the unlimited compile-time default (MESSAGE_SIZE_UNLIMITED) with a bounded DEFAULT_MAX_MESSAGE_SIZE of 10 MiB, so reliable endpoints reject an oversized declared length before growing the receive buffer even when no limit is explicitly configured. The release also adds a regression test for an oversized length field. The issue and fix are tracked publicly in COVESA/vsomeip issue #1009.

Deployments that cannot upgrade immediately should apply the following mitigations.

• Deployments can explicitly set max-payload-size-reliable (or the equivalent per-service reliable message-size limit) to a value appropriate for the service. Endpoints with such a limit configured reject oversized declared lengths and are not affected by this issue. This is the most effective mitigation available without upgrading.

• Because the vulnerability is reachable by any host that can open a TCP connection to a reliable SOME/IP endpoint, exposure should be minimized through network segmentation. Reliable endpoints should be confined to trusted, isolated in-vehicle or lab networks, and firewall or access-control rules should limit connectivity to known, authorized peers. SOME/IP endpoints should never be exposed to untrusted or external networks.

• Operators should monitor for anomalous memory growth on services offering reliable endpoints and for unexpected or repeated inbound TCP connections to SOME/IP ports, which may indicate attempts to exploit this vulnerability.

Thank you to the Jaafer Rahmani for reporting this vulnerability. This document was written by Alexander Curtis.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

This document was written by Laurie Tyzenhaus.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

This vulnerability note was prepared by Laurie Tyzenhaus.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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).

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.

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.

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.

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.

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

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.

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.

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.

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.

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.