Currently browsing: Technology

Overview
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.
Description
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.
Impact
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.
Solution
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.
Acknowledgements
Thanks to hodlturk for reporting this vulnerability. This document was written using AI assisted tools by Alexander Curtis and Alex Lewis.

Overview
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).
Description
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).
Impact
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.
Solution
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.

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

Overview
Two memory-related vulnerabilities have been identified in PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. An unauthenticated remote attacker with network access to PHP web services can exploit these vulnerabilities via specially crafted HTTP requests to potentially achieve arbitrary code execution.
Description
PHP is a widely used open-source scripting language designed for web development and server-side applications. It powers millions of websites and web applications worldwide and can be deployed through a variety of server configurations, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
CVE-2026-109618: A memory corruption vulnerability exists in the out-of-memory (OOM) handling mechanism of PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The vulnerability occurs when an OOM condition interrupts request processing while internal request data is only partially initialized; subsequent cleanup routines may access the invalid memory, potentially causing memory corruption and enabling arbitrary code execution.
CVE-2026-109619: A use-after-free vulnerability exists in the global state management of PHP versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The vulnerability occurs when a worker retains a reference to request-owned state after its backing memory has been freed. A subsequent request handled by the same worker can access this stale state before normal request initialization resets it, potentially causing memory corruption and enabling arbitrary code execution.
Impact
Successful exploitation of these vulnerabilities allows an unauthenticated attacker to remotely execute arbitrary code via specially crafted HTTP requests, compromising the confidentiality, integrity, and availability of the web service and underlying infrastructure. Apache mod_php deployments are at particularly high risk, as proof-of-concept exploitation has demonstrated that unauthenticated requests can trigger the attack before any application code executes.
Solution
Refer to the Vendor Information section below for newly patched versions of PHP that remediate these vulnerabilities. All PHP users are strongly encouraged to update immediately to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12. Source downloads are available on the official PHP release page at php.net/downloads.
Linux users are advised to check with their distribution vendor for updated packages, as many distributions received patches in advance. For PHP 8.1 and older versions that no longer receive official updates from the PHP project, contact your LTS vendor for backported fixes or upgrade to a supported version. The PHP security team has provided limited source backports for PHP 7.4, PHP 8.0, and PHP 8.1 to assist users building from source or without access to an LTS vendor.
If immediate patching is not feasible, the following temporary mitigation measures may reduce exposure to specific attack paths, though they do not provide complete protection. Because these vulnerabilities are closely related, mitigations for both CVEs should be applied:
For CVE-2026-109618 (OOM Corruption):

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

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

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

System owners can limit the potential impact of successful exploitation by implementing network segmentation and ensuring that PHP installations are configured to run with minimum necessary privileges. Users are advised to monitor closely for unusual PHP process behavior or unexpected memory allocation patterns.
Acknowledgements
Thanks to OpenAI, Wiz, and Ryan at Calif.io for reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview
An authentication bypass vulnerability in the Xerj Console API allows sessions to bypass passkey-backed requirements during token issuance. By exploiting this flaw, an attacker with an existing valid token can create independent, persistent successor credentials directly through the console API. This allows the attacker to maintain access and potentially escalate privileges within the Xerj ecosystem, even if the initial token is revoked.
Description
Xerj is an open-source search and indexing engine tailored specifically for AI agents utilizing the Elasticsearch API, allowing AI models to query a structured index.
The vulnerability, CVE-2026-97406, stems from a flaw in how session states are authenticated and handled within the Xerj system architecture. According to the documented security contract, the issuance of new API tokens must be strictly authorized by a passkey-backed session. However, the Xerj implementation converts both standard browser sessions and API bearer tokens into the same generic AuthSession object. The token creation handler then accepts this generalized principal without verifying whether the session was authenticated via a passkey.
Because of this architectural oversight, an attacker who obtains or intercepts a valid Xerj API token can directly invoke the token creation endpoint, allowing them to create independent successor credentials with the same access levels of the original token. Furthermore, the Xerj platform lacks hierarchical revocation logic; consequently, revoking a compromised parent token has no effect on any descendant tokens spawned from it.
Impact
Exploiting this vulnerability allows an attacker to gain persistent, unauthorized access that completely bypasses multi-factor controls. The security risk escalates significantly if the compromised token belongs to a Xerj account owner. In this scenario, the newly created successor token retains full administrative authority. An attacker can use this persistent access to issue a new account invitation, redeem it in their own browser, and successfully enroll an entirely independent, attacker-controlled passkey. This grants the attacker permanent control over the Xerj instance and its sensitive data indices, rendering the revocation of the initial token completely ineffective.
Solution
The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project’s GitHub repository for updates and install the latest version of this library once a fix has been released.
Acknowledgements
Thanks to the reporter, Shiran Guez, a Principal Application Security Architect.
This document was written by Laurie Tyzenhaus.

