#maven

Bypass/Injection vulnerability in Apache Camel-Bean component under particular conditions. This issue affects Apache Camel: from 4.9.0 through <= 4.10.1, from 4.0.0-M1 through <= 4.8.4, from 3.10.0 through <= 3.22.3. Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases. This vulnerability is only present in the following situation. The user is using one of the following HTTP Servers via one the of the following Camel components * camel-servlet * camel-jetty * camel-undertow * camel-platform-http * camel-netty-http and in the route, the exchange will be routed to a camel-bean producer. So ONLY camel-bean component is affected. In particular:  * The bean invocation (is only affected if you use any of the above together with camel-bean component). * The bean that can be called, has more than 1 method implemented. In these conditions an attacker could be able to forge a Camel header name and make the...

### Impact The homepage of the application is public which enables a guest to download the package which might contain sensitive information. ### Patches 1.11.7 ### Workarounds The access to the page can be manually restricted to a specific set of users or groups.

Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not require POST requests for the HTTP endpoint toggling collapsed/expanded status of sidepanel widgets (e.g., Build Queue and Build Executor Status widgets), resulting in a cross-site request forgery (CSRF) vulnerability. This vulnerability allows attackers to have users toggle their collapsed/expanded status of sidepanel widgets. Additionally, as the API accepts any string as the identifier of the panel ID to be toggled, attacker-controlled content can be stored in the victim’s user profile in Jenkins. Jenkins 2.500, LTS 2.492.2 requires POST requests for the affected HTTP endpoint.

An incorrect authorization vulnerability exists in multiple WSO2 products, allowing protected APIs to be accessed directly using a refresh token instead of the expected access token. Due to improper authorization checks and token mapping, session cookies are not required for API access, potentially enabling unauthorized operations. Exploitation requires an attacker to obtain a valid refresh token of an admin user. Since refresh tokens generally have a longer expiration time, this could lead to prolonged unauthorized access to API resources, impacting data confidentiality and integrity.

**Summary / Details** Systems running the Instaclustr fork of Stratio's Cassandra-Lucene-Index plugin versions 4.0-rc1-1.0.0 through 4.0.16-1.0.0 and 4.1.0-1.0.0 through 4.1.8-1.0.0, installed into Apache Cassandra version 4.x, are susceptible to a vulnerability which when successfully exploited could allow authenticated Cassandra users to remotely bypass RBAC to access data and and escalate their privileges. **Affected Versions** - Cassandra-Lucene-Index plugin versions 4.0-rc1-1.0.0 through 4.0.16-1.0.0 - versions 4.1.0-1.0.0 through 4.1.8-1.0.0 when installed into Apache Cassandra version 4.x. **Required Configuration for Exploit** These are the conditions required to enable exploit: 1. Cassandra 4.x 2. Vulnerable version of the Cassandra-Lucene-Index plugin configured for use 3. Data added to tables 4. Lucene index created 5. Cassandra flush has run **Mitigation/Prevention** Mitigation requires dropping all Lucene indexes and stopping use of the plugin. Exploit will be possibl...

### Impact When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. ### Workarounds As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: ``` SslContext context = ...; SslHandler handler = context.newHandler(....); ``` to: ``` SslContext context = ...; SSLEngine engine = context.newEngine(....); SslHandler handler = new SslHandler(engine, ....); ```

### Summary Remote Code Execution (RCE) is possible if an application uses certain GeoTools functionality to evaluate XPath expressions supplied by user input. ### Details The following methods pass XPath expressions to the `commons-jxpath` library which can execute arbitrary code and would be a security issue if the XPath expressions are provided by user input. * `org.geotools.appschema.util.XmlXpathUtilites.getXPathValues(NamespaceSupport, String, Document)` * `org.geotools.appschema.util.XmlXpathUtilites.countXPathNodes(NamespaceSupport, String, Document)` * `org.geotools.appschema.util.XmlXpathUtilites.getSingleXPathValue(NamespaceSupport, String, Document)` * `org.geotools.data.complex.expression.FeaturePropertyAccessorFactory.FeaturePropertyAccessor.get(Object, String, Class<T>)` * `org.geotools.data.complex.expression.FeaturePropertyAccessorFactory.FeaturePropertyAccessor.set(Object, String, Object, Class)` * `org.geotools.data.complex.expression.MapPropertyAccessorFactory.new...

In Apache Cassandra it is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorized operations. This is same vulnerability that CVE-2020-13946 was issued for, but the Java option was changed in JDK10. This issue affects Apache Cassandra from 4.0.2 through 5.0.2 running Java 11. Operators are recommended to upgrade to a release equal to or later than 4.0.15, 4.1.8, or 5.0.3 which fixes the issue.

Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches. This issue affects Apache Cassandra through 3.0.30, 3.11.17, 4.0.15, 4.1.7, 5.0.2. Users are recommended to upgrade to versions 3.0.31, 3.11.18, 4.0.16, 4.1.8, 5.0.3, which fixes the issue.

Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer. Users with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions. This issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer. Operators using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.