Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component "commons-beanutils", which contains a class that can be used for remote code execution over RMI. Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore. In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases. How to check whether RMI support is enabledRMI support can be over an RMI-specific TCP port, and over an HTTP binding. Both are by default enabled in Jackrabbit webapp/standalone. The native RMI protocol by default uses port 1099. To check whether it is enabled, tools like "netstat" can be used to check. RMI-over-HTTP in Jackrabbit by default uses the path "/rmi". So when running standalone on port 8080, check whether an HTTP GET request on localhost:8080/rmi returns 404 (not enabled) or 200 (enabled). Note that the HTTP path may be different when the webapp is deployed in a container as non-root context, in which case the prefix is under the user's control. Turning off RMIFind web.xml (either in JAR/WAR file or in unpacked web application folder), and remove the declaration and the mapping definition for the RemoteBindingServlet:         <servlet>             <servlet-name>RMI</servlet-name>             <servlet-class>org.apache.jackrabbit.servlet.remote.RemoteBindingServlet</servlet-class>         </servlet>         <servlet-mapping>             <servlet-name>RMI</servlet-name>             <url-pattern>/rmi</url-pattern>         </servlet-mapping> Find the bootstrap.properties file (in $REPOSITORY_HOME), and set         rmi.enabled=false     and also remove         rmi.host         rmi.port         rmi.url-pattern  If there is no file named bootstrap.properties in $REPOSITORY_HOME, it is located somewhere in the classpath. In this case, place a copy in $REPOSITORY_HOME and modify it as explained.  

In multiple functions of binder.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

If the `recursive-clients` quota is reached on a BIND 9 resolver configured with both `stale-answer-enable yes;` and `stale-answer-client-timeout 0;`, a sequence of serve-stale-related lookups could cause `named` to loop and terminate unexpectedly due to a stack overflow. This issue affects BIND 9 versions 9.16.33 through 9.16.41, 9.18.7 through 9.18.15, 9.16.33-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.

A `named` instance configured to run as a DNSSEC-validating recursive resolver with the Aggressive Use of DNSSEC-Validated Cache (RFC 8198) option (`synth-from-dnssec`) enabled can be remotely terminated using a zone with a malformed NSEC record. This issue affects BIND 9 versions 9.16.8-S1 through 9.16.41-S1 and 9.18.11-S1 through 9.18.15-S1.

Every `named` instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the `max-cache-size` statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit. It has been discovered that the effectiveness of the cache-cleaning algorithm used in `named` can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured `max-cache-size` limit to be significantly exceeded. This issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.

A compromised child process could have injected XBL Bindings into privileged CSS rules, resulting in arbitrary code execution and a sandbox escape. This vulnerability affects Firefox < 70.

In bindPlayer of MediaControlPanel.java, there is a possible launch arbitrary activity in SysUI due to Unsafe Intent. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-271845008

In bindOutputSwitcherAndBroadcastButton of MediaControlPanel.java, there is a possible launch arbitrary activity under SysUI due to Unsafe Intent. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-271846393

In Splunk Enterprise versions below 9.1.0.2, 9.0.5.1, and 8.2.11.2, an attacker can inject American National Standards Institute (ANSI) escape codes into Splunk log files that, when a vulnerable terminal application reads them, can potentially, at worst, result in possible code execution in the vulnerable application. This attack requires a user to use a terminal application that supports the translation of ANSI escape codes to read the malicious log file locally in the vulnerable terminal, and to perform additional user interaction to exploit. Universal Forwarder versions 9.1.0.1, 9.0.5, 8.2.11, and lower can be vulnerable in situations where they have management services active and accessible over the network. Universal Forwarder versions 9.0.x and 9.1.x bind management services to the local machine and are not vulnerable in this specific configuration. See SVD-2022-0605 for more information. Universal Forwarder versions 9.1 use Unix Domain Sockets (UDS) for communication, which further reduces the potential attack surface. The vulnerability does not directly affect Splunk Enterprise or Universal Forwarder. The indirect impact on Splunk Enterprise and Universal Forwarder can vary significantly depending on the permissions in the vulnerable terminal application and where and how the user reads the malicious log file. For example, users can copy the malicious file from the Splunk Enterprise instance and read it on their local machine.

Draytek Vigor Routers firmware versions below 3.9.6/4.2.4, Access Points firmware versions below v1.4.0, Switches firmware versions below 2.6.7, and Myvigor firmware versions below 2.3.2 were discovered to use hardcoded encryption keys which allows attackers to bind any affected device to their own account. Attackers are then able to create WCF and DrayDDNS licenses and synchronize them from the website.

Incorrect Permission Assignment for Critical Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.2.0 through 1.6.0.  The attacker can bind any cluster, even if he is not the cluster owner. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick [1] to solve it.[1] https://github.com/apache/inlong/pull/7947 https://github.com/apache/inlong/pull/7947

There is an LDAP bind credentials exposure on KACE Systems Deployment and Remote Site appliances 9.0.146. The captured credentials may provide a higher privilege level on the Active Directory domain. To exploit this, an authenticated attacker edits the user-authentication settings to specify an attacker-controlled LDAP server, clicks the Test Settings button, and captures the cleartext credentials.

Incorrect access control in Videogo v6.8.1 allows attackers to bind shared devices after the connection has been ended.

An issue was discovered in Exynos Mobile Processor and Modem for Exynos Modem 5123, Exynos Modem 5300, Exynos 980, and Exynos 1080. Binding of a wrong resource can occur due to improper handling of parameters while binding a network interface.

