In JetBrains TeamCity before 2023.05.6, 2023.11.5 stored XSS in Commit status publisher was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 stored XSS via OAuth connection settings was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 stored XSS via issue tracker integration was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 reflected XSS via OAuth provider configuration was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 stored XSS via third-party reports was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 an XSS could be executed via certain report grouping and filtering operations

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5, 2024.03.2 a third-party agent could impersonate a cloud agent

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 improper access control in Pull Requests and Commit status publisher build features was possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5 several Stored XSS in code inspection reports were possible

In JetBrains TeamCity before 2022.04.7, 2022.10.6, 2023.05.6, 2023.11.5, 2024.03.2 path traversal allowing to read files from server was possible

The application implements an up- and downvote function which alters a value within a JSON file. The POST parameters are not filtered properly and therefore an arbitrary file can be overwritten. The file can be controlled by an authenticated attacker, the content cannot be controlled. It is possible to overwrite all files for which the webserver has write access. It is required to supply a relative path (path traversal).

The EmbedAI application is susceptible to security issues that enable Data Poisoning attacks. This weakness could result in the application becoming compromised, leading to unauthorized entries or data poisoning attacks, which are delivered by a CSRF vulnerability due to the absence of a secure session management implementation and weak CORS policies weakness. An attacker can direct a user to a malicious webpage that exploits a CSRF vulnerability within the EmbedAI application. By leveraging this CSRF vulnerability, the attacker can deceive the user into inadvertently uploading and integrating incorrect data into the application’s language model.

The HUSKY – Products Filter Professional for WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's shortcode(s) in all versions up to, and including, 1.3.5.3 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The application does not change the session token when using the login or logout functionality. An attacker can set a session token in the victim's browser (e.g. via XSS) and prompt the victim to log in (e.g. via a redirect to the login page). This results in the victim's account being taken over.

When LDAP authentication is activated in the configuration it is possible to obtain reflected XSS execution by creating a custom URL that the victim only needs to open in order to execute arbitrary JavaScript code in the victim's browser. This is due to a fault in the file login.php where the content of "$_SERVER['PHP_SELF']" is reflected into the HTML of the website. Hence the attacker does not need a valid account in order to exploit this issue.

IBM Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data 3.5, 4.0, 4.5, 4.6, 4.7, and 4.8 could allow a user with access to the Kubernetes pod, to make system calls compromising the security of containers. IBM X-Force ID: 265264.

Zoho ManageEngine PAM360 is vulnerable to Stored XSS vulnerability. This vulnerability is applicable only in the version 6610.

In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001

Improper restriction of local upload and download paths in check_sftp in Checkmk before 2.3.0p4, 2.2.0p27, 2.1.0p44, and in Checkmk 2.0.0 (EOL) allows attackers with sufficient permissions to configure the check to read and write local files on the Checkmk site server.

The WP STAGING WordPress Backup Plugin – Migration Backup Restore plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the wpstg_processing AJAX action in all versions up to, and including, 3.4.3. This makes it possible for authenticated attackers, with administrator-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible.