Security
Headlines
HeadlinesLatestCVEs

Tag

#apache

GHSA-76h9-2vwh-w278: Apache MINA Deserialization RCE Vulnerability

The `ObjectSerializationDecoder` in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the `ObjectSerializationCodecFactory` class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will  not be enough: you also need to explicitly allow the classes th...

ghsa
#vulnerability#apache#java#rce#ssh
ABB Cylon Aspect 3.08.02 (WatchDogServlet) Authenticated Reflected XSS

The ABB BMS/BAS controller suffers from an authenticated reflected cross-site scripting vulnerability. Input passed to the GET parameter 'name' is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML/JS code in a user's browser session in context of an affected site.

GHSA-f697-gm3h-xrf9: Apache HugeGraph-Server: Fixed JWT Token (Secret)

Authentication Bypass by Assumed-Immutable Data vulnerability in Apache HugeGraph-Server. This issue affects Apache HugeGraph-Server: from 1.0.0 before 1.5.0. Users are recommended to upgrade to version 1.5.0, which fixes the issue.

Apache Tomcat Vulnerability CVE-2024-56337 Exposes Servers to RCE Attacks

The Apache Software Foundation (ASF) has released a security update to address an important vulnerability in its Tomcat server software that could result in remote code execution (RCE) under certain conditions. The vulnerability, tracked as CVE-2024-56337, has been described as an incomplete mitigation for CVE-2024-50379 (CVSS score: 9.8), another critical security flaw in the same product that

GHSA-77pm-w3hx-f8mj: Apache Hive and Spark: CookieSigner exposes the correct signature when message verification fails

Signing cookies is an application security feature that adds a digital signature to cookie data to verify its authenticity and integrity. The signature helps prevent malicious actors from modifying the cookie value, which can lead to security vulnerabilities and exploitation. Apache Hive’s service component accidentally exposes the signed cookie to the end user when there is a mismatch in signature between the current and expected cookie. Exposing the correct cookie signature can lead to further exploitation. The vulnerable CookieSigner logic was introduced in Apache Hive by HIVE-9710 (1.2.0) and in Apache Spark by SPARK-14987 (2.0.0). The affected components are the following: * org.apache.hive:hive-service * org.apache.spark:spark-hive-thriftserver_2.11 * org.apache.spark:spark-hive-thriftserver_2.12

GHSA-vq94-9pfv-ccqr: SQL injection in Apache Traffic Control

An SQL injection vulnerability in Traffic Ops in Apache Traffic Control <= 8.0.1, >= 8.0.0 allows a privileged user with role "admin", "federation", "operations", "portal", or "steering" to execute arbitrary SQL against the database by sending a specially-crafted PUT request. Users are recommended to upgrade to version Apache Traffic Control 8.0.2 if you run an affected version of Traffic Ops.

ABB Cylon Aspect 3.08.02 (syslogUpdate.php) Remote Code Execution

The ABB BMS/BAS controller suffers from an authenticated OS command injection vulnerability. This can be exploited to inject and execute arbitrary shell commands through POST parameters, including REMOTE, IP1, IP2, IP3, IP4, and NAME, called by the syslogUpdate.php script.

GHSA-27hp-xhwr-wr2m: Apache Tomcat Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability

Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97. The mitigation for CVE-2024-50379 was incomplete. Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat: - running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true) - running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false) - running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed) Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include check...

Orgs Scramble to Fix Actively Exploited Bug in Apache Struts 2

A newly discovered vulnerability, CVE-2024-53677, in the aging Apache framework is going to cause major headaches for IT teams, since patching isn't enough to fix it.

GHSA-p7c9-8xx8-h74f: Apache Kafka's SCRAM implementation Incorrectly Implements Authentication Algorithm

Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation. Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation. Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue. How to Detect If You Are Impacted: If your deployment uses SCRAM authent...