Currently browsing: Security

Overview
A vulnerability in the zipx.Unzip extraction routine of Develar’s app-builder allows an attacker to overwrite arbitrary files on macOS using Apple File System (APFS). The issue arises from a combination of Unicode normalization collisions and unsafe symlink-following behavior. APFS treats certain Unicode equivalent filenames as identical (e.g., ß ↔ ss), while app builder performs no canonical normalization before validating or writing paths.
Description
Develar’s app-builder is a command‑line build tool used heavily in the Electron ecosystem to package, sign, notarize, and produce distributable application bundles for macOS, Windows, and Linux. It is popular because it is a transitive dependency of electron-builder, one of the most widely used packaging tools for Electron apps.
The vulnerability arises from how the zipx.Unzip routine handles Unicode‑equivalent filenames and symbolic links during ZIP extraction. APFS treats certain Unicode representations as identical (e.g., ß and ss), but app-builder does not perform canonical normalization before validating output paths. As a result, an attacker can craft ZIP archives that combine Unicode normalization collisions with malicious symlinks to redirect writes outside the intended extraction directory.
The GitHub Pull Request addresses the symlink-following variant of this vulnerability (CWE‑22 and CWE‑59) by rejecting any symlink whose resolved target escapes the intended output directory and by adding O_NOFOLLOW to regular file writes. Without these protections, an attacker can craft ZIP archives containing malicious symlinks and Unicode-colliding filenames to overwrite arbitrary files on APFS-backed systems.
Impact
Exploitation of this vulnerability allows an attacker to overwrite arbitrary files on macOS systems using APFS. By combining Unicode normalization collisions with symlink‑following behavior in the zipx.Unzip routine, an attacker can craft ZIP archives that bypass path‑validation checks and redirect writes outside the intended extraction directory. This may result in loss of integrity, denial of service, or potential code execution, depending on which files are overwritten. Because APFS treats certain Unicode‑equivalent filenames as identical, the attack can evade typical sanitization logic unless canonical normalization is enforced. The vulnerability is exploitable during ZIP extraction without requiring elevated privileges.
Supply-chain Impact
Develar’s app-builder is widely used as a dependency across the ecosystem, affecting numerous downstream repositories. Several projects have already mitigated their exposure, while others may still be affected. A complete remediation requires fixing the vulnerability at its source.
Solution
Develar has not responded to several emails or to issues posted in the GitHub repository requesting contact. The reporter has developed a Pull Request to provide downstream customers with a reference fix and to enable them to analyze the vulnerable code or implement their own patches: https://github.com/develar/app-builder/pull/163
Acknowledgements
CERT/CC thanks the reporter, Tomas Illuminati, Cyber Security Researcher & Threat Intelligence Specialist, for assisting many downstream vendors and developers in mitigating this issue.
We also thank Electron-Userland for responding quickly and implementing a mitigation to protect their downstream users.
This AI-assisted vulnerability note was prepared by Laurie Tyzenhaus.

Overview
A vulnerability has been discovered in the OPeNDAP Hyrax software solution. A remote attacker with the ability to submit crafted requests to an affected Hyrax instance could cause the application to communicate with unauthorized remote systems. Under certain conditions, the vulnerability may also result in the unintended disclosure of user authentication tokens to unauthorized destinations.
Description
CVE-2026-16637
OPeNDAP Hyrax is vulnerable to Server Side Request Forgery (SSRF) and credential disclosure via unvalidated HTTP redirects that bypass the AllowedHosts allowlist and leak Earthdata headers (User-Id, Echo-Token) to attacker-controlled endpoints.
OPeNDAP Hyrax is an open-source data server software that enables remote access to scientific datasets over the internet using the OPeNDAP protocol. It allows users to query, subset, and retrieve data in various formats (such as NetCDF, HDF, or GrADS) without downloading entire files. OPeNDAP Hyrax uses a list of allowed hosts, specified through a regular expression, to limit where it can fetch data. When a requested server responds with a redirect, HTTP 3xx, the software follows the redirect without checking whether the new destination is still on the allowed list. This behavior enables an attacker to redirect the system to an untrusted or internal target that would otherwise be blocked. Additionally, when the system follows such a redirect, it may carry certain user identification headers, including a legacy credential called Echo-Token, to the new destination, even though the main authorization token is correctly stripped by the underlying library.
Impact
Successful exploitation could allow an unauthenticated remote attacker to access internal services that are not intended to be reachable from the internet. If a user is authenticated when exploitation occurs, the attacker may also obtain the user’s Earthdata identifier and a reusable legacy credential. These credentials could be used to access protected datasets or other resources as the affected user.
Solution
The CERT/CC is currently unaware of a practical solution to this problem. OPeNDAP has been notified and is working to develop a patch that will be released shortly, if it hasn’t already. Administrator of Hyrax server are advised to review their allowed host configurations carefully and consider limiting exposure of the gateway endpoint to trusted networks until the fix is available, likely in versions Hyrax-1.18.0 or later.
Acknowledgements
Thanks to the Juan Salvador Sleibe for reporting this issue. This AI-assisted document was written by Timur Snoke.

