#docker

Cybercrime has stopped being a problem of just the internet — it’s becoming a problem of the real world. Online scams now fund organized crime, hackers rent violence like a service, and even trusted apps or social platforms are turning into attack vectors. The result is a global system where every digital weakness can be turned into physical harm, economic loss, or political

### Impact ### youki’s apparmor handling performs insufficiently strict write-target validation, which—combined with path substitution during pathname resolution—can allow writes to unintended procfs locations. **Weak write-target check** youki only verifies that the destination lies somewhere under procfs. As a result, a write intended for `/proc/self/attr/apparmor/exec` can succeed even if the path has been redirected to `/proc/sys/kernel/hostname`(which is also in procfs). **Path substitution** While resolving a path component-by-component, a shared-mount race can substitute intermediate components and redirect the final target. This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems. https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm ### Credits ### Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@toni...

### Impact ### This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy `tmpfs` file and thus not apply the correct LSM labels to the container process. The mitigation runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files. Rather than using a fake `tmpfs` file for `/proc/self/attr/<label>`, an attacker could instead (through various means) make `/proc/self/attr/<label>` reference a real `procfs` file, but one that would still be a no-op (such as `/proc/self/sched`). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mi...

### Impact ### This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). In runc version 1.0.0-rc3 and later, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). The reason that the attacker can gain write access to these files is because the `/dev/console` bind-mount happens...

### Impact ### The OCI runtime specification has a `maskedPaths` feature that allows for files or directories to be "masked" by placing a mount on top of them to conceal their contents. This is primarily intended to protect against privileged users in non-user-namespaced from being able to write to files or access directories that would either provide sensitive information about the host to containers or allow containers to perform destructive or other privileged operations on the host (examples include `/proc/kcore`, `/proc/timer_list`, `/proc/acpi`, and `/proc/keys`). `maskedPaths` can be used to either mask a directory or a file -- directories are masked using a new read-only `tmpfs` instance that is mounted on top of the masked path, while files are masked by bind-mounting the container's `/dev/null` on top of the masked path. In all known versions of runc, when using the container's `/dev/null` to mask files, runc would not perform sufficient verification that the source o...

## Summary A command injection vulnerability in MotionEye allows attackers to achieve Remote Code Execution (RCE) by supplying malicious values in configuration fields exposed via the Web UI. Because MotionEye writes user-supplied values directly into Motion configuration files without sanitization, attackers can inject shell syntax that is executed when the Motion process restarts. This issue enables full takeover of the MotionEye container and potentially the host environment (depending on container privileges). ## Details ### Root Cause: MotionEye accepts arbitrary strings from fields such as **image_file_name** and **movie_filename** in the Web UI. These are written directly into **/etc/motioneye/camera-*.conf**. When MotionEye restarts the Motion service (motionctl.start), the Motion binary reads this configuration. Because Motion treats these fields as shell-expandable, injected characters (e.g. $(), backticks) are interpreted as shell commands. ### Vulnerability flow: Dashboa...

Cyberattacks are getting smarter and harder to stop. This week, hackers used sneaky tools, tricked trusted systems, and quickly took advantage of new security problems—some just hours after being found. No system was fully safe. From spying and fake job scams to strong ransomware and tricky phishing, the attacks came from all sides. Even encrypted backups and secure areas were put to the test.

Threat actors tied to North Korea have been observed targeting the Web3 and blockchain sectors as part of twin campaigns tracked as GhostCall and GhostHire. According to Kaspersky, the campaigns are part of a broader operation called SnatchCrypto that has been underway since at least 2017. The activity is attributed to a Lazarus Group sub-cluster called BlueNoroff, which is also known as APT38,

## Summary CVE-2025-57803 claims to be patched in ImageMagick 7.1.2-2, but **the fix is incomplete and ineffective**. The latest version **7.1.2-5 remains vulnerable** to the same integer overflow attack. The patch added `BMPOverflowCheck()` but placed it **after** the overflow occurs, making it useless. A malicious 58-byte BMP file can trigger AddressSanitizer crashes and DoS. **Affected Versions:** - ImageMagick < 7.1.2-2 (originally reported) - **ImageMagick 7.1.2-2 through 7.1.2-5 (incomplete patch)** **Platform and Configuration Requirements:** - 32-bit systems ONLY (i386, i686, armv7l, etc.) - Requires `size_t = 4 bytes`. (64-bit systems are **NOT vulnerable** (size_t = 8 bytes)) - Requires modified resource limits: The default `width`, `height`, and `area` limits must have been manually increased (Systems using default ImageMagick resource limits are **NOT vulnerable**). --- ## Details(Root Cause Analysis) ### Vulnerable Code Location **File:** `coders/bmp.c` **Lines:*...

Docker Compose trusts the path information embedded in remote OCI compose artifacts. When a layer includes the annotations com.docker.compose.extends or com.docker.compose.envfile, Compose joins the attacker‑supplied value from com.docker.compose.file/com.docker.compose.envfile with its local cache directory and writes the file there. ### Impact This affects any platform or workflow that resolves remote OCI compose artifacts, Docker Desktop, standalone Compose binaries on Linux, CI/CD runners, cloud dev environments is affected. An attacker can escape the cache directory and overwrite arbitrary files on the machine running docker compose, even if the user only runs read‑only commands such as docker compose config or docker compose ps. ### Patches v2.40.2 ### Workarounds NA