Vulnerabilities

Buffer Overflow vulnerability in mtrojnar osslsigncode v.2.3 and before allows a local attacker to execute arbitrary code via a crafted .exe, .sys, and .dll files.

Nullsoft Scriptable Install System (NSIS) before 3.09 mishandles access control for an uninstaller directory.

<br /> The affected TBox RTUs store hashed passwords using MD5 encryption, which is an insecure encryption algorithm.

<br /> The affected TBox RTUs run OpenVPN with root privileges and can run user defined configuration scripts. An attacker could set up a local OpenVPN server and push a malicious script onto the TBox host to acquire root privileges.<br /> <br />

Knowage is the professional open source suite for modern business analytics over traditional sources and big data systems. The endpoint `_/knowage/restful-services/dossier/importTemplateFile_` allows authenticated users to download template hosted on the server. However, starting in the 6.x.x branch and prior to version 8.1.8, the application does not sanitize the `_templateName_ `parameter allowing an attacker to use `*../*` in it, and escaping the directory the template are normally placed and download any file from the system. This vulnerability allows a low privileged attacker to exfiltrate sensitive configuration file. This issue has been patched in Knowage version 8.1.8.

Sealos is a Cloud Operating System designed for managing cloud-native applications. In version 4.2.0 and prior, there is a permission flaw in the Sealos billing system, which allows users to control the recharge resource account `sealos[.] io/v1/Payment`, resulting in the ability to recharge any amount of 1 renminbi (RMB). The charging interface may expose resource information. The namespace of this custom resource would be user&amp;#39;s control and may have permission to correct it. It is not clear whether a fix exists.

`tktchurch/website` contains the codebase for The King&amp;#39;s Temple Church website. In version 0.1.0, a Stripe API key was found in the public code repository of the church&amp;#39;s project. This sensitive information was unintentionally committed and subsequently exposed in the codebase. If an unauthorized party gains access to this key, they could potentially carry out transactions on behalf of the organization, leading to financial losses. Additionally, they could access sensitive customer information, leading to privacy violations and potential legal implications. The affected component is the codebase of our project, specifically the file(s) where the Stripe API key is embedded. The key should have been stored securely, and not committed to the codebase. The maintainers plan to revoke the leaked Stripe API key immediately, generate a new one, and not commit the key to the codebase.

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to "debug" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`.<br /> <br /> Case 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node.<br /> <br /> In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node&amp;#39;s peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded.<br /> <br /> The theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated.<br /> <br /> As the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that "for" loop to never be reached).<br /> <br /> This regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don&amp;#39;t set the log output to "json", leave at "plain", or don&amp;#39;t set the consensus logging module to "debug", leave it at "info" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one&amp;#39;s nginx setup).

Products.CMFCore are the key framework services for the Zope Content Management Framework (CMF). The use of Python&amp;#39;s marshal module to handle unchecked input in a public method on `PortalFolder` objects can lead to an unauthenticated denial of service and crash situation. The code in question is exposed by all portal software built on top of `Products.CMFCore`, such as Plone. All deployments are vulnerable. The code has been fixed in `Products.CMFCore` version 3.2.

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. The mempool maintains two data structures to keep track of outstanding transactions: a list and a map.<br /> These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node.<br /> <br /> The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. Increasing the value of `cache_size` in `config.toml` makes it very difficult to effectively attack a full node. Not exposing the transaction submission RPC&amp;#39;s would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-31999. Reason: This candidate is a reservation duplicate of CVE-2023-31999. Notes: All CVE users should reference CVE-2023-31999 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.

2FA is a Web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Cross site scripting (XSS) injection can be done via the account/service field. This was tested in docker-compose environment. This vulnerability has been patched in version 4.0.3.<br />