| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Inappropriate implementation in Custom Tabs in Google Chrome on Android prior to 117.0.5938.62 allowed a remote attacker to obfuscate a permission prompt via a crafted HTML page. (Chromium security severity: Medium) |
| XXE in the XML Format Plugin in Apache Drill version 1.19.0 and greater allows a user to read any file on a remote file system or execute commands via a malicious XML file.
Users are recommended to upgrade to version 1.21.2, which fixes this issue. |
| Incorrect security UI in BFCache in Google Chrome prior to 116.0.5845.179 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: High) |
| Synapse is an open-source Matrix homeserver Prior to versions 1.95.1 and 1.96.0rc1, cached device information of remote users can be queried from Synapse. This can be used to enumerate the remote users known to a homeserver. System administrators are encouraged to upgrade to Synapse 1.95.1 or 1.96.0rc1 to receive a patch. As a workaround, the `federation_domain_whitelist` can be used to limit federation traffic with a homeserver. |
| Mediawiki v1.40.0 does not validate namespaces used in XML files.
Therefore, if the instance administrator allows XML file uploads,
a remote attacker with a low-privileged user account can use this
exploit to become an administrator by sending a malicious link to
the instance administrator. |
| Remote code execution (RCE) vulnerability in Brocade Fabric OS after v9.0 and before v9.2.0 could allow an attacker to execute arbitrary code and use this to gain root access to the Brocade switch. |
| eprosima Fast DDS is a C++ implementation of the Data Distribution Service standard of the Object Management Group. Prior to versions 2.10.0 and 2.6.5, the `BadParamException` thrown by Fast CDR is not caught in Fast DDS. This can remotely crash any Fast DDS process. Versions 2.10.0 and 2.6.5 contain a patch for this issue. |
| Deserialization of Untrusted Data, Improper Input Validation vulnerability in Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK.This issue affects Apache UIMA Java SDK: before 3.5.0.
Users are recommended to upgrade to version 3.5.0, which fixes the issue.
There are several locations in the code where serialized Java objects are deserialized without verifying the data. This affects in particular:
* the deserialization of a Java-serialized CAS, but also other binary CAS formats that include TSI information using the CasIOUtils class;
* the CAS Editor Eclipse plugin which uses the the CasIOUtils class to load data;
* the deserialization of a Java-serialized CAS of the Vinci Analysis Engine service which can receive using Java-serialized CAS objects over network connections;
* the CasAnnotationViewerApplet and the CasTreeViewerApplet;
* the checkpointing feature of the CPE module.
Note that the UIMA framework by default does not start any remotely accessible services (i.e. Vinci) that would be vulnerable to this issue. A user or developer would need to make an active choice to start such a service. However, users or developers may use the CasIOUtils in their own applications and services to parse serialized CAS data. They are affected by this issue unless they ensure that the data passed to CasIOUtils is not a serialized Java object.
When using Vinci or using CasIOUtils in own services/applications, the unrestricted deserialization of Java-serialized CAS files may allow arbitrary (remote) code execution.
As a remedy, it is possible to set up a global or context-specific ObjectInputFilter (cf. https://openjdk.org/jeps/290 and https://openjdk.org/jeps/415 ) if running UIMA on a Java version that supports it.
Note that Java 1.8 does not support the ObjectInputFilter, so there is no remedy when running on this out-of-support platform. An upgrade to a recent Java version is strongly recommended if you need to secure an UIMA version that is affected by this issue.
To mitigate the issue on a Java 9+ platform, you can configure a filter pattern through the "jdk.serialFilter" system property using a semicolon as a separator:
To allow deserializing Java-serialized binary CASes, add the classes:
* org.apache.uima.cas.impl.CASCompleteSerializer
* org.apache.uima.cas.impl.CASMgrSerializer
* org.apache.uima.cas.impl.CASSerializer
* java.lang.String
To allow deserializing CPE Checkpoint data, add the following classes (and any custom classes your application uses to store its checkpoints):
* org.apache.uima.collection.impl.cpm.CheckpointData
* org.apache.uima.util.ProcessTrace
* org.apache.uima.util.impl.ProcessTrace_impl
* org.apache.uima.collection.base_cpm.SynchPoint
Make sure to use "!*" as the final component to the filter pattern to disallow deserialization of any classes not listed in the pattern.
Apache UIMA 3.5.0 uses tightly scoped ObjectInputFilters when reading Java-serialized data depending on the type of data being expected. Configuring a global filter is not necessary with this version. |
| If an attacker gains write access to the Apache Superset metadata database, they could persist a specifically crafted Python object that may lead to remote code execution on Superset's web backend.
The Superset metadata db is an 'internal' component that is typically
only accessible directly by the system administrator and the superset
process itself. Gaining access to that database should
be difficult and require significant privileges.
This vulnerability impacts Apache Superset versions 1.5.0 up to and including 2.1.0. Users are recommended to upgrade to version 2.1.1 or later. |
| 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. |
| This vulnerability exists in ESDS Emagic Data Center Management Suit due to lack of input sanitization in its Ping component. A remote authenticated attacker could exploit this by injecting OS commands on the targeted system.
Successful exploitation of this vulnerability could allow the attacker to execute arbitrary code on targeted system. |
| Apache NiFi 0.0.2 through 1.22.0 include Processors and Controller Services that support HTTP URL references for retrieving drivers, which allows an authenticated and authorized user to configure a location that enables custom code execution. The resolution introduces a new Required Permission for referencing remote resources, restricting configuration of these components to privileged users. The permission prevents unprivileged users from configuring Processors and Controller Services annotated with the new Reference Remote Resources restriction. Upgrading to Apache NiFi 1.23.0 is the recommended mitigation. |
| The JndiJmsConnectionFactoryProvider Controller Service, along with the ConsumeJMS and PublishJMS Processors, in Apache NiFi 1.8.0 through 1.21.0 allow an authenticated and authorized user to configure URL and library properties that enable deserialization of untrusted data from a remote location.
The resolution validates the JNDI URL and restricts locations to a set of allowed schemes.
You are recommended to upgrade to version 1.22.0 or later which fixes this issue. |
| A reflected cross-site scripting (XSS) vulnerability exists in Brocade Webtools PortSetting.html of Brocade Fabric OS version before Brocade Fabric OS v9.2.0 that could allow a remote unauthenticated attacker to execute arbitrary JavaScript code in a target user’s session with the Brocade Webtools application. |
| An information disclosure in the web interface of Brocade Fabric OS versions before Brocade Fabric OS v9.2.0 and v9.1.1c, could allow a remote unauthenticated attacker to get technical details about the web interface. |
| Brocade SANnav Web interface before Brocade SANnav v2.3.0 and v2.2.2a
allows remote unauthenticated users to bypass web authentication and
authorization. |
| In Apache Linkis <=1.3.1, because the parameters are not
effectively filtered, the attacker uses the MySQL data source and malicious parameters to
configure a new data source to trigger a deserialization vulnerability, eventually leading to
remote code execution.
Versions of Apache Linkis <= 1.3.0 will be affected.
We recommend users upgrade the version of Linkis to version 1.3.2. |
| In Apache Linkis <=1.3.1, due to the lack of effective filtering
of parameters, an attacker configuring malicious Mysql JDBC parameters in JDBC EengineConn Module will trigger a
deserialization vulnerability and eventually lead to remote code execution. Therefore, the parameters in the Mysql JDBC URL should be blacklisted. Versions of Apache Linkis <= 1.3.0 will be affected.
We recommend users upgrade the version of Linkis to version 1.3.2. |
| SnapCenter versions 4.8 through 4.9 are susceptible to a
vulnerability which may allow an authenticated SnapCenter Server user to
become an admin user on a remote system where a SnapCenter plug-in has
been installed. |
| Relative library resolution in linux container-executor binary in Apache Hadoop 3.3.1-3.3.4 on Linux allows local user to gain root privileges. If the YARN cluster is accepting work from remote (authenticated) users, this MAY permit remote users to gain root privileges.
Hadoop 3.3.0 updated the " YARN Secure Containers https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/SecureContainer.html " to add a feature for executing user-submitted applications in isolated linux containers.
The native binary HADOOP_HOME/bin/container-executor is used to launch these containers; it must be owned by root and have the suid bit set in order for the YARN processes to run the containers as the specific users submitting the jobs.
The patch " YARN-10495 https://issues.apache.org/jira/browse/YARN-10495 . make the rpath of container-executor configurable" modified the library loading path for loading .so files from "$ORIGIN/" to ""$ORIGIN/:../lib/native/". This is the a path through which libcrypto.so is located. Thus it is is possible for a user with reduced privileges to install a malicious libcrypto library into a path to which they have write access, invoke the container-executor command, and have their modified library executed as root.
If the YARN cluster is accepting work from remote (authenticated) users, and these users' submitted job are executed in the physical host, rather than a container, then the CVE permits remote users to gain root privileges.
The fix for the vulnerability is to revert the change, which is done in YARN-11441 https://issues.apache.org/jira/browse/YARN-11441 , "Revert YARN-10495". This patch is in hadoop-3.3.5.
To determine whether a version of container-executor is vulnerable, use the readelf command. If the RUNPATH or RPATH value contains the relative path "./lib/native/" then it is at risk
$ readelf -d container-executor|grep 'RUNPATH\|RPATH'
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/:../lib/native/]
If it does not, then it is safe:
$ readelf -d container-executor|grep 'RUNPATH\|RPATH'
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/]
For an at-risk version of container-executor to enable privilege escalation, the owner must be root and the suid bit must be set
$ ls -laF /opt/hadoop/bin/container-executor
---Sr-s---. 1 root hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor
A safe installation lacks the suid bit; ideally is also not owned by root.
$ ls -laF /opt/hadoop/bin/container-executor
-rwxr-xr-x. 1 yarn hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor
This configuration does not support Yarn Secure Containers, but all other hadoop services, including YARN job execution outside secure containers continue to work. |
