Уязвимость расширения Oauth программного средства для реализации гипертекстовой среды MediaWiki, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. The page_recent_contributors leaked the existence of certain deleted MediaWiki usernames, related to rev_deleted.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. It incorrectly logged sensitive suppression deletions, which should not have been visible to users with access to view AbuseFilter log data.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. Its AbuseFilterCheckMatch API reveals suppressed edits and usernames to unprivileged users through the iteration of crafted AbuseFilter rules.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. A MediaWiki user who is partially blocked or was unsuccessfully blocked could bypass AbuseFilter and have their edits completed.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. The Special:AbuseFilter/examine form allowed for the disclosure of suppressed MediaWiki usernames to unprivileged users.

An issue was discovered in the CommentBox extension for MediaWiki through 1.35.2. Via crafted configuration variables, a malicious actor could introduce XSS payloads into various layers.

An issue was discovered in the PageForms extension for MediaWiki through 1.35.2. Crafted payloads for Token-related query parameters allowed for XSS on certain PageForms-managed MediaWiki pages.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. It incorrectly executed certain rules related to blocking accounts after account creation. Such rules would allow for user accounts to be created while blocking only the IP address used to create an account (and not the user account itself). Such rules could also be used by a nefarious, unprivileged user to catalog and enumerate any number of IP addresses related to these account creations.

An issue was discovered in the CheckUser extension for MediaWiki through 1.35.2. MediaWiki usernames with trailing whitespace could be stored in the cu_log database table such that denial of service occurred for certain CheckUser extension pages and functionality. For example, the attacker could turn off Special:CheckUserLog and thus interfere with usage tracking.

An issue was discovered in the AbuseFilter extension for MediaWiki through 1.35.2. It improperly handled account blocks for certain automatically created MediaWiki user accounts, thus allowing nefarious users to remain unblocked.

An issue was discovered in the Oauth extension for MediaWiki through 1.35.2. It did not validate the oarc_version (aka oauth_registered_consumer.oarc_version) parameter's length.

An issue was discovered in the Oauth extension for MediaWiki through 1.35.2. MWOAuthConsumerSubmitControl.php does not ensure that the length of an RSA key will fit in a MySQL blob.

An issue was discovered in the CentralAuth extension in MediaWiki through 1.36. The Special:GlobalRenameRequest page is vulnerable to infinite loops and denial of service attacks when a user's current username is beyond an arbitrary maximum configuration value (MaxNameChars).

An issue was discovered in the AbuseFilter extension in MediaWiki through 1.36. If the MediaWiki:Abusefilter-blocker message is invalid within the content language, the filter user falls back to the English version, but that English version could also be invalid on a wiki. This would result in a fatal error, and potentially fail to block or restrict a potentially nefarious user.

An issue was discovered in the CentralAuth extension in MediaWiki through 1.36. The Special:GlobalUserRights page provided search results which, for a suppressed MediaWiki user, were different than for any other user, thus easily disclosing suppressed accounts (which are supposed to be completely hidden).

An issue was discovered in the CentralAuth extension in MediaWiki through 1.36. Autoblocks for CentralAuth-issued suppression blocks are not properly implemented.

An issue was discovered in the Translate extension in MediaWiki through 1.36. The Aggregategroups Action API module does not validate the parameter for aggregategroup when action=remove is set, thus allowing users with the translate-manage right to silently delete various groups' metadata.

An XSS issue was discovered in the SocialProfile extension in MediaWiki through 1.36. Within several gift-related special pages, a privileged user with the awardmanage right could inject arbitrary HTML and JavaScript within various gift-related data fields. The attack could easily propagate across many pages for many users.

An XSS issue was discovered in the SportsTeams extension in MediaWiki through 1.36. Within several special pages, a privileged user could inject arbitrary HTML and JavaScript within various data fields. The attack could easily propagate across many pages for many users.

An issue was discovered in the FileImporter extension in MediaWiki through 1.36. For certain relaxed configurations of the $wgFileImporterRequiredRight variable, it might not validate all appropriate user rights, thus allowing a user with insufficient rights to perform operations (specifically file uploads) that they should not be allowed to perform.

Уязвимость контейнера сервлетов Eclipse Jetty, связанная с созданием временных файлов с небезопасными разрешениями, позволяющая нарушителю повысить свои привилегии

Уязвимость контейнера сервлетов Eclipse Jetty, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю вызвать отказ в обслуживании

In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.

In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request.

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.

Уязвимость компонента PersistenceManager сервера приложений Apache Tomcat, позволяющая нарушителю выполнить произвольный код

Уязвимость реализации сетевого протокола HTTP/2 сервера приложений Apache Tomcat, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Уязвимость реализации конфигурации сервера приложений Apache Tomcat, позволяющая нарушителю выполнить произвольный код

Уязвимость сервера приложений Apache Tomcat, существующая из-за недостаточной проверки входных данных, позволяющая нарушителю вызвать отказ в обслуживании

While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.

When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed.

When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.

When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.

The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue.

Apache Tomcat 8.5.0 to 8.5.63, 9.0.0-M1 to 9.0.43 and 10.0.0-M1 to 10.0.2 did not properly validate incoming TLS packets. When Tomcat was configured to use NIO+OpenSSL or NIO2+OpenSSL for TLS, a specially crafted packet could be used to trigger an infinite loop resulting in a denial of service.

Уязвимость реализации неблокирующего метода ввода/вывода («nonblocking I/O») сервера приложений Apache Tomcat, позволяющая нарушителю вызвать отказ в обслуживании

A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.

не закрыты CVE-2020-13943, CVE-2020-17527, CVE-2021-24122, CVE-2021-25122, CVE-2021-25329