#maven

An issue was discovered in Bouncy Castle Java Cryptography APIs before BC 1.78. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed. Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier: - Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts. - Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type. These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

A vulnerability was found in Wildfly’s management interface. Due to the lack of limitation of sockets for the management interface, it may be possible to cause a denial of service hitting the nofile limit as there is no possibility to configure or set a maximum number of connections.

Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier programmatically sets the Java system property `hudson.model.ParametersAction.keepUndefinedParameters` whenever a build is triggered from a release tag with the 'Svn-Partial Release Manager' SCM. Doing so disables the fix for [SECURITY-170](https://www.jenkins.io/security/advisory/2016-05-11/#arbitrary-build-parameters-are-passed-to-build-scripts-as-environment-variables) / CVE-2016-3721. As of publication of this advisory, there is no fix.

Jenkins Telegram Bot Plugin 1.4.0 and earlier stores the Telegram Bot token unencrypted in its global configuration file `jenkinsci.plugins.telegrambot.TelegramBotGlobalConfiguration.xml` on the Jenkins controller as part of its configuration. This token can be viewed by users with access to the Jenkins controller file system. As of publication of this advisory, there is no fix.

In Apache ActiveMQ 6.x, the default configuration doesn't secure the API web context (where the Jolokia JMX REST API and the Message REST API are located). It means that anyone can use these layers without any required authentication. Potentially, anyone can interact with the broker (using Jolokia JMX REST API) and/or produce/consume messages or purge/delete destinations (using the Message REST API). To mitigate, users can update the default conf/jetty.xml configuration file to add authentication requirement: <bean id="securityConstraintMapping" class="org.eclipse.jetty.security.ConstraintMapping">   <property name="constraint" ref="securityConstraint" />   <property name="pathSpec" value="/" /> </bean> Or we encourage users to upgrade to Apache ActiveMQ 6.1.2 where the default configuration has been updated with authentication by default.

A flaw was found in Quarkus. When a Quarkus RestEasy Classic or Reactive JAX-RS endpoint has its methods declared in the abstract Java class or customized by Quarkus extensions using the annotation processor, the authorization of these methods will not be enforced if it is enabled by either 'quarkus.security.jaxrs.deny-unannotated-endpoints' or 'quarkus.security.jaxrs.default-roles-allowed' properties.

A vulnerability was found in jberet-core logging. An exception in 'dbProperties' might display user credentials such as the username and password for the database-connection.

A flaw was discovered in the RESTEasy Reactive implementation in Quarkus. Due to security checks for some JAX-RS endpoints being performed after serialization, more processing resources are consumed while the HTTP request is checked. In certain configurations, if an attacker has knowledge of any POST, PUT, or PATCH request paths, they can potentially identify vulnerable endpoints and trigger excessive resource usage as the endpoints process the requests. This can result in a denial of service.

### Impact We have identified a local privilege escalation vulnerability in Ant Media Server which allows any unprivileged operating system user account to escalate privileges to the root user account on the system. This vulnerability arises from Ant Media Server running with Java Management Extensions (JMX) enabled and authentication disabled on localhost on port 5599/TCP. This vulnerability is nearly identical to the local privilege escalation vulnerability CVE-2023-26269 identified in Apache James. Any unprivileged operating system user can connect to the JMX service running on port 5599/TCP on localhost and leverage the MLet Bean within JMX to load a remote MBean from an attacker-controlled server. This allows an attacker to execute arbitrary code within the Java process run by Ant Media Server and execute code within the context of the “antmedia” service account on the system. ### Patches 2.9.0 ### Workarounds Remote the following parameters from antmedia.service file ```-Dcom....