dep on docker-cli is wrong

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

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

Уязвимость плагинов авторизации (AuthZ) программного обеспечения автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации Docker Engine, позволяющая нарушителю повысить свои привилегии

Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well. When containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs. Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly. In addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver. When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself. As a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved. Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected. Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address. Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.

Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. In 26.0.0, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`. An container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, (1) Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses, (2) if router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses, and (3) the interface will be a member of IPv6 multicast groups. This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface. The issue is patched in 26.0.2. To completely disable IPv6 in a container, use `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create` or `docker run` command. Or, in the service configuration of a `compose` file.

Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low. Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it. A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted. Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable. docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.

Не использует опции Docker: DOCKER_NETWORK_OPTIONS → OPTIONS

не корректная информация о версии

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

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

containerd is an open source container runtime. Before versions 1.6.18 and 1.5.18, when importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service. This bug has been fixed in containerd 1.6.18 and 1.5.18. Users should update to these versions to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.

containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and 1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. Downstream applications that use the containerd client library may be affected as well. This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions. As a workaround, ensure that the `"USER $USERNAME"` Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to `ENTRYPOINT ["su", "-", "user"]` to allow `su` to properly set up supplementary groups.

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

Уязвимость файла includes/page/Article.php программного средства для реализации гипертекстовой среды MediaWiki, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации

Уязвимость программного средства для реализации гипертекстовой среды MediaWiki, существующая из-за непринятия мер по защите структуры веб-страницы, позволяющая нарушителю провести атаку межсайтового скриптинга (XSS)

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

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

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

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

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

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

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

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

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

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

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

A insufficiently protected credentials vulnerability in fixed in curl 7.83.0 might leak authentication or cookie header data on HTTP redirects to the same host but another port number.

An issue was discovered in MediaWiki through 1.37.2. The SecurePoll extension allows a leak because sorting by timestamp is supported,

The Private Domains extension for MediaWiki through 1.37.2 (before 1ad65d4c1c199b375ea80988d99ab51ae068f766) allows CSRF for editing pages that store the extension's configuration. The attacker must trigger a POST request to Special:PrivateDomains.

The SemanticDrilldown extension for MediaWiki through 1.37.2 (before e688bdba6434591b5dff689a45e4d53459954773) allows SQL injection with certain '-' and '_' constraints.

The FanBoxes extension for MediaWiki through 1.37.2 (before 027ffb0b9d6fe0d823810cf03f5b562a212162d4) allows Special:UserBoxes CSRF.

The admin API module in the QuizGame extension for MediaWiki through 1.37.2 (before 665e33a68f6fa1167df99c0aa18ed0157cdf9f66) omits a check for the quizadmin user.

The Nimbus skin for MediaWiki through 1.37.2 (before 6f9c8fb868345701d9544a54d9752515aace39df) allows XSS in Advertise link messages.

An issue was discovered in MediaWiki through 1.38.1. The lemma length of a Wikibase lexeme is currently capped at a thousand characters. Unfortunately, this length is not validated, allowing much larger lexemes to be created, which introduces various denial-of-service attack vectors within the Wikibase and WikibaseLexeme extensions. This is related to Special:NewLexeme and Special:NewProperty.

An issue was discovered in MediaWiki before 1.35.7, 1.36.x and 1.37.x before 1.37.3, and 1.38.x before 1.38.1. XSS can occur in configurations that allow a JavaScript payload in a username. After account creation, when it sets the page title to "Welcome" followed by the username, the username is not escaped: SpecialCreateAccount::successfulAction() calls ::showSuccessPage() with a message as second parameter, and OutputPage::setPageTitle() uses text().

An issue was discovered in MediaWiki before 1.37.3 and 1.38.x before 1.38.1. The contributions-title, used on Special:Contributions, is used as page title without escaping. Hence, in a non-default configuration where a username contains HTML entities, it won't be escaped.

An issue was discovered in the MediaWiki through 1.38.2. The community configuration pages for the GrowthExperiments extension could cause a site to become unavailable due to insufficient validation when certain actions (including page moves) were performed.

An issue was discovered in MediaWiki before 1.35.8, 1.36.x and 1.37.x before 1.37.5, and 1.38.x before 1.38.3. HTMLUserTextField exposes the existence of hidden users.

An issue was discovered in MediaWiki before 1.35.8, 1.36.x and 1.37.x before 1.37.5, and 1.38.x before 1.38.3. Upon an action=rollback operation, the alreadyrolled message can leak a user name (when the user has been revision deleted/suppressed).

An issue was discovered in MediaWiki before 1.35.8, 1.36.x and 1.37.x before 1.37.5, and 1.38.x before 1.38.3. When changes made by an IP address are reassigned to a user (using reassignEdits.php), the changes will still be attributed to the IP address on Special:Contributions when doing a range lookup.

An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. When installing with a pre-existing data directory that has weak permissions, the SQLite files are created with file mode 0644, i.e., world readable to local users. These files include credentials data.

An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. SpecialMobileHistory allows remote attackers to cause a denial of service because database queries are slow.

An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. There is XSS in Wikibase date formatting via wikibase-time-precision-* fields. This allows JavaScript execution by staff/admin users who do not intentionally have the editsitejs capability.

An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. E-Widgets does widget replacement in HTML attributes, which can lead to XSS, because widget authors often do not expect that their widget is executed in an HTML attribute context.

An issue was discovered in MediaWiki before 1.35.9, 1.36.x through 1.38.x before 1.38.5, and 1.39.x before 1.39.1. CheckUser TokenManager insecurely uses AES-CTR encryption with a repeated (aka re-used) nonce, allowing an adversary to decrypt.

In the GrowthExperiments extension for MediaWiki through 1.39, the growthmanagementorlist API allows blocked users (blocked in ApiManageMentorList) to enroll as mentors or edit any of their mentorship-related properties.

An issue was discovered in the GrowthExperiments extension for MediaWiki through 1.39.3. The UserImpactHandler for GrowthExperiments inadvertently returns the timezone preference for arbitrary users, which can be used to de-anonymize users.

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. When a user with checkuserlog permissions makes many CheckUserLog API requests in some configurations, denial of service can occur (RequestTimeoutException or upstream request timeout).

An issue was discovered in the GrowthExperiments extension for MediaWiki through 1.39.3. Attackers might be able to see edits for which the username has been hidden, because there is no check for rev_deleted.

An issue was discovered in MediaWiki before 1.35.10, 1.36.x through 1.38.x before 1.38.6, and 1.39.x before 1.39.3. An auto-block can occur for an untrusted X-Forwarded-For header.

guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP. Affected versions are subject to improper header parsing. An attacker could sneak in a newline (\n) into both the header names and values. While the specification states that \r\n\r\n is used to terminate the header list, many servers in the wild will also accept \n\n. This is a follow-up to CVE-2022-24775 where the fix was incomplete. The issue has been patched in versions 1.9.1 and 2.4.5. There are no known workarounds for this vulnerability. Users are advised to upgrade.

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.

An issue was discovered in MediaWiki before 1.35.11, 1.36.x through 1.38.x before 1.38.7, 1.39.x before 1.39.4, and 1.40.x before 1.40.1. It is possible to bypass the Bad image list (aka badFile) by using the thumb parameter (aka Manualthumb) of the File syntax.

An issue was discovered in MediaWiki before 1.35.11, 1.36.x through 1.38.x before 1.38.7, and 1.39.x before 1.39.4. BlockLogFormatter.php in BlockLogFormatter allows XSS in the partial blocks feature.

An issue was discovered in the GoogleAnalyticsMetrics extension for MediaWiki through 1.39.3. The googleanalyticstrackurl parser function does not properly escape JavaScript in the onclick handler and does not prevent use of javascript: URLs.

An issue was discovered in the Cargo extension for MediaWiki through 1.39.3. XSS can occur in Special:CargoQuery via a crafted page item when using the default format.

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. In Special:CheckUser, a check of the "get edits" type is vulnerable to HTML injection through the User-Agent HTTP request header.

An issue was discovered in the Cargo extension for MediaWiki through 1.39.3. It allows one to store javascript: URLs in URL fields, and automatically links these URLs.

An issue was discovered in the CheckUserLog API in the CheckUser extension for MediaWiki through 1.39.3. There is incorrect access control for visibility of hidden users.

An issue was discovered in SubmitEntityAction in Wikibase in MediaWiki through 1.39.3. Because it doesn't use EditEntity for undo and restore, the intended interaction with AbuseFilter does not occur.

An issue was discovered in SiteLinksView.php in Wikibase in MediaWiki through 1.39.3. There is XSS via a crafted badge title attribute. This is also related to lack of escaping in wbTemplate (from resources/wikibase/templates.js) for quotes (which can be in a title attribute).

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. In certain situations, an attempt to block a user fails after a temporary browser hang and a DBQueryDisconnectedError error message.

An issue was discovered in the DoubleWiki extension for MediaWiki through 1.39.3. includes/DoubleWiki.php allows XSS via the column alignment feature.

An issue was discovered in the ProofreadPage (aka Proofread Page) extension for MediaWiki through 1.39.3. In includes/Page/PageContentHandler.php and includes/Page/PageDisplayHandler.php, hidden users can be exposed via public interfaces.

An issue was discovered in the Vector Skin component for MediaWiki before 1.39.5 and 1.40.x before 1.40.1. vector-toc-toggle-button-label is not escaped, but should be, because the line param can have markup.

An issue was discovered in MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. There is XSS in youhavenewmessagesmanyusers and youhavenewmessages i18n messages. This is related to MediaWiki:Youhavenewmessagesfromusers.

An issue was discovered in VectorComponentUserLinks.php in the Vector Skin component in MediaWiki before 1.39.5 and 1.40.x before 1.40.1. vector-intro-page MalformedTitleException is uncaught if it is not a valid title, leading to incorrect web pages.

An issue was discovered in DifferenceEngine.php in MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. diff-multi-sameuser (aka "X intermediate revisions by the same user not shown") ignores username suppression. This is an information leak.

An issue was discovered in ApiPageSet.php in MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. It allows attackers to cause a denial of service (unbounded loop and RequestTimeoutException) when querying pages redirected to other variants with redirects and converttitles set.

An issue was discovered in includes/page/Article.php in MediaWiki 1.36.x through 1.39.x before 1.39.5 and 1.40.x before 1.40.1. Deleted revision existence is leaked due to incorrect permissions being checked. This reveals that a given revision ID belonged to the given page title, and its timestamp, both of which are not supposed to be public information.

An issue was discovered in the CheckUser extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. A user can use a rest.php/checkuser/v0/useragent-clienthints/revision/ URL to store an arbitrary number of rows in cu_useragent_clienthints, leading to a denial of service.

An issue was discovered in the PageTriage extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. Usernames of hidden users are exposed.

An issue was discovered in the SportsTeams extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. SportsTeams: Special:SportsManagerLogo and Special:SportsTeamsManagerLogo do not check for the sportsteamsmanager user right, and thus an attacker may be able to affect pages that are concerned with sports teams.

An issue was discovered in the Wikibase extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. There is no rate limit for merging items.

An issue was discovered in the Wikibase extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. During item merging, ItemMergeInteractor does not have an edit filter running (e.g., AbuseFilter).

An issue was discovered in the ProofreadPage extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. XSS can occur via formatNumNoSeparators.

An issue was discovered in the SportsTeams extension for MediaWiki before 1.35.12, 1.36.x through 1.39.x before 1.39.5, and 1.40.x before 1.40.1. It does not check for the anti-CSRF edit token in Special:SportsTeamsManager and Special:UpdateFavoriteTeams.

Непрописанный файловый конфликт между mediawiki-common и mediawiki-extensions-Math

Прошу собрать с PHP 8.2

WP-CLI is the command-line interface for WordPress. An improper error handling in HTTPS requests management in WP-CLI version 0.12.0 and later allows remote attackers able to intercept the communication to remotely disable the certificate verification on WP-CLI side, gaining full control over the communication content, including the ability to impersonate update servers and push malicious updates towards WordPress instances controlled by the vulnerable WP-CLI agent, or push malicious updates toward WP-CLI itself. The vulnerability stems from the fact that the default behavior of `WP_CLI\Utils\http_request()` when encountering a TLS handshake error is to disable certificate validation and retry the same request. The default behavior has been changed with version 2.5.0 of WP-CLI and the `wp-cli/wp-cli` framework (via https://github.com/wp-cli/wp-cli/pull/5523) so that the `WP_CLI\Utils\http_request()` method accepts an `$insecure` option that is `false` by default and consequently that a TLS handshake failure is a hard error by default. This new default is a breaking change and ripples through to all consumers of `WP_CLI\Utils\http_request()`, including those in separate WP-CLI bundled or third-party packages. https://github.com/wp-cli/wp-cli/pull/5523 has also added an `--insecure` flag to the `cli update` command to counter this breaking change. There is no direct workaround for the default insecure behavior of `wp-cli/wp-cli` versions before 2.5.0. The workaround for dealing with the breaking change in the commands directly affected by the new secure default behavior is to add the `--insecure` flag to manually opt-in to the previous insecure behavior.