SQL injection in Log4cxx when using the ODBC appender to send log messages to a database.  No fields sent to the database were properly escaped for SQL injection.  This has been the case since at least version 0.9.0(released 2003-08-06) Note that Log4cxx is a C++ framework, so only C++ applications are affected. Before version 1.1.0, the ODBC appender was automatically part of Log4cxx if the library was found when compiling the library.  As of version 1.1.0, this must be both explicitly enabled in order to be compiled in. Three preconditions must be met for this vulnerability to be possible: 1. Log4cxx compiled with ODBC support(before version 1.1.0, this was auto-detected at compile time) 2. ODBCAppender enabled for logging messages to, generally done via a config file 3. User input is logged at some point. If your application does not have user input, it is unlikely to be affected. Users are recommended to upgrade to version 1.1.0 which properly binds the parameters to the SQL statement, or migrate to the new DBAppender class which supports an ODBC connection in addition to other databases. Note that this fix does require a configuration file update, as the old configuration files will not configure properly.  An example is shown below, and more information may be found in the Log4cxx documentation on the ODBCAppender. Example of old configuration snippet: <appender name="SqlODBCAppender" class="ODBCAppender">     <param name="sql" value="INSERT INTO logs (message) VALUES ('%m')" />     ... other params here ... </appender> The migrated configuration snippet with new ColumnMapping parameters: <appender name="SqlODBCAppender" class="ODBCAppender">     <param name="sql" value="INSERT INTO logs (message) VALUES (?)" />     <param name="ColumnMapping" value="message"/>     ... other params here ... </appender>

Instruments with Illumina Universal Copy Service v2.x are vulnerable due to binding to an unrestricted IP address. An unauthenticated malicious actor could use UCS to listen on all IP addresses, including those capable of accepting remote communications.

A flaw was found in the Open Cluster Management (OCM) when a user have access to the worker nodes which has the cluster-manager-registration-controller or cluster-manager deployments. A malicious user can take advantage of this and bind the cluster-admin to any service account or using the service account to list all secrets for all kubernetes namespaces, leading into a cluster-level privilege escalation.

Clusternet is a general-purpose system for controlling Kubernetes clusters across different environments. An issue in clusternet prior to version 0.15.2 can be leveraged to lead to a cluster-level privilege escalation. The clusternet has a deployment called `cluster-hub` inside the `clusternet-system` Kubernetes namespace, which runs on worker nodes randomly. The deployment has a service account called `clusternet-hub`, which has a cluster role called `clusternet:hub` via cluster role binding. The `clusternet:hub` cluster role has `"*" verbs of "*.*"` resources. Thus, if a malicious user can access the worker node which runs the clusternet, they can leverage the service account to do malicious actions to critical system resources. For example, the malicious user can leverage the service account to get ALL secrets in the entire cluster, resulting in cluster-level privilege escalation. Version 0.15.2 contains a fix for this issue.

@fastify/csrf-protection is a plugin which helps protect Fastify servers against CSRF attacks. The CSRF protection enforced by the @fastify/csrf-protection library in combination with @fastify/cookie can be bypassed from network and same-site attackers under certain conditions. @fastify/csrf-protection supports an optional userInfo parameter that binds the CSRF token to the user. This parameter has been introduced to prevent cookie-tossing attacks as a fix for CVE-2021-29624. Whenever userInfo parameter is missing, or its value can be predicted for the target user account, network and same-site attackers can 1. fixate a _csrf cookie in the victim's browser, and 2. forge CSRF tokens that are valid for the victim's session. This allows attackers to bypass the CSRF protection mechanism. As a fix, @fastify/csrf-protection starting from version 6.3.0 (and v4.1.0) includes a server-defined secret hmacKey that cryptographically binds the CSRF token to the value of the _csrf cookie and the userInfo parameter, making tokens non-spoofable by attackers. This protection is effective as long as the userInfo parameter is unique for each user. This is patched in versions 6.3.0 and v4.1.0. Users are advised to upgrade. Users unable to upgrade may use a random, non-predictable userInfo parameter for each user as a mitigation.

An Improper Handling of Unexpected Data Type vulnerability in IPv6 firewall filter processing of Juniper Networks Junos OS on the ACX Series devices will prevent a firewall filter with the term 'from next-header ah' from being properly installed in the packet forwarding engine (PFE). There is no immediate indication of an incomplete firewall filter commit shown at the CLI, which could allow an attacker to send valid packets to or through the device that were explicitly intended to be dropped. An indication that the filter was not installed can be identified with the following logs: fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_rule_prepare : Config failed: Unsupported Ip-protocol 51 in the filter lo0.0-inet6-i fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_rule_prepare : Please detach the filter, remove unsupported match and re-attach fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_process_rule : Status:104 dnx_dfw_rule_prepare failed fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_process_filter : Status:104 dnx_dfw_process_rule failed fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_update_filter_in_hw : Status:104 Could not process filter(lo0.0-inet6-i) for rule expansion Unsupported match, action present. fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_create_hw_instance : Status:104 Could not program dfw(lo0.0-inet6-i) type(IFP_DFLT_INET6_Lo0_FILTER)! [104] fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_bind_shim : [104] Could not create dfw(lo0.0-inet6-i) type(IFP_DFLT_INET6_Lo0_FILTER) fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_update_resolve : [100] Failed to bind filter(3) to bind point fpc0 ACX_DFW_CFG_FAILED: ACX Error (dfw):dnx_dfw_change_end : dnx_dfw_update_resolve (resolve type) failed This issue affects Juniper Networks Junos OS on ACX Series: All versions prior to 20.2R3-S7; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S4; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2.