Vulnerabilities

JumpServer is an open source bastion host and an operation and maintenance security audit system. Prior to v4.10.16-lts, JumpServer improperly validates certificates in the Custom SMS API Client. When JumpServer sends MFA/OTP codes via Custom SMS API, an attacker can intercept the request and capture the verification code BEFORE it reaches the user's phone. This vulnerability is fixed in v4.10.16-lts.

JumpServer is an open source bastion host and an operation and maintenance security audit system. a Server-Side Template Injection (SSTI) vulnerability exists in JumpServer's Applet and VirtualApp upload functionality. This vulnerability can only be exploited by users with administrative privileges (Application Applet Management or Virtual Application Management permissions). Attackers can exploit this vulnerability to execute arbitrary code within the JumpServer Core container. The vulnerability arises from unsafe use of Jinja2 template rendering when processing user-uploaded YAML configuration files. When a user uploads an Applet or VirtualApp ZIP package, the manifest.yml file is rendered through Jinja2 without sandbox restrictions, allowing template injection attacks.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, the chunked upload completion path for file requests does not validate the total file size against the per-request MaxSize limit. An attacker with a public file request link can split an oversized file into chunks each under MaxSize and upload them sequentially, bypassing the size restriction entirely. Files up to the server's global MaxFileSizeMB are accepted regardless of the file request's configured limit. This vulnerability is fixed in 2.2.4.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, An API endpoint accepts unbounded request bodies without any size limit. An authenticated user can cause an OOM kill and complete service disruption for all users. This vulnerability is fixed in 2.2.4.

Gokapi is a self-hosted file sharing server with automatic expiration and encryption support. Prior to 2.2.4, An insufficient authorization check in the file replace API allows a user with only list visibility permission (UserPermListOtherUploads) to delete another user's file by abusing the deleteNewFile flag, bypassing the requirement for UserPermDeleteOtherUploads. This vulnerability is fixed in 2.2.4.

SFTPGo is an open source, event-driven file transfer solution. SFTPGo versions before v2.7.1 contain an input validation issue in the handling of dynamic group paths, for example, home directories or key prefixes. When a group is configured with a dynamic home directory or key prefix using placeholders like %username%, the value replacing the placeholder is not strictly sanitized against relative path components. Consequently, if a user is created with a specially crafted username the resulting path may resolve to a parent directory instead of the intended sub-directory. This issue is fixed in version v2.7.1

SFTPGo is an open source, event-driven file transfer solution. In SFTPGo versions prior to 2.7.1, a path normalization discrepancy between the protocol handlers and the internal Virtual Filesystem routing can lead to an authorization bypass. An authenticated attacker can craft specific file paths to bypass folder-level permissions or escape the boundaries of a configured Virtual Folder. This vulnerability is fixed in 2.7.1.

calibre is a cross-platform e-book manager for viewing, converting, editing, and cataloging e-books. Prior to 9.5.0, a path traversal vulnerability in the RocketBook (.rb) input plugin (src/calibre/ebooks/rb/reader.py) allows an attacker to write arbitrary files to any path writable by the calibre process when a user opens or converts a crafted .rb file. This is the same bug class fixed in CVE-2026-26065 for the PDB readers, but the fix was never applied to the RB reader. This vulnerability is fixed in 9.5.0.

The GetGenie plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.3.2. This is due to missing validation on the `id` parameter in the `create()` method of the `GetGenieChat` REST API endpoint. The method accepts a user-controlled post ID and, when a post with that ID exists, calls `wp_update_post()` without verifying that the current user owns the post or that the post is of the expected `getgenie_chat` type. This makes it possible for authenticated attackers, with Author-level access and above, to overwrite arbitrary posts owned by any user — including Administrators — effectively destroying the original content by changing its `post_type` to `getgenie_chat` and reassigning `post_author` to the attacker.