Overview
Firmware versions 2.7.7 and earlier of the Arris BGW210-700 residential gateway contain an authentication bypass vulnerability, tracked as CVE-2026-16771, that allows any unauthenticated LAN-side user to read sensitive configuration data and modify device settings through web management endpoints. Although this vulnerability was recently discovered, the majority of in-service gateways are not expected to be running the affected version. Only devices that have not received automated ISP-managed firmware updates since version 2.7.7 in 2020 are vulnerable.
Description
The Arris BGW210-700 is a residential gateway used widely in AT&T deployments to provide routing, wireless networking, and wide-area network (WAN) connectivity for home users. The device exposes a browser-based management interface on the local-area network (LAN) side that allows users to configure WiFi settings, check diagnostics, and run system operations.
Several CGI (Common Gateway Interface) handlers within the BGW210-700’s web interface do not enforce any server-side authentication checks. Although the interface presents an “Access Code” prompt to users, this restriction is entirely implemented through client-side HTML and JavaScript and is not validated by the server before processing requests. As a result, any HTTP client that ignores client-side code can directly access and interact with the underlying CGI endpoints.
The lack of server-side authentication affects multiple configuration and diagnostic pages. The wconfig_unified.ha endpoint returns the plaintext WiFi pre-shared key for all configured SSIDs to any unauthenticated requester. The broadbandconfig.ha endpoint accepts unauthenticated POST requests that directly modify WAN configuration parameters, including settings that persist across device reboots. Additional diagnostic endpoints, such as diag.ha, allow unauthenticated triggering of backend diagnostic jobs.
Impact
This vulnerability allows any unauthenticated user on the LAN, including devices connected to the gateway through the main WiFi network, Guest WiFi network, or LAN ethernet, to read sensitive configuration information and make persistent changes to gateway settings. A local attacker can retrieve the network’s plaintext WiFi password with a single HTTP request and achieve unauthorized access to manipulate, intrude on, and interfere with protected networks.
Solution
This gateway is ISP-managed, so all standard internet-connected devices are expected to have been automatically updated to newer unaffected versions. Users can determine their active version by checking their router’s diagnostic settings via web browser, and optionally contact their ISP to confirm that automatic updates are functioning correctly. Because the vulnerability is limited to the LAN-side management interface, standard network hygiene practices such as isolating untrusted devices, keeping IoT systems updated, and monitoring for the presence of unknown clients can further reduce risk in environments where older firmware may still be present.
Acknowledgements
Thanks to David Weekly for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
The Logto platform contains multiple vulnerabilities affecting the identity‑processing pipeline. These flaws reduce the reliability of authentication and authorization decisions and may allow attackers to bypass account‑ownership checks, skip MFA, replay externally issued SSO responses, or submit identity assertions without proper cryptographic or validity checks. Collectively, the issues create several paths for unauthorized access across both local and federated sign‑in flows.
Description
Developed by Silverhand Inc., Logto is an identity and access management system for software as a service (SaaS) and AI applications. It provides multi‑tenant authentication, single sign-on (SSO), role-based access control (RBAC), support for openId connect (OIDC), open authorization (OAuth) 2.1, and Security Assertion Markup Language (SAML) authentication. Several vulnerabilities have been identified in Logto’s authentication and SSO components that weaken core identity‑security protections across these protocols.
CVE-2026-15611
Logto allows unverified email-based SSO account linking. If a new SSO login arrives and no existing (issuer, identityId) account is found, Logto searches for a local user by the email address supplied by the identity provider (IdP) and links the SSO identity to that account. Logto does not require the IdP to confirm email_verified before linking, so an attacker who registers the victim’s email at a permissive upstream IdP can take over the victim’s existing account on first login.
CVE-2026-15612
Logto stores a nonce in the connector session at authorization request time and expects the returned id_token to echo it back. The validation check is guarded by if (data.nonce), so when an id_token omits the nonce claim entirely, the check is skipped, even when nonceFromSession is set.
CVE-2026-15614
Logto does not atomically handle IdP-initiated SAML sessions. Session lookup and session deletion are two separate steps, and because the lookup response is returned before the deletion finishes, any deletion errors are silently discarded. Two requests presenting the same session identifier in close succession can both pass the lookup before either deletion completes, allowing the same IdP-initiated assertion to authorize two separate sign-ins.
CVE-2026-15615
Logto’s SAML implementation relies on the samlify library to validate the Conditions element, but samlify’s check is bypassed whenever the Conditions element is absent from the assertion. An attacker who omits Conditions from a forged or replayed assertion bypasses the NotBefore and NotOnOrAfter time window check entirely, and Logto adds no independent validation of its own.
CVE-2026-15616
Logto’s authentication process does not enforce locally configured multi-factor authentication (MFA) when a user signs in via SSO. MFA is bypassed when hasVerifiedSsoIdentity is true. As a result, an attacker with a federated identity from a permissive upstream IdP can bypass the local MFA requirement by signing in through SSO.
CVE-2026-15617
Logto performs strict, unnormalized comparisons on identity attributes (email domains, issuer identifiers, and identity IDs) during SSO flows. The absence of case, whitespace, and Unicode normalization leads to inconsistent domain‑rule enforcement and incorrect resolution of linked identities, allowing sessions to bind to unintended local accounts.
Impact
Collectively, the vulnerabilities in Logto’s authentication and SSO infrastructure fail to implement core identity protections across the OIDC, OAuth 2.1, and SAML protocols. These flaws can interact in ways that allow attackers to evade account‑ownership checks and MFA, replay federated sessions, and inject unvalidated or unsigned identity assertions.
Solution
Mitigations
Unfortunately, Silverhand Inc. could not be reached for coordination of these vulnerabilities. Until a patch is available, administrators can reduce the attack surface by implementing the following defensive measures:
* Where possible, avoid provisioning local accounts with the same email addresses that will be used for federated sign-in, since Logto does not currently expose a setting to disable automatic email-based account linking.
* Avoid using Logto’s “social SAML” connector entirely.
Require MFA at the upstream IdP for all federated sign‑ins.
Enforce strict domain normalization at the IdP or provisioning layer.
Shorten session lifetimes and aggressively invalidate sessions.
Monitor authentication logs for anomalies.
* Place Logto behind an identity‑aware reverse proxy.
Acknowledgements
Thanks to the reporting team:
Zixu (Jason) Zhou (PhD student), Professor David Lie, Ilya Grishchenko (Postdoc), and Xiangyu Guo (PhD student) of the University of Toronto. This AI-assisted vulnerability note was prepared by Laurie Tyzenhaus.

