The AsyncResponseWrapperImpl class in Apache Olingo versions 4.0.0 to 4.6.0 reads the Retry-After header and passes it to the Thread.sleep() method without any check. If a malicious server returns a huge value in the header, then it can help to implement a DoS attack.

The XML content type entity deserializer in Apache Olingo versions 4.0.0 to 4.6.0 is not configured to deny the resolution of external entities. Request with content type "application/xml", which trigger the deserialization of entities, can be used to trigger XXE attacks.

nimbus-jose-jwt: Uncaught exceptions while parsing a JWT

Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.

An issue was discovered in the protobuf crate before 2.6.0 for Rust. Attackers can exhaust all memory via Vec::reserve calls.

libquartz: XXE attacks via job description

initDocumentParser in xml/XMLSchedulingDataProcessor.java in Terracotta Quartz Scheduler through 2.3.0 allows XXE attacks via a job description.

an unauthenticated user could get access to information of some backend screens by invoking setSessionLocale in Apache OFBiz 16.11.01 to 16.11.06

Apache OFBiz 17.12.01 is vulnerable to Host header injection by accepting arbitrary host

cxf: OpenId Connect token service does not properly validate the clientId

Apache CXF ships with a OpenId Connect JWK Keys service, which allows a client to obtain the public keys in JWK format, which can then be used to verify the signature of tokens issued by the service. Typically, the service obtains the public key from a local keystore (JKS/PKCS12) by specifing the path of the keystore and the alias of the keystore entry. This case is not vulnerable. However it is also possible to obtain the keys from a JWK keystore file, by setting the configuration parameter "rs.security.keystore.type" to "jwk". For this case all keys are returned in this file "as is", including all private key and secret key credentials. This is an obvious security risk if the user has configured the signature keystore file with private or secret key credentials. From CXF 3.3.5 and 3.2.12, it is mandatory to specify an alias corresponding to the id of the key in the JWK file, and only this key is returned. In addition, any private key information is omitted by default. "oct" keys, which contain secret keys, are not returned at all.

shiro: Cookie padding oracle vulnerability with default configuration

Apache Shiro before 1.4.2, when using the default "remember me" configuration, cookies could be susceptible to a padding attack.

When using an authentication mechanism other than PKI, when the user clicks Log Out in NiFi versions 1.0.0 to 1.9.2, NiFi invalidates the authentication token on the client side but not on the server side. This permits the user's client-side token to be used for up to 12 hours after logging out to make API requests to NiFi.

spamassassin: crafted email message can lead to DoS

In Apache SpamAssassin before 3.4.3, a message can be crafted in a way to use excessive resources. Upgrading to SA 3.4.3 as soon as possible is the recommended fix but details will not be shared publicly.

cxf: OpenId Connect token service does not properly validate the clientId

Apache CXF before 3.3.4 and 3.2.11 provides all of the components that are required to build a fully fledged OpenId Connect service. There is a vulnerability in the access token services, where it does not validate that the authenticated principal is equal to that of the supplied clientId parameter in the request. If a malicious client was able to somehow steal an authorization code issued to another client, then they could exploit this vulnerability to obtain an access token for the other client.

A malicious admin user could edit the state of objects in the Airflow metadata database to execute arbitrary javascript on certain page views. This also presented a Local File Disclosure vulnerability to any file readable by the webserver process.

we got reports for 2 injection attacks against the DeltaSpike windowhandler.js. This is only active if a developer selected the ClientSideWindowStrategy which is not the default.

poi: a specially crafted Microsoft Excel document allows attacker to read files from the local filesystem

In Apache POI up to 4.1.0, when using the tool XSSFExportToXml to convert user-provided Microsoft Excel documents, a specially crafted document can allow an attacker to read files from the local filesystem or from internal network resources via XML External Entity (XXE) Processing.

In Apache Incubator Superset before 0.32, a user can view database names that he has no access to on a dropdown list in SQLLab

In Apache Incubator Superset before 0.31 user could query database metadata information from a database he has no access to, by using a specially crafted complex query.

A flaw in the libapreq2 v2.07 to v2.13 multipart parser can deference a null pointer leading to a process crash. A remote attacker could send a request causing a process crash which could lead to a denial of service attack.

While investigating UBSAN errors in https://github.com/apache/arrow/pull/5365 it was discovered Apache Arrow versions 0.12.0 to 0.14.1, left memory Array data uninitialized when reading RLE null data from parquet. This affected the C++, Python, Ruby and R implementations. The uninitialized memory could potentially be shared if are transmitted over the wire (for instance with Flight) or persisted in the streaming IPC and file formats.

solr: JMX monitoring service exposed without authentication in default configuration

The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr. If you use the default solr.in.sh file from the affected releases, then JMX monitoring will be enabled and exposed on RMI_PORT (default=18983), without any authentication. If this port is opened for inbound traffic in your firewall, then anyone with network access to your Solr nodes will be able to access JMX, which may in turn allow them to upload malicious code for execution on the Solr server.