#git

### Impact In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R ...

### Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the `#syntax` line on your Dockerfile, or with `--frontend` flag when using `buildctl build` command. ### References

### Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with `--mount=type=cache,source=...` options. ### References https://www.openwall.com/lists/oss-security/2019/05/28/1

### Impact A malicious BuildKit frontend or Dockerfile using `RUN --mount` could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. ### Patches The issue has been fixed in v0.12.5 ### Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing `RUN --mount` feature. ### References

### Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. ### Patches The issue has been fixed in v0.12.5 . ### Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the `#syntax` line on your Dockerfile, or with `--frontend` flag when using `buildctl build` command. ### References

### Summary A ReDoS vulnerability occurs when nodemailer tries to parse img files with the parameter `attachDataUrls` set, causing the stuck of event loop. Another flaw was found when nodemailer tries to parse an attachments with a embedded file, causing the stuck of event loop. ### Details Regex: /^data:((?:[^;]*;)*(?:[^,]*)),(.*)$/ Path: compile -> getAttachments -> _processDataUrl Regex: /(<img\b[^>]* src\s*=[\s"']*)(data:([^;]+);[^"'>\s]+)/ Path: _convertDataImages ### PoC https://gist.github.com/francoatmega/890dd5053375333e40c6fdbcc8c58df6 https://gist.github.com/francoatmega/9aab042b0b24968d7b7039818e8b2698 ### Impact ReDoS causes the event loop to stuck a specially crafted evil email can cause this problem.

### Impact It is possible to craft an OCI tar archive that, when stereoscope attempts to unarchive the contents, will result in writing to paths outside of the unarchive temporary directory. Specifically, use of `github.com/anchore/stereoscope/pkg/file.UntarToDirectory()` function, the `github.com/anchore/stereoscope/pkg/image/oci.TarballImageProvider` struct, or the higher level `github.com/anchore/stereoscope/pkg/image.Image.Read()` function express this vulnerability. ### Patches Patched in v0.0.1 ### Workarounds If you are using the OCI archive as input into stereoscope then you can switch to using an [OCI layout](https://github.com/opencontainers/image-spec/blob/main/image-layout.md) by unarchiving the tar archive and provide the unarchived directory to stereoscope. ### References - Patch PR https://github.com/anchore/stereoscope/pull/214

The MOAB may not be just recycled data after all.

### Description: When the application is password-protected (deployed with the `ACCESS_CODE` option), it is possible to access plugins without proper authorization (without password). ### Proof-of-Concept: Let’s suppose that application has been deployed with following command: ```sudo docker run -d -p 3210:3210 -e OPENAI_API_KEY=sk-[REDACTED] -e ACCESS_CODE=TEST123 --name lobe-chat lobehub/lobe-chat``` Due to the utilization of the `ACCESS_CODE`, access to the chat is possible only after entering the password:  However, it is possible to interact with chat plugins without entering the `ACCESS_CODE`. Example HTTP request: ``` POST /api/plugin/gateway HTTP/1.1 Host: localhost:3210 Content-Length: 1276 {"apiName":"checkWeatherUsingGET","arguments":"{\n \"location\": \"London\"\n}","identifier":"WeatherGPT","type":"default","manifest":{"api":[{"description":"Get current weather information","name"...

### Impact OctoPrint versions up until and including 1.9.3 contain a vulnerability that allows malicious admins to change the password of other admin accounts, including their own, without having to repeat their password. An attacker who managed to hijack an admin account might use this to lock out actual admins from their OctoPrint instance. ### Patches The vulnerability will be patched in version 1.10.0. ### Workarounds OctoPrint administrators are strongly advised to thoroughly vet who has admin access to their installation. ### Credits This vulnerability was discovered and responsibly disclosed to OctoPrint by Timothy "TK" Ruppert.