All posts by admin

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

Overview
Shopware 6.7 contains a stored cross-site scripting (XSS) vulnerability in its media upload functionality that can lead to administrator credential compromise and remote code execution.
Description
Shopware is an open-source e-commerce platform used to build and manage online stores. It provides merchants with customizable product pages, administrative interfaces, plugin functionality, and a media management system that allows users to upload and serve files.
CVE-2026-104937 In affected versions, Shopware’s media upload API accepts HTML files that are later served as text/html without effective Content-Security-Policy or X-Content-Type-Options security headers. An attacker with access to the media upload capability can therefore upload an HTML file with malicious embedded JavaScript, and if an administrator opens the corresponding media URL, the attacker can exfiltrate the administrator’s authentication token and use it to gain unauthorized access to the Shopware Administration API.
Impact
Successful exploitation of this vulnerability could allow an attacker with media creation/upload access to execute arbitrary JavaScript in the administrator browser context, steal valid administrator authentication tokens, and gain privileged access to the Shopware Administration API. If the affected administrator account possesses extension management privileges, an attacker could upload, install, and activate malicious plugins to achieve arbitrary PHP code execution on the underlying OS with the privileges of the Shopware process.
Solution
Unfortunately, the CERT/CC was unable to reach Shopware to coordinate this vulnerability. Until a patch is available, users can reduce risk by limiting access to the media upload functionality to trusted roles or disabling HTML file uploads entirely, preventing attackers from creating malicious browser-interpretable content.
Acknowledgements
Thanks to Deflask13 for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
Thelia versions 2.6.0 and 2.6.1 contain multiple vulnerabilities relating to file management, Smarty templating, module installation, and administrative workflows. Successful exploitation of these issues could enable remote code execution (RCE), server-side template injection (SSTI), stored and reflected cross-site scripting (XSS), unauthorized URL redirection, and other risks that expose both server-side and client-side attack surfaces.
Description
Thelia is an open-source e-commerce platform designed to provide merchants with customizable online storefronts, product management workflows, and administrative functionalities. It utilizes the Smarty template engine and provides administrators with broad control over templates, content, and modules.
CVE-2026-103521 In Thelia v2.6.0, the document upload endpoint properly blocks the upload of executable file types, but the document update endpoint does not perform the same validation. An attacker with administrative Thelia permissions can exploit this vulnerability to upload arbitrary executable files, such as malicious PHP scripts, to achieve remote code execution on the underlying server.
CVE-2026-103522 In Thelia v2.6.0, the store banner upload feature performs insufficient filetype validation that relies exclusively on client-supplied MIME types. An attacker with administrative access can upload a PHP file disguised as an image to bypass validation and achieve remote code execution on the underlying server.
CVE-2026-103523 Thelia v2.6.0 contains an open redirect vulnerability in its address creation workflow. After a user accesses a crafted URL and successfully submits the “Add New Address” form, the application redirects them to the URL specified in the next parameter. Because the application does not validate whether the destination belongs to the same origin or an approved allowlist, an attacker can supply an arbitrary external URL and redirect users to an attacker-controlled website.
CVE-2026-103524 Thelia v2.6.0 is vulnerable to multiple stored XSS vulnerabilities within the administrative interface. User-supplied input is stored without sufficient output encoding or sanitization and is later rendered in the administrator interface and/or the web store’s product pages, allowing arbitrary JavaScript execution when the affected pages are viewed. The vulnerability affects multiple administrative functions including category creation and product creation.
CVE-2026-103526 In Thelia v2.6.0, both the administrative login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate valid administrator accounts. Because the endpoint also lacks rate limiting or other protections against repeated authentication attempts, username enumeration can be performed efficiently at scale.
CVE-2026-103527 Thelia v2.6.0’s Smarty templates (address.html and address-update.html) fail to properly escape double quotes in the next parameter, enabling reflected XSS when an authenticated user visits the malicious link containing attacker‑controlled JavaScript.
CVE-2026-103528 Thelia 2.6.0 uses Smarty for email templates without properly restricting access to dangerous PHP functions. An authenticated administrator can inject malicious Smarty expressions into email templates via the messages configuration interface, and when the template is previewed or rendered, functions such as system(), exec(), file_put_contents(), and file_get_contents() can be executed with the privileges of the web process. This allows arbitrary OS command execution, file read/write operations, and RCE on the server.
CVE-2026-103529 Thelia v2.6.0 permits authenticated administrators to upload and install modules via the ZIP upload function without validating or sandboxing embedded PHP code. An attacker can include malicious PHP code in a module’s install() method which will then be executed upon installation, enabling remote code execution with the privileges of the web server.
CVE-2026-103535 Thelia v2.6.1 contains path traversal and PHP code injection vulnerabilities in its translation editor that can be chained to achieve remote code execution. The item_name parameter, used to build the translation file’s write path, does not sanitize directory traversal sequences such as ../, allowing an authenticated user with UPDATE-level permission on admin.configuration.language to write files outside templates/, including to web-accessible directories. Separately, the translation-writing logic does not escape in user-supplied values, allowing input to break out of the PHP string literal and inject executable code into the translation file. Chained together, these flaws allow a malicious PHP file to be written to a web-accessible path and executed with the web server’s privileges.
CVE-2026-103537 Thelia v2.6.1 contains an absolute path traversal vulnerability in its Smarty template handling that enables SSTI and remote code execution. The checkTemplate() validation restricts relative directory traversal sequences such as ../ but does not reject absolute paths, allowing an authorized user to supply an arbitrary filesystem path as a template. Smarty then loads and compiles the referenced file without an effective security policy, so, depending on filesystem layout and deployment configuration, template code in that file can be executed with the web server’s privileges.
Impact
Several of these vulnerabilities allow authenticated administrative users to achieve arbitrary code execution on the host server. These include insufficient file validation and unsafe upload/update workflows (CVE-2026-103521 and CVE-2026-103522), unrestricted execution of PHP code during module installation (CVE-2026-103529), unsafe template evaluation for email content (CVE-2026-103528), server side template injection via absolute paths (CVE-2026-103537), and flaws in the translation writing process that permit path traversal and PHP injection (CVE-2026-103535). Exploitation of any of these issues can result in complete compromise of the underlying application environment with the privileges of the web server.
Separately, user-supplied content rendered within administrative templates enables stored and reflected XSS. CVE-2026-103524 allows persistent JavaScript execution within the admin interface, while CVE-2026-103527 enables reflected JavaScript injection via unescaped template parameters. These vulnerabilities allow attackers to hijack administrative sessions and perform privileged actions in the browser context of other authenticated users.
The discrepancies in authentication error-handling identified in CVE-2026-103526 allow unauthenticated attackers to easily enumerate valid administrative usernames, increasing the risk and effectiveness of subsequent brute-forcing or authentication-related attacks.
Finally, the open redirect described in CVE-2026-103523 allows attackers to redirect users to external attacker-controlled websites, increasing the effectiveness of phishing or other downstream attacks.
Together, these vulnerabilities facilitate full server takeover for authenticated administrative attackers, and expose avenues for browser-based compromise or credential attacks to both authenticated and unauthenticated attackers.
Solution
Unfortunately, we were unable to coordinate these vulnerabilities with Thelia, and a patch is not yet available. To reduce risk until these issues are remediated, users and organizations should restrict access to Thelia administrative interfaces, disable or tightly limit file-upload and template-editing features, and remove PHP execution permissions from user-writable directories wherever possible. Applying strict reverse-proxy controls such as rate limiting, MIME filtering, and URL allowlisting can further reduce exposure.
Acknowledgements
Thanks to the reporters K08UK0VU, s-b312, DuanNH, Deflask13, LongNBH, and NNPhong (pnn219) from ETC JSC security team for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview
An Out-of-bounds Write vulnerability in the InsydeH2O IHISI software used by HP PC BIOS can allow a local attacker with OS kernel privileges to perform arbitrary physical memory writes, including writes to System Management RAM (SMRAM). Because the vulnerable code executes in System Management Mode (SMM), successful exploitation can allow an attacker to modify SMM-protected memory and potentially achieve arbitrary code execution in SMM. Depending on the platform’s memory and firmware configuration, the arbitrary physical memory write primitive may also have implications for UEFI firmware update or flash-related operations.
Description
HP PC BIOS is firmware that initializes and manages hardware components during the boot process and provides runtime services to the operating system and provide the ability to update firmware. The affected system uses InsydeH2O Kernel version 5.5 or earlier. The BIOS includes custom HP SMM handlers that execute in System Management Mode (SMM), a highly privileged CPU execution mode that is isolated from the operating system.
CVE-2026-12855: An Out-of-bounds Write vulnerability in the H19WMIHandlerSmm module (GUID f1946499-571b-44c3-9b9c-cc55210b0c02) allows a local attacker with OS kernel privileges to read or write arbitrary physical memory, including SMRAM, through a Software SMI handler.
An attacker with kernel-level privileges can trigger the vulnerable SMM handler by issuing a Software System Management Interrupt (SMI) through I/O port 0xB2 and supplying specially crafted CPU register values. The vulnerable handler does not adequately validate the supplied parameters before performing memory operations, allowing the attacker to influence the physical address and data involved in the operation.
Because the affected handler executes in SMM, the resulting arbitrary physical memory write can target memory regions that are normally inaccessible to software executing outside SMM, including SMRAM. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution in SMM. The ability to affect firmware or ROM contents is platform-dependent and is not assumed as a direct consequence of this vulnerability.
Impact
An attacker with privileged OS kernel access (ring 0) can exploit the vulnerability by raising Software SMI interrupts through I/O port 0xB2 with crafted CPU register values. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution and persistence via modifying SMRAM.
Solution
Users should check HP’s security bulletins to determine whether their system is affected. Insyde advisory is available at https://www.insyde.com/security-pledge/sa-2026009/
Acknowledgements
Thank you to Zhenyu Liu for reporting these vulnerabilities. This document was written by Vijay Sarvepalli.

Overview
Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty “signatures” array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material.
Description
Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication.
As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the “signatures” section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected:
jws.deserialize_json(“payload”:”…”, “signatures”:[], key=None)
jws.deserialize(‘”payload”:”…”,”signatures”:[]’, key=None)
Impact
An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following:
* Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin).
* Signed message injection between microservices using JWS.
* Forged authorization claims such as scopes, roles, or permissions.
* Integrity bypass in systems relying on signed JWS data.
Solution
The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project’s GitHub repository for updates and install the latest version of this library once a fix has been released.
Acknowledgements
Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.