The Formidable Forms plugin for WordPress is vulnerable to an authorization bypass through user-controlled key in all versions up to, and including, 6.28. This is due to the `frm_strp_amount` AJAX handler (`update_intent_ajax`) overwriting the global `$_POST` data with attacker-controlled JSON input and then using those values to recalculate payment amounts via field shortcode resolution in `generate_false_entry()`. The handler relies on a nonce that is publicly exposed in the page's JavaScript (`frm_stripe_vars.nonce`), which provides CSRF protection but not authorization. This makes it possible for unauthenticated attackers to manipulate PaymentIntent amounts before payment completion on forms using dynamic pricing with field shortcodes, effectively paying a reduced amount for goods or services.

The Formidable Forms plugin for WordPress is vulnerable to a payment integrity bypass in all versions up to, and including, 6.28. This is due to the Stripe Link return handler (`handle_one_time_stripe_link_return_url`) marking payment records as complete based solely on the Stripe PaymentIntent status without comparing the intent's charged amount against the expected payment amount, and the `verify_intent()` function validating only client secret ownership without binding intents to specific forms or actions. This makes it possible for unauthenticated attackers to reuse a PaymentIntent from a completed low-value payment to mark a high-value payment as complete, effectively bypassing payment for goods or services.

Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected<br /> preferred key exchange group when its key exchange group configuration includes<br /> the default by using the &amp;#39;DEFAULT&amp;#39; keyword.<br /> <br /> Impact summary: A less preferred key exchange may be used even when a more<br /> preferred group is supported by both client and server, if the group<br /> was not included among the client&amp;#39;s initial predicated keyshares.<br /> This will sometimes be the case with the new hybrid post-quantum groups,<br /> if the client chooses to defer their use until specifically requested by<br /> the server.<br /> <br /> If an OpenSSL TLS 1.3 server&amp;#39;s configuration uses the &amp;#39;DEFAULT&amp;#39; keyword to<br /> interpolate the built-in default group list into its own configuration, perhaps<br /> adding or removing specific elements, then an implementation defect causes the<br /> &amp;#39;DEFAULT&amp;#39; list to lose its &amp;#39;tuple&amp;#39; structure, and all server-supported groups<br /> were treated as a single sufficiently secure &amp;#39;tuple&amp;#39;, with the server not<br /> sending a Hello Retry Request (HRR) even when a group in a more preferred tuple<br /> was mutually supported.<br /> <br /> As a result, the client and server might fail to negotiate a mutually supported<br /> post-quantum key agreement group, such as &amp;#39;X25519MLKEM768&amp;#39;, if the client&amp;#39;s<br /> configuration results in only &amp;#39;classical&amp;#39; groups (such as &amp;#39;X25519&amp;#39; being the<br /> only ones in the client&amp;#39;s initial keyshare prediction).<br /> <br /> OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS<br /> 1.3 key agreement group on TLS servers. The old syntax had a single &amp;#39;flat&amp;#39;<br /> list of groups, and treated all the supported groups as sufficiently secure.<br /> If any of the keyshares predicted by the client were supported by the server<br /> the most preferred among these was selected, even if other groups supported by<br /> the client, but not included in the list of predicted keyshares would have been<br /> more preferred, if included.<br /> <br /> The new syntax partitions the groups into distinct &amp;#39;tuples&amp;#39; of roughly<br /> equivalent security. Within each tuple the most preferred group included among<br /> the client&amp;#39;s predicted keyshares is chosen, but if the client supports a group<br /> from a more preferred tuple, but did not predict any corresponding keyshares,<br /> the server will ask the client to retry the ClientHello (by issuing a Hello<br /> Retry Request or HRR) with the most preferred mutually supported group.<br /> <br /> The above works as expected when the server&amp;#39;s configuration uses the built-in<br /> default group list, or explicitly defines its own list by directly defining the<br /> various desired groups and group &amp;#39;tuples&amp;#39;.<br /> <br /> No OpenSSL FIPS modules are affected by this issue, the code in question lies<br /> outside the FIPS boundary.<br /> <br /> OpenSSL 3.6 and 3.5 are vulnerable to this issue.<br /> <br /> OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.<br /> OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.<br /> <br /> OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.