#docker

Researchers earned a $50,500 Bug Bounty after uncovering a critical supply chain flaw in a newly acquired firm,…

### Summary The application is vulnerable to parameter injection in database connection strings, which allows an attacker to read local files on the machine the application is running on. ### Details The application uses string concatenation to build database connection URIs which are then passed to corresponding libraries responsible for setting up the database connections. This string concatenation is done unsafely and without escaping or encoding the user input. This allows an user, in many cases, to inject arbitrary parameters into the URI string. These parameters can be potentially dangerous depending on the libraries used. One of these dangerous parameters is `allowAllFiles` in the library `github.com/go-sql-driver/mysql`. Should this be set to `true`, the library enables running the `LOAD DATA LOCAL INFILE` query on any file on the host machine (in this case, the machine that WhoDB is running on). Source: https://github.com/go-sql-driver/mysql/blob/7403860363ca112af503b4612...

### Summary While the application only displays Sqlite3 databases present in the directory `/db`, there is no path traversal prevention in place. This allows an unauthenticated attacker to open any Sqlite3 database present on the host machine that the application is running on. ### Details WhoDB allows users to connect to Sqlite3 databases. By default, the databases must be present in `/db/` (or alternatively `./tmp/` if development mode is enabled). Source: https://github.com/clidey/whodb/blob/ba6eb81d0ca40baead74bca58b2567166999d6a6/core/src/plugins/sqlite3/db.go#L14-L20 If no databases are present in the default directory, the UI indicates that the user is unable to open any databases:  The database file is an user-controlled value. This value is used in `.Join()` with the default directory, in order to get the full path of the database file to open. Source: https://github.co...

By integrating security into CI/CD, applying automated policies, and supporting developers with the right processes and tools, infosec teams can increase efficiency and build secure software.

IntelBroker targets Hewlett-Packard Enterprise (HPE) again, claiming to have access to the company’s internal infrastructure and the possibility…

### 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

# 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; ...

# 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...

# 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">...

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