Two XSS vulnerabilities were fixed in message list and view in the Hupa Webmail application from the Apache James project. An attacker could send a carefully crafted email to a user of Hupa which would trigger a XSS when the email was opened or when a list of messages were viewed. This issue was addressed in Hupa 0.0.3.

In Apache Geode before v1.4.0, the Geode server stores application objects in serialized form. Certain cluster operations and API invocations cause these objects to be deserialized. A user with DATA:WRITE access to the cluster may be able to cause remote code execution if certain classes are present on the classpath.

In Apache Geode before v1.4.0, the TcpServer within the Geode locator opens a network port that deserializes data. If an unprivileged user gains access to the Geode locator, they may be able to cause remote code execution if certain classes are present on the classpath.

When an Apache Geode cluster before v1.4.0 is operating in secure mode, the Geode configuration service does not properly authorize configuration requests. This allows an unprivileged user who gains access to the Geode locator to extract configuration data and previously deployed application code.

Security constraints defined by annotations of Servlets in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.

The qpidd broker in Apache Qpid 0.30 and earlier allows remote authenticated users to cause a denial of service (daemon crash) via an AMQP message with (1) an invalid range in a sequence set, (2) content-bearing methods other than message-transfer, or (3) a session-gap control before a corresponding session-attach.

The Privileges portion of the web GUI and the XMLRPC API in Apache VCL 2.3.x before 2.3.2, 2.2.x before 2.2.2 and 2.1 allow remote authenticated users with nodeAdmin, manageGroup, resourceGrant, or userGrant permissions to gain privileges, cause a denial of service, or conduct cross-site scripting (XSS) attacks by leveraging improper data validation.

The console in Apache jUDDI 3.0.0 does not properly escape line feeds, which allows remote authenticated users to spoof log entries via the numRows parameter.

Apache Karaf prior to 4.0.8 used the LDAPLoginModule to authenticate users to a directory via LDAP. However, it did not encoding usernames properly and hence was vulnerable to LDAP injection attacks leading to a denial of service.

Vulnerability allows a user of Apache Oozie 3.1.3-incubating to 4.3.0 and 5.0.0-beta1 to expose private files on the Oozie server process. The malicious user can construct a workflow XML file containing XML directives and configuration that reference sensitive files on the Oozie server host.

In Apache JMeter 2.X and 3.X, when using Distributed Test only (RMI based), jmeter server binds RMI Registry to wildcard host. This could allow an attacker to get Access to JMeterEngine and send unauthorized code.

A Denial of Service vulnerability was found in Apache Qpid Dispatch Router versions 0.7.0 and 0.8.0. To exploit this vulnerability, a remote user must be able to establish an AMQP connection to the Qpid Dispatch Router and send a specifically crafted AMQP frame which will cause it to segfault and shut down.

When using Distributed Test only (RMI based), Apache JMeter 2.x and 3.x uses an unsecured RMI connection. This could allow an attacker to get Access to JMeterEngine and send unauthorized code.

The Windows installer that the Apache CouchDB team provides was vulnerable to local privilege escalation. All files in the install inherit the file permissions of the parent directory and therefore a non-privileged user can substitute any executable for the nssm.exe service launcher, or CouchDB batch or binary files. A subsequent service or server restart will then run that binary with administrator privilege. This issue affected CouchDB 2.0.0 (Windows platform only) and was addressed in CouchDB 2.0.0.1.

The Apache Thrift Go client library exposed the potential during code generation for command injection due to using an external formatting tool. Affected Apache Thrift 0.9.3 and older, Fixed in Apache Thrift 0.10.0.

In Apache jUDDI 3.2 through 3.3.4, if using the WADL2Java or WSDL2Java classes, which parse a local or remote XML document and then mediates the data structures into UDDI data structures, there are little protections present against entity expansion and DTD type of attacks. Mitigation is to use 3.3.5.

A Denial of Service vulnerability was found in Apache Qpid Broker-J 7.0.0 in functionality for authentication of connections for AMQP protocols 0-8, 0-9, 0-91 and 0-10 when PLAIN or XOAUTH2 SASL mechanism is used. The vulnerability allows unauthenticated attacker to crash the broker instance. AMQP 1.0 and HTTP connections are not affected. An authentication of incoming AMQP connections in Apache Qpid Broker-J is performed by special entities called "Authentication Providers". Each Authentication Provider can support several SASL mechanisms which are offered to the connecting clients as part of SASL negotiation process. The client chooses the most appropriate SASL mechanism for authentication. Authentication Providers of following types supports PLAIN SASL mechanism: Plain, PlainPasswordFile, SimpleLDAP, Base64MD5PasswordFile, MD5, SCRAM-SHA-256, SCRAM-SHA-1. XOAUTH2 SASL mechanism is supported by Authentication Providers of type OAuth2. If an AMQP port is configured with any of these Authentication Providers, the Broker may be vulnerable.

In Apache Allura before 1.8.0, unauthenticated attackers may retrieve arbitrary files through the Allura web application. Some webservers used with Allura, such as Nginx, Apache/mod_wsgi or paster may prevent the attack from succeeding. Others, such as gunicorn do not prevent it and leave Allura vulnerable.

Apache CloudStack 4.1 to 4.8.1.0 and 4.9.0.0 contain an API call designed to allow a user to register for the developer API. If a malicious user is able to determine the ID of another (non-"root") CloudStack user, the malicious user may be able to reset the API keys for the other user, in turn accessing their account and resources.

In Apache CloudStack 4.1.0 and 4.1.1, when calling the CloudStack API call listProjectAccounts as a regular, non-administrative user, the user is able to see information for accounts other than their own.