Overview
Duplicati v2.3.0.1 is vulnerable to arbitrary code execution when installed outside the default C:Program FilesDuplicati 2 directory. An attacker with local user privileges who can write files to the Duplicati installation directory can execute arbitrary code by placing malicious files, such as DLLs, in that directory. To mitigate this vulnerability, install Duplicati in the default C:Program Files directory or update to the latest fixed version.
Description
Duplicati is a free, open-source backup solution that stores data across cloud and local storage platforms. On Windows, Duplicati is distributed as an MSI installer. By default, the installer deploys the application to C:Program FilesDuplicati 2, where the directory inherits the standard protected ACLs provided by Windows.
The following vulnerability affects Duplicati v2.3.0.1:
CVE-2026-16157 During installation, the MSI registers a LocalSystem service that executes binaries from the Duplicati installation directory. When the default installation path under C:Program Files is used, the directory is protected by the appropriate ACLs. However, if Duplicati is installed to a non-default location, the installer does not apply equivalent permissions to the installation directory. As a result, standard local users may have write access to files within the installation directory, allowing an attacker to place malicious files, such as DLLs, that may be loaded by the LocalSystem service, resulting in arbitrary code execution with elevated privileges.
Impact
A local attacker with write access to a non-default Duplicati installation directory can replace or introduce DLLs used by the Duplicati service. Upon service restart, the Windows loader loads the attacker’s DLL before any managed code is executed, allowing arbitrary code to run with NT AUTHORITYSYSTEM privileges.
Solution
Install Duplicati in the default installation directory (C:Program FilesDuplicati 2). If a non-default installation directory is required, ensure it is manually configured with ACLs that provide equivalent protections to those applied under the C:Program Files directory. Additionally, install all vendor patches and updates that address this vulnerability. See Vendor Information for details
Acknowledgements
Thank you to Valton Tahiri for discovering and reporting this vulnerability. This document was written by Bob Kemerer.