Overview
Five Name Constraints findings in BoringSSL (VU#410595.8–.12) describe cases where certificate names may not be constrained as intended. Records .8, .9, .10 and .12 concern the legacy crypto/x509 path; .11 concerns the newer pki path. Two have been fixed, one is accepted, one is disputed, and one was declined.
Description
Name Constraints limit the names a subordinate certificate authority may issue. The reports concern how BoringSSL applies those limits to certain SAN (Subject Alternative Name) forms. The records do not share one status, and they do not all affect the same validation path.
VU#410595.8 (Fixed 2026-03-04): A wildcard DNS name may not be treated as covering a specifically excluded host.
VU#410595.9 (Accepted): A URI with a colon before @ may cause the wrong host to be used when matching URI constraints.
VU#410595.10 (Disputed): The finding concerns first-@ domain extraction in rfc822Name constraint matching. How consuming mail applications interpret the submitted multi-@ input, and whether that creates deployment exploitation, was not established.
VU#410595.11 (Rejected): Trailing-dot handling in rfc822Name domains. The BoringSSL team declined this on 2026-02-28 as below its security threshold.
VU#410595.12 (Fixed 2026-03-04): Trailing-dot DNS names were not always normalized on the legacy validation path.
Using BoringSSL in a product does not mean that product invokes an affected path or name form.
Impact
These findings matter only where Name Constraints are enforced on an affected path, a trusted signature can be obtained over attacker-chosen SAN fields, and the accepted name is used for authorization. Mixed-library environments may accept or reject the same certificate differently. Presence of BoringSSL does not, by itself, mean that Chrome, Android, or other products are affected.
Solution
BoringSSL fixes land in the upstream repository and reach products through each product’s own update process.

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

CERT/CC is not coordinating BoringSSL fixes. For vendor status, contact the BoringSSL team through the Google Issue Tracker. Operators should confirm whether their deployment uses an affected path, apply available updates, and keep issued SANs well formed. A second validator helps only when it uses the same inputs and fails closed.
Acknowledgements
Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Overview
This note covers thirteen library-specific records (VU#948176.6, .8–.19) of how widely used TLS libraries apply X.509 Name Constraints. The records describe cases where a constrained name may be accepted by one library and rejected by another. Some are fixed, some remain under review, and some were not accepted as security issues.
Description
Name Constraints are meant to keep a subordinate CA inside an allowed namespace. The records cover several name forms and do not all have the same classification. VU#948176.7 does not exist.
DNS case-sensitivity and wildcards. While RFC 5280 requires case-insensitive DNS matching, it does not explicitly define wildcard Subject Alternative Name (SAN) matching, leading to varied implementation behaviors. For instance, GnuTLS was found to perform case-sensitive comparisons on certain names (CVE-2026-3833, fixed in 3.8.13). Similar discrepancies regarding case handling in wildcard parent-constraint lookups were reported in Go, as well as wildcard inconsistencies in LibreSSL and wolfSSL. Additionally, pyca/cryptography was identified to check DNS Name Constraints against certificate SANs but failed to validate them against the requested peer name (CVE-2026-34073, fixed in 46.0.6).
IP addresses. Some libraries treat IPv4 and IPv4-mapped IPv6 forms as different when matching constraints. The Go security team determined that report did not meet its security bar; similar reports exist for Apple’s Security.framework and Mozilla NSS and are included as comparative evidence.
URIs. Libraries can differ on which host they extract from a URI SAN. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report remains in triage. Related URI reports exist for Apple, NSS, and wolfSSL (CVE-2026-3547, fixed in 5.9.0). A well-formed single @ is handled per RFC 3986 by most implementations.
Common Name fallback. AWS-LC and s2n-tls were reported to apply DNS constraints inconsistently when a leaf has no SAN and uses a wildcard Common Name. The AWS-LC wildcard-CN issue has been fixed; a separate Unicode CN question remains under coordination. s2n-tls is in triage.
Non-critical constraints. In the reported Mbed TLS configuration, non-critical Name Constraints are not enforced. RFC 5280 requires conforming CAs to mark the extension critical, and the reviewed Mbed TLS 3.x configuration rejects unsupported critical extensions. The vendor treats adding support as a feature request; the reporter’s concern remains disputed.
Impact
These records matter only when an attacker can obtain a trusted signature over chosen certificate fields, reach an affected validation path, and the application uses the accepted identity for authorization. Validator disagreement alone is not exploitation. Effects, if any, are deployment-specific and may include acceptance of a name outside the intended namespace.
Solution
CERT/CC is coordinating remediation across the affected projects. The following summarizes available status; individual entries reflect different reporting and confirmation dates.
GnuTLS — CVE-2026-3833 fixed in 3.8.13.
pyca/cryptography — CVE-2026-34073 fixed in 46.0.6.
wolfSSL — CVE-2026-3547 fixed in 5.9.0. The wildcard was addressed in PR# 9991.
Go’s crypto/x509 — Two reports are in triage. The IPv4-mapped IPv6 report was not accepted as meeting the project’s security bar.
OpenSSL — PR #30319 was merged and, as confirmed on 10 September 2026, is present in all then-current publicly supported versions. The separate userinfo-colon report remains in triage.
Apple’s Security.framework — Three reports submitted on 2026-03-16 remain in triage.
Mozilla NSS — IP-address report under coordination.
LibreSSL — Wildcard report under coordination.
AWS-LC — Wildcard CN issue fixed; Unicode CN report under coordination. s2n-tls is in triage.
Mbed TLS — Non-critical Name Constraints are not enforced in the reported configuration. Marking the extension critical causes such chains to fail closed rather than adding enforcement.
Until updates are widely deployed, operators who depend on Name Constraints should confirm the behavior of the libraries they actually run, keep leaf certificates to explicit SANs, and treat issuance policy as the first control. A second validator helps only when it uses the same inputs and fails closed.
Acknowledgements
Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.

Overview
Bisheng contains three vulnerabilities: a pre-authentication account takeover mechanism via a legacy single sign-on (SSO) endpoint; an Insecure Direct Object Reference (IDOR) vulnerability that exposes cross-user workflow data; and prior to version 2.5.0, authenticated attackers could perform cross-user LLM credential abuse and data disclosure due to missing service-layer access checks. Together, these flaws could allow unauthenticated attackers to gain administrative control while enabling authenticated users access to sensitive data and hardcoded credentials.
Description
Bisheng is an open-source Large Language Model (LLM) application DevOps platform, developed by DataElement, designed to assist in building, managing, and scaling LLMs.
CVE-2026-96679 (Legacy SSO Bypass) A vulnerability resides in the legacy SSO endpoint (POST /user/sso). The application processes incoming JSON payloads containing arbitrary usernames and issues a valid JSON Web Token (JWT) without enforcing any form of caller authentication, such as signature verification, shared secrets, or network allowlisting. Furthermore, if the provided username does not exist, the system automatically registers the account. If this newly generated account matches the configured administrative username or is the first user in the system, it is automatically granted super-administrator privileges.
CVE-2026-96681 (IDOR Workflow Exposure) There are missing authorization controls across multiple version retrieval endpoints. The underlying source code retrieves flow and workflow version records based on user-supplied parameters without performing any data ownership or permission validation. Any authenticated user can query and read the complete Domain-Specific Language (DSL) configurations belonging to other accounts.
CVE-2026-100156 (Credential Abuse & Access Control Skip) Within the assistant service’s prompt auto-optimization feature, endpoints accept an assistant identifier from the caller without verifying whether the caller owned that assistant. An assistant identifier is a mechanism that lets users or systems recognize that content or interactions come from an AI assistant rather than a human.
Impact
Authentication Bypass / Account Takeover: The legacy SSO vulnerability (CVE-2026-96679) allows unauthenticated attackers to bind their session to an existing victim’s profile by completely skipping JWT validation, potentially granting full super-administrative access, leading to full application compromise.
Unauthorized Data Disclosure: The IDOR vulnerability (CVE-2026-96681) causes a breach of data confidentiality, as the system fails to properly validate whether the authenticated user has permission to access the resource.
Resource and Credential Abuse: The assistant service vulnerability (CVE-2026-100156) allows authenticated attackers to run unauthorized AI inferences billed directly to another user’s provider account (such as OpenAI, Azure, or Anthropic), while also leaking the victim assistant’s configured tools and workflows.
Solution
The vendor has addressed two of the three discovered vulnerabilities in subsequent software releases. CERT/CC recommends upgrading to patched releases.
CVE-2026-100156: The vendor has remediated the assistant service vulnerability in version 2.5.0.
CVE-2026-96681: The vendor has remediated the IDOR workflow vulnerability in version 3.0.0.
For the remaining unpatched vulnerability (CVE-2026-96679), DataElement/Bisheng has not responded to multiple coordination efforts. CERT/CC suggests implementing the manual mitigations below until an official update becomes available.
CVE-2026-96679 Legacy SSO Vulnerability: Administrators should consider the following defensive measures:

Avoid setting BISHENGPRO=true in the environment configuration.
Disable or deprecate the legacy SSO endpoint entirely, or enforce global JWT validation. The affected function is sso(), located in src/backend/bisheng/user/api/user.py, affecting the API endpoint POST /user/sso.
Restrict access to the POST /user/sso network path to loopback/same-origin to provide defense-in-depth.

Acknowledgements
Thanks to Louis Sanchez, Voke Cyber, for reporting these vulnerabilities.
This vulnerability note was prepared by Laurie Tyzenhaus.

Overview
Versions <= 2.2.0 of Periphery, an agent within the Komodo server management platform, is vulnerable to OS command injection due to missing validation of container names, through two vectors: container destruction and container log searches. This allows an authenticated attacker to execute arbitrary commands as root on the underlying host, enabling persistent compromise of infrastructure.
Description
Komodo is an open-source server and deployment manager, maintained by mogh.tech, widely used in self-hosted and Docker multi-server environments. Periphery is an agent service installed on servers to give Komodo control over Docker environments.
In vulnerable versions of Komodo, Periphery does not properly validate user-supplied Docker container names before those values are interpolated into shell commands used by the agent. Two operations exhibit this vulnerability: container destruction (DestroyContainer / RemoveContainer) and container log searches (SearchContainerLog / GetContainerLogSearch). Through both avenues, raw container names are directly inserted into sh -c command lines without any shell escaping or validation. These commands then run with Periphery’s root privileges on the host OS and Docker socket.
Impact
An authenticated non-admin user can escalate privileges through OS command injection via a maliciously crafted container name. Successful exploitation enables arbitrary command execution as root on a target server within a Komodo deployment. Ultimately, this enables an attacker to establish persistence, achieve lateral movement, and completely compromise a user or organization’s managed infrastructure.
Solution
Fortunately, Komodo was reached to coordinate this vulnerability, and a patch has been implemented to remediate the issue in versions 2.3.0 and higher. The CERT/CC recommends that all users update immediately.
Acknowledgements
Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Overview
Lowcoder, version 2.4.10, contains an authorization bypass vulnerability in its Query Library feature’s API. Authenticated users with an admin or dev role can access private library-query data from other organizations within a multi-tenant Lowcoder instance.
Description
CVE-2026-16753 Lowcoder is an open-source low-code platform that allows individuals with minimal coding experience to build web applications through a visual drag-and-drop interface. Each Lowcoder project contains a centralized Query Library which stores the workspace’s data queries and sources for quick reuse; however, the LibraryQuery API service layer lacks organization-scope checks at two endpoints: metadata retrieval and query execution.
While the application features a role-based access mechanism (requires admin or dev), it only checks the role’s validity against the user’s own organization. The vulnerable endpoints do not validate whether the requested resource belongs to the requester’s organization.
Impact
Any authenticated attacker with an admin or dev role in any organization on a multi-tenant Lowcoder instance can access other tenants’ Query Libraries. Note that these roles are granted by default for any self-signup account when LOWCODER_EMAIL_SIGNUP_ENABLED and LOWCODER_CREATE_WORKSPACE_ON_SIGNUP are TRUE. This allows an attacker to do the following:

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

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

Potential impacts include cross-tenant data exposure, modification, or destruction, as well as cost abuse via querying paid data sources using another tenant’s finances. By bypassing organization-level authorization, Lowcoder instances effectively function as shared environments for attackers, violating data isolation between organizations.
This vulnerability was confirmed against Lowcoder version 2.4.10.
Solution
Unfortunately, Lowcoder could not be reached to coordinate this vulnerability. To mitigate, Lowcoder administrators should restrict access to the affected Query Library API endpoints until an official security update is available. Administrators can reduce exposure by limiting application access to trusted users and reviewing admin and dev role assignments. Organizations operating multi-tenant Lowcoder deployments should consider isolating tenants into separate instances to prevent cross-organization data access. Where source-code modifications are possible, administrators should implement organization-level authorization checks for Query Library metadata retrieval and query execution.
Acknowledgements
Thanks to Louis Sanchez, member of Voke Cyber, for reporting this vulnerability. This document was written by Alex Lewis.

Overview
This note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify.
Description
The observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280.
DNS-name comparison. RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names’ case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison.
IP address handling. RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other.
URI-authority parsing. RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when @, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single @ is handled per RFC 3986 by most implementations.
Wildcard matching. RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory.
These differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment.
Impact
An attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed.
Solution
CERT/CC is coordinating with the affected projects:
* Go’s crypto/x509
* Apple’s Security.framework
* OpenSSL*
* LibreSSL
* pyca/cryptography
* wolfSSL
Operators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ.
Acknowledgements
Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.
Supporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).