#maven

In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource. Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka 3.4.0, and "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" is disabled by default in in Apache Kafka 3.9.1/4.0.0

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0,...

### Summary GeoTools Schema class use of Eclipse XSD library to represent schema data structure is vulnerable to XML External Entity (XXE) exploit. ### Impact This impacts whoever exposes XML processing with ``gt-xsd-core`` involved in parsing, when the documents carry a reference to an external XML schema. The ``gt-xsd-core`` Schemas class is not using the EntityResolver provided by the ParserHandler (if any was configured). This also impacts users of ``gt-wfs-ng`` DataStore where the ENTITY_RESOLVER connection parameter was not being used as intended. ### Resolution GeoTools API change allows EntityResolver to be supplied to the following methods: ```java Schemas.parse( location, locators, resolvers, uriHandlers, entityResolver); Schemas.findSchemas(Configuration configuration, EntityResolver entityResolver); ``` With this API change the `gt-wfs-ng` WFS DataStore ENTITY_RESOLVER parameter is now used. ### Reference * [GHSA-jj54-8f66-c5pc](https://github.com/geoserver/geoser...

If you enable Basic Authentication in Pekko Management using the Java DSL, the authenticator may not be properly applied. Users that rely on authentication instead of making sure the Management API ports are only available to trusted users are recommended to upgrade to version 1.1.1, which fixes this issue.

### Summary Fess (an open-source Enterprise Search Server) creates temporary files without restrictive permissions, which may allow local attackers to read sensitive information from these temporary files. ### Details The `createTempFile()` method in `org.codelibs.fess.helper.SystemHelper` creates temporary files without explicitly setting restrictive permissions. This could lead to potential information disclosure, allowing unauthorized local users to access sensitive data contained in these files. ### Impact This issue primarily affects environments where Fess is deployed in a shared or multi-user context. Typical single-user or isolated deployments have minimal or negligible practical impact. ### Workarounds Ensure local access to the environment running Fess is restricted to trusted users only. ### References - [CVE-2022-24823: Netty temporary file permissions vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2022-24823)

### Impact In XWiki 16.10.0, required rights were introduced as a way to limit which rights a document can have. Part of the security model of required rights is that a user who doesn't have a right also cannot define that right as required right. That way, users who are editing documents on which required rights are enforced can be sure that they're not giving a right to a script or object that it didn't have before. A bug in the implementation of the enforcement of this rule means that in fact, it was possible for any user with edit right on a document to set programming right as required right. If then a user with programming right edited that document, the content of that document would gain programming right, allowing remote code execution. This thereby defeats most of the security benefits of required rights. As XWiki still performs the required rights analysis when a user edits a page even when required rights are enforced, the user with programming right would still be warned a...

Spring Security Aspects may not correctly locate method security annotations on private methods. This can cause an authorization bypass. Your application may be affected by this if the following are true: * You are using @EnableMethodSecurity(mode=ASPECTJ) and spring-security-aspects, and * You have Spring Security method annotations on a private method In that case, the target method may be able to be invoked without proper authorization. You are not affected if: * You are not using @EnableMethodSecurity(mode=ASPECTJ) or spring-security-aspects, or * You have no Spring Security-annotated private methods

Improper Restriction of XML External Entity Reference vulnerability in bonigarcia webdrivermanager on Windows, MacOS, Linux (XML parsing components modules) allows Data Serialization External Entities Blowup. This vulnerability is associated with program files src/main/java/io/github/bonigarcia/wdm/WebDriverManager.java. This issue affects webdrivermanager: from 1.0.0 before 6.1.0.

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x. There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenarios where you only load trusted configurations. Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

### Impact Two minor vulnerabilities were identified in the Graylog2 enterprise server, which can be combined to carry out a stored cross-site scripting attack. An attacker with the permission `FILES_CREATE` can exploit these vulnerabilities to upload arbitrary Javascript code to the Graylog2 server, which - upon requesting of the file by a user of the API browser - results in the execution of this Javascript code in the context of the Graylog frontend application. This enables the attacker to carry out authenticated API requests with the permissions of the logged-in user, thereby taking over the user session. ### Patches The generic API has been removed in 6.2.0 rendering the attack vector unreachable and additional escaping has been added. Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd