Security
Headlines
HeadlinesLatestCVEs

Tag

#docker

GHSA-36gq-35j3-p9r9: Excessive Platform Resource Consumption within a Loop when unmarshalling Compose file having recursive loop

### Impact The `compose-go` library component in versions `v2.10-v2.4.0` allows an authorized user who sends malicious YAML payloads to cause the `compose-go` to consume excessive amount of Memory and CPU cycles while parsing YAML, such as used by Docker Compose from versions ` v2.27.0` to `v2.29.7` included ### Patches compose-go `v2.24.1` fixed the issue ### Workarounds There isn't any known workaround. ### References * https://github.com/docker/compose/issues/12235 * https://github.com/compose-spec/compose-go/pull/703 * https://github.com/compose-spec/compose-go/pull/618 * https://github.com/docker/compose/commit/d239f0f3187a2ed5404c61f83bd5e995c81600ff#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R10

ghsa
#vulnerability#git#auth#docker
GHSA-43c9-gw4x-pcx6: Authenticated arbitrary file deletion in YesWiki

# Authenticated arbitrary file deletion in YesWiki <= 4.4.5 ### Summary It is possible for any authenticated user, through the use of the filemanager to delete any file owned by the user running the FastCGI Process Manager (FPM) on the host without any limitation on the filesystem's scope. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the `filemanager` that allows a user to manage files that are attached to a resource when they have owner permission on it. This part of the code is managed in `tools/attach/libs/attach.lib.php` ```php public function doFileManager($isAction = false) { $do = (isset($_GET['do']) && $_GET['do']) ? $_GET['do'] : ''; switch ($do) { case 'restore': $this->fmRestore(); $this->fmShow(true, $isAction); break; ...

GHSA-w59h-3x3q-3p6j: Authenticated Stored XSS in YesWiki

# Authenticated Stored XSS in YesWiki <= 4.4.5 ### Summary It is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This part of the code is managed in `tools/attach/libs/attach.lib.php` and the faulty function is **[showFileNotExits()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/att...

GHSA-wphc-5f2j-jhvg: Unauthenticated DOM Based XSS in YesWiki

# Unauthenticated DOM Based XSS in YesWiki <= 4.4.5 ### Summary It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This part of the code is managed by `tools/tags/handlers/page/listpages.php`, and **[this piece of code](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/tags/handlers/page/listpages.php#L84)** is responsible for the vulnerability: ```php $output .= '<div class="alert alert-info">...

Introducing confidential containers on bare metal

Confidential Containers (CoCo) are containers deployed within an isolated hardware enclave protecting data and code (data in use) from privileged users such as cloud administrators. Red Hat OpenShift confidential containers are available from OpenShift sandboxed containers 1.7.0 as a tech-preview on Azure cloud and as a tech-preview on Azure Red Hat OpenShift.In this article we introduce confidential containers on bare metal which is now available as a preview using Assisted Installer for OpenShift. We cover a number of use cases for CoCo bare metal, explain how it works with different trusted

Hackers Claim Breach of Hewlett Packard Enterprise, Lists Data for Sale

Hacker IntelBroker claims to have breached Hewlett Packard Enterprise (HPE), exposing sensitive data like source code, certificates, and…

GHSA-rcxc-wjgw-579r: Matrix Media Repo (MMR) allows untrusted file formats can be thumbnailed, invoking potentially further untrusted decoders

### Impact If SVG or JPEGXL thumbnailers are enabled (they are disabled by default), a user may upload a file which claims to be either of these types and request a thumbnail to invoke a different decoder in ImageMagick. In some ImageMagick installations, this includes the capability to run Ghostscript to decode the image/file. If MP4 thumbnailers are enabled (also disabled by default), the same issue as above may occur with the ffmpeg installation instead. MMR uses a number of other decoders for all other file types when preparing thumbnails. Theoretical issues are possible with these decoders, however in testing they were not possible to exploit. ### Patches This is fixed in [MMR v1.3.8](https://github.com/t2bot/matrix-media-repo/releases/tag/v1.3.8). MMR now inspects the mimetype of media prior to thumbnailing, and picks a thumbnailer based on those results instead of relying on user-supplied values. This may lead to fewer thumbnails when obscure file shapes are used. This also...

Malicious Kong Ingress Controller Image Found on DockerHub

A critical security breach in the software supply chain has been detected. An attacker accessed Kong’s DockerHub account…

GHSA-32q6-rr98-cjqv: OpenFGA Authorization Bypass

### Overview OpenFGA v1.3.8 to v1.8.2 (Helm chart openfga-0.1.38 to openfga-0.2.19, docker v1.3.8 to v.1.8.2) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. ### Am I Affected? You are affected by this authorization bypass vulnerability if you are using OpenFGA v1.3.8 to v1.8.2, specifically under the following conditions: 1. Calling Check API or ListObjects with a model that uses [conditions](https://openfga.dev/docs/modeling/conditions), and 2. OpenFGA is configured with caching enabled (`OPENFGA_CHECK_QUERY_CACHE_ENABLED`), and 3. Check API call or ListObjects API calls contain [contextual tuples](https://openfga.dev/docs/concepts#what-are-contextual-tuples) that include conditions. ### Fix Upgrade to v1.8.3. This upgrade is backwards compatible.

GHSA-2r2v-9pf8-6342: WireGuard Portal v2 Vulnerable to OAuth Insecure Redirect URI / Account Takeover

### Impact Users of WireGuard Portal v2 who have OAuth (or OIDC) authentication backends enabled can be affected by an Account Takeover vulnerability if they visit a malicious website. ### Patches The problem was fixed in the latest alpha release, v2.0.0-alpha.3. The [docker images](https://hub.docker.com/r/wgportal/wg-portal) for the tag 'latest' built from the master branch also include the fix.