#maven

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....

RCE-Remote Command Execution vulnerability in Apache HugeGraph-Server.This issue affects Apache HugeGraph-Server: from 1.0.0 before 1.3.0 in Java8 & Java11 Users are recommended to upgrade to version 1.3.0 with Java11 & enable the Auth system, which fixes the issue.

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

Server-Side Request Forgery (SSRF) vulnerability in Apache HugeGraph-Hubble. This issue affects Apache HugeGraph-Hubble: from 1.0.0 before 1.3.0. Users are recommended to upgrade to version 1.3.0, which fixes the issue.

Keycloak was found to not properly enforce token types when validating signatures locally. An authenticated attacker could use this flaw to exchange a logout token for an access token and possibly gain access to data outside of enforced permissions.

A flaw was found in Keycloak. An active keycloak session can be hijacked by initiating a new authentication (having the query parameter prompt=login) and forcing the user to enter his credentials once again. If the user cancels this re-authentication by clicking Restart login, the account takeover could take place as the new session, with a different SUB, will have the same SID as the previous session.