Overview
Version 3.5.8 of Analog Way’s Picturall Quad Compact Mark II server contains a local privilege escalation vulnerability, tracked as CVE-2026-14985, due to improper privilege delegation and insufficient input validation in a maintenance script.
Description
The Picturall Quad Compact Mark II is a compact, heavy-duty 8K media server developed by Analog Way for video playback and content management in professional audiovisual environments.
The core firmware includes a maintenance script called create_local_installer.sh, and the default script permission allows the low-privileged user, picmedia, to execute it as root and without a password. An attacker creates a malicious Ext4 disk image that contains the file, picturall-version.txt, with a directory traversal string and a payload file. create_local_installer.sh reads input from picturall-version.txt when processing these attacker-supplied disk images. This input is not properly sanitized, allowing an attacker to supply directory traversal sequences. As a result, the attacker can manipulate the script to write files outside of the intended extraction directory and execute a malicious payload.
Because the script executes with root privileges, this behavior enables arbitrary file writes to sensitive system locations such as `/etc/cron.d, a system directory in Unix/Linux operating system used to store system-wide task scheduling files. An attacker can then leverage this capability to execute arbitrary code with root privileges.
Impact
By exploiting this path traversal vulnerability, an attacker with local access to the device can write arbitrary files to privileged locations. This access allows modification of scheduled tasks, and system configuration files. It can also allow the execution of a[RM2.1][MB2.2]rbitrary commands with full system privileges.
An attacker does not need valid root credentials to enable straightforward and repeatable exploitation, resulting in complete system compromise.[RM3.1][MB3.2] This constitutes a Technical Impact = Total under the SSVC framework, meaning:

The vulnerability gives the adversary total control over the behavior of the software or total disclosure of all information on the affected system.

Solution
Analog Way has released version 3.5.9 to address this vulnerability. Users are strongly encouraged to update to the fixed release as soon as possible.
Acknowledgements
Thanks to the reporter James Tully for responsibly disclosing this issue. This document was written by Michael Bragg.

Overview
The project management tool Plane, versions 1.3.0 and earlier, contains a multi-tenant authorization bypass vulnerability in its asset-management API that allows unauthorized users to access, delete, or duplicate assets that belong to other workspaces.
Description
Plane is an open-source project management platform that provides multi-tenant workspace isolation for users to track issues, monitor progress, and manage workflows. The platform’s API supports uploading, retrieving, deleting, and duplicating files associated with issues and tasks within a workspace.
CVE-2026-15342 Plane’s asset-management API endpoints accept workspace slugs and asset identifiers as path parameters, but do not verify that the requesting user is authorized to access the specified workspace. As a result, an authenticated user in one workspace can supply the slug and asset ID of a different workspace when sending requests, which enables them to perform unauthorized read, duplicate, or delete actions on the other workspace’s assets.
To exploit this vulnerability, an attacker must authenticate to any existing Plane workspace, including their own, and know the slug and asset ID belonging to the victim workspace. These identifiers can be obtained from sources such as public or semi-public issue/board URLs, attachment download links, or exported API data.
Impact
The ability to bypass workspace-level tenant isolation enables an attacker to exfiltrate sensitive files, destroy project data, and create permanent copies of victim assets inside their own workspace.
Solution
Unfortunately, the CERT/CC was unable to reach Plane to coordinate this vulnerability, and a patch is not yet available.
Mitigations
Users and organizations can reduce their risk by implementing API-gateway rules, firewall restrictions, or other network controls to limit access to the vulnerable endpoints. Detailed activity logging and security alerts should be enabled to monitor for cross-workspace asset requests, unusual presigned URL activity, or unexpected delete operations.
Acknowledgements
Thanks to Weeraphat Srisutham for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
A denial-of-service (DoS) vulnerability exists in some HTTP/2 server implementations that fail to adequately limit resource consumption when buffering response data under stalled flow-control conditions. A remote, unauthenticated attacker can trigger memory exhaustion and service interruption by using standard flow-control parameters such as SETTINGS_INITIAL_WINDOW_SIZE = 0 to stall outbound data for multiple simultaneous request streams.
Description
HTTP/2 is a widely used application-layer protocol that supports multiplexing, header compression, and flow-control mechanisms to regulate the transmission of data between web browsers and servers. Flow control is designed to prevent senders from overwhelming receivers and relies on client-advertised window sizes to determine the maximum volume of unacknowledged data that can be in transit at any given time.
A client can intentionally stall outbound flow control by withholding WINDOW_UPDATE frames or by advertising SETTINGS_INITIAL_WINDOW_SIZE = 0. In some HTTP/2 implementations, the server continues processing requests and generating complete response bodies even though it is unable to transmit them. The resulting response data remains buffered in memory, and each stalled stream retains its allocated buffer until the connection closes or a timeout occurs.
An attacker can exploit this behavior by opening many simultaneous streams and requesting large resources, causing the server to accumulate large amounts of buffered response data. In environments with permissive resource limits, this can lead to excessive memory consumption, swap exhaustion, service instability, and, in severe cases, system crashes. Even under more conservative limits, the attack can exhaust worker or connection resources and degrade service availability.
Impact
A remote, unauthenticated attacker can cause denial-of-service conditions on affected HTTP/2 server implementations. Under high resource limits, an attacker may be able to induce unbounded memory amplification resulting in OOM kills, severe swap thrashing, or full system unresponsiveness. Under default or lower limits, the attack can exhaust available connections or worker resources, temporarily preventing new clients from establishing sessions and degrading overall service availability.
Solution
Several vendors have addressed this vulnerability in recent updates; see the Vendor Information section for individual CVEs and remediation details. Implementations that enforce memory ceilings, restrict concurrent stream counts, and actively terminate stalled connections can substantially reduce the risk of denial-of-service conditions.
Acknowledgements
Thanks to the Okta Red Team for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
A Pickle deserialization vulnerability has been discovered within the SGLang project, enabling an attacker to perform remote code execution (RCE) on the target vulnerable server. In order for an attacker to exploit this vulnerability, the expert-parallel backup subsystem must be enabled, and an attacker must have network access to the SGLang service. No patch is available at this time, and no response was obtained from the project maintainers during coordination.
Description
SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. A vulnerability has been discovered within the tool and is tracked as follows:
CVE-2026-14890
SGLang uses an expert-parallel backup subsystem designed to handle the large amount of compute and memory constraints associated with different model types. This system, when running, exposes a ZeroMQ PULL socket on a routable network interface that does not contain authentication or deserialization safeguards, allowing an attacker to provide a malicious pickle file that results in unauthenticated remote code execution when the feature is enabled and the service is reachable over the network.
The vulnerability is caused by the ZeroMQ PULL socket in expert_backup_manager.py binding to an external IP address with no authentication, meaning that any process that can reach the endpoint can send a payload that eventually gets deserialized with Pickle. This vulnerability is structurally similar to CVE-2026-7301 and CVE-2026-7304 in that it enables unauthenticated remote code execution via unsafe deserialization of data through pickle.loads(), but differs by occurring in the expert-parallel backup subsystem, rather than the multimodal scheduler or custom logit processor interfaces.
Impact
If exploited, this vulnerability could allow an unauthenticated attacker to achieve remote code execution on the host running SGLang. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.
Solution
Until a patch is available, affected users should consider the following mitigations:
Mitigations

Restrict access to the service interfaces and ensure they are not exposed to untrusted networks.
Implement network segmentation and access controls to prevent unauthorized interaction with the vulnerable endpoints.
Change SGLANG_USE_PICKLE_IPC to “false” within environ.py.

The SGLang maintainers have made strides in addressing pickle deserialization vulnerabilities, and have begun to work to refactor the code base with msgpack to prevent deserialization issues such as CVE-2026-14890, but the SGLANG_USE_PICKLE_IPC defaults to true within the codebase at the time of writing.
Acknowledgements
Thanks to the reporter, edwardav970@gmail.com.
This document was written by Christopher Cullen.